[danielbarla]

Delphi certainly was supremely productive for the kinds of one-off, bespoke enterprise apps that I was involved with, and it is valid to question why that was the case. I don't think the tooling was necessarily all that superior, the industry trend was simply way towards "slap a grid on top of that SELECT * FROM Orders".

Clearly, there are many things wrong with that, but the fact that one could whip up several screens and essentially ship them in a few hours makes it a worthwhile thought exercise to think about what has been gained, and what lost. Most enterprise apps that I encounter seem to be massively overcomplicated for what they actually do.

[gonzo41]

Most enterprise apps that I encounter seem to be massively overcomplicated for what they actually do.

I think the big issue is every app I use/develop in the enterprise needs single sign on and fine grained access control. Those modern requirements create a minimum layer of complexity that really slows things down.

But yeah, the whole enterprise programming world really missed an opportunity with JavaFX. For all the shit they get being able to deploy desktop apps in a virtual environment is really powerful.

[cy_hauser]

> "slap a grid on top of that SELECT * FROM Orders"

FWIW, before there was Delphi there was an entire language (and consulting industry) built around this: PowerBuilder. Its primary component was a "DataWindow" which was a fancy presentation object around basic CRUD SQL. Good times were had by many.

[karmakaze]

Working on a number of quarantine projects, I have come close to this now. Currently make single fullstack repo for the app with backend and frontend code committed together and deployed separately. Client goes to Netlify. Backend to a hosted VM that can autoupdate from Github and apply schema migrations.

Local dev, autorefreshes the Vuejs frontend code (yarn serve) and backend autorefreshes with `air` if Go-based or Intellij debug hot-reload if Jvm-based. I can whip up a db schema, backend, and frontend in a day with a good amount of layout and styling. It just took repetition and templating a few things.

Which is to say it doesn't take a lot of tooling to be productive--as long as it's focused.

[jonnypotty]

What the hell else to business apps do? I'm genuinely interested to know what you think is the clear issue with showing users data from database tables.

[danielbarla]

I'm not sure I 100% understand your question, and it's also hard to respond without more context.

Many Delphi apps back in those days were very lazily slapped together, with thin layers of code (or none) on top of whatever queries got the job done. There are performance issues, security issues, correctness issues (in terms of: does the app allow you to do some things that should not be allowed). There are also meta-level issues that came into play, as anything that did not fit into the out of the box patterns was so outrageously more expensive to develop that companies opted away from it, and in many cases UX suffered.

On the other hand, we have now overreacted in the opposite direction, with many business apps having empty layers of code that do nothing except pass on the exact same message to the next layer, because, well, "that's how it's done in the real world", or something. Tons of boilerplate code get created that never end up adding any real value. Other than this specific example, there are plenty of YAGNI violations.

I prefer something of a balance between the two.

[jonnypotty]

I guess I don't buy the idea that anything has changed. If a straight query shows you the data you need why would you put anything else but a thin layer of software over the top? More software is worse, not better. Apps are still lazily created by people downloading frameworks and plugging them into whatever shit they happen to be creating at the time.

The issues you state. Security, correctness and performance. None of these are solved by having more software. It might seem safer if you have more layers of shit between the user and the valuable data, but it isn't. Having a mental idea that now I use 'model and view' im going to be quicker, more correct or more secure I think demonstrably isn't true.

[danielbarla]

This could be argued infinitely, I think. I do appreciate your points; yes, simply adding code - by default or by itself - does not resolve those things I mentioned. But, it's important to view my comments within the context of what we were talking about, which was the defacto development style that grew around Delphi, especially in the early days (before their libraries got smarter). In the case of my "SELECT *" example, this was quite often literally the case - queries were not optimised in the least bit regarding the columns and rows that were being retrieved (mostly due to lack of awareness or laziness). In terms of correctness, you can bet that business rules were usually sprinkled around the UI in a happenstance kind of way, rather than being collected in a relatively well defined, easy to verify and unit test business object, say. Again, while I do agree in theory that "more code" does not necessarily solve anything, these are the kinds of practicalities I am arguing about, not on a pure level. The tooling was great for getting things done instantly, but encouraged a laziness that caused a counter revolution which went too far in the opposite direction.

[jonnypotty]

My work until recently was working on one of the Delphi apps you're talking about. Not in terms of unoptimised queries but bad separation of business logic and ui. But the product has passed between 4 diffent companies and is over 20 years old now, I just don't see how you prevent these issues. I do see what you're saying, but I think the real issues is humans which hasn't changed.

[danielbarla]

Agreed, and I also don't have a real answer. At least, not a technological one. The closest we can get it is a bunch of developers who care about a product, ask themselves lots of "why do we do it this way", and "could this be done better", and try to come up with some solid answers. Of course, with products that survived 10+ years of maintenance, it is highly unlikely that enough time will be afforded to any team.

Circling back to what I was trying to say with the first comment - I suspect the rapid development promise and culture back in the day led to a lot of these apps being developed. The tooling was just an enabler.