A brief (and irreverant) history of programming
The Triumph of Objects
The very first programmers did their work with soldering irons. At that time, the algorithm was encoded in an electrical circuit. Weird as this sounds, the technique is still used today. For example, custom circuits for encoding and decoding CD-ROMs are essentially programs that have been expressed as a specialized electrical circuit.
Von Nuemann is the person credited with the inspiration to make a general purpose circuit that could execute different algorithms, depending on what data was input to the device. The program for this type of device was data that described how the circuit should configure itself for each step in the algorithm. This lead to programming languages that look something like:
move <some memory location>, Register1
move <some other memory location>, Register2
add Register1, Register2
jz <some location in the program> # jump on zero
These kind of languages, called assembly language, are also still used today, but mostly by people with very specialized jobs. Generally, concerning oneself with details of the computer's internal operations is a separate task from whatever problem the programmer really wants to solve.
Fortran was the first language that attempted to frame programming in a way that was well meshed to human thought. It organized data by introducing named variables and arrays, and control structures that were natural language-like, assuming that when you want to count to 10 in increments of two, you would say "do 'i' equals zero comma ten comma two print 'i' done.", or some such.
Fortran's small success inspired no end of "higher level" languages that tried to be an even better match to how humans solve problems. Cobol was the businessman's version of Fortran and Fortran became the "scientific" programming language. Many would be successors seemed to arise from an infatuation with some particular programming technique: Lisp expresses everything as a list and makes its adherents have fun trying to pronounce "caddadr". Forth used a stack as the ideal model of everything. Prolog and sendmial.rc expressed everything has rules of inference. There were many others.
However, it was C that next held sway. C was a modest improvement on Fortran. It introduced ways to organize data of mixed types, more control structures, and recaptured some programming functionality that was present in assembly language, but not expressed in Fortran, such as, manipulating memory addresses, manipulating binary data, and making recursive subroutine calls. C's simplicity and power set a high bar for would-be successor languages. Ada, Pascal and Modula-2 are among the languages that failed to over-come this threshold.
The wedge-everything-into-some-mental-model-folks eventually triumphed. They came up with a mental model that was admirable in its lack of specificity, an object. They also managed to co-opt C into this model by inventing a feature bloated super-set called, C++. Objects have emerged as the orthodoxy of modern programming. Adherents will give you some clap-trap about the power of polymorphism, inheritance, and so on, but objects are vague enough that they don't force you to program in any particular way. You don't have to use a list, or a stack, or an inference engine.
I think the real utility of objects is that they provide a way to contain complexity. Expectations for what a commercial software program does have grown to a point where a single program consisting of global variables and functions is unmanageable. The potential internal interactions are just too much for any one person to grasp. Objects help to break a large program into self-contained chunks that can be divied up between people, or focussed on by a single person at different times.
It seems that all programming languages that are currently popular, support an object model. Almost all also use some slight variant of C control structures, operands and programming syntax. However, I think that the success of this approach has more to do with the requirements for organizing the work of groups of programmers than it does with meshing human thought to how computers work. In fact it sometimes seems that true believers take a certain amount of pride in pointing out that objects are a different way of framing problems that the uninitiated just don't get.
In one sense objects are also not more powerful problem solving tools than anything else. All programming languages are basically glorified PDAs (Push Down Automaton), and in a mathematical sense, the set of problems that they can solve are the same. In a practical sense, there can be large differences in ease of expressing an idea in one language, or conceptual framework over another, but we should remember that we are talking about taste and psychology rather than absolute facts.
No comments yet.
More by this Author
- 0Chinese idioms - Suyu and Chengyu - explained, Chengyu are a cultural phenomena particular to Chinese
A brief explanation of different kinds of Chinese idioms written for non-Chinese speakers.
A brief introduction to some techniques and principals for leaving the dock under sail in a sailboat.
x squared, integrated, differentiated and re-integrated. This hub builds on work done in previous hubs and uses some powerful techniques from both mathematics and programming. If you recall calculus, derivatives and...