Snarled
Storage
(Evolution of
Programming Methodology, Part I , Page 3)
By Bill Nicholls
February 28,
2000
A
form of shared data storage known as Common was used
extensively. This enabled further growth in program size. A
Common definition of variables and arrays was created in the
main program, and each subroutine needed to define one
exactly like it in terms of variable type and size,
but alas, not in name. Common proliferated, and became Named
Common and plain Common. Names inevitably differed in the
subroutines, from the main program, and from each other.
Another level of chaos had developed.
Programmers developed their own standards for using
Common. Where multiple programmers collaborated, as was
becoming typical on large projects, someone was chosen to
manage the interconnection between subroutines. Common
gradually came under control as a standard deck that was
duplicated and placed in each programmer's box of cards. The
cards were another hazard for programmers. Dropping a 2000
card box was a major disaster. Not only did you have to put
the cards back in order without sequence numbers, but then
it took a pass or two through the compiler to work out the
bugs caused by your missing a few misplaced cards. A dropped
box was typically equivalent to three days lost time.
Those programmers who have worked in the field less than
25 years probably haven't seen a punched card. Cards were
the ubiquitous form of source and object code, developing a
whole sub-industry for supply, from key punches to card
readers to storage cabinets. Slightly larger than a dollar
bill, it was made of paper to exacting requirements for
dimensions, stiffness, and strength. Numerous companies
jumped into the supplier ranks with less-expensive supplies,
and while the card remained the primary storage for
programs, made significant profits on a commodity product.
Structured Programming
The next step in the
evolution of programming methods came with the introduction
of structured programming (SP). This concept was described
in a paper by, you guessed it, E. Dijkstra titled
"Structured Programming." It was printed in a NATO sponsored
Science Committee report in Italy, 1969. This eight-page
paper succinctly describes the concept, a program "As a
string of pearls" created by carefully crafting modules into
a whole process. He was way ahead of his time in 1969, and
30+ years later, still ahead of quite a few practitioners.
This was a significant step in that it was the formal
recognition of the importance of design in computer
programs, and supplied a methodology that produced improved
designs. At the time this was seen by others as the
answer to programming problems. Now any project could be
built successfully, and many of the early uses of SP worked
well.
As with all tools, exploration of its limitations was not
long in coming. SP let larger and more complex programs be
undertaken, which was enabled by larger and faster
computers. Once again, the process created its own downfall,
a kind of evolutionary death caused by hypergrowth. Even
with those problems, the programming community was
developing techniques to handle larger and more complex
programs. Despite the weaknesses of SP, it offered another
step in greater complexity.
<<<Previous
Page >>>Next
Page
