> for the type of application that Delphi is appropriate
What type of application is that, in your opinion? Would you use it for a web-based app? (Many boring corporate apps are now web-based, and not just because the developers want that. The business people often want it too.)
> new languages/platforms and especially modern program design paradigms with their multiple tiers & supporting libraries, multiple levels of indirection resulting in 30 level deep call stacks, etc results in productivity perhaps 1/4 of what you could achieve with a product like Delphi.
Modern languages don't particularly encourage or discourage that style of programming. Let's assume we're comparing Delphi to Ruby and Python as the modern competitors for the high-productivity, just-get-it-done language. Those languages have standard libraries with rather minimalist APIs, so I don't see the bloat there.
Now, it's true that frameworks in those languages, like Django and Rails, and huge and have deep callstacks and lots of indirection.
But those frameworks are big because their problem domain (dynamic web app development) is so big and complex. I challenge anyone to find a framework in any language that 1) is as powerful and flexible as Django or Rails, 2) is sanely coded, and 3) doesn't have deep call stacks or lots of indirection.
Maybe I'm way off base, and you're not talking about web development at all. I went that direction because web development is what I think of when people start talking about boring business apps.
I can't comment on the web capabilities of Delphi specifically, I'm thinking your standard boring enterprisey CRUD app with various calculations/business logic/reports, etc....thousands of new apps of these kind are written every year, nowadays typically with a web front end (regardless if that's really necessary, all things considered). For most complex applications, a client based GUI is superior for power users, the portions of the app that need widespread distribution can be implemented with a web interface.
The big difference to me is the automatic binding of data from the database through to the UI, you're "done" the requirements so quickly that the currently standard practices of "improving" things with some design patterns and what not gets skipped. It's not so much that Delphi's language capabilities are superior (other than the binding), I think it's that so much of the currently fashionable bloat is more likely to be skipped.
> Modern languages don't particularly encourage or discourage that style of programming
I agree...this is not forced on us by modern languages, it is current culture/fashion. There are so many cool geegaws out there today, it would be a shame to not use them such that you can include that experience on your resume (to hell with the additional costs and complexity, let someone else worry about that.)
> What type of application is that, in your opinion?
Not the OP, but I wanted to chime in that I think Delphi's forte is, was and will always be desktop-based GUI apps. That was always the main point.
Admittedly, I haven't touched it since the early 2000s, but I can't imagine that it could compete as a language/platform for anything else these days. Its power comes from the tight GUI design/language integration, the brilliance of which is still unmatched by tools like Interface Builer; but the language — even with features like generics — hasn't been able to keep up.
That said, in the late 1990s/early 2000s, I was actually using Delphi for headless backend apps. They were distributed, fairly complex backends connected using DCOM and interfacing with Windows technologies like TAPI and MAPI. We had to integrate with C libraries (linked as DLLs) and had to convert the header files to ObjectPascal. I actually wrote a tool called htrans that had a hand-coded C/C++ parser that produced very good ObjectPascal translations, but it was still a chore. Talk about going against the grain.
In hindsight, I should probably have been using C++, and a lot of the problems our team had was due to the fact that we were trying to use Delphi for something that Borland just wasn't focusing on. But we did love the fast develop/compile/run cycle that Delphi provided, Delphi's OO was great at the time, and the apps worked. The difference between Delphi and C++ back then felt a lot like Rails versus, say, J2EE. It was incredibly easy to develop stuff.
> What type of application is that, in your opinion? Would you use it for a web-based app? (Many boring corporate apps are now web-based, and not just because the developers want that. The business people often want it too.)
I think this is mostly a lament of how very, very, very horrible web-based apps are for the developer. Delphi gets you pixel-perfect interfaces that work on a 486 with windows 95 right up to todays windows 8 (there is a version of delphi that would get you 3.1 support as well). With one recompile, the same app runs on android, ios. I have trouble writing a web-app that supports 2 browsers (and especially have not found a way to test that this is so without manually going through the app), yet every delphi app supports over 8 runtime environments.
> Modern languages don't particularly encourage or discourage that style of programming. Let's assume we're comparing Delphi to Ruby and Python as the modern competitors for the high-productivity, just-get-it-done language. Those languages have standard libraries with rather minimalist APIs, so I don't see the bloat there.
On the web there just isn't any other way of doing things. This is supposed to be flexible and "good" design, but here's the catch : changing one tiny thing in the backend requires you to change (e.g. go from 1 to 2 phone numbers per customer) :
1) the backend itself
2) the business rules in the second tier
3) the RPC/REST/... interface to the second tier
4) any and all frontend code interacting with this data
In delphi, by contrast, you change the backend, and that's it. At runtime, mind you, you don't even need a recompile in most cases. Tables will automatically start showing it, forms will magically contain the new field.
> I agree...this is not forced on us by modern languages, it is current culture/fashion. There are so many cool geegaws out there today, it would be a shame to not use them such that you can include that experience on your resume (to hell with the additional costs and complexity, let someone else worry about that.)
I think part of the question being asked here is "how do these help application development" ? How do they improve the applications ? Well, they make them worse.
What type of application is that, in your opinion? Would you use it for a web-based app? (Many boring corporate apps are now web-based, and not just because the developers want that. The business people often want it too.)
> new languages/platforms and especially modern program design paradigms with their multiple tiers & supporting libraries, multiple levels of indirection resulting in 30 level deep call stacks, etc results in productivity perhaps 1/4 of what you could achieve with a product like Delphi.
Modern languages don't particularly encourage or discourage that style of programming. Let's assume we're comparing Delphi to Ruby and Python as the modern competitors for the high-productivity, just-get-it-done language. Those languages have standard libraries with rather minimalist APIs, so I don't see the bloat there.
Now, it's true that frameworks in those languages, like Django and Rails, and huge and have deep callstacks and lots of indirection.
But those frameworks are big because their problem domain (dynamic web app development) is so big and complex. I challenge anyone to find a framework in any language that 1) is as powerful and flexible as Django or Rails, 2) is sanely coded, and 3) doesn't have deep call stacks or lots of indirection.
Maybe I'm way off base, and you're not talking about web development at all. I went that direction because web development is what I think of when people start talking about boring business apps.