3 ms·

I've never used Delphi, but I had a manager who had worked with it in a previous job, and he utterly hated it. It was kind of funny, because just mentioning it

I've never used Delphi, but I had a manager who had worked with it in a previous job, and he utterly hated it. It was kind of funny, because just mentioning it could get him started complaining about it for a good three minutes. It never looked that bad to me, but of course a quick glance on the Wikipedia page isn't equivalent to maintaining a large codebase. This manager was also a big advocate for the ColdFusion language, so take that for what it is, but I think his ranting about it has made it so I never tried it (or any of its derivatives).

praptak 2y ago
I hated maintaining a mid-sized Delphi code base too. Although this one might have to do with the fact that the main product code base was basically "a separate repository per each customer, copy-pasted from the least messy one when the development started". I also remember it was very easy to slap a simple CRUD GUI on top of an existing DB. The trouble started when you had to evolve this. Putting some non-trivial reusable business logic between the UI and the DB was non-trivial.
- CRConrad 2y ago
  > Putting some non-trivial reusable business logic between the UI and the DB was non-trivial. It took me a good long while to figure it out too, but once you got the hang of it, it wasn't really all that complex. AFAICR, the trick was mainly to put object definitions (that pretty closely reflected your DB table structures) and functions/procedures to manipulate them in your data modules with the DB components. The main problem, IMO, was that these strategies weren't really documented anywhere, you had to figure them out for yourself. This, in turn, was AIUI probably because Borland itself wanted to upsell you to the Enterprise (and later Architect) version, while independent companies also wanted to sell you their various (more-or-less-)fancy "middleware" alternatives.

praptak 2y ago

I hated maintaining a mid-sized Delphi code base too. Although this one might have to do with the fact that the main product code base was basically "a separate repository per each customer, copy-pasted from the least messy one when the development started". I also remember it was very easy to slap a simple CRUD GUI on top of an existing DB. The trouble started when you had to evolve this. Putting some non-trivial reusable business logic between the UI and the DB was non-trivial.

CRConrad 2y ago
> Putting some non-trivial reusable business logic between the UI and the DB was non-trivial. It took me a good long while to figure it out too, but once you got the hang of it, it wasn't really all that complex. AFAICR, the trick was mainly to put object definitions (that pretty closely reflected your DB table structures) and functions/procedures to manipulate them in your data modules with the DB components. The main problem, IMO, was that these strategies weren't really documented anywhere, you had to figure them out for yourself. This, in turn, was AIUI probably because Borland itself wanted to upsell you to the Enterprise (and later Architect) version, while independent companies also wanted to sell you their various (more-or-less-)fancy "middleware" alternatives.