CMP's TechWeb
spacer Click Here!
 Write to Byte
 Editorial Calendar

 Previous Weeks

Research Center

 Java Resources
 History Of Byte

 BYTE Humor
 Ian Shoales' Page

 Print Archives
 By Issue    By Topic

 About Us
 Byte Editorial Staff
 Sales Staff
 Privacy Policy

Sponsored by:
Click Here!

TechWeb Sites
 Bank Systems
     & Technology
 eBusiness Expo
 File Mine
 Insurance & Technology
 Network Computing
 PC Expo
 Planet IT
 TechWeb News
 TechWeb Today
 Wall Street & Technology

 Ad Info


Evolution Of Programming Methodology, Part II
Programming Languages Constrain Productivity

By Bill Nicholls

March 27, 2000

In This Article
  Evolution Of Programming Methodology, Part II

  The Missing Element

  MVC Changes The Conceptual Level

  Structure Of The Universe and Programming

  It's A BIG Job

Print This Article
One paradoxical aspect of computers and software is that the process of writing software, -- the price/performance of programmers, if you will -- has gained much less in productivity, compared to the evolution of computers and hardware themselves.

Last month, in Part I, I talked about why programmers' productivity has evolved much slower than hardware. Now, let's continue this examination and explore some ways to significantly improve matters.

Out of the chaos of early programming came insights into better methods and structures for writing programs. From the 1950s through the mid 1970s, these insights centered on the program text, it's structure, layout, and partitioning. Even though the program could be well structured, large programs were difficult to write. Part of the problem was the huge number of details that each programmer had to remember, and part was because of the exponential growth of human communications as the program complexity increased. Something beyond program structure needed to be addressed.

Looking back on nearly four decades working with computers, certain elements of the programming process stand out as essentially unchanged. An obvious example is the knowledge and level of detail required to develop a program in C or C++. In some aspects, they compare unfavorably to using assembler. The syntax is more complex, the structures can be even more obscure than assembler-level data definitions and the potential hidden problems easily exceed those of assembler.

In return for the extra details of C and C++, we are supposed to get portability, readability, and maintainability. Sometimes we do, but it is well known that one can write obscure programs in many languages, even unintentionally. It isn't my purpose to make C or C++ a strawman to knock down. They fall in the class of languages that leaves every decision up to the programmer. It is this requirement that the programmer handle all of the details that characterizes the first generation tools.

A later generation of tools, still called languages, hide varying amounts of detail from the programmer and provide default routines that can do the job or be overridden by the programmer. For many simpler or one-shot jobs, the inefficiency of the run time process is inconsequential to the total cost when you consider the jump in programmer productivity. Well-known examples of this class of tools include Smalltalk, Perl, and Python.

A third generation of tools is focused and specialized, yet very powerful. Here, the appearance of traditional programming is hidden. The programmer deals on a functional level and all of the details are handled by the tool. Into this broad class fall Tcl/Tk, AWK, Bison, regular expressions, APL, Finite State Machines, BNF grammar processors, and VLSI logic processors.

None of these tools has eliminated the drudge work of general-purpose programming. Even the Interactive Development Environment (IDE), a standard of modern development, has not changed the basic requirement of in-depth knowledge and voluminous typing. It, too, is a first-generation tool. Creating a program should not be like an old-time garment worker who assembled suits one hand-cut piece at a time, yet this is the way most programmers still work, almost 50 years after Univac I was delivered to the Census bureau.


    >>>Next Page

CMPnet spacer Click Here!