h1. Haskell vs. Fortran Disclaimer: I do not write Fortran, just learned it from Internet to compare, so this article may miss something. Fortran 90 may have some of those problems fixed, but 1. In totally kludged way 2. Nobody uses it anyway, and libs are in 77 (See *Legacy*), h2. Fortran isn't lazy Laziness[1] of Haskell allows it to make superior compile-time optimizations and allows user to write simpler code, not worrying about evaluation order. h2. Fortran has lame syntax constructs all over the place. Syntactic sugar is good, but lots of "special cases" isn't. One of examples is Fortran's output formats. Vary lame embedded language, C's printf does much better job while not requiring language extensions. Haskell has only required minimum of syntactic constructs, and none of them are use-specific. One the other hand, embedded DSLs are easy to write in language itself, and they typecheck with the rest of program. h2. Indentation is nuts Position counts. Even "python":nopython doesn't have such shit. In Haskell, indentation is optional and limits to "new indentation level continues previous line". h2. Recursion Fortran does not allow recursion. This denies the possibility of writing declarative, easy understandable programs, forcing coder to fall back to iterative algorithm unrolling. Haskell has recursion without any kludges, and its compiler can optimize "tail recursion":http://en.wikipedia.org/wiki/Tail_recursion, eliminating the call stack overflow problem. h2. Legacy Fortran suffers the same problem as C++: compatibility with its predecessor. Fortran 90 advances the language to bearable level, but nobody needs it, since all the libraries are written in archaic Fortran anyway. And if libraries have to be rewritten, what's the point in writing in same language? There are much better ones. h2. Formula translation. Fortran is imperative language, that means that user has to explicitly state the order of evaluation. That makes its niche as "*for*mula *tran*slator" rather questionable. Are formulas iterative descriptions of evaluation? No, they are beautiful sets of rules, which output depends only on input. Here's factorial, as it's described in traditional maths. !http://dump.bitcheese.net/images/sitabas/fac-maths.png! Here's how it's written in Fortran: bc. function fact(n) integer fact, n, p p = 1 do i = 1, n p = p * i end do fact = p end Of course, mathematicians write such shit too. !http://dump.bitcheese.net/images/dinezaz/math-shit.png! Doesn't look *so* bad though. And now, factorial in haskell! (Not to hurt fortranners' feelings, a straightforward version. It may be even better) bc. fac n | n == 1 = 1 | otherwise = fac (n - 1) * n Which one does look more like formula? h2. Beating the children with 16kg weights As i said before, fortran is imperative. This means that functions are pre-defined and special cases. Look at this non-working Fortran code: bc. PROGRAM TRIAL REAL A,B,C,V1 V2 = FUN V1 = V2(A,B,C) END REAL FUNCTION FUN(X,Y,Z) FUN = X*Y**Z END In haskell, you can treat functions just like values of any other type. bc. f1 x = x + 1 f2 = (+1) f3 = f1 main = do print $ map ($ 3) [f1, f2, f3] Line 1: Plain function definition Line 2: Function is defined using partial application (+ requires two arguments, but given one, and it will take second argument when applied to some value) Line 3: Function is defined as equal to some other function ... Last line: all the functions are applied to value 3. Result is [4,4,4], meaning all the functions do the same thing: add 1 to argument. Fortran's *call()* is so lame and insecure, that it isn't even worth mentioning. fn1. It's when calculations are performed as they are needed, not as they are mentioned.