Before you answer, consider this quote from the FAQ section of Google’s blog post about the first release of its fascinating new programming language, Go:
Programming today involves too much bookkeeping, repetition, and clerical work. As Dick Gabriel says, “Old programs read like quiet conversations between a well-spoken research worker and a well-studied mechanical colleague, not as a debate with a compiler. Who'd have guessed sophistication bought such noise?” The sophistication is worthwhile—no one wants to go back to the old languages—but can it be more quietly achieved?
As someone who was peripherally involved in the creation of today’s ubiquitous, object-oriented programming languages, and who has also coded real-world-used programs in COBOL, FORTRAN, C, and a little-known gem called MODEL 204 User Language, the answer to the question of whether it’s time to toss away old programming languages for most IT shops with mainframes is: not yet. Why? Ah, thereby hangs a tale.
The Means Don’t Always Justify the Object
What follows is a grossly generalized hop, skip, and jump over the history of programming languages. It starts with recognition that there’s a rough, sharp dividing line around 1990 between pre-1990 “straight-line” languages and post-1990 “semi-object-oriented languages.” Today, if you’re a mainframe programmer (or even if you’re tending old Windows C programs), in most cases you’re doing straight-line programming. If you’re a Web programmer, by and large, you’re doing object-oriented programming.
At a 20,000-foot level, the difference between the two is as follows: Straight-line programming says to the machine executing the program, do this, then do this, then do this. It’s an intuitive way of programming. Object-oriented programming requires a mind shift: It says, view a program as a set of independent pieces of code (“objects”), sending messages to each other, with the program itself shifting from object class/state to object class/state. Such a program is assumed to run forever; an example is software on one machine handling communications from other machines. The machine waits for inputs, changes state, depending on the input to respond appropriately, and then waits for the next input.
The virtues of object-oriented programming have been rehashed so often we tend to forget there are many problems this approach didn’t solve. Among the key virtues of object-oriented programming:
• It’s superb for representing Windows-type user interfaces with their icons and “virtual screens.”
• It provides a way of improving program quality by “proving” the correctness of a piece of code without needing to revisit it in another program; it does this by isolating the program as a separate “class.” For example, many of today’s object-oriented programming languages allow “assertions” in classes to double-check error-handling.
• It helps decouple software from a particular machine; e.g., a Java program can run with its own little “virtual machine” that’s easy to transfer online from one machine or operating system to another.
However, for various reasons, object-oriented programming languages as implemented were and are deficient in two related areas:
• Data processing
• Hardware and software parallelism.