"Of all the monsters that fill the nightmares of our folklore, none terrify more than werewolves, because they transform unexpectedly from the familiar into horrors. For these, one seeks bullets of silver that can magically lay them to rest."The familiar software project (...) has something of this character; it is usually innocent and straightforward, but is capable of becoming a monster of missed schedules, blown budgets, and flawed products. So we hear desperate cries for a silver bullet - something to make software costs drop as rapidly as computer hardware costs do.
"But, as we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity."
-- Frederick P. Brooks (author of "The Mythical Man-Month")
"If you have a $5 head, wear a $5 helmet"
-- Motorcycle Helmet Ad
The choice of a computer language and/or environment cannot guarantee the success or failure of a project. Many excellent products have been produced with awful tools, and many terrible products have been produced with wonderful tools. Software development is a creative, poorly understoood process where the selection of the right people is far more important than tools, methodologies, or environments.
That said, selection of appropriate tools for a given task can have a profound effect on productivity. Whereas no tool can be a "silver bullet" that automatically produces results, an inappropriate tool can actively hinder the software developer in his job. The process of software development is difficult enough without hindrance from inadequate tools! Conversely, appropriate environmental support can be a great help.
In that spirit, I wish to present some of my reflections about tools that could possibly be used for upcoming software projects, and where they might or might not be appropriate. Following this analysis, I'll describe some of the experience that has lead me to these opinions.
I wish to emphasize this analysis was written with a particular type of software in mind: Specifically, business systems written for the Medical industry. I do not think that the conclusions reached in this analysis apply to all software development! Further, this analysis was written in December of 1994, and the world changes. The conclusions reached herein may well be dated in short order... All four languages considered are undergoing active development, and limitations that were present as of this writing might have been fixed by the time you read this.
In this analysis, I largely ignore the cross-platform implications of various choices. If it were judged important that upcoming products be capable of running on more than one platform, that would rule out a large number of tools. This analysis assumes that products who's client side is limited to the various flavors of Microsoft Windows will be adequate.
Visual Basic is a simple, appealing tool for the development of simple GUI applications. It is very easy to learn, and can be productively used by someone familiar with basic GUI concepts within about an hour of first using it. It has the further advantage that it is inexpensive, and that third-party extensions (basically widget toolkits in the form of "VBX" libraries) are readily available.
Visual Basic fills essentially the same role as a 4GL, or a scripting language. It makes it easy to write simple applications. It is without a doubt an excellent tool for a non-programmer to use to create an empty GUI prototype to get an early idea of the look-and-feel of an application (in fact, it was used with great success in just this way in a previous project at Medicus). It may also be appropriate for developing a class of relatively simple programs, such as programs to maintain an administrative database.
There are some problems with the current implementation of Visual Basic. Visual Basic is a "Win 16" application, and has some limitations that result form that (such as lists that can hold only 64K of data). Also, it is basically a naive interpreted (P-code) system, which makes it one or two orders of magnitude slower (than C, for example) for computationally-intensive operations. Limitations such as these, while serious, are not fundamental to the Visual Basic approach, and I shall not explore them here.
A more serious drawback to doing any kind of serious development is the total lack of support for dependency management. The Visual Basic language lacks the features necessary to support traditional structured programming, much less object-oriented programming. Following are some of the key abstraction mechanisms missing from Visual Basic:
Given these limitations, it would be extremely difficult to develop (much less maintain!) an application of any complexity in which non-trivial application logic were expressed in the Visual Basic language.
There is an alternative use of Visual Basic that does not suffer from the above disadvantage. That is to use Visual Basic as a scripting language to write the GUI front end of an application, but to write the real application logic in some other language, typically C++. In this scenario, Visual Basic would be used for little more than its GUI builder, and perhaps implementation of some of the simpler parts of the application.
At first blush, this might seem an attractive notion: combining Visual Basic's ability to rapidly develop applications with the advantages of C++. I believe that this appeal is illuisory, based on the following observations:
To summarize, Visual Basic is a tempting language, because it is simple to learn and to use. It is unsuitable, however, for any serious application development, because it does not support good software engineering practices (such as modular design, information hiding, and object-oriented programming).
C++, from a software engineering perspective, is a giant leap beyond C. With proper program design, a project written in C++ stands a much better chance of being correct and maintainable. This is due, I believe, largely to the superior encapsulation provided by C++. One can approach a "design by contract" style of programming by carefully following a set of conventions and rules within a C++ program. Another crucial benefit of C++ is that it supports the object-oriented programming paradigm. It is also a very popular language, so compilers and other tools are readily available.
Some of the benefits of C++, however, have been oversold. C++ largely fails to deliver on its promise of being easy to assimilate by C programmers. Though superficially similar, the kind of appreciation of C++'s strengths that it takes to really effectively exploit C++ take much longer to absorb. Learning C++ does not necessarily lead to learning object-oriented programming.
Some tool vendors (notably Microsoft) have contributed to the overselling of C++. They seem to be trying to convey the impression that their tool can automate much of the task of programming (in Microsoft's case, through various "wizards"). What these tools really do is provide a slick veneer over the easiest part of software construction, that is, the writing of an empty application skeleton. These tools are valuable and do have their place, but in the "big picture" of writing any significant application, their contribution to productivity will probably be minimal.
The design of C++ is very much an engineering compromise. Two of the stated goals of the design are "backwards compatibility with C code" and "no runtime penalty for language features that are not used". Further, C++ inherits the strong runtime-efficiency bias of C, which makes a great deal of sense for writing operating systems, but is of less value for typical business applications.
In part because of some of the compromises made in the design of C++, it suffers from some pitfalls, particularly when one tries to implement a large system. Succinctly, C++ applications often don't scale well. Some of the problems that hamper the development of really large systems with C++ are:
In summary, C++ is an important, popular language that provides fairly good support for the development of small and medium-size applications. It allows a fair amount of encapsulation, and it supports the object-oriented paradigm. It has its share of quirks and failings, however, notably in that it is easy to introduce subtle, hard-to-debug runtime errors.
Eiffel is a statically-typed language that is simple (to use), robust, powerful and elegant. It does not suffer from any of the failings of C++ listed above, and it is outstanding in its concern for supporting the production of reliable, well-engineered software. Unfortunately, it is not very popular, and the tools that are available for it (notably the GUI widget sets) are somewhat immature. Applications developed using Eiffel would probably not be competitive for Medicus' target market, at least in terms of GUI look-and-feel.
Smalltalk is a language initially developed by the Xerox Palo Alto Research Center during the 70's and early 80's. Smalltalk was one of the first languages used to create GUI applications as we know them today, and it was the second important "object-oriented" language (after Simula). Smalltalk is available from several vendors on many platforms, and offers a number of benefits.
Like all languages, Smalltalk has its disadvantages, too. Some of them are:
Some of the advantages are:
The claim of "2 to 5" time productivity increase may seem incredible, but I personally find it to be fairly believable. I base this on my experience working both with C++-style development environments (with their long compilation times) and with environments offering a more interactive style of development (for example, the Smalltalk environments I've used, and the Symbolics Lisp machine). Of course, no language can remove the inherant complexity of software development ("there is no silver bullet"), but Smalltalk (and other systems like it) relieve the developer from much of the low-level "grunt work," such as chasing down memory bugs, exploring class hierarchies with a text editor, and waiting extended periods of times for rebuilds. The cumulative effect of this kind of environmental support can be of great significance.
Smalltalk environments provide particularly good support for rapid applications development during a prototyping phase. The highly interactive and responsive nature of a Smalltalk system can lead to extremely quick production of functional prototypes (or simulations) that can serve as the basis for production of the final system.
One claim that is often made against Smalltalk is that it is slow, and that systems that are developed with it are overly large. These criticisms may have been valid ten years ago, when Smalltalk technology was not as well developed, and when machine resources were very much more expensive. In today's environment, however, Smalltalk programs are very competitive in terms of size and execution speed, particularly for typical GUI business applications.
In summary, Smalltalk combines the quick turnaround time of Visual Basic with the abstraction abilities and support of the object-oriented paradigm that C++ has. It is an excellent choice, particularly during the early development phase, but also during production and maintenance. Generally speaking, developers working with Smalltalk can produce applications faster and with fewer bugs than developers using C++.
Unfortunately, I am not in the position of having written large systems with each of the above four environments. I have, however, had experience with many similar systems.
With Visual Basic, there's not much to learn. I've written a few trivial programs to explore it, and I've spoken to people who have written larger systems. To explore some of its limitations, I tried to do something that wasn't built in to the language: I tried to customize the behavior of a widget a bit. I attempted to make a combo box that is like the one one gets when searching for help: one where typing text into a box positions the list below to the closest matching entry. This does not come with Visual Basic (although it is probably available as a .VBX add-on from various third-party vendors), but I wanted to know if it was possible to do it within the Visual Basic language, extending existing components. It's not. Without going into the details, Visual Basic does not give the programmer adequate access to the workings of their widgets to use them as a base from which to build.
This experience has implications for any serious use of Visual Basic: It suggests that developing a widget that doesn't already exist will be challenging, certainly requiring development in C or C++, and probably requiring re-implementation of facilities that are present in Visual Basic, but not exposed to the developer. This is in contrast to a system like Motif or Galaxy where subclassing is supported (and even encouraged). Another way of saying this is that Visual Basic is not easily extensible.
In the C/C++-with-GUI-builder environment, I have had extensive experience, both with Galaxy and C++, and with Motif and C.
I have not had much direct experience with Smalltalk. (Note: Since the writing of this paper, I have used Smalltalk quite a bit more than described here!) In my spare time, I've experimented with two Smalltalk environments, and developed a few small programs. I have, however, had some commercial experience with a similar environment: A Common Lisp GUI workstation. In this project I got a taste for the kinds of productivity gains that can be had by proper environmental support for interactive development.