Re: A petition to J3 apropos FORTRAN's future

From: Dan Tex1 (dantex1_at_aol.com)
Date: 02/28/04

  • Next message: Greg Chien: "Re: Use of subroutines"
    Date: 28 Feb 2004 19:40:53 GMT
    
    

    From: analyst41@hotmail.com (analyst41)

    >beliavsky@aol.com wrote in message
    >news:<3064b51d.0402270914.58b0d53a@posting.google.com>...
    >> Helge Avlesen <avle@ii.uib.no> wrote in message
    >news:<72vfltez5i.fsf@tindved.ii.uib.no>...
    >.
    >>
    >> Most programming magazines are dominated by discussion of databases,
    >> web programming, GUI development, and text analysis. Most programmers
    >> seem to be working on things far removed from numerical work, and this
    >> may partially explain the small market share of Fortran.
    >
    >Please try to be aware of the dismal FACTS and then comment.
    >
    >(1) before the decimation of the Fortran user-base (which took place
    >apprximately in the decade of the 1980s +- a couple of years) -
    >Fortran was EVERYWHERE - weapons systems, industrial process control,
    >aerospace, wall street, just anout every large enterprise. The
    >Creature called VAX-FORTRAN (ie Fortran with a lot of C-like
    >extensions including system calls) was a smashing success story in
    >terms of user take-up. Statistical packages like SAS were written in
    >Fortran as were most commercial optimization packages.
    >
    >(2) Fortran is now viewed as a quaint relic by wall street and
    >mainstream businesses and new development in Fortran is unthinkable.
    >I would assume that it has been eliminated from weapons systems
    >software.
    >
    >(3) During the dying off period of Fortran there were massive
    >'porting' projects that would be advertised in the employment ads
    >(mostly to C or C++). VAX Fortran is now essentially kaput, as far as
    >I know, as are any significant legacy Fortran applications in any
    >Fortune 500 enterprise.
    >
    >(4) Take Linear Programming - the one purely quantitative application
    >on which the most money is probably spent world wide. The premier
    >commercial package is written in C. The user manuals spend 99 pct on
    >how to call the package from C/C++/Java. There is a teeny tiny
    >section on how to call it from Fortran - just Fortran - not a peep
    >about Fortran 90 or 95. SAS has now been rewritten in C. The list
    >goes on and on.
    >
    >Just think about - the supposedly CORE COMPETENCY area of Fortran -
    >quantitative computing - has been occupied by C/C++/Java.
    >
    >(5) For the pull-the-***-over-your-head crowd that hangs out here -
    >some remnants such as weather prediction and still-working code from
    >the 70s that no one has been able to port is a source of comfort - but
    >the writing is clearly on the wall.
    >
    >(6) We need to turn our back on the Fortran committee and go back to
    >Fortran 77 and re-evolve it avoiding all the ada-envy driven bloat and
    >minimally extend that beautiful language - it would be such a thing of
    >beauty that the user base will return. But it must happen soon before
    >the current crop of Fortran experts who are still lurking in
    >mainstream computing retire. If something is not done soon - it is
    >curtains for all flavors of Fortran.

    I disagree. Going back to F77 would be a big mistake IMHO. If we were to go
    back to F77, or F77 with a few minor extensions... I feel quite confident that
    THAT would be the death blow to fortran. And... the death would come quickly.
    ie... almost NO new code would be written in the language.

    Fortran is an old language. Thus... Comp Sci departments in schools aren't
    likely to even want to look at Fortran and consider it's usefulness unless some
    major changes occur in the language. Even then... by human nature, they
    probably won't give it much thought. You know how things work. When someone
    comes out with some tasty new flavor of ice cream, everone wants some. It's
    the new flavor of the month. However, after a while... there come other new
    flavors of the month. Most people never really want to go back to the
    original flavor of the month. So... it's not really hard for me to believe
    that Comp Sci depts. don't want to backtrack and take another look at fortran,
    even in it's modern form. If you go back to F77... it's a given that they
    don't even want to hear you mention the name, "Fortran".... other than for a
    good laugh that is.

    Of course... Comp Sci departments ( in general ) aren't spending all that much
    time on the types of codes that scientists and engineers want and need to
    write. So... why should they look at Fortran??? After all... if you want a
    good Finite Element program, are you going to ask someone without the
    engineering background to write it? You might ask them to write an interface,
     but... someone who knows and understands FEM needs to write the analytical
    parts of the program. Sure. I've seen engineering codes where a
    "non-engineer" wrote the code. However, I don't ever think I've seen such
    codes that actual worked very well. They often look spiffy. They just tend to
    bomb often and spit out erroneous results when they don't bomb. Yes. You
    often get the same results when an engineer writes the code too. However, the
    good programs are actually written by engineers who "can" program. Not by
    engineers who can't program or by Comp Sci programmers who don't know much
    engineering. Bottom line... Comp Sci depts don't focus primarily on science
    and engineering codes. Thus... they have no incentive to spend much time on
    languages which are appreciated by scientist and engineers.

     There are a lot of features that F77 doesn't have that a LOT of people want (
    even for FEM type codes ). Thus... going back to F77 isn't going to
    popularize fortran at all IMHO. Heck... the mere lack of dynamic memory
    allocation in F77 is "all by itself" a reason not to go back to F77. The
    simple TRIM() function is worth having. I've found Modules, even in their most
    basic form to be very helpful. The new array syntax for operating on arrays
    makes code easier to read. The new syntax makes some codes much easier to read.

    All of these features are, IMHO, incredibly nice to have. I've seen a lot of
    post here claiming that F90 became way too complex. None of these features is
    very complex ( at least from a users point of view ). And... every one of them
    is extremely helpful.

    How about abstract data types ( user TYPEs ). Boy... these are sure nice to
    have at times.You don't always need them. But... when you do... they are
    nice!!! And.. in general, they are "very" easy to use.

    Yes... pointers are in the language now. They certainly add some complexity (
    in my opinion, the most complex addition to the language for your average
    "engineer-type" of programmer ). However, where needed, they are very
    powerful ( linked-list as one example ). Without them... more people will
    just claim that not having them is a "con" to the language. Additionally, at
    least Fortran pointers are more restricted and controlled. It's easy to shoot
    yourself in the foot with them. However, unlike pointers in most other
    languages... you're only risking shooting yourself in the foot. In other
    languages, the risk is of sticking the gun barrel in your mouth and squeezing
    the trigger.

    So... I reiterate. Go back to F77 and the language is essentially dead. I
    think the committe did a great job with F90/95 overall. I still have to wait
    and see about the upcomming F2003. I'm worried a little about the complexity
    there. ie... will the language still be easy enough to use for those who are
    scientist/engineers, etc. who do programming in addition to their normal tasks.
     Some of the features for F2003 sound pretty nice. I'm merely hoping that they
    are implemented in a way which doesn't overly complicate things.

    Dan :-)


  • Next message: Greg Chien: "Re: Use of subroutines"