|
|
Articles
|
Free
VCL
|
Downloads
|
Job
Sites
|
|
Links |
|
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.
Visual Basic is very easy to learn and use, not only because the programming language is not an OOP language and is 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. 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 this is way too much of a bother when compared to Visual Basic's Recordset and Data Control that notably simplify this matter. 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. +------------------------------------------------------------------+
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 * The Wrong Tool for
the Right Job - By Don Kiely, 1999 Visual Basic is ideal
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 +------------------------------------------------------------------+
One of the merits that must be recognized to Visual Basic is that -thanks to its easiness- it 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 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.
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 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 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.
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 1) Those who decide
to make a living as independent developers are not beginners
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 +------------------------------------------------------------------+
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 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 +------------------------------------------------------------------+
|
| Borland User Group meeting held every Wednesday, 7PM. For venue, send email to [email protected] or [email protected] for more details. |
| Copyright
© 2001 Delphi User Group of the Philippines and respective copyright
owners. All rights reserved. |