Delphi 11 Alexandria
blog.marcocantu.com
blog.marcocantu.com
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.
But later they become CodeGear and later their R&D division is moved to Romania. Products become unstable and unreliable.
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.
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
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
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.
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).
Wait isn't QT free?
Do you?
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 am pretty sure they might even sell more professional licenses if they had a wider userbase of enthusiast users.
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.
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.
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.
To attract new users, you first have to show them, that you have a great product, then you can charge them. I am very happy that LispWorks is still a product and wish them all the best. If their strategy works well for them, great! I can only tell the story why I haven't gotten LispWorks, despite having a good impression of the system in the minimal trial I was able to run. But I couldn't try it to the point where I would have been willing to spend that much money on this. I am a Lisp programmer for over 20 years now, 15 of those as a professional developer. I ended up with the stack consisting of SBCL+Slime+LTk. Also quit nice :). At work, our team uses mostly SBCL and Allegro. None of us has used LispWorks, all for similar reasons. And that is, why no one pushed for LispWorks, when purchase decisions were discussed.
LispWorks has the no-cost Personal Edition to get an impression and one can get trial licenses of the whole product.
Generally I fear that there is very little money to be made from a low-price (say: $100 - $300) Lisp implementation (the market is still small) and that few people will upgrade to a more expensive version of it (what would be the reason to do so?).
I tried the no-cost edition, but as it couldn't run my pet project I was working on back then (memory limit), that trial lasted a few minutes and I continued to use SBCL.
In reality it is a company with a handful of employees in a very small niche market.
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.
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.
Jetbrains proved that you can successfully can compete against free. But the pricing needs to be reasonable.
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.
At least at the time it allowed me to build professionally looking applications with practically nil experience and with little effort.
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.
Having a Delphi equivalent for Rust would be a dream. The build times are never going to match Pascal's single pass compiler, though.
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.
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.
There are ways to get it in Java, but other than Graal, they cost just as much.
https://news.ycombinator.com/item?id=28490736
2021-09-11 73 points | 163 comments
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.
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.
- 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.
Last I checked two weeks ago there was no Linux support. I still don't see any mention of Linux support.
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.
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.
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?
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.
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/
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 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
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
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.
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.
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 ?
Zoom ships their own copy of Qt in the Linux packages as an example, lives in /opt/zoom next to their code.
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")
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.
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.
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.
- 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.
Brrrr... /shudders
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.
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.
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.
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.
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
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.
https://news.ycombinator.com/item?id=28489516 - "RAD Studio 11 Alexandria" - 11 days ago
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.
Lazarus is good enough and the cross-platform promise of Delphi was never truly compelling enough.
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.
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!
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.
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'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.
How many people still do this? Most new work I do is either mobile or web/server.
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.