How many people use Delphi?

[David Schwartz 426]

Stack Overflow is not like most social media sites with a "newsfeed" that are more like sitting on the bank of a river watching things float by, many of which are the same Qs and As on different days.

 

Delphi evolves very slowly, and a large number of users are still working with much older versions -- many even D7. There are a bunch of folks on SO who do their best to slap people who don't do searches (although it helps a lot to know what exactly to search for that may already be there, which is my biggest impediment). 

 

So in a nutshell, it may be fair to say that most of the questions people might have about Delphi have been asked and answered. SO is a rich resource in that respect. Newer languages and ones like C++ and C# are evolving much faster than Delphi, so of course there will always be lots of questions on newer features and updates.

 

I don't know if those metrics on SO are measuring Delphi-related SEARCHES or just POSTED QUESTIONS. Regardless, with such a slow evolution of the language and the fact that it retains so much backward compatilbility, what stone hasn't already been unturned when it comes to, say D7?

[David Schwartz 426]

In the "Is Delphi Dead" category, one of the largest users of Delphi over time has been the US Veterans Administration. Delphi was used for all of their front-end apps, and MUMPS for all of their DB needs. (I worked for a company for a while that was working with them, and their "API" as it were was a bit of code published in 1996 and a threat that anybody who touched it in any way would be tarred-and-feathered. I know someone else who went to work with another very LARGE tech company that had just secured a big VA software contract, and he was hired to organize a team to do the Dephi part. Everything that goes on inside of VA hospitals and their facilities worldwide runs Delphi on their UIs. 

 

That's not to say that some companies haven't built simple Delphi adapter layers that allow them to run something on top of them, but Delphi was used to issue MUMPS DB requests and get back MUMPS-formatted responses. 

 

I've been out of that loop for several years now, but this is a prime example of a huge organization with a TON of Delphi code that wasn't going to be moving to anything else very soon or very quickly. 

 

And keep in mind that the VA is not just a "medical facility" -- besides HIPAA and related requirements, they treat symptoms and injuries caused by stuff that's highly classified by the US Government and I was told that HIPAA regs pale in comparison to the other secrets they have locked away in their DBs. "Security by obscurity" seems to work well for them.

 

The US Government might well be keeping EMBT on life support simply to ensure it does NOT go belly-up. 

 

Keep in mind there are plenty of companies paying Microsoft to continue issuing security updates for Windows 7 to them, presumably to avoid that cost and "trauma" caused by being forced to move a bunch of code to a newer version of Windows that may cause their software to operate improperly.

 

I've also worked on a couple of State Govt contracts that have 10-15 year-old apps written in Delphi that they are forced to update periodically as state laws impose changes in things the software manages. At one place, I was told the legislature there had been trying to pass a budget to replace all of the software and every time they did a formal analysis, it was always far cheaper to just pay to have contractors come in and fix the code than go through the hassle of replacing it with something totally new. The biggest threat to their software was not Delphi, but being forced to upgrade all of their hardware and Windows software that usually led to a lot of breakage that, of course, nobody ever budgets for.

 

 

 

Edited April 25, 2023 by David Schwartz

[David Schwartz 426]

As far as performance goes, I don't think I've ever worked on a Delphi project where the speed of the code was ever an issue. I've seen planty of situations where we got complaints about performance, and in every instance they were tracked down to poorly-devised DB (usually SQL) queries. I've also seen some poorly written code that sped up amazingly with a little bit of refactoring. But none of it was slow because of compiler optimizations -- or lack thereof. Shoot, most projects don't even bother to turn off Debugging code support! UIs offer plenty of time to get stuff done while the user is waiting for back-end queries to process. 

 

One place I worked at for a while involved insurance "illustration" apps. They cared far more about repeatable math results with predictable rounding errors than in how fast the calculations ran. When you can be held legally liable for calculations that have slight rounding errors that get magnified over 40-60 years, that's a problem. A really BIG and EXPENSIVE problem. 

I've worked on a bunch of real-time embedded software platforms, and they were all pre-Delphi. But they all used C and assembly language. They were always paranoid even to use C++ for years after it came out. They mostly avoided Windows as well. (Does anybody remember the fiasco when they were building the new Denver Airport using Windows NT? It was designed as a real-time embedded system and it just didn't work. They have miles of tunnels there for moving luggage that were simply abandoned because the idiots in charged believed Win NT was a Good Idea for controlling a distributed network of control nodes. The company whose DB they were using ended up being thrown under the bus and went out of business. They were using a Windows-based C compiler, that may have been Borland's.)

[dummzeuch 1505]

Performance can be an issue, but most of the time it's not really the performance of the generated code but the wrong algorithm selected by the programmer or a faulty implementation of that algorithm. Only after the best algorithm has been selected (and properly implemented) the optimization of the compiler becomes an issue. I have had several performance bottlenecks that were solved by simply turning on optimization (which I usually leave turned off due to it not making any difference and sometimes creating issues). But once you get to manipulating large amounts of data that reside in RAM, the poor quality of the compiler begins to show. But in my experience these situations are rare.

[David Heffernan 2345]

1 hour ago, David Schwartz said:

I don't think I've ever worked on a Delphi project where the speed of the code was ever an issue.

That's nice. But plenty of other people are in the situation which you are lucky enough never to have found yourself in.

[Stefan Glienke 2002]

"An E-Smart is a pretty fast and comfortable car!" - grandma who only ever drives to the local grocery store.

Edited April 25, 2023 by Stefan Glienke

[David Schwartz 426]

On 4/25/2023 at 6:33 AM, David Heffernan said:

That's nice. But plenty of other people are in the situation which you are lucky enough never to have found yourself in.

 

In my experience, if performance is really critical on a project, then first of all, Windows is NOT the platform you want to be working on. Second, you certainly don't want to be stuck using a programming language / system built around building apps that are based around forms used to interact wiht a DBMS somewhere off-premeses. But that's just me. I would never even take such a role, and I've been offered several. They make me want to reply, "What part of 'square tires will never be as smooth at rolling down the road as round tires' don't you guys understand?" You cannot "optimzie" rolling resistance out of square tires. They just think we're all a bunch of "dumb programmers" and that "poor attitudes" are to blame.

 

Phones today are many times faster than Cray computers were in the 90's. Don't expect me to agree that getting a few more percent of performance from compiler optimization is important when CPUs a year hence will offer a a 2x-5x improvement right out of the box with zero optimization.

 

I do realize there are environments that rely on old hardware and software for safety and durability reasons, but if compiler optimization is really a make-or-break proposition, you're way too close to the edge of a very dangerous precipice, IMHO.

 

[David Heffernan 2345]

1 hour ago, David Schwartz said:

In my experience, if performance is really critical on a project, then first of all, Windows is NOT the platform you want to be working on.

Why not? My experience is that the OS is largely unimportant because it's the hardware that matters. 

 

1 hour ago, David Schwartz said:

Second, you certainly don't want to be stuck using a programming language / system built around building apps that are based around forms used to interact wiht a DBMS somewhere off-premeses.

Well no, but that's not even remotely what I'm talking about. 

 

1 hour ago, David Schwartz said:

Phones today are many times faster than Cray computers were in the 90's.

My competitors aren't coding for 90s Crays. They are coding for today's hardware, as am I. 

 

1 hour ago, David Schwartz said:

Don't expect me to agree that getting a few more percent of performance from compiler optimization is important when CPUs a year hence will offer a a 2x-5x improvement right out of the box with zero optimization.

For of all, we haven't been getting annual doubling of performance for quite a while now. But again I'm not competing against last year's computers. The developers writing code that competes against mine are also able to use that same hardware as me. 

 

Just because performance isn't important to you doesn't mean that it isn't important to others. Your experience of the world isn't the same as others. 

[dummzeuch 1505]

2 hours ago, David Schwartz said:

CPUs a year hence will offer a a 2x-5x improvement

Nowadays single threaded CPU performance doesn't really improve that fast. And even if it did, do you really propose to replace all computers in an organisation, because one program is too slow?

It's much better to improve the software, especially make it multithreaded, because that will benefit everybody at once, including those who actually get a faster computer.

 

And often it's not even possible to solve a performance bottleneck with hardware. It might be in some area that is intrinsically slow. Ok, in that case, compiler optimisation won't help either. But that's a low hanging fruit: If the compiler creates better code, all programs will benefit just by recompiling them.

 

On the other hand: There are so many awfully slow programs around, that even without any optimization and with full debugging enabled, a reasonably well planned and written Delphi program would outperform most of them. I'm currently on vacation, but before I left, I was analyzing a tool that comes with hardware with a 5 digit price tag, which not only has a dreadful user interface but is also slow as hell. I plan to replace it with a Delphi program, because everybody in the company who came in contact with it, hated it on sight. To be fair: It's the frontend part with the UI that sucks, I won't be able to replace the backend, that does the actual work. And I will of course only implement those parts of the functionality we actually use.

[Stefan Glienke 2002]

7 hours ago, David Schwartz said:

when CPUs a year hence will offer a a 2x-5x improvement right out of the box with zero optimization.

If it weren't for other statements already this one really disqualified you from even participating in any performance-related discussion.

I just recently updated from an Ivy Bridge CPU to a Raptor Lake at home and the single-thread performance of some Delphi benchmarks approximately doubled.

 

If you don't believe my sample then simply take a look at https://www.cpubenchmark.net/year-on-year.html

You see that in about 10 years the single thread performance approximately doubled (and even less on server hardware).

 

And when we think about how the real gains in performance are achieved these days (parallel computing) Delphi is even in a worse situation given the poor support for anything parallel computing (yes, it can be achieved but you need to handcraft a lot of code and much existing code does not scale well at all).

[Fr0sT.Brutal 900]

One more of those endless topics 🙂

Talking about poor performance of Delphi, remember there are Electron applications 🙂

[David Heffernan 2345]

21 minutes ago, Fr0sT.Brutal said:

Talking about poor performance of Delphi, remember there are Electron applications

Sorry, I don't know what point you are making. Can you elaborate?

[Stefan Glienke 2002]

33 minutes ago, Fr0sT.Brutal said:

One more of those endless topics 🙂

Talking about poor performance of Delphi, remember there are Electron applications 🙂

Rhetoric 200 - What's Whataboutism?

Edited April 27, 2023 by Stefan Glienke

[Fr0sT.Brutal 900]

15 hours ago, David Heffernan said:

Sorry, I don't know what point you are making. Can you elaborate?

You point out that Delphi compiler produces slow code but there are slow as hell Electron or Java GUI apps that are however very popular. Market seems no not care much about speed (of course not talking about servers and data processing tools).

15 hours ago, Stefan Glienke said:

Rhetoric 200 - What's Whataboutism?

This is the ~5th similar topic on my memory, no more left to say except flood 🙂

Edited April 28, 2023 by Fr0sT.Brutal

[PingPIng 23]

the main problem is that there is not a community of programmers who do it as a hobby, and also a lot of projects on github are not carried out because there is no collaboration (unlike all other languages)

[David Heffernan 2345]

55 minutes ago, Fr0sT.Brutal said:

You point out that Delphi compiler produces slow code but there are slow as hell Electron or Java GUI apps that are however very popular. Market seems no not care much about speed (of course not talking about servers and data processing tools).

Let's look at this argument. There also exist many dev tools and programs built with them, that are blazingly fast. By your logic we would conclude that market does care about speed. But now we've got contradictory conclusions using your logic. There must be a flaw somewhere. Is it possible that performance is critical in some cases, but not others?

 

If go right back to the start of this particular thread, my original comment was in response to a claim that code compiled by delphi was fast. I disagreed with that. Seems like you actually agree with me. 

[Sherlock 663]

I'd like to think, that the "Delphi is fast" statement refers to compile times (only). But then I compile for anything other than Win32 and grow silent again....

[Fr0sT.Brutal 900]

6 minutes ago, David Heffernan said:

There also exist many dev tools and programs built with them, that are blazingly fast.

Really? I tried several Electron apps and even the simplest of them (markdown editor) is like a snail. And VSCode too when you fill it with several necessary addons.

9 minutes ago, David Heffernan said:

If go right back to the start of this particular thread, my original comment was in response to a claim that code compiled by delphi was fast. I disagreed with that. Seems like you actually agree with me. 

Well, I agree for sure - I've seen many samples of poor ASM generated - but my point here is that most of Delphi use cases are desktop apps where even awful performance is acceptable (these Electron apps) and compared to them Delphi code is fast enough. Moreover, projects like mORMot strive to write fast server code and succeed. As for complex data processing where your main criticism of Delphi code goes - I suppose such apps only occupy a little % of all Delphi software. Anyway huge part of computations are done with interpreted Python, what better evidence of that people prefer develop simplicity over speed is needed 🙂

[David Heffernan 2345]

4 minutes ago, Fr0sT.Brutal said:

Really?

Not with Electron. I'm thinking of programs built with other tools. Or do you claim that programs exist that perform their task efficiently?

 

5 minutes ago, Fr0sT.Brutal said:

most of Delphi use cases are desktop apps where even awful performance is acceptable (these Electron apps) and compared to them Delphi code is fast enough

I don't disagree. I'm talking about the other use cases.

 

5 minutes ago, Fr0sT.Brutal said:

Moreover, projects like mORMot strive to write fast server code and succeed.

Have you seen how much labour Arnaud puts in to writing asm code? Because the Delphi compilers can't do the job. Other tools can do the job though.

 

7 minutes ago, Fr0sT.Brutal said:

Anyway huge part of computations are done with interpreted Python, what better evidence of that people prefer develop simplicity over speed is needed

I don't think that's a fair assessment. The programs you are talking about call into libraries like numpy and scipy and the kernels of these libraries are implemented in Fortran and C. 

 

 

I wish people would stop telling me that performance doesn't matter to me. How do you all know what matters to me?

[Fr0sT.Brutal 900]

2 minutes ago, David Heffernan said:

I wish people would stop telling me that performance doesn't matter to me. How do you all know what matters to me?

I'd never tell such a foolish thing 🙂 Everyone has his own requirements. I'm just telling Delphi's performance seems to be OK for most of its use cases.

[Lars Fosdal 1792]

@Fr0sT.Brutal

I use VSCode a lot to search source code and structured data (XML, JSON), and I've got 47 plugins installed.

I find it to be pretty snappy for my use, TBH.

 

[Dalija Prasnikar 1396]

13 minutes ago, Fr0sT.Brutal said:

but my point here is that most of Delphi use cases are desktop apps where even awful performance is acceptable (these Electron apps) and compared to them Delphi code is fast enough.

Are you sure that poor speed is acceptable on desktop applications? What about applications that need to load complex forms where opening such form can take half a minute or more? Or when you need to create plenty of business objects, or when you need to do some textual processing. Good compiler means a lot in such cases. In last few Delphi releases @Stefan Glienke has continuously submitted hand crafted code to improve speed of some widely used RTL routines that have impact on overall performance. With better compiler that would not be necessary. Not only that, but with better compiler all other code we write would be faster and when speed matters we wouldn't have to bend over backwards, writing horribly unreadable code just to get the speed we need. We could just write the clean and readable and maintainable code and leave the dirty work to the compiler.

 

Speed always matters. Now, Delphi still might be fast enough for many purposes, but for many that is simply not enough. Once it was state of the art compiler, now it is seriously falling behind.

[Kryvich 165]

However, they have updated the build-in assembler, and now you can write quick code snippets right in the PAS file.

[Fr0sT.Brutal 900]

4 hours ago, David Heffernan said:

Or do you claim that programs exist that perform their task efficiently?

I'm afraid I don't understand this

4 hours ago, David Heffernan said:

Have you seen how much labour Arnaud puts in to writing asm code? Because the Delphi compilers can't do the job. Other tools can do the job though.

Sure, he's amazing. Great that Delphi allows rewriting only some critical parts to achieve good speed, isn't it?

4 hours ago, Lars Fosdal said:

I use VSCode a lot to search source code and structured data (XML, JSON), and I've got 47 plugins installed.

Well, you're lucky. Mine has only 10 and switches between working folders in ~10 secs (I mean to become fully functional with all language features). It could be addons that cause slowdown of course but what's the sense in bare VSCode after all?

4 hours ago, Dalija Prasnikar said:

Are you sure that poor speed is acceptable on desktop applications?

NO and never! I hate slow and fat apps. But vendors seem to think contrary. Skype, Slack (or Discord?) and many more turned from compact native apps to Electron based monsters.

Edited April 28, 2023 by Fr0sT.Brutal

[Stano 143]

Unfortunately, many of them with a million features that nobody wants. After all, the manufacturer knows best what users really need.