Hacker News new | past | comments | ask | show | jobs | submit login

For me (Delphi programmer until around 2001), there were several more important factors in the eventual failure of Delphi.

First, at the time Borland (or, briefly, Inprise) tried to move into the "enterprise" market, with expensive, nebulously defined "middleware" products like Midas. This is why they aggressively pursued failed tech like CORBA. It was a disaster, and had nothing to offer those who wanted to get stuff done. They also clung to BDE despite the fact that ODBC was much more mature and fast. Serious users used some ODBC components that someone built.

They forgot that Delphi was a tool to build great apps in, and didn't figure out that Delphi was great on the back end. It was all about GUI apps, but it turns out that it was incredibly productive for non-visual apps, too. With a better strategy, Delphi might have competed with Java, but they missed a lot of what made Java great in the beginning. Support for web development, even sockets, was near-non-existent.

One problem with backend apps in Delphi was that it was painful to work with C libraries. One huge thing they could have done was to make it trivial to generate C bindings, but the best they had was a rather terrible tool to convert header files to Pascal files. (I wrote a much better tool that understood macros and could even translate complex C++ headers like Microsoft's MAPI, but I'm sure Borland could have done even better.)

Delphi also tried to pursue COM (in addition to CORBA) as a distributed programming glue. Delphi 4 even had a typelib editor (which was buggy and horrible), which you needed to use to get any performance at all; the automagic "OLE Automation" support built into the language was awesome but really slow. It turns out that distributed programming with COM was not very mature, and trying to use it with Delphi was painful (though possible).

Borland also got distracted by Linux (not a good fit for a closed-source company) and by C++ (C++Builder could never be as successful as Delphi since they didn't control the language and had to extend the C++ compiler with custom directives to make it work the way Delphi did).

In the end, it's best summarized as: Lost focus, didn't realize what they had, pursued the wrong markets. Being stuck with a proprietary language didn't help, of course.




I agree with everything you're saying here except for one thing: Delphi was amazing for COM programming. In fact, it took me years of reading complaints about how complicated COM programming was (and thinking everybody is nuts) before I first saw an example of COM done with C++ and realized what people meant. We were doing a ton of COM / COM+ programming in Delphi 5 and we've never had any problems.


Having done a ton of COM programming in Delphi, the problem wasn't that it didn't work that well — the language integration was fantastic, and things like QueryInterface and AddRef/Release were done for you — but the support wasn't quite good enough.

The typelib editor, for example, was atrocious in Delphi 4 (maybe it got better in later versions), and if you wanted to use a COM-based library (MAPI, TAPI, OLE DB, etc.) you couldn't do it without the headers. Since so much of COM came from Microsoft, it felt like fighting a losing battle against the official way of doing COM programming (Visual C++, at the time). Ironically COM programming seemed much worse in VC++, given the lack of language integration.


Ah, I've never used Delphi 4; I skipped from 2 to 5 and then 7 (the last one I've used). I've never had problems with the typelib editor in D5.


Agree.

Funny thing is that now, around 20 years later we have .NET going fully AOT with .NET Native (kind of Delphi experience) and C++/CX with XAML (kind of C++ Builder experience).




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: