Delphi .NET ?
When Delphi 1.0 was released in March of 1995 it made a huge splash. And why not? It was an elegant, very well-designed development environment that used a language that was customized for the environment and for fully object-oriented programming. Many features that Visual Basic developers had been begging Microsoft for years to include were implemented in Delphi—not the least of which was truly compiled code!
So now, for the first time in many years, Microsoft had a serious challenger in the development tools arena. Since the decline in market-share of Borland C++ there had really been no serious contenders. Now Delphi burst on to the scene with a vengeance.
Microsoft responded by identifying and copying as many of Delphi's best features as it could. Suddenly Visual Basic was compiled, had true objects, and even the property set/get methods looked familiar. One feature after another was stolen. And not only features—Anders Hejlsberg, the chief architect of Delphi, left Inprise and went to work for Microsoft (for an obscenely high salary, no doubt!).
But through all of this, I was convinced that some of the truly best features of Delphi would never be stolen:
• Delphi is written in Delphi—it's more than a trite phrase or marketing slogan. It's undeniable proof that Inprise so completely believed in this tool and this language that they were willing to develop their premier product in it.
• Delphi's elegant hierarchy of base objects inherited to the visual and non-visual components that you use in the environment. And the fact that you can choose an object anywhere in the hierarchy and begin your own inheritance line to expand and enhance it.
• The ease with which you can implement low-level API calls, COM interaction, and a variety of other tasks which Visual Basic simply couldn't touch.
Microsoft couldn't steal these features. They were part-and-parcel of Delphi and the way it was designed from the outset. Microsoft would have to rewrite everything to implement features like this. They would never do that. It would be too expensive.
I was wrong.
Microsoft, even as I write, is in the process of doing all of this and more. They are truly rewriting everything from the ground up. It's called the Microsoft .NET initiative.
But we're Delphi people! Why should we care what Microsoft does? Because your livelihood could depend on it! Don't get me wrong. I'm not saying Delphi is dead. Not by any means. But Inprise and the Delphi community must understand how the industry is changing in order to know how to respond and how to find a place within it.
The .NET framework is a hierarchy of objects that provide a variety of services from database access to COM. It provides an easy way for you to access, inherit, and extend a broad host of functionality. And it will be built into Windows and made available to any programming language in Visual Studio. Anders Hejlsberg has clearly had a major hand in the design of .NET!
And speaking of programming languages, the next version of Visual Basic finally gets true inheritance and polymorphism. It also gains the ability to do a whole bunch of low-level things that it could never do before, including multi-threading. It's actually been completely re-written from the ground up. In the process, they got rid of many of the annoying and inconsistent syntax that's been a part of the language since the early days. And, you guessed it—it was re-written in Visual Basic. How is that possible? For that you need to understand a little more about the way Visual Studio will work.
Visual Studio now becomes much more than a hodge-podge collection of all of Microsoft's development tools. In fact, it becomes a single, unified IDE into which third parties can plug in their own languages. These languages become first-class members of Visual Studio and gain access to all of the features and shared tools that are built into the IDE. There are over a dozen companies that have already dedicated themselves to creating languages to plug into the Visual Studio environment by the time the new version is released.
All languages (Visual Basic, Visual C++, and the third-party plug-ins) compile down to a common Intermediate Language (IL) that's similar to Java byte-codes. This common IL makes possible things that have never been done before—like creating an object in C++ and then inheriting it in Visual Basic. Cross language inheritance and development is a breeze in Visual Studio, and all languages share all of the same capabilities and access to the .NET framework. They all compile down to the same IL that is, in turn, compiled (either at compile time or dynamically at runtime) to executable code. There's no performance hit in any language. So now language choice becomes merely a preference.
This promises to bring an explosion of new languages like there hasn't been seen for many years. In the past, there were benefits to consolidating to just a few languages. Now, with Visual Studio's capabilities, all of those benefits are nullified. This also means, for better or worse, that if you want to be a player in the Windows world of software development, you'd better plug into Visual Studio. The benefits of doing so will be too great! The strain of attempting to re-implement all of the functionality that the .NET framework and Visual Studio provide will be too much, even for a company with a significant head start like Inprise.
Of course, this leads up to one big question: Will Inprise create a Delphi language plug-in for Visual Studio? This would provide a career track for all of the loyal fans of Delphi who want to access this exciting new world. It would also, without any extra effort, provide a host of new utilities and capabilities to the Delphi environment.
Delphi, as an independent development tool will continue. Kylix promises to make Delphi the visual development tool of choice for multiplatform development—no doubt about it. This is one area where Microsoft has chosen not to play, and that leaves the field wide open for others to fill the void.
Delphidevelopernewsletter.com/dd/DDmain.nsf/getauthor?open&Bill~Hatfield">Click here to learn more about Bill Hatfield