Slashdot Mirror
Is FORTRAN Still Kicking?
Algorithm wrangler queries: "I'm beginning to wonder if I should invest the time in learning FORTRAN. Although it is, arcane it seems to be the best tool when it comes to demanding optimization tasks and heavy computations. C/C++ does not cut it for me - it is simply too easy to make mistakes and I find myself using half of my time hunting bugs unrelated to the problem at hand. Additionally, although tools like Matlab exist they don't provide the power that justify the huge price tag they carry. I find any script based language (Matlab, Numeric Python, Scilab) to be inadequate as soon as it is necessary to use loops to describe a problem and using such tools for recursive systems can be a real pain. As another data-point, the Netlib repository seems to be very FORTRAN oriented, and it is a true gold mine when it comes to free routines for solving almost any computing task. What bothers me though is that FORTRAN code is really ugly and the language lacks almost any modern day language feature (I know about Fortran 90 but it is not much nicer than F77, and no one seems to use it). Can it really be true that the best tool we have for heavy duty computing is a 25 year old language, or have you found anything better - free or non-free?"
FORTRAN is used in high performance scientific computing. The language allows for high parrelelization.
Fortran 90 has plenty of structured programming features to make maintainable code. Equally, if not more important, is that Fortran code can be much better optimized than C/C++ code for numerics. IBM did a good job on Fortran, and it's still a major player today.
Care about electronic freedom? Consider donating to the EFF!
IT IS NOT
Learn C/C++ better. Stupid mistakes are not an inherent property of C.
Yes, FORTRAN is still alive, and many important scientific applications are still written in it and maintained in it.
Alas, for the rest of the question, I'm not a mathematician/number cruncher. The only floating point numbers I deal with are currency...
I'm a Java convert now thought.
As a recent CS grad I had to help some of my friends in the Meteorology department with their programming course(of course not taught by a CS prof). To my surprise it was FOTRAN. It seems a lot of the stuff NOAA and other government agenicies program is in FORTRAN so it is compatible with the stuff they stil use from the 70's and 80's.
"Success is not the result of spontaneous combustion. You must first set yourself on fire." -- Fred Shero
I'm not a true lisp hacker but from lurking on comp.lang.lisp I believe that the lisp guys belive that a good Common Lisp implementation can get pretty kickin' numeric performance. Of course you have to put in various declarations to allow the compiler to generate efficient code. But if you do that, it's supposed to be pretty good. And the advantage is you can build up your program without the declarations, get it working and then optimize by adding them in. Or that's the theory. Also these things vary from implementation to implementation--some are more tuned toward numeric style computation than others.
my dad is a physicist. he, and every colleague of his who writes code, writes it in Fortran.
part of it is that there's 40 years of perfectly good legacy code to keep using. but mostly it's that C's numerical libraries still, after all this time, aren't as fast as a good Fortran's.
Cretin - a powerful and flexible CD reencoder
I'm beginning to wonder if I should invest the time in learning FORTRAN.... [I]t seems to be the best tool when it comes to demanding optimization tasks and heavy computations.
If you don't know the language, how can you state that? Hmm.. I wonder if I should invest the time in learning Pascal? It seems to be the best tool when it comes to parsing text files.
It depends on what you mean exactly by the "best tool". If you're looking for something easier, then I can't help you. If you're looking for something FASTER, then just use Assembly Language.
There is no mod option "-1: Disagree" for a reason. "Overrated" is not an acceptable substitute. Post something instead.
Active work is underway to provide a front-end
for the GCC-system for Fortran 95.
See: http://g95.sourceforge.net/
Toon Moene (current g77 maintainer).
You can become a passable FORTRAN programmer in a couple of hours if you already know another language, such as C or Pascal. There are a couple of gotchas (predeclared variables & COMMON statements IMHO).
If you are going to touch any heavy simulation code (such as statistics, physics & biology) learn FORTRAN. It works very well for those problems. Yes, it is old, but that doesn't mean it's bad. It's not modern, but it works surprisingly well.
I find myself teaching FORTRAN to budding scientists, and they are able to write complex stuff very quickly because they don't trip all over the language (e.g. '==' vs '=' in C).
Home of the VAX and land of Basic, FORTRAN, and COBOL!
Wu-Tang Name: Half-Cut Skeleton Get your own Wu-Na
Fortran has several things going for it...
1) it's been the standard scientific computing language for so long, that every platform has a compiler, and that compiler is likely to be very mature (i.e. stable, and produces fast code).
2) since it's been a standard for so long, everyone has routines written in it which have been debugged and work, no sense rewriting them and introducing errors.
3) the language itself lacks complicated constructs, so it is very simple to optimize. This, with (1) makes fortran still outperform c, thanks to the compilers.
That said, I HATE fortran with a passion, mostly because it's ugly. 6 character variable names are impossible to deal with. Couple this with capitalization and indentation rules left over from the punch card era and you have code which is literally painful to read.
Doug
Venn ist das nurnstuck git und Slotermeyer? Ya! Beigerhund das oder die Flipperwaldt gersput!
if you want to multiply two numbers a million time, for everything else C still rules.
Je t'aime Stéphanie
I know of a lot of research and development facilities that still use fortran for mathematical modelling, and mathematical programming. Especially mathematical modelling of physical phenomena (ie. nuclear power plants, etc.)
:-)
I didn't find it that hard of a language and I believe it would be worth learning for someone who needs to mathematics on a computer simply and easily without having all of the dongles and doo-dads.
~ kjrose
When it's already dead? Use C++. C++ can do everything fortran can do and more. If you are tracking bugs in C++, learn C++ better.
Yes: Fortran is still alive (the FORTRAN spelling has been depricated). There is a shitload of stuff for Fortran 77. Fortran 95 kicks some ass, and has a lot of features seen in modern languages.
Shit, what a stupid question.
The middle mind speaks!
to your C code. You just have to know how FORTRAN arrays are held in memory and how long the FORTRAN types are. Then you need to know what standard FORTRAN libs you need to link, so that your numerical libs will work. I did that for lots of my numerical work and it worked fine. You have to test it of course and it takes a while to work out the kinks.
***Quis custodiet ipsos custodes***
you would hear shit like that on comp.lang.lisp. try actually writing the "efficient code" and benchmark it against Digital Fortran (or whatever the hell it's called these days), and find out why everyone but comp.lang.lisp posters have given up on it.
What are these modern language features you are looking for?
FORTRAN is almost perfect for what it is used for: massive number crunching. Very little bells and whistles, which allows the programmer to concentrate on the numerics of the problem at hand and not the picky little programming details.
Life is like a web application. Sometime you need cookies just to get by.
I thought FORTRAN was more like 50 years old?
First, an admission...I have used only a little FORTRAN in college, and that only to satisfy the requirements of a freshman level course. That said, although I find it hard to believe that other languages or libraries or toolsets are not up to snuff when it comes to the kind of number crunching you are doing. In any case, if it does seem that your application has serious number crunching needs, but you still feel compelled to use C,C++,Delphi,Perl,whatever, then perhaps you ought to wrap your number crunching code in a library, but written in FORTRAN. Then do your "other" code (infrastructure, UI, control) in the language of your choice, calling out to the FORTRAN code whenever necessary. If your application is as computationally intensive as you seem to imply, the additional runtime cost of a library load and callout should easily be offset by the savings in computation time due to the "better" language.
Another way to look at this is that most languages are created because a problem domain exists which the language creator thought would be better served by this new language. FORTRAN has long been considered the best language/implementation for computationally intensive applications. Use the right tool for the job.
G'luck.
The problems you described in C/C++ are probably mostly inherant to C. C is not type strict, so it lets you shoot yourself in the foot (or head) a lot.
What it sounds like you want is a strongly typed and type safe language. That would catch most of your problems, assuming your're just writing algorithms and not trying to interface to strange API or hardware.
PASCAL/MODULA-2/-3, or ADA can probably do what you want, and have GCC frontends available. These languages usually have runtime checks for safety, but after debugging, you can usually optomize them out for a production release.
So over all, go compiled, go type safe, go modern/OO if you can.
There is nothing so silly as other peoples traditions, and nothing so sacred as our own.
hey I get to post my favorite fortran joke
about variable naming.
"God is real; unless declared integer"
my other favorite math joke is
"what's purple and commutes?"
Different languages have different strengths and weaknesses. I use Fortran, C, Ada95, and Ocaml interchangeably for different tasks. Often times linking the object files into a single executable.
Fortran, designed for mathematics and engineering, obviously excels at that job. You might want to consider writing the "intensive" parts of your application in Fortran and then linking it with modules written in another language such as C or Ada.
I've found that C is perfect for handling the I/O routines for such apps, but my Ada libs are ideal for doing memory managment and when the code outgrows the practical limitations imposed by Fortran.(Note: Interfaces.C and Interfaces.Fortran).
Likewise Ocaml tends to fit around anything with a minimum of hassle.
Of course, this is just a subjective evaluation derived from my own experiences. However I would encourage you to experiment to find the combination that works best for you. As we all should know "Theres more than one way to do it."
I'm sorry if this post seems somewhat vague, but it would be rather hypocritical of me to outright prescribe a certain language or tool when I personally have a tendency to float around and use whatever tool is most convenient.
NiCad
Fortran was one of the first programming languages I taught myself in preparation for an engineering contest in High School.
The book that I used to learn this great language is "Fortran 77 Programming w/ An Introduction to the Fortran 90 Standard" by Ellis, Published by Addison Wesley.
I have the second edition of this book and not only is it a great programming book but a great Math book as well teaching such concepts as Data Fitting by least Squares approximation and the Newton-Raphson method for solving non-linear equations. (Using the first derivitive of an equation to approximate a root.)
This book put me well ahead of the people in my calculus classes.
G77 works great, but what about ifc (Intel Fortran Compiler)? Anybody tried using it? I tried using ifc (free Linux version) to compile some of my Fortran 77 code, but the program crashes on writing to and from internal files. Is ifc only compatible with Fortran 95? Is G77 compatible with Fortran 95? Anybody know other good free compilers?
It will export your script as C.
-... ---
I know people who only write FORTRAN code. They need the speed which the heavily optimised compilers provide (they use it for simulation of stellar evolution and planetary evolution)
Its still taught to many Physics students at Cambridge University due to the speed and wide availability of scientific libraries.
It's in the Museum of American History. I saw McCracken's _FORTRAN IV Programming_ or whatever it is, in the IT section in the basement. I learned Fortran with that book! Dang, it's old, and so am I!
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
The DOC institute I am working at uses F90 to develop FMS (Flexible Modeling System) for the purpose of climate research. The NCAR/NOAA uses F90 in their latest CAM2 (Community Atmospheric Model v2). So it seems pretty safe for me to say that F77/F90 is still very active and is a proven tool in the academic environment.
Together, we are strong; Apart, we are stronger.
I still turn to FORTRAN when I have a linear programming problem. There aren't too many simplex solvers out there and most of the good ones I know of are in FORTRAN libraries. In some ways more modern languages just don't go the extra mile on the obscure math and as we all know math doesn't go out of style.
There are still lots, and lots of libraries for
numerical analasys written in Fortran.
So if you intend to use it for somthing like that
it's a good idea to learn it.
God is REAL! Unless explicitly declared INTEGER
If the only thing you hate in Matlab is the price, give octave a try!
delete free(system.gc);
Fortran is used HEAVILY in very specialized industries -- almost any mechanical design or scientific modelling program has some Fortran code in it.
What do you want to do with it? Model fluid dynamics? Do structural or materials analysis? (Such software already exists.) Or do you simply want to find a better way to encode your DivX files?
It appears to me as though you are trying to select the proper tool for driving nails into wood, while looking in the screwdriver section of the hardware store. If you need to ask why you should learn Fortran, you probably shouldn't learn it.
- A.P.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
COBOL rulez!
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
I've had to do some fortran, and I cant see ANY benefit from using it over something like mathematica or maple for modeling or computation. The price tag isnt that high, and if you're a student, you can usually swing a free copy of one or the other if you look hard. Using fortran, you're going to spend five times as long and get something that might run differently on your development platform than your processing platform. Perhaps you need to specify your task better. "demanding optimization tasks and heavy computations" is vague.
People who think they know everything really piss off those of us that actually do.
Learning a new language isn't going to help you avoid debugging. C can do anything Fortran can do (but not vice-versa!) Fortran is a simple language to learn, but so is C. Mastery of either is difficult. Because is it so popular, the support base for C is much larger than for Fortran, so I would suggest sticking with it.
You don't say what kind of programs you want to write. For general-purpose programs you're worse of in Fortran than C/C++.
Your mention matlab and the netlib, which suggests you're doing numerical stuff. For that kind of program Fortran is indeed still very much alive, mainly because of the efficient compilers, the good support for array manipulation, and the enormeous amounts of legacy code.
You also mention recursion. If you're working on tree-like data structures Fortran is not so great. In that case a functional language such as ML or Haskell can be a very good choice. As a bonus, functional languages are often very comfortable to program in, since a lot of irrelevant detail is silently handled by the language.
A friend of mine is very much into computer simulations of physics and chemistry - he writes his own code in c / c++, and so manages to do on a (heavily optimized) Linux PC what his colleagues using FORTRAN still need Crays to run. All the difference is that he can use custom datastructures that FORTRAN (and the existing libraries) does not offer him.
If you need to do numerical linear algebra (vectors and matrix), nothing beats Matlab. But as you said, Matlab costs a bunch of money. Maybe you'd be interested in Octave, an open-source, Matlab-like and mostly Matlab-compatible scripting language / interpreter.
My dad is a computational physicist. He works with some codes that are k*100,000 lines of FORTRAN. Mostly f77 too.
Once upon a time, Cray had a really good automatically vectorizing compiler for FORTRAN and a mediocre C compiler. The Killer App stuck.
The word on the street (from my dad) is that new physics codes are being written in C/C++. So, maybe in 20 years most of the old FORTRAN will be replaced.
I've tried to get my dad to learn more C/C++, but he plans to retire before that's necessary.
Start Running Better Polls
Only learn it to convert it...
I've begun writing a perl converter it convert my company's routines that doesn't mangle the C code like the fortran2c program. Fortran 90 is a bit better than Fortran 77 but only because of the C work around features in the compiler. I also have to disagree about the performance of Fortran compared to C in math heavy routines. I've been having better performance on my math routines after they've been converted to C.
Reasons why not to use FORTRAN:
Lack of structures, classes, and a lot of OOP that C/C++ have. Even though Fortran 90 has memory allocation and dynamics, think about how Fortran 77 and g77 don't!
Not convinced that it isn't for you!? Then try the fact that Fortran passes ALL variables by reference only! Excellent isn't it?
Still not convinced not to use it for big projects yet? Try that since everything is pass by reference it has no pointers.
Try making linked lists/trees and stuff out of it easily!
The only thing it has going for it is the fact that you can pass variable length arrays into a function like so:
func(array,m,n)
double precision array
integer m,n
-------
Don't let that fool you into thinking it's robust! You can do that in C although a bit of ugly pointer arithmetic is involved.
Continuing... If you accidently mistype a variable the compiler will go ahead and create that variable implicitly based on its first letter to determine its primative data type instead of reporting an error!
Seriously, C can do all the stuff it can do and then some.
I've been using MS Visual Fortran for several weeks now, and it's able to make all the same GUI components I'm used to using in other languages. And, with the Calculator OCX, I'm even able to do math!
Honestly, your objection to C++ is unclear to me...you say you spend more time fixing bugs than approaching the task at hand? Is this because you don't know the language that well? Perhaps because you're not taking advantage of the many excellent libraries available to you? Keep in mind that C++ library design requires a great deal of skill, but using a well-designed library is actually easier than coding in other languages.
C++ is my own personal choice for anything by the most demanding of high-performance computing applications. Is there an overhead to the language? Debatably, yes. Does it matter, in 99.9% of applications? No. And with only a little bit of forethought, even the "inherent" performance hits can be avoided in the places where it matters. It's just that you have to rely on a profiler to tell you where those places are...
There is a significant community of researchers and developers working on scientific and high-performance computing in C++. Check out some of these:
These are just a few good starting points. Do a google search for 'high performance c++' to find many more. Just, please, for the love of Deity, don't code in FORTRAN. ick....
Let's try not to let fact interfere with our speculation here, OK?
Can you read your iPAQ when the battery is dead? I can't. And as good as my iPAQ is for some things, that screen is just too damned small for reading.
I much prefer books. You can annotate the hell out of them. Books don't crash. Books don't have issues with "alternate" operating systems. Books aren't subject to the whims of some funky piece of software that might just decide to stop working.
And most importantly, when was the last time you replaced the missing leg on that old couch with an iPAQ?
-- "It's just this little chromium switch here..."
It always kills me when these kids with snot still dripping from their noses enter the world of programming, and winder when they are going to get to program with the latest and greatest tools that they were promised in schools.
You are entry level programmers. You will do entry level work until you are no longer the low man on the totem.
More specifically, unless you are doing something that depends on the latest tools, like web development, then you will need to learn the legacy of where ever it is that you are employed. That is the real world.
Anyone that tells you different, or tries to sell you a different job went belly up in the dot com bubble burst.
FORTRAN has the same kind of cherubic appeal as a very very large hirsute man wearing a tutu.
You can leave FORTRAN behind, but you can never forget it. Sometimes, I wake up at night, thinking about it -- wishing I didn't.
"I have opinions of my own, strong opinions, but I don't always agree with them." -- George H. W. Bush
I'm doing some consulting this summer for a company in my home town, and they have a VERY odd fortran implementation.
It grew out of an old fortran (formatted type - probably f60 or so) program that was written by some guys in germany for calculating the size and price of heat exchangers. This company I work for has since decided it needed to have a web front end for this program and had a couple of engineers (this is the first problem - NEVER have plain vanilla engineers write code!) come up with a 'solution'.
What they have now is a mess of ASP pages using VB dll's to call a Fortran 60/77/90 and C++ conglomerate program that ultimately writes ASP (yes! directly out of the fortran). All of this interfaces with multiple databases stored on both an AS400 and a Dell/Windows machine.
IT IS A HUGE FREAKING MESS!! I was brought in to clean it up - and redo all the pricing. I have done what I can - but short of a total rewrite it is not going to get much better.
Fortran needs to die a horrible death. It is soooooooooo ugly to look at and decipher (all of this code didn't even have branching statements in it - it just had a TON of GOTO's !!!).
Just thought I would share my experience......
Derek
I'm an undergraduate in Physics at the University of Michigan. Both my parents are physicists and I work for one. What do my parent's use when they need something programmed? Fortran! What does my boss use? Fortran! What does my boss tell *me* to use? Fortran! Fortran is still a very useful (and relatively simple) language that's used very heavily in Physics. Lots of software coming out of CERN is programmed in Fortran. The primarily used Monte Carlo simulation code ( That's particle physics simulations ) GEANT is coded entirely in Fortran. As is another very commonly used in High Energy Physics software package called Paw (Physics Analysis Workstation). Most of the public and very often used software in physics that I've had the experience of working with is most definitely still in Fortran. I can't say the same for most proprietary software. But otherwise, Fortran is everywhere! Michael Borysow, University of Michigan
...of the simple loop structures. In C, you can have a for( ; ; ) statement that does basically all sorts of weird crap in here ( ; ; ), and you can also do things like pointer aliasing (impossible in Fortran since there are no pointers at all).
Fortran loops, on the other hand, are very very simple - all you can do is increment the loop variable, and repeat. That allows for very heavy loop optimization by the compiler - comparable to what the best assembly programmers might be able to do. Furthermore, a Fortran compiler can more easily generate optimized loop code using vector instruction sets like Altivec or SSE2, whereas C compilers have a much harder time (again, because of the wide variety of loop structures possible in C, and things like pointer aliasing, etc.)
All is Number -Pythagoras.
Although I haven't used them personaly, MATLAB has linkable C libraries available for a lot of their highly optimized functions. Of course you have to purchase them, but you get away from having to use their script language which does indeed suck on recursive work. I started working on genetic algorithms in Matlab, but switched to C because the interepretative nature of MATLAB made things crawl. I just wrote my own library of functions that I used for the GA work instead of porting my MATLAB code to C and linked against their libraries.
It's obvious that the story's poster didn't really look into FORTRAN much past the aging F77.
I currently use F77 to do research in magneto-hydrodynamics simulations of neutron stars on Cornell's Velocity Cluster (which has been featured on slashdot before). Fortran, due to its lack of things like pointers, etc, is rediculously efficient, and almost completely cross platform (because surprise surprise- it's very difficult to attempt to do anything remotely platform specific). The language is much simpler than something like C with pointers, etc, that must be messed with. Sure it's ugly as hell, but once again the newer versions of Fortran take care of most of these issues.
I would suggest that anyone interested in high performance computing should check out High Performance Fortran. It's a set of extensions to the F90 language to allow the seemless integration of large-scale parallelization in your code. It also has several other performance advancements.
I highly disagree with the poster of the story, Fortran 90 is much more modern than F77, including things like objects, safe pointers, better recursion, better array sharing, generic routines (a type of function overloading). The language syntax is also much more lenient than F77 (which was designed to work with punchcards). It also has some really great array operations (things like slices, etc) that are rediculously fast. While I absolutely hate F77, if I was going to write a computationally intensive simulation, I'd probably do so in F90 or HPF.
A lot of people still use Fortran, especially computational physicists and meteorologists... Many of these people don't have time to learn new programming languages, and Fortran works very well for what they need, better in most situations than almost any other language. It's something to consider.
Cheers
Justin
I work as a controls engineer at the NASA Ames Research Center. Most of the nonlinear aircraft simulations are still written in FORTRAN. FORTRAN provides very robust mathematical libraries while making it very easy to parse text files. In other words, FORTRAN is ver good at taking a text document of flight data, and crunching it into a useful simulation. The main thing is that so many compilers and languages talk to FORTRAN. I do a lot of work in Matlab and C, and both can link to my FORTRAN code. I can pull up an old simulator from the early 90s, slap on an s-function or C-wrapper, and use the code in my new code. Of course, the question is: is new FORTRAN code being generated for reasons OTHER than to be compatible with the old code, or because it is the only language the crusty engineer knows? Well, it's a toss-up. Matlab seems to be making a lot of headway, especially since it's code is very C-like and can link to old code. But, the gnu g77 compiler means I can distribute my FORTRAN work to anybody with a Unix box. Not everyone has put out the cash for Matlab. My recommendation is to learn enough FORTRAN to understand the math and logic loop functions. This will be enough to be able to read old code, and to be able to write math subroutines to be linked to more modern code. I still have to write in FORTRAN, but it's uncommon that I ever write a stand-alone FORTRAN program with an interface or anything. It is mostly text-file and math subroutines for Matlab or C.
Can it really be true that the best tool we have for heavy duty computing is a 25 year old language
Can it really be true that the best tool we have for driving nails is a 3000 year old piece of wood with metal on the end?
The course mainly focusses on solving machine numbers, solving linear systems (direct and iterative methods), solving non-linear systems (mostly Newton-type methods), and solving eigenvalue/vector problems. The codes that students wrote last year started from scratch with early assignments. Then, I allowed them to incorporate Basic Linear Algebra Subprograms (BLAS) into their codes. Then they were allowed to use LAPACK for the rest of the semester. They were free to use the C interface, but most chose to use the FORTRAN examples, probably because of the skeleton code that I provided.
Given the tremendous amount of code that is already out there, I agree that knowing FORTRAN is an asset. And since it's not hard to learn, why the heck not, right?
On a side note, they had to use Makefiles, LaTeX their assignments, and send everything to me electronically in a gzipped tarball. They got quite a workout in console tools. For reference, I had some that were quite familiar with the system and some that had had BASIC at some level and that's it. Lots of help was needed as the semester reached the final weeks.
Matlab was used for visualization and graph creation, but I am considering using GNUPlot this year, if it is up to the task. (I think it probably is.) I may also encourage the use of Octave, where possible.
For reference, the class website (which will soon be updated for the new semester) is here: Math 224.
Curmudgeon Gamer: Not happy
The language feels as though it's designed by a committee and has features tacked on left, right and centre. IO sucks arse, so don't expect to write a wonderful user interface for it (but you could always do a wrapper in another language, I suppose).
I use F90 at uni, and although it's a bit of a messy language it does what it's good at: spewing out tables of numbers. It is expensive for a single licence, however. I wouldn't bother with it if I didn't have access to the university number crunchers.
No.
(Hint: +5 Funny)
All we have is this "25 year old" language for numeric tasks, and another language that's about as old for system programming. It's called C.
--Matthew
Fortran is truly ugly, if you need to write fortran, at least do it an ratfor (Rational Fortran) described by Kernigan and Plauger in Structured Programming.
Ratfor adds "normal" structured programming constructs to fortran to make it readable by somebody less than 40 years old.
You write code that looks like:
for(i=1;i=100;i=i+1) {
fortran code here
}
Ratfor generates:
23002 if(.not.(i.le.100))goto 23004
fortran code here
goto 23002
23004 continue
I dont know about Linux, but ratfor is included in the FreeBSD ports.
S.E.S.S.D.E.N.E.E.NW from west end of hall of mists
Blitz++ makes use of C++ templates to deliver near FORTRAN like speeds (and in some cases better).
Don't be afraid of C++ templates - all this Blitz code stays clear of C++'s pointers, and are very easy to use.
The easiest way to tell a Real Programmer from the crowd is by the programming language he (or she) uses. Real Programmers use FORTRAN. Quiche Eaters use PASCAL. Nicklaus Wirth, the designer of PASCAL, gave a talk once at which he was asked "How do you pronounce your name?". He replied, "You can either call me by name, pronouncing it 'Veert', or call me by value, 'Worth'." One can tell immediately from this comment that Nicklaus Wirth is a Quiche Eater. The only parameter passing mechanism endorsed by Real Programmers is call-by-value-return, as implemented in the IBM\370 FORTRAN-G and H compilers. Real programmers don't need all these abstract concepts to get their jobs done -- they are perfectly happy with a keypunch, a FORTRAN IV compiler, and a beer.
- Real Programmers do List Processing in FORTRAN.
- Real Programmers do String Manipulation in FORTRAN.
- Real Programmers do Accounting (if they do it at all) in FORTRAN.
- Real Programmers do Artificial Intelligence programs in FORTRAN.
If you can't do it in FORTRAN, do it in assembly language. If you can't do it in assembly language, it isn't worth doing.And my personal favorite:
A Real Programmer might or might not know his wife's name. He does, however, know the entire ASCII (or EBCDIC) code table.
The whole story can be found here.
Take the time to become a "Real Programmer." You'll be glad you did.
I am currently using FORTRAN 90 to write Maxwell's Equations simulation code.
At first I was a bit leery of programming in FORTRAN, but after a couple of months on the project I wouldn't start anything similar in another language. The array and mathematical manipulation capability of FORTRAN is just much better. FORTRAN 90 offers more readability than C, anyway.
So yes, definately learn FORTRAN. For an experienced coder it should be the work of an afternoon to get the basics. The only problem is the output--it might take another whole afternoon to learn format statements.
sgi? gis? gsi? sig.
i made this site using matlab about 4 years ago.
matlab is VERY powerful, ESPECIALLY in for loops and recursive problems. any walls you are finding while writing MatLab scripts, well, you aren't trying very hard. i would even write MatLab scripts that would write Perl Scripts that would write MatLab scripts!
MARIJUANA, SHROOMS, X: ONLINE?! - E
Try your stuff in Squeak (http://www.squeak.org) and then see if you come back :)
If it does the job.
'nuff said.
I'd rather be sailing...
With enough production code, you can essentially push a language's lifespan out to infinity.
SciPy is an open source python application that sits on top of quite a few C and Fortran libraries. It is specifically targetted at the scientific computing community, and its performance is quite good, even though it's still a very young product. It supports massively parallel computation, has a number of nice plotting and graphing features, and is completely cross platform. It also includes weave, which allows you to produce native C code from python.
Best of all, it's python, which means the learning curve isn't as punishing as C++, for instance.
The website for SciPy is:
http://www.scipy.org/
FORTRAN is still a useful language for engineering and scientific computing for several reasons.
A very good one is that FORTRAN isolates the platform much better than C does. a real is a real is a real. At most, it's a matter of finding the appropriate compiler option.
A great many people in the field know FORTRAN.
Lack of issues such as pointer aliasing, etc, make automatic optomization and to an extent parallelization go much better in FORTRAN.
C's history is one of letting the programmer optomize the code, FORTRAN has a stronger history of considering that the compiler's job (good for numerical programming).
There's a lot of good, well used and tested code out there for FORTRAN.
If your interests lie programming for scientific or engineering, especially HPC, FORTRAN is still a must.
Having said that, when you're writing a large piece of code, much of the code probably isn't number crunching; its schlepping data back and forth between solvers, doing I/O, etc. For that, FORTRAN is fairly limited; so you use other languages.
You use the right tool for the part of the code you're writing. We are working on a large simulation code; our numerical solvers are all in FORTRAN, and we have no intention of chaning that; however, we use other things (C, Python) for higher-level tasks. And this is how it should be. People who argue about `Language X rocks!' or `Language Y sucks!' Just Dont Get It. All the languages still in use are still in use for a reason -- they have certain things they're good at. And so you pick the right tool for the job.
FORTRAN is still incredibly useful for high-performance code because, icky as the language is, it has a number of features that make it much easier to optimize than C, C++, or Java. FORTRAN doesn't have arbitrary pointers. When you pass pieces of the same array to a function the language definition says that the compiler can assume they don't overlap, which makes reordering array accesses much easier. These two are the key to effective optimization. Take a look in any compiler book; optimizing FORTRAN is fairly easy, optimizing languages with pointers is much harder.
Finally, FORTRAN simply doesn't have a lot of abstractions that produce slow code, like dynamic dispatch. When you're doing high-performance computing, the constants in the running time of your program matter, and it's much easier to make the constants small for FORTRAN.
If you find Matlab price prohibiting, what about trying R ? www.r-project.org ! :)
Alex
FORTRAN is used in high performance scientific computing because people in charge are too old to switch to something else.
I've had the same problem and have tried several solutions to it.
One fortran 90 is actually almost OK to work in. The problem is that many programmers create fortran 90 code that is really fortran 77 code with some new features being used. Unfortunately it still looks like f77 code. f90 (and even better f95) can be fine to program in as it takes care of many of the major flaws in f77. Plus it has many vector functions and is the fastest code out there (that I have come across). However f90 is not free for linux (that I know of) although it does come with most sun & alpha machines.
Personally I love matlab. You can even call it from C (although I haven't benchmarked that). I disagree that it is flawed for serious programming although it does appear that you can't optimize the code as easily. Anyway I love matlab and the ease of which it graphs goes along way to saving you a lot of time when examining your output.
I dislike idl immensely and agree that c, even with libraries, doesn't really cut it for serious number crunching.
Another free possibility is PDL. I quite like it although performance is an issue. Its very fast to develop in although it is always a work in development when it comes to its feature set.
Hope this helps
Scheme is a solid language taht is very fast. It has excelent math precesion and isn't very difficult to learn. Looping structures are available as the language is ideal for recursive solutions. Check here for more info. If i remeberfree versions are avaialble for you to try them. The precesion is excelent.
Although many peopl will go Scheme what, sometimes the best solutions are more obscure.
When I switched out of engineering and into computer science, I found that C's (and C++'s) printf/scanf supported the same rich lexical scanning constructs but did it in a different manner.
Some reasons to use FORTRAN: legacy maintenance, well, that's all I can think of; if you want to link to numeric libraries written in FORTRAN but compiled, you can do that from C.
Some reasons to use C: faster, available on all platforms, and very readable. The line numbers in FORTRAN and indiscriminate GOTO's makes it hard to trace program flow. C encourages gotoless coding practices and, IMHO, is easier to read.
If debugging is a problem for you, I'd wager you have a lot of memory problems - undefined references, bus errors, and such. Use Java if you can, it combines readability with automatic memory management. Not sure how rich the libraries are for numeric, but you can use JNI to link to some FORTRAN ones if you absolutely have to.
Back when I used to work in a University Maths department we used Fortran almost exclusively. Because its quicker and easier to code up most math problems in Fortran rather than C and because of the extensive numerical libraries available. The compiler we used would tell you off if you used swear words for your variable names. So of course our favourite game was looking for expletives that the compiler didn't know about. Some of them got pretty inventive!!
No sigs please, I'm British!!
by clever usage of pass by value, right?
Nice try on the optimization, though.
My guess is that they can both be optimized
pretty much equally. Care to back up your
argument with a reference; I'm ready to be schooled.
the best advice you will ever hear:
never, ever leave Ann Arbor.
Perl has some handy features in this respect. It's a nice high-level language in its own right, and the Perl Data Language module (PDL) provides access to some very nice numerical and binary data libraries including some that are written in FORTRAN.
I know Perl seems too high level at first, but give PDL a try. It's well worth the investment of time to get to know it.
spent 5 years of my life learning software patterns, algorithm analysis, multithreading, etc, etc.
/. account with all caps, based on some computer game...
what do i get to do? technical document reviews. unit test code for ancient C programs.
it gets better.
batch scripts. shell scripts. adding layers of kludge to older layers of kludge.
but at least they pay me the same as if i were doing all the exciting tech i wanted to do. but there's only so much you can take of shell and batch scripting before you go completely insane, and open a new
MORTAR COMBAT!
When coding for fun, I almost always start out in C as I like to keep my marketable skills sharp, but I usually end up in Delphi (visual Pascal).
C just requires more babysitting than I am prepared to give. I don't like having to hold the compiler's hand every time I send a variable or pointer somewhere, or have to flip through a reference manual every time I want to use a simple bitwise operation. Typically, I spend 2 hours debugging really bizare behavior (crashes after commenting out a printf, etc.) before switching to Delphi and having completely re-written and running code in 45 minutes.
It's sooooo nice in pascal to just type "xor" when I want to use an xor instead of looking up some gibberish (%% or && or ^% or something, who knows)
As a heavy user of F90, and a frequent user of F77, C, C++, and perl, (all in heavy duty parallel and serial computational materials science) I can tell you:
There are no systematic speed advantages to FORTRAN over C or C++, no matter what FORTRAN zealots might claim. Check out, e.g. Dr Dobbs Journal from Nov 1997.
There are, indeed, lots of good FORTRAN oriented numerical libraries. This might be the only good argument for FORTRAN left. Compatibility with colleagues from the stone age is another.
old-fashioned F77 is unusable - predeclared variables, common blocks, and no checking for parameter passing into subroutines will cause many more bugs than C/C++ pointer issues if you're moderately competent with C/C++. Fixed format source and short variable names pretty much guarantee unreadable source, too.
F77 plus extensions is marginal.
F90 is perhaps barely usable. You get free source format, dynamic memory allocation, structures, namespaces (sort of), and checking of variable passing into functions. No way to override the latter when it's useful, though. Also NO void *. This means, e.g., no generic communications or I/O routines. F90 pointers are schizophrenic, too. I now hate F90, but I'm locked in by my own legacy code.
In conclusions: use C/C++. You might need to avoid SOME C++ programming techniques, but it'll still be much nicer/more efficient to code than F90, and at most insignificantly less fast. You can almost always call the FORTRAN libraries if needed.
Yo daddy teaches at a university in the UP. Good guy.
You use the right tool for the right job. You don't use a table saw to slice a pizza. In the same way you won't use Fortran in Web design, you will NEVER use Java for massive computational tasks. I'm in the field of physics and astronomy and I'm as old as Fortran 77 itself. It is still being used today, specifically if you have a million point model of a galaxy that you are going to run one simple calculation on over and over again. If you have a dual processor machine, or a massively parallel machine, Fortran is optimized for such tasks and such hardware. Also, I find it necessary to know Fortran and C/C++ and IDL, so I can utilize old, yet optimized Fortran code of my professors' with new "fancier" code I write today.
Also, despite what you say, well formatted Fortran code is no more ugly than most other code (and a hell of a lot nicer looking than your average Perl code :-().
I don't know why people believe that newer languages are automatically better. At the end of the day, you got storage, you got ops screwing around with the storage, and you got a mess of control flow holding the guts together. Just because I'm some hotshot wanting to get my name in the (geek-) papers with my shiny new syntax doesn't mean it's any different. And it certainly doesn't mean it's any better.
So go ahead and learn Fortran. Learn about the joys of representing linked lists as a set of next indices into an array. Learn about dimension statements and equivalence blocks. Learn how to squeeze down your numeric processing into the nub of a kernel of procedural truth. You'll end up being a better programmer.
That is all.
I *hate* FORTRAN.
My main reason for disliking FORTRAN, aside from the complete lack of structure provided/enforced by the language and the true spaghetti nature of most FORTRAN code ( written by engineers or scientists with no interest in the poor saps who have to read/maintain/port/bugfix their code later and little if any notion of good coding practices ) is the fact that I *HAVE TO* read, port, and maintain FORTRAN code.
The US Government ( FCC, various other gov't branches ) is addicted to FORTRAN, even writes *new* FORTRAN code, and still uses FORTRAN originally developed in the '50s. IMHO, there is no good reason to use the language - I mean, certain math operations might be pretty fast, but what the hell kind of processor are you running on, anyway?? I'd much rather use C, Java, Objective-C, or even crufty C++...
Unfortunately, FORTRAN, like DOS, will survive forever, like cockroaches; they'll still be kicking after we've nuked humanity from the face of the planet.
You can't forget the hairstyle-intensive programming language FROTRAN, and the symbolic Ebonics notation language FO'TRAN. ;)
-- the_Librarian
Check out Sisal.
My opinion is that fortran 90 is for straightforward numerical problems. By straighforward I mean simple program structure not the codesize. (My program is about 4000 lines, not much anyway)
can write a FROTRAN program in any language.
FORTRAN is still very much in use by people I know that do lots of Monte Carlo simulations. Lots of people also write most of their code in C, but end up linking to FORTRAN libraries that contain routines that do the computations.
EGS (Electron Gamma Shower) in particular uses it's own variant called MORTRAN, which gets interpreted and converted to FORTRAN code for execution. MORTRAN is basically a high level set of routines that encapsulates the routines that do all the work.
"For I am a Bear of Very Little Brain, and Long Words Bother Me"
Is FORTRAN still alive? Check this out and learn the meaning of Fear:
(Yes, you read that right. FORTRAN.NET. Flee! The Seventh Seal has been opened!)
Read my blog.
I hate language zealots of all types. All languages have their good points, and most bad points people bring up are biased, uninformed, specious, or just plan ignorance. I never meet a language I didn't like. Well, ok, I don't like Ada...
Anonymous Cowards suck.
I see these annoying questions all the time. "Don't tell me that a 30 year old whatever is the best we have!" Alright, I won't tell you. But, I'll tell everyone else, Fortran is sometimes the best language for the job, even after 30 years. It is simple, fast as hell and very robust. What's wrong with that? Oh, you can't write a gui in it or you can't have derived object classes? Tough, that's not what it was designed for.
Why is it that the age of a language or tool is associated with it being inferior? Do you feel that everything that was created prior to your birth is inadequate or inferior? It is in fact, very common for the earliest versions of many things to be far superior to newer ones. This is true, not just for for languages but also for many other things. Most often, the "improvements" and "advances" that are made cheapen, dilute, complicate and destabilize the original product. This is, at least partly to blame for the disposable society that we live in today. Better, or smaller faster cheaper, usually also means less reliable and durable.
To answer your question, yes. Fortran is still a very viable language and is still, after 30+ years, the best language for heavy number crunching. If you need to create a gui and have derived oject classes as well, just link to the fortran libs. But, I'm sure that some snot nosed whippersnapper will suggest that Perl is the only solution. Puhleez!
Learning a new programming language never hurt anyone. Once you know one imperative language, learning others is relatively easy. It is a good exercise and entertaining. Also, you will be in a better position to evaluate the pros and cons of Fortran if you actually know it, rather than listening to other zealots do the typical Fortran vs. some other language. Also, since there really isn't anything in Fortran that is different than your standard no-frills programming language, it isn't a mindf*ck to learn.
I've known FORTRAN since...well...for longer than many slashdot readers have been alive. Done big, numerically intensive projects in it for many years in the 1980s.
I've also done C (1990s) and C++ (2000s).
Ten years ago the criticism about speed was true - that compiled FORTRAN would beat C++ to pieces. Not anymore, unless you're committing newbie mistakes in C++.
If I were you I'd make the best of all worlds. I'd use Python for upper level logic in a clean syntax, in a quick scripting environment.
Then, if there's numerically intensive loops in the lower reaches of your code that get executed billions of times, go ahead and use FORTRAN. Especially when you're doing something like computing eigenvalues for specially shaped matrices, etc., where chances are someone has already written a FORTRAN subroutien to do it well.
Finally, use something like SIP or SWIG to connect the upper level Python to the lower level FORTRAN. Look, too, at Numerical Python and SciPy for others that have been down this road.
There's a lot to be gained from all those netlib routines that have withstood the test of time and been optimized to such an extent that even the FORTRAN programmers surrender, and drop down to call BLAS routines that are best written in assembler.
Using FORTRAN for the whole project is asking for pain once you start looking at things like parsing character input, connecting to network, linking into system libraries written in C. Been there, done that, have the scars.
"Provided by the management for your protection."
I'll get flamed for this but a nice choice, particularly if you want recursive computing, is Lisp. Lisp was not really designed for heavy computational use but it did find its niche in AI which is heavily mathematical in its algorithms. There is a lot of numerical library code floating around out there though you will find none at netlib. clmath is a nice math library that can be found here and there out there. Lisp is slow you say? BS. It is fast for development, fast for testing/debugging, and yes...it is fast to execute. Lisp can be both interpreted and compiled. Interpreted means fast testing. Compiled means fast execution. One implementation of lisp (cmucl) is actually faster than C or fortran in many instances. Personally, I use clisp but that is because it compiles on OS X out of the box for the most part. Well, that's my advice. It's nearly as old as fortran but still a great great language.
Fortran is SUCH A pain to troubleshoot.
Its very easy to make mistakes
Its easy for mistakes to go unnoticed.
Typically used with legacy systems, you end up dealing with INCOMPREHENSIBLE manuals.
However much you try to comment in your program, it will be pretty much of 0 value to anyone else.
Dont do it......
Contemplate the marvel that is existence, and rejoice that you are able to do so.
Compared to C and C++ its going to be slower, but against interpreted languages, like python and perl, its going to be much faster in the loops.
It is an easy language from a coding standpoint. Not nearly as dangerous as C and C++, so you won't spend all your time looking for "stacks in my structs, arrays in my queues; I got the segmentation violation, core dump blues" -mod-fortune.
You can compile Java to native code, if speed is of paramount importance, and it has thread support built in. Does FORTRAN have thread support? On a multi-cpu system this might make all the difference.
In short, I would sooner code VB than take up FORTRAN again. I would rather deal with C, hands down. I coded once in FORTRAN 77, back in 1988, even then it was archaic, but it was all the VAX understood.
I was thrown into a project that was written completely in fortran, and considering that my native language is C++, I was a bit nonplussed at first.
I find, though, that it really isn't that much different than writing procedural C or something like that. I suppose you can complain about it for certain things (memory allocation is a bit of a pain in the butt), but for the most part (for what I'm using it for, Computational Electromagnetics), it works absolutely fine.
"There are two things a man must do,
Before his life is done...
They're write 2 lines of APL,
and make the buggers run!"
I did a good amout of Fortran and Algol in the late 70's/early 80's for CAD software... then I got into APL for simulations, auto-place and route, and DRC. If you're doing compex array or matrix programming, you can't beat APL. Multiply one x-dimensional matrix by a y-dimensional matrix using only one operator... fun stuff, especially for 3 dimensional vector graphics!!
If you don't think it will cut it, then you probably don't know how to use it. Matlab has plenty of constructs for doing loops.
Also, there are often times when you DO NOT want to use loops with Matlab. For example, you may create a loop to do matrix multiplication, but you don't do that with Matlab, because it's already been optimized to calculate such stuff. In fact, anytime you can perform an operation with vector math instead of looping, it is _much_ faster.
Did you know you can also compile to C code with Matlab? Is that enough for you.
You have to think about what your target problem is. There are many professors in my department, most have switched OFF of FORTRAN. Why? My favourite quote from one guy (old guy), "I used to spend 2 days programming and debugging. Now it happens in 2 hours with Mathematica"
I feel the same. I get my work done much faster using Matlab/Maple/Mathematica. I don't care how fast the code runs, because the END RESULT is completed much more quickly.
If you don't want to pay for Matlab, Octave is free (and GPL).
There are times when you may still want to use FORTRAN, but that is if the program is relatively short and simple compared to the run-time. Also, for particular fields (e.g. particle physics), there may be "pre-done" routines in FORTRAN for analyzing data a certain way.
In general, I'd recommend staying way from it if you can.
Here you can find a project of the french compagny of electricity (state monopoly) that went open source for every one to use and contribute to.
And it's not a dead project that they would kinda release, it's alive and already interresting a lot of less rich countries specialists.
Some dig it.
(This is unlike Fortran 77, where for example there are certain tasks that cannot be performed without GOTO's. Ugh. It's got many other problems, too, even leaving aside the 6 character name restriction (since most compilers allow long variable names anyway).)
I couldn't tell you whether it'd be worth your while learning Fortran as compared to using other languages. I do know that there seems to be no (reliable) free Fortran 90 compiler for Linux (g77 does a good job with Fortran77, though, with a few exceptions). We're using a compiler from Absoft here at work, and it seems to work well.
My main point, though, is that Fortran 90 is not a bad language to use. It's not any more hideous than any other language, as near as I can tell; I've seen terrifying code in any language, and I've seen (and written) good code in F90.
-Erf C.
Cthulu always calls collect...
Fortran is still alive and kicking - there are good optimizing compilers for Fortran on a number of machines and a number of good libraries for it.
However, I distrust Fortran personally - a number of years back I took a course in non-linear optimization - the course focussed on well behaved objective functions (smooth, a single optimum...) and the prof had some sample Fortran code that used his favorite optimum finder.
He gave us an example and the answer. But his version was running on one architecture, compiler and OS - I did not have easy access to that machine, though I did to others. I ported the program to those other machines (mostly a question of fiddling output statements and similar more or less trivial changes - the algorithm was still the same). I eventually ran it on six machines (architectures, compilers...) and got six different answers - three of these were close, the other three were substantially different from each other - and the original answer was one of the outliers.
I tried to figure out what the code was doing to see if I could find out where the error was creeping in. The code used pretty much every icky Fortran construct possible (multiple loops ending at a single statement, odd traversals of arrays, and the like) and of course not a comment to be seen. After about a week I gave it up as a bad job.
Yup, this was only one program, but my sampling of fortran code shows it as more typical than not.
There are a couple of interesting alternatives. One is Sisal - a very interesting language that attacks numeric problems more directly than Fortran (see sourceforge for the current Sisal project). Some measurements showed Sisal as being more than competitive with Fortran and other such languages and it seems quite possible that it could take advantage of the processing power in a clustered environment. When I tried to do some image processing algorithms in Sisal it took about two days to write error free code and another day to write code that outperformed my original C code.
Another is APL. I've not been able to verify this recently, but I once heard that there was an APL interpreter that extended APL with some basic numeric operations (matrix inversion and the like are built in) that would pass off the hairy stuff to optimized routines. Admittedly, APL is an interesting language to learn, but it does provide wonderous array manipulation primatives.
Fortran was designed specifically for numerical calculations and thus is better suited for certain tasks than a language designed for system programming like C. Many engineering schools (mine included) require Fortran in the first year curriculum. They keep talking about switching to a more "modern" language like c or matlab, but that has been mostly talk.
So go learn some Fortran, if you will be doing computational programming. Even if you won't it is one of the easiest languages to get into programming.
Beauty is truly in the eye of the tiger
Yeah, yeah, I know. Shameless plugging. :)
:)
To be a bit on-topic, however - I've never used FORTRAN, so I don't know what its benefits are. I've used QBasic, VB, Visual DialogScript (a Delphi offshoot), C++ (Both VC++ and "regular" linux/BeOS C++), and now I've been playing with PHP.
I really like PHP. It's fun.
Whilst Fortran '77 has been around for 25 years, the original language was developed in 1954, some 13 years prior. The fact that it is still used and highly regarded 48 years later is pretty amazing. I used it in college circa 1973 - "Where's my deck?, Anybody see my deck?"
"Can I borrow some blank cards?"
"Oh shit!, I dropped my deck!"
"I hear we're getting a 360/70!!!"
-Ojnab
GCC now has a very flexible front-end and back-end model. The front-ends translate the language into an internal sort of meta-language, and the back-ends output assembler. Even C code goes through this translation process, via the C front-end to GCC.
Besides, even if it did translate to C, it could still be faster than most C code, as it'd likely be translating to a subset of C.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
It's the first language I learned, punching cards one-by-one and handing in the deck to be compiled a la "batch" style, with 24-hour turnarounds between compiles. The language is a lot older than 25 years - I believe it's been around for more like 50 years.
No, I don't see why, with a decent compiler, Fortran should be particularly more efficient than, for example, C, except perhaps for transcendental functions and the like which have been espicially optimized in Fortran compilers.
I could see why the OO overhead of C++ could be a downside compared to Fortran, at least for purely numeric processing tasks.
You think you've seen bugs? Try unravelling all the GOTOs and CALLs in the typical patched-up FORTRAN program.
Moreover, I have no desire to go back to those stupid "FORMAT" statements! YECCHH!!! Believe me, you can be a lot more productive in other languages.
Edsger Dijkstra (Interestingly enough, Dijkstra died today.)
Yeah, I saw that. Sad, losing a luminary like that.
And pointedly relevent to this discussion, since FORTRAN used to use GOTO statements for branching.
If you're considering FORTRAN, then beware the GOTO as Edsger pointed out in this classic.
"Provided by the management for your protection."
I've never touched Fortran in my life, and I have no desire to. I hear all the time about how fortran code is faster than language_x for math, but I have a hard time buying it.
In most cases, does a given numerical algorithm well-coded in C underperform the same algorithm well-coded in Fortan? Assume of course there are better and more expensive optimizing C compilers, as there are for Fortran.
If so, by how much? if it's 10%, or even 20-30%, I would think it's not worth the trouble of using a nonstandard language. Your next hardware upgrade will make C just as fast if not faster.
If Fortran wins - I would assume the win is because the restrictiveness and explicitness of the language make it easier for an optimizer to *really* know what's going and how to optimize things away safely. In this case I have to ask - can't you still code 90% in C and the rest in assembler - or be careful about your C code's semantics to make sure optimizations are obvious to the compiler? And wouldn't eitherof those still be preferable to supporting a klunky old language?
11*43+456^2
I hate to sound trollish, but Python seems to handle loops quite well, and I find them intuitively easier to implement than in C/C++. The next time the author uses Numeric Python maybe he should give for or while a try. Plus there are other modules such as sci.py and scientific python that offer other tools, and Python integrates well with R, gnuplot, GRASS, and other computational tools. And I find C++ to be pretty zippy speed-wise.
FORTRAN will always be in use as long as there is ONE scientist alive who knows it.
Scientists like to latch on to one thing (theory, programming language, etc...) and never let it go.
We have guys where I work that would install Cygwin on their Windows machines (rather than just install Linux or use one of the many Unix boxes we have) because that's what they used before.
People still using Netscape 3 because that's all they know.
I'm sure that whatever work is being done in FORTRAN could be done just as well in another language (Lisp, Java, C/C++, etc...) but since that's all they know, that's what they use. I've seen some pretty big number sets crunched using Java and even bigger sets crunched using C++. Maybe FORTRAN just allows sloppy coders to get away with more? A good programmer can eek as much performance out of a language as is possible.
I think the questioner should just stop whining about how hard C++ is to program in and either become a better programmer or (if his/her profession isn't programming) find a better programmer to do the work.
Just my 0.02 cents, feel free to mod how you see fit.
"For a successful technology, honesty must take precedence over public relations for nature cannot be fooled." -Feynman
I suppose it's the case with most articles on here, but many of the comments appearing seem to be written by people with no knowledge of the subject. Instead it seems to be "I don't have a clue about this but..." speculation.
Fortran 77 has not aged as well as C. It lacks pointers, which can allow the compiler's optimizer to operate more efficiently as there aren't aliasing problems, but there are a number of things that just can't be done efficiently without pointers (or equivalents). I am not aware of any other performance benefit over C. In exchange you get utterly lousy IO, no structs, and a generally clumsy way of doing things.
Fortran 90 has pointers (as well as many things you expect in a modern language), but then as a result it loses that particular performance advantage over C/C++. Fortran 95 goes further down that route.
The big benefit of Fortran 90/95/later versions is that they have parallel programming constructs, which on the face of it give a major performance win over other languages. Indeed it does if a) you're running on a parallel system, b) you have a compiler capable of optimising parallel code for that system and c) you're solving a problem for which the inner loops aren't available in some form of library (e.g. NAG).
The fact is 90% of numerical computing boils down to feeding numbers into standard black box routines: linear algebraic solvers, eigensolvers, BLAS, etc. These should be available in highly optimised (i.e. assembler) form for whatever system you are using, so the language you use to call them is irrelevant from a performance perspective. Consequently other considerations come in.
Take an example. A huge area is finite element analysis. This involves generating a mesh (a complicated procedure), building a linear system, and solving it. The last (rate determining) stage would be done with a fast library routine. That leaves meshing as the primary challenge, and that -- like much computational geometry -- lends itself to C/C++ for a number of reasons: object orientation is a convenient paradigm; there are C++ libraries; and perhaps most importantly from a practical perspective, you can use OpenGl (or a variety of libraries) to display the result.
And that last point is the key one. You can go off and use Fortran, and perhaps (and it's a big "perhaps") get some performance advantages in specialised applications. But you're effectively cutting yourself off from the rest of the computing world. What are all the graphics libraries written in? OS APIs? UI toolkits? You become a second class citizen when interacting with the system, and in a world where numerical computing is being driven towards user-friendliness and nice windowing interfaces, Fortran is not an asset.
Fortran is easy to learn if you already know how to program, and coming out of college it pays to know as many different languages as you can. I graduated a few years ago, and thankfully I took a class that required Fortran programming. I taught myself as I went along, and ended up learning a lot about Fortran. At the time, I thought that I'd never use it, but I was wrong. After some corporate downsizing, I found myself in the same market as people with five times my experience. I had trouble finding work using my favorite languages (Java, C++, C#) because of the poor job market (200+ applicants for an entry-level job). But, I recently landed a great job because I knew Fortran. None of the other candidates that applied had Fortran experience. Best of all, I get to code mainly in C#.
If you have the time to learn Fortran, by all means do it. It sucks trying to find a computer job right now coming out of college (depending on where you're at), and having Fortran on your resume might be your ticket in. Trust me, you never know when you might use it!
If this is right its by far the most interesting statment in the discussion.
FORTRAN is good because its limited!:)
FORTRAN was one of the two languages taught at my college when I was there, and up until 1998, it was the primary focus next to COBOL.
There were a lot of local businesses that still used it in some form of another. Both of these in the government sector (defense and insurance).
I guess it's hard to kill that kind of language when the primary machines you have still depend on it for survival.
My current place of employment still uses FORTRAN, and it's still a very integral part of the system.
The computer system is a real time host that processes up to 800 transactions per second. Each transaction consists of incoming data, validation, comparison to other data, writing of data to disk, formulation of reply, validation of reply and sending of reply. The central engines are written in FORTRAN.
We have a slightly nicer front end (pre-compiler) called RATFOR - it's much closer to C. The rest of the system is written in C, and there's some nice stuff done to interface between the FORTRAN and C code.
This system is supporting a very large business, and has to be stable. It also has to handle enormous amounts of transactions at peak periods. It has to do it reliably, and fast. FORTRAN is at the heart of this system, pumping away without problems. Don't think it's crap, just because it's old!
Fortran is still around in scientific applications and probably will be for some time to come. To write parallel code in C you need to manage the threads yourself. In fortran, you compile, set some environment variables and you're running multiple threads...Of course, I'd take the ugliness of pthreads over the ugliness of fortran any day.
It's true, but from what I understand CERN is beginning to rewrite the libraries in C++. I think that GEANT will be primarily C++ in the next 2 years.
Yes, much like the chicken who's been decapitated some time ago. It doesn't make it any less dead.
While I certainly agree with your observation that Matlab is pricey, I don't understand your complaint that it is "inadequate as soon as it is necessary to use loops to describe a problem".
Heck, one of Matlab's greatest advantages is that every numeric variable is represented as a matrix and that many loops can be dispensed with completely with a little judicious linear algebra.
If you want to rip on Matlab, you'd be better off scorning its poor memory management or its byzantine handle graphics.
However, it does provide a nice development environment for computationally intensive problems. Scripting is a lot nicer than compile-link-debug-repeat when you're still trying to figure out the problem. Plus you can always farm out the most intensive processes to external code modules - which you can write in C/C++, Java or (gasp!) FORTRAN.
If price is the sticking point - why not take a look at GNU Octave. It is free as in beer (not GPL despite the name) and offers much of the same functionality as Matlab. Unfortunately, it shares most of the weaknesses of Matlab as well - and they are usually worse.
FORTRAN looks modern and up to date compared to COBOL. I actually had to take COBOL in college and I miss every minute of time I lost learning it.
http://www.kubuntu.org/
Every code that we use that has been purchased from an outside vendor uses FORTRAN for the actual number crunching. C is generally only used in data analysis after the fact and visualization. AMBER, Gaussian, NWChem, GAMESS-US, GAMESS-UK, you name it - FORTRAN is still the standard.
:).
That said, everything I write is in C
I just read some sad news on the internet.
It seems that Dijkstra is dead.
I'm sure the whole slashdot crowd will mourn his death. Even if you don't like stacks, there is no denying that goto is harmful.
I think it is still in use--do a Google search for ratfor.
While the first two of the three points listed in the parent post are somewhat true, they are usually mitigated, depending on the languages you consider (e.g., you can find good compilers and well-optimized routines for C++ that will perform on par with FORTRAN, but maybe you can't for, say, Java).
However, the third point is actually a disadvantage in my mind: the overwhelming simplicity to FORTRAN leads to simple-minded implementations that are often less efficient (in time and especially in space) than a good implementation in a more modern language.
Case in point: Check out the sorting chapter of Numerical Recipes, and you'll find that their "ultimate" sorting algorithm -- and hence the algorithm that a whole generation of FORTRAN coders think is the fastest -- is heapsort. Now, heapsort is a fine algorithm, but it has some significant disadvantages over quicksort (the algorithm used in the C/C++ standard library. well, almost, anyway.) Of course, you can't implement quicksort properly in FORTRAN because the language isn't recursive! So, I guess it makes sense that they skip over it in Numerical Recipes.
These sorts of issues abound in FORTRAN programming. A lot of (older) engineers and scientists still insist that FORTRAN is the best language for high-performance mathematics, and to some extent, they're correct. As long as your mathematics are limited to those problems that can be solved with gobs of iteration, FORTRAN is your tool. But the minute you step into a realm where a more advanced data structure would be more important to performance (think hashes, heaps, trees, linked lists, etc. Places where algorithms actually matter.), FORTRAN falls flat on it's face. And don't even get started on space efficiency -- any modern language will beat FORTRAN 77 on this, hands down. Pre-allocation of arrays tends to kill an application's memory footprint...
Some of these issues are addressed in FORTRAN 90, but really, if you're going to use that language, you might as well use a language like C++, which is more common, and just as efficient, with proper care.
Let's try not to let fact interfere with our speculation here, OK?
Last summer I worked for a computer modeller who took vast amounts of matrix data and performed hundreds of operations on it. The application was to calculate crustal rebound from glacial retreat based on dozens of lithospheric parameters, and the data was anywhere from a 100km to 100m cell resolution.
Because the jobs took so long, I experimented with it in between jobs. I took a subset of the program, (two routines + main) and rewrote it in C and Perl and ran it on an UltraSparc 10. C was about 1.5 times slower and Perl was 1.65 times slower.
When you're talking 24 hour jobs, a 33% (from C to Fortran) speed gain is measured in hours. On a shared supercomputing facilitie, all the other eggheads appreciate it if you take the least amount of time possible!
P.S. > Fortran is simple to learn. Takes about 3 days if you know C. That being said, I did spend 2 full days debugging a program only to discover that my vast overflow errors were because I had tab characters at the start of my line instead of 5 space characters!
"A computer without COBOL and Fortran is like a piece of chocolate cake without ketchup and mustard."
Slashdot's first reaction to VMware
- If you're considering learning Fortran, just do it. If you're fluent in other languages, it'll take you a day to learn Fortran, and another to feel comfortable in it. It is pretty simple (which also makes it possible to have compilers that generate very optimized code, as was mentioned by other posters here).
- Every programming language has its specific area of use.
- I'm sorry, but I can't resist: If speed is what you're after, program in assembler!
;)
So, to summarize: real men code in asm, and geeks code in whatever is convenient.Then decide whether it is worth it for you to switch to Fortran, or whether you may want to write speed-relevent parts in Fortran.
A case in point: Matlab. You critisized the high price tag and its low performance. The application of matlab is quick prototyping of mathematical algorithms. I am a mathematician and as such, am interested in getting the algorithm to work. Once I have accomplished this (including convergence theory and parameter optimization, done in matlab), I am ready to implement this algorithm in a lower-level language such as C or Fortran (lower level compared to Matlab).
In this scenario, Matlab has a clear advantage since I don't have to mess about with matrix manipulation, eigenvalue approximation or linear equation solvers---I simply use the algorithms supplied by Matlab.
HTH, mlf.
I learned Fortran 77 in college, my father learned an earlier version when he was in college. It is ugly, clumsy, strange, and very, very good for doing scientific calculation because it was designed as a scientific calculation language. Anyone who uses it for anything else is going to feel a lot of pain, just as they would if they tried to use other languages for doing calculations, or Cobol for anything at all.
Just my $0.02 worth.
I just recently completed a port (a consulting job) of some MSDOS Fortran IV to Linux Fortran 77 (about 65K lines).
The interesting thing is that I wasn't ever a big fan of Fortran, and never used it much. In fact I haven't written a line of code in Fortran in over 15 years.
However, it literally took me only a few minutes to "come up to speed". The language is very clean, readable and maintainable. I wonder if anyone will be able to say the same about current languages in 15 years.
Can You Say Linux? I Knew That You Could.
Interesting article about Frances E. Allen in the NY Times yesterday. She just retired from IBM after 45 years. She joined the company in 1957. Her first job: teaching FORTRAN to skeptical IBM programmers. Up until then, everybody at Big Blue was hand coding assembly.
"...Fortran code can be much better optimized than C/C++ code for numerics."
Hardly. Apparently, you've slept through the last half-decade of advancements in OO numerics and C++ libraries. See Blitz++, MTL, and the numerous other C++ projects listed on NETLIB.
But more to the original point, why does everyone assume that FORTRAN and C++ are an either/or proposition? They aren't!!! Its not at all difficult to call most of the myriad F77 routines (including highly optimized BLAS and LAPACK libraries) available on NETLIB from C++ programs. I've done it both "by hand" and with the help of wrappers available in, for example, MTL.
Since this is yet another "tool for the job" question, I think its very important that people understand that they don't have to use just one tool. With a mixed-language approach you can employ, for instance, C++ to handle strings and call FORTRAN for the BLAS and LAPACK routines.
hth,
Ed
Well sounds like you should be using VB, it was designed to hold your hand.
Another product to consider is IDL. The only problem with IDL is that it's price tag is similiar to that of Matlab. However, it does provide a complete programming language, a rich set of data analysis and computation routines, it's own development enviroment, and the ability to create complex visualizations and user interfaces.
... with FORTRAN, I will echo what others have said, plus add a bit.
Yes, FORTRAN is incredibly nice for what it was designed to do: calculate. It is quite quick at it, and the compilers for the 77 version, as noted by others, are incredibly well optimized for this purpose.
FORTRAN is the code of choice for anything that requires a huge bit of mathematical calculations. When you're working with weather models, and it takes 20 hours just to run the FORTRAN code, you begin to notice when that extra overhead the other copilers put in when it increases run times by hours.
That said, if you've programmed before in other languages, be prepared to be sitting there complaining about how terribly FORTRAN is set up. One of my mantras about FORTRAN which keeps me sane is: "The people who made FORTRAN were obviously screwy in the head." Of course, that is said entirely tongue-in-cheek, since the language was "setup" before I was even born. ('Course, not long before, but still before.)
There's a lot to hate about FORTRAN from modern programming, but if you're willing to bite the bullet and accept it for what it can do, then you probably will find it incredibly useful in the long run. FORTRAN is perfect for long calculations (think hour-long, at least), but it is terrible at many other things.
As for the 90 version, it has some nice features, but, overall, you can do a lot of what 90 has in 77 with only a few extra lines of code. Plus, from what I understand, the only decent 90 compilers are commercial (i.e. not free), so factor that into your decision.
So, yes, FORTRAN is ugly code... yes, FORTRAN is terribly constructed given current languages... but, it does its job admirably well. And if anyone wants to complain with me that the difference in running time between C and FORTRAN is only 10%, let me give you a program that'll run for 30 hours in FORTRAN and I'll gladly have those 3 hours extra I just saved.
-Jellisky
When I programmed in FORTRAN the compiler didn't make you declare variable names. You could declare them implicitly in the code. So I was constantly misspelling variables and therefore creating new ones on accident. This led to tons of bugs even in small programs. There might be some compilers that don't allow this though. If there are use those, because misspelling variables is a gigantic source of errors.
Democracy Now! - your daily, uncensored, corporate-free
At the University of Missouri-Rolla, I have noticed many of the engineering departments use applications written in FORTRAN. Just because these huge programs are effective at doing what they do, however, does not mean FORTRAN is a better language. In fact, most of the most recent software I have gotten my hands on is written in C or C++.
Of recent, however, they have been moving over to C and C++. I think this is a wise move as C and C++ are better documented, more versatile, and better understood by modern programmers than FORTRAN. The key to a having easily updatable science and mathematics software lies in within those factors. Plus, C can do so much more.
FORTRAN has some nice elements, but they only carry it so far.
[c0d3fu]: jwjb62@umr.edu || james@macrohub.com
Ever play with pari gp? We used it for calculations in a cryptography course. Our prof was very much into linux and perl - quite a guy really. Tis GPLed, works on several architectures, and is really powerful. Go here or apt-get install pari-doc pari-extra pari-gp, if debian's your bag.
nwp
Forth.
This is an interesting paper on the subject: paper
Look, it's trying to think - Albert Rosenfield
Franz has some case studies of high-end solutions with CL.
more info can be found at XANALYS Lisp Works, which includes this comment:
"Advanced numeric types. The Common Lisp arithmetic package includes unlimited size integers, fractions, complex numbers, and a complete floating point library. Conversion between numeric types occurs automatically."
mp
"The secret to strong security: less reliance on secrets." -- Whitfield Diffie
I just had a grad class this summer in Scientific Computing and it was all Fortran 90. I knew Fortran 77 from a numerical computation course a few years ago. My point is, it is _still_ being taught and it is still *THE* language of choice for high performance scientific programming. Those who count Fortran as "outdated" or no longer significant obviously don't get exposed to this type of programming. While Fortran can seem "odd" to a programmer who grew up on java or C++, it is still a worth while language to learn and use.
Who said Freedom was Fair?
Thank you. You have convinced me to use C. University of Michigan is obviously an inferior school and thus uses Fortran. As a student at The Ohio State University, I can not in good faith use the same thing as University of Michigan. Go Bucks!
F77 is an old beast indeed, but, like a lot of people have mentioned, still the best for numerical computing and analysis - mostly because there's a huge library of well-written math/science functions sitting out there for it.
My personal advice, from experience (I've helped rewrite/maintain/port Fortran77 code written for VAX - not a pleasant thing), is that once you go over about 500 lines in FORTRAN, you're asking for trouble. It's not a language designed for Big Things - it's designed to do Little Things Really Well (like, say, intensive mathematical computations - exactly what it was designed for!).
Write your computation-intensive routines in it and bind the code into your C/C++ interface that does all the string handling/GUI/OS interface/whatever - GCC makes this lovably easy as long as you're not braindead.
In short: It's well worth learning, because there's still code out there written in it, and it's bloody fast. Don't reinvent the wheel if you don't have to. Plus, saying that you have experience with Fortran77 is a great thing to put on a resume.
Try O'Caml (caml.inria.fr); it's a modern language that's compiled very efficiently (independent benchmarks) and is suitable for heavy crunching. O'Caml has lots of features that you won't find in many languages, like algebraic data types, higher order functions, etc., but is intended for real general purpose programming. Most importantly, it's type-safe (statically) so you probably won't spend as much time tracking down bugs unrelated to the problem at hand. (That has certainly been my experience with SML, a language from the same family.)
Most compiler manufactureres (gnu, DEC, Sun,
Object oriented languages produce less optimized machine code because they make assumptions for you, the programmer, about how the program is supposed to work. The object oriented view is often more powerful conceptually and programmatically, but the piper will be paid in machine code before it is over.
As languages get higher level, they get less effecient
- Assembly (assembled, HARD to write/debug, runs like the wind)
- C, Fortran, Ada (compiled, easier to write, slightly less effecient)
- C++, Objective C (compiled, conceptually more powerful, slightly less effecient)
- Perl, Python (dependent on external runtime environment, quite abstract syntax, much less effecient)
- Java, Powerbuilder, other 4GL languages...
Before you flame me, I list Java with Powerbuilder only because I really really really hate them bothAnyway, back on focus now with the original question, any language higher level than assembly is going to have ineffeciencies
"Glory is fleeting, but obscurity is forever." - Napoleon Bonaparte
It's probably worth checking out
I do subsurface fluid flow modeling and most of the industry standard codes are written in Fortran. Examples: Flow and Transport: MODFLOW-88, 96, 2000 (Fortran 77, 77, and 95) UTCHEM 6.2 and 7.1 (Fortran 77, 90) SWIFT (Fortran 77) Optimization: PEST (Fortran 77 or 90) The addition of dynamic array allocation was the largest (and best) improvement between 77 and 90 in my opinion. Also, the modularity has improved with each new addition. Basically I find a combination of Perl and Fortran to be the most useful for crunching numbers and interpreting results from the huge data files that are produced. -ed
I'm not going to wade in on a lame language war, but Fortran IS very portable. I have worked on code that was written in 1967 for a CDC mainframe. It was then ported to a:
PDP-11, then a
Vax, then a
486-class PC. The code ran much faster on the PC then the Vax.
Then I discovered that I needed a routine from the original CDC implementation, which had not been touched since. So I typed in the routine FROM CDC PUNCH CARDS. Compiled perfectly.
In grad school in 1992 I wrote FORTRAN programs when I was trying to use fractal methods to describe landscape patterns and time-series data of sandy beach volume measurements. I hadn't ever used fortran since I learned it in undergrad, in maybe 86. But I started from other people's programs, and they were written in FORTRAN.
Nobody cares much about fractals in that field any more, as far as I know, but they're still using the programs in a "math for scientists" class, in the unit on time series. FORTRAN may be ugly to real hacker-types, but scientist-types, who generally don't put as much thought into the "what language should I really be using" question, still use it all the time.
As an IT manager now I wouldn't want any new programming done in FORTRAN (I manage a Museum, though, and most of our programming is OpenACS stuff anyway). But scientists pretty much work for themselves and make their own decisions. Given the entrenchment of FORTRAN and its ability to do calculations, scientists will be using it, and mostly it, for a long time to come.
So I think this comes down to a personal decision: I had an academic career as a scientist, and programmed in FORTRAN. Now, perl, php, python, tcl, java, VB weren't options then, but if I'd been in Grad school in the late 90's, and I'd known that I'd end up in IT instead (I did know that, actually)--then maybe I would have picked some other language to learn knowing that it would be better for my ultimate career. Even if it would be slow or difficult for calculations (it was only a master's). But if I was going to stay a scientist, then FORTRAN would have been fine as a choice.
Just a bit of trivia. FORTRAN is NOT turing complete.
For example, there is no way to write a Fortran program that computes the summation of two arbitrary numbers without using input and output primitives. (when I say arbitrary i DO MEAN ARBITRARY).
The main reason for this is that Fortran has no memory allocation method. You have to give it a finite initialized memory storage hard coded into the program.
Not only that but Fortran doesn't support recursive functions.
Basically every Fortran program is a huge finite automata.
This of course assumes you aren't using input and output parameters to get arbitrary storage...But that's really ugly.
Not that you can't do useful things with Fortran, but I'd suggest Common Lisp, an ML dialect, and C over Fortran any day.
((lambda (x) (x x)) (lambda (x) (x x))) http://www.endpointcomputing.com a scientific approach to custom computing.
OK, I couldn't resist... Here are the rest:
"Real programmers don't write in FORTRAN. FORTRAN is for pipe stress freaks and crystallography weenies. FORTRAN is for wimp engineers who wear white socks."
"The primary purpose of the DATA statement is to give names to constants; instead of referring to pi as 3.141592653589793 at every appearance, the variable PI can be given that value with a DATA statement and used instead of the longer form of the constant. This also simplifies modifying the program, should the value of pi change."
-- FORTRAN manual for Xerox Computers
"You can measure a programmer's perspective by noting his attitude on the continuing viability of FORTRAN."
-- Alan Perlis
"You can tell how far we have to go, when FORTRAN is the language of supercomputers."
-- Steven Feiner
"An engineer is someone who does list processing in FORTRAN."
"FORTRAN is a good example of a language
which is easier to parse using ad hoc techniques."
-- D. Gries
[What's good about it? Ed.]
"FORTRAN is not a flower but a weed -- it is hardy, occasionally blooms, and grows in every computer."
-- A.J. Perlis
"FORTRAN rots the brain."
-- John McQuillin
"FORTRAN, 'the infantile disorder', by now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is too clumsy, too risky, and too expensive to use."
-- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5
"[FORTRAN] will persist for some time -- probably for at least the next decade."
-- T. Cheatham
"It's multiple choice time...
What is FORTRAN?
a: Between thre and fiv tran.
b: What two computers engage in before they interface.
c: Ridiculous."
"On the eighth day, God created FORTRAN."
Slashdot's first reaction to VMware
Your issue with extra ints on unformatted writes of Fortran file io... I've worked on Fortran development on 2 platforms:
1) DEC/Compaq Alphas running OpenVMS with DEC compilers
2) Windows NT4/2K with MS Powerstation v4 and Compaq Visual Fortran v6 compilers.
The DEC compilers on OpenVMS did *not* do those extra ints on unformatted file io. My C code to read the output file worked with no extra steps, and could read data structures with few problems. The MS/Compaq compilers *did* write extra ints on the Windows platform. Drove me buggy when I was trying to port some software from VMS to Windows. (Don't ask why, I was ordered to do it.)
Incidentally, the MS Powerstation v4 compiler wrote a 16-bit int before and after, and the Compaq Visual Fortran v6 compiler wrote a 32-bit int before and after. That change also drove me nutty. This had some extra issues... an array declared as
integer(4) MYVAR(1000)
was *larger* than the 16-bit int could specify... so the compiler broke it up into 128-byte chunks. Yes, a 4000-byte array was written as a series of 31 128-byte chunks (each with its own leading and trailing 16-bit ints), followed by a 32-byte chunk with its own leading and trailing 16-bit ints. Making C code to read this mess hurt my brain. At least switching to the Compaq v6 compiler took that issue away.
I didn't look up the Fortran language spec to see which one was actually complying with the spec. Having seen all three methods, I decided none were correct.
Incidentally, when doing unformatted writes of structures where one language is writing, and another language is reading the file... Make sure both compilers are using the same memory/data alignment rules. My Fortran compiler was doing align=byte, and my C compiler was doing align=word, and my structures with some logical*1 and integer*2 variables were messing up my read routines.
Ahh... the dangers and joys of multi-language development projects.
This is my sig. There are many like it but this one is... Oops. Frank, I've got your sig again! Where's mine?
A lot of new code is being written in C++, though, and Root (http://root.cern.ch) is used somewhat in place of Paw. Pretty much all of our code for run 2 of CDF (the Collider Detector at Fermilab) is in C++, although some wraps older Fortran code (in particular, Monte Carlo generators like Pythia). I hear Atlas at the LHC is using Python to drive some of its code, most of which will be in C++.
Not because FORTRAN is a must-know language (actually it is butt-ugly) but the time you need to invest is a few days at worst. Yes, FORTRAN (77 and prior versions) is that simple.
Gentlemen, you can't fight in here, this is the War Room!
I vote for high-performance Java, personally (with further extensions for better performance like lightweight objects [no inheritance but very little overhead for things like complex numbers], immortal [static] objects and a good generics implementation). I'd also like to see a very flexible and extensible operator overloading functionality, as well as the ability to use Unicode in Java source as an optional extension, for both variables and operators.
Also don't forget that gcc 3.x now includes a Java front end...perfect for extending into numerical Java. It's especially appropriate since it is a traditional "ahead of time" compiler permitting full optimization.
IBM has already provided matrix libraries written in Java with about 80% of the performance of fully optimized FORTRAN. Another interesting library is the Colt Library. It is also possible, using JNI and DirectIO, to use legacy libraries efficiently from Java where appropriate.
The focal point for numerical Java is Java Grande.
BTW, I was sorry to miss the Java 3 discussion yesterday, but this post summarizes my desires in that area. Quite a bit different from those of the article's author (what a whiner that guy was!).
At any rate, FORTRAN is still alive and kicking, and will be for another hundred years I'm sure... ;-)
I hope new development is mostly being done in Java in the not too distant future, though!
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
I think the main reason Fortran is still alive and well is that legions of professors and graduate students in the 60s and 70s wrote so much good numerical analysis software. Translating that code into a more modern language is simply out of the question. It would require a huge effort.
If is really tough to write a function to invert a matrix of arbitrary size that performs well and to do it with proper attention to numerical stability (basically I mean that round off error won't kill you). You would need to write about a thousand such functions to replace the work that is available if you are willing to use fortran.
The R language (www.r-project.org), which for this discussion can be considered an open source version of matlab, has been built atop the old fortran sources. It's a very cutting edge software package and if it weren't for the gnu fortran compiler and the old fortran numeric code, it would have never gotten off the ground.
I am so glad to see this topic on Slashdot. I can't say how many times I have asked around with this question, only to see it neglected. I think the issue of whether or not FORTRAN is still kicking belies another, much deeper problem in the numeric computing community that this post touches on. I'm convinced that numeric computing is in quiet crisis at the moment.
FORTRAN is still kicking, very much so, for all of the reasons you enumerate: it has been the standard for so long that everyone uses it, it's widely available, and archaic code has stood the test of time. So in one sense, the answer is "Yes, FORTRAN is still kicking."
In another sense, though, the poster was asking whether or not they should learn FORTRAN. That I just don't know about. Maybe FORTRAN is still kicking. The question, though, is "Should it be?"
True, FORTRAN is fast, it's freely available, everyone knows it, and there's plenty of code available for it.
However, FORTRAN is entirely too archaic. I can't stand the syntax, which I find gratuitously convoluted and difficult to work with (GOTO jokes that apply to BASIC should be applied with equal regularity to FORTRAN). Some might praise FORTRAN for its procedural "simplicity", but I think it's just crude and inefficient. Newer versions of FORTRAN, such as 90, 95, and so forth, take care of these issues, but are irrelevant because practically no one uses them! It's almost as if FORTRAN 90+ exists solely for the purpose of rhetorical argument, to say "Yes, but newer versions solve those problems." It's a trick, because the newer versions are rarely used, undercutting all the benefits of longevity and standardization that F77 provides.
In the end, then, you have this dilemma: C/C++ provides the modern syntax, but lacks the numeric constructs of FORTRAN (native matrix notation, etc.). FORTRAN, on the other hand, is made for numeric computing, but undercuts itself by being nauseatingly convoluted.
Thus, the crisis. Numeric computing is missing a language. We have high-level languages like MATLAB, Octave, R, Maple, Mathematica, and so forth, and the extremely low-level FORTRAN, but nothing in between. True, you can do numeric computing in C++ (that's what I do), but that's sort of bastardized due to the lack of native numeric constructs. Java might work, and has its own benefits for numeric computing, but also it has its own problems. Modern FORTRAN looks good, but no one uses it.
So, in a sense, I don't think this guy should be asking "Should I learn FORTRAN?" We should all be asking ourselves "What the hell are we doing?" Is there a language that we could be using that would be better? Is it time to make a painful but necessary effort to just switch to, e.g., F95? Tacitly shun F77 and translate existing code into F95?
This is something that really bothers me a lot. I don't mean to sound complainy, but I really think there is a problem. There shouldn't be as much of a disconnect between MATLAB/R and C++/FORTRAN as there is; there should be something sitting in the middle.
Are there any other languages that look like serious rivals to FORTRAN that the numeric computing community should be switching to or evaluating? I've seen some suggestions here, like Ada, but are there others?
I for one am surprised that OCaml hasn't proliferated more in numeric computing, given its speed and functional-object-oriented nature. It would be nice to see native OCaml matrix libraries, for example.
So what about it? What else could this guy learn? What else could we all learn and teach in our CompSci 1024, Introduction to Numeric Computing course?
Yes - it is still useful. Here at LANL (http://www.lanl.gov/) it is the predominant language for existing AND new scientific codes. Array languages are just better suited for scientific computation, and Fortran is the most popular. Others such as ZPL show promise, but for mainstream support F90/95 is the best. I have worked with POOMA, which was mentioned by someone. There is a reason that very few people use it. C++ is just too gross for real codes.
Fortran does not force you to write spaghetti code, any more than c forces you to generate buffer overflows or perl forces you to write unreadable code.
Design and structure your application.
If you are used to objects and methods, just use subroutine modules and entry points to the same effect.
Fortran was where I learned to use multiple entry points into one sequential file for recursive processing.
I'd just like to say that I'm employeed as a programmer and my last few tasks have been to take old highly computational programs in fortran, and reprogram them into VB 6.0. I have found that using VB is almost exactly like using fortran and is fairly easy. The last program I worked on was one that simulates the risk of consequence in an 80 foot drop of a container of nuclear waste. [My company engineers the containers] The only serious difference in code was how variables were stored going from procedure to procedure. When I was done, the code was nearly the same, but more modernized. So in my opinion VB 6.0 is a better option than FORTRAN just for the simple fact that its more, modern. -Me
it's 45 years old. Original Fortran, 1957. Fortran-77 isn't all that different from F66 and its predecessors.
That being said, if you write numerical algorithms or bust numbers for a living, there's nothing like it. (of course, that's also said of Vegamite)
I know the reason for it: any binary file in fortran has to be separated into records. On the other hand any record may contain any sequence of characters, thus no record separators (like the newline for formatted files) can be defined. One of the solutions (not encoded within the standard, so be careful when you want to read a binary fortran file from a new architecture) is putting an extra piece meta-information with the length of the line (usually a four bytes integer not belonging to the record itself). Now you may want to ask: Why the length of the record is written both at the beginning and at the end of any record? The reason for this is that the fortran code should be able to move both forward and backward of one record at a time. Ones I bacame mad trying to discover these things
Right now I'm debugging a 10 year old fortran project, and it's hell. Somebody decided "hey, let's add something", and forgot that somewhere else in the code, common block A was used to transfer the data rather than common block B. Naturally, being common blocks, there is no need for having a common _name_ across the different files, so it is impossible to track.
So, I'm stuck with a problem that can't be tracked, in a language that nobody knows and a project that most people don't care about anymore (after all, it's my Ph.D., not there's!).
Take my advice -- forget the optimizing, and use a language you can read. Hardware will catch up soon, and in probably less time than it takes you to debug the damn thing!
If you want a serious scientific library written in C, see the GNU scientific libary at http://www.gnu.org/software/gsl/gsl.html
I was involved in a study by UNM on the choice of language for entry level computer scienctist (aka the weed-out course). We considered all the options (java, c++, pascal, lisp, etc) and I happened to think it might be useful to ask practicing programmer what language they learned and what language they would recommend new developers to cut their teeth on.
I asked them to consider both the training (aka marketability) and educational aspects of their recommendation. I didn't want the concerns of getting a job to be the overwhelming focus of their recommendation. I wanted them to also think about how much useful experience, insights and language neutral knowledge they gained from the language they first learned.
Not suprisingly, BASIC was the most common language cited as "first learned" followed closely by PASCAL. FORTRAN, Modula II and SCHEME all placed in statistically close proximity to one another. Don't stop reading yet though- the punch line is to come.
A more interesting trend came from these same practicing programmers answer to the question of whether they felt their first language was of great help to them or simply a cross to bear. FORTRAN 77 was overwhelmingly cited as the most worthwhile language to learn from. This was almost universal among the FORTRAN first users and statistically relavent among those who'd taken learned other langauges first and come to FORTRAN later on. Please note this was conducted in '94 before FORTRAN 90 had sort of taken over.
The BASIC developers, once they had a bit of experience under their belt, as the source of many bad habits and of limited income earning and problem solving potential. The PASCAL initiates saw no use for the langauge beyond academia. Modula II was cited as a very educational language but with limited commercial potential. FORTRAN, though, was overwhelmingly cited as a great langauge to learn from.
It's simplicity gave the semantics a low learning curve but the richness of the constructs and the structure they impose avoided the bad habits picked up within BASIC. The respondents (other than the old hats) were also nearly universally suprised by how widespread FORTRAN was not only for legacy code but as an everyday prototyping and general purpose language. They found FORTRAN knowledge mapped easily into other imperative languages.
So, from both a practical, resume building point of view and for the holistic education FORTRAN will provide- go for it. 215 programmers can't be wrong.
vr/
Justin
and you're a fag
There are some memory considerations and interface issues that make them want to switch over.
If it's mainly the interface issues, restructure the Fortran code as a library, factoring out the interface code, and then rewrite the interface in a different language. It's not that hard to call library functions from most languages.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
And, as a Fortran compiler writer, I say "Use it! Oh God, please keep using it, or I'm out of a job!"
I agree with you on a number of levels (and admire your use of Ocaml). I use different languages for different tasks; I think most of us do.
I'm not sure that this is the issue here, though. I think the problem is not "Which language should I use?", but "Which language should I use for low-level numeric computation?"
This is a much more serious and direct question. The problem isn't that one language doesn't do anything, it's that one language isn't good at what it's supposed to be good at anymore, and there isn't an adequate replacement. Sure, I wouldn't write scripting interface in FORTRAN or C++; I'd probably use Tcl/Perl/R/something similar. But when it comes to writing that multivariate integration routine, what should I use? FORTRAN? C++? OCaml? What?
I agree that we should use the right tool for the job. This is something else: there is no right tool for the job.
If RPG video games like Fallout or Arcanum have taught us anything its that OLDER forgotten technology/magic ALWAYS is/works better than NEW technology/magic.
Ave Molech Setting
What investment? It takes a day to learn FORTRAN. Just go learn it, then decide whether you want to use it or not.
If you know any other programming language (C, C++, Perl, LISP, Visual Basic, Q-BASIC, ANYTHING), then it will take you a day or two to learn FORTRAN, especially if you don't need I/O routines. Give yourself a week if you want to learn I/O, EQUIVALENCEs, and the other details. Type "FORTRAN TUTORIAL" into your local Google search box and start working.
I wouldn't want to learn it as a first language - I think the I/O is terrible. I can't use it for 30% of my work - I use C for decent I/O, preprocessor macros, simple string manipulation, pointers and casts. For the other 70%, it's just as good as any other procedural language.
Of course, now someone will say C's I/O is terrible, and FORTRAN's is far easier. But again, it's silly to spend much time listening to debates like that, when you could learn the language in a day or two and decide for yourself. Jeeze, it's not C++ or LISP - it's just FORTRAN. It's like asking if Wordpad or Notepad is better for text editting...
Anyone who's written in c knows that's it's constructs are very simple. Also "safety" features such as array bound checking, etc. are nonexistent. Therefore, compiling it to any normal machine code is very straightforward because of the simple mapping. Not familiar with Fortran, but I doubt it's any better for performance than c.
Vote for Pedro
What types of bugs would these be exactly.
"Compilation" bugs? Those are actually there to help you and will save you many more nasty "logic" bugs in the future. Take some time and learn the language a little better, these will gradually become insignificant and invaluaable at the same time.
"Logic" bugs? It's hard to see how logic bugs could be unrelated to the "problem at hand" unless it's a lack of libraries and or consistent interface that is your problem. Not sure how Fortran would help in any case.
Knowing something about these bugs is the first step in trying to avoid them. (whereas switching languages would be one possible last step)
I'll make some guesses:
You're experiencing many compilation bugs because you don't understand the C/C++ environment you're working in, or because you're trying to force fit code from one environment to another. This is natural in switching from a specialized high level language to a very general purpose low level language. It takes a lot of time and effort to really master C or C++.
A nice compromise might be using C or C++ that is callable from Matlab code. This could give you performance where you need it and ease of use when you don't. (Although from what I remember of Matlab the *seems* are no fun...)
Of course, an even better alternative might be Java. It has wide library support and a great degree of similarity in the API's presented by most libraries. It might not be quite as efficient as C or C++ for some problems, but can be more efficient for others. It's also fairly easy to learn and use, and it's going to beat the pants off Matlab or Maple in computation speed. (It can also call native C when necessary, though the data structures differ greatly between C and Java)
Hmm, maybe this whole article is just a Java troll...
There are many, many numerical based libraries available (see LAPACK, BLAS, SPARSEKIT, etc) that were originally written in Fortran. Many people much smarter than I have spent countless hours writing, optimizing and verifying these libraries. Since there is no point in reinventing the wheel, I make heavy use of the above.
However, just because they are written in Fortran doesn't mean I have to write in Fortran. I can link in these libraries using whatever language I chose. In my case, that's C/C++.
The advantage and disadvantage of C/C++ is that they are advanced languages. You are given more than enough rope to hang yourself multiple times. At the same time you can write some amazingly powerful stuff. Good style and experience can protect you from many pitfalls.
You mention that you find you are spending too much time fixing bugs related to your lack of experience with C++. If you are more experienced in Fortran than C++, then certainly you may find your time better spent coding in Fortran.
However, there is no evidence to believe that Fortran is a superior numerical coding language based solely upon the large available base of libraries. Packages such as Blitz++ written in C++ have already demonstarted performance on par with Fortran based codes.
If you have the freedom of choice use whatever you are most comfortable in using. The reason Fortran numerical libraries are still around is sheer inertia. Personally I can't imagine coding in a language as full of vestigial punchcard idiosyncrasies as Fortran on a daily basis.
any script based language (Matlab, Numeric Python, Scilab) to be inadequate as soon as it is necessary to use loops to describe a problem and using such tools for recursive systems can be a real pain.
These are exactly the places where these languages excel, especially as compared with fortran! Fortran has only the most basic looping structures, and the lack of complex structures, pointers, and object abstraction makes writing any complex algorithm an excercise in mental anguish.
Things like Numerical Python were implemented specifically to put the control structures in a language that is readable, writable, portable and understandable. If you really need to, you can code the bit twiddling in C and link from Python/Matlab/whatever, but for god's sake, leave the high-level program structure up where you can read it.
Always use the right tool for the job... in other words, learn every language you can. I regularly program in C++ (mainstream applications), Fortran 90/95 (scientific number curnching and high-performance cluster apps), Python (scripting and prototypes), Java (portability and network systems), and various other languages as the need arises. Programming is a matter of algorithm, process, and design; syntax is a detail. BTW, your opinion of Fortran 90 is incorrect; indeed, Fortran 90 (and 95) is widely used, especially in the high performance computing (cluster) community. There is an active Fortran 95 project for the GNU compiler collection, and Intel has a "non-commercial" version of the Fortran 95 for Linux. Fortran 200x is in development right now.
All about me
"My opinions are my own, and I've got *lots* of them!"
I read an article recently about a C extension to Python that very efficiently (and correctly) handled multi-dimensional matrix math. Thus you can write code using the very nice syntax of Python and still get good performance. The author of the article said something like "No one who has tried Python with these extensions ever wants to go back to FORTRAN."
It made me wonder if, with enough C extensions, Python can take over FORTRAN's niche as a high-performance heavy number-crunching language.
I don't know enough about the issues to make any predictions; I'm just wondering.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
Sorry, I meant Fortran 77. Fortran 90 of course has pointers, but if I'm not mistaken Fortran 90 has facilities for avoiding pointer aliasing (perhaps that is what your code is showing? I've never written Fortran 90 code...)
All is Number -Pythagoras.
I think the author spent two weeks wondering why 3^2 kept giving him the answer 1 instead of 9.
Duh.
In my numerical analysis class, we spent a good deal of time demonstrating the pitfalls of Fortran. There are certain numerical mistakes that can ONLY be made in Fortran. Ick.
I do use Fortran (F95). It runs beautifully both on my Linux desktop and on a remote Alpha cluster on True64. It also runs fine in the Soliaris and SGI workstations. The beauty of F95 is not that it is quite portable, but it is _easy_ You can use loads of time saving constructs which are a pain to deal with in C (I also do C for some other things mind you). If you use Windows, you get some pretty good debuggers (the ones for Linux are quite ugly, and since gcc does not yet support F95, gdb does not particularly care for it).
The thing is that if you tye F9x, you'll find writing the code easy. Learning the language is a no-brainer. You can then interface the numerical stuff with things such as SciPy to display it and so on.
I happen to know that fortran is used for:
* Modeling entire forests (not as easy as it sounds)
* Modeling Jake Brakes (18 wheelers')
It is a powerful language, still very much alive. Notice recent changes that allow it to link with Visual Basic code as the UI.
Daniel
Besides, I'm not porting the 2.7 million lines of code to C++ to make some linux weenie happy.
"FORTRAN --"the infantile disorder"--, by now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expensive to use."
--Edsger Dijkstra, 1975
How do we tell truths that might hurt?
I think the original poster is correct about a few points. A major problem with C/C++ is that it assumes its user is an expert programmer and will willingly go off the edge of the nearest cliff if steered that way. On the other hand FORTRAN is very primitive but can still provide better optimization because it can make more assumptions. My proposed solution is a subset of C++ that limits what the programmer can do so that novices, and people that don't need the flexibility can have seat belts. With these limitations imposed, it would be possible for the compiler to also make more assumptions and generate more optimized code. There might even be a compiler option to automatically generate multithreaded object code.
if you ever see yourself working for the us department of defense, it might worth your time to familiarize yourself with it. sure, in most cases they've moved on from it (and ada) to c++ and others, but there's a crapload of legacy out there that has to be maintained by somebody. because a lot of the guys who know fortran are near retirement, they'll need a replacement...and if you knew fortran, you'd be one of the few young folks who knew it.
w|f
Fortran is only still alive because that's the only language that scientists and engineers (other than CS people) are taught. Just like the speed of light is still considered constant becuase that's what we were all taught. -Chris
>in advance, and are able to simulate decent
>control structures with GOTOs, go ahead...
???
GOTO???? Yes, both C and older version's of Fortran have them, but the last version of Fortran that needed them was the 1966 standard. There is no need for them in 77 (save the strange places you would also need them in c, but those are more thana little rare).
hawk, trying to figure out how to criticize the 1966 c standard
The core mainframe-based flight operations system I worked on at Northwest Airlines (originally developed at United and also heavily used there) is almost all FORTRAN code, and there are several dozen airlines around the world (including Luftansa, Air France, and Air Canada) who are still using various "USAS" airline applications from Unisys Corporation (written in FORTRAN 77).
(USAS stood for "UNIVAC STANDARD AIRLINE SYSTEMS" at one point in time, and it reflected the heavy presence Univac 1100 mainframe hardware had in the airline industry in the 60's and 70's).
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
You are asking entirely the wrong question. It is never appropriate to ask, "Should I learn ?" Instead, you should ask, "Under what circumstances is it best to use ?" For nearly every language, there is a use for which it excels.
This attitude that "you kids" seem to have today of "is this language worth learning" drives me up the wall. Learning a language to the point where you can use it to do routine tasks should not take more than about 4 weeks. It's just not worth worrying about. I have used over 2 dozen programming and scripting languages, and won't hesitate to learn more.
If you know the fundamentals of software construction, you can see that most programming languages are about 95% similar. You can categorize most languages into one of a handful of classes of similar languages. Once you arrive at that point, whether or not to learn another language is almost a complete non-issue. If it fits the job, you do.
It is striking that this nonsense FORTRAN debate makes it to the /. front page on the day that the death of E.W.Dijkstra has been announced. It is even more striking that the news about the loss of this computer science giant is deemed of less significance by your moderators. What is next? Advocating the implementation of 'goto' in java 3?
/.-ers is may be interesting that he also started the first real flamewar with his infamous "Goto considered harmful"-article.
E.W.D. was one of the most influential pioneers of computer science, like Turing, Zuse and Von Neuman. His work was always been in the light of creating a solid mathematical foundation for programming. His most remarkable achievements include the wide acceptance of 'structured programming', the invention of semaphores and ofcourse the Dijkstra shortest-path algortihm. He was awarded the ACM Turing Award in 1972. For
For the news on his death: here, here or here.
For programmers who like to read all of his manuscripts (if you haven't read them, you don't know what programming is about): there is a great archive of all his material. Dijkstra died at the age of 72. May he rest in peace and may his work live on.
Back on topic:
FORTRAN, "the infantile disorder", by now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is too clumsy, too risky, and too expensive to use.
-- Edsger W. Dijkstra.
http://www.cs.utexas.edu/users/EWD/ewd03xx/EWD340. PDF
Granted, I don't know if this guy has the necessary credentials to make such statements.
forest, trees, blah blah blah...
The post in question was discussing the code in NR, which uses FORTRAN 77 (yes, I know it can be compiled using F90).
Check out the numerical extensions to Python. They're quite good and can give you an environment with the power of Matlab for zero dollars.
:-)
Numpy uses the netlib libraries behind the scenes, by the way, so you get very good speed for array operations. You get the best of both worlds -- Fortran speed with Python's expressive power. It's much easier to do I/O and UI programming in Python than Fortran.
-DA
I worked at the Arctic Region Supercomputing Center for one summer when I was an undergrad. I didn't do any FORTRAN programming, but almost everyone else there did. If you want some information about FORTRAN programming on high-performance systems, check out their newletters, or just try searching their site for 'FORTRAN'.
If you're good at a tool the religion is kind of moot, isn't it ?
t ml
Try a modern Fortran called F which pruned away some stuff that was said to be confusing (although not to me) and kept the good. It is free, although not GPLed (spare me the GPL flames, please):
http://www.fortran.com/fortran/imagine1/index.h
Regards,
rcs
If you wan't the job done, and don't want to fuck around debugging all day go for .net, either vb.net or C#, these languages are so user friendly it hurts !!
FORTRAN is still a required programming course for an undergrad degree at my university... but not for the CS students. It's still required for all Nuclear Engineering students, because there is nothing better or with a decent enough user base for nuclear modeling applications. No one else takes it any more at my alma mater except for us nukes.
It may or may not be up there in computational speed, but is is extremely functional mathematics application, and it is extremely configurable, and is Open Source. An excellent application that I have used on occasions with excellent results.
Kim
There has been a very long discussion on the comp.lang.fortran groups about a very similar question. Many people there can help you decide what your particular problem warrants as they use most of the languages described in the various comments here. Quick link to this particular thread is below: discussion at groups.google.com --OoSync
I always get the shakes before a drop.
I don't know if anyone mentioned ROOT yet, so here goes.
There's a framework from CERN called ROOT, which has a lot of nice features for numerical scientific computing.
The language is C++, but don't let that scare you - in time you will also frown upon procedual languages (they are hard to maintain) and functional languages (they just don't do the job for numerical stuff - to bad - I like the concept).
ROOT provides things like histograms, persistent object storage (and it beats Objectivity by miles!), and ladida. ROOT also has an interactive scripting environment, using C++. This is cool, as it means you can prototype your algorithms as scripts, and when your happy with them, you can simply compile them, and get much higher speeds.
Also note, that Intel's free C++ compiler is reputed to give a 30% increase in speed compared to GCC 3.0.
ROOT is used by some 70+ physics research projects around the world - from the gigantic Alice and STAR to the more modest Athena and BRAHMS.
If I were you, I'd defently consider C++ again. The stuff you've found on netlib is almost all outdated, and there's a good chance that it's been ported to C/C++.
There are quite a few people working on polishing up Java for numerical work.
A couple of links would be IBM's NINJA, the Java Numerics page and Java Grande.
There are papers (albiet old) on the IBM site which show they were able to come within 10% of FORTRAN performance using Java code and a massaged JVM.
IBM's matrix routines (downloadable somewhere) are friggin' fast.
The runtime optimisation also lets you tweak and prune to a greater extent than C/C++ code, although FORTRAN still rules in the code optimisation department. I believe this is because it's a simpler language (and most papers I've read come to this conclusion... C/C++ lose because the compiler can't be as brutal in its optimisation).
For a while there were large advances in C/C++ compilers, but I don't see as much of that any more... not that it would be on my radar necessarily, because I haven't kept up on the reading.
Anyway... Java... eventually. I think it'll get there. Of course I meet with huge resistance from the FORTRAN purists whenever I say that, but that's life. Whatever works for you, I guess. I'd rather write stuff in Java that FORTRAN; FORTRAN drives me up the wall.
That being said, I do most of my stuff in MATLAB these days. That program rocks.
MJC
In my first job I found niether, FORTRAN nor C/C++ up to the job. But given that the FORTRAN compiler compiled in to C, I found that it was easy to write C programs that used FORTRAN subroutines. The catch being that the C wrappers I wrote for the FORTRAN subroutines were not portable in their own right as name munging and argument handling was differnt for each operating system.
However the effect was worth while, and gave me a way of dealing with legacy code (all in FORTRAN).
Mixed language programs, is an idea often forgotten, but often give the best solutions.
Very much so. I use it very regularly on old and new code. I typically use f77 primarily because I use C for all non-numeric work. This tends to make new FORTRAN functions very short and clean. Pop in, do a bit of complex arithmetic and pop back to C. As long as you don't pass strings
to FORTRAN mixing the languages is easy. On one
large (>500,000 line) system I mixed C, FORTRAN, lex and yacc.
I don't usually use FORTRAN unless I'm doing complex arithmetic unless I want to preserve the style of a larger system.
FORTRAN and C share a common trait. I can remember all the important parts of the languages standards. I doubt that anyone can make that claim about C++.
Note that if you don't do serious numerical work, there probably is no reason to use FORTRAN. My default choice is C which handles the 80% that doesn't require heavy lifting.
As for people who insist on rewriting numerical routines in the language de jour. They should get a life instead of wasting time rediscovering how hard serious numerical routines are to code.
I've extensive scientific programming with both of these languages.
The strengths of FORTRAN and Perl in scientific computing are orthogonal.
FORTRAN is perfect for number crunching - compilers are very mature, lots of numberical libs exist, the language lends itself to matrix operations, etc. That's why FORTRAN is so pervasive in physics and engineering settings. But FORTRAN is the wrong tool for text manipulation, string matching, process management, etc.
Perl is great for text manipulation, especially with pattern matching (regexps). That's why Perl is used so much in bioinformatics where the bulk of the work is munging and searching text data and connecting to DBs. But its a terribly inefficient language for large scale number crunching.
I've used Python for a numerical analysis / computational methods class (wich delt with algorithms and algorithm discovery). I found it to be very capable in handling very large and very small numbers. For example, it was able to determine 30,000! (yes that's thirty thousand factoral). It also handled extremely small decimal numbers to the precision of 10^(-600000), I didn't go any further as I did not care to test how precise Python would allow. The only problem I had was with garbage collection, when using it I did not know of any GC methods (as I was new to the language) and subsequently after a very memory intensive procedure was run (like computing 30,000!), my computer pretty much crawled along.
FORTRAN is still currently the language behind CHARMM and AMBER, two molecular force field programs in the realm of protein modelling/energetics. It's also the reason that PDB files (protein coordinate files) are the beast that they are to work with. Each column has to be in perfect alignment for when the FORTRAN parser reads them in as units for the CHARMM program.
Mordor...a magical, mythical land where women are more rare than dragons--but where every man would rather find a dragon
RATFOR was the start of structured F77, but is rather obsolete now.
F90 is ok (that's it)
HPF (High Performance FORTRAN) is not a dream, but one of the best cross-platform opensource parallel languages I have ever seen.
take a look at Adaptor
Ordo Militum Unix.
A quick search on jobserve turns up 19 current job listings requiring Fortran. Not bad for a 30+ year old language. Several satellite, stress engineering and meteorology jobs.
Working code just doesn't stop working because some new language has come out. Imagine having the job of converting 5 million lines of fortran code into visual C++ dotNet code. By the end of the week. With no errors. And no overtime... It just doesn't happen, working code doesn't need to be replaced, and thus it isn't.
I'm still surprised when recruiters ask me about my fortran and cobol skills. I don't list them as skills, because I haven't touched them in more than a decade. But the skillPimps can see I'm an old fart, and the older ones know I started my career with the old languages, because perl and C++ didn't exist in 1972. Hell, Larry Wall was still in diapers when I first touched a computer.
This goes back to the discussion, here and other places, about the difference between coders and computer scientists. Coders insist the only language they know is the only one for the job, because they are too uneducated to understand a language is just a tool. CompSci gurus will just pick up the best tool for the job, whether something ancient like fortran, or something like a procedural language or even assembler.
the AC
Hemos is like...sci-fi fans;he thinks technology is cool, but he hasn't bothered to understand the science it's based on
-1, Troll?
Hardly. Apparently, you've slept through the last half-decade of advancements in OO numerics and C++ libraries. See Blitz++, MTL, and the numerous other C++ projects listed on NETLIB.
Sorry, but there's a hell of a difference between beating a naive fortran code compiled with g77 (which sucks) and a manually tuned piece of code compiled e.g. with IBM xlf.
Most of this stuff was eventually rewritten in other languages and programming them wasn't necessarily an entirely pleasant experience but all of the above were done with Fortran 66 [often with a ratfor preprocessor], all were successful in their niches and the things in that list I used were pretty reliable. Note also that, by using the popular compiler of the day, most of these projects were also fairly portable.
There are some advantages to a sparse environment and Fortran (at least until recently) certainly qualified!
PRIMOS was a particuarly interesting case. Prime had a similar idea to Unix: They wrote it in a language accessable by their target users of scientists and engineers: Fortran IV (Later it was rewritten in PL/1 subset G).
http://www.pbm.com/~lindahl/real.programmers.html
Additionally, although tools like Matlab exist they don't provide the power that justify the huge price tag they carry.>
This is the problem of all linux users, they think that everything is free and they are killing their own industry living on the money of the stupid IPO of companies like RedHat, valinux, mandrake and others. The development of linux would never be without those company and by the governement funds.
I'm just feeling bad about this cause I would like to do software for living later and this is not on the linux side that I will can.
I'm just hoping linux will not kill the software industry.
I'm currently writing an Astronomy library in C# for an Astronomy Masters (which I'm doing entirely online incidentally). My motivation was disgust with the overuse of archaic languages in computing. For example try finding a book on orbit determination with a computer that doesn't have basic or fortran code (or sometimes pascal).
I want to write a truely extensible, object oriented library. OO programming is ideally suited to flexible scientific modelling, where everything is based on a scientific model - mostly idealized or statistically based. I narrowed the menagerie of languages down to 3 possibilites - Java, which I ruled out as too slow, C++ which does require mastery if you don't want to be chasing technical and memory management bugs, and C#. I chose C# for a number of reasons, not the least of which that this was a good pet project to learn to use it. I've written some code for numerical methods, and a few simple astronomical problems so far. C# does appear to be a good language to work in for this kind of problem. My only complaints are:
1) It's a proprietary language.
2) It's currently limited to the windows environment, and some parts of it may always be despite efforts to get past this.
3) Lack of 3D graphics support at this stage.
Advantages include:
1) A modern complete and quite powerful language.
2) Interoperability with other languages.
My feeling is that scientific computing needs to move on from the procedural era, just as most business computing has. It's not good enough to say that you're not a computer person and thereby justify your avoidance of learning the best currently available tools for a programming task. That just doesn't make sense.
That said it also makes sense to be able to read, modify/maintain and perhaps even wrap existing fortran code. I would encourage anyone who's doing scientific programming to LEARN Fortran, but not to use it in a new scientific project, unless constraints won't allow the use of an object oriented paradigm.
There is a lack of availability of freely available numerical libraries in other languages. This is a good reason to go out and develop them! Not a good reason to stay buried in archaic code. There is nothing inherent about modern OO languages that prevent them for being used for numerical processing.
Sammy
These posts express my own personal views, not those of my employer
First of all, let me say that I concur with the many others who've said that FORTRAN is alive and well. For a lot of numerical computing, it is a powerful tool.
I do not consider MATLAB a replacement for FORTRAN, rather it's a fast-feedback analysis and visualization language. For matrix math it's unsurpassed. But I totally disagree about it being inept at looping--it would be a useless language if it were.
It's been years since I've used MATLAB extensively, but I remember writing simulation of electro-mechanical systems in MATLAB that used FOR looping, conditional looping, and breaking out of loops. No disrespect meant, but I suspect that the person who asked this question has only a cursory knowledge of MATLAB, the kind you get after having one linear algebra class in college where the most advanced operation you use MATLAB for is to find the eigenvalues of a matrix. If you're a EE, then you don't really get to see what MATLAB can do until you take some advanced control systems or power systems analysis classes.
If you are after a Fortran like compiler, there is the F compiler. F is a language that is a subset of Fortran 95. The F compiler is free (check the licence, its been a while since I used it) and can be found here.
From what I remember the F language supports a large and usefull subset of the Fortran 95 language and the compiler is based on the NAG compiler, so should produce pretty reasonable code.
Don't be an idiot. You have to realize that they're probably using Fortran because that's what they learned and they're biased against all those "lesser" languages that they don't know or understand. Give it a break. I still have to argue with dinosaurs in my company that think Object Oriented programming is a fad, "Windows is a toy operating system", and "the command line is the only interface our users need". When you get older, you'll come to realize that daddy doesn't know best. In fact, when it comes to programming, the old programmers are usually wrong in assessing new technology.
I desperately need a free for noncommercial use F90 compiler. Thanks! If the license turns out to be OK for University work I'll install it throughout our lab. This will make a number of scientists very happy!
:)
So, is Fortran dead? Hardly.
--Maynard
...they don't have to use just one tool.
This idea is common sense IMO. =)
Pixels keep you awake!
OK. The argument about numerical efficiency -- I'll cave on that. But, Fortran vs. C/C++, it's got to be very close. The real issue here is about the culture of language. You can tell by my nickname that I go back aways - my first language was Fortran in the (19)60's. It was great. Back then. Then Cobol, PL/I, 20 different assembly languages, APL, Bliss, Pascal, C, C++, Perl and, finally, Java, Python, PHP. The real important differences in languages are the ways they help you to think about the problem. I have some old colleagues who still insist that Fortran is best for what they do. However, when I probe, I discover that they have many types of objects they're dealing with. If they knew an object-oriented language their code would be simpler, probably would more accurately reflect the physical model they're trying to emulate. (recall: (legend has it that) C++ was invented to simulate phone systems.) So, though Fortran may still live, it's unfortunate. Java or C++ would be better to help clarify thinking. C++ would be better for performance. C++ is better than Java because in the real world we really do have multiple inheritance.
This comment elequently points out -- from a real F developer -- why Fortran is still of such use! Buddy, even if no moderators notice your comment, this AC surely does.
Best to you,
-AC
This depends a bit on your age. If you are old enough that you know the HP calculator syntax 32S, 48G... pretty well then you basically know Forth. If you liked the HP calculator syntax you'd probably like Forth. Forth is faster than Fortran, it can be translated easily into pseudo-assembly, and thus you can take advantage of CPU firmware specific instruction sets. Forth does have a very nice style is freely available. Lots of mathematical libraries exist for it (nothing like the number for Fortran but enough so you are writing everything from scratch). It's kind of outside the mainstream but you are looking for suggestions...
In the FORTRAN world, where number-crunching is the main application and optimization is easier, compilers are expected to number-crunch correctly as delivered, or the vendor gets hell. So they do.
FORTRAN is like VI
It's blatantly out of date
But it will never die
If you look sharply enough at the FORTRAN syntax you can still see the punch card shine through. And through VI you can look at the typewriter console.
He saw some dirty arabs and fired. Too bad it was just some friendly kurds, BBC reporters and his fellow cowboys.
I've seen a lot of FORTRAN code converted to Visual BASIC. But then I've also seen companies still using FORTRAN 77 on IBM 4381 Mainframes, running DOS/VSE, go figure! FORTRAN and COBOL jockeys also tend to make some serious money for those companies running Dinosaur IBM 4381 Mainframes.
All of you who are clinging to Fortran based on the assumption that Fortran is faster (and who are afraid to research the facts because you might find out you should learn another language), do some research:
b bs2/drdobb s2.html#qcd
Blitz++ (a C++ library) vs Fortran
The benchmarks show Blitz++ beating Fortran in most cases. (Originally from Dr.Dobbs Journal)
http://osl.iu.edu/~tveldhui/papers/DrDo
4: Conclusion
After nearly a decade of being dismissed as too slow for scientific computing, C++ has caught up with Fortran and is giving it stiff competition. The combination of new library design techniques (expression templates, template metaprograms) and better compilers means that programmers can enjoy the expressiveness and ease of C++ without paying a performance price.
And if you're worried about "not being able to use the legacy fortran code", then call fortran from C.
I really like PHP. It's fun. :)
Maybe fun to play around with for a while, but it can't seriously be considered a programming language. It's a totally inconsistent mixture of C, Perl, Java and whatsoever. The API description already take >2000 pages and keeps growing like leavened dough. Security was discovered only recently and I bet there are a zillion holes still buried inside.
He saw some dirty arabs and fired. Too bad it was just some friendly kurds, BBC reporters and his fellow cowboys.
In C, for the same function, you are allowed to send it the same array twice (it's called aliasing)
As velco pointed out, ISO fixed the aliasing problem in C99. C99's 'restrict' keyword lets a developer specify in a function's prototype that no two input pointers point to the same area of memory, letting the C compiler do Fortran-esque optimizations. GCC is working toward C99 support.
Will I retire or break 10K?
Your not going to learn about the computed goto? how many other languages allow you to use an expression to evaluate to a three way branch?
How about redimensioning an array? Or even redimensioning the middle of the array away so you can use its memory for some other bit of code you need to run? Many programs would set up a huge array and then repartition it latter depending on what they were doing and it was common to load compiled code into an unused section of memory and then call it.
How about vector calculations?
The fastest machines in the world still use Fortran and ist mostly because there are standard ways of telling fortran to do vector arithmetic while newer languages depend on add on libraries.
Fortran's history is relected in most languages today as well as the archetecture of the CPUs.
A language that doesn't affect the way you think about programming, is not worth knowing. --Alan J. Perlis
Fortran offers new ways to wrap your head around some problems. That makes it worth learning.
I was forced to take Fortran 66, 77 and WATFIV (University of Waterloo Fortran) in engineering school in 1988. 14 years later and I still curse the goddamn day I walked into that classroom.
The only thing that course was good for was for some war stories:
1. Our professor, an electrical engineer, kept swearing there was no way a modem could go faster than 1200 bps. I know he meant baud, since normal copper has a hard time going over 2400 baud but to this day I still remember him. I bet he is still teaching that damn class.
2. I took this course at the University of Puerto Rico. Puerto Rico has sub tropical weather, for us 78 degrees means run and grab a frickin sweater. The very first time I saw a parka in person was in the admin console for the DEC/VAX 11/750 at the computing center. The VAX was kept in a glass-walled room at around 65 degrees Farenheith. The parka was kept by the door for when the sys admins had to walk into the room!
3. We were using DEC VT-100 terminals to access the VAX to do our homework. A couple lucky bastards got to use the VT-220 (which to us was the shiite).
4. The first time ever I connected to a computer system remotely was when we used our VAX accounts to connect to the library catalogs of the other UPR campuses in the island. We could use it to request inter-library book loans.
5. We learned to curse the students taking structured programming in Pascal. While our WATFIV programs were only a few hundred lines long, theirs were thousands! If you were unlucky enough to run a compile right after one of the WATFIV people started theirs, you could actually walk to the cafeteria a hundred yards away, get coffee, come back and still not finish the compile.
After I graduated in '92 I thought I would never see a damn VAX 11/7XX series again. 6 months later in the US Army Space Command, guess what I found: A freaking 11/780! Gimme a break!!!! We used them for simulating RF saturation of satellite communication networks. Terrible. Step too hard on the elevated floor tiles and the disk packs died on the spot. No wonder there were so many disk platters used as decorations (people would spend night shifts engraving them with all sorts of cool stuff, then hang them as cubicle art).
Fortran was a necessity back in the day, but honestly I don't see why would anyone need it now except people maintaining legacy apps. WATFIV output formats still give me the creeps after all this time.
Pedro
----
The Insomniac Coder
Well, I won't argue with that. It's nowhere near the programming language that C++ is. I like it, though, because it gets results. It's quick and painless to build a nice database-driven website with a decent visual appearance, whereas making a good-looking GUI app in C++ (or even a website using C++ :) can be an excercise in futility for inexperienced programmers.
:) Oh well, once summer's over, I'll jump off that building. :)
Anyway. I like PHP because it gets results, and because I haven't decided to take that final leap and actually learn how to program GUIs in C++.
Netlib is FORTRAN-ish, but has a significant amount of C, too. Many languages, MATLAB included, allow you to call C and FORTRAN code from their languages. So why not use the best of all these worlds? Pick your favorite language that provides you with an API to functions implemented in other languages, and use it.
I prefer MATLAB for *many* reasons, but regardless of what you pick odds are you can still mix-and-match languages to some extent. Microsoft's CLR is a big step in this direction, too, but that's a whole other thread...
-- Nabeel
One of the major reasons FORTRAN became so popular in the high performance arena was data dependecy analysis. Companies like Alliant, Convex, and SGI were building parallelizing compilers based upon Kuck's concurency analysis. In order to make things concurrent in a loop (execute in parallel), the compiler needed to make sure there was no data dependency. In example:
for (i=0 ; i<100; i++) {
a[i] = b[i] + c[i];
}
In theory, each iteration of the loop could run on a seperate thread because it is not data dependent. i.e. neither the value in b[] or c[] depend on any previous iteration. In C however, b[] and c[] could be pointers to some section of a[] . For instance, b = &(a[i-1]); . The value of b[] could be the value of a[] from the previous iteration of loop. This is nearly impossible to check for at compile time. In FORTRAN, (or more specifically, FORTRAN 77) there are no pointers. Every array is a unique block of memory. The sheer simplicity of the language makes compile time dependency analysis much more feasible.
I have been away from this area for a while, but I believe this is still a problem in C, although pragmas can allow the user to give the compiler some hints. It also seems parallelism is more explicit these days at the thread level, compile time concurrency is not as much of a hot topic. Anyway, food for thought.
I started to work for an environmental engineering lab where my boss promptly put me to work debugging her (not too old) F90 code. She told me that a lot of the non-eecs engineers stuck to learning that for simple data-sampling-and-storing models, because it was simple to learn. If anything, learn Fortran if you're faced with it (or better - learn it, so you can translate to C/C++), but otherwise, it's pointless. Especially when there's very little available today to even learn the language...
I did a bit of FORTRAN in the early 90's. IMO, its great strength is the ability to control the range and accuracy of numerical values as part of the language. No other programming language (that I know of) has comparable abilities. FORTRAN's control of numbers is analogous to the way Perl treats regular expressions as part of the language.
Sure, you can get a math library for your favorite language that provides similar ability. You can get a regular expression library for other languages that gives you Perl-like abilities. But if you have ever used Perl, you know that the regex libraries of other languages cannot provide the flexibility-- the ease of expression-- the Awesome Power-- that Perl allows with regex. So it goes with numbers in FORTRAN. If you have a fetish for numbers, FORTRAN is for you.
Yea, FORTRAN code is write-only, like Perl... such is the price of expressive-control.
You can have it good, fast, or cheap. Pick any two.
Used to use Fortran a lot, its good for crunching numbers, but the lack of OO is a big down-side its hard to write clean maintainable code. Also its hard to interface Fortran with other software. I see your point about C/C++ as error prone, especially if you're not used to it. My current preference for scientific stuff is to do it in Java and compile to native code, this allows the use of a very nice clean OO language, native code complilation can give simular performance to C code, best of both worlds. Mark
Sure, the authors NR took on a big task (I wouldn't call it mammoth, because they only skim over things like PDEs), but they weren't up to it.
The authors are scientists, not specialists in numerical computing. The appearance of "complete" does not equal accurate or correct. Writing robust and accurate numerical codes is difficult work, and there are journals dedicated to the topic.
Even their code for special functions is pretty lousy, often just taken from Abramowitz & Stegun, which is a source from the 1950s!!!
I'll freely admit that Netlib is not uniformly good; often, you have to find the most up-to-date solution to your particular problem from among the 3 or 4 solutions you find there. Also "old" does not mean "incorrect," or "untested," although it often does mean "probably inferior to some later work."
Real production-quality matrix codes, for instance, are not easy-to-read like NR. They are total mazes of special cases and tests and branches, but all of those things were put in for very good reasons, and the stuff that survives in high-quality libraries has been throughly tested and peer-reviewed. Don't expect to read a few pages of chatty prose and a couple pages of Fortran and feel totally informed. Expect it to be a black box that you can use with confidence, but inside is basically incomprehensible without careful study.
NR is a danger because it is not as good as readers think, and because it causes readers to not look any further for better solutions to their problems.
Wasn't ADA developed by the DoD for use in all DoD applications? There are still some legacy applications that use ADA, but I hope that you are right and it is dead. Can anybody who does embedded programming for DoD verify this?
Looking at ADA is painful. It looks like a language developed by a very large committee that wanted a language to do everything well. It acheives this, at the cost of being next to impossible to learn.
Network Security: It always comes down to a big guy with a gun.
Just like the adds say at the top of slashdot.
.net today.....
Try Visual Studio
The Perl Data Language (PDL), found here, gives a fast backend for scientific and matrix computing.
It is a tried and true extension to Perl that has been thoroughly abused by lots of folks.
I would say FORTRAN is the way to go for scientific computing but PDL is something to give a look.
I am an 8-year long Linux user and contribute via bug reports, etc.
I am a 30-year long FORTRAN user and am too old to
change. I have tried several different "modern" languages. I do my best documentation in Latex. But, I still resort to FORTRAN to get any real work done that requires number crunching. Also, as many have stated, there is a wealth of existing code in FORTRAN that will never be converted to another language. So until something comes along that replaces these old codes that is written in a "modern" language, then you will always have FORTRAN.
-professional engineer
Since most of my job involves maintaining Fortran code, I'm a bit biased. Most points are right: lots of old code that is very debugged by now and too much to port, compilers are well worn and dependable. Many people knock F77 for the limitations of the standard, but no one uses that, they use the common extensions (Vax and Unix) like long variable names, no case sensitivity, include files and some other items. F77 is very flexible since most compilers do F90 as well. I use Compaq Visual Fortran which uses the MS Developer Studio, so there's no lack of a modern development environment.
I have to personally give it a lot of respect since many Fortran compilers have a switch to toggle F66 syntax rules - as in 1966 - the year I was born! And Fortran was already 9 or 10 by that time.
It's like FORTRAN but it whips around character variables like buttah!
If you are using loops in MATLAB you are doing it wrong. Go back and read the manual. VECTORIZE!!! Blazing speed!
Yes, the 25 year old languages tend to be best in many ways. Fortran, Lisp, and so on...and many of the old unix utilities. Fortran dates from circa 1957 so is a bit older than 25.
The old 6 character variable limitations, lack of some structures, and some other bits tend not to exist in better Fortran compilers. However, Fortran remains the leading example of actual working shareable and reusable code. For all the hype that languages with inheritance and object orientation have, somehow they don't come close. Fortran's advantage is chiefly that its syntax closely resembles that of engineering math, though its I/O system is very easy to learn and use. The language does not have prominent pointers, but that tends to help its reliability. As for variable subscripts starting at 1, not zero, that is so, but newer compilers allow that to be changed too.
Fortran is good for a learner, in much the way that putting together a flipflop or a trigger out of discrete components is: you learn how to do things and can see how they work at low level with very little effort. Knowing how these things work can be helpful in thinking OUT of the box in solving problems later...you get a sense of the possible that eliminates the temptation to treat supporting structures as magic.
Go and learn.
... still use a simulation written in Fortran, that runs in Linux.
Why?, you might ask... Mainly because it works, and they have a realistic stable software turnover time, and this simulation has been around for over 10 years now, it actually originally ran on VAX's, then Sun's, now PC's (Linux).
VK3TST
-- "People aren't stupid. Usually." -- jd
Ok, there are lot of old dinosaur libraries out there written in Fortran. There will be people who turn their noses up because these are old and, in their perspective, klunky. These, of course, are the same people who say C++ is an elegant and powerful language ( IMNHO C++ is a fine language, only most C++ programmers suck at writing clean simple C++ code ). Anyway, having kicked sand in the face of the C++ faithful, I will now point out that it's not hard to build wrappers around the Fortran dinosaur. I guess where I'm headed with this is "learn enough fortran to read it, but probably not enough to write it." You can leverage others work, fixing it if need be, but not wasting time becoming fluent.
The cost and somewhat slower performance of Matlab and other languages designed for scientific computation is a poor reason to go running away to code Fortran instead. If you're doing anything even remotely complex, any money you save by doing things in Fortran instead of buying Matlab, RSI's IDL, Maple, Mathematica, or some other appropriate tool will be eaten up by the huge productivity losses incurred by using such a low level tool as Fortran. Reinventing the wheel is inherently expensive in terms of opportunity cost. Do yourself a big favor and spend the money on a very high level, mathematically intuitive, interactive tool that is appropriate for the job and some badass hardware to achieve the performance you need. You'll get the job done in a jiffy without major debugging headaches and be able to move on to do other more productive things with your time that will add value to the company.
I keeping reading in this thread over and over about how "large" the reusable code base is for Fortran and how reusing Fortran code is such an advantage. Then in these same posts the authors talk about how the newer versions such as Fortran 90 and 95 even have some implementation of advanced features found in newer languages.
Well, as I see it. The Fortran people are just wasting time duplicating a different, larger set of efforts. If they spent the same effort helping to optimize C/C++ compilers as they do trying to reinvent their own language then C/C++ would give them the ONE advantage they are all looking for... Numerical speed. But instead they cling to "We use it cause its faster." When that doesn't have to be the case.
I will never live for sake of another man, nor ask another man to live for mine.
WATFIV was my very first programming language. At UTA, nearly a quarter century ago, I was a freshman EE major until I took my first programming class, FORTAN. Actually we used WATFIV in the class... and on punchcards. We lowly freshmen weren't privileged enough to get to use the DECWriter interactive terminals. Anyway, FORTRAN/WATFIV ruined my life because I fell in love with programming instantly and changed my major to computer science instead. I made a D in that class, barely passing it.... because I spent my entire computer account time doing my own programming creations on the IBM mainframe instead of doing the assigned classwork :-)
If it weren't for WATFIV, I doubt I'd be in the career I'm in today.
You mention something like Matlab as an alternative if it did not have poor performance. There is a very high quality free (beer, speech) program for Windows/Linux/OSX called R that is a matrix oriented language based on the S language, whose commercial analog is S-Plus. One of the really nice features is that you can write iteration or computation heavy routines in C or Fortran and dynamically load them into your R program/script.. The benefits are that you can take advantage of the high-level nature and easy scriptability of R (not to mention publication quality graphing capabilities), while taking advantage of the speed of Fortran/C.
I am always shocked at how little attention R gets considering how good it is.
For the love of $DEITY, loose != not win!!!!!
And frankly, it is a language isssue. FORTRAN doesn't have recursion. You can't properly implement quicksort in a non-recursive language. And quicksort outperforms heapsort in most cases.
If Quicksort is the most relevant example you can think of, then I'm afraid you're not making a very strong case.
Both are O(n log n) in the best case, and I'll be extremely surprised if there's more than about a factor of two difference in running time for comparable best-case inputs. And yes, I've done the analysis.
Quicksort, however, has a nasty habit of not guaranteeing anything better than O(n^2), which can be triggered by a variety of pathological cases (admittedly less likely for large sets being sorted). What you wind up with in practice, working through the analysis assuming randomly-distributed lists, is O(log n) average-case behavior with a nastier coefficient, degrading performance to a level closer to than of heapsort.
You can use clever methods for selecting the pivot to reduce this problem, but this bites you back with the extra operations you have to perform. You don't gain a whole lot for the average case (though you make the pathological case far less likely).
In summary, the quicksort-vs-heapsort argument is a red herring.
Yes, there are problems for which recursive formulations are very elegant, but the majority of scientific problems that require brute force seem to be implemented adequately in Fortran-77. Do you have examples of important, computation-intensive problems for which the recursive formulation is far better than an iterative formulation?
More to the point, I don't believe C is a great language even though it's a great tool and it's a language.
My shot, circa 1990, at the well-known-by-now aliasing issues between FORTRAN and C.
One of many complaints I made about the unfortunate disagreements among Fortran vendors regarding how to interpret numbers in Fortran programs. (You'd think "the best scientific/numeric programming language" would have a community that agreed on how to interpret constants in code, but no.) Another post on the same topic.
An example of Fortran's distinction between subroutines and functions, a distinction not available in C (or, to my knowledge, C++).
Fortran has a strange way for functions to return their value compared to C and PL/1, illustrated by this post.
More about Fortran functions versus subroutines, including an aside about how C programmers trying to design interfaces to Fortran sometimes confuse themselves over what is really an inappropriate use of the term "function" in the C world. (I.e. it only looks like a function in terms of syntax; it's really a subroutine, that is, an imperative sequence of operations that must be performed as written.) See also this short post, unusual for me in that it's short!
Fortran actually has more intelligent character concatenation than C, at least from the linguistic point of view. The compiler actually has to understand, in some cases, that the destination can hold only so much of the source in an assignment; in C, you have to string together tons of imperative calls to library functions, which can, at least theoretically, take much longer and more memory to perform at run time.
(Though, in my experience, so few people use Fortran for "character" or string work that compiler authors don't work hard at such optimizations. But the language comes oh-so-close to providing a pretty decent character-manipulation environment in which pretty decent optimizations -- the sort C programmers must often resort to hand-coding to achieve -- can be straightforwardly implemented by the compiler.)
A theoretical rant, of sorts, regarding Fortran 90's "RESULT()", and Fortran's weird, sometimes inscrutable, means of distinguish a reference to a function itself from an invocation of that function -- a probably C doesn't quite have in that specific case, though it has its own grody areas when it comes to types, declarations, casts, and such. Another such rant.
Fortran has logical operators that C doesn't. Seriously, it's true: C doesn't have "AND" or "OR", for example. It has only a straightforward bitwise form of AND/OR and an IF/THEN/ELSE form of AND/OR, but not a more-general, compiler-can-do-what-it-wants-like-normal-people, AND/OR, which even "bare-metal" FORTRAN 77 has. The linked-to post contains one of my classic, old-style flames designed to bring this out, and is probably not the best way to understand the distinction, but, like people ruined by learning BASIC, C programmers often seem to have been ruined by thinking that "&" and "&&" contain, among them, all you ever need to express the concept "AND". (Of course, you can express C's and/or "operators" in FORTRAN, though it usually takes a bunch of extra typing. I take another crack at explaining this here, here, here, and here.)
Jim Giles and Paul Havlak try to clue me in back around 1990 when I was still trying to understand how, in practice, Fortran was easier to optimize than C for its target "audience" of numerical codes.
Stuff about named COMMON, which reminds me that while strict FORTRAN 77 doesn't offer dynamic memory allocation, that doesn't prevent a compiler from employing it under the hood, and a smart one from doing it in a way that reduces the working set (memory footprint) of the hot spots of the code -- something that is much harder for C compilers, given that the C coders have already "figured this stuff out" (perhaps for an older, differently-memory-architected machine) and hand-coded in their assumptions.
I muse over the general issue of names reserved to language libraries vis-a-vis Fortran and C.
I/O built in to the language has its advantages for portability, but unless designed with all sorts of "hooks", which FORTRAN isn't, it has disadvantages when it comes to redirecting old code's I/O through new filters without having to rewrite it substantially.
The indivisible unit of a file from Fortran's vs. C's point of view, and the assumptions made by C programmers as a result of their worldview.
On alternate ENTRY points, which FORTRAN 77 has, C doesn't, but....
A VOLATILE issue I wrote about, regarding new features in Fortran 2000.
How FORTRAN might have helped work around the lack of a universal end-of-file indicator on mainframe systems using punched cards. C programmers never had to deal with this legacy! ;-)
The subtleties of FORTRAN DO versus C "for" loops are hinted at here.
Why we should all be programming in BASIC instead (just kidding ;-).
Practice random senselessness and act kind of beautiful.
I have at least one Geology professor that uses Fortran. Although I'm completely unfamiliar with this language, it seems to serve his purposes very well. And so do the apps he writes because they still work 15+ years later. Plus, I can just get a copy of the source and use them at home on my Linux system with a minimum of fuss. Portability is a big plus in my opinion.
Smeghead every day of the week.
was almost certainly written in C. Think about this.
(P.S. To my knowledge, there has never been a FORTRAN compiler written in FORTRAN. And thank bloody god for that, I say.)
If its faster to write it in bash, then use bash. Optimise after you've got the thing producing correct results. Otherwise both C++ and Python have advanced numeric libraries that I know off.
Personally I really dislike Fortan, and the advise above comes from a project where I had to pick up some Fortan code. After a month of wasted time trying to understand someone elses code I figured it would be better to write something clearer with something I knew.
Comment removed based on user account deletion
tried Ada?
our company's software is 90% fortran77. we've
been doing it for 15 years now. recently i was
asked to check out if it's possible to use
some kind of a converter (f2c?) to convert the
whole big sh*t to c...
the fortran code is ugly, the language is
limited, and we even use c routines to do
the dynamic memory management... so don't
use fortran even it might compile to faster
binaries than anything else. it just isn't
worth it.
but because we still have those guys working
who started this whole thing and can't do
anything else than f77 we are stuck to that...
> Lots of work being done on Python between 2.0 and 2.2 . . .
then they ought to call it Python 3, so everybody gets a clue that it's a big change. Scoping is a big change.
Don't make the mistake that the sun/java people are doing - after two api-doubling releases and lots of cleanup releases, it's up to what, 1.4 I think. It's the marketing people who called it Java 2 cuz they couldn't stand it.
Marketing-driven companies end up over-marketing their products. Engineering-driven companies end up over-engineering
> If optimising fortran is so easy, why's gnu f77 such a pile of crap?
my guess, it gets much less use than the C stuff. How much of the average Linux distro is in Fortran? probly 1%. They don't even fix all the C bugs.
Marketing-driven companies end up over-marketing their products. Engineering-driven companies end up over-engineering
Fortran is still alive and well in the high energy physics (HEP) community... though it is fading away slowly (not as slowly as some people would like though). Up until very recently, FORTRAN was *THE* language for data analysis but is slowly being replaced by C++ in newer experiments such as BaBar at SLAC and is replacing FORTRAN for data analysis at a few older experiments such as H1 at DESY. The reason why FORTRAN is fading away so slowly is mainly because of CERNLIB which is a FORTRAN library that contains many useful functions (random numbers, matrix manipulation, data fitting etc...) As most particle physicists "grew up" using CERNLIB, it will be a while yet before FORTRAN well and truly disappears (in the HEP community anyway). Also of note, CERNLIB has now been released under the GPL, so anyone can use it. Nice.
>I know about Fortran 90 but it is not much
>nicer than F77,
Wether F90 is nicer than F77 or not is a matter of taste I guess, but I think it's much better. I really hate F77, while F90 is in my opinion one of the best programming languages ever. It is easy to learn, very high level, and fast.
>and no one seems to use it
???
I know lots of peaople who uses F90, no one who uses F77 for new development.
For all those people who don't seem to know just
how old FORTRAN is, it was invented in 1956.
Often functional languages have great support for doing numerical work (all of the below have free implemenations).
R, this is a free version of S a stats language developed by AT&T, built on top of a scheme interpreter. You can also build C or F77 modules an access them from R.
Haskell, lots functionality in not much code.
Scheme.
Whatever "bugs" you're chasing, fortran is not going to make you stop making those mistakes.
Switching languages once or twice would allow you to combine the practises that one compiler enforces on the other language. However, switching to fortran is not going to have that effect.
Fortran is a bit simpler than C. This allows the compiler to make more assumptions about what you're doing. This allows the compiler for example to find paralellism. A for-next loop that goes over 100 thousand elements can be split in fortran into two loops over 50 thousand elements, each of your two processors doing half the work. However, after this one loop that the compiler happened to optimize, the second CPU will become idle again until anohter optimization opportunity occurs.
Humans are much better at finding parallelism than compilers. Thus if an optimizing compiler can find 50% "things to do" for a second CPU you should be able to find almost 100%.
Thus if you have an OLD, debugged, program that you want to run on the new parallel machine, a fortran compiler can boost your performance better than a C compiler. But you shouldn't learn fortran just because it's often used in high perofrmance computing. It's just that those guys happen to have large patches of code lying around, they have the fortrna experience, and lack the incentive to learn anything else.
Roger.
I perused the whole listing and no IMSL references?
This library was fantastic for quickly developing filters and analyzing data and waveforms, performing matrix inversion, reduction, Karhunen-loeve, etc. This was what made Fortran so simple and powerful.
Visual Numerics (www.vni.com) purchased them and now has JNL, and CNL, a subset of netlib. I used PV-Wave (also vni) years ago (VAX, military days) and it was a nice, tight package, similar to Matlab
...but to do it you have to use EQUIVALENCE statements.
ROOT is another option for visualisation (along with Octave and GNUPLOT). Interestingly, the ROOT system also includes a C++ interpreter (yes, interpreter!).
"C/C++ does not cut it for me - it is simply too easy to make mistakes and I find myself using half of my time hunting bugs unrelated to the problem at hand."
If you know the language, you might maybe write code that isn't full of simple code related bugs. If you want simple, go with Visual Basic...
OTOH, if you've never seen F90/95, then you're in for a shock. At first glance, F90 is extremely C-like. To zeroth order, it looks exactly like C and has all the different types of looping, pointer and conditional operations that a C programmer uses. In fact, Fortran has more (as opposed to FORTRAN).
F90 is a much better language for someone who wants to get things done without having to worry about issues like 4/9 being equal to 0. The array semantics just *beg* to be used in finite discretizations. Imagine being able to declare an array that starts from -100 and ends at +100. Wonderful!
That being said, I don't use F90, just because I'm so comfortable with C and more people are using C these days. However, if I were to learn a new language and didn't care what other people use, F90 would be my language of choice.
Forget what you know about FORTRAN. Fortran is a language made in heaven.
Peter
Actually, the the best tool we have for heavy duty computing is a forty-seven year old language which, among other things, handles arbitrary size and arbitrary precision numbers transparently, handles memory allocation automatically, handles recursive functions naturally as a key part of the language. As for efficiency, I can code factorial in three lines (70 bytes) of code, and compute the factorial of 10000 in 2.08 seconds:
* (defun fact (n)(cond ((= n 1) 1)
(t (* n (fact (- n 1))))))
FACT
* (time (progn (fact 10000) nil))
Evaluation took:
2.08 seconds of real time
1.91 seconds of user run time
0.16 seconds of system run time
[Run times include 1.66 seconds GC run time]
0 page faults and
70756080 bytes consed.
NIL
*
Beat that in any language. Note: only core features of the language used, no special libraries, no special constructs. Note also: I didn't declare n as an integer, I didn't have to. I didn't declare n a bignum, I din't have to. The language handles all that sort of detail automatically, and if I wanted the imaginary part of the factorial of 1000 all I'd have to do is ask for (imagpart (fact 1000)). Not only are complex numbers supported in the core language, they're supported transparently too.
People get put off by the fact that LISP looks different and has a slightly different vocabulary from the ALGOL-derived languages they're used to. Once you're over the initial hurdles it's a very natural and extremely powerful language to use.
I'm old enough to remember when discussions on Slashdot were well informed.
I worked as a SysAdmin and programmer at the University of Connectuicut's Optical Fiber Research Manufacturing Labratory for two years. Our graduate students, some of which were programmers, wrote their numerical models exclusively in F77. Our reasons were:
* The base model had been written in F77 and the majority of relevant literature was also written for F77
* Easily understood by other researchers; increased chances of getting published
* Trivial to port and run on a Cray, Sun Workstation, or a Linux cluster [which we had].
* Variety of parallel programming packages available: HPF, MPI, PVM
* The professor said it was The Way To Do It.
I personally spent almost a year writing F77 code with PVM. While F77 had some unpleasant limitations which have already been covered, I was glad to have the experience.
We used The Portland Group's compilers exclusively, and my benchmarks against g77 showed significant preformance gain.
As part of my continuing work with the lab I am developing a parallel version of an extremely long [5 days on a dual AMD 1900+ !] and CPU-intensive algorithm, using MPI and F77. I have no doubt that F77 and F90 will be around and it use for a long time.
Joshua Thomas
formerly University of Connecicut
email: jthomas at poweronemedia dot com
What's the advantage gained by the hand-coded stack approach? Smaller stack frame, you say? Why does that affect execution speed in this context?
A smaller stack frame gives your code a better chance of running correctly on an embedded system whose processor architecture specifies a 256 byte stack, such as anything based on a 6502 processor. I've had to program for one of those (the NES). Heck, I've had to program on one of those (the Apple IIe).
Will I retire or break 10K?
http://www.goatse.cx
I worked for a while at a physics department in a University. They used IDL almost exclusively for number-crunching - especially the atmospheric physics guys. Apparently you could write code rather quickly and easily and it had excellent graphics capabilities. Check out Research Systems Inc.. Mind you it costs a stack. We got it cheaper coz we were a Uni but it still cost heaps.
We had some Matlab around which the theoretical guys used more but IDL was the most prevalent.
Why would anyone want to use a text editor that is not vi?
http://gri.sourceforge.net
Doesn't do 3-D, but very good on 2-D (including contours and colour-coded images).
ForTran (aka ForTran) had its place in the history of this discipline. It bothers me personnaly to see so many negative comments from so many that should know better. C may be older than F'77 but it is young compared to Fortran. In its age ForTran was used as a replacement for assembly language and found its way into use for writing almost every type of application imaginable: scientific codes, numeric codes, compilers, operating systems, system utilities, etc. The language is very old, and to trace it only to F'77 does not do it justice. For some of us, the introduction of F'77 was heresy, and we continued to code in F'66. But even F'66 was not the first standard ForTran. I remember coding in Fortran II, III and IV. Coding by the rules almost guarunteed portability. Many widely distributed (free) numeric codes were written independent of word length: 32, 36, 48, 60, 64 bit lengths were all supported. But there were a few quirky implementations that required non-standard statements to be added. Should one learn ForTran? Should one learn about history? If your interest is numeric or scientific computing than one should develop at least a reading knowledge of the language. As many have pointed out, there is a wealth of very good codes that exist written in ForTran. If it is your goal to re-invent the wheel, then ignore ForTran, if you want to leverage on top of the work of others, then learn the language. It is fortunate that the languages in common use have progressed beyond ForTran -- but they are far from problem free. But the capability of our computers has far surpassed the systems on which ForTran was developed. [the first computer I programmed was an IBM 1620 with 20,000 digits of core memory, no disk, and a purely hollerith card based system -- try running your C programs on that beast]. So keep it in perspective. Use the tools that are most appropriate for the job at hand.
I try to learn as many programming languages as possible. While programming languages such as FORTRAN, Common Lisp, and even COBOL are indeed very old, there are many implementations both commercial and non-commercial being actively maintained and used. Even if I find that the language doesn't provide the tools I need, as is the case with FORTRAN and COBOL, the process of exercising my mind through learning has made me a better computer scientist.
I'm proud of my Northern Tibetian Heritage
I was thinking of gnuplot which is almost always used with Octave but which, despite the "gnu" in the name, is not associated with the GNU project or the FSF and is not GPL'd.
You are absolutely correct, Octave is GPL'd. My most sincere apologies to the Octave team for my inadvertent slander.
I don't think there's any point in learning FORTRAN in the absense of any explicit necessity of doing so, right now. Not when you could spend your time on something more didactically recommendable.
Delay learning FORTRAN until you find an actual need for it --- the language is simple enough to learn it in a couple of days as the need arises, provided you already now how to code in any other, less outdated language. If the need to learn FORTRAN never arises at all, consider yourself a lucky guy.
This sounds like you are realizing just how complex Programming can be. Unless you work at understanding how to program partial solutions, your frustration will only festor, more.
1) Fortran is fine, especially f90. It's as though you think there must be something wrong with a language that has stood the test of time. Fortran and lisp both are still impressive designs.
2) It sounds to me like you didn't give numeric python a real chance. If you think it won't do loops and recursion well, you really ought to take another look.
The Golub/Van Loan book is certainly the best text on linear algebra I have ever seen. However, LINPACK has more or less been obsoleted by LAPACK (which is based on LINPACK). The main difference is that a lot of code has been rewritten to use level 3 BLAS in the inner loops, which will speed up things quite a lot.
sig intentionally left blank
Libraries of existing code, particularly for scientific computing, are a huge incentive to switching. As long as you don't need to create a GUI for the application, or do bit level manipulation, or do extensive string parsing, FORTRAN and the existing libraries will probably suite you well.
And the more languages you learn, the better programmer you will be in all of these languages. You will also start to view languages as tools - selecting the proper one for the job at hand - rather than trying to do everything in one language.
I have written code for a variety of applications. And I've developed a repetoire of languages (Python, C/C++, FORTRAN) that covers most of the bases of what I need to do. But programming is easier if you don't think of yourself as a "FORTRAN Programmer", but rather as someone who looks at a problem and says "I can program a solution to that. It would make the most sense to program it in X.
It's not wasting time, I'm educating myself.
FYI, of all the models, "Eta" is not an acronym but is named for the Greek letter parameter that it included as it's breakthrough. So like modern Perl (which has disavoweed both retronums), it's spelled leading-cap and not full-cap.
(Since I'm still only reprocessing sounding files from the models, I'm using Perl. Not sure if I'll be able to use PDL or C++ when I make the leap to GRIB files, might have to get a Fortran.)
-- I'm Pedantic, not Pompous; there's a difference!
Q. What will scientific programming look like in 2020?
/not/ named Lisp.)
.sig is backed up on tape somewhere.
A. I don't know, but it will be called Fortran '05.
(I heard this joke first as my Government IT shop was slowly preparing to adopt F77 in 1981; as told then it was right on target, in 2001 they probably were using F90 as predicted.)
(Same jokes works for Business DP and Cobol; we're looking at porting legacy VMS Cobol to MicroFocus on AIX to consolidate platforms. Joke used to work for A.I. and Lisp, but Common Lisp has been subsumed by its leading dialect Scheme, which is
-- My
I just tried to transfer my 10 year old DP AAS Degree to a State College. They claim that my FORTRAN class will not transfer because they do not teach FORTRAN there anymore. I checked with other local colleges and got the same response.
Oh yeah they also won't take my:
Pascal, Ada, 8086 Assembly, C Language, or DOS/VSE JCL classes. What a bummer, eh? Looks like I'll be taking Intro to Programming over using C++ instead?
In ten years time, your computer college courses will be obsolite. Three years and they already have a better version of the language or technology to learn. Ten years and it is practially useless and non-transferable. Sucks, don't it? Same thing does not happen to Math, English, Music, History, Business, Nursing, or Communication Majors.
I'm very sceptical of the claim that FORTRAN is superior in speed to C/C++ on a modern CPU. The reason is that CPU's are optimised to suite the most prevelent programming languages. With the vast proportion of all recent software packages being written in C or C++, surely the Intel's and AMD's of this world are optimising their CPU's instruction sets to run C or C++ - and not something like FORTRAN.
www.sjbaker.org
I've also done Fortran - easy to learn, a few really ugly contructs like array overlaps, lousy I/O and character handling, funky bug opportunities in call-by-reference, but f77 and newer versions could interact well enough with C, so you could do the complicated parts in C and hand off any big array-crynching jobs to Fortran subroutines.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Now I've found the perfect language to write my next really cool art installation in!
*eyes gleam with the possibilities*
You wouldn't program a website in C++ anyway, would you? And that's the only domain where PHP is of some use.
As a beginners programming language for standalone apps I would rather recommend Java than C++ because it's easier to use and safer in the sense that those features most frequently leading to programming errors in C/C++ aren't available in Java.
He saw some dirty arabs and fired. Too bad it was just some friendly kurds, BBC reporters and his fellow cowboys.
Actually, I did once use C++ to make a little tool for my webserver. It would allow me to use the web to stop and restart some services (MUSCLE, mainly). Worked great ... but I suspect it would've been easier to code in PHP :)
C/C++ is by no means a difficult language all by itself (without any extensions), and I don't see how any programmer who's worth anything can write C code and then spend hours trying to fix syntax errors. That's just stupid! When writing programs the only errors I tend to make are logic errors, and those, unlike syntax errors, are not language specific. If you don't know the right way to write your program you will be making the same bug whether it is C/C++ or FORTRAN. FORTRAN is a dead language! I discourage anyone in thier right mind from learning when they could better spend thier time learning something more useful like C, Java, Perl, Python, etc etc. Of course, if you get a job having to maintain/port legacy code originally written in FORTRAN then by all means learn it! As long as you have a use for it. :)
Of course, you can't implement quicksort properly in FORTRAN because the language isn't recursive!
Actually, most any "nonrecursive" language can implement recursion using a stack. I've never bothered to do it in Fortran, but I translated a Turbo Pascal recursive maze algorithm to C= 64 Basic doing exactly that.
The thing that keeps getting missed is that the available base of Fortran programs were written by domain experts in the various physical sciences. And once you've written a several thousand line program that takes an expert of exceptional understanding to write, are you going to let Joe the Contractor or Fred the Grad Student rewrite it in C++/Java/Lisp/etc and break the code because he does something to the code he thinks is a good idea, but doesn't really work?
Well, Fred the Grad Student is almost a disposable part, so maybe you let him futz on it a year or two, but in general, a scientist doesn't get many kudos spending several months to a year rewriting code that already works. He would be better off publishing science, rather than catering to the current fashion in languages.
Gray
In the high energy experiment I'm working on at th e moment we use two languages: Fortran 77 and Perl. Perl glues together the conglomeration of Linux machines, Suns, DECs, and even a Cray in various parts of the country to manage the 120TB (yes, terabyte) data set. Fortran does all the number crunching (and since the runtimes of these programs are measured in hours, and a run through a part of the data might be a matter of a week even on a hundred machines this is a big point...the freedom of C translates into easier errors, whereas Fortran usually just chokes at compile time).
However, the other reason it's still all Fortran is CERNlib. This takes care of histograms, dynamic data structures, user interface, the works. There are some folks trying to make a C++ version called ROOT. There are experiments trying to switch over to it. It's been a nightmare.
Interestingly, the next experiment is supposed to use gtk+ for our interfaces. This makes me wonder if we're going to C, which surprises me. On the other hand, C was my first programming language.
Someone above mentioned Pascal. Forget Pascal. It's dead, and thank god! We recount to each other the horrors of that language in my lab: some folks at CERN were really pushing it about fifteen or twenty years ago.
Most physicists have never heard of BNF notation. The computer is simply the last part of an electronic apparatus. Its role is fairly simple; the data structures are usually fairly straightforward. Many physics students learn electronics before they learn programming, and the computer remains only a piece of their approach.
On the other hand, I know a nuclear theorist who does all his programming in Forth. His gripe recently is that math coprocessors on x86 machines have less precision than the ones he had on a punch card machine in the early '80s. It's not much better elsewhere: an astrophysicist I know is ever cursing his UltraSPARC's limited precision in his simulations. The moral: the language doesn't matter. It's only an interface to the hardware, and it's more pleasant to write Fortran than assembly.
Has anyone like him written a "something-other-than-Java-language" compiler for JavaVM? I'm interested in compiling (or building a compiler for) legacy code for JavaVM (an environment that is now the lingua-franca of the computing world).