Oct. 15, 1956: Fortran Forever Changes Computing’s Fortunes

davidw · on Oct 15, 2009

This is relevant:

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).

10ren · on Oct 15, 2009

FORTRAN may well be eclipsed, but like the moon, it's still there.

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.

jacquesm · on Oct 15, 2009

It's interesting how probably FORTRAN will never go away.

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.

vorador · on Oct 15, 2009

You must mean, between lisp and lisp, I presume.

jacquesm · on Oct 15, 2009

No, I meant LISP and FORTRAN, which is why I wrote that.

LISP as the arch functional programming language, and FORTRAN as the basis for the imperative branch.

jonsen · on Oct 15, 2009

I know what you mean, and agree on that. But LISP and FORTRAN are two different things as I see it. LISP is a bridge between the lambda calculus and the actual machine. FORTRAN is not a bridge between the machine and a fundamental theoretical construct like say the Turing machine. FORTRAN is just an attempt at abstraction away from the machine. You might say LISP is an implementation where FORTRAN is a construction.

jacquesm · on Oct 15, 2009

It's like math vs engineering to me.

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.

wglb · on Oct 15, 2009

It was indeed a godsend. However, my own young brash impatience for fortran to change led to a very fun career in compilers.