Slashdot Mirror
Delphi Turns 10
NavySpy writes "Today is Delphi's Tenth Birthday! The launch of Delphi 1.0 occurred on February 14th, 1995 at the Software Development '95 conference at the Moscone Center in San Francisco. Numerous links are commemorating the event, including a recorded interview with Zach Urlocker and Gary Whizin, members of the original management team. Zack's original Product Definintion document is here. An attendee at the original event reminisces about the launch."
The combination lets developers whip up full-featured GUI apps in minutes. This concept was hyped as "RAD" -- rapid application development: Create a new form. Put a tabular editor widget on it. Put a data source component on it. Hook the table widget visually to the data source. Now you have a table containing your database's data.
Delphi later wooed COM/DCOM and CORBA, and added these two systems as first-class citizens in the language, similar to RMI or Distributed Ruby -- suddenly it was a snap to write an app whose objects lived in a separate process or on a remote machine. It was part of an ill-fated strategy to capture the "middleware" market.
Borland's Java product, JBuilder, tried to be "Delphi for Java", but failed to live up to the "just works"-quality of its parent product. Even later, Delphi has gone after .NET, but I stopped paying attention long before that.
Delphi could have been big. It was a masterpiece in engineering. Sadly, Borland shot themselves in the foot in several ways:
Part of Borland's fall from grace may be blamed on greed -- greed and the dot-com era. They were originally a development tools company. But even after the Philippe Kahn-era attempt to compete with Microsoft (Quattro Pro, etc.) failed, the execs made a similar mistake by going after the gold mine that is the enterprise consultancy business.
They renamed their company Inprise, touted a bunch of half-assed products, and drowned their web site and communication in buzzwords about enterprise middleware, B2B, application servers and other stuff that were the obvious product of executives, not visionary engineers. They were not just a product company any more, but now also a "solutions" company. And rather than going after common-sense technologies, they went where the hype was. Their new products were also not up to the quality that customers knew and loved from previous products. In the end, they had the arrogance suited for the business, but not the savvy. So they failed.
Borland have refocused in recent years, and the effort is commendable, but they have not regained their former reputation. For one, I don't know anyone who uses Delphi anymore.
Perhaps most sign
Things that are written in a "weaker" language, such as Visual Basic, tend to have the top level or the parts you are having your newbie app developer write in the "weaker" language, and they tend to have an "industrial-strength" language (such as C++) "under the hood." Visual Basic consumes ActiveX controls that are written by specialist developers in C++. Now in later versions of Visual Basic you could write ActiveX controls in VB, but am I correct in saying that using an ActiveX is considered "easy", but generating an ActiveX is considered pretty hard core, even with all of the VC++ "wizards" to generate the program skeletons?
You have this type of dichotomy in the "scripting" languages -- you write the app in Python but you write C/C++ extension modules to do the hardcore, time-critical, low-level stuff. The other extreme is Common Lisp, Smalltalk, and Java. While these are considered "easy" languages (not saying Lisp is "easy", but Paul Graham claims he can do much more stuff more quickly with it) -- you are encouraged to do everything in Lisp if you are using Lisp, everything in Java if you are using Java, and while Java has the JNI, its use is discouraged by the official Sun party line. I see Python working on growing from "just being a scripting language" to an attempt, with the right libraries, to make Python another Common Lisp, Smalltalk, or a Java.
I think that Borland went for the unified approach -- the Visual Form Designer allowed programming with drag and drop, it automatically wrote the Pascal, and you weren't really supposed to touch the Pascal very much. In fact, the generated Pascal was so parsimonious, I was afraid of it because I didn't know what was going on -- a lot of what was going on was that objects were initializing themselves and connecting themselves in the form/control hierarchy by reading in state information from the .DFM files (which you can view as ASCII text -- this forms the "second Delphi" language which is a kind of Pascal-syntax XML).
Then you had component development, which was supposed to be done by object inheritance and by writing some hard-core Pascal code -- there were (at least a first) no wizards to guide this, and extending a class by inheritance is a much tougher programming job and the code writer-driven composition of a top-level Delphi app.
Of course, the component developers were supposed to be the hard core programmers, and they could be fewer in number because they would publish their components for reuse for the vast army of Delphi Form Designer weenies. But if the Form Designer weenies were to use dBase Basic, there would have to be a Pascal/C++ other product (at least in the first iteration) to do component developement.
The argument for a single-language universe is its uniformity. The argument for multiple languages (VB.NET /C#.NET doesn't count as those are simply syntax "skins", but Managed C++ may count) is that different languages are suited for the different levels of an app.