At the end of Part One of my professional biography, I promised to come back to both my programming philosophy and why I entitled the piece the way I did. Let's get back to these ideas.
As a mainframe Cobol programmer, I learned the "Top Down" model of programming. This means to take a problem and break it down into smaller and smaller chunks. This is done iteratively, until a chunk is of a manageable size to be turned into computer code that can accomplish a very specific task. Then, the next chunk is tackled, translating part of a business or technical requirement into a program. And then, do the same for the next chunk. And again. And again, until the entire set of requirements has been translated.
There is nothing magic here, just the methodical, detailed, and painstaking transformation of an idea from one idiom to another. What has historically intimidated many people about this is just how detailed you must be to do this successfully. That, and the fact that programming languages are simply not natural expressions of how people communicate. Of course, when we program, we're not communicating with people, we're communicating with very persnickety machines.
Cobol is a particularly verbose method of communicating with computers. It is a third generation programming language. The first generation was binary machine language, 1's and 0's grouped into specifically sequenced patterns that matched exactly how the central processing unit executed them. The second generation was assembly language, mnemonic codes like ZAP and MVC and BLR that were slightly less cryptic representations of patterns of binary, that were translated into machine language by programs known as assemblers.
A third generation programming language is more human-readable than earlier generations. Its statements may resemble mathematical formulas or English-like sentences.
Consider the normal calculation for straight time pay, hours worked times hourly rate. In Basic, this could be rendered as: Pay = Hours * Rate. Contrast this with a typical Cobol rendering: Multiply Hours by Rate giving Pay. Both are easily comprehended, and the languages are much simpler to learn than a first or second generation language.
In both cases, and this trend has not only continued but accelerated with time, the drafters of programming languages have continually taken advantage of increases in computing power to make the job of the programmer easier. Languages are not only more comprehensible to more people -- there is less of a caste of programming "high priests" or "wizards" than there used to be -- but programming environments are more conducive to troubleshooting programming problems and to higher productivity in writing programs in the first place.
The syntax and grammar available in a language both shape how ideas are expressed and limit what can be expressed. Cobol was my primary programming language, counting school, for a decade and a half. That has had a profound effect on how I program, as well as on how I think about programming.
The top down development methodology imposes a discipline that is process oriented, which lends itself to Cobol quite nicely. Cobol is a procedural language, which means that the flow of control, the sequence of execution, throughout a program is in a straight line, step-by-step from beginning to end. Each Cobol program is a whole, a single unit, and each executable statement in a program can access and affect any piece of data being processed. This concept is known as "scope", and it's another idea we'll come back to.
There are statements in the language that cause program execution to branch to another place in a program; this is a necessary feature of all programming languages. Loops cause certain program instructions to be repeated over and over; subroutines isolate certain functionality in a single piece of code, which can be executed from wherever it is required in a program. Branching instructions, when used haphazardly, give rise to a programming style know as "spaghetti code". This means that you can jump from any point in a program to any other point, leaving an execution trail that resembles a plate of spaghetti. I learned a more disciplined style known as "structured programming", which requires a designed execution path through a program, where each subroutine has single entry and exit programs, and scope is designed to be limited rather than global.
Cobol and top down design combine to form a simple and straightforward programming methodology. This does not mean simplistic; this methodology is behind the majority of the world's business data processing. It is a rigid methodology; once development has started, it is not easy to change directions if requirements change.
When I returned to programming eight years ago, I became a web developer. I primarily used VBScript, Javascript, HTML, Internet Information Services, and the Oracle database manager. Except for Oracle, my development tools were either Microsoft technologies, or Microsoft implementations of web standards. All of these tools were philosophically aligned with Cobol and top down design.
In the years since, I have continued to support applications developed in this older mode, as well as having done new development in a newer methodology called object oriented programming. This is a radically different philosophy of programming than what I originally learned, one that I struggle with mightily, and the subject of the next essay in this series.
