Evolution Of Programming
Methodology, Part II
Programming Languages
Constrain Productivity
By Bill
Nicholls
March 27,
2000
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
