Delphi vs. Visual Basic: Just another comparison between these two RAD tools

A comparison between Delphi and Visual Basic

Copyright © 2001 Ernesto De Spirito

Refer this page to a friend!

Storage Library - Save your app's configuration

Introduction

Which one is better? Delphi or Visual Basic? It's a simple and direct question, but unfortunately it doesn't have a simple and direct answer. The reason is that –although they are both Visual RAD tools– they have very significant differences and peculiarities that make it impossible to draw a straight and general conclusion. What we can do however is analyze and compare their different characteristics, hoping you find them useful as a guide for evaluation. My choice was Delphi because in the comparison I gave more weight to certain factors, prioritizing them over the others, and then the result was Delphi. With different requirements it would be perfectly valid to choose Visual Basic. Your choice of language is up to you and will depend on the importance you give to each characteristic.

Learning curve

Visual Basic is very easy to learn and use, not only because the programming language is not an OOP language and thus it's easy to learn and code (in the end it comes from BASIC), but also because the IDE is simple and conformable to use, and the database objects that come with Visual Basic provide an interface that makes them easier to use.

Visual Basic does many things for the programmer. For example, objects are reference counted, and this means that for example if we create an object referenced by a local variable, the object will be automatically released when the function or procedure ends (unless we assign it to a non-local variable). Visual Basic has a sophisticated memory management system and uses a garbage collector so it's fast deallocating memory.

Database access in Visual Basic is very simple compared with Delphi. Just one component is used to open the Recordset, offer a navigator visual interface and link to the data controls, while in Delphi we have to use three components for that (dataset, datasource, navigator). This architecture may look bothersome for Visual Basic programmers, but it has its advantages, like the freedom to combine different dataset and navigator components at will and the possibility to place the dataset and/or the datasource components in a different unit (for example in a centralized data module).

The big advantage of Visual Basic Recordsets over Delphi Datasets is that the first ones handle updatable queries automatically: you can have a query on two tables and it can be "live", while in Delphi we have to use Cached Updates and an UpdateSQL component with the respective SQL queries to insert, update or delete a record. Additionally, when you act against a database server in Delphi you have to use a transaction component, while this is not necessary in Visual Basic. From the perspective of a Visual Basic programmer, the data access of Delphi may represent way too much of a bother when compared to Visual Basic's Recordset and Data control that notably simplify this matter.

In Delphi, the functionality of Visual Basic's Data Control is split into three components. In the image you can notice that the data is available at design time, and for example you can change the default label of the fields, as well as their display width, display format, edit mask, etc.

Delphi is harder to learn, but not for people who are familiar with Turbo Pascal or FreePascal. Yes, Delphi is harder to use, but has its advantages. For example, objects usually aren't reference counted and this means the programmer has to take care of disposing unused objects created by a procedure or function when that procedure or function ends. The advantage is that we have more freedom in manipulating the object and we can release it when we don't need it anymore, no matter how many variables point to it. Delphi has its own memory management system optimized for small blocks of data, although it doesn't have a garbage collector. Database access is cumbersome compared with Visual Basic, but very flexible and extensible.

The IDE deserves a special mention. Particularly, the Code Editor of Visual Basic has some interesting things. Maybe Borland invented Code Insight, but personally I think that Microsoft implemented it better. The possible values of a variable or parameter, or the possible properties or methods of an object appear automatically and instantly. Letter-case formatting is a nice feature too (for example if you declare a variable with the name "Doc", if later you write "DOc", "doc", "dOc", etc., the variable is formatted as it appears in the declaration statement –i.e. "Doc"–). One nice thing of the Visual Basic IDE is that when you are debugging you can modify a sentence and continue the execution with the changes in effect, without having to restart your application. Another nice feature of Visual Basic is the Immediate Window where you can execute interpreted sentences.

But ease of programming had to come at the expense of something. Visual Basic is easy to learn at the beginning and doesn't require a strong background of formal education in programming to learn it, but as you advance and demand more and more out of it, you start finding that VB has serious limitations that start reminding you that not for nothing the "B" of Basic stands for "Beginners" (BASIC = Beginner's All-purpose Symbolic Instruction Code). This doesn't necessarily mean that Visual Basic programmers will eventually switch to a more powerful language, actually most Visual Basic users will be happy with it for years as long as they never need to go beyond its limits, but truth is that Visual Basic has been the "entry language" for many current Delphi programmers. Here are some testimonials:

One big fact about Delphi is that you can really do it all and you can "easily" reach everything your machine and operating system has to offer. In Visual Basic, to call an API function you have to search the declaration of the API function, constants and types in a database to copy and paste them in your programs. From the perspective of a Delphi programmer, this is way too much of a bother when compared with Delphi, where you can just call an API function as if it were a built-in function. Of course, an OOP language is very hard to learn if you don't have a strong programming background, but once you master it, it gives you the ability to write reusable, extensible and easily-maintainable code. With Delphi's data components you can have open a database table or query and view the data at design time, something nice at the moment of setting the width of the columns in a data grid. The Delphi IDE doesn't offer the features I described above for Visual Basic, but offers other things. For example Delphi's Code Editor offers to possibility to choose the Key Mapping schema and Code Templates to save you typing (something that curiously I would expect to find in Visual Basic instead of Delphi). When it comes to debugging you have some advanced features like CPU and FPU windows and the possibility to debug multi-threaded applications.

"Visual Basic makes the easy things easier, Delphi makes the hard things easier" (Computerworld, 1998).

Purpose

What do you intend to use a programming language for? This a key issue when choosing a programming language. Here's an interesting testimony from a former Visual Basic programmer:

And below is the reply of a Visual Basic programmer admitting Visual Basic limitations, but also saying an important thing: each language "has its unique strengths and weaknesses, despite the marketing hype produced by those with vested interest in the languages" in a clear allusion to... Well, read it by yourself

Visual Basic is good for simple front-end applications and unsuitable for more complex stuff, while Delphi is ideal for both the front-end and the back-end. What does this mean? For example, with Visual Basic you can develop a compression tool (like Winzip) by designing a user interface and writing some code calling the compression routines of a given DLL or an ActiveX object (written in another language) that provides compression capabilities. With Delphi you can do the same that you can do with Visual Basic, but you can also write the DLL or the ActiveX object that performs the compression/decompression task. It's not that it's impossible to write a DLL or an ActiveX object in Visual Basic: it's technically feasible, but might be very inconvenient (see Performance and Code Size).

Delphi is more an "all-purpose" language than Visual Basic.

Market share

One of the merits that must be recognized to Visual Basic is that -thanks to its easiness- it has put Windows programming at the fingertips of literally millions of people.

In particular, the success of Visual Basic in the Spanish-speaking community is overwhelming because to the ease of use we have to add that the IDE, online help and printed documentation are translated into Spanish. I heard that in Spain Delphi is delivered with the printed documentation in Spanish. Hey Borland, why don't we have that choice in the Spanish-speaking countries of Latin America? You are loosing in big here...

The purpose and the ease of use has accommodated Visual Basic with a much bigger market share than Delphi in the global market. However, in certain market niches, Delphi rules over Visual Basic.

In-house programming

Medium-size and large companies that hire programmers to develop and maintain their internal management systems clearly choose Visual Basic over Delphi. This is the market of "simple front-end applications", and executives know there aren't as many Delphi programmers as Visual Basic ones, so their choice is Visual Basic because they simply prefer to have an army of programmers at their feet when they need someone.

We are talking of companies that have enough money to pay for the licenses of the latest version of Visual Basic (see Obsolescence), to be up-to-date with the hardware (see Performance and code size), and to pay for a solution when their IT staff can't develop something in Visual Basic due to its intrinsic limitations.

Only those companies that demand more than just "simple front-end applications" from their IT staff use Delphi.

In a sort of feedback process, or a "vicious circle" if you like, the dominant position of Visual Basic pressures programmers to follow the Visual Basic path to enter the work market, giving programmers another reason to choose Visual Basic instead of Delphi.

Management-systems developers

In this category fall software corporations, software consulting firms and independent (individual) developers that develop management systems (billing, inventories, payroll, etc.), usually tailor-made.

Delphi's position is perhaps a little bit better in this market, but Visual Basic still wins by large because it's almost the same case of in-house programming that I discussed above, only just that it is carried out by a third party.

However, in the case of individual developers we can see a shift. In this particular sub-category, Visual Basic wins only because there are many unemployed Visual Basic programmers that occasionally take jobs as independent developers while they are looking forward for a fixed job, but those who have truly decided to make a living as independent software developers clearly make of Delphi their choice for Windows development (at least this is the case of all my friends), being perhaps five key reasons (among others) that:

  1. Those who decide to make a living as independent developers are not beginners
  2. Being relieved of the pressure to use Visual Basic to enter the work market, they are free to choose the development tool they want
  3. Delphi applications have less system requirements (medium and small companies –the ones that hire individual developers– can't upgrade all their hardware regularly like the big ones)
  4. There are a lot of freeware VCL components available (individual developers usually can't afford to constantly buy solutions from other software developers)
  5. Usually they can't afford to upgrade their hardware and development tool every year, so they prefer to buy a tool that can stay with them for a long time (see Obsolescence).
Delphi's performance doesn't limit you to simple front-end applications. With Delphi you can create stand-alone and fast DLLs, ActiveX objects, service applications, etc.

Other software developers

Finally, we have the market of those who develop shareware and commercial applications (different from management systems), ActiveX controls, libraries, etc. In this market, Visual Basic has an extremely weak position compared with Delphi, although to honor the truth, C++, particularly Visual C++ still prevails in this market, but I can see how Delphi is slowly but steadily growing in this market at the expense of Visual C++ because it offers a power and performance closer to C++ and a ease of use closer to Visual Basic, bringing the best of both worlds, plus the addition of a ready-made, easy-to-use, highly-standardized and easily-extensible hierarchy of visual and non visual components (the VCL).

Visual Basic is the choice of executives, beginners and those who are forced to use it to get a job or simply follow the masses. Delphi is the choice of independent developers.

Performance and code size

The only item where I saw that Visual Basic has a good performance is in data access, and perhaps reports, because the data access layer and report generation aren't written in Visual Basic, but when it comes strictly to code generation, despite the fact that Visual Basic now produces native code instead of pseudo-code (P-Code), it is still very far from reaching a speed comparable to Delphi. This happens because Delphi has an optimizing compiler and yet there are compiling options to improve the speed of your code. To say more, if you are not happy with the performance of a routine in Delphi, you can fine-tune the code to squeeze the last nanosecond out it. In this respect, Delphi is ideal for tasks that require heavy programming.

Apart from the performance of the generated code, the VCL performs caching of Windows objects (such as fonts, pens, brushes, etc.) to render a more efficient use of Windows resources.

The more system resources, the better –of course–, but execution speed and efficient use of resources make it possible for Delphi applications to run reasonably well in old Pentium machines with little memory like those you can still find being used in many small and medium companies.

Delphi features an optimizing compiler. Some options (optimizations, alignment of record fields, no stack frames, no complete boolean evaluation, no range checkings and no overflow checking) help the professionals get the best out of their code. When needed, compiler directives can be used to turn compiler options on or off in the source code.

Speed and code size usually conflict, but when we compare Delphi and Visual Basic, Delphi clearly wins at both ends. A small database application using ADO and some third-party components fits in a single installation diskette in the case of Delphi, while its Visual Basic counterpart would fit in no less than two or three diskettes (in both cases I am not including ADO that has approximately 8 Mb). Why is the difference so big? Delphi optimizes code size all it can, it generates standalone executables (it can also generate executables that work with runtime libraries if you want) and it uses SmartLinking to avoid including in the executable procedures and functions that are not referenced in the code. Visual Basic has no other option than to work with runtime libraries and ActiveX objects (that are bigger and not as performant as their VCL counterparts).

Delphi produces standalone applications that are small and deliver great performance, making them more friendly with system resource and modem bandwidths, making of Delphi an ideal choice over Visual Basic for independent developers that produce tailor-made solutions for small or medium companies, as well as shareware or commercial applications to be distributed in the Internet.

Extensibility

Visual Basic and Delphi are extensible. Both IDEs support add-ons to add wizards and other extensions to the IDE, but what is more interesting for programmers –better said, more needed– is the possibility to use visual and non-visual objects apart from those that originally come with the development tool.

ActiveX Objects

In Visual Basic you can use ActiveX objects. They come in .OCX files that are like sort of DLLs that have special functions to expose objects with their properties, methods and events. Accessing properties and methods of ActiveX objects is slow because they are accessed with IDs. String properties are UNICODE strings, while applications normally work with ANSI strings, adding another overhead (UNICODE-ANSI or ANSI-UNICODE conversion) when accessing string properties.

ActiveX objects provide encapsulation, but they don't provide inheritance. Inheritance can be simulated by declaring the same methods and properties of the "base class" and implementing them as calls to the respective methods and properties of the "base class". The "derived class" is therefore nothing but a wrapper from the "base class". Not only this makes the source code long and difficult to maintain, but it also makes the invocation of properties and methods of the new object more than twice as slow than the original object.

VCL Components

Here is where OOP makes the difference. In Delphi you can use ActiveX objects if you want, but Delphi offers something much better: the VCL (Visual Component Library), a hierarchy of classes that go from those that offer basic common functionality to those highly specialized like a database table. From these classes you can derive your own, and you only have to code what you want to add or redefine, and this is why VCL components are much smaller, faster and more easily maintainable than ActiveX objects. They are faster due to the following reasons:

  1. References to properties and methods are resolved at compile-time ("early binding") or –in the case of virtual or dynamic methods– at runtime ("late binding"), but in the latter case, the code used to get the address of a method in the VMT (Virtual Methods Table) is very small and efficient compared with the way used by ActiveX to find its methods and properties. If a property refers directly a data field, no function is called. With ActiveX, there's always a function call.

  2. Normally most of the properties and methods of the base class are not redefined, so when you invoke one of these properties and methods the call goes directly to those of the base class without having to pass thru any intermediary. ActiveX inheritance is simulated, making all method and properties invocations more expensive.

  3. Normally you use ANSI strings (not UNICODE strings like ActiveX objects), so there is no conversion overhead.

  4. They are part of the executable and this means that it's not needed to open a file to use them, load a list of the functions they expose, etc.

Apart from being faster and significantly smaller, VCL components consume less system resources then their ActiveX counterparts and their inheritance mechanism allows for extensibility.

Availability of third-party libraries, objects, etc.

There are lots of ActiveX objects and DLLs in the net that you can use with Visual Basic, but most are payware and most don't come with the source code, not even after you pay their licenses, and when they come with source code, it's in another language (usually Visual C++ or Delphi), and this means that if you want to modify these sources you need to 1) know something of that language, and 2) have the respective development tool, and I don't think it's worth it to buy a license just to occasionally make minor modifications to objects and libraries.

The availability of lots of top-quality VCL components and IDE experts, both freeware and payware, is one of the strongest points of Delphi. They speed up application development and help developers add particular functionalities and a great look and feel to their applications.

The perspectives in Delphi are a lot better, because in addition to ActiveX and DLLs, you can find a lot of VCL components in the net, being freeware most of them, many of them come with source code, and most of those that are payware usually come with the source code after you register or for an additional fee. And in which language is the source code written? A very small minority are written in C++ Builder, but the overwhelming majority are in Delphi, of course, so you don't have to learn a new language or use a different development tool if you wish to modify them.

Delphi is not limited to ActiveX. VCL components are faster, smaller, source code is usually available (and in Delphi), and the inheritance mechanism allows the easy creation of new VCL components based on existing ones.

Obsolescence

Among Visual Basic programmers, how many of them are still programming in Visual Basic 4.0? And how many are programming in Visual Basic 5.0? Almost all Visual Basic programmers I know are programming in Visual Basic 6. With Delphi happens something completely different. A lot of people are still programming in Delphi 3 or 4, and perhaps the minority have Delphi 5, when Delphi 6 has just come to light. Why is that? Is it that the upgrade is too expensive? Nah... On second thought, yes it is! Please allow me to explain. What happens with Visual Basic is that –avid of more features– Visual Basic programmers upgrade rapidly as soon as there is a new version available. Delphi 3 C/S is so powerful that it is not yet obsolete, and this explains why many Delphi 3 programmers don't see the need to pay for an upgrade when they already have what they need. Extensibility has also a lot to do with that.

Visual Basic programmers need to upgrade too soon. Delphi is so powerful, functional and extensible that its versions don't become obsolete easily: in the long run, Delphi is cheaper.

Programming power and functionality

Among many other things, with Delphi you can:

  1. Write commercial-quality, fast and small applications, libraries, ActiveX objects and VCL components
  2. Create reports by code (or modify existing ones, for example to change or add a column)
  3. In general, everything that can be done visually (at design time) can also be done programmatically (at runtime)
  4. Easily write multi-threaded applications
  5. View data in tables and queries at design time
  6. Call API functions as if they were built-in functions
  7. Embed assembler code for best performance where necessary
  8. Take advantage of lots of VCL components available to give your applications a distinctive look and feel and offer an improved functionality.
  9. Easily subclass existing VCL components to add functionality
  10. Access new technologies not present when the IDE was released (for example ADO access with Delphi 4) without having to upgrade
The Delphi IDE offers programmers advanced features like the ability to debug multi-threaded applications or to execute the code step by step in assembler!
 
Delphi offers programmers a power and functionality that leaves Visual Basic and its limitations behind.

Portability

If you are interested in Linux, there is a Delphi for Linux (Kylix), and I don't see there will be a Visual Basic for Linux...

Kylix takes Delphi to the Linux platform, where VB won't go.

Comparisons by NTSL

National Software Testing Laboratories, Inc. (NSTL) prepared two reports comparing Delphi 4 with Visual Basic 5 and Visual Basic 6. These reports are published at Microsoft's web site:

There are some things about these reports I'd like to point out:

  1. Delphi 4 is used for the comparisons, and not Delphi 5
  2. The hardware used for testing hides the inefficiencies of Visual Basic. I wonder why the test didn't include several hardware configurations (like two/thirds the speed and half the memory?)
  3. There are lots of features that (deliberately) hasn't been evaluated. Would it be because Delphi has many features that Visual Basic lacks and they don't want to show that Delphi is a far superior tool?
  4. The selection of tests is too arbitrary. It looks very much that they studied Delphi's weaknesses and selected the few tests where Visual Basic had a comparable or better performance (take the time of a for loop from 1 to 1000000000 to see what I mean). Clearly to me, these tests are (deliberately) not comprehensive. Would it be because they don't want to show that Delphi is the clear winner in many other tests? http://www.mers.com/INPRISE/FAQ/2780.HTML
  5. I don't buy that the Sieve algorithm to find prime numbers runs faster in Visual Basic than in Delphi. I think that this is the result of poor coding in Delphi or something. "Curiously", the code used used in the benchmarks is not revealed. Also curiously, I recall that the old Clarion Desktop Developer claimed to outperform C in this test... Yeah right! :-)
  6. The testers admitted not to have a good knowledge of Delphi. Does this mean that benchmarks are comparing the code produced by a senior Visual Basic programmer with the one produced by a Delphi newbie?
  7. Testers were contracted by Microsoft. Of course! ;)
  8. The reports are published under Microsoft's copyright.
It looks to me that these reports are not independent and that are too biased to be considered seriously.

Support

Product support is usually a critical factor when deciding which tool to use. Microsoft has physical presence in almost all major cities of the world. I've heard that if you wait long enough over the phone, you get transferred from one person to another until you finally get to talk with the programmer who actually wrote that function that gives you trouble. What a support! But I would like to ask you a question: what kind of support is waiting two or four hours on the phone to finally be told that a bug has been corrected in the latest version (i.e. "pay the upgrade") or that it'll be corrected in the new version (i.e. "wait and pay the upgrade when it comes out")? When I have a problem I want a solution, and I want it now, and I don't want to pay the cost of an upgrade.

One of the things I like of Borland is that they are very responsive with this issues (for example if you find a bug in a VCL component, likely someone already developed a patch or found a workaround, or if you need additional functionality for a component, if it's a common task probably someone has already developed a substitute component or else someone in the newsgroup can give you a hint or some source code to do what you want). Tech support is very important for me, and the architecture, the extensibility and the availability of the source code of the VCL gives me confidence, and I feel well backed when I see that the members of Borland technicians and the members of the Community that participate answering questions in the forum have a high level of knowledge and strive to answer from the simplest questions to the roughest ones.

Borland is a company with experience and dedication to development tools, not a division of an operating-systems company. I know what to expect from Borland in the future, and I know they'll keep developing and supporting Delphi, but the truth is I don't know what Microsoft will come up with in the future, if they'll keep developing Visual Basic or if one day they'll decide to stop supporting Visual Basic and say that they want Visual Basic programmers to migrate to a Microsoft Universal Language or something like that...

Tech support is important. Don't let the physical proximity of an office guide you, and ask your colleagues about their experience with the support of one or the other provider... and how much it cost!

Links to more comparisons, testimonials, etc.

Conclusions

Visual Basic is suitable for simple front-end applications, typically management applications (billing, inventories, payrolls, etc.). Its ease of use makes of it the right choice for beginner programmers. Delphi is even better for front-end applications since the availability of VCL components allows one to develop superior-quality interfaces, both in terms of functionality and presentation, but it's not as easy to use for beginners, that are the majority group and for whom this factor prevails over the quality of the work, execution speed, code-size, use of system resources, development time, costs or any other factor.

Corporations prefer to have many candidates available when they need to cover a position, than to have fewer candidates to cover a position that requires more qualifications and for this reason they prefer Visual Basic over Delphi. If you want to get a job, learn Visual Basic.

I think it's only possible to convince an executive to choose Delphi instead of Visual Basic when there are specific requirements that justify it, for example if the company can't have the latest in hardware, can't buy the upgrades to the latest version of Visual Basic, can't afford to pay for solutions every time they find a limitation in Visual Basic, needs a better-quality GUI (more functional and/or more visually appealing) or when the Visual Basic staff can't deliver applications on schedule (this normally happens when they are crashing against some VB limitation, because usually the code gets complicated to circumvent it and thus it gets difficult to maintain) or when shorter development times are required for applications that are not so simple.

The code editor has some productivity features, like the user-defineable Code Templates that save you from typing common blocks of code, and the Code Explorer that help you browse all the elements (classes, methods, variables, procedures, functions, etc.) defined in a unit.

Delphi is harder to use than Visual Basic at first, no question about that, but it allows us to do all. Like someone said, "Delphi is more Windows-compatible than Visual Basic". Those programmers who carry in their luggage some knowledge of an object oriented language (like C++, Turbo Pascal 5.5+ or FreePascal) don't have problems to learn Delphi. They are usually those who have a base in formal education in programming (universities, colleges, etc.) or learned by themselves. The market of Delphi is not limited to front-end applications: Delphi is also used for the back-end (servers, libraries, ActiveX objects, etc.), a market out of the reach of Visual Basic.

Third-party packages of VCL components help developers give their applications a touch of distinction.

Visual Basic does a lot of things for the programmers, so many that use it are too comfortable with it (Delphi might look too arcane for them), and if they haven't faced Visual Basic limitations, why change? Visual Basic is the right tool for them. On the other hand, I see many that are unhappy, and I really think they will be much better off programming in Delphi... as well as a few Delphi programmers (newbies with bad, little or no background in programming) that perhaps should be programming in Visual Basic. My concept of Delphi is that it's a professional tool for a professional programmer, while my concept of Visual Basic is that it's for those that are satisfied with the little the tool gives to them because either they only develop simple front-end applications without much aspirations, or they lack preparation or experience in Windows programming or OOP, or they don't want or don't like to program, or they don't have time to learn, or they don't know English, or because with Visual Basic it's easier to get a job since companies prefer to hire people who meet this profile. Despite of all this, it must be said that Visual Basic is a great tool that has put programming at the fingertips of a lot of professionals that come from careers outside programming (Information Systems Analysts, Electronic Engineers, etc.).

The best tool for the job is the one that best conforms to your requirements, limitations and expectations.
 

This article was featured in the Developers Newsletter:

JfControls Library - for Delphi and C++ Builder

Refer this page to a friend!

Pascal Newsletter. Free ezine for Delphi (and Kylix) programmers with articles, news, reviews, tips, trinks, and links to new Delphi content on the web!