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...
I'm more of a western coder ... lots of wide open spaces in between clauses for readability. Documentation in bits rather than 100 lines of code then a paragraph about what happened in there.
I'm sure someone somewhere would gripe about my style too.
A feeling of having made the same mistake before: Deja Foobar
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.
So are they using "FORTRAN" as a adjective replacing "crappy" and then whipped up an article that has been covered in about 5,000 different programming books and/or documentation regarding some largely accepted guidelines for writing clean, manageable and efficient code?
Why is this on the front page?
"Acmqueue Click-thrus ACTIVATE!! Go Go Go!"
Sehr geehrter Toilettenbenutzer!
For the uninitiated, Brainfuck's a Turing Complete language with eight language statements, each consisting of a single character:
> increment the pointer.
+ increment the byte at the pointer.
- decrement the byte at the pointer.
. output from the byte at the pointer (ASCII).
, input to the byte at the pointer (ASCII)
[ jump forward to the statement after the corresponding ] if the byte at the pointer is zero.
] jump back to the statement after the corresponding [ if the byte at the pointer is nonzero.
I'd post actual code, but the /. filter is fucking me up.
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
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.
I think people like perl because you can do cool things in a short program with it, not because it's beautiful.
I am trolling
So what if Fortran is ugly--all languages get uglier the less they are used and the more high-level languages are developed. I'm sure lots of people would look at assembly code and say it's ugly too. It's only a matter of time before our kids look at C++ code and say, "Boy, am I glad I didn't have to program like that!".
Kinda reminds me of "Back to the Future III" where Marty plays that shoot-em-up arcade game in front of kids, and all they can do is complain "You mean you have to use your hands. That's like a baby's toy."
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.
... 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.
The existence of Perl poetry says that you're wrong...
While Fortran 77 is ugly and I saw terrible programs written in Fortran 77, Fortran 90 or 95 is a pretty modern and nice language and if you know C, it is easy to learn Fortran 90. It is not that much different from anything else. It is great in numerical programs (especially linear algebra) as the matrix handling is nice and fast. The only problem is that only recently free (as in speech) Fortran 90 compilers has become available and they are still in beta stage. However, for Linux, Intel Fortan Compiler is free (as in beer) and works fine. It includes also documentation of the language so you may try it.
Save the bandwidth. Don't use sigs!
Heh. The quote of the day at the bottom of slasdot was somthing like "HONK USE IF THEN" earlier this morning.
-Peter
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
... or did they consistently replace "APL" with "FORTRAN" in the article.
I could fix that for them with sed, or maybe a Perl script. Now, where did I leave all my leaning toothpicks...
Eloi, Eloi, lema sabachtani?
www.fogbound.net
Have you ever had the misfortune of working with APL?
...except that each time a page loads, a new set of ads is displayed, potentially making it more profitable for the author.
So the artificial 'page' breaks are a byproduct of profit motive, nothing more.
Sad, but true.
the keycard punched YOU!
Is something burning?
Oh, it's my karma.
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.
[A two page ad. A middle-age man with a youthful, shy grin, dark horn-rimmed glasses, slicked, short hair, and the premonition of a hairy chest emerging from a blue denim(?) shirt, fills the left page; the vista of urban sprawl outside a window behind him; painted scrawls of mathematical formulas superimposed. On the right hand page is a block of sans-serif text]
Meet an elder statesman in the computer business.
IBM's Jon Backus is 43, pretty young for an elder statesman in most industries. But then, the computer business is less than 20 years old and a mathematician Bakcus has been in it since the beginning. He started workig with computers in the early 1950's. It was about the time a leading business magazine estimated that no more than 50 companies would ever have use for a comptuer. Today, it is estimated that there are well over 50,000 comptuer installations in the United States alone. Part of the reason for this astonishing growth: the progress made in programming. In this field, John Backus was a pioneer. "It bothered us, in the early days of computers, that so few people coluld use them" he says. "One reason was, programming cost as much as the machine. A small compnay just couldn't afford data processing." With a small group of associates, John Backus tackled the problem and stayed with it for three years. The result was the simplified programming system called FORTRAN (FORmula TRANslator) which made programming considerably less expensive than before. Today, FORTRAN is probably the most widely used programming system in the world. Currently, John Backus is working on a new mathematical concept which is still in the realm of pure theory. But his theories, like the work of many IBM scientists, ultimately have a way of making computers more useful.
[A red line runs across the text. A matching red 'IBM' (not the blue, CRT lines version) appears in the margin.]
From a beginning less than two decades ago, computer technology has made remarkable progress. John Backus is one of many outstanding men and women in the industry who have turned a laboratory marvel into tens of thousands of computers helping people around the world.
...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
There is Visual Fortran and Fortran .NET. Visual Fortran I've actually seen and installed on a computer. Watching one of the grad students start to write a Windows program, with GUI, in Fortran was rather scary. I haven't messed with Fortran .NET but apparantly you can really generate .NET code with it. This also mean that one could write stuff in Fortran and call it from C++. To make things even scarier, there's a PERL .NET kit. So one could write a PERL program that calls on Fortran.
:)
These are things man was not meant to do
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.
We're still using F77 here, so I didn't know that. :-)
Fortran 90/95/2003 are well worth 'upgrading' to -- for starters, the array syntax is fantastic. If A and B are arrays, you can assign from one to another simply by 'A=B'. Likewise, 'A=sin(B)' would set each element of A to the sine of the corresponding element of B. Code like this is a doddle to parallelize automatically, enabling one to write parallel code with very little effort.
Tubal-Cain smokes the white owl.
" 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.
As somebody that has been programing for 25 years, all I can say with regard to this article is "Well, duh! Tell me something I don't already know!" Seriously, if you've been programming for more than 3 years and haven't already figured out by yourself (and by bad example) how to write understandable code, maybe you shouldn't be programming!
I've abandoned my search for truth; now I'm just looking for some useful delusions.
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.
FORTRAN (FORmula TRANslation) was never meant to be a general-purpose programming language, it is strongly biased towards scientific calculations. It has native support for doing fast computations with scalars and arrays of integer, real and complex data types. In modern revisions of the language (F90/95, Fortran 2000/2003) it gained support for dynamic memory allocation (although there is no garbage collection), abstract data types, pointers and object-oriented programming but few people use these capabilities. And yes, it is possible to write beautiful programs in FORTRAN although bad practices prevail due to the backwards capability of modern FORTRAN with F66/F77.
- You don't have enough experience reading/writing code. You have to read (more so than write) a tremendous amount of code to get good at reading code.
- You don't understand the problem the code is solving.
- The code is very badly designed at a higher level than things like white space and underscores.
A lot of people get frustrated when they don't understand code right away, and rather than trying to grok why they don't understand it (because 2/3rds of the time it is the reader's fault, not the coders), they just bitch about white space and brace placement. That is never the problem.For the second case:
#include <iostream>
class A { public: virtual void do_something() { std::cout << "A" << std::endl; } };
class B:public A { public: virtual void do_something() { std::cout << "B" << std::endl; } };
void myfunc(A& a) {
a.do_something();
}
Does this code print A or B when myfunc is called? Which do_something() is executed? Unless you are using function pointers, this ambiguity does not exist in C (or FORTRAN)
For the first case I wrote:
There is no way of telling just by looking at this code.
in C if I have int i; do_something(i); I know that i doesn't change. I don't need to look at the prototype (ok do_something could be a macro)
What I would have liked is for the caller to a non-const reference to still have to write that '&'. The callee gets the benefit of the reference and anyone looking at the caller code immediately knows that there might be something happening that isn't explicit in the code they are looking at.
In theory a smart syntax highlighter could do this but it would probably have to almost be a compiler to handle this, especially if you want it to be correct, even in the face of macros. And I don't want to have to wait for a compilation every time I load a file up into my editor.
An editor could not handle something like:
#ifdef REALLY_SCREW_THINGS_UP
void shit(int& i) { i=i+1; }
#else
void shit(int i) { }
#endif
int main() {
int i=0;
shit(i);
}
But a compiler could have refused to compile unless that call in main was changed to shit(&i); if REALLY_SCREW_THINGS_UP was defined.
God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.