My most productive time was early-mid '90s using a 4GL for green screen applications.<p>You could pound out a trivial screen or report in an hour. With SQL being a first class participant, you just interlaced SQL and logic to get your bidding done. Turn around was really fast. Having a functional TUI meant there was no time lost fiddling with placement or colors or any of that. The hardest part was squeezing everything on to a single 80x24 screen, and those high density screens were really rare. "Any color you like, as long as it's green."<p>I won't say it was low code, but it was certainly a lot less code. If the application fit well into the "CRUD screen/reports" paradigm, it was a lot less code. It was almost pure logic, with little need for formatting or UI. Mostly validation and deciding what fields to skip and when.<p>With flexibiliy comes complexity. For back office data processing, this solved an enormous swath of problems. It was pre-web, pre-json. It was not OO in any way. Code reuse was perhaps a bit more difficult that one may have liked, but at the same time, it wasn't really that necessary. Each program did its own thing, rarely did that overlap with other programs, so less need to actually share logic.<p>Unix processes, CRON for scheduling. We had no need for a message queue, beyond stuffing things into tables and processing stuff in batches. Workflows based on end-of-day, end-of-week, and end-of-month processes.<p>Honestly, never felt constrained by the limitations of the system. Not really. And, despite all of the gains and modern UXs, how pretty, and flashy, and such it is, it's just not that much better IMHO. Not for most back office use cases, not for the complexity and time it takes to create modern apps.<p>Still, its very hard to go back. As much as "You're not going to need it", it's hard to leave that flexibility behind, "Just in case".