SoylentNews is people
SoylentNews
from the Get-Off-My-Extremely-Efficient-Lawn dept.
Ars technica looks at Fortran, and some new number crunching languages in Scientific computing's future: Can any coding language top a 1950s behemoth?
This state of affairs seems paradoxical. Why, in a temple of modernity employing research instruments at the bleeding edge of technology, does a language from the very earliest days of the electronic computer continue to dominate? When Fortran was created, our ancestors were required to enter their programs by punching holes in cardboard rectangles: one statement per card, with a tall stack of these constituting the code. There was no vim or emacs. If you made a typo, you had to punch a new card and give the stack to the computer operator again. Your output came to you on a heavy pile of paper. The computers themselves, about as powerful as today's smartphones, were giant installations that required entire buildings.
(Score: 5, Insightful) by legont on Friday May 09 2014, @09:40AM
You have a handy razor blade to cut new holes and a bunch of paper squares to cover wrong ones.
Back to FORTRAN, it's simple and efficient - hard to beat, same as AK47.
"Wealth is the relentless enemy of understanding" - John Kenneth Galbraith.
(Score: 2, Insightful) by Wootery on Friday May 09 2014, @11:41AM
Indeed.
They've both shown themselves to effective problem-solvers despite being entirely devoid of pointer arithmetic.
(You were right to use same as AK47 rather than same as the AK47 - it forces the use of a Russian accent.)
(Score: 4, Insightful) by hubie on Friday May 09 2014, @01:38PM
With a COMMON block, you don't need pointer arithmetic.
(Score: 3, Informative) by Anonymous Coward on Friday May 09 2014, @02:47PM
Ultimately, COMMON blocks just were shared global variables. Indeed, in some aspects they are cleaner than true global variables, since every function has to explicitly declare which of the common blocks it uses. Yes, there's the lack of type checking, but as soon as you have several files, C is not much better in that respect (the preprocessor helps this, but then, preprocessing FORTRAN code isn't exactly unheard of either, although it was never part of the standard).
Note that there is no such thing as a dangling COMMON block, or dereferencing a NULL COMMON block. There's no COMMON BLOCK arithmetic. A COMMON block does not change over time (the values of its variables may change, of course). And given the simple syntax of pre-90 FORTRAN, a program that checks that all your COMMON blocks are consistent should not be too hard to write either. OTOH, testing whether a program has no pointer issues is equivalent to the halting problem.
Note that I'm not advocating the use of COMMON blocks in modern software; today we have superior constructs also in Fortran. But COMMON blocks were by far not as complex and error prone as pointers are.
(Score: 2) by hubie on Saturday May 10 2014, @02:37AM
Not only are they shared global variables, what made them immensely useful to me was that they are also contiguous memory. Because of this it was trivial to do type conversion on the fly when reading in a record. If one had a 1000 byte record, one could read it in one subroutine
And in the subroutine where you handle the data
The variables were filled in and ready to use. Like with all languages, there were ways to get yourself in trouble if you weren't careful.