Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

The myth of code-centricity

Break through productivity barriers with a new software model

By Jack Harich, JavaWorld.com, 08/24/01

Page 2 of 7

Table 1. Software generations from the 1950s to the present

Generation language	Description	Examples	Key limitation
First (1GL)	Machine code	1101 0111 0011 0010	It's hard to think in binary.
Second (2GL)	Assembly language	SUB..PROC .........CMP....AX, 97 .........JL.........DONE	Rather tedious for general use. The sample shown is from the Intel 8086 family of processors (comments not shown).
Third (3GL)	Procedural languages	Java, C, Python, Perl, COBOL, BASIC, Smalltalk	Low productivity; historic average of 10 lines of code (LOC) per day per developer for the first three generations.
Fourth (4GL)	GUI tools with direct WYSIWYG	Drag-and-drop GUI builders, Dreamweaver, PhotoShop	Cannot handle most domains well because, in most cases, product does not equal image.

Each successive generation increased productivity by an order of magnitude. What can we learn from these generations? Why did they increase productivity so dramatically? Because each generation allows higher expressiveness through closer tool congruence.

Note that I have classified generations by quantum increases in productivity, not by conventions such as language constructs. Thus the four generations you see above don't match those defined in conventional wisdom. This classification prevents false generations from fooling us into thinking we have advanced.

The problem of tool congruence

As mentioned earlier, congruence is a measure of how closely two things match. Expressiveness is a measure of how well a tool lets a user accomplish a task. We each have a mental model of anything we build, including software systems. Tool congruence is how closely a tool's external appearance and use matches that mental model.

Thus, the more congruent the mental model and visual image, the more expressive a tool is. The more expressive a tool is, the more it becomes transparent to the user, and therefore the more productive it is. A well-designed tool disappears altogether if it completely merges your mental and physical activity.

For example, suppose you need to write some narrative text. Any reasonable 4GL text editor will let you do that in WYSIWYG style. This is 100 percent congruence because your mental model of paragraphs and sentences is the same as what the tool shows.

But suppose you must write a complex SQL statement with multiple tables and fancy joins. Your mental model is that of several tables with certain fields joined to other fields. This is not what a SQL line shows. Thus, using a text editor to write SQL results in a classic impedance mismatch and has low congruence. In this example, you can achieve high congruence with a GUI tool that allows modeling the SQL statement by dragging tables around and connecting fields to define joins. But not all domains can achieve congruence.

Currently, the most heavily used tools are either 3GL (such as code editors for C, Perl, Python, and Java) or 4GL (such as Dreamweaver, Visual Basic, and JBuilder). Visual Basic and JBuilder are a mixture of 3GL and 4GL. For more than 10 years, we've been stuck with 4GLs; the march of software generations has come to a roadblock.

 

Improve efficiency with Visual Studio(r) 2010 Beta 2. - Microsoft

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.