A comparison between Delphi and Visual Basic

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:

Why Borland's Delphi?

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:

Hardcore Visual Basic - By Bruce McKinney, 1999

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

The Wrong Tool for the Right Job - By Don Kiely, 1999

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:

Client/Server Development Tools - By NTSL, 1999

Benchmark: Rapid Application Development Tools - By NTSL, 1999

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.

Thirteen ways to loathe VB - by Verity Stob, 2000

Why I really like Delphi - by Null Writer, 1999
Saying Goodbye to Hardcore Visual Basic - by Bruce McKinney, 1999
The End of Hardcore Visual Basic - by Bruce McKinney, 1999
Hardcore Visual Basic - by Bruce McKinney, 1999
The Wrong Tool for the Right Job - by Don Kiely, 1999
The Case for Delphi - by Alan C. Moore, Ph.D., 1999
The cult of Delphi - by Marco Cantù, 1999
Delphi. Reasons why. - by Greg Lorriman, 1999
Client/Server Development Tools - by NTSL, 1999
Benchmark: Rapid Application Development Tools - by NTSL, 1999
Free Value - by Peter Jackson - Published in PC Magazine UK, 1999
Delphi 4 and VB6 take aim - by Peter Coffee, 1998
Delphi vs Visual Basic - by MER Systems Inc., 1998
RAD Programming Tools Shootout - by Les Kendall, 1997
Delphi 3 closes in on Visual Basic 5.0 - by Maggie Biggs, 1997
Visual Basic and Delphi Head to Head - by Stephen W. Plain, 1997
Comparing OOP Languages: Java, C++, Object Pascal - by M. Cantù, 1997
Should Delphi people be worried about C++ Builder? - by David Lipschitz, 1997
Delphi Leaves Visual Basic In the Dust...Again - by Paul Bonner, 1997
Battle of the Visual Masters - by David S. Linthicum, 1996
A Comparison of Client/Server Development Tools; Powerbuilder 5.0 vs. Delphi 2.0 - by Michael Lant, 1996
Delphi vs Visual Basic - by Borland Staff, 1995
Why Shun Delphi? - by Graham Perkins
Why not VB.Net?
VB.Net for the VB6 Developer - by Bob Butler, 2001
Moving to VB.Net - by Bob Butler, 2001
Developers cry foul over new Microsoft language - by Mary Jo Foley, 2001
.NET Changes Can't Be Ignored - 2001
The New Visual Basic - by Mike James, 2000
Get Your Designs in Gear for VB.NET - by Paul R. Reed Jr., 2000
Visual Basic.NET Revealed - by Bruce McKinney, 2000
Why Delphi?
Why Borland's Delphi? - by many authors
Why Delphi? - by Marco Cantù
Why Delphi ? Why not ?!!?? - by Matlus
Ten Things I Love About Delphi - by Charles Calvert, 2000
Stand up and be counted - by Marco Cantù, 1999
Case studies
ASSESS: Delphi Helps American Skandia Compete - by Denis Perrotti, 2000
California's CalJOBS Project - by The EDD Development Team, 1997
Inquire Within - Engaging Kiosk System Reels in Apartment Shoppers - by David Rippy, 1996
Microsoft Visual Basic and Delphi - The Decision Making of Systems of Emergency Management - by
Binh Lam, 1996

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.