Programming, the Coming of Language

(Continued from Programming, the Early Years)

The thought was that if the languages would be more human like so it would be easy for people to create software then there would be no need for programmers. The earliest programming languages were created to allow scientists and researchers the ability to write programs themselves which is why FORTRAN is considered to be the first high-level programming language. The idea here being that  The programs in these higher level languages would be run through a tool called a compiler which either converted the program into assembly language (which would then have to be ran through an assembler) or straight into machine language.

While higher level languages made it easier to create programs, learning how to program was still a chore. The fact that the programs were ran in batches so there was a long delay between writing code and seeing the results was the biggest culprit. Computers, thankfully, continued to grow in power to the point that there were a lot of waisted computer cycles. To better utilize the hardware, time-sharing systems and terminals started appearing. This lead to the obvious idea of having programming languages that were interactive in nature. By interpreting the code instead of compiling the code it was possible to write programs in real time.  The downside to interpreters were that they were significantly slower than compilers.

Another issue that was becoming bothersome was the fact that every machine had a different machine language. Sure, you could simply write programs in high level languages and compile it for the different computers that the program had to be ran on, but different compilers for the same language would compile the code differently so idiosyncrasies were common place. The term for moving code from one computer to another is porting. The fact that a term was created to describe this problem (which still persists today) should tell you that it was not a trivial problem. UCSD Pascal solved this problem by compiling code to a virtual p-machine language. The computer would then interpret this virtual p-code. Because p-code was essentially machine language, the computer could interpret this code much faster than an interpreted language could be ran. Still, it was slower than code compiled for a particular machine. When micro-computers started taking off, the speed difference became a big factor in commercial software sales.

While it seemed that compiled code won, computers continued to grow faster to the point where they were more than fast enough to accomplish most common tasks. At the same time, the internet  started taking off. Sites wanted to be more dynamic but had to be not only cross-platform but cross-browser compatible. Both interpreters (JavaScript) and virtual machines (Java) were used to accomplish this. To make the virtual machine fast enough, a new technique called Just-In-Time compiling was developed. The idea here is that the virtual machine code is compiled into native machine language as it is ran so code will run much faster.
The concept of a virtual machine running on the browser seemed to me to be the best solution. Sadly, for a variety of reasons Java never became the browser language of choice but instead ended up largely on the server. Flash is currently the virtual machine of choice for browser programming, but JavaScript is probably the most common choice for web development. The only thing holding JavaScript back is the lack of some of the Rich Internet Application features, but HTML 5 is pretty much solving those issues. It will be a few years before HTML 5 becomes the standard, but with Google, Apple, and Mozilla pushing for the standard it is possible to take advantage of a lot of HTML 5s features right now.

So we have gone from writing code in machine language to compiling the code into machine language to running the code in an interpreter. What is really interesting is that changes in hardware is what drove programming evolution. Computers are now so fast and have so much memory that programmers no longer need to concern themselves with writing efficient code. What matters now is that the code that is written is finished quickly. Sure, many programmers want to write efficient code but they only have to write efficient code in the increasingly rare case where the program runs too slow. What is worse is the fact that programming has moved further away from machine language that there are many programmers who don't really understand what the computer is actually doing. That, however, is a subject for another day.