Slashdot Mirror
How Not to Write FORTRAN in Any Language
gManZboy writes "In an article that's sure to p/o Fortran programmers, Donn Seeley has assembled a rant that posits there are characteristics of good coding that transcend all programming languages, except Fortran. Seriously though, his point is that early FORTRAN made coding ugly. Thus the joke 'Don't write FORTRAN' was applied to anyone with ugly code. Though Fortran has in recent years overcome its early challenges, the point -- 'Don't write FORTRAN' (i.e. ugly stuff) -- still applies."
When I took computer programming in high school, it was all FORTRAN. We used a wonderfully dry textL FORTRAN IV with WATFOR and WATFIV. We didn't have any sort of microcomputer (this was 1980, and we were behind the times even then), but we had a keypunch, so we'd write code on a form, punch cards, rubber band 'em together, and send them off to be run on the district's big iron. Then you'd wait a week and get back a few sheet of green and white striped paper with ***SYNTAX ERROR*** all over it. And we liked it that way!
Although that was a toothache of a programming experience, I have never lost this bizarre fondness I have for that ugly, unwieldy, but somehow cool FORTRAN. Writing that stuff makes you feel like you're talking the language of a retro-scifi computer, like the ones in the original Star Trek that spoke in that odd mechanical monotone. Robby the Robot had to
have been programmed in FORTRAN (and NO he was NOT a guy in a suit! I'm not listening! La la la!).
At any rate, old-fashioned FORTRAN may deserve to be bashed, but I can't help shedding a tear.
sure to p/o Fortran programmers
.divide. o Fortran programmers.
You mean "sure to p
While I take issue with his blantant anti-FORTRANism, he makes the excellent point: Write good code in whatever language you write. Just because you can write Perl that looks like line noise does not meen you must.
How does the Slashdot Effect happen given that no slashdotters ever RTFA?
Thus the joke 'Don't write FORTRAN' was applied to anyone with ugly code.
I mostly program in C, Java,php and C++(and several other languages that I dont use as much), and am always interested in picking up new languages to play around with. Is Fortran worth learning? And are there any things that it does a lot better than other languages?
Boxing Equipment Reviews
In an article that's sure to p/o Fortran programmers and bore the hell out of everyone else, Donn Seeley...
As long as you use vi. You can never write beautiful code with emacs
I just figured I'd follow one pointless flame fest with another.
Isn't FORTRAN used these days primarily to figure out mathematical and engineering calculations? I am sure most of these programs are small and maintained by a few people. So does it matter if it is ugly? I am sure there are FORTRAN libraries to access databases but how many are really large programs??
I have had to make changes to UNIX shell scripts and PERL code before. Most of the undocumented cryptic scripts were small enough to figure out what I needed to change.
Seriously, it's about time that someone knocked Fortran programmers down a peg or two. It seems impossible to get any type of programming job if you don't know Fortran.
Every job classified ad section is filled to the brim with Fortran positions while less relevant languages like Java, C# and Visual Basic are almost completely neglected.
I for one welcome news like this if it help Fortran programmers acquire just a little humility.
I'm a big tall mofo.
The name "FORTRAN" came from "FORmula TRANslator." It was created so that engineers and scientists could write programs to perform calculations. They wouldn't need a degree in programming, and they wouldn't be reliant on programming staff. They would be able to independently take advantage of a company's (or university's) computing resources. It wasn't DESIGNED to be a pretty language; it was designed to be used by people who would have stared blankly at you if you'd mentioned the concept of a pretty language. It served its purpose well.
It reminds me of SQL in that respect. I have worked with managers who knew less about computers than their secretaries, but they were able to use SQL to write queries to get information that they wanted. SQL was written for that purpose. It ain't pretty, but it serves its target market.
I doubt that designers of armored cars and dump trucks worry about the slings and arrows of the Ferrari's designers; I think this rant is pretty much in the same vein as that. Beauty and utility are not synonymous.
if the article weren't broken
into such small pieces.
That way I could
print it for my students.
Sort of amusing for an article that discusses using white space in a good way.
As Nietsche famously said, "If you stare too long into the Abyss, 1d4 Tanar'ri of random type will attack you."
I have to say my interest in the article plunged through the floor when I saw the example using Bush/WMDs as the subject. I immediately realized I'm either reading something written by a college student or someone who has not matured much beyond that. How gauche.
Regardless of how you feel about the politics, it's just not kosher to use examples like that. Clearly this is a person with an axe to grind.
I read the fucking article. I didn't see too much very insightful, or see any specific reference to Fortran at all.
They're really starting to shake up the industry on slashdot, I'm sure this will create a lot of disruption in the massive FORTRAN industrial establishment. Oooh, next they should link an article criticizing ALGOL, that will shake up things even more.
I prided myself in college that I could write FORTRAN in any language. I had a prof that couldn't figure out why I was doing bit manipulation in COBOL. (Yes, this can be done in COBOL through multiplication and division, but it's really ugly.)
If you don't want crime to pay, let the government run it.
... people would have got the point. Christ even John Backus (FORTRAN's creator) said that FORTRAN and even all imperative languages were horrible ugly hack, and that we should all go away and use "[the] functional style, and it's algebra of programs".(warning: pdf link).
Since major companies like IBM have chosen to produce compilers that perform best with FORTRAN. (absoft markets the compilers with a front end)
I like C, and a slew of other languages much better...
But my G5 dual-processor desktop machine can be optimized to run at around 35 GFLOPS. Try that on an 8086 derivative What, maybe you can get 2-4 GFLOPS per machine (if a dual-processor system)? I have a low-end supercomputer on my desk! Unfortunately, without FORTRAN, it wouldn't be so super.
FORTRAN is the only language that will easily take advantage of the HW (Altivec 'velocity engine' and parallel processing).
Each language is good for some tasks. FORTRAN happens to be good for performance in science and engineering work.
1. Do not separate the presentation logic from the application logic. I love it when I have to search for a specific code function sandwiched between the visual element constructors and modifiers.
2. Do not create a data layer. It is great to search through thousands of line of code to change the sql code.
3. Use one very long class instead of separating the program's functionality into small atomic units. I just love 7th or 8th level if statements that are repeated everywhere.
4. Don't comment or doccument anything. Good code should be self docummenting right?
5. Don't handle exceptions. Good programs don't make em.
6. Don't use configuration files. Because we love to recompile everything to change settings.
Forgive my rant, it has been one long week... after another... of working with other people's code.
Cheers,
Adolfo
"I, for one, look forward to the day when I can think code and have it be done instead of writing it line-by-line."
So you have aspirations to be in management or an end user? I'm not clear here.
BSD is designed. Linux is grown. C++ libs
You had new punch cards to use? Back when I was in high school we had to recycle old punch cards from national elections, fill in the holes with white-out, cut new holes with our pen knife then tie them together with catgut!
The p/o'd response basically sounds like "He's equating Fortran with FORTRAN-66 (or 77)".
I know that I do this too. When someone says "It's written in FORTRAN" I don't think Fortran-95, I think FORTRAN-77... and I'm usually right.
I suspect that there are two reasons for this:
Which is a shame really because you should be judging the quality of the application - and not what it was written in. Seriously, if it does x and it does it quickly and well with a nice user interface - does it really matter that it was written in Algol 68?
As a by no-means perfect example, check out this site which is, I think, a reasonably nice looking application written in Visual Basic (it acts as a GUI to the free SMS gateways out there). I don't claim to have it perfect, but the feedback I've had from people indicate that they don't think it's the usual run-of-the-mill-vb-application.
Disclaimer: I wrote it and the preference section is a little nasty, but I'm working on it. Also, I know that VB is only really for doing RAD but I don't have the time or inclination to learn Visual C++.
Avantslash - View Slashdot cleanly on your mobile phone.
...but it's still quite possible to write readable and modular code even in Fortran 66.
(I'm saying this as a programmer who spent 12 of the past 15 years doing exactly that -- writing and maintaining Fortran 66 code that was part of a critical production system at a major airline).
As with any language, the onus is on the programmer who is writing the code to organize it and implement it in a way which is easy for subsequent programmers to follow and understand.
We were able to do it even within the limits and conventions present in the environment (external variable/parameter references limited to six (6) characters, internal references limited to either five (5) or one (1) character, subroutine names limited to six characters) by using common sense and trying to use a consistent coding style.
Yes, arithmetic IFs are ugly, computed GOTO statements can be confusing, and strings defined using Hollerith notation are strange to folks who haven't seen it before, and programs are hard to follow when everything is lined up neatly in column 7 without any spacing between code and comments. So don't use that style, avoid confusing notation, and refrain from using confusing syntax or statements which might make the intent of the program unclear.
It's the same advice in any languages -- cute tricks might save a few bytes or clock cycles, but in a production environment it's usually long-term MAINTAINABILITY that counts -- and that's true in *any* language!
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
For certain purposes (including most of what I do), fortran is unmatched.
It is *possible* to write C that runs as fast as Fortran for heavy math. However, it involves hand-optimizing your C until this happens.
Fortran handles calculations quite well, thank you. It take less Fortran code to handle many common operations, and array options are built in and optimized to high heaven.
With Fortran 90 and 95, the grammars that led to the CS horror (e.g., computed gotos) are marked either deleted or obsolescent (meaning expect deletion in another standard or two).
Also, due to the selection of which features are included in Fortran and which are not, Fortran compilers can make much stronger assumptions than, for example, C compilers working with pointers.
There's nothing unfortunate at all about Fortran's (not FORTRAN any more) role in scientific computing. The tragedy is the number of people who bought into those silly C campaigns.
hawk
Libraries - the most bullet-proof, battle-tested numerical code is pretty much all in FORTRAN
Optimizers - if you must wring the last factor of two of performance out of big vectorizing iron, and you're not a CS guru, the FORTRAN compiler is still your best bet
Semantics - FORTRAN the language enforces some constraints that make vectorizing optimization work better than less constrained stuff like C
The problem is, for these guys FORTRAN is a means to an end - most of them have had very little formal training in good coding practice, and worse, most of the code they read was written by people with similar experience.
Maybe what we should do is require scientists and engineers to pair-program with recent CS graduates. Both sides would learn a lot from that.
To a Lisp hacker, XML is S-expressions in drag.
" it's a lot quicker to write/maintain makes most of that speed differential meaningless." No it doesn't. Some of the FORTRAN code is used in algorithms that do things like Finite Element Analysis, High Energy Physics and Weather Prediction where it is not uncommon for something to run for HOURS or run many times with different variable settings (i.e. Monte Carlo). These systems invariably use highly optimized FORTRAN code. CPU time is NOT free and often an Engineer is charged a "tax" by IT for his CPU useage over his allocation. You only save the programmer time once, you save execution time EVERY run. I've worked in the Aerospace biz many years and have never seen big number crunching programs done in C/C++ or Java. I have seen some Assembler but not much. I've also written C code for embedded systems and I do know it can be written very efficently, but it's not at all optimized for Math thus FORTRAN beats it.
Certainly, you can write poorly in any language. But you can't necessarily do the opposite.
:P
For example, I initially resisted C++. I viewed it as poorly designed objects on C (after experiencing the beautifully done objects of LPC), and programming examples for it made objects of things that never should have been objects - and as such I wanted nothing to do with it.
However, the other features of C++ ended up proving themselves infinitely useful, and since the value of C++ objects has shot up notably in my mind. Examples:
Templates: I can't even imagine how many pieces of code I wrote before C++ in which I wrote different versions of the same function for different variable types. Talk about a maintainance nightmare
Const correctness: I remember resisting this like crazy, because it makes initial programming harder. But not only does it offer some serious benefits to the compiler at optimization time, but it's saved me many times from errors and really helped with code cleanup and refactoring into functions. My only real problem with it, now, is programmers who don't const their libraries, thus preventing me from consting variables that I need to pass to them at each step of the way.
Destructors: I don't think I need to even get into why having your variables clean up their memory when they go out of scope is probably the best thing that ever happened concerning fighting memory leaks. You can also do garbage collection with smart pointers, but that's a topic for some other time and is less standard.
std::vector: I can't believe that I used to not only have to clean up variable size arrays before, but used to have to have each array contain three variables - the pointer, the count of elements, and the allocated size - all of which would need to be checked and adjusted at each insertion and deletion.
std::string: A lot easier to use than C's unwieldy strings, and easy to convert to and from regular C strings.
I could go on for a long time... a good language can save you many programming headaches if you're willing to learn it.
We also have a halon fire extinguisher. Its always nice to have a fire extinguisher that kills people around.
Unfortunately, g95'S developer chose to rather violate the GPL than to either work together with the gcc people or at least let them use his code. Look here for more information on the split.