Dari dulu aku menyimpan artikel-artikel dari internet. Dan karena aku memasang Google Desktop Search di komputerku, artikel-artikel itu terindeks. Ketika kemarin mencoba mencari beberapa artikel, tidak sengaja artikel lama ini muncul. Karena menarik aku coba share di sini. Isinya VB vs Delphi ketika baru muncul. Isinya masih relevan untuk VB 6 compared to Delphi 6. Untuk .Net udah gak keliatan bedanya lagi karena .Net dibidani oleh Delphi creator juga. Anyway, artikel ini tetap menarik untuk disimak, kenapa Delphi sering disebut sebagai Visual Basic killer.
Visual Basic and Delphi Head to Head
By Stephen W. Plain
THE DEFINITIVE GUIDE TO PC TECHNOLOGIES & TOOLS
With a true compiler and object-oriented language, Borland’s Delphi looks to the future. Is it ready to topple VisualBasic?
With all of the visual development tools on the market today, it’s worth remembering that early Microsoft Windows 3.xdevelopment was anything but visual. Building a native Windows application back then demanded a certain type ofprogrammer: one who’d mastered C and the Windows API–and who was blessed with a bottomless store of patience.
Then Visual Basic (VB) came along and changed everything. The Ford of development tools, it brought Windows development to the masses and eliminated the laborious chore of writing UI code to create each form and button. It was built on Basic, a language almost anyone could learn, and it made building event-driven applications easy, simply by
attaching Basic code to visual controls.
VB was also an interpreted language system, so you could test and debug your application on the fly from within the development environment. And it was extensible. Prewritten
functions in the form of custom controls could simply be plugged into the environment, ready for use in your program. The combination was revolutionary. Suddenly, there was a quick way to build complex, powerful, professional-looking Windows applications.
Initially, Microsoft seems to have thought of VB as a general-purpose tool. But VB quickly caught the attention of corporate developers building client/server applications, because it was so well suited for rapid application development (RAD) methodologies that stressed iterative development, fast turnaround, and user involvement in prototyping. It was inevitable that other RAD development systems would adopt a VB-like approach. In fact, tools loosely based on the VB paradigm have come to dominate client/server development. These VB competitors–including runaway successes like Powersoft Corp.’s PowerBuilder–provide a visual interface that lets you paint an interface by dropping and resizing
controls and database connections onto forms. They also typically offer integrated development environments (IDEs) that let you add specialized controls and customize things to your liking. Generally, these tools also attempt to address the problem of code reuse, a big concern of corporate IS shops striving to make developers more productive over time.
A few also tackle the code performance issues raised by an interpreted system, usually by generating source code that can be compiled to true machine code.
Meet the Challenger
Of these VB competitors, Borland International’s Delphi is perhaps the most interesting to come along since VB itself. It borrows the best of the VB visual paradigm while breaking new ground in the areas of code reuse and performance.
With Delphi, Borland has raised the bar for RAD tools by coupling a highly productive visual design environment with a true compiler, a powerful object-oriented programming (OOP) language and a generous set of tools. Delphi is based on Pascal, a language many of us worked with in school. Its fresh approach to RAD provides an interesting mix of
productivity and power, and its specialized client/server tools let it compete with the likes of PowerBuilder and Gupta Corp.’s SQLWindows.
We did a side-by-side comparison of the currently shipping versions of Delphi and VB that are specifically geared toward client/server development: Borland’s Delphi Client/ Server and Microsoft Visual Basic 3.0, Professional Edition.
We invited Borland and Microsoft to come to PC Magazine Labs to help us construct an application fragment representative of a real-world database front end. Both products will soon be appearing in 32-bit versions, more or less coinciding with the release
of Microsoft Windows 95. While most of the fundamental features described in this story that distinguish them will not change, both will receive significant enhancements (for details, see the sidebar “Targeting Windows 95”).
Beyond Traditional Languages
Visual as these two products are, Delphi and VB both rely on traditional programming languages for their robustness.
Delphi and VB use existing languages: Pascal and Basic; their respective dialects include significant extensions to each, however. VB’s flavor of Basic extends the language with the concept of objects, properties, and methods, referenced through the now-ubiquitous object-dot-property notation. VB also extends Basic to make it an inherently event-driven
development system. While standard Basic programs execute line by line using essentially a single body of code, VB breaks your code up among various event-handler routines that respond to particular events. From the moment the first form loads in a VB application, all code execution occurs in response to events. Coding in VB is a process of designing the forms–the look of an application–and then defining the various behaviors to occur as a result of particularn events.
Borland built Delphi around its powerful Object Pascal language. Though Object Pascal’s roots are in standard Pascal, it includes true object orientation with support for inheritance, encapsulation, and polymorphism. The Pascal derivative in Delphi is sophisticated and powerful, yet easier to comprehend and manage than C++. Like VB, Delphi uses dot notation to reference objects’ properties and methods. Unlike VB, however, the Delphi language relies consistently on objects and allows you to create your own classes by subclassing from other objects and inheriting their properties and
methods. This powerful feature, the cornerstone of OOP, gives you significantly more control in creating well-structured applications. It’s also an excellent vehicle for code reuse.
Which language you feel more comfortable with depends on your perspective. Without a doubt, VB is the easier of the two to learn. You simply can’t beat Basic for its simplicity and readability. VB is also more forgiving of poor coding style, making it more friendly to new programmers. One example of this is VB’s default Variant data type. A Variant
can handle numeric, string, or date/time values. While the Variant type makes it easy to code without considering the data types of your variables, it can also lead to sloppy coding and wa steful use of system memory (Microsoft recommends that a Variant be used only in certain special cases). Delphi, on the other hand, is anything but forgiving in
this respect.
Since Pascal is a strongly typed language, you must declare all variables with their respective types before using them.
You also have to take care to use the appropriate data types with functions to avoid type-mismatch errors during compilation. For VB coders who are not accustomed to declaring all of their variables explicitly, this element of Delphi can take some getting used to. It does, however, make for a well-organized program, since you are more likely to conserve variable storage, and all of the variables appear clearly in the Var block of each object’s code. VB provides an Option Explicit statement, which can force you to declare your variables similarly (and Microsoft recommends its use), but
this feature is optional.
Interpreted Vs. Compiled
One of the biggest architectural differences between Delphi and VB is the way each compiles its code. VB is based on a language interpreter that translates code into machine instructions at runtime, while Delphi compiles its Pascal source code directly into machine code and builds a standalone executable. While compiled executables are always faster than interpreted code, the speed advantage will vary in degree depending on the nature of the application. Applications that are processing-intensive, perform heavy number crunching, or make heavy use of large loops and arrays reap the most benefit from compiled code. Database front ends that are primarily constrained by data-access performance will gain less. Delphi uses Borland’s well-respected Pascal-compiler technology to build highly efficient code. Not only does Delphi enable you to create standalone .EXEs and .DLL’s, but it eliminates the distribution hassle VB programmers face of having to include the appropriate runtime .DLL file with an application.
Although VB works at decoding application commands at runtime, it does not use a purely interpretive technique. As you leave each line of new source code in the design environment, VB tokenizes that line into an intermediate representation. VB maintains this “in-between” code while you continue to work in design mode. When you choose the
Compile or Run commands, your source code compiles to pseudo-code (p-code), a series of processor-independent codes that represent a series of machine instructions. Since the code has been precompiled, the application can start to run very quickly.
When you select the Make EXE option, VB builds an executable file that contains the p-code for the application, as well as the necessary executable header and startup code. When you run the VB-created .EXE file, the VB runtime .DLL file VBRUN300.DLL loads to translate the program’s p-code to machine instructions. While this approach is slower than running true compiled machine code, it can produce smaller .EXE files. This footprint advantage increases as you run multiple applications or instances of applications. All VB applications share the same instance of the runtime .DLL in
memory, so the memory footprint is far less than with multiple instances of completely compiled .EXEs.
One big advantage of an interpreted system such as VB is that you can test and debug portions of the application within the environment at any time. While most traditional tools force you to go through separate compile and link steps to test an app, Delphi offers an on-the-fly compile and link that lets you test in the development environment as you go, much as VB does.
Building with Forms
Both Delphi and VB base the development of the visual aspect of your program on forms. Each product lets you design and keep open multiple forms for your application. Both programs provide project windows that let you manage the various files in your application and save them collectively as independent projects. The functional interface elements that you place on your forms–buttons, sliders, list boxes, and all the other visual controls that can initiate or respond to events–are similar in concept between Delphi and VB, but the interface you use to manage them is slightly different, as
is the terminology.
In Delphi, visual and nonvisual components are available in a floating, tabbed window called the Component Palette, which normally appears horizontally at the top of the screen . Components reside on pages labeled Standard, Additional, Data Access, Data Controls, Dialogs, System, VBX, and Samples. These pages can be fully customized, and
new pages can be added. VB uses a simpler approach called the Toolbox. This is simply a floating palette of icons representing the program’s controls. You can add and delete Toolbox controls, but you cannot organize them into groups.
Although both products offer a similar design interface, they store their form information in very different ways. VB saves each form as a binary file with an .FRM extension. This .FRM file also contains any event-handler code you have written. Additionally, your program can contain standalone code modules with the standard .BAS Basic source-code extension. These modules are not tied to forms and typically contain global declarations and general-purpose functions.
Delphi uses two files to store the information associated with each form. The first, a binary file with a .DFM extension, stores the visual aspects of each form such as height, width, and color. Another file stores the code associated with the form as a contiguous block. This file, and every Delphi source file, uses the .PAS Pascal extension and is called a unit.
A new form is derived from the standard Delphi class TForm and created as a new class definition in the unit file.
Creating a new form might produce a type definition TForm1=class(TForm), for example.
As you place components on the form, new instances of each component’s class automatically appear inside the form object within the current form’s unit file.
While VB presents the event-handler code in each form as a series of individual so-called “snippets” attached to the various controls, Delphi organizes them as separate procedures within a single, contiguous code module. In VB, you can only view the snippets individually, while in Delphi you can view them all at once. Programmers accustomed to
working with traditional procedural code will feel more at home with Delphi’s approach.
Once you place controls and components on a form, each product gives you a way to set their properties through a GUI interface. VB’s Properties window lists all of the properties associated with the selected control or form. To attach code
to one of an object’s event handlers, you can double-click that object and then select the desired event handler (DblClick, for example), from a drop-down list box. When you double-click for the first time on a control, VB will bring up that control’s default handler. For example, double-clicking on a new command-button control will start a new
subroutine called Command1_Click().
Delphi makes properties and events accessible through a single dialog with two pages, called the Object Inspector.
Double-clicking on the procedure name associated with an event brings up the form’s unit file and starts you off with the framework for the procedure for that event. When you add a component to a form, Delphi creates a field for that component in the form’s class in code; the component’s methods then become part of the form’s class. Adding a
procedure to respond to the click event for Button1 on Tform1 produces
TForm1.Button1Click, for example.
Custom Controls
Although Delphi and VB both provide the flexibility to add custom controls to their environments, Delphi definitely has the upper hand in this department. In VB, custom controls use the .VBX format, a Microsoft-defined component format designed to extend the VB environment. There are many hundreds of third-party VBX custom controls that provide unique functionality or plug gaps in VB’s core feature set. VBXs, however, are special DLL’s usually written in C/C++;
you can’t create them in VB. In contrast, you can write Delphi’s components in Delphi. In fact, Delphi’s interface itself was written in Delphi.
To create your own Delphi components, you can either subclass any existing Delphi component or write your own from scratch. Once you’ve written the actual unit for your component, you register it with Delphi’s Visual Component Library, which automatically recompiles to include it. Though creating a component from scratch is an involved
process, subclassing existing components is straightforward; Delphi includes Component Expert, which steps you through creating a new component based on an existing one. You can also add standard VBXs to the Delphi environm
ent, which puts a component wrapper around them. You can even extend the capabilities and modify the behavior of a VBX using Delphi through subclassing. The Delphi Client/Server package includes the complete source code for all of the Visual Component Library components. As an extensible architecture, Delphi is first-rate.
Data Engines
Both Delphi and VB provide robust data-access capabilities through proprietary database engines that help abstract the developer from the back-end data sources and present uniform record-navigation methods.
VB 3.0 comes with the same Jet engine used in the powerful Microsoft Access database. Since it shipped before Access 2.0, however, VB 3.0’s Access 1.1 engine is not the latest version. A VB Compatibility Layer gives you the ability to work against Jet 2.0 databases, however.
Our testing showed that it’s a good idea to have Access 2.0 and VB on the same machine, when you’re working on database applications. In addition to the updated engine, Access gives you much better control over your database than VB’s rudimentary Data Manager utility. Jet stores all of the elements of a database as a single .MDB file and allows you
to attach tables in the .MDB file to remote data tables. VB and Jet together let you access ODBC SQL databases, as well as Access, Btrieve, dBASE, Microsoft FoxPro, and Paradox data directly. One of the most powerful features of Jet is its
ability to perform heterogeneous joins against different databases (say, Microsoft SQL Server and dBASE),and give you a unified, updateable view of that data.
There are two ways to work with databases in VB: through bound data controls and programmatically through Access’s Data Access Objects (DAO). Data controls provide the easiest solution. You simply place the data control on the form and set its DatabaseName and RecordSource properties to point to the database table or tables you wish to access. You can then use the data control as the record source for data-bound controls.
Unfortunately, only some of the editing controls in VB 3.0 are data-bound controls. The lack of data-control support for important controls such as the combo box and grid have spurred a number of third-party custom-control developers to fill the gap. The data control returns a dynaset, a dynamically updateable view of the underlying data. You have much more control, however, if you use the DAO support in the VB Professional Edition. This lets you work directly with tables and queries in code and gives you more
flexibility in returning and navigating the data. You can also reap some performance gains by implementing Jet transactions through code to batch updates, since a dynaset will normally update the database one record at a time.
Delphi Client/Server comes well equipped for database-oriented application development. Delphi uses the Borland Database Engine (BDE), the underlying engine used in both Borland’s Paradox and dBASE and the cornerstone of all Borland PC database products. BDE is a centralized data engine similar in concept to Jet. It can work directly with
dBASE and Paradox files, and–through Borland SQL Links–can access Informix, InterBase, Microsoft SQL Server,
Oracle, and Sybase. BDE also supports ODBC drivers, though it comes with none of its own. Borland SQL Links are optimized drivers that offer high-performance connectivity and let you take advantage of server-specific features.
Delphi also comes with the Local InterBase Server, a fully functional Windows version of The Borland InterBase Workgroup Server. This local engine can be used to develop applications for deployment later against remote SQL databases. It can also be distributed royalty-free with applications b uilt with the client/server version.
Although BDE abstracts your data source and provides consistent cursor management much as Jet does, it deals differently with its data. When Jet performs a query for a dynaset, it initially returns only the keys for the result set.
Then, in the background, or as requested, Jet retrieves the actual data for the dynaset. The user perceives a fast response time, even with huge return sets. BDE, on the other hand, will return all of the rows of a query to a local result set automatically.
Delphi includes two types of components for database access, one nonvisual and one visual. The nonvisual components, which provide the actual low-level links to your database, are located on the Data Access page of Component Palette.
Unlike VB, Delphi implements these low-level links using two layers of nonvisual components in order to provide a database abstraction before linking to visual components. The lower layer comprises two components, TTable and
TQuery, which provide the link to BDE and its data sources. You can choose to use either or both depending on your form’s needs. For each TTable or TQuery component on a form, you can attach one or more upper-layer TDataSource components. These serve as the link to all of your visual database components. Two other powerful upper-layer
nonvisual components, TStoredProc and TBatchMove, offer the integrated capabilities to execute stored procedures on a server and perform batch copy operations between tables or even disparate databases.
On the Data Controls page, you will find Delphi’s 12 visual data-bound controls, which let you build a user interface to your database. Delphi provides a broad range of components here including a bound grid, a navigator component for
performing basic cursor navigation and editing operations, bound labels, bound edit boxes, and bound radio-button groups. The DBMemo and DBImage components allow you to edit binary large object (BLOB) text and graphic data.
Two other components, the DBLookupList and DBLookupCombo, give you easy ways to present your users with scrollable lists of predetermined choices and to update database fields automatically with valid values. The list presented to the user can come from a different data source than the data source being updated. For example, an invoice-entry
screen might present the user with a drop-down list of company names and phone numbers and upon selection update an invoice table with the correct customer ID. The user never has to worry about the customer ID and you don’t need to worry about checking for valid entry. Overall, Delphi offers a good selection of data components that are on par with
third-party packages available for VB, and you are always free to whip up your own by modifying the standard components.
Like VB, Delphi lets you use SQL pass-through to talk directly to a SQL database without any BDE translation. While this does require more knowledge of your server’s capabilities, it lets you take advantage of server-specific functions.
One key advantage of using one local database engine to address multiple back ends is flexibility. Since Jet lets you create customizable attachments from Jet tables to remote data sources, and BDE lets you abstract data sources with aliases, you can build an application on one database and scale the application later to another database relatively easily.
Put to the Test
During testing at PC Labs, we built a section of a realistic database application that implemented a one-to-many order-entry screen. Our entry screen was rather ambitious and required access to five separate database tables. Our test script also required the creation of validation logic and implementation of referential integrity constraints. For both development systems, we first worked on local data in the tool’s native database format and then switched the connection to an identical database schema running on Microsoft SQL Server, Version 4.21. While both tools fulfilled the requirements of our test application, Delphi particularly impressed us with its broad database functionality, which required only minimal hand coding.
Delphi got us off and running quickly with its Database Form Expert, which stepped us quickly through the process of building a o
ne-to-many form based on our first two tables. The Database Form Expert creates the form, adds edit boxes for the fields of the primary table and a data grid for the secondary table, places the TTable and TDatasource components on the form and adds a Navigator component. From there, we simply added three more TTables and TDatasources for access to our Salesman, Order_items, and Products tables to get the data we needed. We ended up with two navigator components, one for browsing customers and another for orders; and a TQuery component that we used for adding orders.
For the tests with VB, we allowed Microsoft to use a set of third-party tools from Sheridan Software Systems:
Datawidgets 1.0d, Designer Widgets 1.0b, and VBAssist 3.5a. These three add-in products list for a total of $349.
Microsoft also used Access 2.0 to work with the database during the design process and to create SQL query statements visually. Access retails for $339.
Though this collection of tools gave us all the functionality we needed for our test application, we spent a considerable amount of time debugging it. The problem turned out to be related to some of the inherent limitations in the VB data control. One of its quirks is its behavior as you access the end of its record set from within code. Although the problem had nothing to do with the Sheridan controls, it took us a while to isolate the problem since we had a mixture of standard and third-party controls. In the end, our application performed flawlessly. Although the VB application required only
slightly more hand coding than the Delphi application, we found that the code was less readable since it was hidden behind various controls in their event handlers.
While Delphi and VB are well suited to RAD, there is no question that Delphi has one-upped VB in power. Delphi’s power, however, comes at a price: Delphi Client/Server lists for $1,995. In contrast, Visual Basic, Professional Edition, lists for only $339, leaving plenty in your budget for the third-party controls you’re likely to need. Much of Delphi’s
high price tag is because of the unlimited distribution license for the Local InterBase Server you get with Delphi Client/Server. From a visual design perspective, Delphi comes in about even with VB when VB is coupled with third-party custom controls and environment enhancements.
When it comes to coding, however, it’s a different ball game. Delphi’s Object Pascal gives you top-notch power for a language that is closely integrated with visual design tools. OOP, however, is certainly not for everyone, and VB makes coding a simple task for just about anybody.
Summing Up
For the professional who writes general-purpose applications, Delphi is superior to VB on many fronts and offers a highly viable alternative to such languages as C++. Hobbyist programmers are probably better served by VB unless they are seriously committed to learning OOP.
For corporate client/server developers–a market both Borland and Microsoft see as critical for success–the choice is more complex. Clearly, both tools are up to the task of building a wide range of client/server applications. Other factors you should consider include the current skill levels and language backgrounds of your programmers, your company’s willingness to adopt an object-based code-reuse strategy, the performance requirements of the application, and the type of SQL back ends you’ll be developing against. Corporations should also clearly examine any prospective tool vendor’s
long-term strength and stability as a business before standardizing on its products.
Within two years, we predict that the combination of visual development, object-oriented language, and incremental compiler as pioneered by Delphi will become as common as visual programming is today. While companies may feel uneasy about making the move right now, many will be considering pilot programs in the near future. Certainly, a
company that is not using visual RAD tools such as VB, Delphi, or one of their competitors is missing out on this decade’s biggest trend in software development.
Untold Contemplation 