After the initial successes of the computer (breaking German codes and calculating logarithms), the field ran into two problems. Firstly, the machine itself was slow—or at least slower than desired—for the new problems at hand. Secondly, it took too long to write the instructions (code) that the machine would execute to solve the problem.
Making the machine itself faster was largely an engineering problem. The underlying substrate went from steam and valves to electromechanical relays to vacuum tubes to integrated circuits. Each change in the substrate improved the rate at which instructions could be executed. This form of progress, while interesting, is outside of the scope of this book.
Once computers evolved past needing their programs to be wired up, programmers were free to start expressing their algorithms as text, in a programming language. While typing is faster than running wires, it has its own issues. Fortran was one of the first languages to address them successfully.
Early languages were generally not very human-friendly. It took specialized training to be able to write (and read) programs written in these languages. Programmers would often add comments to their code, either within the code itself or in external documentation, but the problem was deeper. The languages themselves were cryptic.
For example, the following code in x86 assembly language determines whether a year is a leap year or not (from http://rosettacode.org/wiki/Leap_year#X86_Assembly):
align 16
; Input year as signed dword in EAX
IsLeapYear:
test eax,11b
jz .4
retn ; 75% : ZF=0, not a leap year
.4:
mov ecx,100
cdq
idiv ecx
test edx,edx
jz .100
cmp edx,edx
retn ; 24% : ZF=1, leap year
.100:
test eax,11b
retn ; 1% : ZF=?, leap year if EAX%400=0This is the first problem Fortran addressed. Fortran set out to be more readable. An important goal was that mathematical equations in code should look like mathematical expressions written by human beings. This was an important step in enabling coders to express algorithms in terms that they themselves understood, as opposed to a format the machine could directly work with. By comparison, a Fortran function to determine whether a year is a leap year reads easily (from http://rosettacode.org/wiki/Leap_year#Fortran):
pure elemental function leap_year(y) result(is_leap) implicit none logical :: is_leap integer,intent(in) :: y is_leap = (mod(y,4)==0 .and. .not. mod(y,100)==0) .or. (mod(y,400)==0) end function leap_year
The first languages were specific to the machine they were meant to run on. A program written on one machine would not run on another. This led to the wheel being reinvented often. Consider a sorting algorithm. Many programs need to sort their data, so sorting algorithms would be needed on many different computers. Unfortunately, an implementation of quicksort on one machine, in that machine's language, would not run on another machine, in its language. This resulted in many, many reimplementations of the same algorithm.
Also, a programmer who knew how to write code on one machine had to relearn everything to use another. Not only was it difficult for talented individuals to go where they were needed, but also buying a new machine meant retraining the entire staff. The first thing the staff then did was rewrite all the existing (working) code so that it would run on the new machine. It was a tremendous waste of talent and time.
This is the second problem Fortran addressed—how can a program be expressed so that it runs on more than one machine (that is, how can programs be made portable)? The goal was that if a program was written in Fortran on one machine, then it would run on any other machine that supported Fortran.
To this end, Fortran compilers were developed. A compiler translates a program in one language (Fortran in this case) to another language (the language of the machine the program would run on).
While readability and portability were important, no one was going to use Fortran if the resulting program ran slowly on their computer. Early coders expended immense amounts of time and effort making their code run as quickly as possible. Problems were big and computers were slow and time was money.
This is the third problem Fortran addressed—and its solution—is the primary reason Fortran is still in use today: Fortran programs run fast. The details are out of the scope of this book but the result is clear. Algorithms expressed in Fortran run quickly. Fortran was designed that way. Implementations are judged on their efficiency, compilers generate clean code, and coders always have an eye on performance. Other languages have surpassed it in terms of readability, portability, and other measures of quality, but it is a rare language that measures up in terms of efficiency.
It is important to understand some of the environment that Fortran programs were running in when it was first developed. While we are used to a computer running multiple programs simultaneously today (multitasking), early computers ran only one program at a time. The programs would sit in a queue, in order. The operating system would take the first program, run it from beginning to end, then do the same for the next program, and so on. This form of job scheduling is known as a batch system.
Batch systems are very efficient. At the very bottom of things, a processor can only do one thing at a time. A multitasking system just switches what the processor is doing from one thing to another very quickly, so it looks like multiple things are happening at once. This makes for a smoother user experience; however, multitasking systems can spend a lot of time doing this switching.
Batch systems can devote this switching time to running the program. In the end, the program runs faster (although the user experience is degraded). Fortran, with its emphasis on speed, was a natural fit for batch systems.