Delphi 11 Alexandria(blog.marcocantu.com)
blog.marcocantu.com
Delphi 11 Alexandria
https://blog.marcocantu.com/blog/2021-september-delphi-11-released.html
120 comments
The company has quite a different focus than Borland of old, which tried to get their products in as many hands as possible. Many a programmer was weaned on a cheap copy of Turbo Pascal or Turbo-C.
Idera, on the other hand, caters to enterprises. I haven't had a deep look at Delphi in recent years, but if it's the same as ExtJs now (another company bought up by them), I don't see it as a viable option, compared to C# for most small business developers who still need to make UI apps (and on the pure hobbyist end, you've got Lazarus).
I leave the language complaints to the Rust brigade.
Idera, on the other hand, caters to enterprises. I haven't had a deep look at Delphi in recent years, but if it's the same as ExtJs now (another company bought up by them), I don't see it as a viable option, compared to C# for most small business developers who still need to make UI apps (and on the pure hobbyist end, you've got Lazarus).
I leave the language complaints to the Rust brigade.
Funny you left the complaints to the brigade. I actually found in Rust what I had been missing from Pascal since my Delphi years: a sane, structured system programming language.
Having a Delphi equivalent for Rust would be a dream. The build times are never going to match Pascal's single pass compiler, though.
Having a Delphi equivalent for Rust would be a dream. The build times are never going to match Pascal's single pass compiler, though.
Ask HN: Why Did Pascal Fail?
https://news.ycombinator.com/item?id=28490736
2021-09-11 73 points | 163 comments
https://news.ycombinator.com/item?id=28490736
2021-09-11 73 points | 163 comments
Unfair competition from Microsoft, that's it.
Top reply on that thread is correct. The brains behind Turbo Pascal took a job at Microsoft and developed .NET and C#. Game over.
As much as I hate Microsoft, I'm not sure that's entirely fair. Borland held the Pascal crown with Turbo Pascal. They introduced Turbo C, but IIRC it never really had the success of Turbo Pascal. Borland was known as the Pascal company, not the C company.
Meanwhile, Microsoft C, the big version, was what everyone used to develop Windows programs in C. It was on the expensive side, like a few hundred bucks I think.
Microsoft came out with Quick Pascal and Quick C, to complement their very-successful QuickBasic product. Quick C was more successful than Borland's Turbo C because Quick C was a hobbyist version of Microsoft C for $99. Microsoft was the C company, Borland was the Pascal company. And C won that argument, not Pascal.
Now it could be said that Microsoft had an advantage because it was easier for them to make Quick C compatible with Microsoft C than it was for Borland to make Turbo C exactly compatible with Microsoft C, especially when all Microsoft had to do was change their C features all the time to keep Borland always playing catch-up.
Meanwhile, Microsoft C, the big version, was what everyone used to develop Windows programs in C. It was on the expensive side, like a few hundred bucks I think.
Microsoft came out with Quick Pascal and Quick C, to complement their very-successful QuickBasic product. Quick C was more successful than Borland's Turbo C because Quick C was a hobbyist version of Microsoft C for $99. Microsoft was the C company, Borland was the Pascal company. And C won that argument, not Pascal.
Now it could be said that Microsoft had an advantage because it was easier for them to make Quick C compatible with Microsoft C than it was for Borland to make Turbo C exactly compatible with Microsoft C, especially when all Microsoft had to do was change their C features all the time to keep Borland always playing catch-up.
What MS did to Borland was exactly what they did with Netscape 10 years later: use their dominance of the OS to displace competitors in other areas. The only difference is that computing was a much smaller part of the economy at the time. Things changed with Netscape and other multi-billion dollar web companies, so the government decided to act.
The big difference to me is that with Netscape, Microsoft distributed a free Internet Explorer with Windows just when Netscape was trying to monetize their software. In the case of Borland, Microsoft wasn't distributing free C compilers to compete with Borland's paid compilers.
I think the government decided to act because in the case of the browser, they bundled it with Windows, for free, to kill a competitor. But I agree, having Windows on nearly every desktop in the world gives them a way to launch new products that no other software company enjoys, even to this day, except maybe Apple, Google, Amazon, and Facebook.
I think the government decided to act because in the case of the browser, they bundled it with Windows, for free, to kill a competitor. But I agree, having Windows on nearly every desktop in the world gives them a way to launch new products that no other software company enjoys, even to this day, except maybe Apple, Google, Amazon, and Facebook.
Borland was taken over by managers and did themselves in:
- bought DBase for WAY too much money when flat files DB were on the way out.
- spent lavishly on a new HQ in Mountain View
- renamed themselves to the pompous name of "Inprise"
- suddenly jacked up the price of all their packages so high that their natural user base started looking elsewhere, rather than trying to convince their boss to pay for licences.
...And then came the web, for which they had no product to sell.
Microsoft was only happy to help their downfall by poaching and copying.
- bought DBase for WAY too much money when flat files DB were on the way out.
- spent lavishly on a new HQ in Mountain View
- renamed themselves to the pompous name of "Inprise"
- suddenly jacked up the price of all their packages so high that their natural user base started looking elsewhere, rather than trying to convince their boss to pay for licences.
...And then came the web, for which they had no product to sell.
Microsoft was only happy to help their downfall by poaching and copying.
Delphi, as technology, is amazing. But the company controlling it operates on the model of locking-in existing customers and ratcheting up prices. It's a bad deal for everyone not already stuck in the ecosystem with things they need to maintain. Look up Lazarus for the open source I-can't-believe-it's-not-Delphi
Delphi was my first real programming environment circa 1998.
At least at the time it allowed me to build professionally looking applications with practically nil experience and with little effort.
At least at the time it allowed me to build professionally looking applications with practically nil experience and with little effort.
Well - once upon a time they WAS amazing.
But later they become CodeGear and later their R&D division is moved to Romania. Products become unstable and unreliable.
But later they become CodeGear and later their R&D division is moved to Romania. Products become unstable and unreliable.
They had flops, meh versions / releases and good ones stability wise. Just as any other major IDE (or product for that matter).
I own Delphi and still nothing beats it productivity wise for desktop applications. I successfully used Lazarus as well to develop Raspberry Pi based GUI software that controls various electronic gizmos(debugging on Pi was unstable but I've managed).
For products that do not have GUI (or using browser for front end) I stick to C++.
Embarcadero's pricing / marketing though does suck big time. Well, the only product that comes close to Delphi for GUI development is QT and their licensing and pricing sucks even more.
I own Delphi and still nothing beats it productivity wise for desktop applications. I successfully used Lazarus as well to develop Raspberry Pi based GUI software that controls various electronic gizmos(debugging on Pi was unstable but I've managed).
For products that do not have GUI (or using browser for front end) I stick to C++.
Embarcadero's pricing / marketing though does suck big time. Well, the only product that comes close to Delphi for GUI development is QT and their licensing and pricing sucks even more.
> their licensing and pricing sucks even more.
Does Delphi even have a LGPL option ? Because with Qt's LGPL you can use it in a lot of proprietary systems without having to pay for a license
Does Delphi even have a LGPL option ? Because with Qt's LGPL you can use it in a lot of proprietary systems without having to pay for a license
Delphi does not have an LGPL option. Lazarus, however, does.
I've already said elsewhere that having read their licensing terms and limits on what parts and how it can be used I would not touch QT with the wooden pole. Not interested in discussing those either. Others might disagree but hey each of us makes their own choices.
I heard Delphi has free version. I did not go into detail as I own commercial version and keep it up to date. But from what I understand you can use their community edition for free as long as you do not make more than $5000 per year.
I heard Delphi has free version. I did not go into detail as I own commercial version and keep it up to date. But from what I understand you can use their community edition for free as long as you do not make more than $5000 per year.
> I've already said elsewhere that having read their licensing terms and limits on what parts and how it can be used I would not touch QT with the wooden pole.
the OSS licensing terms are the LGPL or GPL.
- https://github.com/qt/qtbase/blob/dev/LICENSE.GPL3
- https://github.com/qt/qtbase/blob/dev/LICENSE.LGPLv3
- https://github.com/qt/qtdeclarative/blob/dev/LICENSE.GPL3
- https://github.com/qt/qtdeclarative/blob/dev/LICENSE.LGPLv3
they can add whatever separate licensing scheme they want in addition to that but if a repo has LICENSE.LGPLv3 in it, you can use it under LGPL like every other OSS project (and those two repos cover by far most of Qt, you can pretty much build an entire OS userspace out of them).
the OSS licensing terms are the LGPL or GPL.
- https://github.com/qt/qtbase/blob/dev/LICENSE.GPL3
- https://github.com/qt/qtbase/blob/dev/LICENSE.LGPLv3
- https://github.com/qt/qtdeclarative/blob/dev/LICENSE.GPL3
- https://github.com/qt/qtdeclarative/blob/dev/LICENSE.LGPLv3
they can add whatever separate licensing scheme they want in addition to that but if a repo has LICENSE.LGPLv3 in it, you can use it under LGPL like every other OSS project (and those two repos cover by far most of Qt, you can pretty much build an entire OS userspace out of them).
Are they still extending the language? I remember that working with strings was somewhat frustrating, for example RegExes were not a thing without external libraries...
>"Are they still extending the language"
Yes they are. I do find it strange though to base language acceptance criteria on regex when there are tons of libs. But yes Delphi has its own as well
Yes they are. I do find it strange though to base language acceptance criteria on regex when there are tons of libs. But yes Delphi has its own as well
> Are they still extending the language?
https://news.ycombinator.com/item?id=22328219
https://news.ycombinator.com/item?id=22328219
[deleted]
I wonder if The Qt Company is looking at them for inspiration the past couple of years...
Maybe that’s the only viable business model.
You can see the same pricing scheme with all of these "batteries included" niche products, from Xojo to LispWorks. It looks like the sweetspot is around $1,500/year, sometimes lower, sometimes higher.
I still think they are wrong, though, and these companies would make way more money if they'd cater to the masses at a price range of $30 to $100 per major version (depending on the version/features). In the VST plugin market, price ranges were comparably high until companies figured out that the mass of hobby musicians is more lucrative. Now products are basically on eternal sale, prices reduced from 50% to 95%.
In the VST market increased competition forced companies to lower prices during sales. Maybe the lack of competition prevents the same from happening to IDE companies.
I still think they are wrong, though, and these companies would make way more money if they'd cater to the masses at a price range of $30 to $100 per major version (depending on the version/features). In the VST plugin market, price ranges were comparably high until companies figured out that the mass of hobby musicians is more lucrative. Now products are basically on eternal sale, prices reduced from 50% to 95%.
In the VST market increased competition forced companies to lower prices during sales. Maybe the lack of competition prevents the same from happening to IDE companies.
I think you have a point. They should adopt a pricing strategy similar to Jetbrains where they have a non-transferable cheap individual license that can be used commercially, and a more expensive version for enterprise.
I believe many React Native, Electron and other hybrid solutions are made by people like me, who don't want to spend huge amounts of money to test an unknown piece of tech. These people also make recommendations to the companies they work for, which would actually afford to buy these licenses.
Why not think of a "discount" as part of the marketing budget? How much money do they spend on marketing and sales to get new customers? They will get new developers who will improve the branding and gain new "leads" organically.
I believe many React Native, Electron and other hybrid solutions are made by people like me, who don't want to spend huge amounts of money to test an unknown piece of tech. These people also make recommendations to the companies they work for, which would actually afford to buy these licenses.
Why not think of a "discount" as part of the marketing budget? How much money do they spend on marketing and sales to get new customers? They will get new developers who will improve the branding and gain new "leads" organically.
If they lowered the price they would likely sell a boatload of licenses, because the RAD even 10 years ago was already more advanced than anything existing now.
The problem might be that they can't or don't want to set up an infrastructure to offer support to that many developers and companies using it, so they rather squeeze as much money as they can to the few companies buying it because they're forced to in order to maintain older projects.
It's a sad reality in which new programmers are discouraged to try a product that is likely better than anything else.
What you are describing _was_ the borland model back in early 1990s. But then they flipped to this high price model in the late 1990s when they changed their name to Inprise.
Borland was awesome, with Turbo Pascal, Borland Pascal, Borland C++ and later Delphi they ran circles around their competitors, Microsoft included. It is incredible how they have disappeared from the scene completely.
Yep.
Things like Matlab and Mathematica end up in the $2k to $3k for commercial business, but just a few hundred for hobbyists.
I've been playing with a batteries included (like kitchen sink, but still tiny) Forth language (pretty rare as most Forths are focused on embedded) called 8th that is dirt cheap for a professional edition. I think it has a good price model as it is exactly what I'd be comfortable paying for something niche.
Things like Matlab and Mathematica end up in the $2k to $3k for commercial business, but just a few hundred for hobbyists.
I've been playing with a batteries included (like kitchen sink, but still tiny) Forth language (pretty rare as most Forths are focused on embedded) called 8th that is dirt cheap for a professional edition. I think it has a good price model as it is exactly what I'd be comfortable paying for something niche.
I am not sure that this is fair to LispWorks. I think that I initially paid $3000 for a license and the yearly maintenance fee is about $500. Their support is amazingly good and CAPI is good for UI development.
Still, this is just out of range for most non-professionals. Several times I have considered to buy a LispWorks license for personal usage, but couldn't quite justify the costs.
I am pretty sure they might even sell more professional licenses if they had a wider userbase of enthusiast users.
I am pretty sure they might even sell more professional licenses if they had a wider userbase of enthusiast users.
For anyone curious, a hobbyist license for LispWorks is $500 for a 32-bit version that works on a single operating system, then $250 every year after that. If you actually want to release software other people can use, then it's $1000 and $500 every year after that. If you want to sell software other people can use, double that. Want the ability to use a database? Double it again! Oh, and if you want to release anything but 32-bit software? Double that, too.
All of this is per-seat, too.
It's really "Our company and or university gives us enough money to blow on software that we don't have to look at the prices"-oriented pricing.
LispWorks is amazing software from a development standpoint (though SBCL is significantly faster if you're actually using what you write), but it's also one of the best examples of predatory proprietary software.
All of this is per-seat, too.
It's really "Our company and or university gives us enough money to blow on software that we don't have to look at the prices"-oriented pricing.
LispWorks is amazing software from a development standpoint (though SBCL is significantly faster if you're actually using what you write), but it's also one of the best examples of predatory proprietary software.
> one of the best examples of predatory proprietary software.
Your conclusion is completely wrong. From what I see, LispWorks is making just barely the minimum to make their operation work. I wouldn't classify this as predatory. They're just trying to make enough money to survive on an environment where very few people are willing to pay for software. From what I see, most people using Lisp are hobbyists, and they already use open source products. To survive, LispWorks had to search for companies that wanted/need to pay for a supported version of Lisp.
Now, Microsoft using proprietary software to lock customers, that is predatory.
Your conclusion is completely wrong. From what I see, LispWorks is making just barely the minimum to make their operation work. I wouldn't classify this as predatory. They're just trying to make enough money to survive on an environment where very few people are willing to pay for software. From what I see, most people using Lisp are hobbyists, and they already use open source products. To survive, LispWorks had to search for companies that wanted/need to pay for a supported version of Lisp.
Now, Microsoft using proprietary software to lock customers, that is predatory.
I don't think the license prices for professionals are too high, but I think there should be affordable license options for non-commercial uses. This could not only generate additional direct revenue but also might increase the number of professional users from enthusiasts who turn professional.
That could be right, but I imagine they already tried that and it didn't work.
I am pretty sure they don't. I was interested in LispWorks since the late 90ies. I downloaded and used a bit the free edition, but that was too limited even for hobby usage. The personal edition was a bit cheaper then, I almost bought it. I would assume, if they had offered something in between, I would have noticed.
LispWorks exists since 1987. Originally developed by Harlequin, a software tools and software applications (Postscript, Lisp, ML, Dylan, ...) company. After Harlequin closed its doors, Globalgraphics bought the remaining assets and employed some staff. They spawned a company. This spawned the current LispWorks company which is a relatively small company dedicated to only the Lisp product.
Initially LispWorks *only* addressed the professional and academic market (for UNIX systems) with the professional edition, enterprise edition, site licenses and special implementations (like the one on NASA's Deep Space One). Over time it got ported to Windows, Mac, Linux, Android, iOS.
A bunch of years ago they have introduced two versions of 'Hobbyist' editions: with delivery and without. This is still expensive, but in reach for dedicated hobbyists (my hobby camera costs like five times of a Hobbyist license).
Meanwhile, mostly only LispWorks and Franz Inc survived in the commercial market for Common Lisp, while all cheaper Lisp offerings (from companies like Expertelligence, Procycon, Corman, Gold Hill, Apple, ... etc.) haven't survived as a commercial and maintained product.
Competitors in similar or more expensive price ranges also went away (Lucid, Symbolics, TI, Xerox, LMI, Ibuki, ...).
Franz and LispWorks must have done something right -> they are still there and publish new releases, while all the other companies (in various price ranges and various target markets) had to give up.
Initially LispWorks *only* addressed the professional and academic market (for UNIX systems) with the professional edition, enterprise edition, site licenses and special implementations (like the one on NASA's Deep Space One). Over time it got ported to Windows, Mac, Linux, Android, iOS.
A bunch of years ago they have introduced two versions of 'Hobbyist' editions: with delivery and without. This is still expensive, but in reach for dedicated hobbyists (my hobby camera costs like five times of a Hobbyist license).
Meanwhile, mostly only LispWorks and Franz Inc survived in the commercial market for Common Lisp, while all cheaper Lisp offerings (from companies like Expertelligence, Procycon, Corman, Gold Hill, Apple, ... etc.) haven't survived as a commercial and maintained product.
Competitors in similar or more expensive price ranges also went away (Lucid, Symbolics, TI, Xerox, LMI, Ibuki, ...).
Franz and LispWorks must have done something right -> they are still there and publish new releases, while all the other companies (in various price ranges and various target markets) had to give up.
I have a fairly large CAPI (UI) example in my Common Lisp book and it runs OK on the free LispWorks edition. The free edition of LispWorks is memory and session time limited, but these limits allow many use cases. The message list for LispWorks contains comments that make me believe that many people use the free edition.
They have a license for hobby users that costs $500 (and $750 for 64 bits). It is not cheap, but it is within reach for people who really want it.
> "predatory proprietary software"
In reality it is a company with a handful of employees in a very small niche market.
In reality it is a company with a handful of employees in a very small niche market.
In my opinion, Jetbrains has the better model.
After all, what happened to JBuilder? Nobody is using it anymore, Codegear/Embarcadero priced themselves out of the competition.
Eclipse was free, Netbeans was free, JDeveloper was free, IntelliJ could be had for around 500 bucks and asking price for JBuilder was 4000 or more.
Jetbrains proved that you can successfully can compete against free. But the pricing needs to be reasonable.
Jetbrains proved that you can successfully can compete against free. But the pricing needs to be reasonable.
Jetbrains seem to be able to compete because they are building for the mass market. JBuilder is an exception. Delphi is a niche product still strongest for fast desktop app development which has a small market compared Rider (C#), PyCharm (Python), IntelliJ (Java), etc. which are all much larger markets.
The pricing was intentional which is different from saying someone "priced themselves out of a market" (which I take to be an unintentional act). They (wrongly) intentionally targeted both an enterprise and niche desktop development segment of the market who are not building mass market apps and could never escape from there because the value of Delphi diminished when Java, and especially C# became mainstream in the early 2000s.
This mistake has more complexity to it when you understand what what going on around Borland and the market in the late 90s. If you are looking at it now, then it just seems like an obvious unforced error.
The pricing was intentional which is different from saying someone "priced themselves out of a market" (which I take to be an unintentional act). They (wrongly) intentionally targeted both an enterprise and niche desktop development segment of the market who are not building mass market apps and could never escape from there because the value of Delphi diminished when Java, and especially C# became mainstream in the early 2000s.
This mistake has more complexity to it when you understand what what going on around Borland and the market in the late 90s. If you are looking at it now, then it just seems like an obvious unforced error.
I currently work with a licensed C++ Builder, which uses Delphi libraries.
Because of lackluster examples of C++ code, I have to look through Delphi code several times a day on the internet and when I'm debugging.
Because of lackluster examples of C++ code, I have to look through Delphi code several times a day on the internet and when I'm debugging.
I guess when you use RAD Studio, it's probably better to go "all in" and use the Delphi language too. I tried C++ Builder once while I was working with Delphi, hoping it will be faster than Visual C++. Little did I know that the slow compile times are "baked in" into C/C++ family languages in ways that are hard to get around, so I was disappointed and went right back to Delphi. The Delphi language is (conceptually, not syntactically) not that different from other classical OO languages like C++ or Java, although it (thankfully in my opinion) doesn't have as many bells and whistles. But of course if you have lots of legacy code in C++ Builder, switching is probably not an option...
I don't really work with any legacy code, because I'm a new hire and build bespoke applications for customers as a one-man-team.
The company I work for has been using Borland since mid-90s, but now I wonder how I should break it to the company that I want to switch to Java.
The company I work for has been using Borland since mid-90s, but now I wonder how I should break it to the company that I want to switch to Java.
You might miss the Delphi's AOT compilation though.
There are ways to get it in Java, but other than Graal, they cost just as much.
There are ways to get it in Java, but other than Graal, they cost just as much.
> Apparently they support iOS,Android,Linux, Windows, MacOS including Apple M1
Last I checked two weeks ago there was no Linux support. I still don't see any mention of Linux support.
Last I checked two weeks ago there was no Linux support. I still don't see any mention of Linux support.
Delphi does support Linux: https://docwiki.embarcadero.com/RADStudio/Sydney/en/Linux_Ap...
It was initially aimed at server-side apps. Despite what the doc there says, you can also create UI apps through FMXLinux, an addon made available along with Delphi when you buy it.
It was initially aimed at server-side apps. Despite what the doc there says, you can also create UI apps through FMXLinux, an addon made available along with Delphi when you buy it.
It's there, but you need an enterprise license...
Sure, it still is a thing.
They can't keep on releasing new versions if nobody is using it :) I use it and stay up-to-date via their subscriptions.
Is it good? Well.. the old VCL stuff is pretty good, very stable, can do pretty much all you want. But that's Windows only.
The multi device framework (FMX aka firemonkey) is getting better, but does sometimes still lack in how mature it is. Normally however you can work around any issue you bump into.
So is it perfect? No, but I'm not aware of a tool that is perfect when you need cross platform development tools.
As far as cost goes (the main complaint I tend to see), it's not very cheap on initial purchase. But with the subscription you basically have a cost of about $500/year for the professional version. Not insurmountable if you consider that they actively work on improving the language and support.
They can't keep on releasing new versions if nobody is using it :) I use it and stay up-to-date via their subscriptions.
Is it good? Well.. the old VCL stuff is pretty good, very stable, can do pretty much all you want. But that's Windows only.
The multi device framework (FMX aka firemonkey) is getting better, but does sometimes still lack in how mature it is. Normally however you can work around any issue you bump into.
So is it perfect? No, but I'm not aware of a tool that is perfect when you need cross platform development tools.
As far as cost goes (the main complaint I tend to see), it's not very cheap on initial purchase. But with the subscription you basically have a cost of about $500/year for the professional version. Not insurmountable if you consider that they actively work on improving the language and support.
Delphi and other Embarcadero products are still a thing. In Brazil, Delphi was the number 1 platform for several years, and there are still companies maintaining products using this technology. It was cheap at the time (compared to MS offerings) and very easy to use. Given the large number of products released with this platform, I imagine they will be able to stay in the market for a long time.
We use Delphi to develop and maintain a large Windows desktop application.
For that I think it's still pretty darn good.
I recently made a new module for our program, with ~300 input fields including custom search inputs, several grids and multiple 3-layer deep details (head-detail-subdetail). I got the UI elements down in less than two days, and had the whole module ready for initial testing in a less than a month, UI to DB.
This included a lot of smarts, overview/selection views and other custom dialogs, as well as configurable UI defaults like tabstops, required fields, field colors and default values which vary based on current process (think invoice vs credit note).
So yeah, for that kinda stuff it's still pretty great I think. You might want to buy some components, but Delphi itself is expensive so that shouldn't be a huge issue.
For the other platforms I'm less sold.
I've tried FireMonkey, which is their cross-platform UI framework, and it was tedious and the code did not fill me with confidence (3D math library was mixing various concepts etc). They've had some years to work on it since then, maybe things have improved. But you're forever stuck with non-native on all platforms.
The key issue for me is that if you're planning on writing an application with an expected lifetime of 10+ years, like we are, I feel uncomfortable relying on a closed-source tool chain.
Delphi works today, but I don't know where it'll be in 5 years time. I can most likely get it to compile in a VM, worst case, but will it generate the code I need?
For that I think it's still pretty darn good.
I recently made a new module for our program, with ~300 input fields including custom search inputs, several grids and multiple 3-layer deep details (head-detail-subdetail). I got the UI elements down in less than two days, and had the whole module ready for initial testing in a less than a month, UI to DB.
This included a lot of smarts, overview/selection views and other custom dialogs, as well as configurable UI defaults like tabstops, required fields, field colors and default values which vary based on current process (think invoice vs credit note).
So yeah, for that kinda stuff it's still pretty great I think. You might want to buy some components, but Delphi itself is expensive so that shouldn't be a huge issue.
For the other platforms I'm less sold.
I've tried FireMonkey, which is their cross-platform UI framework, and it was tedious and the code did not fill me with confidence (3D math library was mixing various concepts etc). They've had some years to work on it since then, maybe things have improved. But you're forever stuck with non-native on all platforms.
The key issue for me is that if you're planning on writing an application with an expected lifetime of 10+ years, like we are, I feel uncomfortable relying on a closed-source tool chain.
Delphi works today, but I don't know where it'll be in 5 years time. I can most likely get it to compile in a VM, worst case, but will it generate the code I need?
20 years ago, when I was in college, I remember being super relieved that our Comp Sci course tutor wanted us to use Delphi/Pascal instead of VB.
At the beginning of the course, the tutor asked us all what other languages the class had experience with already. Being smug, I said I had used C++ and he then sarcastically announced to the rest of the class how they were all unworthy to be in my presence.
I really enjoyed Delphi. Those T prefixes still evoke nostalgia for Delphi 6 and 7, just before Borland went all-in on .NET and ruined the IDE.
Now that Qt is becoming more and more hostile, perhaps Delphi shouldn't be overlooked so easily for writing cross-platform desktop software... although it seems there's still no Linux support in the free edition.
At the beginning of the course, the tutor asked us all what other languages the class had experience with already. Being smug, I said I had used C++ and he then sarcastically announced to the rest of the class how they were all unworthy to be in my presence.
I really enjoyed Delphi. Those T prefixes still evoke nostalgia for Delphi 6 and 7, just before Borland went all-in on .NET and ruined the IDE.
Now that Qt is becoming more and more hostile, perhaps Delphi shouldn't be overlooked so easily for writing cross-platform desktop software... although it seems there's still no Linux support in the free edition.
There is Lazarus, which is an open source Delphi clone based on Free Pascal. Haven't tried it yet though. But the file manager I use daily (https://github.com/doublecmd/doublecmd) is written in it, and I have some ideas for improving it, so maybe I will try to compile that project for good old time's sake...
For anyone that's curious, popular game hacking/reverse engineering tool Cheat Engine(basically a fully fledged Windows debugger nowadays) is also made in Lazarus - though I can't seem to come up with anything else that is from the top of my head.
> just before Borland went all-in on .NET and ruined the IDE.
That was when it went off the rails and never recovered imho, others are mentioning Borlands business practices which were not the best at the time. Technically it lost direction as well, it never developed a response to Java, .Net and the web, and still doesn't, though you can actually develop web applications with Delphi to, with 3rd party components and they work very well.
That was when it went off the rails and never recovered imho, others are mentioning Borlands business practices which were not the best at the time. Technically it lost direction as well, it never developed a response to Java, .Net and the web, and still doesn't, though you can actually develop web applications with Delphi to, with 3rd party components and they work very well.
> Now that Qt is becoming more and more hostile
Can you please elaborate on that? I thought the free edition of Qt was open enough to be the right choice for writing fast multiplatform code. Did they change anything wrt licensing, or there are technical issues?
> although it seems there's still no Linux support in the free edition.
And the insane price tag of the other editions wouldn't help either. Anyway, Lazarus may be far from being the same thing feature-wise, still it's worth of consideration for Linux development. https://www.lazarus-ide.org/
Can you please elaborate on that? I thought the free edition of Qt was open enough to be the right choice for writing fast multiplatform code. Did they change anything wrt licensing, or there are technical issues?
> although it seems there's still no Linux support in the free edition.
And the insane price tag of the other editions wouldn't help either. Anyway, Lazarus may be far from being the same thing feature-wise, still it's worth of consideration for Linux development. https://www.lazarus-ide.org/
Qt's corporate owners have been openly hostile to the community for a while, and have been trying to get away with shady stuff. The license terms for commercial use are terrible, you need an active license to distribute existing software, not only develop new software, the prices are excessive and keep increasing, and once you get a commercial use license you have to keep it forever or you won't be able to distribute your existing work. Commercial license users are prohibited from contributing to the community version. They also made registration mandatory for all downloads, even of the GPL/LGPL licensed stuff, which information they use for Oracle-style license shakedowns. They keep delaying GPL/LGPL releases and have stated an intention to delay them by the maximum permitted amount (one year) meaning all community contributions are effectively blocked because contributors don't have access to the current codebase. While the contract with the Qt community does prevent the Qt Company from going completely closed, they're certainly not someone I'm comfortable with.
I can't add much to this really.
The Qt Company obviously don't think app developers using slightly old versions of their software provide any value to their shareholders, even though you're helping to grow the broader Qt ecosystem (libraries available, product awareness, knowledge sharing, growing the job market, etc).
As far as the Qt company are concerned if you're a FOSS app developer, and not on bleeding edge Qt 6 and actively contributing bug reports (i.e. acting as their outsourced QA), then you're just a worthless leech.
The feeling is the Qt library is only FOSS at this point because their hands are tied contractually by the KDE foundation.
This has lead the KDE foundation to create a surprisingly active fork of Qt 5.15:
https://invent.kde.org/qt/qt/qtbase/-/commits/kde/5.15
which is now the default Qt 5 base package on Arch Linux:
https://github.com/archlinux/svntogit-packages/blob/packages...
The Qt Company obviously don't think app developers using slightly old versions of their software provide any value to their shareholders, even though you're helping to grow the broader Qt ecosystem (libraries available, product awareness, knowledge sharing, growing the job market, etc).
As far as the Qt company are concerned if you're a FOSS app developer, and not on bleeding edge Qt 6 and actively contributing bug reports (i.e. acting as their outsourced QA), then you're just a worthless leech.
The feeling is the Qt library is only FOSS at this point because their hands are tied contractually by the KDE foundation.
This has lead the KDE foundation to create a surprisingly active fork of Qt 5.15:
https://invent.kde.org/qt/qt/qtbase/-/commits/kde/5.15
which is now the default Qt 5 base package on Arch Linux:
https://github.com/archlinux/svntogit-packages/blob/packages...
Isn't it the case that the KDE foundation can basically just yank away Qt for any reason they see fit? Seems like the Qt company would be playing a dangerous game there
No. Only if the Qt Company violates the terms of the agreement.
Right, seems like I misremembered this part:
>The foundation will control the rights to the Qt Free Edition and ensure that current and future releases of Qt will be available for free software development at all times. All changes to the Qt Free Edition license will have to be approved by the KDE Free Qt Foundation which will consist of two members of Troll Tech AS as well as two members of the KDE project. One of the representatives of the KDE project will have a double vote to be used in case of a tie.
so they have full control (majority of the votes) over approving license changes but I guess that doesn't mean they can enact them on their own
https://kde.org/community/whatiskde/kdefreeqt_announcement/
>The foundation will control the rights to the Qt Free Edition and ensure that current and future releases of Qt will be available for free software development at all times. All changes to the Qt Free Edition license will have to be approved by the KDE Free Qt Foundation which will consist of two members of Troll Tech AS as well as two members of the KDE project. One of the representatives of the KDE project will have a double vote to be used in case of a tie.
so they have full control (majority of the votes) over approving license changes but I guess that doesn't mean they can enact them on their own
https://kde.org/community/whatiskde/kdefreeqt_announcement/
> They keep delaying GPL/LGPL releases and have stated an intention to delay them by the maximum permitted amount (one year) meaning all community contributions are effectively blocked because contributors don't have access to the current codebase
Qt 6.0 was released for both commercial and LGPL at the very same time.
> https://www.qt.io/blog/qt-6.0-released
Same for Qt 6.1
> https://www.qt.io/blog/qt-6.1-released
Same for the upcoming 6.2
> https://www.qt.io/blog/qt-6.2-beta-released
so that's very much FUD.
Sure, there's the LTS thing where some point releases past a given .z are kept private, but who actually uses that in the open-source world ? Even LTS distros that use LTS versions of Qt never upgrade their point releases:
* Ubuntu 18.04 is on Qt 5.9.5 while the latest point release of the 5.9 LTS branch is 5.9.9: https://packages.ubuntu.com/bionic/qt5-default
* Ubuntu 20.04 is on Qt 5.12.8 while the latest point release of the 5.12 LTS branch is 5.12.11 https://packages.ubuntu.com/focal/qt5-default
Qt 6.0 was released for both commercial and LGPL at the very same time.
> https://www.qt.io/blog/qt-6.0-released
Same for Qt 6.1
> https://www.qt.io/blog/qt-6.1-released
Same for the upcoming 6.2
> https://www.qt.io/blog/qt-6.2-beta-released
so that's very much FUD.
Sure, there's the LTS thing where some point releases past a given .z are kept private, but who actually uses that in the open-source world ? Even LTS distros that use LTS versions of Qt never upgrade their point releases:
* Ubuntu 18.04 is on Qt 5.9.5 while the latest point release of the 5.9 LTS branch is 5.9.9: https://packages.ubuntu.com/bionic/qt5-default
* Ubuntu 20.04 is on Qt 5.12.8 while the latest point release of the 5.12 LTS branch is 5.12.11 https://packages.ubuntu.com/focal/qt5-default
All you're saying is that FOSS developers targeting Linux might[0] be able to lean on the generosity and hard work of Linux distro package maintainers.
That's great, but if you're a FOSS (or free as in beer) app developer targeting Qt on macOS or Windows you're choice is basically between shipping a bleeding edge version of Qt 6.x that will almost certainly cause regressions for your users, or ship a version of Qt 5.15 that almost certainly has known security vulnerabilities.
As an app developer bumping minor Qt versions on my users isn't something I want to do every other month, since doing so requires a lot of regression testing and user feedback. Most of the time I just want to roll in critical bug fixes (security issues, crashers, etc).
[0] In reality shipping Qt apps for Linux is really horrible. As you noted every distro is using a different version, so the users of your app don't all get the same experience unless you go to a herculean effort to bundle your own Qt build.
That's great, but if you're a FOSS (or free as in beer) app developer targeting Qt on macOS or Windows you're choice is basically between shipping a bleeding edge version of Qt 6.x that will almost certainly cause regressions for your users, or ship a version of Qt 5.15 that almost certainly has known security vulnerabilities.
As an app developer bumping minor Qt versions on my users isn't something I want to do every other month, since doing so requires a lot of regression testing and user feedback. Most of the time I just want to roll in critical bug fixes (security issues, crashers, etc).
[0] In reality shipping Qt apps for Linux is really horrible. As you noted every distro is using a different version, so the users of your app don't all get the same experience unless you go to a herculean effort to bundle your own Qt build.
I guess we have a different definition of herculean, I just have a script that builds KDE's 5.15 branch statically and run find_package(Qt5) in my cmake
1. Static linking is legally troublesome if you're distributing binaries because under the terms of the LGPL you have to allow for re-linking of your application. See ringworld's sibling comment on the Zoom app.
2. Even if you static link, you still need to build Qt for every single distro you want to ship your app on. On Linux the Qt GUI library alone has over 40 shared library dependencies. There are also ABI issues. Things like AppImage can help but are pretty nasty.
3. It's a lot easier on Windows and macOS, where there are fewer system dependencies and Qt Company themselves provide bundling tools (windeployqt, macdeployqt) to bundle libraries with your application.
2. Even if you static link, you still need to build Qt for every single distro you want to ship your app on. On Linux the Qt GUI library alone has over 40 shared library dependencies. There are also ABI issues. Things like AppImage can help but are pretty nasty.
3. It's a lot easier on Windows and macOS, where there are fewer system dependencies and Qt Company themselves provide bundling tools (windeployqt, macdeployqt) to bundle libraries with your application.
Regarding 2. that is false, I build everything on a CentOS 7 docker and my appimage just works on every distro from that era onwards (~2015). Hy do you say that it's pretty nasty ? It's the same packaging mechanism than on Mac and Windows, the app ships everything except libc.
There's a linuxdeployqt tool for appimaged - I've never used it but saw a fair amount of apps using it I guess it works ?
There's a linuxdeployqt tool for appimaged - I've never used it but saw a fair amount of apps using it I guess it works ?
> unless you go to a herculean effort to bundle your own Qt build
Zoom ships their own copy of Qt in the Linux packages as an example, lives in /opt/zoom next to their code.
Zoom ships their own copy of Qt in the Linux packages as an example, lives in /opt/zoom next to their code.
And this is a perfect example to show the complexity.
On Arch Linux:
- /usr/bin/zoom is a symlink to /opt/zoom/ZoomLauncher which does not link against Qt. Presumably this just sets LD_LIBRARY_PATH and spawns /opt/zoom/zoom
- /opt/zoom/zoom is the main zoom binary and when run under 'ldd' actually tries to load /usr/lib/libQt* (Qt 5.15 on my system). Running this binary directly doesn't work (Error: "opt/zoom/zoom: symbol lookup error: /opt/zoom/imageformats/libqsvg.so: undefined symbol: _ZdlPvm, version Qt_5")
On Arch Linux:
- /usr/bin/zoom is a symlink to /opt/zoom/ZoomLauncher which does not link against Qt. Presumably this just sets LD_LIBRARY_PATH and spawns /opt/zoom/zoom
- /opt/zoom/zoom is the main zoom binary and when run under 'ldd' actually tries to load /usr/lib/libQt* (Qt 5.15 on my system). Running this binary directly doesn't work (Error: "opt/zoom/zoom: symbol lookup error: /opt/zoom/imageformats/libqsvg.so: undefined symbol: _ZdlPvm, version Qt_5")
> Can you please elaborate on that? I thought the free edition of Qt was open enough to be the right choice for writing fast multiplatform code. Did they change anything wrt licensing, or there are technical issues?
The minor releases are free only until next major one is out. After that, further minor releases are proprietary-only. I.e. that means right now, no free updates to 5.x anymore, if you want maintained release, only 6.0 is an option.
The minor releases are free only until next major one is out. After that, further minor releases are proprietary-only. I.e. that means right now, no free updates to 5.x anymore, if you want maintained release, only 6.0 is an option.
> Can you please elaborate on that? I thought the free edition of Qt was open enough to be the right choice for writing fast multiplatform code. Did they change anything wrt licensing, or there are technical issues?
I believe it still is, as long as you can afford to have a law firm on retainer :)
Same for Delphi TBH. Two great products, dead.
I believe it still is, as long as you can afford to have a law firm on retainer :)
Same for Delphi TBH. Two great products, dead.
Some observations on Delphi, from someone who briefly used it in the mid-90's (so pre-.NET and all that):
- Its main competitor was of course Visual C++ (and I guess to a lesser extent VB); it never quite gained the traction to supplant these, probably various factors here (explored in other comments);
- Building GUIs was a lot nicer that using Visual C++, which at the time was locked into a weird model whereby there was a wizard to create apps that kind of forced you into its Document-View paradigm - a very specific way of looking at an application that wasn't always applicable (in my experience, in fact, rarely applicable). Delphi just allowed you to build GUIs with windows like a normal person;
- C++ lacked STL at the time, we'd use weird stuff like RogueWave to get even basic things like usable strings, vectors etc; with Delphi this was all built in and it Just Worked in this regard;
- Some lower-level shenanigans were difficult in Delphi, and the community was not much help. For forgotten reasons, I needed an equivalent of offsetof, and only eventually sussed out how to do this;
- Verity Stob was a user (and fan)
It's good to see that it's still going though.
- Its main competitor was of course Visual C++ (and I guess to a lesser extent VB); it never quite gained the traction to supplant these, probably various factors here (explored in other comments);
- Building GUIs was a lot nicer that using Visual C++, which at the time was locked into a weird model whereby there was a wizard to create apps that kind of forced you into its Document-View paradigm - a very specific way of looking at an application that wasn't always applicable (in my experience, in fact, rarely applicable). Delphi just allowed you to build GUIs with windows like a normal person;
- C++ lacked STL at the time, we'd use weird stuff like RogueWave to get even basic things like usable strings, vectors etc; with Delphi this was all built in and it Just Worked in this regard;
- Some lower-level shenanigans were difficult in Delphi, and the community was not much help. For forgotten reasons, I needed an equivalent of offsetof, and only eventually sussed out how to do this;
- Verity Stob was a user (and fan)
It's good to see that it's still going though.
>Its main competitor was of course Visual C++
Visual C++ wasn't visual. Perhaps the main competitor was Visual Basic.
Visual C++ wasn't visual. Perhaps the main competitor was Visual Basic.
> Visual C++ wasn't visual. Perhaps the main competitor was Visual Basic.
Both. Their slogan at the time was "The ease of Visual Basic with the power of Visual C++!" -- and AFAICS, it was true.
Both. Their slogan at the time was "The ease of Visual Basic with the power of Visual C++!" -- and AFAICS, it was true.
Ahhhh the Rogue Wave standard libraries! CORBA! The ACE Reactor Library! We had all that in 1998, kiddos.
Kudos for the trip down memory lane regarding ACE. What an amazing library that was. Great abstractions in a language that might have not been 100% ready for them yet...
And rock solid. I worked within a telco platform that combined it with CORBA and PThreads and damn it was contrived but work it did.
> CORBA
Brrrr... /shudders
Brrrr... /shudders
First law of distributed objects: Don't distribute your objects !
I shudder these days whenever a read about thrift, grpc and other binary protocols.
It's kinda sad that Microsoft pawned all Delphi devs to start .NET. It basically killed it, together with c++ builder and all other VCL frameworks.
However, I'm doing a big project using Lazarus and free-pascal (the GPL version of Delphi/VCL), and it's amazing, the IDE has been getting improvements continuously for more than 15 years and now I believe it's better than Delphi, very stable, amazingly fast and also multi-platform.
However, I'm doing a big project using Lazarus and free-pascal (the GPL version of Delphi/VCL), and it's amazing, the IDE has been getting improvements continuously for more than 15 years and now I believe it's better than Delphi, very stable, amazingly fast and also multi-platform.
I've maintained the same Delphi application for 16 years now, made with Delphi 7, and is working 24/7 all the year (no failures, generating about 20,000 db records daily), amazingly only consumes 7mb of ram and is superfast, try doing that with electron.
Ah, yes, news from the Delphi universe...
As a guy who used to work with Delphi professionally until ~10 years ago, I find it fascinating how a development environment can survive for so long while completely flying under the radar. I guess it's mostly legacy applications? I mean, COBOL is considerably older, but still a thing thanks to legacy applications.
As a guy who used to work with Delphi professionally until ~10 years ago, I find it fascinating how a development environment can survive for so long while completely flying under the radar. I guess it's mostly legacy applications? I mean, COBOL is considerably older, but still a thing thanks to legacy applications.
Honestly, for these types of applications (small-business/enterprise in-house) I think we're going in a terribly wrong direction, from terminal apps to Windows GUIs to web apps.
The DX might have improved, UX hasn't. First programmer GUIs with too many buttons and widgets, now the Pagemakerization of everything.
So apart from resources, I can understand companies that try to stick with the old.
The DX might have improved, UX hasn't. First programmer GUIs with too many buttons and widgets, now the Pagemakerization of everything.
So apart from resources, I can understand companies that try to stick with the old.
I think even DX-wise we are painting ourselves into corner. First it is "hey, I know web tech, let's use it for anything". Then it is "hey, that's a bit complicated, let's make a framework". Then "hey, this framework get heavy, let's make some tooling around it". And then "oh, now I spend 75% of my time fighting with the infrastructure".
My team mostly codes internal apps and I 100% agree.
Most SaaS, cloud providers, new data bases, etc... Target web scale, machine learning powered applications deployed to the edge (plus other buzzwords).
Most offerings that target SMBs are low code soluctions or some other sort of hyper locked-in, inflexible bullshit.
I think there's a set of stuff every business wants nowadays (internal network, internal static pages, internal APIs, internal object store, internal DAG / job runner) and there's money to be made by offering a quick, robust, secure and cost-efficient way of developing and integrating those.
/rant
Most SaaS, cloud providers, new data bases, etc... Target web scale, machine learning powered applications deployed to the edge (plus other buzzwords).
Most offerings that target SMBs are low code soluctions or some other sort of hyper locked-in, inflexible bullshit.
I think there's a set of stuff every business wants nowadays (internal network, internal static pages, internal APIs, internal object store, internal DAG / job runner) and there's money to be made by offering a quick, robust, secure and cost-efficient way of developing and integrating those.
/rant
Honestly, I'm not so sure about your conclusion. Businesses themselves don't want job runners. They want their job to be easier.
I mean, that's what I liked about Delphi: It was inflexible, it was (relatively) low on code. Not as much as Visual Basic, which for me always seems to have crossed one bridge too far. But it wasn't exactly highfalutin software engineering all the time. Especially when you're just "beating Excel" by having a simple database interface.
Mainframe apps are something entirely different, but at least the interface is even closer to the data. Some form based apps seem rather like "naked objects".
I think those two "extremes" worked well. Very restricted UI, but that means it's easy to get familiar with it, and enough shortcuts to involve into a very honed workflow for experts.
Or a native app, where you're just used to how things work, from toolbars to scrollbars to combo boxes.
Early web apps were worse, as the HTTP cycle messed up easy tasks, both from a programming and UI perspective. And you still didn't have system-wide shortcuts and all the other UI niceties that were happening since Apple introduced the Mac in 84.
But modern ones? Yeah, sure, now you've got easier dialogs, but still no proper shortcuts and expected UI behavior -- and the web and mobile apps are now going on for long enough that nobody knows anything about that anymore, so there's no word for this loss. I can forgive people not knowing about files and folders anymore, but people should know how a button looks and works.
I mean, that's what I liked about Delphi: It was inflexible, it was (relatively) low on code. Not as much as Visual Basic, which for me always seems to have crossed one bridge too far. But it wasn't exactly highfalutin software engineering all the time. Especially when you're just "beating Excel" by having a simple database interface.
Mainframe apps are something entirely different, but at least the interface is even closer to the data. Some form based apps seem rather like "naked objects".
I think those two "extremes" worked well. Very restricted UI, but that means it's easy to get familiar with it, and enough shortcuts to involve into a very honed workflow for experts.
Or a native app, where you're just used to how things work, from toolbars to scrollbars to combo boxes.
Early web apps were worse, as the HTTP cycle messed up easy tasks, both from a programming and UI perspective. And you still didn't have system-wide shortcuts and all the other UI niceties that were happening since Apple introduced the Mac in 84.
But modern ones? Yeah, sure, now you've got easier dialogs, but still no proper shortcuts and expected UI behavior -- and the web and mobile apps are now going on for long enough that nobody knows anything about that anymore, so there's no word for this loss. I can forgive people not knowing about files and folders anymore, but people should know how a button looks and works.
Related discussion:
https://news.ycombinator.com/item?id=28489516 - "RAD Studio 11 Alexandria" - 11 days ago
https://news.ycombinator.com/item?id=28489516 - "RAD Studio 11 Alexandria" - 11 days ago
I have to repost https://news.ycombinator.com/item?id=28491963 :
My main problem with delphi: it is "too proprietary". It was a very productive ide in the 90's or early 2000's but lost their path and never recovered.
Some new versions broke compatibility with previous version's components. There was the case where you paid a good amount of money on some proprietary components and they simply wouldn't work in the next version: you were imprisoned in an obsolete ide. By not being multi-platform (I hear it improved it lately) you could only use it with/for win32 so it lost servers, embedded and mobile. By not being open-source nobody could improve it.
Then it had to compete with "native tools". Whoever develops for windows wouldn't quit ms' tools to use it, whoever develops for mac wouldn't quit apple's tools to use it, whoever develops for android wouldn't quit google's tools to use it, whoever develops for linux was mostly ignored after kylix.
Note that I didn't even mentioned price and license.
They improved it later, I heard. But seems more like the old case of too little too late. Most successful programming languages today are open source and multi-platform. Delphi was dependent on win32 for too long and it still is "too proprietary". You do the world a favor by porting your project to lazarus.
My main problem with delphi: it is "too proprietary". It was a very productive ide in the 90's or early 2000's but lost their path and never recovered.
Some new versions broke compatibility with previous version's components. There was the case where you paid a good amount of money on some proprietary components and they simply wouldn't work in the next version: you were imprisoned in an obsolete ide. By not being multi-platform (I hear it improved it lately) you could only use it with/for win32 so it lost servers, embedded and mobile. By not being open-source nobody could improve it.
Then it had to compete with "native tools". Whoever develops for windows wouldn't quit ms' tools to use it, whoever develops for mac wouldn't quit apple's tools to use it, whoever develops for android wouldn't quit google's tools to use it, whoever develops for linux was mostly ignored after kylix.
Note that I didn't even mentioned price and license.
They improved it later, I heard. But seems more like the old case of too little too late. Most successful programming languages today are open source and multi-platform. Delphi was dependent on win32 for too long and it still is "too proprietary". You do the world a favor by porting your project to lazarus.
After installing Delphi 10.4 community edition and the license didn't even work, it was the final point for me to say permanent goodbye to the new Delphi.
Lazarus is good enough and the cross-platform promise of Delphi was never truly compelling enough.
Lazarus is good enough and the cross-platform promise of Delphi was never truly compelling enough.
Mine last Delphi was 7... greatest release!
I still miss Delphi from time to time. I started with 5 and used both 6 and 7 before leaving for greener pastures. I've never used anything as productive for creating Windows applications, it was just a joy to use (in 2001-2004).
It's kind of sad that an IDE from 2002 is the pinnacle of ease of use and productivity when it comes quickly and efficiently creating GUI applications.
For inexplicable reasons well beyond my understanding mainstream development had always gone into the most masochistic state.
I usually mention this when Delphi pops up on HN - anvil.works comes close to re-creating that ease of use and productivity, but for web-apps, and in Python.
Now talk to some Smalltalk developers...
Dunno, my gut feeling is that the decline started somewhere after Delphi 5.
I haven't really used 6 but my transition from 5 to 7 was a bit crappy. I remember that Delphi 7 added lots of bells and whistles but had more cluttered UI and worse stability than 5.
Most probably because 7 was supposed to be the big entry of Delphi into the web app market, which resulted in a product with felt rushed and half-baked.
I haven't really used 6 but my transition from 5 to 7 was a bit crappy. I remember that Delphi 7 added lots of bells and whistles but had more cluttered UI and worse stability than 5.
Most probably because 7 was supposed to be the big entry of Delphi into the web app market, which resulted in a product with felt rushed and half-baked.
Idk, I remember some good things that I was surely missing in 5, and little less in 6. Upgrades were a little bumpy, but after that phase it all felt much better.
Same here. It was an era where the company I worked for was looking to transition to web. The web was NOWHERE near ready for a desktop-app like experience. Especially since the RAD crowd (VB, Delphi, etc) expected to drag and drop components on a canvas and wire them up in code. We saw that as the holy grail. Delphi apps were promoting a "briefcase model" client/server architecture. And we were sort leveraging that for salespeople in the field. They'd go out, do their work, and then get online to sync data when they could. The idea that they could just hit a web page and do up to the minute transactions over a dial-up internet connection was the new "holy grail".
Moving to the web meant Perl:DBI, then Python/MySQL, then finally PHP4.
I'll always have such a soft spot for those Delphi days though. Kylix too!
Moving to the web meant Perl:DBI, then Python/MySQL, then finally PHP4.
I'll always have such a soft spot for those Delphi days though. Kylix too!
Interesting that there is still a development team working on that product. Also interesting that apparently you can produce android applications with it. Sadly due to the pricing, I doubt many will take this into use for new projects.
The language popup insisting on every page that they've unhelpfully detected my ip address is in Germany is really annoying. It asks on every page load and does not remember anything. I guess there are some dust old developer offices somewhere in Germany still handing over cash to them to maintain decades old enterprise applications.
The language popup insisting on every page that they've unhelpfully detected my ip address is in Germany is really annoying. It asks on every page load and does not remember anything. I guess there are some dust old developer offices somewhere in Germany still handing over cash to them to maintain decades old enterprise applications.
I have very fond memories of Delphi - it got me into programing and I earned my first money from a job using Delphi. Nowadays, while doing web development I still miss some features. I haven't used Delphi after version 7 (just before the .NET switch).
However, Delphi is still used by some companies! My mother works in a small company developing business software like accounting, payroll, inventory tracking etc. They still used Delphi (I think version 7) and have a small, but thriving business. No incentive to switch...
However, Delphi is still used by some companies! My mother works in a small company developing business software like accounting, payroll, inventory tracking etc. They still used Delphi (I think version 7) and have a small, but thriving business. No incentive to switch...
I'm part of a team that looks after a 1.3 million loc application in Delphi using the XE7 version. The 32-bit version builds in just 11 seconds on an 18 month old laptop.
I've just spent the last two years adding Virtual Channels support to our product. If you're not into COM in C++, Delphi is excellent for this kind of stuff. However the Infosec part of the company hates that we have to have Local Admin access but you can't register/unregister COM objects without it.
I've just spent the last two years adding Virtual Channels support to our product. If you're not into COM in C++, Delphi is excellent for this kind of stuff. However the Infosec part of the company hates that we have to have Local Admin access but you can't register/unregister COM objects without it.
[deleted]
I have fond memories of Delphi, and it looks like an amazing product, the deal breaker for me is that it runs only in Windows.
Reading about Delphi brings back some fond memories about Delphi 6 and using the JEDI JCL / JVCL and Inno Setup for the installation and upgrade process. Spent a couple of years building a software for editing and synchronizing configuration files (for a specific piece of hardware) with Palm Pilot devices. Good old time.
I was using Delphi 5 for years, that's 2001 year, to build a Vehicle annual inspection system
[deleted]
Delphi was nice for building desktop Windows apps.
How many people still do this? Most new work I do is either mobile or web/server.
How many people still do this? Most new work I do is either mobile or web/server.
borland died .. wasted my 4 years on this product.
That's unfortunate.
I started off writing applications with Nantucket's Clipper. That product also died but I look back fondly at the experience because I learned a great deal that I was able to apply to the next thing and the thing after that.
I started off writing applications with Nantucket's Clipper. That product also died but I look back fondly at the experience because I learned a great deal that I was able to apply to the next thing and the thing after that.
For most people though, including me, Delphi seems to be something nostalgic. Good old days, the first time I built applications in high school until I get reliable internet connection and gained my bad coding habits with learning PHP.
I remember building a password manager(stored your passwords in a plain text file hidden deeply in the OS folders structure, had an access counter), a lottery coupon filler(generated printable coupon images so you don't do it with a pen) and a port scanner(the remote address tab was called "far address", because English) and getting them distributed on application download websites.