Fortran - a "technology that refuses to die" 
Author Message
 Fortran - a "technology that refuses to die"

I was reading the February issue of MIT Technology Review, and it had an
article entitked "Ten Technologies That Refuse to Die" (a follow-up to an
October 2003 article on ten technologies that "deserve to die").  Some on
the list were analog watches, dot-matrix printers and vacuum tubes.  Number
10 was fortran.

"Forty-seven years after IBM unleashed it, Fortran (FORmula TRANslation),
the original "high-level programming language [wouldn't that be COBOL? -
Steve], would seem to be the infotech equivalent of cuneiform.  But it's
still widely used, especially in scientific computing. Why has this
Eisenhower-era veteran outlasted so many hardware and software generations?
"It's partly the learning curve," says Hewlett-Packard Laboratories' Hans
Boehm, former chair of the Association for Computing Research's [I think
they meant Association for Computing Machinery - Steve] special interest
group on programming languages. "For some people it's good enough, and it's
hard to let go of something once you learn it."  Adaptability and
compatibility, which made Fortran the programmer's lingua franca in the
1960s and '70s, are also the key to its viability.  Major upgrades have
boosted efficiency and added features while preserving old versions intact.
So a vast number of tried-and-true Fortran 77 programs jibe with the current
Fortran 90. [sic]  Microsoft, take note."

Rather patronizing, to be sure, but it was interesting to see it there.  I'm
not sure what makes Boehm ( http://www.*-*-*.com/ ) an
expert on Fortran...

--
Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH

Intel Fortran Support:
  http://www.*-*-*.com/

User communities for Intel Fortran and Visual Fortran:
  http://www.*-*-*.com/



Thu, 20 Jul 2006 00:17:33 GMT  
 Fortran - a "technology that refuses to die"
On Sat, 31 Jan 2004 16:17:33 GMT, "Steve Lionel"

[snip]

Quote:
>Rather patronizing, to be sure, but it was interesting to see it there.  I'm
>not sure what makes Boehm (http://www.hpl.hp.com/personal/Hans_Boehm/) an
>expert on Fortran...

From the paragraph you quoted, he's clearly not an expert on Fortran.

But from his resume, I see that he's expert in garbage collection.
It's not too many steps to go from garbage collector to picker to
collector/dealer of antiquities to appreciator of the truly classic.

The core criticism of Fortran is always that it's old.  But the kids
who don't appreciate age never seem to notice that there is a lot of
technology about the same age as Fortran that has not been improved
upon.  There is, in fact, a lot that we'd be hard pressed to replicate
today.

Ken Plotkin



Thu, 20 Jul 2006 02:38:07 GMT  
 Fortran - a "technology that refuses to die"

Quote:

> On Sat, 31 Jan 2004 16:17:33 GMT, "Steve Lionel"

> [snip]
> >Rather patronizing, to be sure, but it was interesting to see it there.  I'm
> >not sure what makes Boehm ( http://www.*-*-*.com/ ) an
> >expert on Fortran...

> From the paragraph you quoted, he's clearly not an expert on Fortran.

> But from his resume, I see that he's expert in garbage collection.
> It's not too many steps to go from garbage collector to picker to
> collector/dealer of antiquities to appreciator of the truly classic.

> The core criticism of Fortran is always that it's old.  But the kids
> who don't appreciate age never seem to notice that there is a lot of
> technology about the same age as Fortran that has not been improved
> upon.  There is, in fact, a lot that we'd be hard pressed to replicate
> today.

x86 architecture.  We could do so much better if we could s{*filter*}and
start anew.  I would be sure to include provisions for lots of real
timers, external interrupts, and discrete, synchro, differential, etc.
I/O provisions in a nice modular design.

Quote:

> Ken Plotkin

--

Gary Scott

Fortran Library
http://www.*-*-*.com/

Support the GNU Fortran G95 Project:   http://www.*-*-*.com/



Thu, 20 Jul 2006 03:09:36 GMT  
 Fortran - a "technology that refuses to die"

Quote:

> I was reading the February issue of MIT Technology Review, and it had an
> article entitked "Ten Technologies That Refuse to Die" (a follow-up to an
> October 2003 article on ten technologies that "deserve to die").  Some on
> the list were analog watches, dot-matrix printers and vacuum tubes.
> Number 10 was Fortran.

Analog watches are actually superior.  There were some psychology
experiments a few years back (more than a few probably: 70's maybe?)
that indicated that people looked at their watches (or a clock) for a
variety of purposes, and a digital watch required more mental effort
to fulfill most of those purposes.  If you want to know the time, both
sorts of watches are evenly matched.  But, if you want to know how
long till your meeting, the analog watch is easier.  Or, if you want to
know how long it has been since something began, analog is easier.
Etc.  It's something to do with using some of the perception powers
of the visual part of your mind rather than passing all the work to the
language centers responsible for reading - that's how I remember it.

I bring this up because Fortran survives for many of the same reasons.
It suits the purpose better, in a psychological way, than many other
languages.  Experiments, for example, have shown that people
really regard the end of a line as synonymous with the end of a
programming statement.  This sets programming apart from human
to human communications.  These experiments were mostly done
with Pascal and Algol-like languages, so the bias wasn't caused
by prior familiarity with Fortran.  The conclusion was that programming
languages should use the end of line as a synonym for the end of
statement mark, and use explicit continuation when a statement needs
to be longer than a line.  (I suspect they would have explicitly criticized
the column-6 approach then used by Fortran - correctly, IMO).

Similarly, we had the recent discussion about assignment operators
in C and the possibility of having all those compound operators in
Fortran (this was in the j3 mailing list).  There were experiments
that indicated that programmer productivity was worse if the language
had assignment allowed as an operator within expressions than if
assignment were limited to one-per-statement.

There have been lots of experiments (mostly old, unfortunately) that
analyze the psychology of various language features and designs.
Fortran, which predates all these studies, actually does pretty well.
Many recent languages don't.  That's kind of surprising.  I think that
the reason such studies are seldom performed any more is that they
tend to discredit favorite dogmas of modern language designers.

--
J. Giles



Thu, 20 Jul 2006 07:43:21 GMT  
 Fortran - a "technology that refuses to die"

Quote:

> "Forty-seven years after IBM unleashed it, Fortran (FORmula TRANslation),
> the original "high-level programming language [wouldn't that be COBOL? -
> Steve], would seem to be the infotech equivalent of cuneiform.

No, Fortran is older than COBOL.  The original COBOL report was published
in 1959.  No implementations were available until later.

Donald Knuth's latest book contains an article on Fortran's predecessors.

                                                 Sincerely,
                                                 Bob Corbett



Thu, 20 Jul 2006 08:42:28 GMT  
 Fortran - a "technology that refuses to die"
Hip! Hip! Hourra! for Fortran :-)


Quote:
> I was reading the February issue of MIT Technology Review, and it had an
> article entitked "Ten Technologies That Refuse to Die" (a follow-up to an
> October 2003 article on ten technologies that "deserve to die").  Some on
> the list were analog watches, dot-matrix printers and vacuum tubes.
Number
> 10 was Fortran.

> "Forty-seven years after IBM unleashed it, Fortran (FORmula TRANslation),
> the original "high-level programming language [wouldn't that be COBOL? -
> Steve], would seem to be the infotech equivalent of cuneiform.  But it's
> still widely used, especially in scientific computing. Why has this
> Eisenhower-era veteran outlasted so many hardware and software
generations?
> "It's partly the learning curve," says Hewlett-Packard Laboratories' Hans
> Boehm, former chair of the Association for Computing Research's [I think
> they meant Association for Computing Machinery - Steve] special interest
> group on programming languages. "For some people it's good enough, and
it's
> hard to let go of something once you learn it."  Adaptability and
> compatibility, which made Fortran the programmer's lingua franca in the
> 1960s and '70s, are also the key to its viability.  Major upgrades have
> boosted efficiency and added features while preserving old versions
intact.
> So a vast number of tried-and-true Fortran 77 programs jibe with the
current
> Fortran 90. [sic]  Microsoft, take note."

> Rather patronizing, to be sure, but it was interesting to see it there.
I'm
> not sure what makes Boehm (http://www.hpl.hp.com/personal/Hans_Boehm/) an
> expert on Fortran...

> --
> Steve Lionel
> Software Products Division
> Intel Corporation
> Nashua, NH

> Intel Fortran Support:
>   http://developer.intel.com/software/products/support/

> User communities for Intel Fortran and Visual Fortran:
>   http://softwareforums.intel.com/



Thu, 20 Jul 2006 10:07:06 GMT  
 Fortran - a "technology that refuses to die"

Quote:
> Analog watches are actually superior.

I agree.  I spent a number of years fussing with increasingly complex
digital watches, but returned to analog about a dozen years ago.  (Hi-tech
analog, to be certain, but analog nonetheless.)

Fortran gets the job done.

Thanks to Robert Corbett for the clarification as to which language came
first. I knew Fortran was 1957, but somehow I had it in my head that COBOL
was earlier.

Steve



Thu, 20 Jul 2006 10:36:15 GMT  
 Fortran - a "technology that refuses to die"

Quote:


>>I was reading the February issue of MIT Technology Review, and it had an
>>article entitked "Ten Technologies That Refuse to Die" (a follow-up to an
>>October 2003 article on ten technologies that "deserve to die").  Some on
>>the list were analog watches, dot-matrix printers and vacuum tubes.
>>Number 10 was Fortran.

> I bring this up because Fortran survives for many of the same reasons.
> It suits the purpose better, in a psychological way, than many other
> languages.  Experiments, for example, have shown that people
> really regard the end of a line as synonymous with the end of a
> programming statement.

<lots snipped here and there>

I don't think we even need psychology or experiments,
just "logic". Most statements fit on one line (90%?,
95%, 99%?), so the default should be that you need to
do something "extra" to override the common situation
and continue onto more than one line.

--
Walt Brainerd         +1-877-355-6640 (voice & fax)
The Fortran Company   +1-520-760-1397 (outside USA)

Tucson, AZ 85750 USA  http://www.fortran.com



Thu, 20 Jul 2006 11:38:55 GMT  
 Fortran - a "technology that refuses to die"
...

Quote:
> I don't think we even need psychology or experiments,
> just "logic". Most statements fit on one line (90%?,
> 95%, 99%?), so the default should be that you need to
> do something "extra" to override the common situation
> and continue onto more than one line.

Yes, I agree.  I've used that very line of reasoning before.

On the other hand, I've heard it argued that programs should be
written like prose: if one statement ends and there's still room
for a token or two, you begin the next statement right there.  Now,
it may be that the psychological distinction is there and not with
the continuation.  Even programmers that use languages that
permit such run-together code typically don't do so.

Whatever the psychology, it is not valid to use natural language
communication as an analogy to programming.  You would get
poor designs.

--
J. Giles



Thu, 20 Jul 2006 11:55:25 GMT  
 Fortran - a "technology that refuses to die"

Quote:

> No, Fortran is older than COBOL.  The original COBOL report was published
> in 1959.  No implementations were available until later.

According to Jean Sammet's book Programming Languages, work on the first
COBOL report began on June 23, 1959.  The report was completed on
September 1, 1959.  No implementations of that first version of COBOL
were ever completed.

                                                    Sincerely,
                                                    Bob Corbett



Thu, 20 Jul 2006 17:38:01 GMT  
 Fortran - a "technology that refuses to die"

Quote:

> I was reading the February issue of MIT Technology Review, and it had an
> article entitked "Ten Technologies That Refuse to Die" (a follow-up to an
> October 2003 article on ten technologies that "deserve to die").  Some on
> the list were analog watches, dot-matrix printers and vacuum tubes.  Number
> 10 was Fortran.

> "Forty-seven years after IBM unleashed it, Fortran

I wouldn't take that as a liability.  IBM produced Fortran, so it's
firmly outside of the reach of SCO.

:-) :-)

Now let's start to rewrite Linux (the kernel) in Fortran :-) :-)

[Sorry, couldn't resist]

--

Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc.gnu.org/fortran/ (under construction)



Thu, 20 Jul 2006 23:21:00 GMT  
 Fortran - a "technology that refuses to die"

Quote:

>...
>> I don't think we even need psychology or experiments,
>> just "logic". Most statements fit on one line (90%?,
>> 95%, 99%?), so the default should be that you need to
>> do something "extra" to override the common situation
>> and continue onto more than one line.


Quote:

>Yes, I agree.  I've used that very line of reasoning before.

>On the other hand, I've heard it argued that programs should be
>written like prose: if one statement ends and there's still room
>for a token or two, you begin the next statement right there.

That's a reasonable counter-argument.  But one could say that programing
was more like poetry, in which the end of line is end of a metrical
unit.  In good poetry, at least in my opinion, the end of a sentence
does not come mid-line.

--
Clive Page



Fri, 21 Jul 2006 01:30:13 GMT  
 Fortran - a "technology that refuses to die"
...

Quote:

...
>> On the other hand, I've heard it argued that programs should be
>> written like prose: if one statement ends and there's still room
>> for a token or two, you begin the next statement right there.

> That's a reasonable counter-argument.  But one could say that programing
> was more like poetry, in which the end of line is end of a metrical
> unit.  In good poetry, at least in my opinion, the end of a sentence
> does not come mid-line.

And I've used that argument before too.  But I think that it's not
the end of a statement that people concentrate on, but the beginning.
They want each new statement to begin on a new line.  It's less like
poetry than like cooking recipes or preflight checklists.  Each step
begins on a new line (or even a new paragraph) so that you can
follow step-by-step.

--
J. Giles



Fri, 21 Jul 2006 03:34:26 GMT  
 Fortran - a "technology that refuses to die"


Quote:
>According to Jean Sammet's book Programming Languages, work on the first
>COBOL report began on June 23, 1959.  The report was completed on
>September 1, 1959.  No implementations of that first version of COBOL
>were ever completed.

A few year back, when Grace Hopper was getting enormous amounts of PR,
part of the tale seemed to be that she had invented COBOL, the first
high level language.

Any skinny on those tales?

Ken Plotkin



Fri, 21 Jul 2006 04:28:17 GMT  
 Fortran - a "technology that refuses to die"


Quote:
>That's a reasonable counter-argument.  But one could say that programing
>was more like poetry, in which the end of line is end of a metrical
>unit.  In good poetry, at least in my opinion, the end of a sentence
>does not come mid-line.

Programming cannot possibly be like poetry.  I am reasonably competent
at programming, but completely inept at poetry - both reading it and
writing it.

I used to use BASIC, which allows multiple statements on a line.  I
always found programs which did have multiple statemenst to be very
hard to follow.  The only time it really made sense to me was when it
gave the functionality of block IF.  BASIC had no block IF, but IFs
applied to the rest of the line.

Ken Plotkin



Fri, 21 Jul 2006 04:32:51 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. "c%Er:r)}+?IHOT TECHNOLOGIES AND FREE STUFFtT"U"$

2. how to "die" in Ruby

3. nasm 0.97 dies on "int1"

4. nasm 0.97 dies on "int1"

5. When do global variables "die"

6. CMU CL dies with "GC lossage"

7. string.join(["Tk 4.2p2", "Python 1.4", "Win32", "free"], "for")

8. what is "melting ice technology"?

9. Seva Technologies "The Ultimate EDA Tool"?

10. IEEE Spectrum "Technology 1994: Software engineering"

11. off-topic, "Compiler" technology

12. TAL Technologies "Software Wedge"

 

 
Powered by phpBB® Forum Software