Visual Basic and Kylix

Are VB developers ready to down tools and move over to Delphi and Kylix?

Home

Sign up to be notified of future articles

Books for Developers

Web Development code examples

Contact

 

Inprise/Borland is pushing for Visual Basic developers to port applications to Linux using Delphi (see the press release). The logic goes something like this. First, Delphi is just like VB. It is form-based, drag a button here and a listbox there, double-click to add some code, and away you go. Second, developers will love the idea of building applications for both Windows and Linux since it increases their market. So there it is, a no-brainer.

I have been developing with both Visual Basic and Delphi since the early days of both products. I was there when the beta of Delphi 1.0 was presented to the press, and we were asked what we thought it should be called. (Borland wanted AppBuilder, but at the time Novell had a product with that name). Right since that first presentation, it's been clear to me that Delphi is a better product than VB. There are two core reasons for this. The language is better designed, more logical, more consistent, more powerful, more pleasant to work with. And the Visual Component Library (VCL) is superior to VB's black-box visual objects. I have even told the world. On numerous occasions, I have written comparative reviews which end up by recommending Delphi as the most productive Windows development tool. You might imagine therefore that I would be right behind this latest campaign. But I find myself sceptical.

Let's look again at that logic. Is it true that Delphi is like VB? Visual Basic has some specific strengths. It is a safe and cosy environment, at least until you get into hard-core VB hacking. It is the macro language of Microsoft Office and quite a few other applications. It does a good job of hiding the complexities of COM, letting you build ActiveX libraries that you can call from any COM client, or from Active Server Pages for web applications. It works smoothly with Access .mdb data, again as used by Microsoft Office, as well as SQL Server.

Now, Borland/Inprise is arguing that Delphi is sufficiently like VB that developers will move with little pain. The interesting question though is why haven't they moved already? Delphi has been around a long, long time, in the crazy accelerated time scale of the IT world. Yet it only has a fraction of the market. There may be all manner of reasons for this, but surely a strong factor must be that those VB strengths mentioned about really do matter. If Delphi's many superior features haven't counted enough to make these VB guys move on Windows, why on earth will they now be persuaded by a Linux version?

Let's be clear about something else. The Windows-specific features that will not port easily from Delphi to Kylix are even more important in the VB world. Little things like COM, ADO, DAO, and ActiveX controls. Bear in mind, for example, that VB's success in its early days was driven by the widespread availability of VBX and later OCX components. Is Sheridan's Data Widgets coming to Kylix? Or Spread/OCX? Or any number of other popular controls. Delphi developers by contrast tend to use these things less. You don't need to tell me that in many cases use of these controls can be avoided or worked around or substituted by other, native Delphi components. I know that, but I also know what kind of effort is involved in this kind of migration.

Here's another thing. No COM, and no data access API compatibility. Now we're not talking little details here. In many real-world applications, the data access stuff forms the heart of the code. Remember too that Microsoft has been telling VB developers, at least since the release of VB 4, that COM is the way to go. The advanced VB applications that I've seen have taken this message to heart. They use automation servers, they integrate with Microsoft Office, they break the application down into components. When it comes to web development, Microsoft Transaction Server (Component Services on Windows 2000) is a leap forward in scalability, and again COM based. How easily will this stuff port to Kylix? Simple, it won't.

The other key issue of course is just how much developers will gain by building cross-platform applications that run natively on Windows and Linux. This could be a big deal, if you consider that developers can offer their clients applications that run on a free-to-deploy operating system. I'm not convinced though that Linux as a workstation operating system is ready to go. That's a whole other debate, but I couldn't look a typical corporate client in the eye and advise them to kick out Windows and do all their word processing and DTP and spreadsheeting and so on with Linux. On the server, for sure, particularly web applications. However I doubt this is a big enough market to make Kylix sing.

I do want to be convinced. I'd like to see Delphi go from strength to strength, although I worry that Borland/Inprise will be too busy rubbishing Windows and talking up Linux to maintain Delphi's pre-eminent position on Microsoft's platform. I can also see that a strong open-source alternative to Windows is great news for anyone who values a competitive and innovative IT marketplace. In the end though, Kylix will have to succeed on its own merit, not by pretending to be just like Visual Basic (but somehow better).

Copyright Tim Anderson 1st July 2000. All rights reserved.

Sign up to be notified of future articles