"Rapid-development language" is a general term that refers to any programming language that offers speedier implementation than do traditional third-generation languages such as C/C++, Pascal, or Fortran. Rapid-Development Languages (RDLs) produce their savings by reducing the amount of construction needed to build a product. Although the savings are realized during construction, the ability to shorten the construction cycle has projectwide implications: shorter construction cycles make incremental lifecycles such as Evolutionary Prototyping practical. Because RDLs often lack first-rate performance, constrain flexibility, and are limited to specific kinds of problems, they are usually better suited to the development of in-house business software and limited-distribution custom software than to shrink-wrap or systems software.

Efficacy

Major Risks

Major Interactions and Trade-Offs

A weekend warrior using a nail gun, belt sander, and paint sprayer can slap together a doghouse a whole lot faster than someone using only a hammer, sanding block, and paint brush. The power-tool user is also more likely to make a trip to the hospital for emergency medical attention. And if quality is a concern, the power tools will be replaced or supplemented by old-fashioned hand tools anyway. The rewards, risks, and trade-offs of power-tool use in software are much the same.

By "rapid-development language," I am referring to a broad class of development environments that offer more rapid implementation than do third-generation languages such as Basic, C/C++, Cobol, Pascal, and Fortran. Here are the kinds of development environments I'm talking about:

In this chapter, I refer to these languages as "RDLs" for commonality with 3GLs (third-generation languages) and 4GLs (fourth-generation languages). In talking about RDLs, I am not specifically talking about class libraries or function libraries, even though you can apply many of the same considerations to use of those tools.

RDLs support rapid development by allowing developers to develop programs at a higher level of abstraction than they could with traditional languages. An operation that would take 100 lines of code in C might take only 25 lines of code in Visual Basic. An operation that would require opening a file, advancing a file pointer, writing a record, and closing a file in C might require only a single Store( ) statement in an RDL.

Because different programming languages produce such different bangs for a given number of lines of code, much of the software industry is moving toward a measure called "function points" to estimate program sizes. A function point is a synthetic measure of program size that is based on a weighted sum of the number of inputs, outputs, inquiries, and files. Function points are useful because they allow you to think about program size in a language-independent way. A low-level language such as assembler will require many more lines of code to implement a function point than does a higher-level language such as C or Visual Basic. Function points provide a common currency for making comparisons between languages.

Researchers have been able to derive rough approximations of the average amount of work required to implement a function point in different languages. Table 31-1 shows how function points relate to lines of code for programs of various sizes. Lines of code are nonblank, noncomment source statements.

This data is approximate, and some of the numbers vary a lot, depending on coding style. For example, some people use C++ as a type-safe version of C, in which case the C++ figure would be much closer to the C figure than the table shows. But on average, the comparisons between different languages in the table tell an important story.

Suppose you had a word-processing program that was specified to be about 5,000 function points. According to the data in this table, it would take you roughly 625,000 lines of C code to implement the word processor, 250,000 lines of C++ code, or 150,000 lines of Visual Basic code. It would take you roughly 25 percent of the code to implement a program in Visual Basic that it would take to implement the same program in plain old C. That difference can translate to a significant savings in development time.

In general, working in a higher-level language produces savings during both coding and design. Developers tend to be able to write about the same number of lines of code per month regardless of the language they use (Boehm 1981, Putnam and Myers 1992). When they use a higher-level language, coding goes faster simply because they write fewer lines of code for a given amount of functionality. Design also goes faster because less code means there is less to design.

In the word-processor example, you could cut the number of lines of code required by 75 percent by using Visual Basic rather than C. That means that you could cut your design and implementation effort by the same 75 percent. You might have other considerations that would force you to use C in spite of Visual Basic's savings potential, but if development speed is an important consideration, you should at least know what you're missing.

Table 31-2 shows the approximate "language levels" for a wider variety of languages than Table 31-1. The "language level" is intended to be a more specific replacement for the level implied by the phrases "third-generation language" and "fourth-generation language." It is defined as the number of assembler statements that would be needed to replace one statement in the higher-level language. Thus, on average, it would take approximately 2.5 assembler statements to replace 1 C-language statement or 10 to replace 1 Visual Basic statement.

The numbers in Table 31-2 are subject to a lot of error, but they are the best numbers available at this time, and they are accurate enough to support this point: from a development-speed point of view, you should implement your projects in the highest-level language possible. If you can implement something in C rather than assembler, C++ rather than C, or Visual Basic rather than C++, you can develop faster.

The table contains several other interesting data points. One is that the 3GLs are all roughly comparable: C, Cobol, Fortran, and Pascal all require about 100 statements per function point. The 4GLs, DBMSs, and visual programming languages such as dBase IV, Focus, Oracle, Paradox, Sybase, and Visual Basic are roughly comparable to each other too, each requiring about 35 statements per function point. Tools such as spreadsheets—which are occasionally viewed as end-user programming tools—boost productivity through the roof, needing only 6 "statements" on average to implement a function point that would require 128 statements in C.