Stories
Slash Boxes
Comments

SoylentNews is people

posted by LaminatorX on Friday May 09 2014, @09:18AM   Printer-friendly
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.

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Informative) by Anonymous Coward on Friday May 09 2014, @02:47PM

    by Anonymous Coward on Friday May 09 2014, @02:47PM (#41269)

    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.

    Starting Score:    0  points
    Moderation   +3  
       Informative=3, Total=3
    Extra 'Informative' Modifier   0  

    Total Score:   3  
  • (Score: 2) by hubie on Saturday May 10 2014, @02:37AM

    by hubie (1068) Subscriber Badge on Saturday May 10 2014, @02:37AM (#41458) Journal

    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

    SUBROUTINE READDATA(ILUN)
    COMMON /MYCOMMON/ IDUMMY(1000)
    INTEGER IDUMMY
    READ(UNIT=ILUN, "I1000") IDUMMY
    END

    And in the subroutine where you handle the data

    SUBROUTINE DATAPROC( )
    COMMON /MYCOMMON/ IREC, TSTAMP, TEMP1, X(100), ...
    INTEGER IREC, TSTAMP
    REAL TEMP1, X
    . . .
    END

    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.