I 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 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!
And Turbo Pascal was CHEAP, I think in terms of what you got for your $50? I can't remember the original retail price, you couldn't beat it. Hell, if you kept your eye out you could get copies of Delphi, / Delphi 3 for the cost of a "introduction to Delphi" book which almost always came with a standard license of Delphi.
Hobbyist Borland was the best Borland. A really amazing company that fully embraced those original tinkerers... Enterprise <X>, full vomit, but hey, that's where they got to charge many thousands per seat, so you can't really blame them.
Up until Delphi 5 or 6 the cheapest Delphi would be just $100, it wasn't until Borland became Inprise and chased that big $$$ enterprise money that their prices skyrocketed.
Turbo C was actually about the same price, I paid £32 I believe, and then paid £50 for the upgrade to Borland C++ 3.1 (all as a single purchase), vs paying the £200 or so for C++ on it's own. I remember it arriving the day after in a huge 'crate' full of books.
Most of the demo coders that I followed (I wanted to become one, but never did anything significant there), and demo docs were done using Pascal. Eastern europeans (like myself) seemed to prefer it more for some reasons.
TSR applications while a bit large than pure .asm were possible!
When working on demo effects, I found it extremely important to have lightning fast edit-compile-run cycles. Before interactive demo editing tools became a thing, we had to modify code and recompile it to see anything. With Turbo Pascal (or TASM for that matter) you'd have results in under a second. Every now and then your demo would crash, but having set up AUTOEXEC.BAT to start Turbo Pascal, you'd be back in your editor in a few seconds.
I just don't understand how people can put up with waiting for compilers, Docker image downloads, and "continuous integration" builds that take upwards of whole minutes. Granted, it takes some effort to get things fast, but it is perfectly possible on modern hardware to have lightning fast compilation, and runtime replacement of modules. For some reason most people just don't care, and it sometimes makes one feel terribly lonely.
If it was Borland's compiler suite it may or may not have been perfectly standards-compliant, hence the quotation marks. The Borland suite from the early 90s seemed to be pretty relaxed/forgiving about what was valid C/C++.
My school utilized Turbo C++ 3.0 for instruction (and later 4.5), which implemented some weird subset that was pre-C++98. Plenty of things that I was doing when targeting the Borland compiler barfed terribly when compiled with GCC (or G++).
I'd definitely consider what we were writing in those days "C" or "C++" but not anything that resembles modern software...
Not only that, but Borland also had extensions in their C++ compiler to simplify the development of GUI code (similar but different to the tricks Microsoft also used in their compilers).
I assume they are doing that to distinguish the Borland products (Borland C and Borland C++) from the programming languages. Everything in that sentence is the name of a Borland product.
Ugh - sorry this quoting must be my own thing - I don't know why I keep quoting btw, and unfortunately can't tell if anyone else does it (you mentioned people, but you might've just wanted to be polite to me - hehe).
I'll try to work on that! it got me thinking... why the heck!
You certainly aren't the only one, but it's still odd enough to be marked.
(To be more precise, I've seen C in quotes multiple times and maybe that's because one letter looks too small to be a name to some people, but I don't think I've ever seen C++ in quotes before.)
I can't imagine this would be at all sound today, if a heap was shared between multiple threads, or if you marked and released the heap across an arbitrary function pointer callback which allocates memory and expects it to remain valid to access until explicitly freed.
Delphi was what I had to use in my first apprenticeship/job, over 7 years ago now.
Came home after the first day and my dad told me that's what he made his first Windows programs with, too - but 25+ years ago!
After learning other languages, I still have to say it's great for quickly putting together GUIs and filling them with life. The community is rather thin these days though.
One of the OGs of 4GL GUI app development (see also PowerBuilder and the first Visual Basics). Strangely performant on 100 Mhz 486s and the like, I look back at things like Datawindows in Powerbuilder and look at how slow HTML tables are and wonder how the eff they did that with 1/100th the computing power.
Now that I'm an old coder, it really seems like pointless churn as GUI toolkits are constantly built and rebuilt, often with little to show for performance improvement. I do think CSS was a legitimate boon because it provides such a deep means for specifying appearance preferences and is known by so many people, but ultimately the toolkits are repackaging buttons/text entry/radios in mostly the same way the old 4GLs did, often with worse UI construction tools and much more complicated code.
Powerbuilder and Delphi definitely seemed to have GUI dev figured out, but each language transition needed its own (often worse) GUI toolkit and the GUI builder tools never really came. How long until NetBeans included a somewhat-decent GUI builder? Java had been around like 15 years.
NeXT had a great GUI designer too way back in 1990, although you had to write ObjectiveC for the handlers.
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.
Yeah though in practice it is more "write once, compile anywhere, debug everywhere" :-P as there are often minor (and sometimes major) inconsistencies between the underlying widget libraries (not Lazarus' fault though, if anything there is a lot of effort put into providing as much consistency as it can).
Last time I looked at this I couldn't really find an easy standard way to make HTTPS API calls and parse JSON, but only spent an hour or two playing with it. Can you point me at the canonical way to do this? What's the Requests of FreePascal?
I love comments like this because it shows me how diverse this field is, and how different everyone's experience and expectations are.
As a counterpoint to your comment, I make a living writing high-quality libraries. Everything I make is "in the box", but its not hard to improve on that.
My most popular tools are around string functions, json and xml readers/writers and network functionality.
So, on one hand I'm selling ice-cream in Alaska, on the other hand, it's good ice-cream.
It's a small market, a pimple on a niche, but its big enough to keep me going and that's big enough for me.
Free Pascal has fcl-web which should provide a HTTP/HTTPS client (among other things, it can be used to make web apps), though it comes with libcurl bindings out of the box so you could also use that too. fcl-json provides a JSON parser. FWIW "fcl" means "Free Component Library" which contains various tools (mainly exposed as classes).
The packages[0] directory of FPC contains a lot of stuff that come out of the box with the compiler and they often have an "examples" and/or "tests" directory with code you can check. There is some documentation[1] but sadly FCL is really not that well documented - you just have to check the sources for most things.
Note that this is for Free Pascal itself. Lazarus builds on it (LCL, the "Lazarus Component Library", is built on top of FCL) and adds a bunch of additional components of its own. Though usually for non-GUI stuff you just use the Free Pascal classes, Lazarus has some of its own "wrappers" that integrate with the IDE and the form/object designer. The "weblaz" package (it comes with Lazarus but you need to install it manually from Package -> Install/Uninstall Packages) provides a bunch of components for working with the web (mainly for making web apps), including the "TFPHttpClient" component which can be used to make HTTP requests. As a simple example, if you throw a TMemo (multiline text editor) control in a form, throw a TFPHttpClient component and then doubleclick on the form to edit the code to execute during the form's creation you can type "Memo1.Text:=FPHTTPClient1.Get('https://news.ycombinator.com/');" and it will put the HTML code for this forum in the memo (note that you may also need to add the opensslsockets unit in the uses section at the top of the code). Of course that is a very simple example but if you browse the properties and events of the component in the object inspector as well as the available methods by typing "FPHTTPClient1." and pressing ctrl+space in the code editor you can find most of the other functionality the component provides.
For Delphi it is a combo of the Indy project (IdHttp), and superobject (probably other json parsers too but superobject is quick and fairly solid).
However, given I've yet to find Delphi code that straight up compiles in Lazarus/FreePascal, you probably have your work cut out for you, but if you google for [superobject/indy] for Lazarus, others have started those hikes, and you may find there are working versions of one, or possibly both of them. I've never looked.
The one negative I've found with Lazarus... And this is purely if you were someone coming from a Delphi background, or were planning on Lazarus being your "get out of jail free" card if [Embarcadero/(whoever owns it now)] decides to stop updating Delphi (and even then you could probably manage it's lack of updates for years, hell I stayed on Delphi 2007 for a good 8 or 9 years after XE, XE1, XE2 et al had been out).. Anyways, back to my point, the one major negative I've found with Lazarus is you simply can not take Delphi code, and compile it straight in Lazarus... There are many many many very subtle differences. Totally fine and understandable, but if you were planning on taking the attitude of "Stuff Delphi, lets take our 400k line project and move to Lazarus", you are going to have a bad time.
Having said that I've done a couple of my own projects at home in Lazarus. It's fine, it feels dated, going back to the original Delphi / VB style of RAD tool with form designer/code editor as floating windows etc. The intellisense leaves something to be desired, but I can't be too critical because it's not like I'm putting my hand up to contribute to the project. If you look at what you get for what you pay for, it's quite literally amazing.
> It's fine, it feels dated, going back to the original Delphi / VB style of RAD tool with form designer/code editor as floating windows etc.
Note that if you install the "anchordockingdsgn" and the "dockedformeditor" packages you will get a UI that uses a single toplevel window with all the previously floating windows being docked inside it (you can still un-dock them) and a form editor that is inside the window (without the "dockedformeditor" you can still get the single window for the IDE but form editing will happen in floating forms).
Personally i prefer the floating windows UI as i overlap windows a lot (and i'm used to it - also i have a dedicated virtual desktop for coding which helps), but there are enough people who prefer a single window UI that this should work without issues these days (it used to be somewhat very unpolished at the past, like installing the package and having a shotgun blast in the IDE panels :-P so you'd spend a few minutes moving and resizing the panels in sane places).
Hi everyone I operate an irc channel to assist pascal/Delphi programmers with developing projects.
https://libera.chat/guides/ IRC.LIBERA.CHAT Ports [6667 plaintext ] or [6697 secure] channels #fpc #pascal.
It is not necessary to create an account to participate.
We have a fair bit of code in production that was written over 20 years ago. It just works. It has gone through strings switching from 8-bit to Unicode (16-bit) with hardly any modification.
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.
First they deprecated the bundled DB bindings, after hyping them to hell and back; then the bundled report generator. We had more than a million lines of code depending heavily on those.
Proprietary, with almost full sources to the standard library, however. There is indeed a bunch of half-assed stuff, but that's easy to ignore. In general, Delphi moves slowly and hardly ever breaks backward compatibility. Only the transition to Unicode in D2009—oddly not mentioned in the article, along with generics—was a little rough. Apart from that, decades old code keeps compiling/running without issue. It's mostly third party components needing updates sometimes, especially if they're shipped as compiled units or integrate with the IDE.
Mate I've got a project whose first lines of code were struck back in the 80s in Turbo pascal. Your "continuously deprecated" argument doesn't hold a lot of water from where I sit... In terms of actual language features/changes that have caused deprecated status, those are very few and far between. Maybe some VCL database controls, for sure it would have sucked to have built stuff relying on interbase, but that is not a language/compiler feature, that was CodeGear EOL that particular project (I had to manage the exit strategy on one of our projects where it relied on that crapware)
Even library developers are pretty good at pumping out versions of their libs that have support for even Delphi 5. I know of at least 2 people who are still doing windows dev on Delphi 5 or maybe 7, I can't recall.. the very definition of "from my cold dead fingers".
Suffice to say if you were one of those real hold-outs, not updating to the latest.. you wouldn't have generics, dynamic arrays, lambdas/anonymous functions, and you would probably struggle to grab much code written in the last decade and compile it straight up.. but that would probably be the case for a number of languages that have had core features added to them over time.
The fact that the system is proprietary certainly is an issue, but every install always ships with all the source code of the RTL, VCL, and clear instructions on how to compile it with a "you're on your own now" sense of adventure.
How is it possible that one man was responsible for the creation of Turbo Pascal, Delphi, C#, and TypeScript? [1] I don't look up to many people, but here's one.
He didn't spend all his time shitposting BBS/Newsgroups/Slashdot/HN while pretending he knew the one simple trick to obviate global political and economic turmoils?
Perhaps unknown to the HN community is that C# periodically gets Delphi features reintroduced in it in one way or another.
More recently, C# 9 and 10 have returned the concept of `records` (preferably immutable objects) along with the `with` keyword for making copies with some of the properties changed from the source to the dest object.
It has been an interesting decade watching HN metaphorically (and sometimes literally i'm sure) shift around uncomfortable in their chair as the all-encompassing-nightmare M$FT creates two languages that are more and more dominating of developer marketshare - C# and TypeScript.
C# and TypeScript have both been pretty open (in nature and source) for roughly a decade. Which I appreciate. Although, I'm somewhat apprehensive about some of MS's moves with the .Net community, and their holding back on quality of life improvements for C# projects in VS Code.
Although, MS hasn't caused me to generally avoid .Net so much as the more "enterprise" nature of most of the projects I've had experience with. I started with .Net (C#) in 2001, and to this day think there is a lot to like there. Of course these days, I'd appreciate the opportunity to work with Rust more than C#.
Well, to throw extra praise it ran GUI faster on the triple digit single core CPUs than near-any current JS abominations on quad digit multicore CPUs do nowadays...
I keep saying this every time Delphi is mentioned, but it definitely deserves the praises:
Borland Delphi had the best and the most useful documentation/help system that I ever used - and those were times before Google or even access to Internet for many of us, so reading manuals played a huge role in learning.
I remember my Delphi manuals being quite grimy. They were always on hand and I could find something very quickly. It enabled me to get stuff done without any outside help. Windows help files were also good.
In the early days of Delphi I considered it to be a huge competitive advantage in terms of productivity and speed against everything out there. As time went on, though, it slowly died, and it became increasingly difficult to find and integrate 3rd party libraries, or find developers to work in the system. The user interface aspects of it also became dated and difficult to make modern.
Too bad, as I really liked it, especially the language. I liked the AMIGA as well, which also was ahead of its time and seemed to suffer a similar fate.
It's an interesting issue, personally I wouldn't look at someones employment history, and working with legacy tools/environments, as a black mark, but it could be indicative of someone who simply refuses to move to new technology.
I've also hired some younger people who were actually interested in picking it up because they were keen to learn anything they could, and you can learn plenty from Delphi despite it's warts.
Over time I've described myself as suffering a kind Stockholm Syndrome w/ Delphi now, and some of the guys on my team have flat out refused to learn it for maintaining some of our systems.
Having started with FORTRAN in 1970, then discovering the beauty of IF-THEN-ELSE in PL/I, then using ALGOL W in college, all made Pascal a natural successor for me out of school (first MacPascal on Macintosh then Delphi on Windows). Still using Delphi 6 for projects to this day.
What was/is particularly nice about Delphi is the library of GUI objects, single .EXE output with no dependencies, and the ease with which arbitrary-length strings can be used.
I started my career using Delphi and was part of the local community. Two of us worked on support for Borland products at the local distributor - I went to do more development and he joined the local Borland sales team. I was often attending product launches, and presented a few times myself. I recall presenting creating ActiveX controls in Deplhi, using a plugin, in front of an applauding crowd, probably about 2 years before VB could do the same.
Data binding to client-server databases was a big deal at the time, and data-bound controls such as grids and TreeViews (which we all thought were the future) were pretty cool. It was an exciting and productive time to build data-based (enterprisey) apps that customers and users loved.
I remember when Borland launched C++ Builder, which was C++ using the Delphi component library (VCL) and IDE. Everyone was very excited during the demo until build and run (F9?) when compiling started and in the demo, in front of a couple of hundred people, my friend had to talk for a couple of minutes until the app ran - something that would have taken seconds in Delphi.
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 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 was OK, but I was 15.
Delphi 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.
> 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
C++20 Modules, .NET Assemblies, D modules, Ada packages, and plenty of other othes.
Also, Turbo Pascal did indeed allow for circular dependencies between units, as long as the related uses statements were written in the implementation section of the unit, and there were no public dependencies.
Thanks to bitsavers, Turbo Pascal 5 manual, page 97,
Yeah, this... You can have circular dependencies, as long as it is in the implementation only. Takes some thought on interface definitions to avoid these things. Sometimes it's a real pain.
There's also the issue that when you split out units, and then you have a user who wants to consume say, a library you've written, you then have to document "Ok, to use this you have to use X, Y, and Z units for type definitions"
A better approach is to have a single "entry point" unit if you will, that simply re-declares all of the types from the X,Y,Z units, so that when you go to use the code you've written, you only have to import W, and get all the type defs already. (Hard to explain what I'm talking about I guess)
IIRC, pre-Object Pascal Pascals had a "forward" declaration using which you could call a function or procedure before defining it, as long as it was defined somewhere below in the program. I don't remember if it supported circular dependencies or not.
Modules and assemblies are different. Lots of languages ban circular dependencies between modules (most!). Delphi units were single source files though, and that's a much more painful proposition because it forcibly links source file size and program architecture. I saw a lot of big unit files in Delphi code bases.
Arriving at a place with a Delphi codebase developped over the course of 30 years (some files had 80ies copyrights), the tendency tot have enormously long ones was apparent. 10k lines would be short, and 100k nothing unusual. Really hard tot navigatie, the Delphi IDE doesn't really help with that (or much else really).
Apparently no one read the part about dependencies being allowed between implementations section, and I imagine also never looked into Delphi packages, in regards to code size and organising units.
>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
Yes, and I usually find when I run into this that I should be doing something differently in our package/interface design. I think it's overall very helpful though also annoying to detangle if you the cycle is deep enough.
indeed it does; i've run into it a few times. just last week i was writing some go code in vscode and it wasn't working because i had a circular dependency. vscode was reporting something in the "problems" window like a "go list" failure due to "no go files". i couldn't make head or tail of it for a few minutes. it took me some time to note that the path listed in the issue was one i had just edited. in fact, i didn't even notice the path at first -- i tried running `go list` from my repo root and didn't see the error, but when i saw the path and changed to that dir and tried again, i saw the `go list` error as reported by vscode, and i think that when i opened the file i had just edited in vscode it displayed a more understandable cyclic import message in the offending import, and it was easy to go from there.
I was just thinking how the ideas behind Turbo/Borland Pascal and Delphi reminded me of Go, I know it should've been Dotnet, but Dotnet got complicated right from the start with it's deployment model (lots of dlls, assemblies, blah, blah blah).
> 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.
I think the UX was fine as it was made to work with KDE1/Qt1 which was very Windows-like (in appearance and behavior) at the time, but the real issue was that instead of trying to make VCL work crossplatform (like Lazarus' LCL does) they made a different framework (IIRC it was called CLX) which used Qt1 and was very incompatible.
They released a free version with the limitation that your program had to be GPL, though at the time it was fine as GPL wasn't the boogieman it is today. Sometimes i wonder if Borland had released the entirety of Kylix under GPL and thus gained mindshare among open source programmers at a time when Linux had started becoming more popular among programmers if things would be different for Delphi - if nothing else it wouldn't be seen as some ultra-expensive tool that people only use because they have no way to move away from. At the time Borland made money from enterprises (which would buy the expensive enterprise version anyway) and proprietary desktop software developers (which wouldn't use the GPL version anyway) so having Delphi as a GPL'd program wouldn't affect them much but instead have the tool's mindshare expand and even have developers help Borland fix bugs with their framework and improve their compiler.
I was thinking that a couple of years ago when i tried the free version of Kylix under my Linux installation and it failed to work with all sorts of errors despite my efforts - but errors that should be simple to fix if the source code was available. Then i tried it in a VM running some Linux version from the early 2000s and it worked, which made me think how nice it'd be if it was a GPL'd software i could modify.
After that nostalgia session, i deleted the VM, downloaded the latest version of Lazarus and fixed the Gtk1 support[0] because i could as that is open source (ok ignore the broken images, that is because the shot is from a few months ago when i tried to remove the gdk_pixbuf dependency, normally they look fine but that is the only screenshot i had around :-P). FWIW the fixes were merged in (and i made some extra fixes since then).
> Sure, if you're an architecture god who plans out all their internal interfaces in advance on paper it was OK, but I was 15.
Us Architecture Gods don’t need planning. The internal interfaces have been immaculately conceived in our mental space. It’s the regular peasantry of architecture that need to do the planning.
I get a bit of nostalgia when coding in Typescript, Kotlin, Swift.
It is a sweet revenge that most modern languages, have decided to go with the Pascal influenced approach (yes some ML as well), even most of the C++ wannabe replacements (with exception of Circle).
If RAD Studio/C++ Builder allowed building Linux desktop apps, I would have likely bought the architect edition. VCL is so much faster to develop than any other framework.
As someone that grew up on C, I always found Pascal positively brutalist with its BEGIN and END blocks, instead of using the more nimble braces.
These days I recognise the immense potential it had, and lament the fact that I never had the chance to learn it properly. My path was Borland Turbo C++, VB6, VC++6 then I moved to the Linux world.
The BEGINs were replace by THEN (for IFs) and DO (for WHILEs and FORs). They still need something to denote the ENDs. Instead of saying "THEN BEGIN" or "DO BEGIN", you can drop the BEGIN and just assume it's there.
I was introduced to Pascal’s Turtle Graphics back in the 90’s. I thought it was cool but never had a real use for it; x,y seemed easier for some reason. I started drawing SVG’s for a laser engraver and suddenly I wish other languages had them. I even started to write my own but I don’t know the math (even though I hear it’s relatively simple). I may get back to that but I figured out that simple scaling gets me there by reducing the cognitive load of pixels.
I don’t know if this makes sense but I was feeling nostalgic for turtle graphics.
Also a great teaching language, as used at London Imperial College Electrical and Electronic Engineering dept. in the early 00s. Gave you lots of power but not too much, and enough rules to force you to learn without doing mad things. I have fond memories. And I miss the compilation speeds!
I started using Delphi back in the early 90s because I needed to send a "catalogue on a floppy" to customers of my parents.
At the time I'd used VB but the runtime was the size of a floppy on its own, and the catalogue data pushed it over the size. I remember reading that Delphi didn't require a runtime and that was that.
I still use Delphi for LOB apps - so very quick to design a user interface and have a working program ready to roll out, for example so transport can update their haulier quickly, or the accounting software has a shoddy smtp implementation that doesn't play well with our spam appliance so we create a tool that fires statements via mapi and let outlook deal with retries.
It is still quite used in many European countries, I know of German and Belgian companies, and there are enough companies to keep an yearly conference going, and regular sessions on BASTA! conference in Germany.
I worked with Delphi in the beginning of my career, and the only thing I find myself really missing is the runtime type information! It worked really well and sometimes I find myself missing it in other compiled languages.
But I heavily disagree with the author's positivity about Delphi in general.
The UI builder excels on wiring up small utilities, but when you are looking to build applications with more complex UIs, with custom components and/or devices with different screens, the complexity increases exponentially and the UI preview becomes just a small suggestion, I think only in the last release (10.5) in 2022 they addressed this.
The component system is clunky, and very prone to breaking. In my entire time working with it I never once had a completely functional development environment, because components installation never had the same result. To work in some parts of the project i had to just ignore the IDE and edit the text files directly.
Also, Delphi updates required reinstalling everything, and solving the many problems that would arise, and then all dev environments would have to be reconfigured (and troubleshooted) manually.
Talking about editing, the IDE's performance is not very good, and the Intellisense is not asynchronous, the suggestions and error checking took their time to load, and the IDE becomes unresponsive while it processes, and sometimes windows would just kill the application because it was not responding. I had to turn it all off to be able to work. Oh.. And the bugs, the IDE had bugs just everywhere!
The above exposes a problem in the language itself, it did not have good asynchronous behavior, and I never understood it completely, the only way to make sure you would not block the main thread in some way was to spawn a new process to run background stuff.
The standard components are outdated, the WebView they used was Internet Explorer's one until the 10.4 release, in 2021, they just recently started to adopt WinUI, so you were stuck with 00's user experience, their JSON parser was not very standard (it didn't support the number type, for instance). And when I searched community components to implement things I usually found only something very outdated and unmaintained, or just didn't find anything.
I think essentially it had some quite good ideas in the beginning, but this is the important fact, it "had". Delphi stopped improving on itself, and is just trying to convince the same community of people who fell in love with it when it was still good and dedicated their entire careers to it that they are cool now, adding things that sound cool, while nothing important really improves.
Nitpick, but the title SHOULD be 'I come to bury Delphi, not to praise it'
The whole point of Mark Antony's speech is that he was, in fact, praising Caesar, despite the line stating otherwise. Flipping it around removes the entire impact of the speech.
