Is GNU g77 Killing Fortran?

goombah99 asks: "I've come to believe that the existence of GNU g77 (and f2c) is holding back Fortran development. You might think that a free-ware compiler would be good for promoting the language. But it's not because the GNU flavor does not implement the de-facto standard DEC extensions to the language that give it dynamic memory allocation, pointers, and data structures. Without these Fortran 77 is indeed barbaric, but with them it is quite pleasant to work with. The problem is everyone writing new code is now afraid to use these commands in because of the desire to have their applications compilable by the teeming masses who may not want to pay $500 to $1000 dollars for a professional Fortran compiler (all of which do implement the DEC extension). F95 is being held back by the same considerations. Do you agree? Does anyone have some library extensions or pre-compilers that provide these capabilities to g77?" Are the DEC extensions so widespread and common that language survival is dependent on their inclusion, as the submitter suggests, in "every professional compiler". Assuming there aren't comparable features already available in g77, are there plans on eventually implementing similar?

Comments

10 GOTO 20

[Dancin_Santa]

20 C++ faster than Fortran

Re:10 GOTO 20

[Spy Hunter]

Wow. That article is awesome. This code made my jaw drop:

const int N = 64;
Array<double,3> A(N,N,N), B(N,N,N);
Range I(1,N-2), J(1,N-2), K(1,N-2);

A(I,J,K) = (B(I,J,K) + B(I+1,J,K) + B(I-1,J,K) + B(I,J-1,K) + B(I,J+1,K) + B(I,J,K-1) + B(I,J,K+1)) / 7.0;

You can do that with C++?!? And it's super-efficient!?! The article explains that this code actually expands automatically into this loop that traverses the arrays in a convoluted manner designed specifically to improve cache-hit performance. All this complexity is hidden inside the library. Now I see what all these people have been raving about with template metaprogramming and expression templates.

Seems to me that template metaprogramming is a rather awkward way to go about these things though. Couldn't you design a language that had features specifically designed to enable this type of in-line compile-time code expansion?

Re:10 GOTO 20

[jaoswald]

Sure, but it expands into C++ code. You still need a very wise C++ compiler to turn this into efficient machine code.

A decent Fortran compiler knows more about the original statement than the C++ compiler can, and also, a Fortran compiler's number one reason for existence is to optimize array accesses.

A C++ compiler is lucky to correctly compile all of the heinous complexity of the C++ language, much less aggressively optimize this type of array access.

I'd be much more impressed if the poster had shown the resulting machine code.

Re:10 GOTO 20

[Anonymous Coward]

Couldn't you design a language that had features specifically designed to enable this type of in-line compile-time code expansion?

Its called lisp (and yeah, in compiled lisp programs macros are all expanded at compile time).

Re:10 GOTO 20

[Dr. Photo]

Seems to me that template metaprogramming is a rather awkward way to go about these things though. Couldn't you design a language that had features specifically designed to enable this type of in-line compile-time code expansion?

There's something like that already, called ANSI Common Lisp. (Yes, I'm serious.)

Re:10 GOTO 20

[Spy Hunter]

Its called lisp

OK, let me rephrase the question. Couldn't you design an language with features specifically designed to enable this type of in-line compile-time code expansion, and have it not turn out as a functional language with retarded syntax?

Re:10 GOTO 20

[Spy Hunter]

Why do you need to see the machine code? Doesn't the performance of the compiled code speak for itself? He benchmarks the code against hand-optimized Fortran code for the same task, and it beats Fortran. Did you even read the link?

Re:10 GOTO 20

[Anonymous Coward]

I wouldn't trust these guys too much.

Why on earth would you declare the array floating point (double) and then stuff an integer (int) into it?

Hitting the floating point unit doesn't exactly optimize anything.

Re:10 GOTO 20

[popeyethesailor]

Couldn't you design a language that had features specifically designed to enable this type of in-line compile-time code expansion?

Us old farts call it APL ;)

Re:10 GOTO 20

[t]

I've seen this before and its complete crap. Change the first line to
const int N = rand();
Then see how fast it runs. All that uber special loop expanding trickery usually doesn't work when you don't know the sizes of your arrays beforehand.

Re:10 GOTO 20

[Anonymous Coward]

Seems to me that template metaprogramming is a rather awkward way to go about these things though. Couldn't you design a language that had features specifically designed to enable this type of in-line compile-time code expansion?

That's the beauty of C++, the language itself doesn't need to include such specific features because it's powerful enough to allow you to add (and change) them yourself.

In the example he uses a Hilbert space-filling curve to traverse the arrays in a cache-efficient manner. If that algorithm was hard-coded into your compiler and it wasn't working for you then you'd be screwed. However, with the template library approach, all you'd need to do is change the library and recompile.

Re:10 GOTO 20

[hding]

Sure, that's easy.

ANSI Common Lisp already satisfies that requirement. :-)

Re:10 GOTO 20

[Spy Hunter]

No, I don't mean a compiler with a bunch of specific optimizations built-in, I mean a language with programmable code expansion features so that you can write a library that does this sort of thing. The idea that this should be the job of the library is key.

Re:10 GOTO 20

[RevAaron]

yup- ANSI CL's metaprogramming facilities are so powerful that you can write your own syntax- retarded or otherwise.

Re:10 GOTO 20

[Anonymous Coward]

The conclusion reached in that article is spurious. All it proves is that a faster algorithm, implemented in C++, is faster than a slower one, implemented in fortran. The fact that the fast hilbert traversal algorithm is built into his library (note, it was not a result of any of the code shown on the page -- it is hidden in the range objects and the overloading of the () operator, and the code that does it is in the library), and is not a standard feature in fortran, does not change the point that he was comparing TWO DIFFERENT ALGORITHMS.

In fact this is exactly why people still use fortran. Because in 9 times out of 10, the situation is the exact opposite: there is a heavily optimized implementation already available in a widely available fortran library, or you can write your own crappy C/C++/Java/Perl/whatever code.

Re:10 GOTO 20

[Zan Zu from Eridu]

Yes, but it's no more than logical that compile-time optimizations don't work if you don't know these sizes at compile-time, isn't it.

Re:10 GOTO 20

[t]

And your point is?

Re:10 GOTO 20

[Chmarr]

I don't think that's relevant. In most circumstances, you ALREADY KNOW the sizes of your vectors, since they're fixed by the type of algorithm you're programming.

In other words, in these 'most cases' each position in the vector is NOT a new sample in a dataset, but rather a new variable, or axis of variability, in an equation.

Re:10 GOTO 20

[t]

Exactly what kind of algorithms are you thinking of? That's not often the case, no matter how much you capitalize. When certain algorithms are set to a certain size it is usually because of efficiency, but quite often you will want to run different sizes of datasets. This requires the algorithm to be written in a general manner, recompiling would not be an option.

Re:10 GOTO 20

[Zan Zu from Eridu]

The point is, it's not crap. In the (very) large majority of cases, you know the dimensionality of your vectors at compile-time when doing math.

By moving the compile-time constant to a constant generated at runtime, you're moving the problem space from efficiently handling vector math to efficiently handling dynamic multidimensonality.

You're either comparing apples to oranges, or you're using the wrong tool (compile-time optimizations) for the job (dynamic efficiency).

Re:10 GOTO 20

[t]

You and the other guy both claim that in the vast majority of cases you know all of the dimensions so you should hard-code these parameters. I seriously doubt this assumption based on personal experience working in an engineering world. The only times when the dimensions of everything was known was when the target was some custom built piece of hardware with an embedded system that could not support anything but plain old C. (VxWorks is excluded because it has far exceeded typical embedded systems.)

You're either comparing apples to oranges, or you're using the wrong tool (compile-time optimizations) for the job (dynamic efficiency).

I'm not comparing anything. Let me ask you this, suppose you have a version with hard coded constants, and you at some point have to fix it to handle parameters given at run time. How much of a speed hit do you take? What would you do if the hit was so large that you had to drop back and code it in something like C? That is a very important question. Algorithms are quite often reused, and having to recode magic constants is not a good practice.

And finally, it is not simply a choice of either knowing the dimensions at compile time or completely random dimensions at run time. Quite often the best you can rely on is that the vector lengths will be e.g. a power of two. Plain old memcpy is a typical algorithm that combines the best of both by doing fixed-length as much as possible.

Re:10 GOTO 20

[Zan Zu from Eridu]

You and the other guy both claim that in the vast majority of cases you know all of the dimensions so you should hard-code these parameters. I seriously doubt this assumption based on personal experience working in an engineering world.

I don't know that much about engineering, but a lot of the scientific stuff done with computers is simulations and mathematical transformations (along with the inevitable statistics), and the dimensionality of these problems is prety much known before you start designing algorithms.

I'm not comparing anything. Let me ask you this, suppose you have a version with hard coded constants, and you at some point have to fix it to handle parameters given at run time. How much of a speed hit do you take?

Not much compared to your language of choice. If some smart traversal- or summing/factoring-method doesn't work because it needs compile time constants, you can't use this method in any language.

Template engines like these are a way to get a higher abstraction level in the code while still producing fairly efficient code. There are different engines for different problem domains, and in some problem domains you simply can't produce efficient code and keep a high abstaction level at the same time. If this is the case you'll have to resort to either micromanaging your code, or you can take the less efficient (more object oriented) approach and keep a high abstaction level.

Re:10 GOTO 20

[t]

Not much compared to your language of choice.

Exactly what does this mean?

If some smart traversal- or summing/factoring-method doesn't work because it needs compile time constants, you can't use this method in any language.

Your excessive jargon aside, that is what my point was in the original post. That this code doesn't work efficiently if you don't hard-code compile time constants.

Re:10 GOTO 20

[tetabiate]

Yeah, but FORTRAN is a lot easier to program.

Re:10 GOTO 20

[Zan Zu from Eridu]

Exactly what does this mean?

It means that the efficiency of a program is usually not bound by the programming language but by the algorithms you use.

That this code doesn't work efficiently if you don't hard-code compile time constants.

Yes, and this is a fundamental problem, not just one of C++ or the templating engines. If you can't delegate complexity to the compiler and solve it at compile time, you'll have solve the complexity at runtime (over and over), and this is inherently not as efficient.

Re:10 GOTO 20

[Zan Zu from Eridu]

Oh, forgot about the excessive jargon ;)

What I mean by high abstraction level is writing stuff like:
Vector<double, 2> a(0.0, 2.0), b(2.1, -3.2), c(-1.0, 1.0), result;
result= a + b - c;

Instead of writing out the equivalent:
struct vectord2 { double elem[2]; } a= {{0.0, 2.0}}, b= {{2.1, -3.2}}, c= {{-1.0, 1.0}}, result;
for(int i= 0; i != 2; ++i) result.elem[i]= a.elem[i] + b.elem[i] - c.elem[i];

If you use an more object oriented approach, you still write result= a + b - c; but the code produced would look like:
struct vectord2 { double elem[2]; } a= {{0.0, 2.0}}, b= {{2.1, -3.2}}, c= {{-1.0, 1.0}}, result, temp1, temp2;
for(int i= 0; i != 2; ++i) temp1.elem[i]= a.elem[i] + b.elem[i];
for(int i= 0; i != 2; ++i) temp2.elem[i]= temp1.elem[i] - c.elem[i];
for(int i= 0; i != 2; ++i) result.elem[i]= temp2.elem[i];

Re:10 GOTO 20

[Anonymous Coward]

what kinda drugs are you on, can I get some too...
On SGI F95 blows away all the other SGI compilers
for floating point execution (C,f77,...) if you use the proper vectorization notation

Re:10 GOTO 20

[Tore S B]

My DEC computer (PDP-7 http://tore.nortia.no) runs FORTRAN II (the original FORTRAN with subs, basically) TRY FITTING C INTO 32KB OF CORE MEMORY. AND WHO NEEDS LOWERCASE? TTY 33 FOREVER! GOTTA LOVE THE SOUND IT MAKES AT FINISHED COMPILE TOO...^G^G^G^G^G^G!!!

Want "modern" features? Don't use F77

[GuyMannDude]

But it's not because the GNU flavor does not implement the de-facto standard DEC extensions to the language that give it dynamic memory allocation, pointers, and data structures. Without these Fortran 77 is indeed barbaric, but with them it is quite pleasant to work with.

You can mock Fortran 77 all you want but the "barbaric" striped-down version can be highly optimized. And for a lot of the legacy scientific code out there, you just don't need dynamic memory allocations, etc. If you really do need all these fancy, modern features, why the hell are you using Fortran 77? Fortran 77 is a simple yet highly effective, stripped-down language that is appropriate for a limited number of applications. But it does those applications really damn well. Don't blame Fortran 77 if you're trying to use the wrong tool for the job.

GMD

Old age.

[t]

Seriously, that is what is really killing fortran. When I was in undergrad about ten years ago they had stopped teaching fortran and had switched to C. Since then everyone falls into a couple of categories. (1) Those who learned fortran first and still use it. (2) Those who learned C first and thus have no reason to ever use Fortran. (3) Those who are forced by their jobs to use Fortran.

Of these, group (1) is all the old foggies who are retiring, leaving group (2) people to continue the work. Typically what is done is C wrappers are made to call the legacy fortran code and all subsequent work is done in C. Group (3) people are always desperately trying to migrate their projects to C.

That is why fortran is dieing.

Re:Old age.

[MagikSlinger]

Group (3) people are always desperately trying to migrate their projects to C.

Hey! I resemble that comment...

Re:Old age.

[dvdeug]

When I was in undergrad about ten years ago they had stopped teaching fortran and had switched to C.

And now they've stopped teaching C and started teaching Java. Does that mean C is dead? Also, at Oklahoma State, Fortran 77 is still offered as an easy credit in the CS department, and Fortran 90 (and no other computer language) is a requirement for any engineer. It's not like Fortran has disappeared completely.

Re:Old age.

[t]

Go to any job board and search for Fortran. I tried it on one and got 8 hits. Many of which said "C or Fortran".

C won't be dieing anytime soon because once a language hits critical mass it's huge legacy base keeps it going.

It is not suprising that Fortran may still be taught at places where there are old group 1 professors. But to be convincing you're going to have to come up with more than one example. Also, it seems that to secure their position they had to force Fortran 90 to be a requirement. Sad really, quite the disservice to their students.

Why don't you enlighten yourself and compare the history of Cobol to Fortran.

Re:Old age.

[sloptaco]

Remember that seen in Old Yeller where Old Yeller gets rabies and the boy has to go out to the shed to shoot him, and there's the long dramatic scene with the boy cyring and the rabid Yeller barking away? Imagine that scene extending to lets say 5 hours. That's the best way I can describe the persistence of the Fortran programming language. Come on folks, its time to shoot the old dog and move on.

Re:Old age.

[dvdeug]

C won't be dieing anytime soon because once a language hits critical mass it's huge legacy base keeps it going.

And that somehow doesn't apply to Fortran?

But to be convincing you're going to have to come up with more than one example.

One example was all that given that schools were dropping Fortran. A complete survey of schools and the languages they teach might be interesting, but we don't have that.

Also, it seems that to secure their position they had to force Fortran 90 to be a requirement.

I don't think so. I've met many engineers, and it seems that Fortran is still popular there.

Why don't you enlighten yourself

Why don't you can the attitude?

compare the history of Cobol to Fortran.

Cobol dies with the huge computers it was used on. Fortran, OTOH, managed to grab a large audience of scientists and engineers, who still write new code in Fortran. It isn't getting replaced by C, which is a less friendly language for non-programmers; it isn't getting replaced by Java, which isn't good speed-wise; there's some replacement by C++, but C++ is still a programmers language.

Re:Old age.

[t]

C won't be dieing anytime soon because once a language hits critical mass it's huge legacy base keeps it going.

And that somehow doesn't apply to fortran?

Do you even know what the phrase means? How many projects do you know of that are written in fortran? And please give me examples that were written at least in the 90's.

Also, the legacy fortran base is not an asset for fortran as there are C-interfaces to anything important (e.g., lapack et al).

I don't think so. I've met many engineers, and it seems that fortran is still popular there.

Gee, that's funny I am an Engineer that used to work at a company that only hired EE's (no CS) and not a single one of them preferred fortran.

Why don't you enlighten yourself

Why don't you can the attitude?

Sadly, that was meant as a serious suggestion. You only saw what you assumed it to be.

Cobol dies with the huge computers it was used on. Fortran, OTOH, managed to grab a large audience of scientists and engineers, who still write new code in Fortran. It isn't getting replaced by C, which is a less friendly language for non-programmers; it isn't getting replaced by Java, which isn't good speed-wise; there's some replacement by C++, but C++ is still a programmers language.

I'm not the one that brought up Java, I think that using a virtual machine to run numerical code is moronic. And like I said earlier, just like Cobol died with the mainframes, fortran is dieing with the group 1 people who still program in it. I don't know what country you're from but my experience is a first hand view of the Engineering world as an Engineer.

Re:Old age.

[epmos]

I believe that your information is out of date. Fortran 90 is no longer required for engineers at OK State, though this is a recent change.

My sister in law started the ME program there this year, and told me that the fortran requirement had been removed. Her husband just graduated from the same program, and was required to take F90.

Wrong...

[TheSHAD0W]

That should be:

20 CONTINUE
25 C++ faster than Fortran

Remember, jumping to a line number that's not on a CONTINUE statement can break things. :-P

Re:Wrong...

[Dancin_Santa]

I made the switch after that Physics course that required Fortran. I haven't used Fortran since, and I haven't looked back.

I learned Emacs in that course as well. I haven't used that since, either.

Eventually? How about currently?

[devphil]

Assuming there aren't comparable features already available in g77, are there plans on eventually implementing similar?

There's already a team of very capable -- and young, not ancient/retired/whatever -- programmers implementing the Fortran 9x language, which defines some really interesting constructs. The current plan is for an initial release as part of 3.5.

Fortran 2000 has a spec, but I don't know of any implementations for it.

As far as "why is it still being used at all" comments, two words for you: no aliasing. The same reason why numerical computation in Fortran continues to chew C's head off.

Fortran to C++ converter?

[Futurepower(R)]

Why doesn't someone make a Fortran to C++ converter and help everyone out of their misery?

Re:Fortran to C++ converter?

[trouser]

and into Bjarne's.

Re:Fortran to C++ converter?

[turgid]

Not C++ but C: f2c

Oh come on

[BoomerSooner]

You can develop software in any language. Fortran, C, Visual Basic, Assembly, ...

99% of the problem is the programmer not the language. Every language has an advantage in its specific area. VB/Delphi Quick & Dirty Interface or Prototype (quick development time). C/C++ Portability & Speed of Program. Assembly True low level programming. Wait what is fortran used for again? (lol just kidding). Excellent math modeling for quick and dirty precision calculations (I'd still use C because I've never used Fortran).

I guess g77 is holding it back because that is one of the reasons I've never used it. I thought there was a Fortran 85 or 90 spec as well?

Boomer Sooner (way to choke one off early Tejas)

Re:Oh come on

[turgid]

99% of the problem is the programmer not the language.

I'd still use C because I've never used Fortran

FORTRAN, especially in its older incarnations e.g. FORTRAN-77, reall is that bad. Having learned C as a teenager (K&R then ANSI) and then being forced to write some F-77, I can assure you it was no picnic. If you remember the BASIC interpreters that used to come on 8-bit micros in the early 80s, without the user-friendly error messages, with fixed-format 80-column source geared towards old punch cards, cryptic run-time errors, if any... You get the idea.

C is old too, but it's a heck of a lot easier to learn, easier to understand, more consistent etc. than old FORTRAN. FORTRAN's systax is largely ad-hoc. Remember, it was one of the first two compiled "high-level" languages. COBOL was the other. It shows.

FORTRAN 90 and then 95 came along. A few years ago we had a work experience student who was learning a language called F, basically modern fortran with all the old rubbish removed.

Anyway, old FORTRAN (77 and before and without many of the vendor-only extensions) is sheer purgatory for the modern programmer.

There was a better competitor called ALGOL once upon a time, but as with VHS video and MS Windows, the "worst" one prevailed.

God, I'm getting old...

Re:Oh come on

[BrokenHalo]

FORTRAN, especially in its older incarnations e.g. FORTRAN-77, reall is that bad. Having learned C as a teenager...

You said it yourself. If you learned C as a teenager, you would not have been forced to spend the time with Fortran that it takes to get proficient enough with it to appreciate its elegance, power and simplicity.

I'm not going to get on the tired old hobbyhorse of "Real Programmers Don't Use Pascal" (if you're not following me, google for the title), but if you cut your teeth on mainframe assembly code, FTN is a fabulous language.

Trouble is, FTN was designed for people who were assembly programmers first and knew how it all worked, and that doesn't sit well with a generation that can't/won't take the trouble.

As for the "worst one prevailing", I have to ask "worst at what?". If you're doing heavy-duty maths, Fortran is much quicker to code, and the resulting objects are nearly always extremely efficient. (Boeing math library, anyone?) Having said that, I remember coding financial packages in FTN back in 1978...

Re:Oh come on

[turgid]

I stand by what I said about FORTRAN-77 being worse than the interpreted BASICs that came with 8-bit home micros in the early eighties. Going from C back to brain-damaged BASIC-like FORTRAN was hell on a stick.

he time with Fortran that it takes to get proficient enough with it to appreciate its elegance, power and simplicity.

FORTRAN-77 in its pure form is very simple, nay simplistic. The syntax is ad-hoc. There is no WHILE, or REPEAT UNITL. The I/O is primitive to the point of barbarism. Good grief, FORTH was more advanced.

Anyway, thank you for taking part in an entertaining religious flamewar. LOL

Re:Oh come on

[BrokenHalo]

Anyway, thank you for taking part in an entertaining religious flamewar. LOL

Well, Pthhrrrrrrrrrrrrrlllbtt! to you too, script-kiddie! :-D

But seriously, your objections to the absence of WHILE/REPEAT UNTIL/and so forth are somewhat silly. If you really want to code in GWBASIC just do so, don't whine that another language doesn't work the same way.

Re:Oh come on

[LWATCDR]

I learned Fortran as my third of many languges. I learned Fortran IV because my school did not have a Fortran 77 compiler yet. I even wrote a cross asmbler for the 6800 Yes that is 6800 not 68000 chip in Fortran. Fortran IV and 77 where created in the early days of programming. Who cared about reusing code or documentation? IO You could read a file and print so what is the big deal. The statement that Fortran is quicker to code and that the resulting objects are always extrenely efficient are true if these conditions are met.
1. The programmer know Fortran well.
2. The compiler is very good.

Fortran is not the best choice today for most tasks. If I knew Fortran really well, had a really good compiler, and had a project to read in a dataset and do some heavy math I would be use Fortran.
What would be very handy would be a version of Perl or Python that had the math power of Fortran.
Perl is already being used a lot for scientific work.

Re:Oh come on

[Theatetus]

Good grief, FORTH was more advanced.

FORTH can pass compiled and uncompiled closures on the stack, with either static or dynamic binding within them as you choose. That's more advanced than... well... any other language I know of.

Re:Oh come on

[calidoscope]

FORTRAN, especially in its older incarnations e.g. FORTRAN-77,

Older??? WTF??

Lessee, FORTRAN 66 superceded FORTRAN IV which superceded FORTRAN II...

Old FORTRAN is where you had to be careful how you used Hollerith constants which would be 10 characters of 6 bits each on a CDC-6400.

Old FORTRAN compilers would barf at IF(...)THEN lines and give errors messages for ENDIF.

Old FORTRAN is where the unit numbers for I/O actually connected to physical devices.

Old FORTRAN is where the senseswitch actually read whther the switch was on or off.

F77 isn't old FORTRAN, F77 is new FORTRAN. grumble grumble

The first comments I heard about C were "An abomination in the eyes of the Lord" and "If Bell Labs hadn't invented the transistor, the phone company would still be using vacuum tubes"

Whippersnapper - probably wouldn't know what a keypunch was even if it bit him on the ass. It would be astonishing if he saw a FORTRAN coding pad.

Re:Oh come on

[turgid]

Whippersnapper - probably wouldn't know what a keypunch was even if it bit him on the ass. It would be astonishing if he saw a FORTRAN coding pad.

Not quite, but at my old power station the primary reactor temperature monitoring computer was a Honeywell 316 with a teletype terminal, two green-screen displays (one for each reactor operator), a built in 160k disk and 32k-16bit words of ram. It has multitasking, and a paper tape drive for booting the operating system. There was no file system on the disk. Temperatures and flags were stored in sectors on the disk, which were loaded and modified using an octal monitor program. What fun that was. Luckily it the disk gave up in summer 2000, and couldn't be raplced, so the 2nd hand PDP-11/70s they bough 10 years previously, running RSX-11/M and some proprietary software written in CORAL-66, became front line. The power station closed in 2002. I was born in 1974. The honeywell 316 came on-line in 1972, the year my parents were married. It came with a FORTRAN-IV compiler...Yes, we had drawers full of paper tapes with the system on.

So, all those cold, dark Scottish winter afternoons spent loading hex into my ZX81 paid off when I grew up. I wonder how many kids today unedr 10 know what hexadecimal is, let alone could code a hex loader in BASIC off the top of their heads?

Kids today!

Re:Oh come on

[calidoscope]

Born in 1974? Figures... ;-)

I was born 1954 - was first exposed to FORTRAN in January 1971 on a CDC-1700 (at CDC's La Jolla facility) - compilation speed for a real simple program was maybe one line every 3 to 5 seconds. The CDC plant is no longer there, but it was about two to three blocks from Sun's new San Diego facility is now located.

Curious about the old power station - would be fun to look it up in one the "World List of Nuclear Power Plants" that showed up in Nuclear News twice a year.

I seem to recall that the last PDP-11 was shipped a few years ago - that architecture showed some staying power.

I wonder how many kids today unedr 10 know what hexadecimal is, let alone could code a hex loader in BASIC off the top of their heads?

Darned few... My 5.5 year old daughter is pretty adept at using a GUI, but not sure if she will ever learn to use a command line, much less Hex. Of course, in my days, we used Octal NOT Hex!

Re:Oh come on

[turgid]

Curious about the old power station - would be fun to look it up in one the "World List of Nuclear Power Plants" that showed up in Nuclear News twice a year.

Here she is. Reactor 1 is on the left, 2 on the right and the turbine hall is in the foreground. My office was in the low bit at the right hand end of the turbine hall. It's a Magnox station, which means natural uranium metal fuel in "magnox" cans, graphite moderator and carbon dioxide coolant. Thermal efficiency was about 23-25%. On a very good day, with a cold river Blackwater, no refuelling backlog and good deskdrivers it could just about manage 246MW electrical. The reactors were 480MW thermal.

First went critical in 1962, last shut down was March 2002. I left in 2000 to get a job with a future...

Economics force it to close :-( The river is too shallow to build a more powerful replacement (not enough cooling water).

Re:Oh come on

[boots@work]

You know, that sig makes it really hard to take you seriously.

Re:Oh come on

[LWATCDR]

Then don't take me seriously. That is up to you. How foolish must you be to decide the value of persons comment based on their sig.
The question now is are you from the extreme right and hate my sig because I said Evolution was true or the extreme left that hates my sig because I said there is a God?

The Answer:
It doesn't matter a biggot is a biggot.

Re:Oh come on

[boots@work]

Ah yes, obviously anyone who disagrees with you must hold extreme political opinions. Go on, call me a Nazi or Communist if it makes you feel better.

What is this "biggot" you speak of?

Re:Oh come on

[LWATCDR]

Geee it is a called a typo. I ment bigot. Sorry I must be the first person ever on slashdot to make a typo.
I have no problem with someone disagreeing with me. However you said that you could not take my comment on a technical issue seriously based on my beliefs. If the subject had was someone claiming that they could or disprove that there is a God you might have a reason to say that my sig was some kind of proof that I was biased. My comment was on Fortran. I even suggested some alternatives to Fortran. Now someone might have said I was talking out of my hat for thinking that you could replace a compiled language with a scripting language. They might even be right for very large data sets you might really need the speed. Or they could have pointed out that Mathmatica already fills that need. Mathmatica support .net now so it might really become a standard for heavy math programing. However you dismissed my comment based on my sig.
1. You have to be pretty extreme to bash someone for their sig. I have seen lots of nasty sigs posted but that is their sig the can have what ever they want.
2. You dismissed my comment based on the fact that I believe in God or that I believe in evolution. It is not any different that if I had "Member of African American Programers' Group" in my sig and you said that you could not take my comment seriously. That is where you fit in to the deffiniton of a bigot. That good thing is you probably are not really a bigot. Odds are you are nice enough in real life but that you lose your manners on line like most people. I have writen things that where less than kind about technical issues on slashdot. I have also blasted those that want to teach creationism in class rooms. I have even blased them in real life I am sorry to say. To dislike someone because the believe in God is hate and should be considered below any educated person.

Re:Oh come on

[Anonymous Coward]

Typo? You mispelled the word TWICE. That makes you guilty of illiteracy, not bad typing skills. And for that, I hope your God removes you from the gene pool before you pass on your stupidity genes to future offspring. In short, I am trying to say, "Die you godie freak!"

It's "free software" not "free-ware".

[jbn-o]

You might think that a free-ware compiler would be good for promoting the language.

Haggle over the technical merit of g77 all you want, but free software is not the same as "free-ware".

Re:It's "free software" not "free-ware".

[Brandybuck]

If it's free beer then it's freeware. Software that is gratis (free+ware). Since no one has to pay to get g77, it's freeware. I wish the FSF would stop trying to redefine the English language.

Re:It's "free software" not "free-ware".

[Dr. Awktagon]

yeah, it's just like public domain.

Re:It's "free software" not "free-ware".

[jbn-o]

If it's free beer then it's freeware.

I've never seen anyone refer to zero price beer as "freeware": "We're having a party and there will be chips, salsa, and freeware at every table" sounds confusing to me--will there be beer or computer software at every table? Perhaps you were referring to "Free as in beer"?

Software that is gratis (free+ware). Since no one has to pay to get g77, it's freeware. I wish the FSF would stop trying to redefine the English language.
--
Open source, without that fishy smell. FreeBSD

It's ironic that someone who misstates the phrase the FSF uses accuses the FSF of "trying to redefine the English language". As the link I pointed to clearly illustrates, other languages don't use the same word to mean freedom or gratis and leave it up to you to figure out which meaning is intended. The distinction the FSF makes about kinds of software is not understood by talking about price. You're right that you can get g77 without paying for it but that is a side-effect of the freedom to share. One would think someone who hawks FreeBSD in their sig would appreciate this useful distinction.

Re:It's "free software" not "free-ware".

[Brandybuck]

You read way too much in my use of "free beer" versus "free as in beer".

Freeware is software that has no monetary cost. g77 has no monetary cost. Thus g77 is freeware. That may not be the preferred term, but it is accurate in it's way. Side effect of the GPL or not, it's still freeware. The original poster should not have been castigated for using the term.

As an aside, though English has only the one word "free", while many other languages have two, it doesn't make much of a difference, since there much more than two definitions for the word. Depending on your dictionary, there could be between twelve and eighteen. Now that I know the correct word is "libre", which of the eleven to seventeen definitions is the correct one?

The common BSD definition of free is "unencumbered by legal restriction".

Re:It's "free software" not "free-ware".

[Anonymous Coward]

Why the hell would I care what the GNU people think?

They bastardized the word free in the first place.

What about typos :) ?

[Captain Rotundo]

The extra "not" in that post made it almost impossible to understand since it gave the most important sentance the exact OPPOSITE meaning (although in poor english).

took me a while to understand what the heck was going on there.

Re:Eventually? How about currently?

[stevef]

What is this "aliasing" all about? Can you go into more detail regarding why fortran is better than C for numerical computing?

Bare in mind that I have NO knowledge of fortran, but I do compile fortran code for people doing scientific computing. I can see that at some point in the future I will probably have to learn a bit about fortran. It would be nice to know why bother? :)

Steve

Let it go...

[AJWM]

The last time I programmed in Fortran it was still Fortran IV. (Oh, wait, I did write a version of "Asteroids" for a VAX with a graphics unit and AD/DA hardware in DEC's Fortran 77 -- but that wasn't serious programming.)

When I wanted structures and records and fields (oh my!) I went with PL/I or Pascal or C or C++ or Java (in roughly that chronological order). Let it go. If you want to do Fortranish things, use (standard) Fortran. If you want to do Pascalish or Cish or Adaish (etc) things, use that language.

There's probably a corollary of Henry Spencer's law about ignorant OS designers reinventing Unix (poorly) that applies to programming languages, although I haven't quite figured what the "target" language (the way Unix is the target OS) is. (Probably Algol68 ;-)

Re:Let it go...

[pyrrhonist]

(Probably Algol68 ;-)

And remember, it's not a C++ style comment, it's an Algol style comment!

Re:Let it go...

[Anonymous Coward]

> There's probably a corollary of Henry Spencer's law about
> ignorant OS designers reinventing Unix (poorly) that
> applies to programming languages, although I haven't
> quite figured what the "target" language (the way Unix is
> the target OS) is. (Probably Algol68 ;-)

It's Lisp (I think the quote is "Those who do not study Lisp are doomed to reimplement it-Poorly")

Re:Want "modern" features? Don't use F77

[Kris_J]

Indeed. My mother still uses the Fortran v2 DOS compiler because it has no bugs and it does the job she needs (usually brute-force finanical model testing IIRC).

Well fix it

[bluGill]

It is open source. It doesn't work if you sit there and cry about it not working the way you want. It works great if you decide it doesn't work so you fix it yourself.

I don't care how you fix it. You can write the code yourself, or you can hire someone to write the code for you.

Fortran Standards

[aster_ken]

The gropu that works on the Fortran standard is J3.

The current standard is Fortran 95 which, as another poster pointed out, is currently being developed into g77. However, work is progressing nicely on Fortran 2003. From the web site above:

"Fortran 2003 is an upwardly-compatible extension of the current Fortran standard, Fortran 95, adding, among other things, support for exception handling, object-oriented programming, and improved interoperability with the C language."

Re:Fortran Standards

[rangek]

The current standard is Fortran 95 which, as another poster pointed out, is currently being developed into g77.

I am pretty sure that is not true. All of the g77 information I could find indicates that g77 is no longer being developed. There are two Fortran95 frontends to gcc out there: g95 and gcc-g95, but these really have nothing to do with g77.

Re:Fortran Standards

[aster_ken]

This document shows the status of the g77 project. It was last updated in May of this year, and there are a few cryptic references to some work being done to support Fortran 90 (the most current standard developed by ISO/WG5).

From the g77 documentation here and here we see that Fortran 90 is at least partially supported in the compiler - some support only available via a compiler option.

Adding these together we see that their incomplete Fortran 90 feature set is still being developed, and we will probably see full support before a 4.0 compiler release.

As far as Fortran 95 and Fortran 2003 - I haven't found any concrete proof to support the previous poster's claim. But to his his credit, I have not searched the mailing lists and newsgroups.

Re:Fortran Standards

[rangek]

When I think of Fortran90/95 I think of three things that f77 lacks, data types, pointers, and modules. From what I can see the g77 people are never going to add such things. Hence the existence of the g95 projects.

Re:Fortran Standards

[Anonymous Coward]

I think Toon Moene may still be doing some maintenance on g77, but as far as I know the intention is to phase it out when gfortran (formerly gcc-g95, forked off of g95) is finished and have gfortran take over.

I'm serious

[TheSHAD0W]

(I'd still use C because I've never used Fortran).

Why don't you read the basics of Fortran syntax before you pronounce that judgement? I never said that Fortran was unusable; I said it had major structural problems in the language. It's impossible to write a complex program without using GOTOs, for instance. It's okay for quick 'n dirty, small stuff, but for long-term use it can be a maintenance nightmare.

Re:I'm serious

[etcshadow]

It's impossible to write a complex program without using GOTOs

I call bullshit on you. There is <b>nothing</b> about fortran that makes GOTOs any more necessary than they are in C (which is an argument in and of itself... however I come down on the side of "never use them").

I taught two beginner's programming classes between 1995 to 1999, one in F77 and one in C (with the last week talking about C++). Apart from the lack of pointers and structures, F77 has (essentially) all of the language structure C (or any other procedural language) does. I never allowed my students to write GOTO statements, and it was never necessary (beyond the same caveats C programmers have when saying that). As a side note, we got significantly further in programming with the fortran groups than the C groups, despite the fact that the fortran class was taught to freshman chemial and mechanical engineers, and the C class was taught to electrical engineers (who, as demographic cross-section, had somewhat more of a bent towards programming to begin with).

It's true that C is made far more capable (and difficult to learn) because of pointers. It's also true that the lack of structures makes F77 a bit of a pain in the butt at times (but not in any way less capable). However, complex data structures are still <i>possible</i> in F77, if a pain in the ass. I've written binary search trees, recursive descent parse trees, and linked lists in vanilla F77 (no DEC extensions). Granted, the F77 idiom for doing this kind of stuff is really kind of sad. However, I could argue that there are similarly lots of things that C programmers do every day which are horribly fugly because they can't use the idioms of perl (for example).

Anyway, maybe it's pointless to argue because, in the end, I really... <b>really</b> wouldn't recommend anybody program with F77 any more.

Re:I'm serious

[babbage]

It's impossible to write a complex program without using GOTOs

I call bullshit on you. There is nothing about fortran that makes GOTOs any more necessary than they are in C (which is an argument in and of itself... however I come down on the side of "never use them").

You do realize, of course, that once your compiler gets its scruffy mitts on your code, that it all gets turned into GOTOs and JUMP statements at the assembly & machine code level, right?

GOTO is a perfectly necessary construct, and in the right circumstances, completely defensible.

When Dijkstra said that "GOTO is considered harmful", I suspect that he didn't mean to banish it altogether. There's lots of "harmful" things that we deal with every day without batting an eyelid: operating a motor vehicle, working with dangerously high voltage electrical systems (like, say, a computer, or a toaster), handling highly flammable substances (paper burns, man, and those books of you're are just made out of the stuff). etc.

The solution isn't to avoid all harmful things, like GOTO or toasters, but to design our systems such that we can take advantage of the useful properties of these things while shielding us from the dangerous bits. That's why the toaster's heating element is hard to reach (but why pulling out your toast with a fork is dangerous -- but sometimes seems necessary), and that's why most of your programs' GOTO statements are wrapped up in calls under the compiler level (but why high level languages often have GOTO constructs that can also be dangerous, but sometimes make things easier to solve).

A firm, unwavering belief in a slogan such as "GOTO considered harmful" is a sure sign that you've missed some of the subtlety that any catch phrase like this is likely to have elided. Don't fall into that trap. GOTO may be harmful, but that doesn't mean that it doesn't have a necessary place. Students should be taught not to reflexively avoid the harmful thing, but to understand what it is, how it is needed, and what can go wrong when using it.

Re:I'm serious

[etcshadow]

OK, first of all... I *explicitly* sidestepped the argument about GOTOs.

That being said: lets take your goto/toaster analogy. That's crap. A better analogy would be comparing block constructs (loops, branches, subroutines) to toasters and comparing exposed 120V heating coils to GOTOs. I mean, sure loops are implemented using "GOTO"-like assembly instructions, but with a loop (or a whatever) you have certain guarantees and warantees on state consistency and the like. Do you toast your bread with a coil connected directly to wall outlet (without some pansy-ass "electric cord"... I mean, hell, that's what paper-clips and forks are for, right?)? Why use variables, anyway... just write to the registers!

Erg... I don't want to have this argument. I'm being trolled. Just walk away, just walk away...

Re:I'm serious

[babbage]

:-)

I'm really not trying to troll, honest. I just think that the "$foo considered harmful" meme is frequently taken much too far.

The original points behind essays such as Dijkstra's "GOTO considered harmful" or Tom Christensen's "CSH considered harmful" may be valid, but IMO this kind of polemic argument often goes out of its way to ignore any of the redeeming qualities in the harmful thing being considered. This kind of thinking, in my opinion, can lead to "forbidden knowledge" and, ultimately, a sense of ignorance that is worse than the original problem.

It's reflexive, absolutist thinking that bothers me, not the GOTO argument itself. GOTO is harmful, sure, but there are defensible uses for it. Knowledge is being aware of the rules, guidelines, and best practices; wisdom is knowing when to ignore them.

Lol

[BoomerSooner]

I was just joking. The reason you are stating is the reason I've never used g77.

So little logic from a programmer

[Crashmarik]

How can anyone think that the free availability of a vital resource impedes the progress of anything ? Is the availability of free C,pascal,forth etc implementations killing off those languages. Is the availability of GCC for win 32 stopping anyone from using Visual C ? Is the availability of freepascal killing delphi ?

The answer is no. A free implementation of fortran makes it that much easier for the language to be taught. If there are people that know the language they will use it. If people use the language it will grow and develop.

If you wan't to know what's hurting fortran you might try readin Dijkstra's "Goto Considered Harmful".

Re:So little logic from a programmer

[Anonymous Coward]

How can anyone think that the free availability of a vital resource impedes the progress of anything ?

I don't think the hypothetical problem is that hard to understand, although I agree with you that the fortran language is a larger reason for its decline.

Basically, if there is a free compiler that doesn't support the entire language as it is normally used, people will decide not to use the language based on the shortcomings of the free compiler instead of the language's merits. I mean what if (hypothetically) the only freely available C compiler didn't support dynamic memory allocation, but there was a complete and highly-optimized open-source fortran 77 compiler with the DEC extensions and whatever else it took to make fortran usable. People might use fortran instead of C, even in situations where the C language is a much better choice, and C usage would decline.

Re:So little logic from a programmer

[pyrrhonist]

If you wan't to know what's hurting fortran you might try readin Dijkstra's "Goto Considered Harmful".

How often do people actualy use a goto in Fortran? I can't remember ever using a goto in the Fortran stuff I did. Of course, we had a preprocessor that may have helped with this, so I'm not sure if it didn't turn certain constructs into gotos. Seriously, how often do people use a goto?

Re:So little logic from a programmer

[mcdrewski42]

Well, I know of at least one enterprise which has abandoned GCC since they needed 64-bit functionality which GCC didn't support properly. I guess this is the same thing...

Re:So little logic from a programmer

[BrokenHalo]

There is no edict writ in 300-foot letters of flame that says "THOU SHALT/SHALT NOT USE GOTO". I have to admit that from time to time I have used a GOTO (in Fortran IV) but I haven't lost much sleep over it. This is ultimately more of a philosophical argument than a practical one. Sure, Dijkstra was a brilliant man, but he didn't have a monopoly on sensible ideas.

Re:So little logic from a programmer

[Anonymous Coward]

Free availability easily kills things; that is the MS mode of operation. How could the free availability of IE (and its "extensions") impede the ability of Netscape? Look at all the non-standard "innovations" it brought us. Look at how widely used CSSs are. I am not aware of the subtle aspects of g77, but if it is used to teach people and it doesn't have the full functionality of the language, it will certainly hurt its development because it would just encourage those who whine "FORTRAN sucks because it can't do such-and-such."

I usually find the ones who bash FORTRAN the loudest are not ones who ever learned the language ("I had this course once where we had to write some fortran and I hated it"). If you (this is the general "you" as there seems to be multiple people in this post who argue along the same lines) think that GOTO is a vital part of FORTRAN, then you are clearly very ignorant and should keep your uninformed opinions on FORTRAN to yourself.

I've had very positive experiences coding FORTRAN77. I like pass-by-reference, anything you'd want to do with a structure I would use RECORD, and anything you'd want to do with a pointer I would use COMMON blocks. In fact, pointers are natural to FORTRAN because everything is passed by reference anyway.

Re:So little logic from a programmer

[edwdig]

How can anyone think that the free availability of a vital resource impedes the progress of anything ?

Did you see much C++ code being written that took full advantage of the standard, and did not violate it in any way before GCC 3.0 was released? I certainly didn't. The two biggest C++ projects I can think of are KDE and Mozilla. KDE took work to get working with gcc 3.0. Mozilla's decision from the start was to only use a minimal subset of C++ to avoid compiler issues.

Or how about this one... how many people write fully HTML compliant web pages? Not many, compared to the numbers that don't. Why not? Thank the freely available Internet Explorer for that.

Re:So little logic from a programmer

[Anonymous Coward]

"How can anyone think that the free availability of a vital resource impedes the progress of anything ? Is the availability of free C,pascal,forth etc implementations killing off those languages. Is the availability of GCC for win 32 stopping anyone from using Visual C ? Is the availability of freepascal killing delphi ?"

Tell that to Sun and their MS spat over MS shipping a defective bastard Java that held back the language as a whole.

Re:So little logic from a programmer

[Bingo Foo]

How can anyone think that the free availability of a vital resource impedes the progress of anything ?

Think "welfare."

Re:So little logic from a programmer

[PCM2]

If you wan't to know what's hurting fortran you might try readin Dijkstra's "Goto Considered Harmful."

I don't know whether that's meant to be a criticism of Fortran as a language or merely the way in which it's used. I've never learned Fortran and therefore I've never read much Fortran code, so I can't say whether most Fortran programmers use too many Goto statements.

Still, if we're all supposed to regard Dijkstra's essay as gospel, then why have language designers continued to add Goto statements to languages since 1968? Even C has one.

Re:Eventually? How about currently?

[Anonymous Coward]

You can avoid aliasing in C. Use statically sized arrays instead of malloc'ed ones and don't take the addresses of things.

MOD PARENT UP!

[Anonymous Coward]

Everyone should see this! It rocks :-)

Re:Eventually? How about currently?

[Jerf]

I went poking around on Google and could not find an answer in 30 seconds, so you are forgiven. ;-)

I think this page on aliasing should answer most of your good question.

Add to that page the fact that if a compiler can't be sure about something, the answer is typically to copy the thing it can't be sure about into a safe location, and either copy it back somewhere after the "unsafe" thing or explicitly check it for changes.

For instance, if you're calling a function and the compiler can't know what it's going to do to the caller's registers, the compiler must painstakingly copy the registers out to main memory (well, it'll probably land in L1 cache but still it could be very expensive compared to the function itself), call the function, and copy the registers back in, whereas if the compiler can know it's a little function that only uses registers X and Y, it can only save those. If you're calling lots of little functions, this can add up.

A real example of this? If you're making a static call in C to a function, the compiler can go look at the function and do this analysis. If you're calling through a pointer, a common operation (at least, I can't stand using C without it...), it can't, because that pointer could be pointing at anything, up to and including a dynamically constructed function (if you're brave). To maintain its promises to the programmer that a function call never changes the variables in the caller (which may be located in registers), it has to protect all the registers.

Aliasing is a nasty problem because it's completely opaque to the compiler; the compiler can't see through that indirect function call to the function beyond, not even in theory. As the page mentions, other techniques are being developed that don't involve that sort of opacity by working around aliasing, and the JIT compilers take a different, more dynamic tack that in theory lets them do this analysis dynamically. (The Transmeta processors can also do some of this stuff, which is one of the ways they can speed up code when they run it a lot; they can do this more expensive analysis and dynamically optimize the code.)

It's open source

[Anonymous Coward]

You want more, you write it. It's not like people using g77 don't know how to program.

Re:Flame on! -- wrong perspective

[Alinabi]

You are looking at the issue from the wrong perspective. Unlike a software engineer, scientists does not consider the software they write a final product. Their product is the result of the computation performed using the software. That's what brings them grant money. Thus, they would like to spend as little time as possible writing software and dedicate most of their time to interpreting those results. Since most of the numerical libraries out there are written in FORTRAN and that they are already familiar with the language, I think FORTRAN will remain their darling for a long time. It's a fact of life, not a matter of policy.

By the way, most of them use commercial compilers rather than g77, because they need the optimizing features which g77 does not provide (think parallel computing).

Re:Eventually? How about currently?

[jaoswald]

You mean, write Fortran-style programs in a crippled sub-dialect of C?

Plus, how many C compilers are made to optimize for this case that is extremely common in Fortran, but extremely rare in C code?

Fortran compilers are the best compilers for Fortran programs. C compilers are best for C programs. Fortran compilers can be expected to perform poorly on "C-like" structures, and C compilers are likely to perform poorly with "Fortran-like" programs.

77 = 1977 right??

[josepha48]

I think the real issue is that people see languages such as java, C, C++, .net, and newer languages as more exciting to program in and fortran is percieved as archaic. Also there is only a small market for fortran programmers. Many people probably think that fortran is dean, not because of the compiler, but because fortran is like pascal and cobal. Old languages! Personally when you look at the number of java / C# / VB .net jobs out there, would you really want to learn a language that has such a small market share? Where are teh jobs for a fortran programmer vs C/C++/java, etc?

Re:Eventually? How about currently?

[jmv]

As far as "why is it still being used at all" comments, two words for you: no aliasing.

If that's the only reason, then it should be relatively easy to get similar performance in C99 simply by adding restrict's all over the place, no?

Aliasing, Fortran, C, and C++

[devphil]

Yeah... I thought the CS community at large mostly knew about this. Okay:

Fortran specifies that Thou Shalt Not Alias, so in the example on the page that you linked to, the function-calling programmer, the function-implementing programmer, and the compiler can all assume that everything refers to non-overlapping memory, and can optimize the hell out of read/write memory accesses.

When Dennis Ritchie designed C, it was a deliberate decision to not prohibit aliasing. (C's ancestor languages may have allowed aliasing as well, and DMR just decided to continue that; I don't actually know. But the question was brought up and considered; it's not an accident.)

When C was first being standardized by ANSI, a really sloppy proposal was made to add a 'noalias' keyword. It was so bad that DMR sent a public letter to the ANSI committee stating, "noalias must go; this is non-negotiable." So C89 has no way of restricting aliasing.

C++98 and C99 do, sort of. C99 added the __restrict keyword to the language. C++98 left the core language alone and defined a library type, std::valarray, that is free of aliasing by definition, opening up a number of optimization possibilities.

Valarray didn't quite work out; its design is semi-broken. Far more hopeful is using expression templates to expose more of the numerical computations to the compiler, so that more optimizations can be done on visible numbers. Check out Blitz++ at oonumerics.org for an example.

Re:Aliasing, Fortran, C, and C++

[Jerf]

Yeah... I thought the CS community at large mostly knew about this.

They do; my elaborations came from my compiler course. But there are a lot of people, both programmers who never took formal courses (and this is one of the examples of things that programmers very rarely learn on their own but can be very beneficial to know when you need to make that function go 20 times faster, and this is also why it's so hard to explain why a good education can still be helpful to all but the most dedicated self-learners) and people who aren't in college yet.

Those people just need a bit of help figuring out what to search for, which is why I stepped in. A simple search for aliasing is swamped by the graphical meaning of the term, which is basically completely unrelated.

I ended up with "compiler aliasing problem optimization" (no quotes in the search query itself) before I found anything.

Re:Aliasing, Fortran, C, and C++

[James Lanfear]

C's ancestor languages may have allowed aliasing as well, and DMR just decided to continue that; I don't actually know.

C's ancestors were untyped, so I don't know if it would have been possible to prevent aliasing. At best you give hints when pointers were copied, and hope no one deref's anything else.

C99 added the __restrict keyword to the language.

It's restrict in C99. __restrict is a GNU C extension.

Sad but (mostly) true.

[Professor D]

In my former life as a grad student in the sciences the lack of a free f90 compiler definately prevented adoption of GNU/Linux as an alternate/cheap platform. We had code that simply could not be compiled because g77 lacked features that are older than some people reading this post!

The vendor compilers however had all the f90 options, which 'forced' us to pay for the expensive developer packages instead.

At the time, the two extensions we needed (IIRC) were STRUCT and POINTER, which were on g77's to-do list. Now, the better part of a decade later, they _still_ are AFAIK.

I wonder why none of the many high-budget science projects that use open-source extensively have never properly funded g77 development?

Re:Sad but (mostly) true.

[WallsRSolid]

It's because none of those "high-budget science projects" consider themselves highly budgeted. Those that win grants with a lot of money have a lot to accomplish with that money.

For each programmer they hire to work on modernizing Fortran, how many grad students and postdocs do they not hire due to funding constraints? Who is willing to lose that much science for their group? Not many.

It doesn't mean they *shouldn't* put money into Fortran, just that I'd be very surprised if they did. I'm sure I myself will be guilty of exactly that when I reach the ranks of the professoriate.

Why FORTRAN anyway?

[cwsulliv]

I cut my teeth in computing 40 years ago on FORTRAN and used it for general engineering/scientific calculations until switching over to C language about 15 years ago. From my perspective, C seemed to offer everything that FORTRAN had, plus a lot more.

What advantages are there to using FORTAN over something like C for scientific/math/engineering calculations? Is it mainly just maintenance of legacy code? Or maintenance of legacy coders? :-)

Re:Why FORTRAN anyway?

[Anonymous Coward]

Two words: multidimensional arrays.

In C, multidimensional arrays are more difficult to use than one-dimensional arrays. In Fortran, there are real multidimensional arrays that are easy to use in a general way. Yes, you can use structs and stuff in C to get around the problems, but the point is that it is *easy* in Fortran. If you really need dynamic allocation (and your compilers don't suck) you can just call malloc from F77.

Re:Why FORTRAN anyway?

[BrokenHalo]

If you still remember your Fortran, you might just as well keep using it if that's what gets the job done. If you want to do your stuff in a way that is currently trendy, use C or C++. I've made a number of pro-Fortran posts on this topic since I'm another greybeard (figuratively speaking), but I have to admit that every line of compiled code I've written in the last 5 years or more has been in C. Both are excellent. Ultimately, it all depends on what fits your headspace.

Re:Flame on!

[pyrrhonist]

Fortran has too many structural problems to use for major applications.

Fortran is the language used in the communication terminals the Navy uses to send and receive data through the Milstar satellite communication network.
These devices are used in ground stations, ships, and boomers. That's a pretty major application.

Fortran 95.

[Bill, Shooter of Bul]

Frotran 95 includes the For each programming construct that allows the compiler to perform each action in the loop on a different proccessor. And thats just darn cool.

Re:Fortran 95.

[arkanes]

The intel C++ compiler can do this too. Yay for forward looking technology!

all these coders and none can fix the compiler?

[Anonymous Coward]

all these fortran coders and none of them are willing to fix the compiler? sheesh. go back to your parallel processing class.

I do agree!

[Zo0ok]

I once considered writing real code in Fortran. It was a fairly limited library of functions that were supposed to do heavy computations. Other parts of my program was to be written in C.

When realising that G77 lacked many features that my documentation said I should find in Fortran 77 I gave up and wrote everything in C.

Not blaming anyone, I was still a bit disappointed. The feature I lacked was the possibiliyt to pass structures as arguments to F77 functions.

But of course, if G77 did not exist, I would not even have considered Fortran in the first place (this was an academic hobby project, not a commercial project).

Re:I do agree!

[Anonymous Coward]

I can guarantee you that whereas structures did not exist in FORTRAN 77, there's no way that was a feature that should have been found in g77 in order to be standard-conforming (not sure what your documentation was, maybe something for another implementation).

I won't argue that it wouldn't be useful, but I don't believe g77 is missing anything from standard FORTRAN 77.

This is Depressing

[turgid]

When I was doing Physics at Uni they forced me to use FORTRAN 77 for "portability" despite the fact that I already knew C.

However, 10 years ago, FORTRAN compilers were very much more advanced in terms of optimisation for numerical work than C (e.g. the Cray compiler could do automatic vectorisation.)

I would have thought that if you had a big, expensive supercomputer, you can afford the compiler. Not buying the compiler is silly, because you'll probably end up with an order of magnitude less performance out of it with a compiler whose primary goal is portability and has been designed to work well on totally different hardware architectures.

Having said that, though, if you've got a low end box, you probably want a cheap or free compiler. Why spend $1000+ on a compiler when the box probably cost less? The low end box can probably sustain 100+MFLOPS (easily) and peak well into the GFLOPS. That's a cheap Athlon we're talking about. So you probably don't want to buy a fancy FORTRAN compiler. Why not just stick to C or even C++ nowadays? Legacy code :-(

So you have a problem. The big supercomputer you bough 5 years ago probably has a "slow" C/C++ compiler. The nice cheap box you have on your desk has arubbishy FORTRAN compiler and a reasonable C/C++ compiler.

So, you can convert all your legacy code to C and C++, you can buy a commercial FORTRAN compiler or why don't you universities cough up some time and money to give to the GNU FORTRAN people to help them improve their compiler? Or is that too radical and lefty?

what about the intel compiler ?

[dario_moreno]

The Intel Fortran compiler supports F90, dynamical allocation, works better than Absoft or Portland Fortran, and is free for Linux...and for all of you complaining about Fortran, do you have a job ? I know someone who ended with a very nice job just because he had mentioned "Fortran" on his resume, and had spent maybe 1 week of work on " Numerical Recipes in Fortran" and the Intel/g77 compiler.

In other news

[Chelloveck]

But it's not because the GNU flavor does not implement the de-facto standard DEC extensions to the language that give it dynamic memory allocation, pointers, and data structures. Without these Fortran 77 is indeed barbaric, but with them it is quite pleasant to work with.

Yeah, there's a lot of that going around in the open source world. I've heard of this other project that's stifling growth in a major segment of industry by not implementing the de-facto standard extensions that its commercial competitor uses. You might have heard of it, it's called Mozilla.

I admit that I haven't touch FORTRAN since about 1985, so forgive me if I'm not exactly up on the state of the art. From a little googling, it looks to me like g77 is pretty much an orphaned project. This is free software, man, developed and supported by the community. Have you considered volunteering to fix the parts you think are broken? Or volunteering to work on the f95 compiler effort?

Wrong conclusion

[Anonymous Coward]

You've started with a conclusion (g77 is holding back the adoption of F95) then found evidence to support it. However, if we look at the situation logically, a better conclusion would be that non free software is holding back the adoption of F95. F77 is being more widely used because there is a free compiler available for it. In conclusion, the finger should be firmly pointed at vendors who refuse to release an open source or free as in beer F95 compiler.

Troll question

[yanestra]

Is there still an important reason to program in Fortran?

You can easily link modules of different languages. Why do you still work with a language which was long time obsolete when punch cards went out of fashion?

I mean, of course you can bloat the language with structures it originally didn't dream of, but you can't expect every compiler author implement the newest expansion, for free. Just because he wrote parts of an existing compiler years ago.

I'd say, like the old saying, if you don't find a software suiting your desires, why not writing it yourself?

Re:Troll question

[hubie]

My answer: Why not?

If you know the language and the language can do what you want to do, then why not?

Another good reason is if you are supporting existing software you might want to keep the code consistent.

I'm not sure you can claim obsolescence for Fortran, especially at the time when punch cards went out (mid- to late-70's). The gold standard, F77, was used everywhere, and it remained the gold standard at least until F90 came out. While C was being used for taking care of OS issues (networking, etc.) Fortran ruled the roost for industrial machines and scientific/other computation. I think you'll find that many industrial settings still use machines running F77 on PDP-11's, and a good deal of numerical packages still use Fortran. I don't think anyone is going to write the next GUI app, Quake4, or networking protocol in Fortran, but there are still a lot of things you'd do well to use it.

"FORTRAN is so easy even my mother can use it"

[Per Abrahamsen]

There are some pretty smart mothers out there ;-)

Re:"FORTRAN is so easy even my mother can use it"

[Anonymous Coward]

What did you say about my Momma?

IBM Scientific Subroutine Package?

[Futurepower(R)]

Thanks. I have some routines in Fortran I would like to convert.

Do you happen to know if the IBM Scientific Subroutine Package is available on the Internet? This was a collection of math routines.

Re:IBM Scientific Subroutine Package?

[turgid]

No, sorry, it's been many years since I did any scientific programming. I know Sun has some math libraries that may be available freely.

Re:77 = 1977 right??

[etcshadow]

Well, be careful who you're calling old. C is older than F77 (although earlier versions of fortran are far older).

OK, you asked...

[BrokenHalo]

Doesn't the performance of the compiled code speak for itself?

Here's a history lesson:

Once upon a time, every CPU second on a computer was precious (and charged out accordingly). Consequently, a lot of programmers' jobs involved hunting through source code and optimising it by hand. The quick and dirty fixes that folks like Microsoft can now get away with were not permissible then. You (OK, we) didn't have the resources to run code through just to see if it ran faster or not. The idea was to get it right the first time.

Re:OK, you asked...

[Spy Hunter]

Nice history lesson. Let me tell you a story about today. Today, we use libraries. We trust the library authors to write efficient code, and we don't worry about machine code anymore because programmer time is more expensive than CPU time. Modern compilers take care of most of the optimization for us. If our applications turn out too slow, we use profiling tools and change our algorithms instead of optimizing instruction sequences.

The author of Blitz++ has proven, through these benchmarks, that his code, when compiled with an actual C++ compiler (gasp, horror, so inefficient!), is more efficient than Fortran at tasks in which Fortran excels. I sure don't think he needs to show any machine code to convince me. In this particular case, the C++ machine code would be much longer and more complex, in fact, since it uses a complex algorithm to traverse the arrays. Therefore, looking at the machine code would be totally missing the point.

Re:Want "modern" features? Don't use F77

[BrokenHalo]

but the "barbaric" striped-down version can be highly optimized

You mean Fortran 4, of course... :-)

Re:Want "modern" features? Don't use F77

[BrokenHalo]

Good for her, I hope you're proud of her :-)

what is killing fortran

[Mark Muller]

What is really killing fortran is the perception that fortran == f77. Tell someone you program
in fortran, and they immediately think of old,ugly f77.

I write code (both reasearch and commercial vibration analysis) in fortran90/95 every day - I
use modules, I use pointers, and I get great performance. A few things I also get:

1) clean, neat code that is easy to read by non-programmers.

2) Array bounds checking by the compiler - try that with C++. Array bounds checking saves me
huge amounts of time in development.

3) Compiler checking of function calls, via encapsulation of functions in modules.

4) Easy use of BLAS and LAPACK routines for real computational work.

5) The actual function definition used for the function prototype - I don't have to maintain a
separate prototype for my functions to get the advantages of prototyping!

Fortran isn't perfect (yet). It still lacks the ability to make a function part of a data
structure (ie, classes). It current i/o abilities still suck. It's ability to handle characters and
character strings is terrible. But it does have advantages other than producing fast code, and it
isn't your father's fortran77.

Re:what is killing fortran

[MagikSlinger]

1) clean, neat code that is easy to read by non-programmers.

*snort* I'll believe that when I see it.

2) Array bounds checking by the compiler - try that with C++. Array bounds checking saves me huge amounts of time in development.

I use the STL and not think about bounds ever again.

3) Compiler checking of function calls, via encapsulation of functions in modules.

Unless you're badly describing another feature, that was one of the first features of C++ and ANSI C.

4) Easy use of BLAS and LAPACK routines for real computational work.

Two words: C wrapper.

5) The actual function definition used for the function prototype - I don't have to maintain a separate prototype for my functions to get the advantages of prototyping!

Some argue that having a separate prototype prevents the implementor from arbitrarily changing the interface without warning their other team member.

Fortran isn't perfect (yet). It still lacks the ability to make a function part of a data
structure (ie, classes). It current i/o abilities still suck. It's ability to handle characters and
character strings is terrible. But it does have advantages other than producing fast code, and it
isn't your father's fortran77.

You just said the two most important capabilities of any programming environment in most problem domains (I/O and character handling) suck, so what advantages does FORTRAN have have? Native complex number support? The rest of FORTRAN's "advantages" have long since been added to every other programming language on the planet.

And as for native complex number support, I might point out with C++, you can create identical functionality with a class and operator overloading.

Re:Eventually? How about currently?

[rangek]

There's already a team of very capable -- and young, not ancient/retired/whatever -- programmers implementing the Fortran 9x language, which defines some really interesting constructs. The current plan is for an initial release as part of 3.5.

You mean gcc 3.5, not g77 3.5, right?

Is this really a bad thing?

[yandros]

Let me get this straight:

1) People don't want to pay $500-$1000 for a compiler.
2) The existance of g77 means that they don't have to.

What's the problem again? Shouldn't people be able to make a ``less featureful, less money'' decision? (..and that totally ignores the other values of having a free-as-in-speach compiler).

The sad story of G95

[cimetmc]

Like others said, I think it is not so much the existance of G77 that hurts Fortran popularity, but rather the lack of free Fortran 90 or 95 compilers.
The good news is that this is going to change. The G95 project is well on its way implementing a Fortran 95 frontend for GCC.
Alas, this is kind of clouded by sad news. In fact, the G95 development has split up and there are now 2 separate projects:
http://gcc-g95.sourceforge.net/
and
h ttp://g95.sourceforge.net/

While sometimes competition is good, I think this is not the case here. In fact, there are not so many people with enough knowledge on Fortran 95 and on compiler development, and so this project splitting is just a terrible waste of scarse resources.

Marcel

Re:The sad story of G95

[Anonymous Coward]

Well atlest it's integrated into gcc 3.5 now, so check out gcc-tree-ssa and vbuild and you have your up and running fortran 95 compiler.

It's getting quite good, even without most optimizations, ( some silly stuff to be removed which creates overhead ).

Re:The sad story of G95

[Anonymous Coward]

While I agree that it's unfortunate, there were philosophical differences that appear to have made a split inevitable. If the gcc-g95 group hadn't forked, I think they would have quit working on it altogether, which would have been a worse waste of resources than we have now. (And with Andy finally releasing his source code again, there are opportunities to try to take advantage of the work of both groups, albeit at a notable cost in expended effort.)

Re:Eventually? How about currently?

[Anonymous Coward]

If you're willing to totally sacrifice legiblity, sure.

FORTRAN was designed for physicists and engineers to get good performance out of supercomputers.

As sure as death, taxes, and ...

[Anonymous Coward]

Just as every MS or RMS story will draw the same predictable discussion threads, every story even remotely mentioning Fortran always brings out the loud-mouthed ignorants who make all sorts of embarassing claims that "fortran can't to this" and "fortran can't do that."

Hey, if you don't like it or don't understand it, then shut up and use something else. Don't embarass yourself with the fact that you either didn't learn the language and you can't express an intelligent statment about it, or that you jumped head-first onto the OO bandwagon and drank the KoolAid, or that Fortran isn't the flavor-of-the-month "modern" computer language and you gotsta show how l33t you are by using something kewl.

We'll make a deal: I'll keep my Fortran out of your gui apps if you keep your scripting languages out of my high-performance computations.

Re:As sure as death, taxes, and ...

[Anonymous Coward]

THUMBS UP! Why did you post anon? I could have added you to my friends list

Re:Eventually? How about currently?

[jmv]

Actually, what I was saying is that I was under the impression that there was more to it than the aliasing rules. As for sacrificing legiblity, I don't think adding a couple restrict's where it really matters (in most places, it won't) would be that bad.

Of course, the extreme solution is to preprocess your code with s/int \*/restrict int \*/ s/float \*/restrict float \*/ and so on... :)

Fortran 77 is just fine.

[tsphere]

The only reason to learn Fortran today is to work with old code. The old code is invariably written in F77, since it is without a doubt from the 70s itself.

there is no good reason to develop a new application on fortran today.

well, except for massively parrallel calcuations using parallel optimizing compilers.

but write it in F77 anyway, it's all you need.

if you really need dynamic memory or pointers, write it in C. it's faster, easier to optimize with plain gcc, and also from the 70s.

or just buy freaking matlab or mathmatica or something.

I hope it will

[Anonymous Coward]

Afaik Fortran is still used because there are many programs and library that are still in this language and noone wants to convert them. This is a great reason indeed, mabye it is not a good reason for a free compiler by the way, and I don't know if someone in the OpenSource community will miss fortran so badly. Maybe it SHOULD die :D

g77 fills a real need, just not every need

[Anonymous Coward]

There's a tremendous amount of high quality numerical code at netlib.org much (most?) of which is in F77. It's crazy to rewrite it. Dynamically
allocate in C or C++, call the library routine and get on with the job.

It would be nice to have structures in g77 and the ability to access elements in COMMON in gdb.

g77 lets people get work done w/o spending as much for their compiler as they spend on the computer.

F77 shares w/ C a major virtue. The languages are simple enough to understand and remember.
I'd be very sceptical of claims that someone can remember a large fraction of the C++ standard. It's too big and complex.

Let's not forget the old quip about Algol 60 being a great improvement on it's successor

Re:Want "modern" features? Don't use F77

[Kris_J]

Good for her, I hope you're proud of her :-)

Always. Few children have parents that can debug their code (or at least the logic in their code).

Re:Flame on! -- wrong perspective

[Hast]

Well there's always "languages" like Matlab which IMHO are a lot nicer than Fortran. Though my experience with Fortran was charred by converting VAX programs to Win32 and Unix. And the original coder was apparently unaware that there were such a thing as commenting and that "three-way goto" could be a bad idea for readability.

Most engineering places I've seen have used tools like Matlab, Matematica and Maple for computational stuff. And in my experience it's a lot nicer to do it in Matlab. (Though that language suffers from it's share of braindeadness as well: Begin arrays on 1 when all matemathics and engineering disiplines begin at 0?)

i'm disappointed myself.

[the_greywolf]

but the g77 compliler is indeed much less archaic than you make it sound. it does correctly support a number of F90/F95 constructs, though not in completeness.

my big disappointment is that i have to use two separate fortran compilers (Intel and G77) to get anything done, and that is *GREATLY* stifling my work, vbecause one compiler will compile correctly, and the other will not. and the roles switch continuously.

the problem isn't that G77 is stifling fortran development. i think the problem is that Fortran fans are stifling the development of a decent compiler.

what's worse, is that the code i'm being forced to maintain was literally written in the 70's and is so damned sloppy i can't read it, much less work with it. it makes me hate the FCC.

i would save hundreds of manhours simply by REWRITING the damn code in a real language. screw bounds checking and fast math code. i want maintainable code. not a pile of dog shit.

No

[Anonymous Coward]

... it is natural death... ageing may be?

Mod the parent up!

[Anonymous Coward]

The parent is dead on.

FORTRAN in its modern instantiations (F95) is completely unlike F77.

I've worked on lots of numerical computing projects, and have been attracted to many of the features of FORTRAN.

Yes, you can achieve many things in C++ through the use of templates and libraries like Blitz, and yes C++ is comparable in speed to FORTRAN.

However, I still think FORTRAN gets it right with numerical computation. For all the gains C++ has made in numerical computing, it still doesn't have the resources--in terms of libraries, etc--of FORTRAN. All the benchmarks I've seen suggest that FORTRAN is still a hair faster than C++. And the syntax of even the best C++ matrix libraries doesn't compare to FORTRAN. FORTRAN has numerical computing built right into the language, and anyone who has dealt with these things can't really deny its appeal that way.

And yet, whenever I sit down to work on a project, C++ wins. Why? Because of the great features of C++ not available in FORTRAN? Not really, because most of the things I want are in F95.

The reason why I go to C++ again and again is simply because I don't have a F95 compiler available for me to use.

So the choice comes down to C++ versus F77, when it should come down to C++ versus F95.

If a F95 compiler were avaiable, I would probably use that. But it's not there, so I use C++.

I personally think the FORTRAN community's biggest obstacle right now is its identity crisis. There's really no such thing as programming in "FORTRAN." You either do F77 or F95. And yes, they're both FORTRAN. But they're not the same language.

FORTRAN advocates have got to stop using F95 as an argument against using C++ when F77 is what people actually use. F77 is woefully behind. F95 is not. But very few people, even in the FORTRAN community, use F95.

How are you going to attract young FORTRAN developers when they can't compile their code? Just compare the number of free F95 compilers to the number of free C++ compilers, or the number of Java compilers.

FORTRAN isn't being killed off by g77. The lack of g95 is killing off both of them.

Good. Let it die.

[Anonymous Coward]

If the GNU compiler not implementing the DEC extensions is what it takes to kill FORTRAN, than more power to them.

I've seen enough legacy FORTRAN code to last me the rest of my career. What an ugly language.

Why not use gfortran ?

[Anonymous Coward]

It's fortran 95 compliant and is targetting legacy compability (g77 ), and f2k.

It has everything and more.

Also I write in fortran because numerical code ( math ) is silly hard to write in C, I use C for os and system programming.

Write a CFD or CAE app in C :-) ... funny ...

Re:Why not use gfortran ?

[cimetmc]

Why not use gfortran ?

Well, I think it's still a bit early for production use. In its current state, it may be fine to play around with and help the developers, but I don't think it is good enough yet for real world programming.

Marcel

Greenspun's 10th rule of programming

[varjag]

There's probably a corollary of Henry Spencer's law about ignorant OS designers reinventing Unix (poorly) that applies to programming languages, although I haven't quite figured what the "target" language (the way Unix is the target OS) is.

"Any sufficiently-complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp."

:-P

Re:Greenspun's 10th rule of programming

[AJWM]

Heh, thanks.

But that's almost a tautology: any C or Fortran program that doesn't contain "an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp" is clearly not "sufficiently-complicated" ;-)

Re:Greenspun's 10th rule of programming

[Piquan]

But that's almost a tautology: any C or Fortran program that doesn't contain "an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp" is clearly not "sufficiently-complicated" ;-)

Not really. Take P to be any program. As we know, most programs can be implemented with a variety of complexites, so we designate the complexity of a program as c, and P(c) is an implementation of P that has complexity c.

Now, Greenspuns's 10th states that for any P, there exists a program L, such that given any epsilon > 0, there exists a c0 such that, for any c > c0, |P(c)-L| < epsilon. (|P-L| is the difference between P(c) and L.) Furthermore (and this is the crux of Greenspun's 10th) such an L contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp.

In other words, the limit of any program (as complexity approaches infinity) is Emacs.

Re:77 = 1977 right??

[josepha48]

yes this is true, but C is also more powerful and there is a C99 (99 or 2000?) spec out that makes a few updates.

Fotran is still better for scientific numerics

[goombah99]

I fully agree that Fortran is NOT for every day programming of word processors, opertating systems, games, device drivers, and GUIs, and that there is a resistance to learning it in schools these days. However I believe the Modern Fortran Language is a better choice for most scientific and numerical programming by non-computer scientists;

Consider the following....
perhaps the biggest complaint in the cutting edge of computing is that no one knows how to effectively program for multi-processors for ad-hoc, scientific programming. Duals are already ubiquitous at the low end consumer market, and of course IBM, sun and sgi have long made units with dozens of cores. Its only going to increase. Likewise Intels now all have hyperthreading to increase the efficiency of their instruction pipeline.

An unsolved problem is how to write custom code for end use in multi-processors that does not depend on knowing the architecture or require special libraries or the very complicated bussiness of writing thread-safe code (locking variables etc...). Shared Memory management is a major bottleneck: How to distribute arrays to multi-processors and keep caches up-to-date after writes is a huge problem.

For parallel processing fortran 95 boasts many language level features that give ANY code implicit parallelism and implicit multi-threading and implicit distribution of memory WITHOUT the programmer cognizantly invoking multiple threads or having to use special libraries or overloaded commands.
An example of this is the FORALL and WHERE statements that replace the usual "for" and "if" in C.

FORALL (I = 1:5)
WHERE (A(I,:) /= 0.0)
A(I,:) = log(A(i,:))
ENDWHERE
call some_slow_disk_write(A(I,:))
END FORALL

the FORALL runs the loop with the variable "i" over the range 1 to 5 but in any order not just 1,2,3,4,5 and also of course can be done in parallel if the compiler or OS, not the programmer, sees the opportunity on the run-time platform. The statement is a clue from the programmer to the compiler not to worry about loop-order dependencies. Moreover the compiler now knows it can fork off the slow-disk-write operation so it does not halt the loop on each interation.

The WHERE is like an "if" but tells the compiler to map the if operation over the array in parallel. What this means is that you can place conditional test inside of loops and the compiler knows how to factor the conditional out of the loop in a parallel and non-dependent manner.

Moreover, since the WHERE and FORALL tell the compiler that the there are no memory dependent interactions it must worry about. thus it can simply distibute just minimal and orthogonal pieces of the A array to different processors, without having to do maintain concurrency between the array segments used by different processcors, thus elminating shared memory bottlenecks.

Another parallelism feature is that the F95 header declaration not only declare the "type" of variable ,as C does, but also if the routine will change that variable. This lets the compiler know that it can multi-thread and not have to worry about locking an array against changes. In the example, the disk-write subroutine would declare the argument (A) to be immutable. Again the multi-threading is hidden from the user, no need for laborious "synchronize" mutex statements. It also allows for the concept of conditionally-mutable data.

Other rather nice virutes of FORTRAN is that it uses references rather than pointers (like java), so less ways to spend your time debugging.

The sad reason the world does not know about these wonderful features, or repeats the myths about the fortran language missing features is due to GNU releasing a non DEC-compatible language. I think the world would be better off if g77 did not exist. By doing so they undercut the affordable fortran compiler market and forced everyone to write for the lowest common denominator to have their code

Re:Fotran is still better for scientific numerics

[Anonymous Coward]

Another parallelism feature is that the F95 header declaration not only declare the "type" of variable ,as C does, but also if the routine will change that variable.

Like the C++ "const" keyword.

Other rather nice virutes of FORTRAN is that it uses references rather than pointers (like java), so less ways to spend your time debugging.

Like C++ reference (&)

Re:Fotran is still better for scientific numerics

[Anonymous Coward]

yes c++ has & references. the point is fortran does not have the potential lethal mistake of accidentally using the pointer.

Re:Fotran is still better for scientific numerics

[t]

I shall respond, but first let me point out that nowhere did I ever talk about features or whether or not one is better than the other. In fact, it is because the differences are not substantial that fortran is going to die. Learning C gives one much greater access to more programming tasks, whereas fortran is considered specialized.

I fully agree that Fortran is NOT for every day programming of word processors, opertating systems, games, device drivers, and GUIs, and that there is a resistance to learning it in schools these days. However I believe the Modern Fortran Language is a better choice for most scientific and numerical programming by non-computer scientists;

Much numerical programming nowadays is increasingly taking advantage of graphing toolkits for visualization. These toolkits are never in Fortran, this makes C the easier to use language.

... effectively program for multi-processors ... For parallel processing fortran 95 boasts many language level features that give ANY code implicit parallelism and implicit multi-threading and implicit distribution of memory WITHOUT the programmer cognizantly invoking multiple threads or having to use special libraries or overloaded commands.

These types of claims are numerous, and your example is trivial. I'm afraid that until there are bench marks to back up your statement no one will care.

btw, writing to disk with a modern operating system is not slow, it's basically a memcpy since the writes are cached and then flushed to disk at a later time. Also, using mmap is much easier than fwrite.

Also, I would love to see some real code that does something useful using forall. And if you are going to explicitly declare your array size (5) in your code then I don't consider it a realistic case. More often than not code is written for variable lengths. Would that affect the performance of a non-trivial example?

Another parallelism feature is that the F95 header declaration not only declare the "type" of variable ,as C does, but also if the routine will change that variable.

This is the standard "static" tag that has been around forever.

I think the world would be better off if g77 did not exist. By doing so they undercut the affordable fortran compiler market and forced everyone to write for the lowest common denominator to have their code comileable by the masses using g77.

This is quite the claim. Would eliminating g77 reduce the price of commerical fortran compilers? Do you have any idea how much a fortran compiler license usually costs (per developer too). At my last job the commercial fortran compiler for our platform cost several thousand per developer. What do you think would happen if we had to chose between C and fortran? Do you have any idea how much more hardware we could buy with the money that would be burned up by license fees? All your claims of speed increases become irrelevant when you take the total budget into account.

Re:Fotran is still better for scientific numerics

[treat]

course can be done in parallel if the compiler or OS, not the programmer, sees the opportunity on the run-time

Is there any platform where this actually happens?

Huh? What free Intel Linux Compiler??

[Anonymous Coward]

The only intel product I see is a free-for-30 days compiler. please provide a link.

Computer "sceintist" != Real Sceintist

[goombah99]

Numerical recipies said it best. Scientist solve next years problems on last years computer. Computer "scientists" solve last years computer problem on next years computer. You appear to have no clue that all your statements about will slow the code and the memory management ot a crawl.

1) clean, neat code that is easy to read by non-programmers.

>*snort* I'll believe that when I see it.

double snort. Did you know its not possible to make a typo type syntax error in fortran 77 that will compile? hard to believe I know but its true. ( You cant misplace a plus sign or comma or leave off a [] and have it compile.
when I try to debug faulty c-code and see something like
i = --j
I have to try to figure out if they could have meant to write
i = -j or i = j-- or i = --j
yuck.

2) Array bounds checking by the compiler - try that with C++. Array bounds checking saves me huge amounts of time in development.

I use the STL and not think about bounds ever again.


SLOOOOW. And unparallelizable. and it kills multi-processing dead. and loss of control over memory management. loss of memory mapped sub arrays, strides etc.... Sure you can do strides in c++ but now they are function calls not direct-to-memory. In fortran you can often pull contionals outside of loops using the WHERE syntax. Its much better to have a good syntax in the language than make up for it with a bunch of function calls and object instantiation. e.g. both languages can write
A = B*C where A,B and C are matricies but C has to do it with objects and overloads. fortran does not. which do you think is going to be faster.

3) Compiler checking of function calls, via encapsulation of functions in modules.

Unless you're badly describing another feature, that was one of the first features of C++ and ANSI C.

So fortran steals a good thing from C and you complain? In fact fortran 95 implemented headers much better than the asanine way C does it. If fortran you can declare the headers for the called functions right in the code that will call the function so fewere prototype mismatches occur. and fortran also lets you specify the not just the type defs but also whether the subroutine will change the arguments or not (without having to pass by value or declate things final). Thus the compiler can know for example if a cache will need to be written back or how to share memeory between two processors. or if it can multi-thread past a subroutine call.

4) Easy use of BLAS and LAPACK routines for real computational work.

>Two words: C wrapper.

whoopee. I can say it in reverse: take the STL and put a fortran wrapper on it. now fortran has the STL.

5) The actual function definition used for the function prototype - I don't have to maintain a separate prototype for my functions to get the advantages of prototyping!

>Some argue that having a separate prototype prevents the implementor from arbitrarily changing the interface without warning their other team member.

well fortran90 can either derive its prototype or you can specify them your call. its nice to have it both ways and not pay any price.

>Fortran isn't perfect (yet). It still lacks the ability to make a function part of a data
structure (ie, classes).
not really true. You can program in an object oriented fashion if you wish. but its more like perl-objects where the data is explicitly passed rahter than C where its hidden from the user.
in C++ you would say

myobject->hash_get(key)
in fortran you would say:
hash_get(myObjectStructure, key)

is there any important difference?
It current i/o abilities still suck. It's ability to handle characters and
character strings is terrible.

Well fortran90 does have nice string handling. and of course it lacks the C string terminator problems that account for so many buffer overflow issues. But I w

Fortran is a better multi-processor language

[Anonymous Coward]

Youre missing the point. The point is if you wat to write and share portable code you dont want all the people who get it to have to buy a compiler. Imagine if Linux was not distributed with a gCC complier so you have to buy a compiler to compile linux. This would be unacceptable. Now suppose that the only free complier was K+R C, with no extensions. Would people be writing all applicaitons in K+R C rather than say java or c++ because they had to have it able to be compiled by the end user. yes they would. That's the problem with issuing non-standard compilers.

Now as for the second part of your screed, people with big computers preumably are not running data bases, word processors or games. They are doing numerical calculations. and they are not pro prgrammers they are sceintist. So they want results not well designed programs. Fortran is the language of choice for multi-processor ad hoc programming.

Fortran knows how to parallelize it self. the language explicitly indicates to the compiler if it can ignore loop order dependencies, and can factor out contisionals and if subroutines will change data values. Memory is stored in predictiable fashions and thus can be shared more effectively.

So if you have a big box and are using C++ you may not be getting all the benefits you could from your investment.

Please explain!

[Anonymous Coward]

say that agian less crytpically. Is there a usable g95 out??? where??? how? please explain at the end-user level. thanks!

Re:Please explain!

[cimetmc]

Like I explained in my initial message, there are 2 competing G95 projects:

http://g95.sourceforge.net/
and
http://gcc-g95 .sourceforge.net/

Both compilers are still in development, and IMHO not suitable for production use. The second project is the one that got the blessing from the GCC developers and is targeted to be included in GCC 3.5. This will hoever still take some time as currently GCC 3.4 hast not even been released yet.
If you want to play with G95, both projects have snapshots available for you to download. Just follow the appropriate links on the web pages.

Marcel

Re:Please explain!

[Anonymous Coward]

Whether it's usable depends on what code you want to use it for. It's still in development, there are holes in what is and is not implemented, and there are still compiler bugs. So it's good to run your Fortran code through it, make sure it can handle it, and double-check results with your regular compiler, but it's not really ready for prime time yet.

Bah! fortan95 does all this as intrinsics!

[Anonymous Coward]

Couldn't you design a language that had features specifically designed to enable this type of in-line compile-time code expansion?

Yes its called fortran 95. Nearly the same stament is available in fortran but its a langauge intenisic and thus will always beat the template.

Re:Bah! fortan95 does all this as intrinsics!

[Spy Hunter]

Another Fortran apologist? I had no idea you guys were so common ;-)

Did you even read the linked article? This statement beats optimized Fortran. Why? It uses a novel algorithm to traverse the 3D arrays that maximizes cache hits. To implement this in Fortran, you'd have to rewrite the compiler. In C++, this is simply a library feature. That's the difference. It's much easier to change a library than a compiler, so development of new features can happen much faster in a language that relies on libraries than in a language that puts major language features in the compiler itself. Faster development means more cool features to play with, and more time to optimize them. So much for your "language intrinsic will always beat a template" argument.

MOD UP PARENT

[Anonymous Coward]

Seems to make its points well and adds to the discussion even if you might disagree....

Still using Fortran?

[Feret]

Man that is sad you mean there are people still programming in fortran? Man and I thought learning ada in college was bad.

oops youre wrong

[goombah99]

Sorry to have to point this out but did you read the article you tell the parent poster to read?

if you did then you would know the article was about optimzed fortran77. Fortan 95 indeed has all the functionality they were trying to re-invent as meta-templates right in the language definition. parallelism is assumed for array assignments, for loops and even for conditional tests. Looping is implicitly done by the complier.

There's no way a meta-template could ever out perform that because the level of hinting is so much higher in the the fortran 95 syntax

Re:oops youre wrong

[Spy Hunter]

My point is that Fortran 95 is going about this the wrong way. They are adding all sorts of special-case optimizations to the core language. This makes the compiler more complex and harder to develop. There isn't even a free compiler for Fortran 95. If a new technique is discovered, for example this "Hilbert space-filling curve" for array traversal, you have to modify the compiler itself in order to implement it. OTOH, in C++ land, you simply change the library, or use a different library suited for a different task. Since the barrier to implementing new things like this is much lower, more experimentation can go on and more novel algorithms can be tried and used, which often gives more of a speedup than just optimizing throughput of old algorithms.

There's no way a meta-template could ever out perform that because the level of hinting is so much higher in the the fortran 95 syntax

I disagree with that statement. Unfortunately, you didn't provide any evidence for me to dispute. Why do you believe that?

Small Science Vs Big Science

[goombah99]

Do you have any idea how much more hardware we could buy with the money that would be burned up by license fees?

oh about 500 to $1000 dollars is what a fortran lic costs. we have one and share it with 40 people. its a compiler lic not a run time lic, not a per seat lic. it is a processor lic and you can share it.

also if g77 did not exist, I think the number of compilers sold would be at least 100 fold larger, making the price presumably 10 or more times smaller. (the cost of support would not allow it to drop 100 fold) I base this on the empirical fact that indeed fortran compiler lic used to be fairly cheap and ubiquitous prior to g77.

also I think part of the disagreement here is just what is meant by scientific computing. THe fact that you mention a graphical interface at all shows you are thinking of personal scientific software or at best larger scale visualization.

Whereas true large scale number crunching happens on remote servers in batch jobs running in long queues. there is no concept of an interactive command line let alone a graphical interface. Thus much of your comments are off base because they are talking about an entirely different arena in scientific computing ins which C++ is indeed adequate and in some ways more useful due to its better interactivity.

Likewise, as for disk writes being not slow, I have to disagree. And its not uncommon in processing time seriees or genetic data to have writes exceeding four gigbytes, which is not something your are going to cache or even copy. this is compounded because diskwrites across network servers can be quite slow. So again you are imagining scientific computing to be something entirely different than I am.

Re:Small Science Vs Big Science

[t]

oh about 500 to $1000 dollars is what a fortran lic costs. we have one and share it with 40 people. its a compiler lic not a run time lic, not a per seat lic. it is a processor lic and you can share it.

In other words, only one person can compile at a time. Just great. And which is it? $500 or $1000? Or are you guessing?

also if g77 did not exist, I think the number of compilers sold would be at least 100 fold larger, making the price presumably 10 or more times smaller. (the cost of support would not allow it to drop 100 fold) I base this on the empirical fact that indeed fortran compiler lic used to be fairly cheap and ubiquitous prior to g77.

The old theory of supply and demand does not apply to software. As supply goes up, price stays high. Just ask Microsoft. In fact without a free alternative the price could go up even higher. At a previous job the Ada compiler for mips was about $30k a seat. Why? Because they had no competitors. Look at the price drops Microsoft has given when threatened with Linux, the free alternative. Do you even know of any software that people need year after year, that drops in price as the number of customers increases?

also I think part of the disagreement here is just what is meant by scientific computing. The fact that you mention a graphical interface at all shows you are thinking of personal scientific software or at best larger scale visualization.

You mean to tell me that with all of the data that you supposedly crunch, that nowhere is there a program to look at the data? Give me a break. Someone somewhere has to look at your data somehow.

Likewise, as for disk writes being not slow, I have to disagree. And its not uncommon in processing time seriees or genetic data to have writes exceeding four gigbytes, which is not something your are going to cache or even copy. this is compounded because diskwrites across network servers can be quite slow.

Do you even know how something like Linux caches disk writes? They aren't cached permanently, just queued to be written to disk asynchronously from the program. Also, how can you possible be talking about speed of execution while simultaneously talking about writing out 4GBs to network servers? Which is it? Are your programs cpu limited or disk limited?

So again you are imagining scientific computing to be something entirely different than I am.

What exactly are you imagining that scientific computing is? The way you manage to exclude everything it's no wonder the fortran marketplace is vanishingly small.

Re:Small Science Vs Big Science

[Anonymous Coward]

This is an old thread, but I'll still reply about the data.
For visualization, I usually use Gnuplot. I dump the data I need to analyze to text files, write a program to do whatever analysis I need, and it writes another text file that can be read by Gnuplot. Sometimes, if I just want an average, I use a script that prints the average of numbers piped to it.

The cluster that I use mostly I think uses a dedicated network for the filesystem and has its own special servers. It's called enfs- I don't know what it stands for.

BTW, I use Fortran 90 when I write my own programs, I spend most of my time with a program written in F77, and am capable of debugging C* programs- but I hate doing it. I've never dealt with a parallelized C program.

Re:Eventually? How about currently?

[Anonymous Coward]

In C we have a wonderful preprocessor built in, you can just use:

#IFDEF NO_ALIAS
#DEFINE int restrict int
#DEFINE float restrict float /* and so on */
#ENDIF

Why not put them together?

[yerricde]

Then why not make a "Fortran-like" code generator and a "C-like" code generator, run them both on a particular C function's parse tree (assuming the code is in C99 and uses __restrict properly), profile the crap out of the resulting code, and accept whatever's faster?

Real Programmers use FORTRAN

[not-my-real-name]

Or at least they don't use Pascal. I'm surprised that no one has mentioned this yet. Just a bunch of yunguns.

Re:Computer "sceintist" != Real Sceintist

[HumanTorch]

> myobject->hash_get(key)
> in fortran you would say:
> hash_get(myObjectStructure, key)

> is there any important difference?

Other than one is monolithic and one is object oriented?

Free Intel F95 Linux Compiler (for non commerical)

[swmccracken]

It's kinda buried - you have to click the "list of evaulation editions" link. But it most certainly exists.

http://www.intel.com/software/products/compilers/f lin/noncom.htm

However, it's listed as non-commercial only - which means (extracting from the license agreement) "If you are using the Materials under the control of a Noncommercial-Use license, you as an individual may use the Materials for only personal, noncommercial and research purposes"

But to a commercial entity, the fees aren't really that steep anyway, and it is a Fortran 95 Compiler, with all kinds of high-performance features that will make you drool. (For example, it can use SIMD/SIMD-II/MMX parellelizing instructions for the loops in your code without any explicit parallelization instructions in the code.)

There's an equilivent version of the Intel C++ compiler too.

G95 Project

[turgid]

I was looking at the state of development of the FORTRAN compiler in gcc today and found this project to implement a more modern GNU FORTRAN compiler. It looks like it's a proper cross-platform complier, using gcc's back end for code generation.

Re:Computer "sceintist" != Real Sceintist

[Anonymous Coward]

err, every looked a perl. if you had you would see there's no difference. just style and data hiding.

Re:Computer "sceintist" != Real Sceintist

[MagikSlinger]

Did you know its not possible to make a typo type syntax error in fortran 77 that will compile?

Did it many, many times in F77.

SLOOOOW. And unparallelizable. and it kills multi-processing dead. and loss of control over memory management. loss of memory mapped sub arrays, strides etc.... Sure you can do strides in c++ but now they are function calls not direct-to-memory.

Real Scientist != Computer Scientist. What C++ compiler are you using? Even VC++ makes those calls in-line and optimized the heck out of them so they become direct memory access. Also, if you needed that kind of control over an array, you can create an encapsulating class with in-line methods to achieve the same effect. I've looked at the assembly GCC generates for this kind of thing. It's indistinguishable from the equivalent C code.

Your argument rests on gross assumptions of how C++ compilers really work.

As for unparallelizable, there is a project to create a C++ for parallel computing.

In fortran you can often pull contionals outside of loops using the WHERE syntax. Its much better to have a good syntax in the language than make up for it with a bunch of function calls and object instantiation. e.g. both languages can write

Relying on changing the language syntax instead of using libraries is called the PL/1 trap in computing science cicles.

A = B*C where A,B and C are matricies but C has to do it with objects and overloads. fortran does not. which do you think is going to be faster.

It doesn't matter what I think. I check what the compiler actually generates, and the matrix library I wrote in C++ made tight use of memory and in-line calls. Matrix addition was done in situ and looked exactly like the code generated for the equivalent in-line C code. Unfortunately, my workplace only has F77 compilers (commercial ones), so I can't check the matrix operations in F95 and higher, but I'll take your word for it that it is effecient and doesn't use a function call.

So fortran steals a good thing from C and you complain?

I wasn't complaining that FORTRAN stole it, I was responding to the original post that made the implicit slam that C did not do that.

whoopee. I can say it in reverse: take the STL and put a fortran wrapper on it. now fortran has the STL

No, you can't. The STL is templated and largely in-lined code. As well, the STL derives its strength from creating ad-hoc code for the specific data type. You can write a wrapper for that for FORTRAN.

myobject->hash_get(key) in fortran you would say:
hash_get(myObjectStructure, key)
is there any important difference?

Polymorphism.

You still dont get it. Its the underlying model that makes fortran efficient.

I do get it, you don't. I'm saying modern compilers have caught up. From the tone of your post, it sounds like you have access to a souped-up F95 compiler with extensions out the wazzoo, but only access to a cruddy first-generation C++ compiler that probably still uses cfront. Get a real C++ compiler and check the generated assembly.

its the reduced noumber of syntax errors from a less sloppy language deifintion that make it clean and readable and easy to debug. But if you must have examples of speciic cmmands then...consider the FORALL which is a for-loop that goes over its range in any order thus allowing implict multithreading. Consider the WHERE clause which allows conditonals to be factored out of tight loops. Consider that it uses references not pointer arithmatic (like java).

All stuff introduced in F95. Most code and people are still at the F90 level.

The fortran will stil have advantages in syntax, clean looking code and quickly debuggable source.

Care to post an example?

Re:77 = 1977 right??

[Manhigh]

But there is also fortran 90, 95, and the new 2000 spec.

OpenWatcom

[myg]

What about the Fortran portion of the OpenWatcom compiler suite?

It came from commercial roots so it is likely to be a better compiler in many ways compared to g77. They are actively porting it to Linux and Watcom was always known as generating terrific code. For x86 scientific computing it may be just the thing!

How about using Fortran 95?

[Bananenrepublik]

The article uses FORTRAN 77, not the modern Fortran 95 which has a concise loop syntax, which allows the compiler to generate the best code with no reliance on the compiler understanding correctly what the templates are meant to achieve.

Equivalent Fortran 95 code:
INTEGER, PARAMETER :: N = 64
INTEGER, PARAMETER :: DBL = SELECTED_REAL_KIND(15,364)
REAL(DBL) :: A(N,N,N), B(N,N,N)

A(2:N-1,2:N-1,2:N-1) = (B(2:N-1,2:N-1,2:N-1) + B(3:N,2:N-1,2:N-1) + B(2:N-1,2:N-1,2:N-1) + B(2:N-1,1:N-2,2:N-1) + B(2:N-1,3:N,2:N-1) + B(2:N-1,2:N-1,1:N-2) + B(2:N-1,2:N-1,3:N)) / 7.0

(by default array dimensions have lower bound 1 in Fortran, instead of setting the lower bound to 0, as in the C++ example, I chose to adapt the code to the Fortran convention; instead of choosing the real data type on the requested precision I could have used DOUBLE PRECISION, of course; I used uppercase out of tradition, against popular belief, Fortran understands lowercase)

For expressions like this it would be nice if one could deal with index ranges as in the C++ code, but this can also be achieved by means of a preprocessor.

Re:How about using Fortran 95?

[Bananenrepublik]

Alas, I didn't think of the FORALL statement. I need some sleep. A more concise and readable version with the typo corrected follows.

INTEGER, PARAMETER :: N = 64
INTEGER, PARAMETER :: DBL = SELECTED_REAL_KIND(15,364)
REAL(DBL) :: A(N,N,N), B(N,N,N)

FORALL(I=2,N-1, J=2,N-1, K=2,N-1)
A(I,J,K) = (B(I,J,K) + B(I+1,J,K) + B(I-1,J,K) + B(I,J+1,K) + B(I,J,K-1) + B(I,J,K-1) + B(I,J,K+1))/7.

But so what? I'm following up on an old story anyway...

Re:How about using Fortran 95?

[Anonymous Coward]

That's ok.. I enjoyed your post.

Re:Computer "sceintist" != Real Sceintist

[Fyndo]

double snort. Did you know its not possible to make a typo type syntax error in fortran 77 that will compile? hard to believe I know but its true. ( You cant misplace a plus sign or comma or leave off a [] and have it compile.

Maybe if you're using implicit none. And no functions, the lack of function declarations in f77 mean in multi-file programs, that you can leave off arguments, not quite a typo, but..)

Re:Computer "sceintist" != Real Sceintist

[Anonymous Coward]

This is in fact, not true. Superficially Perl may look like its just hiding streight function calls in method calls, but in fact its not. Ie:
$object->method_call;
Is not the same as:
method_all($object);
Because the first figures out what subroutine to call at runtime (based on the class of the $object variable) and the second figures out what subroutine to call at compile time.

Re:77 = 1977 right??

[Anonymous Coward]

C is only marginally more powerful than Fortran, and only in areas that really matter for system-specific stuff (namely, pointers, which are much more circumscribed in Fortran).

For the kinds of stuff I do as a higher-level developer, Fortran would be at least as suitable as C.

(As it is, I use C++ because the advantages in expressiveness outweight Fortran's advantages in execution, but that has more to do with templates than anything else.)

Re:Computer "sceintist" != Real Sceintist

[HumanTorch]

Yes, and I could simulate simple classes in C with structs and passing a this pointer to all the attached functions... but I would rather abstract that further by using actual C++.