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!
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
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
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).
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!
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
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***
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.
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.
Common Lisp is a very high level language with a tremendous amount of expressiveness, and it is suited towards academia in that in general, functionality is not sacrificed for performance.
Check out http://www.lisp.org, http://cmucl.cons.org/cmucl for a really good implementation (and there are even Debian packages of it).
CL is not known for its parallelization abilities, but if you need a language that lets you describe mathematics, CL is useful.
Lisp is actually based around something called the Lambda Calculus, which is a way of expressing concepts by transforming data into other data using data which is expressed as a "function". Because of this, Lisp has a lot of abilities that other languages lack, such as extremely simple and powerful function composition, even at run-time. CL also has a massive core library with OO facilities, basic mathematic primitives, good FFT suppot in most implementations, windowing system support, and good commercial vendors like Franz. Check it out; it's almost as old as Fortran, but has evolved in a much more elegant manner.
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
It will export your script as C.
-... ---
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?"
I'm a big fan of Lisp... The ability to declare as much or as little as you want about your data types is very nice... And it has the greatest macros of any language I've ever used... Once you get used to the Lisp macro functionality, you will cry when the most you can do is a #define in C...
When programming in Fortran or C its important to remember Greenspun's Tenth Rule of Programming: "Any sufficient complicated C or Fortran program contains an ad-hoc, informally specified, bug-ridden, slow implementation of half of Common Lisp"
My Stuff: pspChess and foobar2000 plugins
Because you haven't experienced danger until your run 100+ user production databases on legacy hardware. Suppose I'll go make it safe for another day:
TAPE OPER RES MKC500
INIT MKC500 TAP007
TAPE OPER AVAIL MKC500
*sob*....
Finally, math books without any of that base 6 crap in them.
You can use CORBA, or XML to communicate between your Fortran application, and any other code that you may write. That way, you can get the best of both worlds. I wouldn't give up so fast on C++/Java though. Investigate those languages more thoroughly before you decide to code in Fortran.
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
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?
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
...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.
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.
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
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/
Learning a new language isn't going to help you avoid debugging
Right but his point was that with C/C++ he spends a lot of time dealing with programming issues unrelated to solving his problem. This is a common occurance in C/C++. In C the most obvious example that is near and dear to everyones heart is string handling. It's easy to introduce many bugs into an app that does even simple string manipulation. Vs say a language like VB, where the string handling is fairly straight forward, so you can spend your time dealing with many of the other shortcomings of the language, oops, I meant to say solving your problem.
If the man wants to do math and not have to worry about memory mangement and pointer arithmitic, then moving to a language like Fortran is not necessarily a bad way to go. He shouldn't get caught up in the age (after all, C aint no spring chicken either). If it's still around and being used, then it probably does the job well (don't know a lick of Fortran so I can't say personally).
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.
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!!
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!
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.
Check out Sisal.
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 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!
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."
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...
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
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.
I want to second the advice to parcel your project out into different languages. You would be a masochist to do your I/O routines in FORTRAN (file numbers, anyone?). But try, for example, finding decent optimization algorithms, linear algebra routines (Cholesky decomposition, etc.), and other serious code in C. [Num. Recipes, BTW, is not serious]
Sure, there are CBLAS and CLAPACK -- both hideous automatic translations of the FORTRAN code!
So in addition writing to your own code, you'll be able to scrounge *and adapt* useful routines from the literature.
I agree completely- Matlab is the bomb, and if you have to use loops in a Matlab program, you're a twit- it's a MATRIX based language. Use the matrices.
After having taken yale's cs 201 and taught it twice...i have developed an intense love-hate relationship with scheme -- suffice it to say, it does _NOT_ solve the problem in the orig. post.
When in doubt, parenthesize. At the very least it will let some poor schmuck bounce on the % key in vi. (Larry Wall)
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/
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?
That was exactly my point. If you live in, or plan to ever live in Legacy Land, then by all means learn it. There are still plenty of positions and demand for people who know and can debug/edit commentless arcane legacy code. I don't know how many positions I ran across that were looking for MVS experience!
Wu-Tang Name: Half-Cut Skeleton Get your own Wu-Na
"A computer without COBOL and Fortran is like a piece of chocolate cake without ketchup and mustard."
Slashdot's first reaction to VMware
Nope, being flamebait is saying that Slashdot is full of wusses who don't like being told that they're stupid.
The middle mind speaks!
There are two reasons why fortran generally outperforms c...
1) Language differences: when you use pointers in c it is always difficult and sometimes impossible for a compiler to know in advance what you are doing, and thus can't necessarily optimize it. Fortran also has constructs which are easily vectorized and parallelized, taking better advantage of the hardware.
2) the fortran compilers on most platforms are more mature, and the optimizing algorithms for fortran are well documented and have been studied for longer.
Doug
Venn ist das nurnstuck git und Slotermeyer? Ya! Beigerhund das oder die Flipperwaldt gersput!
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.
... 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
Just curious, does all your knowledge about programming languages date from 1975, or just your prejudices about Lisp? Lisp has had arrays since about then, those arrays have the same O(1) access time as anyone else's arrays, and the performance of code using them is tuneable to FORTRAN speed or better. Whoever taught your "survey of programming languages" course did you a real disservice - maybe you should get them brought up on educational malpractice charges.
That said, FORTRAN can probabaly outrun Lisp on supercomputers, because of the effort put into parallel and vector optimizations on those platforms. I love Lisp, it's my preferred hacking environment, but I wouldn't propose it as the language of choice for big numerical applications unless there was a chance that hairy data structures might improve performance.
To a Lisp hacker, XML is S-expressions in drag.
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?
I'm a physics student working for an experimental physicist. He uses FORTRAN, so I use FORTRAN (only when I can't avoid it). You are right. Pythia (google search the word, and feel lucky) is a great program for simulating High Energy particle collisions (I'm doing Tevatron simulations in the background as I type), but since it was started a couple of decades ago, it's written in FORTRAN. They're trying to convert to C/C++ (can't remember which), but it's a multi-year project for code that's already written. They've put it off for so long because the FORTRAN code works just fine (for the most part). There are some memory considerations and interface issues that make them want to switch over.
It will be nice when the finaly do.
Don't Bogart the fish sticks
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.)
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.
A caveat about Common Lisp:
...) that allow you to write code to traverse arrays in very convenient ways.
it has a lot of good things that are similar to Fortran in the numerical world.
* Integers are not a fixed width, but transparently go to multiple precision instead of wrapping around.
* All of the intrinsics deal with complex numbers transparently.
* True rational numbers: i.e. ratios of integers.
* (Better than Fortran): STANDARDIZED parameters to describe the floating point parameters of the machine (e.g. machine epsilon). Also, built-in, portable access to the floating-point encoding in bit form. Very nice bit-bashing intrinsics (I like them better than C).
* Very flexible arrays. Some nice intrinsics (row-major-aref
* Notation is pretty flexible: can add multiple numbers together using (+ a b c d e f g).
* Lisp macros are amazing. The whole power of the Lisp language is available as a "preprocessor." You can relatively easily write programs that write programs that write programs. As an example, although Lisp has built-in, kick-ass OO (CLOS), you could write your own transparent object-oriented extension to Lisp (i.e., roughly equivalent to what cfront did for C) in about 200 lines of Lisp macros, and it works as well as if it were built-in.
Some slight "disadvantages"
* Prefix notation is the default. Add-on macro packages let you also write code that is infix
(e.g. #I instead (+ (expt a 2) (expt b 2) (expt c 2)))
but it is not a built-in standard.
* The standard does not *mandate* the ability to specify extremely large arrays. Not necessarily a real problem unless you want > 1 GB arrays on a typical 32-bit implementation.
* The notation is sort of verbose. Array references go like (aref array-variable i j k l). This is just notation, so the compiler should optimize this if you ask for it.
* Variables are not typed. The way around this is declarations. Again, the notation is somewhat verbose. (the double-float (+ (the double-float x) (the double-float y)) or (declare (double-float x y) (+ x y)). Again, this is just notation, so you can "easily" write lisp macros to write either of these as something like (d+ x y)
* Most high-performance computers have high-quality Fortran compilers. Fewer have high-quality architecture-specific Lisp compilers. Likewise for highly-multiprocessor machines.
* Most importantly, the bias in the Lisp world has been to optimize things like OO method calls, function calls, recursive function calls, automatic garbage collection. Not much pressure to optimize number-cruching on large arrays. Fortran compiler writers for the last 40 years have been asked to do one thing: optimize number-crunching on large arrays.
That said, for certain numerical codes, Lisp is a nicer tool than Fortran. For some other numerical codes, a good Lisp compiler (which might not be available for your architecture) given code with sufficient declarations could match a Fortran compiler for code speed, no more than 10% performance loss, sometimes performance gain. For some codes, Fortran is going to win big in execution time.
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?
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
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 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
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.
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...
oops, here is the right link
MARIJUANA, SHROOMS, X: ONLINE?! - E
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...
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
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
>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
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.
wrong.
f90 does have dynamic memory allocation.
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
http://www.pbm.com/~lindahl/real.programmers.html
The poster wasn't concerned with speed as much as with having the right tools in which to program his application. He does not specify how long these mathematical operations take, but if we assume that they are complex and take at least 10 seconds, or maybe minutes or hours to complete, then the overhead of making a CORBA call isn't going to be a big deal. If his calculations take only a second or two, then the language that he uses is hardly going to matter for speed. He can just get a faster box.
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.
For having used it (although only in CLI apps) a few years ago (1999-2000), I really really hated working with it. The compiler itself was Digital's, and it caused me and one of my colleagues quite a lot of problems.
For starters, the optimized version didn't run correctly, but would report that variables weren't declared (implicit declaration triggered a warning). So we had 3 versions: Debug, Release (optimized, but actually used for debugging), and Release-real (not optimized, but doing the right calculations).
Then, the linker had some problems once in a while, when it replaced the content of some object files/functions by memory filled with 0. Of course, when you ran into that code, the EIP register would, in time, point to some unallocated memory, and a SIGSEV (or whatever is the equivalent on Windows) would be sent. That problem was very visible in the debugger. The solution? Just recompile the whole thing, and you'd have something sane again. No source file needed to be modified. And I thought that compilers were deterministic...
Other than that, just make sure you know the language (especially when working with 20+ years old code): IF(CONDITION)10,20,30 is completely legal, as well as not declaring all your variables.
Back to my own experience, instead of making the GUI in Visual Fortran, it was a separate app in VB. I won't enter the details of what we needed to do to communicate between the two.
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.
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 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.
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.
Fortran having a goto isn't the problem, the
problem is in fortran you have to use it, because
you have got loop altering constructs like break and continue, or basic switches.
Fortrans other, problem is that its lack of
pointers or references, makes it very hard to
do simple datastructs like linked lists, or
trees without resorting to ugle and wasteful
int arrays of look up values into other arrays.
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.
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!
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?
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.
What do you think of C++, then? Almost every feature maps one to one between C++ and Ada, except for threading, which Ada has and C++ doesn't, and various knobs and dials on templates and object orientation (template specialization, multiple inheritance) which C++ has and Ada doesn't. Furthermore, Ada doesn't have redundant funtions, like struct and class, or multiple ways to cast a value.
Ada's not dead. There is considerable amount of embedded programming done in it, and some hobbist interest. Personally, I got tired of programming in a language where the first time I ran any program, its output consisted soley of "Segmentation fault". Most those programs, written in Ada, wouldn't pass the compiler; the other half would at least give me an exception with a line number for the problem.
Comment removed based on user account deletion
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.
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.
...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...
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 apologize for my tone, but this kind of misinformation is understandably a sore point with Lisp people. Paul Graham's On Lisp is a great book for explaining modern Lisp style, as well as dispelling Lisp myths. The dead trees version is out-of-print, but the ps/pdf versions are available for download. Also check out his Articles page.
To a Lisp hacker, XML is S-expressions in drag.
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.
Dang, it's old, and so am I!
:-b
Pfft. They also have a Commodore 64. Ask me how depressed I was when I saw that.
> Looking at ADA is painful.
Much of beauty is in the eye of the beholder. I think Ada [sic] is much easier on the eyes than most of the other languages that are popular this week.
> It looks like a language developed by a very large committee
It was in fact designed by a team as part of a language-design competition. Is design by a team, or even a committee, a bad thing? I prefer to look at the resulting design rather than at the number of people involved. When I go shopping for a new car I don't give the least thought to how many people may have had a finger in the pie.
> that wanted a language to do everything well.
Sounds to me like a reasonable thing to want.
> It acheives this, at the cost of being next to impossible to learn.
Actually, it's really easy to learn because you only need to learn a small subset of it before you can start writing "real" programs. Then you can add knowledge (and use) of the sophisto stuff as you get more comfortable with it. (I would guess that 10% of the language does 90% of the work.)
Just my experience. I think the biggest issue when evaluating new languages is the "not what I'm used to" effect.
Sheesh, evil *and* a jerk. -- Jade
Don't give up on the code.
.net (because he could) that outputs C# code. He also wrote a .Net compiler for brainf*ck (because he could). He basically views it all as source code transformations, and while I agree with him at a conceptual level, I do not have the patience nor his expertice at writing such code to make any recommendations to him. The guy can write a parser for a language faster than anyone I've ever met. And he's an undergraduate.
You may want to look for some hard core CS students to hire. I have a student who wrote a reverse compiler for microsoft
Network Security: It always comes down to a big guy with a gun.
> The argument that you can learn a small subset to be productive tends to bite you when you start trying to ramp up to multi-developer projects.
Presumably anyone iterested in learning the language will go ahead and learn the rest of it, or at least most of it, after mastering the subset. My point was simply that you can bootstrap yourself into an admittedly "big" language by learning an easy Pascal-like subset, and then start mastering the additional features as time and motivation allow. The ability to learn a simple subset greatly reduces the frustration it would present you otherwise.
No one wants to learn a language that requires you to read a thick book before writing your first Hello World program, but if you can master Hello World at your first sitting, and write at least some types of useful programs after a few days of playing with it, and then learn the more exotic properties of the language later, then even a big language will not scare you off.
Sheesh, evil *and* a jerk. -- Jade
Should I learn FORTRAN?
Should I use FORTRAN?
Different questions, and not as related as one might think.
From long ago, an observation that it is better to learn Pascal and use FORTRAN. Learning FORTRAN and using Pascal doesn't work.
FORTRAN (I'm thinking FORTRAN-IV (1966 standard, I think)) is in some sense an optimal substitute for raw machine language. It can be very machine/architecture independent. There are things expressible in the language which would be better if they were illegal, but that would break the language. With Fortran77 they had an opportunity to make it a programming language. Instead they left it Fortran. I'd be surprised if Fortran90 were any different. If I had to use Fortan, I'd tend to stick to the basics and not victimize myself into thinking the language would take care of me.
If the validity of your results is important, and you are willing to pay the price, Ada should be a good choice. There's stuff in Ada that turns "semantic" errors into "syntactic" errors. This is to avoid cases where a program can give correct results on one architecture and wrong results on a different architecture.
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
> Excuse me, but why the "[sic]"? It actually is Ada. It is not ADA.
That's why I used "[sic]". I was responding to someone who used "ADA", and I wanted to indicate that my change to "Ada" was deliberate.
> And it is a wonderful language, despite all the "designed by committee" crap floating around, posted by people who have never programmed with it.
Such as ESR.
Yes, I agree that it's a wonderful language. I use it for almost everything I do, when the choice is up to me.
Sheesh, evil *and* a jerk. -- Jade