I first learned FORTRAN in high school, where we used optical sense cards to create code. The teacher took them each night to the board office and brought back our output for the next class. If you had ten days for an assignment, you had ten chances to compile/run. The next year the school got a Commodore PET and I had a chance to use that.
I still code - and have just finished converting some FORTRAN astrophysics simulation code from 1974 into C# for a Unity project.
My first job was writing actuarial software in FORTRAN. You submitted your compilation job to the IBM 3090 job queue in the evening and got back the compiled code in the morning, which you tested on a dataset.
> converting some FORTRAN astrophysics simulation code from 1974 into C# for a Unity project
But FORTRAN is SOOOO fast. In R there is still plenty of FORTRAN code running. I still would want the code running FORTRAN and try to figure a way for it to run as is.
I understand the need for it to run in Unity but just I hate the idea of all FORTRAN code needs to be converted.
A language efficiency is about how convenient it is to use for humans to express and absorb ideas about solving a problem.
A lot goes into that. It starts with programmers training to look into problem some way, which allows to formalize the task - as in conversion of a physical problem to a mathematical model.
Then it proceeds to offer good abstractions to use for problem statement. Those abstractions should be convenient - a reasonable set, a generic nature, a good correspondence to "the real world".
Then composability of those abstractions should allow more convenient canned solutions to common subproblems - which are libraries.
Last two parts require to carefully select the language syntax.
It turns out it's tricky to have a language which is good enough for every possible problem to solve. It's also hard to have a good set of composability features - usually you have one set of several possible, and you don't have at the same time all possible mechanisms to combine and use primitives.
I'm not sure Fortran compares well with existing offerings. Literal "formula translation" is a basis of several language philosophies (APL comes to mind), and in non-numeric applications there are other issues.
> A language efficiency is about how convenient it is to use for humans to express and absorb ideas about solving a problem.
That's one kind of efficiency. There are others. One kind that often comes up Fortran is "efficiency of using the CPU". Fortran is pretty good at that kind of efficiency. For people using months of supercomputer time, that kind of efficiency is pretty important.
> One kind that often comes up Fortran is "efficiency of using the CPU".
I think that's rather efficiency of implementation of the language's compiler.
Yes, given particular hardware properties, it might be beneficial to have language enforcing programmers to use mechanisms, which are easier (for translator) to convert to hardware instructions.
One reason Fortran is still so performant is that processor manufacturers devote a lot of resources to making sure that there are highly optimized compilers for their latest architectures. This is partly so that they will look good in benchmarks, but the scientific computing community benefits.
"John W. Backus suggested to IBM a language to replace assembly language."
And today, in a world with far more CPU homogeneity, we have an endless stream of nerds suggesting to HN languages to "replace" C.
I am never sure what "replace" means when used in this context. I'm still using assembly language; other languages cannot match it. In the same way, FORTRAN is still being used. Perhaps "supplement" should be substituted for "replace".
Enduring fact: "Your Father's" languages are more performant than the new ones you hold in high regard.
Because performance will always be important to some people, I doubt these old languages will ever disappear from use.
Unless someone can construct a compiler that accepts a different "language" and produces more performant object code, these languages will never be "replaced".
> I am never sure what "replace" means when used in this context
It means the use of assembly is replaced with the use of Fortran. At which it was very successful in scientific computing.
I don't believe it was ever meant to mean exterminate. Bear in mind that all programming was done in assembly or machine code prior to the introduction of Fortran. Since then a relatively tiny (though important) proportion of programmers program in assembly. That was the intent and it worked swimmingly.
> Enduring fact: "Your Father's" languages are more performant than the new ones you hold in high regard.
I don't know if I buy this. Common Lisp and even to an extent Scheme as we know them today are much faster than the MacLisp of many decades ago. Sure, we're not replacing FORTRAN or C with Python or Ruby, but I think it's disingenuous to say that we haven't gotten better at optimizing newer languages. Even in that same token, C and FORTRAN have changed significantly since the 80's, and C11 hardly looks anything like what C used to be.
Further to the original point, we have Javascript VMs that are incredibly high-performance. Even more-so, C++ wasn't even around at the time of FORTRAN, does that still count as my father's language? I wouldn't say so, and in summary, I don't think performance is the reason we hold on to old languages.
Back to your original point about "replacing" languages: I think you're speaking too broadly. For example, nobody in the high-performance-computing space will likely replace FORTRAN or C for tight mathematical operations, especially when large datasets are involved. However, in the general case, I'd say that FORTRAN and C have been replaced in a lot of other industries. This is especially so in industries where exact hand-written assembly or low-level C don't make sense for the 98%+ of cases. Nobody in their right mind would write scientific computing software in pure assembly. Even if you argue that most of the heavy lifting in Python+Numpy or MATLAB or Julia comes from C libraries, you don't typically interact with the underlying C or FORTRAN from day to day. In many ways, we've replaced C and FORTRAN, even if they're not gone from the annals of history. And given how long software sticks around (even once we've tried killing it), they likely will not be eradicated for a long time. The point, then, is that replacing these languages is just a means to give us better abstractions so we don't have to think on the terms of older languages. There's been a lot of expressiveness gained from language research that have benefited humanity in immeasurable ways.
>Unless someone can construct a compiler that accepts a different "language" and produces more performant object code, these languages will never be "replaced".
I hate to bring it up, but Rust, asm.js, and other low-level projects (Julia / Nim anyone?) are already aiming towards this goal for specific use-cases. I will admit that they are not fully there (sans Rust which already compiles with decent performance), but they will come.
17 comments
[ 2.5 ms ] story [ 51.9 ms ] threadI still code - and have just finished converting some FORTRAN astrophysics simulation code from 1974 into C# for a Unity project.
We coded carefully in days of yore :)
But FORTRAN is SOOOO fast. In R there is still plenty of FORTRAN code running. I still would want the code running FORTRAN and try to figure a way for it to run as is.
I understand the need for it to run in Unity but just I hate the idea of all FORTRAN code needs to be converted.
I did experiment with native and f2c versions - but when targeting for mobile it meant a bunch of Android and iOS packaging that was kinda irritating.
The specific code I targeted (3 body evolution using KS regularization, the triple code at http://www.ast.cam.ac.uk/~sverre/web/pages/nbody.htm) was modest and not CPU intensive.
I'd love to do the same for NBODY6 and that would have to be native.
Look for an update to my ThreeBody app with this code (and a cool gallery of new 3B solutions) sometime late in the year.
[1] https://www.eldacur.com/~brons/NerdCorner/StarGen/StarGen.ht...
FORTRAN is the first general purpose computer language still in use, but that's not the same thing as being the first.
A lot goes into that. It starts with programmers training to look into problem some way, which allows to formalize the task - as in conversion of a physical problem to a mathematical model.
Then it proceeds to offer good abstractions to use for problem statement. Those abstractions should be convenient - a reasonable set, a generic nature, a good correspondence to "the real world".
Then composability of those abstractions should allow more convenient canned solutions to common subproblems - which are libraries.
Last two parts require to carefully select the language syntax.
It turns out it's tricky to have a language which is good enough for every possible problem to solve. It's also hard to have a good set of composability features - usually you have one set of several possible, and you don't have at the same time all possible mechanisms to combine and use primitives.
I'm not sure Fortran compares well with existing offerings. Literal "formula translation" is a basis of several language philosophies (APL comes to mind), and in non-numeric applications there are other issues.
I never considered myself a "X Developer".
That's one kind of efficiency. There are others. One kind that often comes up Fortran is "efficiency of using the CPU". Fortran is pretty good at that kind of efficiency. For people using months of supercomputer time, that kind of efficiency is pretty important.
I think that's rather efficiency of implementation of the language's compiler.
Yes, given particular hardware properties, it might be beneficial to have language enforcing programmers to use mechanisms, which are easier (for translator) to convert to hardware instructions.
http://arstechnica.com/science/2014/05/scientific-computings...
And today, in a world with far more CPU homogeneity, we have an endless stream of nerds suggesting to HN languages to "replace" C.
I am never sure what "replace" means when used in this context. I'm still using assembly language; other languages cannot match it. In the same way, FORTRAN is still being used. Perhaps "supplement" should be substituted for "replace".
Enduring fact: "Your Father's" languages are more performant than the new ones you hold in high regard.
Because performance will always be important to some people, I doubt these old languages will ever disappear from use.
Unless someone can construct a compiler that accepts a different "language" and produces more performant object code, these languages will never be "replaced".
It means the use of assembly is replaced with the use of Fortran. At which it was very successful in scientific computing.
I don't believe it was ever meant to mean exterminate. Bear in mind that all programming was done in assembly or machine code prior to the introduction of Fortran. Since then a relatively tiny (though important) proportion of programmers program in assembly. That was the intent and it worked swimmingly.
And only masochists program in machine code.
I don't know if I buy this. Common Lisp and even to an extent Scheme as we know them today are much faster than the MacLisp of many decades ago. Sure, we're not replacing FORTRAN or C with Python or Ruby, but I think it's disingenuous to say that we haven't gotten better at optimizing newer languages. Even in that same token, C and FORTRAN have changed significantly since the 80's, and C11 hardly looks anything like what C used to be.
Further to the original point, we have Javascript VMs that are incredibly high-performance. Even more-so, C++ wasn't even around at the time of FORTRAN, does that still count as my father's language? I wouldn't say so, and in summary, I don't think performance is the reason we hold on to old languages.
Back to your original point about "replacing" languages: I think you're speaking too broadly. For example, nobody in the high-performance-computing space will likely replace FORTRAN or C for tight mathematical operations, especially when large datasets are involved. However, in the general case, I'd say that FORTRAN and C have been replaced in a lot of other industries. This is especially so in industries where exact hand-written assembly or low-level C don't make sense for the 98%+ of cases. Nobody in their right mind would write scientific computing software in pure assembly. Even if you argue that most of the heavy lifting in Python+Numpy or MATLAB or Julia comes from C libraries, you don't typically interact with the underlying C or FORTRAN from day to day. In many ways, we've replaced C and FORTRAN, even if they're not gone from the annals of history. And given how long software sticks around (even once we've tried killing it), they likely will not be eradicated for a long time. The point, then, is that replacing these languages is just a means to give us better abstractions so we don't have to think on the terms of older languages. There's been a lot of expressiveness gained from language research that have benefited humanity in immeasurable ways.
>Unless someone can construct a compiler that accepts a different "language" and produces more performant object code, these languages will never be "replaced".
I hate to bring it up, but Rust, asm.js, and other low-level projects (Julia / Nim anyone?) are already aiming towards this goal for specific use-cases. I will admit that they are not fully there (sans Rust which already compiles with decent performance), but they will come.