I know he's talking about Delphi here, but FreePascal+Lazarus is still one of my secret weapons. It has some sort of supernatural force field which causes people to ignore it and unfairly denigrate it; meanwhile I whip up desktop applications in hours that would normally take days.
A roadmap for Lazarus just released on 19 Aug 2023 (3 minutes video) https://www.youtube.com/watch?v=ixQ2LZTzVJQ
I come here not to bury Delphi, but to praise it (2019)
11–20 of 113 posts
Re: I come here not to bury Delphi, but to praise it (2019)
#12Earlier quoted context omitted.
> long term maintenance was. How so?
Because it's all proprietary, and continuously deprecated to blend better with the latest hype. I did 13 years with Delphi, full time.
We upgrade every year or so, and in almost all cases it's smooth sailing.
Delphi has been quite good so far when it comes to long term maintenance.
Re: I come here not to bury Delphi, but to praise it (2019)
#13Re: I come here not to bury Delphi, but to praise it (2019)
#14Delphi could have potentially navigated into the web era quickly enough, but was slow to do so. It was essentially a Windows product at its core. They made a half-hearted attempt to port it to Linux but did so using Wine(lib) which back then was very rough, so Kylix had a poor UX and of course the problem was that the Delphi widget toolkit was the Windows toolkit which Linux didn't have. IIRC it was also quite slow to even get things like an HTTP stack, which had to be produced by a third party company.
The focus on visual componentization back then was kinda great though. That's definitely something that went AWOL somewhere along the line. The good database integration is also sorely missing in more modern languages and frameworks.
Re: I come here not to bury Delphi, but to praise it (2019)
#15The no-circular-dependencies rule was a huge pain though. It allowed the compiler to be very fast (along with it basically not optimizing), but no other language has copied this because combined with weak to non-existent refactoring tools it was just a constant pain to be hitting this limitation whilst developing. Sure, if you're an architecture god who plans out all their internal interfaces in advance on paper it w…
Go forbids circular dependencies.
Re: I come here not to bury Delphi, but to praise it (2019)
#16Earlier quoted context omitted.
> long term maintenance was. How so?
Because it's all proprietary, and continuously deprecated to blend better with the latest hype. I did 13 years with Delphi, full time.
Re: I come here not to bury Delphi, but to praise it (2019)
#17Couple of observations:
- Using C (Borland or Microsoft) required two floppy disks - one for the compiler, one for the linker. With most of the Pascal versions you end up just needing one floppy disk, later it didn't matter as we moved to HDD.
- First "terrible" experience (by a friend) - he moved from Pascal to C and placed all his code in the .h-eader file, and was wondering why it takes so much to compile (oh, yes nowadays it's fashionable to have header-only libs, lol), but then it was awful.
- Pascal Units enforced you (as explained in the article) to figure out cyclic dependencies, unfortunately lots of us thought of this as a limitation, which C/C++ did not had. How wrong we were!
- There was barely any use of preprocessor (yes there was), and it was more into the language, than some external pre-processor.
- Mark/Release was superior, but also harder to understand the idea than plain old malloc/free
* Mark - "Records the state of the heap in a pointer variable".
* Release - "Returns the heap to a given state".
* So you can quickly release memory in one hop (like nowadays what json parser might need to do).
- Turbo Pascal 3.0 was only 30-40kb - Even later Borland could keep up to a single disk. Assembly was approachable from it
- Peephole optimization!Re: I come here not to bury Delphi, but to praise it (2019)
#18The no-circular-dependencies rule was a huge pain though. It allowed the compiler to be very fast (along with it basically not optimizing), but no other language has copied this because combined with weak to non-existent refactoring tools it was just a constant pain to be hitting this limitation whilst developing. Sure, if you're an architecture god who plans out all their internal interfaces in advance on paper it w…
>The no-circular-dependencies rule was a huge pain though. It allowed the compiler to be very fast (along with it basically not optimizing), but no other language has copied this Go forbids circular dependencies.
Re: I come here not to bury Delphi, but to praise it (2019)
#19I started with Turbo Pascal 3, Moved to 4, 4.5, 5, 6 then Delphi. Somewhere in there moved to "C" and then "C++". Couple of observations: - Using C (Borland or Microsoft) required two floppy disks - one for the compiler, one for the linker. With most of the Pascal versions you end up just needing one floppy disk, later it didn't matter as we moved to HDD. - First "terrible" experience (by a friend) - he moved from Pa…
TSR applications while a bit large than pure .asm were possible!
Re: I come here not to bury Delphi, but to praise it (2019)
#20The no-circular-dependencies rule was a huge pain though. It allowed the compiler to be very fast (along with it basically not optimizing), but no other language has copied this because combined with weak to non-existent refactoring tools it was just a constant pain to be hitting this limitation whilst developing. Sure, if you're an architecture god who plans out all their internal interfaces in advance on paper it w…
>The no-circular-dependencies rule was a huge pain though. It allowed the compiler to be very fast (along with it basically not optimizing), but no other language has copied this Go forbids circular dependencies.