Mike Croucher writes "Despite the fact that it is over 40 years old, Fortran is still taught at many Universities to students of Physics, Chemistry, Engineering and more as their first ever formal introduction to programming. According to this article that shouldn't be happening anymore, since there are much better alternatives, such as Python, that would serve a physical science undergraduate much better. There may come a time in some researchers' lives where they need Fortran, but this time isn't in 'programming for chemists 101.' What do people in the Slashdot community think?"
Nah, make them learn VB6, if for no other reason for enjoying the screams of horror from 'real" programmers when they come across some VB6 app. Take that, real programmers! For extra evil teach them GOTO. I've found watching the facial ticks and foam build up around the mouth from real programmers when they encounter a GOTO to be quite entertaining!
Well, I'll tell you like my former VB teacher told me, funnily enough after some kid tried to steal my code and pass it off as his own. After Mike(my teacher) got done laughing his ass off he told the kid "BTW you are getting an F for stealing from Kevin". "How do you know that he didn't steal it from me?" Again after Mike got done laughing his ass off he projected the code onto the board and said to the class "Do you notice anything a little odd about this code?" And one said "It has numbers in front of all the lines...and what is a GOTO?"
And Mike said "How old are you Shawn?" and after the kid said 19 he said "And THAT class is why I know Shawn stole this code from Kevin. He turned to me and said "You're what? 35?" and when I confirmed he said "You see class, in the days before PCs became standard with pretty desktops like you have now, all the machines ran BASIC. The numbering and the use of GOTO to call a sub is a classic tell that the person who wrote this cut his teeth on one of the old BASIC computers." He tilted his head and said "Commodore or Atari?" and I sat there with my mouth gaping and said "Commodore VIC20. How did you know that?" he said "Because your code is classic Commodore and Atari style. Very efficient but as subtle as a chainsaw."
After some of the kids started coping pieces of my code and trying to use GOTO and crashing all over the place Mike explained it to me like this-"To an old greybeard like you or me, that actually understands what the code is doing a GOTO can be a quick and efficient way to get something done quick. Subtle as a chainsaw, but it gets the job done. But you give it to these kids, that don't really understand what they are trying to accomplish or understand how the codes works in the machine? It is like handing a monkey a sledgehammer and letting him loose in a room full of bombs. He is gonna blow something up, the only question is when."
So if you want to know why teachers like Mike would cringe when they saw a GOTO, it is because it works fine IF you know what you are doing and how the code will be processed. But with so many learning code the VS way, with everything drag and drop, for many of those GOTO will simply blow up in their faces. Better just to not let them know it exists in the first place.
Evidently, you don't go out that much. People use interpreted languages in science all the time. At least I do. Where I sit, there is quite a bit of spare capacity waiting. When I try to figure something out it is way more reasonable to write a program in three-four hours and have it run overnight than to write it in two days and have it run in (say) thirty minutes.
Python? As an intro language? And I thought people were misguided teaching Java as the first (and often only) language.
Second, while some of these scientific programs can run overnight, a lot of them will take a day or more to run, even when compiled and on a super or parallel computer. I don't know of any highly optimized Python compilers for big metal. Fortran is still the number one language for performance computing.
Third, there seriously needs to be major scientific libraries pre-existing for the language to be useful. An added benefit is being able to support more than one floating point number format.
Finally, the number one most important reason that Fortran is used in the sciences, is because everyone else uses it in the field. Seriously, what good is Python if all your prof's and advisor's and boss's programs that you need to maintain are in Fortran 66? It's faster to learn Fortran than to port it all. This is part of the "dusty deck" problem, where decades old libraries still have to be used and supported. This applies to many languages - many languages are popular precisely because they are popular, not because of inherent elegance or suitability.
In the sciences, the students are not being taught programming for the sake of programming, and they're not even being taught to write good programs necessarily. They're being taught to program as a mere tool for the important stuff being taught. Some classes may not even care what language you use, as long as you can read and understand the sample programs and the math library is correct.
Being in the sciences and not knowing Fortran will be a drawback. In some areas it may not be as big a drawback, but it will be there. This is like trying to do embedded systems without knowing C.
I think you are mistaken regarding what most undergraduate science students actually do (they are not maintaining/upgrading old fortran libraries). Most of the high performance capability that undergrads need involves matrix computations, FFTs, convolution, etc., all of which are included in the python numpy/Numeric module (which is a wrapper around fortran libraries, so they're just as efficient). And since they'll likely spend as much time analyzing data as producing it, python + numpy + matplotlib is a perfectly suitable solution.
I'm not suggesting that fortran isn't of value to some scientists in some situations but many science students will never have to touch fortran code unless they're forced to take a class that teaches it. As you said: "They're being taught to program as a mere tool for the important stuff being taught." Which is why it makes sense that their intro language is one that is easy to learn, supports multiple programming paradigms, has efficient numerical libraries, has easy-to-use visualization tools, an interactive interpreter, and can be used as a general purpose programming language. And while I personally prefer python for a high level language, there are others that could serve the same purpose.
A program language should be taught on the basis that it teaches the student programming and not that it jigsaws them into the world of business. I student that can transcend languages is likely to be a better programmer anyways, as they'll have more tools and models with which to get a task done.
I would agree with this in theory, however in practice it doesn't create a programmer who can transcend languages. In fact, they generally become very tied to specific language paradigms or capabilities. For instance, most universities seem to have selected Java as the language for CS. The problem here is that when they get into the "real world" they can't find a job doing anything but java. Why? Because they have no clue what a pointer is or how to use it.
Most CS and related programs are hurting our students simply because the instructors don't want to teach about certain things, or because they or the students think it's just too hard. Most people I work with don't really understand how programming really works. I once had a co-worker who had been programming for 20 years, but had no idea that the CPU had registers, what they were for, or how they would be used. That's just sad.
My favorite class with respect to this was assembly. It was fairly easy to pick up and taught you how the computer interpreted commands at a relatively low level.
You (and I) are becoming something of a rarity now days, most people I work with know absolutely nothing about assembly.:-(
The Mayan Long Count Calendar turns over in 2012 [today.com]. Mayan date 12.19.19.17.19 will occur on December 20, 2012, followed by the start of the fourteenth cycle, 13.0.0.0.0, on December 21st.
The event was first flagged by megalith scientist Terence McKenna. The end of the thirteenth cycle would break many megalith calculations — which conventionally use only the last four numbers to save on standing stones — with fears of spiritual collapse, disruption of ley lines, Ben Goldacre driving the chiropractors back into the sea and the return of the great god Quetzalcoatl and the consequent destruction of all life on earth.
Megalith programmers from 4000 years ago are being dredged up from peat bogs and pressed into service to get the henges updated to handle the turnover in the date. "It could be worse," said one. "I could still be programming COBOL."
Trust me, while you may wish you were learning how to write applications in the latest pop language during undergrad, the rest of the world wishes you had been taught computer language theory, set theory, data analysis by inference, proper documentation of your code, the 'non-coding' aspects of any number of different SDLC lifecycles, complete code coverage testing approaches, the interaction between software and the machine (where the machine is the network of machines, and the rest of the software running on those machines) and critical thought / problem solving during your undergrad years.
Your disdain for COBOL, FORTRAN, and Pascal show exactly why it's a bad idea to teach a single 'current' language and spend four years focusing on all the APIs and subtle language quirks - languages come and go. Entire platforms come and go. And yet the same people adapt over time (if they are good) and continue to implement strong software engineering principles in whatever comes along to replace those obsolete technologies.
Perhaps during those classes you weren't supposed to be focusing on the medium (the language) and rather be focusing on the lesson (data structures, analysis of algorithms, queue theory, set theory, or the one that has caused the world the most problems - handling every input that could possibly be handed to a routine.)
All of the above can be taught in any language, including one made up by the professor (RIP Edgar Dykstra.)
Actually, the most hardcore lecturer/professor at my University in Australia both promoted the use of Ada and drinking heavily. I guess he taught me how to be a man.
but for math geeks FORTRAN is probably the easiest language to get from pencil-n-paper to computer. Math functions in FORTRAN translate nicely from their paper counter parts. If you can do math and "show your work", or punch numbers in a calculator, you're 2/3 of the way to a FORTRAN command line program.
I don't think it's a useful first language anymore. Something like Python would be more useful "out of college". FORTRAN is really easy to pick up later anyway as it's "old fashioned" and line numbered based. I'd think the biggest problem teaching the class now would be getting students to take it seriously because it's a much older way of thinking about programs from our modern OOP languages.
Indeed, even the creator of Fortran said "actually, that was a shit idea, we should all ignore it and use functional programming instead" in this paper [stanford.edu].
Lets face it: Fortran (even Fortran-90) might not be fashionable, but it's a lot simpler (and therefore quicker and easier to learn) than C++, much faster than Python, and it lends itself well to the implementation of massive calculations.
It's definitely not a language for amateurs in the sense of people who like to fiddle with the system, are interested in how the compiler works, or who just want to make gee-whizz web mashups. It's a language for people who don't care a rat's *ss about computers or programming, but who need to get their calculations done without wasting time on fiddling with pointers and who need reliable answers without being bitten by silent array-boundary overflows to boot. So Slashdot might not be the best place to ask for an opinion.
Besides, most of today's numerical libraries (BLAS, LAPACK, ATLAS, EISPACK, FFT) are written in Fortran. If you want to use them, you could do worse than learn Fortran.
True, it's not a language you'd want to do sophisticated datastructures in, or tree-searches or text-processing or payroll accounting or database manipulation. But especially chemists (and to a lesser extent physicists) have more call for numerical software than they have for non-numerical software.
So no. It's not at all ridiculous to teach Fortran as a first programming language to non-computer-science students. Alongside Matlab (or Octave or Scilab) it will do fine for chemists.
Fortran has it's place, even though it's a bit of a fringe language today.
It has evolved since Fortran 77, and is better. It's also one of the languages where it doesn't require the programmer to have a detailed knowledge about how to parallelize a problem since later versions has those features built in. The programmer just have to be aware that it can be parallelized, but not waste time on the details about how to do it. Unfortunately GNU Fortran doesn't support this yet (unless it has been enabled lately).
Python is certainly not an alternative - unless you want to have a replacement for Basic.
Education shall primarily be done in type-safe languages that forces the developers to learn the importance of type safety. Way too many bugs have been created through history that are related to operations that aren't type-safe. Ada is one language that is really strict. Java is acceptable. C# is not acceptable since it has some unsafe parts when it comes to data typing.
And Visual Basic should be taken out, shot, drowned, burnt and sterilized for all it's abilities to make things unsafe and bug-ridden.
God forbid, don't teach em python first. Learn assembly, c++, ML, fortran even fucking visual basic. You can't learn python first, it's like eating the pudding before the salad. Python is the *last* language you should learn.
I absolutely agree. With a background in c++, learning python (my new department's introductory language) was cake, but I'm watching the people who learned python first struggle to go beyond it. They're even more hindered by the fact that they keep thinking, "But python was so easy..."
The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous. We wouldn't tolerate plumbers or accountants that poorly educated. We don't have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software developers are undereducated and undertrained.
Obviously, we don't want our tools--including our programming languages--to be more complex than necessary. But one aim should be to make tools that will serve skilled professionals--not to lower the level of expressiveness to serve people who can hardly understand the problems, let alone express solutions. We can and do build tools that make simple tasks simple for more people, but let's not let most people loose on the infrastructure of our technical civilization or force the professionals to use only tools designed for amateurs.
The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous. We wouldn't tolerate plumbers or accountants that poorly educated.
Not at all. Most homeowners do a lot more around the house with a lot less training, whether opening up the garbage disposal or trying to manage their retirement accoutns. The goal of these classes--especially for scientists--is the equivalent: Not to get people ready for programming a bug-free third party app; it's so they don't have to sit on their hands waiting for someone else to "build tools" to solve a perfectly manageable, one-off program that will let them move their research forward.
There may be things where there's a nice pre-built commercial or open source app; there will also be problems where there's a need for paid consultants. But there's a lot of ground in the middle, especially in specialized fields.
God forbid, don't teach em python first. Learn assembly, c++, ML, fortran
This seems to me like saying you should learn to drive an F1 car, or a Model T, before being allowed anything with an automatic gearbox.
I would say driving a car is like running a program. Designing or repairing a car is a much better analogy. And in that case, learning the old designs, and the physics they used is much better than "run this diagnostic tool; replace factory-made black-box widget". Learning assembly or C forces a person to recognize the limits of the machine (and thus the limits of interpreted languages).
Are there any cheap but quality tutorial for Fortran? O'Reilly has no contemporary introduction to the language and their last book on Fortran, Migrating to Fortran 90 [amazon.com] , came out nearly two decades ago.
How new does the book need to be for the language standard when it hasn't changed much in 2 decades? It's a simple, easy to use tool for serious engineering.
How new does the book need to be for the language standard when it hasn't changed much in 2 decades? It's a simple, easy to use tool for serious engineering.
Actually, Fortran has changed quite a bit in the last two decades. The Fortran 90, Fortran 95, and Fortran 2003 [wikipedia.org] standards have come out during that time. They added quite a number of major features, such as free-form source code, recursive procedures, operator overloading, dynamic memory allocation, and object-oriented programming. The Fortran of 2009 is not like the Fortran of 1989 at all.
Fortran is still one of the best, fastest, most optimized tools for number crunching. It's also very easy to write simple programs in it. No way I'd use Python for serious large data set numerical calculations.
First I wonder which Fortran you refer to; Fortran 66 is quite a different language from Fortran 95. I agree that all Fortran variants are pretty good languages for number crunching, but Fortran 77 and older lacked support for data structures, making it hard to teach students about them and advanced algorithms in general. (Yes, I've tried.) Fortran 90 and 95 are much better in those respects. On the other hand: C and C++ are not so far behind in speed to rule them out.
It is my opinion that learning two fundamentally different languages makes someone a better programmer. I see value in teaching both Fortran and (for example) Python, using Fortran for number crunching and Python for smarter algorithms.
Fortran is still one of the best, fastest, most optimized tools for number crunching.
Agreed.
It's also very easy to write simple programs in it.
This is a strength of Python too.
No way I'd use Python for serious large data set numerical calculations.
It's not either/or, with F2Py you can put your inner loops in Fortran, and deal with the higher level abstractions with Python. So you get fast number crunching and all the 'batteries included' too.
Even if not phython, what does Fortran have over modern compiled languages, for example?
Lots of libraries for numerical work. Fortunately many of them are being ported to Python modules so you can get the speed/convenience advantage and work in a modern language at the same time.
Fortran has tons of libraries specialized to whatever scientific field you are working in, and is unavoidable in high energy physics especially. Of course, most of these can be wrapped in C and then used in whatever high level language you like.
Citation needed.
Even if not phython, what does Fortran have over modern compiled languages, for example?
0) A lot of legacy code people still have to work with is written in FORTRAN. Sad but true.
1) Many very optimized libraries available. Check if your language du jour has an implementation of a routine for solving a linear system using BLAS [wikipedia.org]. That provides a huge improvement.
2) Many libraries are in fact only available for FORTRAN. For calculating the eigenvalues of a sparse matrix, there is only ARPACK (for Fortran), Arpack++ (a kludgy C++ interface to the very same FORTRAN library), and Matlab's "eigs" (a Visual Basic-style interface to the very same FORTRAN library).
3) Very expressive. For instance, you can reverse the entries of a vector of complex numbers in a single compiler instruction. This is a toy example, but for more complicate stuff this expressiveness pays: the compiler has an easier job in understanding what code can be safely optimized and what cannot. More complicate stuff involving e.g. C++ method calls suffers in terms of pointer aliasing problems and similar stuff. Of course you may write the very same thing in C or machine code, but for 99% of the computations you would use the "standard" interface to vectors/arrays of your languages and forget about this sort of micro-optimizations. A good commercial FORTRAN compiler (forget about gfortran, sorry GNU but sadly it's true) does this automatically.
4) FORTRAN 95 is not a punch-card language anymore, it has most of the fancy modern stuff if you wish to use it. While "bad programmers can write FORTRAN in every language", good programmers can write well-factored and perfectly readable FORTRAN code.
Nevertheless, I do matrix computations, and still I try to avoid it as much as I can. Most people in our field use MATLAB (which is essentially a Visual Basic-style interface to most of the awesome number-crunching FORTRAN libraries) even though for tight "for" loops its performance sucks. If performance is mission-critical, you may write FORTRAN subroutines and call them from MATLAB, and that's very convenient. Python still lacks many of Matlab's features, its only advantage is being Free Software.
BTW, a very ill-advised design choice of Python:
http://www.python.org/dev/peps/pep-0211/ [python.org]
Ask any numerical analyst to know why it is a terrible idea to solve a linear system with inv(A)*b. But make sure you have at least half an hour free.
BTW, a very ill-advised design choice of Python: http://www.python.org/dev/peps/pep-0211/ [python.org] Ask any numerical analyst to know why it is a terrible idea to solve a linear system with inv(A)*b. But make sure you have at least half an hour free.
To make a long story short; solving Ax=b by calculating x=inv(A)*b is a terrible idea because calculating inv(A) is an inherently difficult thing. While it would be extremely useful to have inv(A), it's not strictly neccessary to obtain in in order to solve Ax=b.
At the most basic level, the technique which most would be aware of to solve Ax=b is basic Gauss Elimination, with an augmented matrix and back substitution. In fact, this is often the very first thing people learn how to do in a linear algebra course. It isn't much better than finding the inverse, but it saves a lot of computation in the long run.
Of course there are many other techniques. Happily however, most packages can now automatically make the best choice on which technique to use, depending on the properties of A. In Matlab and Octave, it all boils down to using the left division operator like so x=A\b instead of the inverse calculating x=inv(A)*b
Using the first command, Matlab and Octave will choose a technique that best suits the matrix A. This page [mathworks.com] has a list of all the techniques that Matlab can use to solve the linear system. To my knowledge, Octave has a number of techniques as well, but I'm not sure if it's as comprehensive as Matlab. Also, Octave's left division operator has been known to have bugs.
And to return to the main topic, Octave and Matlab both use LAPACK [netlib.org] extensively, which is written completely in Fortran(and based on BLAS). There's really no other language for linear algebra.
Fortran hasn't had those limitations for decades - Fortran 90 and later are ideal languages for expressing mathematical algorithms and crunching numbers
Fortran hasn't had those limitations for decades - Fortran 90 and later are ideal languages for expressing mathematical algorithms and crunching numbers. The handling of arrays, matrices are just what they should be.
I wouldn't use Fortran as a general purpose language - having used Python for more 10 years I shudder at using Fortran for string handling, databases, user interfaces and more - but as a tool for expressing math it's the best, and also the most widely used. The alternative would be matlab (much of the syntax isn't that different).
Granted. But it's still easier to write simple, basic Fortran code to solve a quick engineering problem and to use/incorporate some of the nice math libraries. If you're really good, you can wrap it all in C and includes to bring in Fortran libs, but why bother for an undergrad's first course? The student only has 16 weeks to learn the basics, while taking other classes. There is always opportunity for more advanced coursework. Plus, Fortran is readily available on lots of systems, new and old. Even C isn't available on every system in every organization where a new engineer could be employed. So start with the basics, and then advance.
...if somebody studies astronomy and will have to work with old legacy Forth code, he should better be taught to program in Forth at university...
This is exactly the wrong reason to teach any programming language. You teach a language to teach programming concepts and methodologies, and so you use languages that emphasize the concepts you want to teach.
You don't teach a language so someone will know it later. That makes no sense at all.
The plus of teaching Python is that it's a badass OOP language with clean and simple syntax. It's an excellent language for conveying object oriented methodologies.
You learned Lisp and Prolog? I learned Scheme and Prolog. Wasn't because anyone thought I'd ever actually professionally program in those langauges, it's because they represent different paradigms, and, as a student, I learned something from seeing the different types of programming languages.
After you've mastered the basics, you go out in the world, and use the right tool for the job. For all that you argue against fanboyisms, you commit a few of them yourself. Keep an open mind.
Does it really matter what language they're taught in? They should be learning the concepts of programming, not just a language. However, FORTRAN has the benefit of already having a large existing code base and deployment in the field in which students in those particular disciplines are studying. There's no reason for them NOT to learn it, and if they feel like learning Python later, then then may. Python isn't the solution for every god damned thing in the world, even if it can do it.
i spoke to someone studying engineering in 1990 who was being taught fortran. they were using a mathematical library that would solve partial differential equations, by presenting the user with the actual mathematical formulae to them.
these kinds of libraries are staggeringly complex to write, and they have been empirically proven over decades of use to actually work.
to start again from scratch with such libraries would require man-centuries or possibly man-millenia of development effort to reproduce and debug, regardless of the programming language.
so it doesn't matter what people in the slashdot community think: for engineers to use anything but these tried-and-tested engineering libraries, that happen to be written in fortran, would just be genuinely stupid of them.
If all you need is to crunch numbers, Fortran is a good choice even today. It might not be the best language to introduce someone to computer science, but it is very powerful for anything that has to do with matrix operations.
A few years ago in a physics graduate course we had a simulation project which left the choice of language to the student. We compared performance between implementations in C C++ and Fortran. Fortran was consistently faster by a big margin. It's also very easy to learn.
There's no problem for teaching Fortran if it's the right tool for the job. It was 13 years ago that I took Fortran in College. It went great with physics and modeling courses. These days I write web-based database apps in Java/Perl/whatever language-du-jour is required of me, but I wouldn't want to use many of these languages for scientific purposes. I'll leave that to Fortran and C.
I am somewhat a Python fan boy. I love it. Its freaking wonderful for prototyping and really has a great, natural flow that reminds me a lot of pseudocode I might just invent on a napkin. Great language. But its also a factor of 30 times slower than a compiled language like C.
And Fortran is able to do optimizations (due to differences in the language for evaluation of expressions) that C is unable to do. This has to do with guarantees of ordering that Fortran does not give that C does. My point is that Fortran is even faster than C. Why do you think its still around?
The physical sciences aren't using a fast language because they are bored, or obsessed with speed for the hell of it. They use them because the problems they solve are typically deep into polynomial space, like O(n^3) or O(n^4). Having something 30 times faster means they can run 30 simulations instead of just 1. It makes a big difference to them.
I think the author of this article has lost some of this perspective.
That said, what this article should have tackled is, what do we want to teach engineering students about computer science? Right now, they take a class that teaches them C++, Java, Python, or whatever. They get some procedural programming skills with maybe a little tiny bit of object-oriented stuff (without really covering OO fundamentals IMHO, which are a more advanced topic) and they are thrown into a world where they are writing code in C for embedded controllers or Fortran for computational codes. As a result, there is a huge body of code out there written by people who know how to get the job done, but don't exactly write code that is very maintainable. They relearn the lessons of CS he hard way over 10-20-30-40(?) years of experience. Are we really giving these young students (who are not CS majors) what they need? What kind of curriculum would be ideal for someone who is going to end up writing code for something like a robot control system in C?
* I didn't really look too closely at this particular source, but I've seen numerous benchmarks all saying the same thing. If you want a surprise, go look at how LISP stacks up compared to C. It is better than you think.
IMO universities should be teaching core principles and methods, not attempting to impart up-to-date job skills.
If you are going to teach FORTRAN because it's of use in the real world, then why stop there? Why not also (god forbid) teach.NET. JavaScript, C#, etc. May as well teach them Excel macros and how to interact with Microsoft Clippy while you're at it.
No!
Teaching programming should be done in a langauge that imparts the principles easily and teaches good habits. You could do a lot worse than Pascal which was often used in this role, or maybe today just C++. I'd argue against Java and scripting languages as the core language since they are too high level to learn all the basics. You could throw in Perl, Python or any modern scripting langauge as a secondary, and for a Computer Science (vs. Physics, Engineering, etc) it's appropriate to teach a couple of other styles of programming - e.g. assembler, and functional programming.
We're not talking CS here, we're talking Engineering. Teaching them a specific language used in their field/is/ teaching them core principles and methods. Think of it like a basic diffeq class, giving them the tools to be able to learn their field, as opposed to more advanced math classes that underly diffeq.
This was clearly written by someone who doesn't actually do any scientific computing.
As hard as it may be for some CS-types (myself included) to believe, Fortran is still the language for scientific computing.
I've worked at flight simulation companies for two different companies (and 5 different groups) for the last 15 years. The math required to simulate a flying aircraft in realtime is ungodly hairy. It also has to get done fast. We typically have 50 or so different simulation models (plus all the I/O) that have to run to completion 60 times a second. That's about 17ms, or 8ms if we want %50 spare. In addition, for a realtime app like a simulatior it needs to take the same time to execute every time (no runtime dynamic allocations, GC, etc.) or things "jitter".
Everywhere I've worked, with the exception of Ada mandated jobs, had this code done in Fortran. Yes that includes today. We are today writing new Fortran, and we are not alone. When we request models from the aircract manufacturers, they come in Fortran (or occasionally Ada). Fortran is still, and quite possibly always will be, the language for Scientific Computing.
Suggesting non-CS math and science students learn some other programming language instead is just wrong. Further suggesting that it should be the author's favorite hip new interpreted languge is just laughable.
I'll add a "+2" to this. My background is in Astrophysics, and the coding there is largely done in Fortran. The friends and people I know spread between 4-5 different universities all program in Fortran. I'm moving into Geophysics/Atmospheric/Oceanic sciences, and all that work is done in Fortran. From fluid dynamics to stress fault calculations, Fortran is the de facto language.
To be clear, we're not talking about programming here. We're talking about math. Pure, hardcore, overwhelming math. The crunching of terabytes of data. Matrices with millions upon millions of cells, being combined with more of the same.
If we were talking about pure programming, Fortran is a terrible language. What we're talking about here is automating massively complex mathematical calculations on enormous amounts of data.
I did my graduate studies in a university electromagnetics lab. Two of the professors main research area was FEA. By default, we still ended up learning some even if it wasn't our research area. Most the students were pro Matlab, where as the professors were pro Fortran. As a result, if you were doing FEA for your research, you were learning fortran. If you are doing small simulations, then go ahead and use Matlab, since it will be easier to code and debug. Once you start creating 3D meshes, the number of unknowns becomes huge. At that point a compiled language is a better choice. At least fortran has complex numbers native to the language, so its implementation is a bit more elegant than say C/C++.
But the original point of the article is about teaching people who are mathematicians (not programmers) FORTRAN or a newer language such as Python. These aren't people who, most probably, won't be coding for a living. Although knowing how a code a little will come in handy. To that extent it's more like the fact that most homeowner own a hammer and know how to use it, but don't have a need to buy a nail gun and learn how to use that. (admittedly buying a nail gun for a homeowner is really about how much FUN it is to have a nail gun handy all the time!)
On a side note : How many of those roofers and framers learned to use a nail gun before a hammer?
Most roofers and framers learned to use a nail gun first, and many, if not most, will never learn to use a hammer at any level that could be called proficient in the real-world "production" environment of housebuilding. Remember, we're talking mastery of the tools at a level that allows "efficiency". That's a plateau that is far lower for the nail gun.
Same goes for programming skills. Python, for example, is far easier to master at that level (efficient production) than FORTRAN, for most tasks. Yes, there are those tasks for which FORTRAN is the right tool for the job (number crunching), but such a case is a very rare exception. So if "knowing how to code a little" is a good thing, spending x hours of the undergraduate's time teaching him a more utilitarian tool is the better expenditure of time, is it not? And BTW, let's dispense with the "but it doesn't teach good programming practice". We're not talking about BASIC here. There are a number of candidates that would fit the bill. Hell, I'd suggest that PERL is a far better choice than FORTRAN.
It's okay to teach them FORTRAN (Score:5, Funny)
But only if they have to do it on punch cards, like I did. Give each student a can of WD40 to keep the machines working smoothly, too.
Re:It's okay to teach them FORTRAN (Score:5, Funny)
Parent
Re:It's okay to teach them FORTRAN (Score:5, Interesting)
Well, I'll tell you like my former VB teacher told me, funnily enough after some kid tried to steal my code and pass it off as his own. After Mike(my teacher) got done laughing his ass off he told the kid "BTW you are getting an F for stealing from Kevin". "How do you know that he didn't steal it from me?" Again after Mike got done laughing his ass off he projected the code onto the board and said to the class "Do you notice anything a little odd about this code?" And one said "It has numbers in front of all the lines...and what is a GOTO?"
And Mike said "How old are you Shawn?" and after the kid said 19 he said "And THAT class is why I know Shawn stole this code from Kevin. He turned to me and said "You're what? 35?" and when I confirmed he said "You see class, in the days before PCs became standard with pretty desktops like you have now, all the machines ran BASIC. The numbering and the use of GOTO to call a sub is a classic tell that the person who wrote this cut his teeth on one of the old BASIC computers." He tilted his head and said "Commodore or Atari?" and I sat there with my mouth gaping and said "Commodore VIC20. How did you know that?" he said "Because your code is classic Commodore and Atari style. Very efficient but as subtle as a chainsaw."
After some of the kids started coping pieces of my code and trying to use GOTO and crashing all over the place Mike explained it to me like this-"To an old greybeard like you or me, that actually understands what the code is doing a GOTO can be a quick and efficient way to get something done quick. Subtle as a chainsaw, but it gets the job done. But you give it to these kids, that don't really understand what they are trying to accomplish or understand how the codes works in the machine? It is like handing a monkey a sledgehammer and letting him loose in a room full of bombs. He is gonna blow something up, the only question is when."
So if you want to know why teachers like Mike would cringe when they saw a GOTO, it is because it works fine IF you know what you are doing and how the code will be processed. But with so many learning code the VS way, with everything drag and drop, for many of those GOTO will simply blow up in their faces. Better just to not let them know it exists in the first place.
Parent
Re:Python? (Score:5, Insightful)
Evidently, you don't go out that much. People use interpreted languages in science all the time. At least I do. Where I sit, there is quite a bit of spare capacity waiting. When I try to figure something out it is way more reasonable to write a program in three-four hours and have it run overnight than to write it in two days and have it run in (say) thirty minutes.
Parent
Re:Python? (Score:5, Insightful)
Second, while some of these scientific programs can run overnight, a lot of them will take a day or more to run, even when compiled and on a super or parallel computer. I don't know of any highly optimized Python compilers for big metal. Fortran is still the number one language for performance computing.
Third, there seriously needs to be major scientific libraries pre-existing for the language to be useful. An added benefit is being able to support more than one floating point number format.
Finally, the number one most important reason that Fortran is used in the sciences, is because everyone else uses it in the field. Seriously, what good is Python if all your prof's and advisor's and boss's programs that you need to maintain are in Fortran 66? It's faster to learn Fortran than to port it all. This is part of the "dusty deck" problem, where decades old libraries still have to be used and supported. This applies to many languages - many languages are popular precisely because they are popular, not because of inherent elegance or suitability.
In the sciences, the students are not being taught programming for the sake of programming, and they're not even being taught to write good programs necessarily. They're being taught to program as a mere tool for the important stuff being taught. Some classes may not even care what language you use, as long as you can read and understand the sample programs and the math library is correct.
Being in the sciences and not knowing Fortran will be a drawback. In some areas it may not be as big a drawback, but it will be there. This is like trying to do embedded systems without knowing C.
Parent
Re:Python? (Score:5, Informative)
I think you are mistaken regarding what most undergraduate science students actually do (they are not maintaining/upgrading old fortran libraries). Most of the high performance capability that undergrads need involves matrix computations, FFTs, convolution, etc., all of which are included in the python numpy/Numeric module (which is a wrapper around fortran libraries, so they're just as efficient). And since they'll likely spend as much time analyzing data as producing it, python + numpy + matplotlib is a perfectly suitable solution.
I'm not suggesting that fortran isn't of value to some scientists in some situations but many science students will never have to touch fortran code unless they're forced to take a class that teaches it. As you said: "They're being taught to program as a mere tool for the important stuff being taught." Which is why it makes sense that their intro language is one that is easy to learn, supports multiple programming paradigms, has efficient numerical libraries, has easy-to-use visualization tools, an interactive interpreter, and can be used as a general purpose programming language. And while I personally prefer python for a high level language, there are others that could serve the same purpose.
Parent
Re:MOD Parent up (Score:5, Insightful)
A program language should be taught on the basis that it teaches the student programming and not that it jigsaws them into the world of business. I student that can transcend languages is likely to be a better programmer anyways, as they'll have more tools and models with which to get a task done.
I would agree with this in theory, however in practice it doesn't create a programmer who can transcend languages. In fact, they generally become very tied to specific language paradigms or capabilities. For instance, most universities seem to have selected Java as the language for CS. The problem here is that when they get into the "real world" they can't find a job doing anything but java. Why? Because they have no clue what a pointer is or how to use it. Most CS and related programs are hurting our students simply because the instructors don't want to teach about certain things, or because they or the students think it's just too hard. Most people I work with don't really understand how programming really works. I once had a co-worker who had been programming for 20 years, but had no idea that the CPU had registers, what they were for, or how they would be used. That's just sad.
My favorite class with respect to this was assembly. It was fairly easy to pick up and taught you how the computer interpreted commands at a relatively low level.
You (and I) are becoming something of a rarity now days, most people I work with know absolutely nothing about assembly. :-(
Parent
Oh come on. (Score:5, Funny)
--No one-- should be taught FORTRAN. Ever...
*sobs in fetal position*
Re:Oh come on. (Score:5, Insightful)
Right. Teach COBOL instead!
Job security well into the next millenium!
Parent
Y2012 problem: Mayan calendar runs out (Score:5, Funny)
The Mayan Long Count Calendar turns over in 2012 [today.com]. Mayan date 12.19.19.17.19 will occur on December 20, 2012, followed by the start of the fourteenth cycle, 13.0.0.0.0, on December 21st.
The event was first flagged by megalith scientist Terence McKenna. The end of the thirteenth cycle would break many megalith calculations — which conventionally use only the last four numbers to save on standing stones — with fears of spiritual collapse, disruption of ley lines, Ben Goldacre driving the chiropractors back into the sea and the return of the great god Quetzalcoatl and the consequent destruction of all life on earth.
Megalith programmers from 4000 years ago are being dredged up from peat bogs and pressed into service to get the henges updated to handle the turnover in the date. "It could be worse," said one. "I could still be programming COBOL."
Parent
Re:Oh come on. (Score:5, Interesting)
Trust me, while you may wish you were learning how to write applications in the latest pop language during undergrad, the rest of the world wishes you had been taught computer language theory, set theory, data analysis by inference, proper documentation of your code, the 'non-coding' aspects of any number of different SDLC lifecycles, complete code coverage testing approaches, the interaction between software and the machine (where the machine is the network of machines, and the rest of the software running on those machines) and critical thought / problem solving during your undergrad years.
Your disdain for COBOL, FORTRAN, and Pascal show exactly why it's a bad idea to teach a single 'current' language and spend four years focusing on all the APIs and subtle language quirks - languages come and go. Entire platforms come and go. And yet the same people adapt over time (if they are good) and continue to implement strong software engineering principles in whatever comes along to replace those obsolete technologies.
Perhaps during those classes you weren't supposed to be focusing on the medium (the language) and rather be focusing on the lesson (data structures, analysis of algorithms, queue theory, set theory, or the one that has caused the world the most problems - handling every input that could possibly be handed to a routine.)
All of the above can be taught in any language, including one made up by the professor (RIP Edgar Dykstra.)
Parent
Re:Oh come on. (Score:5, Funny)
Parent
Re:Oh come on. (Score:5, Funny)
Actually, the most hardcore lecturer/professor at my University in Australia both promoted the use of Ada and drinking heavily. I guess he taught me how to be a man.
Parent
Re:Oh come on. (Score:5, Interesting)
but for math geeks FORTRAN is probably the easiest language to get from pencil-n-paper to computer. Math functions in FORTRAN translate nicely from their paper counter parts. If you can do math and "show your work", or punch numbers in a calculator, you're 2/3 of the way to a FORTRAN command line program.
I don't think it's a useful first language anymore. Something like Python would be more useful "out of college". FORTRAN is really easy to pick up later anyway as it's "old fashioned" and line numbered based. I'd think the biggest problem teaching the class now would be getting students to take it seriously because it's a much older way of thinking about programs from our modern OOP languages.
Parent
Re:Oh come on. (Score:5, Interesting)
Indeed, even the creator of Fortran said "actually, that was a shit idea, we should all ignore it and use functional programming instead" in this paper [stanford.edu].
Parent
Fortran is still useful for calculations (Score:5, Insightful)
It's definitely not a language for amateurs in the sense of people who like to fiddle with the system, are interested in how the compiler works, or who just want to make gee-whizz web mashups. It's a language for people who don't care a rat's *ss about computers or programming, but who need to get their calculations done without wasting time on fiddling with pointers and who need reliable answers without being bitten by silent array-boundary overflows to boot. So Slashdot might not be the best place to ask for an opinion.
Besides, most of today's numerical libraries (BLAS, LAPACK, ATLAS, EISPACK, FFT) are written in Fortran. If you want to use them, you could do worse than learn Fortran.
True, it's not a language you'd want to do sophisticated datastructures in, or tree-searches or text-processing or payroll accounting or database manipulation. But especially chemists (and to a lesser extent physicists) have more call for numerical software than they have for non-numerical software.
So no. It's not at all ridiculous to teach Fortran as a first programming language to non-computer-science students. Alongside Matlab (or Octave or Scilab) it will do fine for chemists.
Parent
Re:Oh come on. (Score:5, Insightful)
Fortran has it's place, even though it's a bit of a fringe language today.
It has evolved since Fortran 77, and is better. It's also one of the languages where it doesn't require the programmer to have a detailed knowledge about how to parallelize a problem since later versions has those features built in. The programmer just have to be aware that it can be parallelized, but not waste time on the details about how to do it. Unfortunately GNU Fortran doesn't support this yet (unless it has been enabled lately).
Python is certainly not an alternative - unless you want to have a replacement for Basic.
Education shall primarily be done in type-safe languages that forces the developers to learn the importance of type safety. Way too many bugs have been created through history that are related to operations that aren't type-safe. Ada is one language that is really strict. Java is acceptable. C# is not acceptable since it has some unsafe parts when it comes to data typing.
And Visual Basic should be taken out, shot, drowned, burnt and sterilized for all it's abilities to make things unsafe and bug-ridden.
Parent
Re:Oh come on. (Score:5, Insightful)
God forbid, don't teach em python first. Learn assembly, c++, ML, fortran even fucking visual basic. You can't learn python first, it's like eating the pudding before the salad. Python is the *last* language you should learn.
Yes, I'm serious.
Parent
Re:Oh come on. (Score:5, Interesting)
Parent
Re:Oh come on. (Score:5, Insightful)
The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous. We wouldn't tolerate plumbers or accountants that poorly educated. We don't have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software developers are undereducated and undertrained.
Obviously, we don't want our tools--including our programming languages--to be more complex than necessary. But one aim should be to make tools that will serve skilled professionals--not to lower the level of expressiveness to serve people who can hardly understand the problems, let alone express solutions. We can and do build tools that make simple tasks simple for more people, but let's not let most people loose on the infrastructure of our technical civilization or force the professionals to use only tools designed for amateurs.
- Bjarne S.
Parent
Re:Oh come on. (Score:5, Insightful)
The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous. We wouldn't tolerate plumbers or accountants that poorly educated.
Not at all. Most homeowners do a lot more around the house with a lot less training, whether opening up the garbage disposal or trying to manage their retirement accoutns. The goal of these classes--especially for scientists--is the equivalent: Not to get people ready for programming a bug-free third party app; it's so they don't have to sit on their hands waiting for someone else to "build tools" to solve a perfectly manageable, one-off program that will let them move their research forward.
There may be things where there's a nice pre-built commercial or open source app; there will also be problems where there's a need for paid consultants. But there's a lot of ground in the middle, especially in specialized fields.
Parent
Re:Oh come on. (Score:5, Insightful)
God forbid, don't teach em python first. Learn assembly, c++, ML, fortran
This seems to me like saying you should learn to drive an F1 car, or a Model T, before being allowed anything with an automatic gearbox.
I would say driving a car is like running a program. Designing or repairing a car is a much better analogy. And in that case, learning the old designs, and the physics they used is much better than "run this diagnostic tool; replace factory-made black-box widget". Learning assembly or C forces a person to recognize the limits of the machine (and thus the limits of interpreted languages).
Parent
How would you learn? (Score:4, Interesting)
Re:How would you learn? (Score:5, Informative)
How new does the book need to be for the language standard when it hasn't changed much in 2 decades? It's a simple, easy to use tool for serious engineering.
Parent
Re:How would you learn? (Score:5, Interesting)
Actually, Fortran has changed quite a bit in the last two decades. The Fortran 90, Fortran 95, and Fortran 2003 [wikipedia.org] standards have come out during that time. They added quite a number of major features, such as free-form source code, recursive procedures, operator overloading, dynamic memory allocation, and object-oriented programming. The Fortran of 2009 is not like the Fortran of 1989 at all.
Parent
Re:How would you learn? (Score:4, Funny)
Parent
While there may be "newer" languages (Score:5, Insightful)
Re:While there may be "newer" languages (Score:4, Insightful)
It is my opinion that learning two fundamentally different languages makes someone a better programmer. I see value in teaching both Fortran and (for example) Python, using Fortran for number crunching and Python for smarter algorithms.
Parent
Re:While there may be "newer" languages (Score:5, Interesting)
Use both. I used Fortran to create some python modules at my last job, and it was dead easy. Take a look at this [cens.ioc.ee].
Parent
Re:While there may be "newer" languages (Score:5, Informative)
Fortran is still one of the best, fastest, most optimized tools for number crunching.
Agreed.
It's also very easy to write simple programs in it.
This is a strength of Python too.
No way I'd use Python for serious large data set numerical calculations.
It's not either/or, with F2Py you can put your inner loops in Fortran, and deal with the higher level abstractions with Python. So you get fast number crunching and all the 'batteries included' too.
Parent
Re:While there may be "newer" languages (Score:5, Insightful)
Citation needed.
Even if not phython, what does Fortran have over modern compiled languages, for example?
Lots of libraries for numerical work. Fortunately many of them are being ported to Python modules so you can get the speed/convenience advantage and work in a modern language at the same time.
Parent
Re:While there may be "newer" languages (Score:5, Informative)
Parent
Re:While there may be "newer" languages (Score:5, Informative)
0) A lot of legacy code people still have to work with is written in FORTRAN. Sad but true.
1) Many very optimized libraries available. Check if your language du jour has an implementation of a routine for solving a linear system using BLAS [wikipedia.org]. That provides a huge improvement.
2) Many libraries are in fact only available for FORTRAN. For calculating the eigenvalues of a sparse matrix, there is only ARPACK (for Fortran), Arpack++ (a kludgy C++ interface to the very same FORTRAN library), and Matlab's "eigs" (a Visual Basic-style interface to the very same FORTRAN library).
3) Very expressive. For instance, you can reverse the entries of a vector of complex numbers in a single compiler instruction. This is a toy example, but for more complicate stuff this expressiveness pays: the compiler has an easier job in understanding what code can be safely optimized and what cannot. More complicate stuff involving e.g. C++ method calls suffers in terms of pointer aliasing problems and similar stuff. Of course you may write the very same thing in C or machine code, but for 99% of the computations you would use the "standard" interface to vectors/arrays of your languages and forget about this sort of micro-optimizations. A good commercial FORTRAN compiler (forget about gfortran, sorry GNU but sadly it's true) does this automatically.
4) FORTRAN 95 is not a punch-card language anymore, it has most of the fancy modern stuff if you wish to use it. While "bad programmers can write FORTRAN in every language", good programmers can write well-factored and perfectly readable FORTRAN code.
Nevertheless, I do matrix computations, and still I try to avoid it as much as I can. Most people in our field use MATLAB (which is essentially a Visual Basic-style interface to most of the awesome number-crunching FORTRAN libraries) even though for tight "for" loops its performance sucks. If performance is mission-critical, you may write FORTRAN subroutines and call them from MATLAB, and that's very convenient. Python still lacks many of Matlab's features, its only advantage is being Free Software.
BTW, a very ill-advised design choice of Python: http://www.python.org/dev/peps/pep-0211/ [python.org] Ask any numerical analyst to know why it is a terrible idea to solve a linear system with inv(A)*b. But make sure you have at least half an hour free.
Parent
Re:While there may be "newer" languages (Score:5, Informative)
To make a long story short; solving Ax=b by calculating x=inv(A)*b is a terrible idea because calculating inv(A) is an inherently difficult thing. While it would be extremely useful to have inv(A), it's not strictly neccessary to obtain in in order to solve Ax=b.
At the most basic level, the technique which most would be aware of to solve Ax=b is basic Gauss Elimination, with an augmented matrix and back substitution. In fact, this is often the very first thing people learn how to do in a linear algebra course. It isn't much better than finding the inverse, but it saves a lot of computation in the long run.
Of course there are many other techniques. Happily however, most packages can now automatically make the best choice on which technique to use, depending on the properties of A. In Matlab and Octave, it all boils down to using the left division operator like so
x=A\b
instead of the inverse calculating
x=inv(A)*b
Using the first command, Matlab and Octave will choose a technique that best suits the matrix A. This page [mathworks.com] has a list of all the techniques that Matlab can use to solve the linear system. To my knowledge, Octave has a number of techniques as well, but I'm not sure if it's as comprehensive as Matlab. Also, Octave's left division operator has been known to have bugs.
And to return to the main topic, Octave and Matlab both use LAPACK [netlib.org] extensively, which is written completely in Fortran(and based on BLAS). There's really no other language for linear algebra.
Parent
Re:Not so easy (Score:5, Insightful)
Fortran hasn't had those limitations for decades - Fortran 90 and later are ideal languages for expressing mathematical algorithms and crunching numbers
Fortran hasn't had those limitations for decades - Fortran 90 and later are ideal languages for expressing mathematical algorithms and crunching numbers. The handling of arrays, matrices are just what they should be.
I wouldn't use Fortran as a general purpose language - having used Python for more 10 years I shudder at using Fortran for string handling, databases, user interfaces and more - but as a tool for expressing math it's the best, and also the most widely used. The alternative would be matlab (much of the syntax isn't that different).
Parent
Re:While there may be "newer" languages (Score:5, Insightful)
Parent
Re:While there may be "newer" languages (Score:5, Insightful)
...if somebody studies astronomy and will have to work with old legacy Forth code, he should better be taught to program in Forth at university...
This is exactly the wrong reason to teach any programming language. You teach a language to teach programming concepts and methodologies, and so you use languages that emphasize the concepts you want to teach.
You don't teach a language so someone will know it later. That makes no sense at all.
The plus of teaching Python is that it's a badass OOP language with clean and simple syntax. It's an excellent language for conveying object oriented methodologies.
You learned Lisp and Prolog? I learned Scheme and Prolog. Wasn't because anyone thought I'd ever actually professionally program in those langauges, it's because they represent different paradigms, and, as a student, I learned something from seeing the different types of programming languages.
After you've mastered the basics, you go out in the world, and use the right tool for the job. For all that you argue against fanboyisms, you commit a few of them yourself. Keep an open mind.
Parent
So what? (Score:4, Insightful)
Does it really matter what language they're taught in? They should be learning the concepts of programming, not just a language. However, FORTRAN has the benefit of already having a large existing code base and deployment in the field in which students in those particular disciplines are studying. There's no reason for them NOT to learn it, and if they feel like learning Python later, then then may. Python isn't the solution for every god damned thing in the world, even if it can do it.
libraries. gigabytes of libraries (Score:5, Informative)
i spoke to someone studying engineering in 1990 who was being taught fortran. they were using a mathematical library that would solve partial differential equations, by presenting the user with the actual mathematical formulae to them.
these kinds of libraries are staggeringly complex to write, and they have been empirically proven over decades of use to actually work.
to start again from scratch with such libraries would require man-centuries or possibly man-millenia of development effort to reproduce and debug, regardless of the programming language.
so it doesn't matter what people in the slashdot community think: for engineers to use anything but these tried-and-tested engineering libraries, that happen to be written in fortran, would just be genuinely stupid of them.
I still use Fortran for sciantific calculations (Score:5, Informative)
If all you need is to crunch numbers, Fortran is a good choice even today.
It might not be the best language to introduce someone to computer science, but it is very powerful for anything that has to do with matrix operations.
A few years ago in a physics graduate course we had a simulation project which left the choice of language to the student.
We compared performance between implementations in C C++ and Fortran.
Fortran was consistently faster by a big margin.
It's also very easy to learn.
That said, I do most of my coding in C.
different languages for different purposes (Score:4, Insightful)
There's no problem for teaching Fortran if it's the right tool for the job. It was 13 years ago that I took Fortran in College. It went great with physics and modeling courses. These days I write web-based database apps in Java/Perl/whatever language-du-jour is required of me, but I wouldn't want to use many of these languages for scientific purposes. I'll leave that to Fortran and C.
PYTHON???? (Score:5, Insightful)
Are you serious? Python?
I am somewhat a Python fan boy. I love it. Its freaking wonderful for prototyping and really has a great, natural flow that reminds me a lot of pseudocode I might just invent on a napkin. Great language. But its also a factor of 30 times slower than a compiled language like C.
(http://www.osnews.com/story/5602/Nine_Language_Performance_Round-up_Benchmarking_Math_File_I_O/page3/)*
And Fortran is able to do optimizations (due to differences in the language for evaluation of expressions) that C is unable to do. This has to do with guarantees of ordering that Fortran does not give that C does. My point is that Fortran is even faster than C. Why do you think its still around?
The physical sciences aren't using a fast language because they are bored, or obsessed with speed for the hell of it. They use them because the problems they solve are typically deep into polynomial space, like O(n^3) or O(n^4). Having something 30 times faster means they can run 30 simulations instead of just 1. It makes a big difference to them.
I think the author of this article has lost some of this perspective.
That said, what this article should have tackled is, what do we want to teach engineering students about computer science? Right now, they take a class that teaches them C++, Java, Python, or whatever. They get some procedural programming skills with maybe a little tiny bit of object-oriented stuff (without really covering OO fundamentals IMHO, which are a more advanced topic) and they are thrown into a world where they are writing code in C for embedded controllers or Fortran for computational codes. As a result, there is a huge body of code out there written by people who know how to get the job done, but don't exactly write code that is very maintainable. They relearn the lessons of CS he hard way over 10-20-30-40(?) years of experience. Are we really giving these young students (who are not CS majors) what they need? What kind of curriculum would be ideal for someone who is going to end up writing code for something like a robot control system in C?
* I didn't really look too closely at this particular source, but I've seen numerous benchmarks all saying the same thing. If you want a surprise, go look at how LISP stacks up compared to C. It is better than you think.
University != Trade school (Score:5, Insightful)
IMO universities should be teaching core principles and methods, not attempting to impart up-to-date job skills.
If you are going to teach FORTRAN because it's of use in the real world, then why stop there? Why not also (god forbid) teach .NET. JavaScript, C#, etc. May as well teach them Excel macros and how to interact with Microsoft Clippy while you're at it.
No!
Teaching programming should be done in a langauge that imparts the principles easily and teaches good habits. You could do a lot worse than Pascal which was often used in this role, or maybe today just C++. I'd argue against Java and scripting languages as the core language since they are too high level to learn all the basics. You could throw in Perl, Python or any modern scripting langauge as a secondary, and for a Computer Science (vs. Physics, Engineering, etc) it's appropriate to teach a couple of other styles of programming - e.g. assembler, and functional programming.
Re:University != Trade school (Score:5, Insightful)
We're not talking CS here, we're talking Engineering. Teaching them a specific language used in their field /is/ teaching them core principles and methods. Think of it like a basic diffeq class, giving them the tools to be able to learn their field, as opposed to more advanced math classes that underly diffeq.
Parent
Sillyness (Score:5, Insightful)
This was clearly written by someone who doesn't actually do any scientific computing.
As hard as it may be for some CS-types (myself included) to believe, Fortran is still the language for scientific computing. I've worked at flight simulation companies for two different companies (and 5 different groups) for the last 15 years. The math required to simulate a flying aircraft in realtime is ungodly hairy. It also has to get done fast. We typically have 50 or so different simulation models (plus all the I/O) that have to run to completion 60 times a second. That's about 17ms, or 8ms if we want %50 spare. In addition, for a realtime app like a simulatior it needs to take the same time to execute every time (no runtime dynamic allocations, GC, etc.) or things "jitter".
Everywhere I've worked, with the exception of Ada mandated jobs, had this code done in Fortran. Yes that includes today. We are today writing new Fortran, and we are not alone. When we request models from the aircract manufacturers, they come in Fortran (or occasionally Ada). Fortran is still, and quite possibly always will be, the language for Scientific Computing.
Suggesting non-CS math and science students learn some other programming language instead is just wrong. Further suggesting that it should be the author's favorite hip new interpreted languge is just laughable.
Re:Sillyness (Score:5, Informative)
I'll add a "+2" to this. My background is in Astrophysics, and the coding there is largely done in Fortran. The friends and people I know spread between 4-5 different universities all program in Fortran. I'm moving into Geophysics/Atmospheric/Oceanic sciences, and all that work is done in Fortran. From fluid dynamics to stress fault calculations, Fortran is the de facto language.
To be clear, we're not talking about programming here. We're talking about math. Pure, hardcore, overwhelming math. The crunching of terabytes of data. Matrices with millions upon millions of cells, being combined with more of the same.
If we were talking about pure programming, Fortran is a terrible language. What we're talking about here is automating massively complex mathematical calculations on enormous amounts of data.
Parent
Re:Fortran is weak sauce buddy (Score:4, Funny)
Yes, everything should be written in a fresh, clean language.
I nominate VBScript.
Parent
Yes (Score:5, Insightful)
Parent
Re:Agreed, but engineers still use Fortran (Score:4, Informative)
Parent
Re:Newer doesn't always mean better. (Score:5, Insightful)
But the original point of the article is about teaching people who are mathematicians (not programmers) FORTRAN or a newer language such as Python. These aren't people who, most probably, won't be coding for a living. Although knowing how a code a little will come in handy. To that extent it's more like the fact that most homeowner own a hammer and know how to use it, but don't have a need to buy a nail gun and learn how to use that. (admittedly buying a nail gun for a homeowner is really about how much FUN it is to have a nail gun handy all the time!)
On a side note : How many of those roofers and framers learned to use a nail gun before a hammer?
Most roofers and framers learned to use a nail gun first, and many, if not most, will never learn to use a hammer at any level that could be called proficient in the real-world "production" environment of housebuilding. Remember, we're talking mastery of the tools at a level that allows "efficiency". That's a plateau that is far lower for the nail gun.
Same goes for programming skills. Python, for example, is far easier to master at that level (efficient production) than FORTRAN, for most tasks. Yes, there are those tasks for which FORTRAN is the right tool for the job (number crunching), but such a case is a very rare exception. So if "knowing how to code a little" is a good thing, spending x hours of the undergraduate's time teaching him a more utilitarian tool is the better expenditure of time, is it not? And BTW, let's dispense with the "but it doesn't teach good programming practice". We're not talking about BASIC here. There are a number of candidates that would fit the bill. Hell, I'd suggest that PERL is a far better choice than FORTRAN.
Parent