25 years of Delphi and no Oracle in sight: Not a Visual Basic killer but hard to kill On this day 25 years ago, Borland Software trotted out version 1.0 of the Delphi application development product, making the announcement at the Software Development '95 event in San Francisco. That year, the current version of Windows was 3.11 (or NT 3.5), with Windows 95 in beta. There was high demand for custom business …
I remember the excitement when Turbo Pascal was first released, prior to that I had been using Oregon Software Pascal-2 because I could write a program on a DEC RSX11M system at work and then recompile it at home on MSDOS or vica versa - sweet! I still occasionally write in Pascal to demonstrate code because it's readable even if you are not a Pascal programmer.
Pascal was a horrible language for real work, at least in the 80s when I first encountered it. Being designed as a teaching language it had very limited I/O features, so almost every implementation had its own subtly-different ways to format stuff with writeln & friends, and input was worse. Linking to external libraries and objects was also sometimes challenging, except perhaps on VMS where the VMS Calling Standard made interoperability simple.
I much preferred Wirth's follow-on language, Modula 2.
That's your opinion - I saw academic researchers all over the world jumping into Pascal and writing programs to implement the math of physics in analyzing human motion. Every single gait analysis application was written in Pascal when gait analysis papers were first published - I say "application" but in reality they were all collections of programs written in Pascal that processed the data.
Anonymous because I still have copies of all the early code but the beauty of Pascal is that you can see "how" it work by reading the code without needing tons of comments. Modula 2 was OK but it was never as widely used as Pascal.
the beauty of Pascal is that you can see "how" it work by reading the code without needing tons of comments
Indeed. I remember very well when once I was given a Turbo Pascal program of a couple of 100k lines which controlled some test facilitie. No documentation was available and my task was to amend the thing. Just tracing and reading the code was enough to understand it - even if it took a few days and a few more...
If your code isn't readable then it's your fault not the languages. A good developer codes in a way that explains to other humans what the code is supposed to do. The computer needs to understand it too but if the humans can't understand it then it can't be modified or maintained.
It's great that Pascal encourages this kind of coding but whatever language you write in you should make readability a prime concern.
it's your fault not the languages
In my short and inglorious career as an assembler programmer on IBM big iron it was impressed on us time and time again "don't try to be too clever". With plenty of examples why not already available in our code base (some of which was written in the 1960s and barely touched since).
If we had to maintain some of the more odd bits of the codebase it was generally easier to just start again rather than fix existing code.
One particularly bad example was a bit of code that essentially copied itself to a new memory block, modified the copy then proceeded to try to execute the copy. Which crashed (really, really badly) once multi-CPU operations came in.
That's your opinion
Not just mine, see Brian Kernighan's paper Why Pascal is Not My Favorite Programming Language. Others have disagreed with him, of course.
A lot of the issues raised by Brian Kerningham apply only to the old or original version of pascal - such as the fixed array lengths, string types and inability to pass arbitrary arrays to functions.
Some of the issues he raised are actually good features of Pascal - which are implemented as kludges in K&R's shitty C. For example the approach of defining a function/procedure in Pascal before using it is actually a favorite feature of mine - it meant that if I am looking for the definition of a function I just need to look above and not everywhere as I have to in C. It also means that the compiler is super fast as it already knows about the function by the time it is called. In C, the put a function anywhere concept means that you need to declare them in header files and use include them everywhere and then deal with the possibility of recursive #includes with the nasty #ifdef _MYHEADER_H_ .. #endif kludge.
I've had huge programs with several thousand lines of code compile (Clean build) in under 1 second on a 4.77MHz PC - try beating that in C. Pascal compilers compiled in 1 pass while C compilers preprocessed, compiled (multiple passes) and linked.
The "father of the buffer overflow"? <G> And one of those who thought a language didn't need a string type - if we wish to talk about I(/O needs? Of course, if you design a language you want it adopted, not someone else's.
All of that, anyway, was written before TurboPascal 1.0 was released (1983), and almost none of them apply to Borland Pascal since at least TurboPascal 4.0 (1987) - and when Delphi was implemented the language had become fairly advanced already - i.e. adding exception handling, full OOP was introduced years before. I/O was already handled by quite functional UI frameworks.
Moreover, a not a little work was required to fix many K&R C issues in later versions of C.
There was no a standardization body - that's true - in those years PC companies were much eager to get any competitive advantage they could than sitting at a table to standardize anything. How many dialects of BASIC existed?
But even today recompiling an application written for GCC with Visual C++ is no exactly painless, and anyway today most of the issues are in the libraries used, not the language itself.
The Wirth original version, probably. But when Apple and Borland implemented their commercial versions, they extended the language to make it far more usable for real work. For example Turbo Pascal could easily link object files, and then DLLs, when Windows appeared.
Don't know about the UCSD version, because I never used it. I believe most developers who used Pascal on PCs used the Borland or Apple version (or even the Microsoft one).
The problem with Wirth is he never improved and update a language, he designed new ones, like Modula-2 and Oberon. I understand that from his point of view, the academic researcher, it was the way to go, but a company betting on a language needs compatibility among the releases, for years.
But when Apple and Borland implemented their commercial versions, they extended the language
Which was the problem, the original was so basic and theoretical that implementations had to extend it. If you only ever used one system, especially a well-specified one like Borland it could be OK, but portability was non-existent.
Don't know about the UCSD version, because I never used it.
I did, for a while, on an Apple II (that dates me :) )
At least UCSD Pascal was OK there, if a little resource-limited. Others were less so, for some weird reason the p-system Fortran implementers decided to make REAL numbers use 5-bytes to get enough precision, but left INTEGERS as 4. A violation of the standard, and it played havoc with COMMON blocks.
The problem with Wirth is he never improved and update a language, he designed new ones
As you say, that was what he needed as a teacher, but it was irritating. Probably the reason why most of them are long-obsolete. Pascal's still around, I haven't seen anything in Modula 2 in years.
"Don't know about the UCSD version, because I never used it."
An OS written in a high level interpreted language was pretty neat. Yes it compiled down to p-code but p-code was then interpreted.
I don't know how novel its UI features were but coming after cards on mainframe and CP/M (even CP/M with FORTRAN) they seemed pretty innovative. There was a ton of clever stuff in there.
I used to write all my commercial applications in Pascal - specifically Turbo Pascal (v6, I think 3 floppies?). I never had the issues with IO - in my line at the time, there input files were never standard between installations, so having to write custom readers for binary data files (with no documentation, of course) was the norm. A lot of our stuff was built as apps which were loaded on the fly from batch files (these were DOS apps). A lot of the manipulation then centred around managing BTrieve databases and new binary data files. TBH. I found TP the strongest and most productive compiler - especially when you built a custom bgi librart.
I wrote a device drivers in turbo pascal to work with a windows Delphi app.
Its job was to pre-register client handles with windows csmapper so that apps could regisster with card services (pcmcia) *after* windows had started (csmapper was intednded only for clients that loaded before windows started).
There was quite a bit of dpmi stuff going on to ensure that callbacks occured in the correct virtual machine (if there were dosbox clients running under windows).
Turbo pascal didn't lack anything C could do.
Pascal was a horrible language for real work, at least in the 80s
When I was at Polytechnic (85-87\0 we had to, as part of the programming module, write a simple stock-control system in Pascal. I was using a Pascal ROM on my BBC model B and one of the (many) features that it was missing was random file access...
So I just wrote a convincing demo instead. The CS lecturer was so amused that he gave me full marks.
I liked ISO and turbo pascal but Delphi was the best of all worlds, nice compact EXE without need to maintain crappy external libraries like the MS rip offs. When I say compact I mean that delphi version of medium sized project fits on a floppy and MS compiler version does not even ignoring the support libraries.
For general purpose code you could write something once and never be bothered with it again, something that has since disappeared in the development world who seem to prefer to push crap code out the door and live off blackmail in the form of maintenance contracts.
Oregon Software Pascal (also known as OMSI Pascal) was not that popular. I thought we were one of less than a handful of UK customers.
We used it for teaching purposes on RSX-11m at Newcastle Polytechnic, and we had the academics writing everything from a student support software suite (which the academic used as his BCS Part 2 qualification work) through linear algebra and realtime control programs (RSX-11M was a real, realtime operating system, and the PDP-11 was great at interrupt processing).
We managed to link to the NAG libraries, a GKS subsystem, and pretty much all of the RSX-11m included libraries, although Files-11 was a bit of a challenge. The secret to traditional data processing in standard ISO Pascal was the Variant record, which enabled you to do fairly sophisticated file I/O even though the standard I/O looked a bit limiting. The one thing Standard Pascal could not do was file I/O with variable record sizes, though. The biggest problem was the 16 bit program address space for the 11/34 we were using, so unless you were prepared to use overlays (I never did get the hand of OVL syntax for overlays), linking large libraries seriously reduced the size of the programs you could write.
You are correct; and really we should have used windows 3.11 for the screen grabs (ran out of time), my only excuse is that in this instance Explorer is being used like Program Manager - this is what happens if an installer designed for Windows 3.x runs on Windows 95.
Tim
> really we should have used windows 3.11 for the screen grabs
I posted a video of installing Delphi and writing a new app on Windows 3.11 a couple of days ago, which you might enjoy: https://twitter.com/cpp_delphi_dave/status/1227574959712690177
It's very short, less than two minutes long.
> it took a lot longer than 2 minutes to feed in the 15 or so floppies it came on.
For sure. I think I was lucky enough to install from the CD, even on Windows 3.1. I recall installing Windows itself from many floppies though.
In the video on twitter, I install via the CD ISO, virtualised to a CD drive in the VM.
Compiling a project though was incredibly fast, like less than one screen refresh cycle fast.
Yes, Kahn and his team could write a really fast compiler. I did a fair bit with Turbo Pascal 3 on an original 5150 IBM PC that had the ROM upgrade to let it use the hard disk expansion, so a 4.77 MHz 8088. One of very few IDEs I actually liked, and recompiling was a matter of seconds even for relatively large programs.
Borland published a great self-teaching book for Turbo Pascal that walked you through developing a Star Trek game, introducing a new major feature in each chapter. I don't remember the title, but it was fun and well-written.
I'm a little sad they spun the languages-and-IDEs products out into CodeGear and then sold that division to Embarcadero before Micro Focus bought Borland. It'd be another nice piece of IBM-PC-compatible-software history for us to have.
> the question is why Delphi failed to sweep up more of the Windows development market than it did
In the late 90s early 00s: snobbery vs Pascal, was what I mostly saw.
Much eyerolling and smirking by developers; much alarum or scoffing by management.
The latter were/are just meme monsters so C++ or Java were cool; the former had a problem with its age but mostly with the idée fixe that it was a baby's-first-teaching language and not capable of real-world work.
RealProgrammers liked it. But they're the exception not the rule.
Actually it was something completely different.
MANY Delphi programmers came from the Clipper world, a big selling MSDOS database handling compiler which could handle a number of databases.
As to the replacement environment there were many.
Number one rules was - can my new development environment use the same database?
In most cases yes, but Delphi not straight away.
A large number of Clipper applications used the data formats DBF CDX FPT.
This was supported in a few other environments including Visual Objects and Alaska XBase++, Delphi used Paradox.
HOWEVER serious systems using Clipper used client server systems with Advantage XBase Server, this was a server based NLM handling the data, later on a Windows service and even more recent a Linux versions were added.
When the Advantage wrappers for Delphi appeared it took off. It was one of the bigger DOS escape routes.
I would put its escapee market share as similar to Visual Objects but with more non Clipper programmers on top.
The writers of AXS later ADS also used Delphi themselves.
But with the improvement in hardware specifications making SQL more usable for medium sized systems the need for fast client server ISAM is dropping, also we do not trust SAP with Advantage, SYBASE were fine.
Also all us older Clipper programmers are either retired, or within a decade of retiring, so systems are now moving to more main stream stuff like C.
We are currently benchmarking tools for our post WIN32 world. We took one choice to WIN32, Delphi users took another.
Oh and in the DOS days it was almost open warfare between Clipper and F*x developers.
Oh hell yes, the paradox database system was a total and utter curse in every way. I remember encountering early projects and it was one of the first things to be taken out of an application and terminated with extreme prejudice. I don't remember there being a single advantage to using it but countless disadvantages. Almost nothing needed it, there really didn't need to be another inefficient and unwieldy competitor to ODBC and even from v1 of the VCL it was possible to put in direct, useful and efficient connectors to databases - although considerably easier to do so with later versions.
Paradox? [shudders] brrrrr
My route to Delphi was through Coral 66, via Clipper to DOS Pascal to Delphi. Because of my Coral background I hated Clipper's variable scoping and their macro expansions. Took to Delphi 1.0 like a duck to water when it was launched. Been a loyal user ever since (it does what it says on the tin). Still use it every day for database development where data integrity and reliability are far, far more important than the appearance on the screen.
Dbase and Paradox made me pick up very bad database design habits. I seem to remember going to a Delphi seminar where the subject of retiring the BDE from one's toolbox was addressed. I'm a big fan of IBObjects.
Happy Birthday Delphi! Let's hope there are many more of them...
Delphi used both dBase and Paradox - the Borland Database Engine supported both natively, since Borland bought Ashton-Tate and developed Paradox. Clipper was a dBase derivative which became hugely popular because it could compile applications and required no run-time.
Many dBase developers migrated to Delphi, especially since Borland didn't developed dBase itself any longer, and Windows was replacing MS-DOS. On my first job we had a Delphi instructor who came from dBase - it resulted he knew less than me who came from TurboPascal.
Delphi and VisualBasic put an end to many dBase clones, although some survived (i.e Access) for a while, but most had problems to switch to a GUI environment.
Anyway, as database servers (both hardware and software) became cheaper the client/server model started to replace shared files databases quickly. I never used Delphi with a file database - since the beginning our targets were Oracle, SQL Server and SQLAnywhere (the latter via ODBC).
I learnt Delphi in a small software house where the owner had just switched across from Paradox, so he kept the DBs and just rewrote the forms in Delphi. He wondered why there we fewer and fewer people going to the parados users group meetings....
Of course, his code was entirely "onclick" button events, which I just accepted being a mere youngster (this was about 1997)
Delphi seemed amazing to me, coming from PDP/11 and VAX stuff with just dumb terminals.
I still have a software suite in Delphi7 i maintain now.
Yes, Pascal was a "language for students" to learn programming.
It wasn't C/C++ and it wasn't VisualBasic, it sort of sat in a bit of a noman's land, it was a well defined academic language, but "real" programmers used C or C++, if they weren't quiche munching beardies and for corporate quick and dirty prototyping, Visual Basic was quicker to get into and, as was pointed out, integrated well with Office.
Photoshop was first written in Pascal. Apple too for a long time promoted the language on its systems.
The stigma of Pascal was that actually Wirth designed it as a learning language, but soon USCD, Apple and Borland turned it into a very useful language. It became more popular in Europe and other places outside US, probably because MS had less foothold in those years outside US.
In many ways, it was a mistake to put Delphi against VB - VB was simpler and many programmers coming from BASIC had no clue about object-oriented programming and Win32 calls - they just needed to churn out data-entry forms like they did with Oracle Forms or Powerbuilder.
Delphi could do it as well, but at an higher cost and the word "pointer" scared a lot of managers, who preferred to sandbox developers to keep them away from such dangerous constructs.
Delphi was almost as powerful as C++, without all the C++ complications, and with a better UI framework - and MS knew it, and worked hard against Borland, luring talent away. Ill fated decisions from Borland itself sealed Delphi fate.
Various reasons.
I think MS being a bunch of (alleged) scumbags at the time with various tie ins and hidden features that made their products work so much better together. Or at least give the appearance of doing so in the kind of demos given to PHB's who will never have to use the tools they "select".
Personally I think the key to Pascal acceptance would have been allowing you to create pointers to procedures, so you can do command parsing by a table lookup.
Viable in C (and the key to implementing C++ in the first place) and (as it happens) part of Delphi.
Good to know there's one independent environment that MS still couldn't kill.
Personally I think the time for 3rd party tools vendors was simply over and from the late nineties on, the market belonged to the big IT vendors that predatory priced development tools because they wanted to promote their "platform".
Another ten years later, open source would also start a significant dent.
Borland maybe should have aligned themselves with a Big One in that period.
@John Smith
It is a very, very long time since I did it, but I'm sure that ISO Pascal had a trick that allowed you to have pointers to procedures. I'd need to look it up, but I'm sure there was a variable type that you could use to pass a dynamic reference for a procedure. It was very obscure, but it's there in the standard, much like the variant records that I mentioned in a previous post.
If I can find my copy of the standard, I might post back.
I used Delphi (v1 and v2) professionally but switched to Java. Not because it was "cool" but because it was far more flexible.
Delphi just wasn't a server-side language and UIs switched to the web in the early 00s, so Windows development became less common in the business world and many of the existing or legacy applications were C/C++ based as they'd predated Delphi anyway.
Then C# came along and did Delphi better than Delphi, with full support from Microsoft, and it was all over anyway.
Nor Java was, as Sun designed it first as a client-side language too - remember the Java Applet, the thin-clients, etc. etc.?
Anyway, it quickly failed to gain market share as a client tool and was quickly repurposed as a server side one, as Oracle, IBM and others quickly see advantages in a "pointerless", garbage-collected language - it matched well the then running CORBA effort - which Java eventually supplanted
It is true that despite renaming itself "Inprise" for a while, Borland never had a clear plan for the changes that were happening, with Windows servers replacing micro and mainframes (until Linux brought a copy of Unix back on them). They acquired Visibroker but did little else to expand their server-side offering and integrate it with their development tools.
Delphi got a multitier framework built on CORBA and DCOM, but it was kept half-baked for too many years, and difficult to use for lack of documentation and updates (and DCOM was complex enough by itself). You had to build the application server from scratch.
Later web services and SOAP support was added, but once again in a half-baked, buggy way. Many developers never used them.
That had a impact they weren't willingly to accept - it was no longer possible to justify the (high) price of the "Enterprise" version just because it added a few drivers for remote databases - especially when every other tool and its dog now offered that for free.
It was a lose-lose situation - developers left, prices were increased to keep the cash coming in, making even more developers leave.
Now Embarcadero is offering a server side solution to develop service-oriented application, but it's a bit late....
No, C# WinForms is still not quite as good as Delphi, except when you want to link to the latest MS technologies like Outlook 365 EWS, which I couldn't do with Delphi 7 but did in minutes with C# VS2017
Delphi's killer trick is the live database links, where you can see your sample at design time.
I still use Delphi at work to produce Windows service applications.
I can build a complete free-standing Windows Service in about 600KB which doesn't need the horrible fucking kludge that is the .NET Framework.
For instance, we have an internally built syslog server which runs as a windows service and the fully compiled executable is 628KB. A separate freestanding GUI application to manage the service and view logs is 1.4MB.
Try to produce the same thing in C# and it will be a couple of GB of code, and still need run-time compillation.
C# executables are actually tiny.
Check out https://medium.com/@MStrehovsky/building-a-self-contained-game-in-c-under-8-kilobytes-74c3cf60ea04 for some inspiration.
Keep in mind that C# shares a common legacy with Delphi. Anders Hejlsberg (as the article points out) was instrumental designing both languages.
I "converted" to C# 11 years ago and never looked back. At that point I gained 64-bit support, unicode, generics, LINQ and (eventually) async. I was skeptical about the things you mentioned, but C# isn't slow, nor bloated.
I do miss the IN operator from time to time, but I can live without it.
Knocking out a windows service (or two) is horribly easy with C#.You have been missing out.
.NET executables are not run-time compiled. Both C# and VB.Net compile to the same bytecode. It might be runtime-linked and interpreted, but for most use cases, the performance hit is nowhere near the order of magnitude that people like to make out, and unless your application is CPU-bound, you're unlikely to get any noticeable benefit from compiling down to native code using a fully-compiled language. There are plenty of use cases for that sort of thing (real-time embedded code, for example), but by-and-large, desktop applications are not one of them. If an application is slow, it's most likely due to poor programming, not the choice of language it is written in.
There are two key performance issues with some of the code: Variants and automatic memory managment. Combine variants with differing string types (unicode and so on) and the executable efficiency slips into the glacial measures of processing cycles. Automatic memory management involves the insertion of arbitary clean up methods within code loops which could either do nothing or process tens of thousands of CPU cycles, the developer really has no control over this. In a strictly event based GUI application this usually isn't too much of an issue but can be where there are tight looks and efficiency and responsiveness is required. There's a reason that almost no games are written entirely in C# but to it's credit it can integrate with non-managed acceptably well these days.
Yes, because they wait for run time to load all the bloat into memory and compile it
If you had bothered to check out the link I posted, you would have run across the following quote: "For a C# app to be self-contained, it needs to include the runtime and all the class libraries it uses. It’s a lot of stuff to fit into the 8 kB that we budget for!"
Eight kilobyte. Eight. Runtime included.
Delphi, at least the versions I used, had similar tricks. You either linked in everything, or shipped the vcl runtime package next to it.
But seriously: Does this matter to you? Do the size of the final executable impair your productivity as a developer in any way? My mobile phone, of the inexpensive variety, has 8 GB storage I think. At least until I plugged in that 256 GB SD card.
I owe a lot to Delphi, but some features ended up mattering less than I originally thought.
C# is certainly better than VB.net, but you need the correct .net runtime. A nightmare.
Do you? AFAIK, the current iteration (I think it is 4.8), is backwards compatible with anything compiled against an earlier version. IIRC, the last time there were any significant changes that may cause backward compatibility issues was when it went from 3.5 to 4.0, which was well over a decade ago. And guess what? You can have them all installed side-by-side without any issues anyway.
There seems to be a lot of hate for .NET on here today. I get that MS have been guilty of some pretty sharp practices in the past, but the .NET framework, and its languages do appear to be something they have got right. Complaints of massive exe sizes, poor performance and dependency hell really don't bear up to scrutiny.
"There seems to be a lot of hate for .NET on here today. "
I first learned programming in GWBasic in the mid 80's. Meh.
Early early 90's, I learned Pascal with TurboPascal. YAY!
Mid 90's and Windows starts looking like it will be popular one day. WinAPI is an enormous PITA.
VB 3 Makes it sooo easy and removes the drudgery.
VB 4 and 5 improve things.
VB 6 was spot on. Fast, small, lots of useful features.
Then Microsoft starts mentioning .NET.
Then Microsoft starts mentioning VB.net won't be like normal VB.
And it wasn't.
The seeds of hate were watered by tears for what we lost.
Anders Hejlsberg's first project was Visual J++. C# 1.0 has similarities. It also has similarities to C/C++.
Since then, C# has evolved somewhat. The .NET framework evolved as well.
Would you judge your current development tool on the features it had 20-25 years ago?
but you need the correct .net runtime. A nightmare.
What do you base that assertion on?
For the past 11 years I have been working on an application that consists of a server part and a client part (and some separate web service parts). We have hundreds of customers. Each customer has several client installation. Nothing big, but enough deployments to confidently say: "No, there is no problem making sure the correct runtime is installed".
Worst case you supply a link to the latest .Net (preferably core...) runtime and ask punters to install that prior to installing your app. It isn't rocket science.
With regular .net, usually the latest OS service pack took care of that anyway.
When it comes to developing an application, deployment is a relatively small piece of the puzzle.
That said, these days the bigger customers seem more walled off than ever. Only web based applications seem to get through. The framework you used is not going to make any difference there (deployment-wise).
Thinking back to 2002-2005, Delphi's biggest problem was a complete failure on improving the language. It took forever to get started on generics support. 64-bit Delphi came years later. Unicode? No go.
One of Borland's developers told me that Delphi was considered a cash cow. Every time they released a new version, everybody would upgrade, and Borland's (or "Inprise") management could celebrate another budget met. Actual features came second. Keeping ahead of the competitors was not on the radar.
I am a little bitter. I think if more of us had spent time with other tools back then, Inprise would have been forced to improve the core product sooner.
I used to hate .NET as well. It was a misplaced anger. And it took me ages to realize that for most apps you cannot squeeze more performance out of your product using a slightly better compiler. You need to work on the core logic first. Heck, 99%+ of the time is spent waiting on a database query... The world's best compiler is not going to change that. At least not as far as the typical business application goes.
That was the era they lost the course. Partly, they were making money with JBuilder and Java looked a promising market. Partly they believed they could jump on the .NET bandwagon, and probably save money on development.
I warned them more than once that a Delphi.NET made no sense - they had no control over the framework and runtime, so switching to C# would have made more sense to use .NET - while people staying in Win32 would have needed improvements, and thereby investments in the compiler, language and framework.
Instead after Delphi 7 (2002) - which was a success - they released the .NET only Delphi 8, which wasn't a success at all. It was followed by Delphi 2005, the worst release ever, as they tried to deliver both. Resources weren't evidently enough to broaden the product, and quality fell down. But they didn't understand it quick enough, and kept the Windows native version on the back burner for far too long, wasting a lot of money in .NET, going nowhere.
Especially, they were unable to understand that Windows had matured into a server tool as well, and it was no longer enough to cover desktop development only as if it was Windows 3.1. Moreover, while in the previous years they could sell RDBMS development as an "Enterprise" feature, with the advent of cheap of free database servers that was no longer a good way to ask more money from customers, and they failed over and over to justify an "Enterprise" SKU - usually adding third party tools that survived one or two releases only.
Their previous attempt to deliver a Linux tool failed too - desktop development wasn't a big business under Linux (server one would have been), and there was even more Pascal haters there, brainwashed into the K&R religion.
Meanwhile JBuilder revenues were being wiped away by free Java tools like Eclipse, and soon after web application reduced desktop application needs greatly, especially when it came to data-entry forms.
It was a perfect storm, and after trying to diversify in the application lifecycle management business, Borland came to an end, selling the ALM part to Microfocus and Delphi and other tools to a private equity fund.
"Their previous attempt to deliver a Linux tool failed too"
Kylix. Forget all the other reasons - it failed because it didn't work. IIRC it just ceased to work about the time the 2.6 kernel rolled in. Again IIRC there was some amended GPLed component in there but, of course, the amended source wasn't. And I remember trying to get some database driver code to compile which it insisted had syntax errors in but yet, oddly, compiled fine in Delphi. Then FPC and Lazarus came along and it no longer mattered whether Kylix was any good or not.
Oh really?
I've just done a release build of a Windows console app, written in C#, which comes in at 347KB, plus about 5MB for the libraries it uses (one of which is Entity Framework, which isn't exactly feature light).
Windows services aren't much more, technically, than a console app, with some different entry points. If I didn't need to do the data access, and logging, that 347KB would be all it needed to be.
Where are you getting that extra 150KB from?
Looking at another release we've got, there's a complete windows service, which is 253KB plus the same 5MB odd for libraries, so a standalone service (that doesn't do data access or logging) written in C# is significantly smaller than 600KB.
Your only valid point remains the requirement for the .NET Framework for the RTE. It's the nature of the beast for bytecode-compiled languages. You'll need to qualify your reasons for calling it a "horrible fucking kludge" - I take it you object to JAVA for the exact same reasons?
Where are you getting that extra 150KB from?
Umm, all the code that actually does stuff, over and above the basic required for a functional console app.
Looking at another release we've got, there's a complete windows service, which is 253KB plus the same 5MB odd for libraries, so a standalone service (that doesn't do data access or logging) written in C# is significantly smaller than 600KB.
No it isn't, it's 5MB larger. For a natively compiled Win32 app, there's no reason to account for the libraries, as they are already loaded by the OS, but for any bytecode-compiled language you have the extra overhead of the abstraction layer.
Your only valid point remains the requirement for the .NET Framework
Which, back in the .net 1.0 days, was somewhere around the 100MB mark IIRC. And I can't imagine it's shrunk since then. But what's an order of magnitude between friends?
You'll need to qualify your reasons for calling it a "horrible fucking kludge"
It's a virtual machine built to emulate exactly one machine which only runs on the one machine that it emulates. Sounds like a horrible fucking kludge to me. I'd also add in "pointless" if I was describing it.
I do object to java, but at least it supported multiple platforms, making it not-entirely-pointless-in-all-conceivable-circumstances.
Erm. .NET does support multiple platforms. Looks like things have moved on a bit since you last checked. The code library I'm writing in C# right now will run on a Linux back-end and link to a web front-end that may well be used on a Mac...
That's a 404. maybe try that preview button next time? I'd make some quip about attention to detail and people who use microsoft tech, but that would just be too easy. :)
And, no, There's an open source implementation of .net which was made by not-microsoft. That's not the same thing as .net supporting multiple platforms.
Or maybe you're talking about .net core, which I'm told has had support a platform that isn't windows for a whole 18 months or so. So .net came out about 18 years ago, and gained support for a platform that it wasn't already emultaing about 18 months ago. Yep, that's a great track record of support right there, and not at all likely to vanish at any moment.
And you're touting the virtues of multi-platform support for the web now? And claiming it's .net somehow?
This post has been deleted by its author
Fine. Except there's this weird thing that keeps happening: people keep changing the subject on me mid-discussion. Almost as if they had no response to my points - It's difficult to distinguish from that old, super-transparent debating technique of shifting the goalposts and derailing the discussion by focusing on irrelevancies. If I'm honest, I find it kind of... rude? That's not really the right word, it's not really that big a deal, but it's the best word I could come up with.
Thanks for checking in, though, I appreciate it :)
Glad you're chillin. Just like to check in when there's a debate - the internet's a scary enough place without people not considering each other's feelings when they're having a discussion. For what it's worth, I just checked, and the latest .NET Core DLLs take up 58MB on Windows. I'd guess it's similar on Linux and iOS. That may slightly be unwieldy of you're making a simple command-line thingy, but for the sake of the rapid construction of quite nice OO-type things, I'd say it's hardly excessive. There's 77MB on top of that if you want to make a Windows UI (seems fair for something shiny) and 17MB if you're using ASP (which is smaller than I'd expect). Python, in comparison, weighs in at 150MB, and the JDK is 300MB.
Sure, when I need heavy lifting, I'll turn to C or even FORTRAN. But sometimes it's nice to be able to just think clearly about your object model without having to worry about keeping track of mundane things like memory allocation and pointers. I think of it like being able to just get some paint from a tube rather than having to mine the rare elements needed to make the pigments myself, or buying a brush from a shop rather than finding a camel with just the right kind of hair. It gives me more time and headspace to make pretty pictures. If the application's not performance critical or calculation intensive (as most things aren't), then modern machines can easily cope with the relatively modest overhead of bytecode interpretation and garbage collection, and 58MB of storage overhead is pennies these days. It may be a little slower to run, but it's a heck of a lot faster to code.
One thing I expect we can agree on, though, is that VB(A) is horrific.
That is very nice of you :) It sure is scary. And it's missing the nuances of verbal and/or in-person communication. no body language. It's easy to interpret the tone differently to how it was meant, which can lead to things like taking offense when none is intended. Which isn't nice for anybody.
Anyway. I'm actually pretty impressed by the sizes you give. Sounds like it hasn't grown much. Which runs contrary to everything I know
Eew, ASP. Is that still a thing? You poor bastard. You need a hug.
I get about 100mb for python3 with pretty much every packaged library and addon that's available. Note that this includes multiple GUI libraries including GTK and two separate versions of QT (4 and 5), opengl, and a whole bunch of other stuff. But for a barebones install of python 3 I get 818 kilobytes.( dpkg-query -Wf '${Installed-Size}\n' `apt-cache depends python3 | grep 'Depends' | awk '{print $2}' ` | awk '{total = total + $1}END{print total}' ). There's also a 'python3-minimal' package which weighs in at 120kb.
(I'm not sure, but I may not have included docs in the 100mb figure, so that could be your missing ~50mb. but docs are certainly not necessary to run stuff, so i think it's fair to exclude them)
It's difficult to compare this apples-and-apples. One could scream "less than one meg!" shrilly, but I expect relatively few things are going to be able to run on that. Basically you just have the standard library. TBH I don't even really know offhand what that gives you because I tend to just install it all on my machines (which are invariably development environments). I could look it up, but effort. I expect that in a real-world scenario, you're going to have a bunch of the libraries installed, so perhaps closer to the 100mb end of things than 1mb. But very rarely would you ever need it all. I'm very dubious that there are many python programs out there that would need even 58mb. Certainly not with equivalent functionality. In particular you're only going to use one of gtk, qt4, and qt5 for any one project. (qt4 and qt5 bindings weigh in at 15mb each. gtk3 is 635kb). And that's broken up into 88 separate packages, so it's much easier to do a minimal install of just what you need. So I'm willing to accept that .net and python are maybe within the same order of magnitude for real-world usage, though I would assert that python is much more flexible and granular and allows only installing what's necessary to get the job done in a way that's not possible with .net.
(You mention "if you want to make a Windows UI". Is that cross-platform and "windows" is a euphamism for "GUI", or is it windows only and therefore the thing isn't really cross-platform? How many gui libraries has .net been through now, anyway? I seem to recall someone bemoaning some fancy new-and-incompatible way of doing GUIs a while back. I'd also be curious to hear about the experience of cross-compiling for a linux target)
But we were talking about Delphi, not python. I already said I object to java so I'm just going to go with your 300mb figure. it looks about right.
I don't have a windows machine handy these days to test actual Delphi on (though I do have my delphi CDs somewhere still), but I can attest that it did produce very small executables, and there was no runtime. Also it only compiled in what you needed. A Hello, world would be very very small, and a useful application pretty small. I recall working on a few large-ish programs which were on the order of 1-2mb. We had one which was 150k LOC and the executable was something like 3mb IIRC. There was probably an embedded bitmap or two in tall hose figures, by the way. The whole thing bundled with an installshield installer with data files and whatnot was definitely under 20mb, maaaaaybe 35 by the time you decompressed it. We're talking ~25% the size for my complete application, and you haven't written a single line of code yet. Approaching an order of magnitude.
I fired up Lazarus and quickly compiled the last thing I was playing around with there, a little opengl thing. Really not large. on the order of 100 lines. It produced a hideously large executable - 20mb. But again, that's the entire thing. No runtime. Everything included in the executable. I expect that wouldn't grow much until I had a very large application. And Lazarus is not delphi, doesn't quite do all the same magical things. But we're only at ~15% of .net here.
Have you worked with Delphi? One of the most beautiful things about it IMO was the really nice place that it found between speed and power and having to deal with things like memory allocation and pointers and stuff (you basically never *had* to deal with pointers but you could if you wanted to). It has a nice string type that you don't allocate or free. Dynamic arrays weren't particularly painful IIRC (it's been a while since I used it seriously). You do have to use create and free when you're working with objects that you instantiate in code, but in my experience that's rarely problematic because object lifespan is pretty well-defined in most cases (yes, there are exceptions, but generally a little bit of good practice can make a lot of that stuff a non-issue). I found Delphi to be a language where you could pretty easily just think clearly about your object model and get stuff done. And it had some really neat ideas and conveniences that .net...shall we say..."borrowed", almost certainly due to the defection of Anders Hejlsberg (things like anchoring controls at left/right/top/bottom to have them resize or move as your form resizes, and seriously awesome data forms). And delphi programs ran FAST. It wss suitable for moderate-to-heavy lifting. I would use it to do heavy-ish lifting in a heartbeat. I'd choose it over C unless I had to. I'd absolutely choose it over .net, which felt so much like a horrible kludge that it pushed me to move to open source languages. As I said elsewhere, though, these days Delpih does feel a bit dated and verbose with its declarations sections and begins and ends if you're coming from something like python.
TL;DR: Delphi has .net beat on size by a pretty serious margin. And I remain unconvinced about how good/complete .net core's multi-platform support is and whether it can be trusted to stay around for the long-haul and not get deprecated in a few years.
One thing I expect we can agree on, though, is that VB(A) is horrific.
Haha. You know, very early in my career when the Dunning–Kruger effect was in full force, I used to love VB and defend it against its detractors.
These days I think it's pretty horrific.
"these days Delpih does feel a bit dated and verbose with its declarations sections and begins and ends"
As of the latest Delphi 10.3 Rio, variables can be declared in line (at last!). It also supports type-inference, which is very useful when using Generics.
I've not used Python in anger, but I find typing begin/end (actually beCtrl+j <enter>) no slower than { } (shift-[ shift-])
And it is much easier to "read aloud"
the autocompletion stuff is a really good point, Delphi always had quite a nice, helpful IDE. But on that front, many IDEs will give you the closing brace for free, so to be fair it's really just shift-[.
I'm sure that if/when I decide to go back to Delphi/Lazarus I'll get used to it in short order. I'm absolutely not saying it's crap, I still rank Delphi as one of the nicest languages and development environments I've ever used. Just giving my impression as someone who hasn't used it very much lately.
Firstly, I'd like to congratulate you on the excellent and appropriate use of an en dash in Dunning–Kruger. Someone taking the time to use an oft-overlooked punctuation convention pleases me.
In answer to a few of your questions - yes, the GUI is only for Windows, sadly. There is no built-in support for GUIs on other platforms, though there are a number of third-party solutions. ASP has moved on a little to become ASP.NET, and isn't quite as evil as it used to be. I guess it's as close to a built-in cross-platform GUI system as .NET core gets (which isn't very). As for compiling for Linux - one good thing about the system is that its built-in gubbins (or bloat, if you prefer!) means an identical DLL can be used on any platform. I'm making a class library to be referenced from an ASP.NET front end, and all I have to do is compile it once, whatever system the back end is going to live on.
For console apps, it's possible to build a platform-specific thing that includes all the libraries with it (in the same install location), meaning there would be no need to maintain a .NET Core installation separately on the target machine. This is, I admit, a bit messy; you could end up with the same libraries installed multiple times in different places for different applications on the same machine. And as far as I can tell, it doesn't let you take only the bits you need. So that's an extra 58MB for every application. (If someone else knows better about that, then I'd be interested to find out how you do it!) But if your machine is generally doing .NET things, then the Core libraries only need to be there once, and my DLL on it's own is a few tens of kBs. Much larger is the data file I need it to access, but that can't really be avoided.
As for trust and support, I think that as of .NET 3, people in general are getting quite enthusiastic about the whole thing. I think if MS made a random decision to cut it off (as they may be apt, and have admittedly done with other things), then my hope is that it would be continued/forked by volunteers, what with it being open source now. For the moment, they seem committed to moving everything into it and (fingers crossed) letting the .NET Framework die. .NET Core 3.1 is an LTS version, supported for three years, which seems vaguely promising. I'd be happier with five, though.
As for Delphi, I never had the pleasure. I knew people in the late '90s who loved it, but back then I wasn't really developing in any useful sense, so I never picked it up. I cut my teeth on BBC Basic, moved on to VB, and danced via a circuitous route to other languages. This will prove controversial, but my favourite language to code in, entirely aside from the large VM required to run it, was Smalltalk. I spent five years as a dev using it for a major (multi-gigabyte) application (meaning the size of the VM was neither here nor there), and it was just an absolute pleasure to debug. Ooh - there's an exception, no matter, here's the piece of code it happened in with the problem highlighted - I see my error - there - ooh, what value is that variable - oh, that should fix it - go - oh, look, it's running fine again now without re-starting/re-compiling/even missing a beat. It was slowish in terms of mathematical calculations, but we used FORTRAN DLLs for the back-end of things like finite element analysis. I still miss it. If written properly, it's also wonderfully self-documenting. I could look at a method written ten years ago (seeing again, at a glance, who last edited it and precisely when - useful sometimes for asking them what the hell they were thinking, and added a degree of accountability) and understand exactly what it was doing at a glance. Good times. Don't know why it's not more popular.
Well, I'd love to take credit, but I'm ethically obliged to confess that I don't deserve the praise. I wasn't 100% sure that Dunning–Kruger was the name of the phenomenon I was thinking of, So I asked wikipedia, and while I was there I got lazy and copy-pasted the name to be sure I'd avoid spelling mistakes. :)
However I do (sincerely, not mocking) commend you on your commitment to pedantry in even noticing. I absolutely would not have. Truth be told I didn't know the difference in usage until you compelled me to look it up just now. So I learned something today. yay!
yes, the GUI is only for Windows, sadly
Which pretty much kills the claim that it's cross-platform (dammit, now you've got me pausing to consider whether it's correct every time I type a hyphen) for me. If I was going to use .net I would only consider using it for writing GUI desktop apps, because I think there are better tools for all other use cases (I mean, there are better tools for GUIs too, but if there is one area where perhaps .net might have an edge [in terms of making a dev's life easier] it would be at rapid development of desktop software).
Is the GUI library a part of .net core, or is it something else? I'm guessing it's something else? And not open source? That pretty severely limits the usefulness as far as I'm concerned. Yeah, technically it's cross-platform, but they've ripped out all the interesting parts to make it so. If MS is so in love with open source these days why not free the gui library, too? My reaction to this is "a-ha, so that''s the catch, they've only open-sourced the uninteresting half of it") I'm coming right back around to my previous use of "pointless". Python and Lazarus and even the reviled java can all do it better and easier, not to mention more safely (from an "am I going to have to rewrite this in 3 years because of an incompatible change or the tech being deprecated or whatever" point of view).
Which I think exemplifies the attitude of a lot of people towards anything MS does and in particular this whole "we love open source" shtick. They have such a long track record of evil that it's going to take a long time doing good before somebody like me is going to even consider trusting them. I remain extremely, extremely skeptical that this is anything other than a particularly slimy "embrace" phase of that famous old strategy - I don't even need to tell you the names of the other two phases I expect to be a few years down the road once this has a userbase in the server space, do I? (no, not "???" and "profit")
And given the track record, I don't think you can reasonably say "oh you're just being paranoid". Maybe in a decade I'll start thinking about throwing a little trust their way. Maybe.
So, sure: .net core is now cross platform. Asterisk. The emulation layer is now able to run on a machine other than the one it's emulating. For the moment. nearly 20 years after it came out (and now that that machine is no longer the dominant one). After they ripped out the (very slightly) interesting parts. I think my initial statement holds water, even if it is "lightly" sprinkled with hyperbole and sarcasm and disregards this latest ploy (if that's the right word. It's not impossible that my assumption is wrong. Just statistically unlikely).
ASP has moved on a little to become ASP.NET, and isn't quite as evil as it used to be
I actually worked with early asp.net, too. It got worse when it became asp.net IMO
means an identical DLL can be used on any platform
Oh right. Bytecode. duh. And I totally knew this, too, I've seen dlls in unity games on Linux a bunch of times. That is kind of nice. But nothing that Java wasn't doing in the 90s.
it's possible to build a platform-specific thing that includes all the libraries with it
Also kind of nice
as of .NET 3 people in general are getting quite enthusiastic about the whole thing
I've heard a couple of people tell me about how .net is popular in open source circles. But I've never met (or, to be fair, discussed this with) an OSS person who didm't share my skepticism.
have admittedly done with other things
You could just hear me getting ready to say "VB6", couldn't you? ;)
it would be continued/forked by volunteers, what with it being open source now.
I'm sure it would. But MS deciding to cut it off isn't really the real concern (granted, it is the only one I outlined, that's shorthand for a bunch of ways it could go). The real concern is when ".net core Plus!" comes out (extend). And does a couple of things a little better. And isn't open source. And oh btw it's not cross platform, either, guess you'll just have to switch those machines to windows if you want this (extinguish). We built a handy tool in azure to help you do just that. Or, if they're playing the longer game, it starts out as cross-platform and then "certain other environments" get dropped once it has a userbase.
Smalltalk
I think I might have seen it on a mac OS ~7 machine back in school. Never had any other exposure to it.
it was just an absolute pleasure to debug
Debugging is one of the things I loved about VB back in the day. The ability to make a change in code during break and then grab that execution arrow and move it back or forward to skip or re-try an operation was awesome.
That's akin to compiling a Delphi application with package support. Frighteningly small application .exe sizes, with frighteningly large external package files (DLLs, in practice). .NET applications are largely the same.
The curse of .NET applications is not always the individual installations of various versions of the .NET support files (effectively DLLs) but how many sets of these there often wind up being installed on any one given system and therefore the multiple copies of these that exist on a system. it's understandable given how Microsoft never implemented a central library management system in the OS but also important in some ways given system security.
In any case, when it comes to loading up external libraries, and APIs, where does one draw the line as to what is considered the application size and not? In some abstract manner, the classic hello world in Windows 10 is roughly 4GB because it requires Windows 10 to be installed...
> Windows 10 is roughly 4GB
Since when can you fit a Windows installation in "just" 4 GB? Last time I checked minimun disk space usage for a clean install was in the 20-30 GB range, and I cannot imagine it has shrunk since. And .NET is part of the problem, not the solution. A monstrosity wrapped in an atrocity.
I think he was referring to memory usage. 4Gb sounds about right for Win10.
After all, when it comes to running programs, it's the bits that sit in memory that matter, not the bits that sit in storage. Although with the rise of the SSD even that becomes a little fuzzy, given that you can park a lot in virtual memory if cutting-edge performance isn't your main goal, and hardly notice the difference at the user end.
Admirable and sure I do subscribe to the "if it ain't broke" mindset but come on, this is just asking for trouble.
I've lost count of the number of times I've put systems on life support because app owners and devs won't move on. We still have a system where I work that's running Oracle v7, Informix and Solaris 8, due one application that 3 users in the company demand we keep running. We're completely unsupported and only 2 people know how to keep it running now. The company that supplies the app went out of business 6 years ago and it took 3 months to get our hands on the source code so we can store it just in case we need to ever try to recompile it!
Things needs to move on, stupidly keeping legacy code and apps around just for the sake of it and denying yourself access to the latest tech is just narrow minded and to my mind, selfish to those who have to support it when it starts to crumble.
I learned to write DOS batch code back around 1986, I loved seeing how far I code push batch code. The largest DOS batch script I wrote was around 2000 lines long and controlled the company's main overnight batch processing. These days I use Powershell and C# to write batch processes on a 3,000 server MS shop. Powershell is incredible and so adaptable, comparing batch to powershell is like comparing the first boneshaker bicycle to a modern 750cc bike.
Things change, don't change for the sake of it of course but there are good reasons to change and move on, take advantage of the latest developments and the latest tech is designed to allow you to save time and spend more time learning fun new stuff. I'd rather write a 10 line Powershell script that let's me deal with 750 windows hosts in a single call rather than fight with 250 line VB or batch scripts and hours of wrangling.
My first paid-for application on a PC was written in Turbo Pascal running under MSDos 3.3. Back then we only needed 512Kb of memory and a couple of floppy disks to make a PC useful. TurboPascal compiled fast and produced single executables. I also used TurboC/C++ too. Borland was a real pioneer that is often overlooked in my view. Sadly, I still have the disks....
Later on I used Delphi to write Windows applications and it was a great product and reasonably priced. I stopped upgrading after 2009 as it's future was uncertain with each new owner and I was using Linux platforms more often.
I did look at upgrading in 2013 but Embarcadero has really stiffened up the prices. The cheapest option is now £1399 initial payment with £399 per year after that using the, now popular, subscription model.
Thankfully the open source Lazarus fulfils my needs at a much more sensible price!
"The cheapest option is now £1399 initial payment with £399 per year after that using the, now popular, subscription model."
Buy and subscribe!
The Borland model IIR was buy it and install wherever you need so if you had an office desktop and a laptop you could install it on both. And no fuss about how distributing the compiled application. What times we lived in!
Unluckily as customers became fewer, Embarcadero decided to up the prices, despite most development having been moved to Ukraine. They also attempted license changes to force developers to move to more expensive SKUs, even if most of them backfired.
Now IIRC you can no longer activate perpetual licenses of older version unless you have an active subscription for a current one, something that is probably illegal in some jurisdiction - but those in charge now looks to have little regard for customers. Just this ransom attitude doesn't invite new customers at all.
Unless you are a shop still churning Windows desktop applications, the price became too high for what could be a "secondary" tool useful when you have to develop quickly some Windows application, maybe as a utility or a tool for other applications.
The technology behind Delphi is still good and useful, unluckily it's now in the hands of a company that I would not have business with.
For the Delphi people on this thread who don't know yet Lazarus, this link will take you to screenshots of what can be done using Lazarus:
https://wiki.freepascal.org/Lazarus_Application_Gallery
We have several developers working with Lazarus and we use Lazarus and Python to produce WAPT, a sysadmin tool for software deployment (https://github.com/tranquilit/WAPT).
We've realized that younger devs who have learned Java or C++ in school adapt very well to Lazarus and FPC. They can become very productive very quickly under the guidance of an experienced Delphi mentor.
Vincent
The direction of Delphi went immediately downhill the moment that some "genius" decided that the only direction was "enterprise". It was pointed out that this was certain failure within moments of it being announced at some conference or other that I attended - I'd like to say that it was me that raised me but I was beaten the this.
Somehow they utterly failed that the popularity and therefore viability of a development environment is massively based on its availability, particularly to student, hobbyist and other beginner developers. While there may be a very brief spike in exhorbitant license fees, users will move on to other platforms: and they did.
Other things that contributed to Delphi's failure were the strange desire to pretend to be cross platform using a very weirdly licensed and out of date kludge system that produced non-native applications on all platforms.
A Delphi anniversary really deserves Verity, especially one this important!
Unfortunately the job market made me move on to C#, among other things. Thankfully Visual Studio has improved a lot in the last 10 years but I'd still rather be using the Delphi IDE and tend to think in Object Pascal.
There were some issues with VB, though. It was an interpreted language, which meant applications were dependent on installing a runtime, and it was slow in comparison to C or C++.
No. VB wasn't interpreted, it was compiled to pCode and executed from there. It isn't as efficient as compiling and linking to native code, but it is faster than interpreted code.
I also wrote several libraries to harness Win32. It wasn't integrated, but it was, for the most part, available, if you knew what you were doing.
Microsoft also upped its game. VB's compiler improved
We actually had Borland come and demo the product to us at work (I was at Cap Gemini at the time), but as the article says, most corporate customers wanted to stay with Oracle or Microsoft products.
Erm, yes. My point exactly...
Tilt.
"Delphi was more of a niche product, loved by independent developers but less prominent in corporate IT departments."
I had a client who'd used Delphi 6 for in-house projects. Just before I left they switched to C# for a new project. The size of the team started growing...and growing...and kept growing. I dread to think what the difference in productivity must have been although maybe their self-styled architect might have had a bearing on that.
Delphi's form designer is the best designer I have ever used.
WinForms appears... I have nothing nice to say about WinForms. (simple test: Press TAB in any user interface that has more than a dozen input controls on it: If the tab order works as expected, then chances are that the thing was done in Delphi, not bloody WinForms)
WPF solves many issues (such as the large/small fonts scaling nonsense), but it is wonderfully complex. There is nothing "Rapid" about WPF. Productivity wise a total disaster (at least initially). The data binding is brilliant, but I'd be surprised if Delphi doesn't offer that as well by now. And if you don't follow a strict MVVM architecture you'll end up with that much more spaghetti.
Some time back in WinNt days, I discovered Delphi. I didn't know Pascal so I had to add that on, but once I was into it, it became my main language. I loved the fact that you could deliver quite a large application as one exe file. It was the only thing I regretted leaving behind when I switched to Linux back in RedHat 7.x days.
I was quite surprised today to see that it is still available, and apparently in cross-platform, but... Going to the website, I quickly found that the cost of the compiler (subscription naturally) is insane.
No thanks. I will stick with Macos, Linux, C, and Perl.
You should at least warn us if you're going to use language like P*w*rB**ld*r in an article.
Some healthy robust Anglo-Saxon is of course expected on El Reg, but we surely have SOME standards here? I mean, some people have had to work with P*w*rB**ld*r, and are still scarred.
(And others have had to work with products built by in-house P*w*rB**ld*r developers, and are more broken than scarred...)
We *still* have production P*w*rB**ld*r apps in use. In 2020.
And while I never used Delphi, I made extensive use of Borland C++ builder which had the IDE and VCL fully implemented as classes. Despite it's GUI emphasis, I wrote server apps with it and made extensive use of the VCL classes for backend processing.
The most significant was a OCI web app that processed up to 3m calls a day until we migrated to Linux in 2011.
The delphi GUI library (VCL) is still very much in use today via the C++Builder product Borland -> Codegear -> Embarcadero.
They do however keep adding fluff to it. It reached its pinnacle at around Borland C++ Builder 5/6.
Some trivia. C# has no relation to C or C++. The 'C' character in it actually stands for Cool#. How much of a manky name is that? A manky name for a manky language.
BCPL was great, in that if you knew what you were doing then you could do anything that could be done in assembler and have it fast, reusable and portable.
Typical compile errors in BCPL (if you got any) were along the lines of "Error near line X" and 99% of the time line X was not where the error was. That being said having a single type and redundancy in program control let you code exactly how you thought. Every other language requires you to keep to their rules where BCPL had the bare minimum of its own and everything else was your choice. Great if you knew what you were doing and didn't have time to use assembler but quite a step learning curve for any new developers who increasingly missed out on low level programming.
C++ was, well, the worst of all worlds, it gave up BCPL freedom in order to make it seem accessible to those that didn't understand low level coding. Yes it is easier for new people to pick up but since BCPL fundamental assumption was that you knew what you were doing and this was carried over to C++ but hidden behind types and coding styles means then coding fails are frequently hidden until after code is released. Welcome to "professional" coding ever since.
I often wondered if one of the reasons that BCPL was seen as needing an update was that it still used oldeworld CAPS which became a promoted hate in computing once case became optional. That in the right hands it could make a system do anything you liked and without the programming language getting in your way seems not to been considered important.
I did a bunch of (IMHO) really good work in Delphi when it first came out, replacing previous apps written in VB. It was a revelation at the time, dropping that awful BASIC dialect, but my heart definitely belonged to C++ at the time.
When C++ Builder came around I jumped across quickly, and it was my go-to tool for many years until I moved entirely to Linux at home and lost the ability to choose my own dev tools at work.
Wasn’t the language or IDE, it was Borland marketing. I was a fan of Turbo Pascal, and used Delphi for my own work. The company I was working for at the time got Borland in to demo Delphi as a possible replacement for VB, but they didn’t understand the product they were competing with (one of the senior devs asked “how do you do control arrays”. These aren’t needed in Delphi as the instance of a control that is clicked passes a reference of its self to the selected event handler, which makes it simple for many controls to share the same event code. The rep didn’t understand this). The second problem was that Interbase, the SQL backend of choice, had to be paid for whenever and however a product was shipped (even a limited user demo copy of an app). Microsoft let you ship a limited version of the backend database for free, and pay licensing costs only when you needed to scale it.
The result was that it was sidelined and the rest is history.
Interbase was never the SQL backend of choice. Interbase was mostly the red-headed stepchild Borland got when it bought Ashton-Tate (which got it too without understanding well what to do with it) to get dBase. A copy was present in most releases, but they never promoted it too much. It had some sever limitation that were fixed not long ago.
Yet in VB times, all you could ship for free with a VB application was the Jet Engine - SQL Embedded or whatever came only far later. Ironically Interbase had a small footprint which would have made it a far better embedded RDMBS.
Actually, the name Delphi was the project codename referring to Oracle ("Where do you go to talk to the Oracle? At Delphi!"), as Oracle was the main database target. Delphi database classes and controls had special support for many Oracle features, i.e. nested tables. It had good support for Sybase/SQL Server as well, plus DB2 and Informix, but I never used the latter two so I don't know how well they were supported. Just, later, when the BDE and its "SQL Drivers" were deprecated, Delphi was not able to deliver a well working replacement, and support for "new" databases like MySQL and Postgres wasn't comparable to the previous one, and it didn't help to make the product more popular too.
Anyway, the Delphi name stuck, and made marketing more difficult. Not many know well Greek history and mythology.... and still they could wonder what it has to do with Pascal.
did not support object-oriented programming
VB did have classes. It was possible to do OO with VB. Just not pretty. Though it's possible this was added in a version >3, I don't recall the timing offhand.
Unfettered access to the Windows API
Unfettered? No. Access? Yes. If you knew what you were doing and had the documentation you could roll your own windows API calls in VB. Doing just that sort of became my speciality very early in my career, I was doing all kinds of things which conventional wisdom said "weren't possible in VB". There was even a tool to help with it included with certain versions/editions. Again, it wasn't pretty (not much about VB was) but it worked.
Delphi was seriously great, though - coming from VB to Delphi where you could just use the windows API was a real joy. I loved it immediately. I still consider it to be one of the best tools I've ever used. Such a great place in the RAD / speed / simplicity / capability tradeoffs.
It is kinda difficult to go back to all those begins and ends and declaration sections and whatnot from something like python or ruby, though. Seems really verbose these days.
Oh, yes, Good point :)
I was pretty new to the idea of OO when I still used it, and I haven't really used it since. Memory is hazy, apparently. I did like it back in the day, but going back to it to write a thing in msaccess about 5 years ago was pretty nightmarish.
The company I worked for back then needed a new accounting system and couldn't use off-the-shelf solutions. I wrote an entire accounting and customer service system in Delphi and loved that language. The inheritance made it simple to modify default control behaviors to get them to do whatever you wanted. The full SQL integration was very well done, and Delphi also integrated into MS Office easily, so it was simple to control Office apps or output spreadsheets or whatever from Delphi. It really was just about a perfect product and worked with everything we used. I was very sad to see what became of it later on.
There is at least one vendor of Electronics EDA that used (and still uses) Delphi for their tools. Apart from the user interface parts, these tools are, in reality, very complex databases and need to be managed as such.
Some other tools use the ODBC route (so you use the database of your choice and simply tell the system which one it is).
I used Borland Pascal back in the day, then Delphi. I was quite taken with C++ Builder (which brought the visual form builder to the C++ development environment) and wrote many a program with it although it certainly had it's quirks (particularly with callback naming conventions) but it was still a major step for the time.
Coming from a background of self-taught GWBasic and some horrible old version of C my dad had books about in the 90s, encountering Delphi in my school computer-room in my early teens was something of a revelation compared to QBasic and BBC BASIC which were the other options available.
It gets its flack but especially compared to what else was around at the time, C#/.Net/VS really is a wonderful development platform and it is pretty amazing it was able to supplant Delphi.
Wasn't C# masterminded by one of the top Delphi people, or based on PASCAL, or something?
Anders Hejlsberg created Turbo Pascal and later Delphi. Then Microsoft lured him away from Borland (he was not the only one, many top Borland developers ended in Microsoft)
C# was designed to go after Java, after the Microsoft attempt to make its own version of Java failed when Sun won in courts, so it took the same approach of using a C-like syntax. Yet it borrowed some features from Delphi as well.
Loved the mention of Clipper in a couple of the comments.
.....and Clipper is still alive and kicking here at Linux Mansions....in the form of Harbour 3.2. All the dBASE databases and quite a lot of the database code from the late Eighties and early Nineties is still in use.
However, there's a tiny change of emphasis. The Harbour compiler is still used to handle database code, but GUI front ends are written in Glade and Python3.
And as to the comments about licence costs.....counting the cost of Fedora 31, Harbour 3.2, Glade and Python3.....I can't get much above "Just the cost of do-it-yourself support".
Clippers great tricks were, very basic OOP in places. Replacable Database Drivers (If you didn't use Advantage your software was born to corrupt indexes.)
I used to like the VGA mode in 5,3B and managed to make a DOS application pretty usable and good looking even in XP days.
Oh and EVERYONE had Blinker
I learnt Pascal at Uni in the late 70s and then used Compas Pascal; the precursor to Turbo Pascal in 1984. 36 years later for my sins I'm still working on Delphi development as it underpins commercial PropTech products. Two products, each about 1.3 million loc and way too big to ever convert to any other programming language. They've been modernised by adding C#/WPF on the front end but the bulk of the products are still in Delphi and now also in 64-bit.
And more recently I've made dynamic virtual channels (DVC) work, completely in Delphi after rewriting 1500 lines of C++. DVC is a Microsoft technology that lets you communicate between a program on your computer and a program running in an RDP session. Delphi is still very versatile and the compiled code is fast. It's just a pity that the desktop development job market is a bit dying these days compared to Web and mobile development!
All application written in Delphi 25 years ago still run perfectly today after just a recompile. In today world where Javascript framework are obsolete every 6 months, using Delphi is a big win. Recompiling takes few seconds (usually less than 10). Yes you can compile millions of lines of code in just seconds. You can save hours during a weeks. Tests run quickly, they compile and are executed quickly. In today world it is a big win. You do not need .net, you do not .net core or whatever you may call it (.net nano, .net atom). You do not need .net at all and it is really cross platform, with a GUI or not and no need for rewrite. You can write micro services, you can deploy with docker, it is highly scalable.
And you know why Delphi did not change that much? it is is because it was well design, right from the beginning.
That is true, you can write monolithic application in Delphi, and many monolithic application has been written in delphi, but you do not have to. We all know that monolithic application are bad. These monolithic applications are hard to maintained. But wait, Delphi is probably the best language to develop component based application, and component based application are easily maintainable and can be written by large team if you need it. Just split you application in several bpl, put things beyond interface (things you can do since Delphi 3) and your application are likely be well designed and maintainable.
I bought a copy of Delphi 1.0 at the Windows show in Olympia on the day it was released. I took a day off and spent my own money (300 quid or so).
Went straight home and rewrote the C++ (OWL!) application that we had been trying to get stable for a few weeks. We had been trying to write a replacement for the Clipper application we supported.
Building the app took me the weekend and it had more features and was rock solid. When I showed my boss on the monday he wrote me a cheque on the spot for my copy of Delphi. Only issue we had was with the horrible Foxpro/dBase drivers. I ended up (on another weekend a few months later) switching to Successwares NTX driver - worked perfectly first time.
Funny how so many of the Clipper tool writers went to Dephi.
I have had exposure to most of the various databases, found bugs in some, I could crash some on demand.
Was a tester for an AS400 database engine, best described as slow.
Just had three different tools up using our data.
Advantage Data Architect (part of server software in Dephi)
My own DBU (multi RDD version recompiled with Alaska XBase++into WIN32 Console)
Our own software in Visual Objects.
If I wanted I could go to an XP PC and load up our last gen software.
All playing nicely.
Turbo Pascal was great. I remember buying version 1.0 for $99 (they claimed "the fastest compiler on the planet, period!" - and they were right). Delphi was incredible, too. I was originally a hardware designer and I got into software because programmers NEVER got drivers right. I was fluent in over a dozen assembler dialects. I started with K&R C (full of bugs). These days I only develop in C++ (Microsoft). Delphi and C++Builder were wonderful products (except for pitiful Boost support). I would still be using those products if it weren't for Embarcadero, who lied constantly to get subscription money. They lied about and missed their 64-bit deadlines so many times that I finally had to ditch them if favor of Visual Studio (has it's problems but at least they didn't lie to me and did deliver on-time).Certainly, Delphi and c++builder had the best RAD capabilities out there. Too bad Embarcadero had to ruin things....
"Object Pascal was Borland's own language, with full support for inheritance."
Eh, no. Clascal, an object version of Pascal, was the main language on the Lisa in 1983. Pascal was the principal language on Macintosh from its launch in 1984 on through the 80s, and the multi-volume Inside Macintosh, the bible of Mac development, had its APIs and examples were all Pascal.
I LOVED Think Pascal with its wonderful editor. When Metrowerks' CodeWarrior came out I happily switched for its sheer power. In 1998, I ported my principal analytical apps to Windows (while still maintaining my Mac versions), and I chose to develop in Delphi due to the ease of porting my Pascal code. The user interface was created within Delphi, but principal calculations were conducted by a separate DLL which was written in CodeWarrior. CodeWarrior ran on either Win or Mac, and could create Mac apps, Win apps or Win DLLs using either development platform. So, I could write in CW for the Mac, and still in CW generate a DLL to be used with the Delphi apps. Sweet!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
