Oct. 15, 1956: Fortran Forever Changes Computing’s Fortunes
wired.com
wired.com
http://journal.dedasys.com/2008/12/04/the-economics-of-progr...
Summed up: for 50 years, programmer time has been getting more expensive relative to machine time, so optimizing for programmer time makes sense (in broad terms - clearly there are plenty of cases where speed matters).
This article gives reassuring answers to the question of: "If FORTRAN is the solution, what was the problem?" Portability and ease of use.
The latter is an open-ended problem, and there is still opportunity for progress in it today.
First mover advantage case study.
What is also interesting is that between LISP and FORTRAN we seem to have the two lineages that combine all programming mechanisms that we are aware of.
LISP as the arch functional programming language, and FORTRAN as the basis for the imperative branch.
Programming is a way to get a machine to do stuff. You can approach that problem in different ways.
Whatever 'method' you use, the most important metrics are 'are the results good' and 'is the program maintainable' and 'is it reliable'.
To see the 'lessons' from both sides put in to practice in (relatively) new languages (such as Erlang, or Python) is where the intermediate future lies.
What I'm really curious about though is not so much which of the LISP or FORTRAN descendants is the 'best' for any given purpose, give it enough time and we'll find that out one way or the other. My real question about all this are there other paths besides these two that have not yet been explored ?
Logic programming is sometimes seen as a 'third branch', but is possible that there are ways of achieving results out there that are not as obvious as any of these and that yet hold in them a kernel of what we could do to get out of the absolutely unmaintainable mess that software is becoming.
It is not an 'engineering' discipline by any standard, yet, and if all this is to 'end well' I think it should be.