Hacker News Reader

Comment by phantom_oracle | Hacker News Reader

1) What makes a language like Fortran so intimidating?

I know it's the butt of many jokes (together with Cobol and Assembly - especially in the context "really hard to learn/use languages) but just scrolling through the github repo (frontpage), the code doesn't seem that intimidating (or any less confusing than Go would seem for someone unfamiliar with its nuances).

2) What makes Fortran so much 'faster' at computation than C?

C is the go-to for any low-level performance, but in terms of computation, Fortran seems to do better (or so we're told). Is/Was Fortran a better-designed language, that allowed it to perform better than C at computation?

View on HN

Modern fortran dialect is actually not so bad. It's actually pretty awesome and let you develop program that take advantage of distributed computing and gpu processing easily. Also, I don't think any mainstream languages these days have vector operations as good as what fortran currently have. But the old one is pretty horrible though, just like most other languages from 30 years ago when compared to modern languages. The things that annoy me the most when working with legacy fortran code a while ago (does not apply to modern fortran dialects):

- very terse and cryptic variable naming. Understandable since fortran 77 only allows variable to contains up to 6 characters. But it makes working with large codebase very painful.

- You had to use upper case only. It may not sounds a big deal, but you'll get tired of it eventually when working with lots of fortran code.

- Implicit typing: If your variable starts with i-n character, it will be treated as integer. Otherwise it's a float. You better not forgetting this one or terrible bugs will appears on your code.

- Source code fixed format: your source code must conform to this format or the compiler won't recognize it:

  - only the first 72 chars get parsed; 
  - first 5 characters/columns of the line must be blank or contain numeric label
  - if your code is not going to fit in one line, you can extend to the next line by marking it with a non-numeric character in the 6th columns. otherwise it should be blank.

I think there are more annoyances but those are the ones that I still remember to this day.

It's exactly the same story with the original BASIC, VB6 and modern Visual Basic. There is a lot of hostility (including on HN) to VB, but usually meant against the early BASIC or VB6. Modern VB.net is very similar to C#, just case insensitive and with words instead of special characters. Microsoft broke backward compatibility when moving to .net, precisely to avoid the sort of legacy annoyances you are describing with Fortran.

Yet VB 6 had two nice features that we had to wait until .NET Native and .NET Core to get it back.

- AOT compilation straight native code

- Distributing the runtime with the application, instead of a central installed location

Personally I wish VB6 had the class declaration capability of what the Actuate Reporting suite had for it's "VB-like" language (from what I remember from back then). It was like having everything you have in Java/C++ - but for VB.

Probably the closest you can get today would be one of the more modern BASICs out there (QB64 or GAMBAS - maybe FreeBASIC?).

"modern" stuff such as free format and identifiers up to 31 chars have been available ever since F90[0] (all the while being compatible with F77 code) released in 1991. AFAICT people stuck with writing (and complaining about) F77-like code because habits.

[0]: https://en.wikipedia.org/wiki/Fortran#Fortran_90

Back in the day, I helped a student fix some Fortran code. They had variables X and Y, and the reciprocals were stored in INVX and INVY.

This is quite common in legacy Fortran codes. The reason is that these reciprocals are probably later used in many multiplications (e.g. for scaling a vector) which is faster than doing many divisions. Well, nowadays the compiler would optimize that for you, but back then either compilers wouldn't do that, or people woudn't want to rely on it.

That's all fine but X and Y were floats while INVX and INVY were integers due to implicit typing. Probably not what they wanted.

Only if implicitly declared. You could define them as reals, and in well written code, you would.

That is why you have the old joke that "God is real, unless declared otherwise".

Yes, you could, but the poor sap who'd only just started programming ended up having to ask the mathmo who knew a bit about computers.

It's actually pretty awesome and let you develop program that take advantage of distributed computing and gpu processing easily.

What do you use for the easy GPU processing? PGI? Or is there something else (hopefully open source) that you've found that works?

I was using the PGI compiler. I'm not aware of any open source implementation that can automatically take advantage of cuda gpu back when I was still working with fortran-related projects. Not sure about now.

Allegedly GCC support GPU (ptx in particular, for NVIDIA) offloading. I don't know whether the performance is competitive and whether it can be used to speed-up fortran co-arrays (which I, as a non-fortran programmer, would expect to be the way that functionality would be made available to fortran). OpenMP should work as well.

> You had to use upper case only. It may not sounds a big deal, but you'll get tired of it eventually when working with lots of fortran code.

Fun fact: Nowadays people are doing the same with SQL - even though there is absolutely no reason to do so.

   select * from mytable

is as good as:

   SELECT * FROM MYTABLE

Nowadays, upper case SQL seems to be a sign that the code is either 1) auto-generated by an ORM, or 2) written by a novice, or 3) written by a project with very strange coding styles (the last two seems to be some kind of cargo culting).

A third variant:

SELECT * FROM my table

has a purpose, which is to visually separate SQL statements from table and column names.

Which is how you should write SQL in my opinion (and many others) it makes it much clearer and easier to understand.

The other advantage it makes bugs where you use a Reserved word where you should not much easier to see visually

Indeed, this is a common workaround when your editor has no proper syntax highlighting. Still, in today's world nobody would write in that style in other programming languages.

You see the same issue with other relicts, for example, Pascal back in the 90s. Old text books wrote Pascal in uppercase style:

  PROGRAM HelloWorld(output);
  BEGIN
     ...
  END.

But in reality, everybody using e.g. the Turbo Pascal IDE wrote lowercase instead, because it easier to type and because of proper syntax highlighting:

  program HelloWorld(output);
  begin
     ...
  end.

Maybe this is not so much about the maturity of the developers (as I assumed in the previous comment), but about the maturity of the tooling.

you do know that some SQL's are case sensitive for table names etc ?

Hence I found it easier to keep all lowercase to avoid headaches.

There's also a good argument for not relying on "proper" syntax highlighting which is not always available -- especially not for such a divergent language family as SQL.

Every RDBMS has its own set of keywords and reserved words, so it's pretty much impossible to maintain a "proper" syntax highlighting mode.

Pretty much this - hence my upvote for you.

I also like to stylistically indent my SQL to make it easier to follow. This works well for most typically use cases, but it can fail horribly when you start to certain kinds of JOINs and such - the indenting will make things more difficult to read.

Of course, once you start doing really wild things with SQL, no amount of casing or indentation will save you.

Had a purpose. Now we have syntax highlighting.

I personally like using uppercase for all the keywords, e.g. "SELECT * FROM mytable". I think it makes it more readable.

EDIT: Missed that the sibling comment said the same thing...

I like standards. Seriously, is this woefully out of date: http://www.sqlstyle.guide/ ?

Also see https://pypi.python.org/pypi/sqlparse

I can recall at my first job (muble years ago) being considered a bit flash because I used Mixed case in my Hollerith statements for prompts ;-)

The Fixed code format went away a long time ago (it was to fit on a 80 col punched card) any one using F77 and later in the last 30+ years will have used free format

And the MAGIC is REAL unless declared INTEGER - professional Fortan programmers declare everything! (well apart form loop indexes I j etc)

I think you could also use 'implicit none', or something like that, to prevent the implicit typing.

> fortran 77 only allows variable to contains up to 6 characters

I never knew that! I've always wondered why the BLAS / LAPACK routines had such frustratingly concise names (dgesv, dgbsv, dposv, ... just grabbing the top few from [1]).

[1]: http://www.netlib.org/lapack/double/

> Implicit typing: If your variable starts with i-n character, it will be treated as integer. Otherwise it's a float.

Hence the old Fortran joke: God is real --- unless declared integer.

All of the formatting restrictions are because the language was developed in the punch-card and teletype era. You had 80 columns per card/line and only upper case.

> the old one is pretty horrible though, just like most other languages from 30 years ago when compared to modern languages

Maybe 50? To put modern into perspective, 30 years ago is 1986 and Python is from 1989. A bunch of other mainstream languages are only slightly younger: Ruby, Java, JavaScript, PHP. I think C++ is not much older than that.

> 2) What makes Fortran so much 'faster' at computation than C?

I think it's more like this: As long as the numerics is vectors, matrices and multidimensional arrays (no complex graph or tree data structures implemented with pointers, no string manipulation, no bit-level fiddling), a scientist or engineer who spent less than a week learning Fortran, can write code, almost in a first pass, with nice array notation, that is close to as performant as a relatively seasoned C-expert could write.

Wow. This should be the canonical answer for all Why Fortran performance questions. Never thought about this effectiveness/experience advantage in Fortran's favour.

Nice.

Is there an introduction, available online, to Fortran support for vector/matrix operation?

Is it true that pointers are completely non-existent in Fortran? This may be related to your point about data structures.

I've heard there is no null dereferencing and pointer nonsense - all without the need for a garbage collector - which ultimately leads to Fortran's great reputation for speed.

Fortran has pointers since Fortran 90. But you don't always need to resort to pointers like in C, as Fortran also has allocatable arrays. You can still follow a null pointer, though, if you don't test for it first.

1) Lack of heap-allocated convenient strings, dynamic lists and a dict/hashmap structure. They would not need to be fast, but the total lack of such types built in means that you cannot even deserialse a JSON or YAML config file without it getting very verbose.

2) Main reason it is faster than C is all arrays are nonaliasable by default (e.g. if you have two arrays as arguments to a function you know they do not occupy the same memory). This enables some important optimizations. In C99 there is the __restrict__ intrinsic to declare the same thing in which case C99 is just as fast. However you still need to write a lot more code in C99 since you need to write loops, while in Fortran "a+b" can add together two arrays (with full compiler support for optimized array expressions).

> 1) Lack of heap-allocated convenient strings

As of Fortran 2003, there's allocatable scalars, including strings (type "character" in Fortran). There's also "allocate on assignment", which is also nice (that is, you don't need to manually allocate an empty character first before writing stuff to it).

> dynamic lists and a dict/hashmap structure.

As of Fortran 90, with pointers and derived types, you can do it yourself, just like in C. But yeah, sometimes it's frustrating that the standard library is so limited (again, not that much worse than C, but compared to many modern languages, certainly).

Heap-allocated was a bad choice of words. I mean strings that allow you to do "a+b" or similar simple concatenation built in almost any other language has (not C though, although there null-termination and stdlib helps a lot more than Fortran character arrays does). Though I guess one could roll one own here too, same as with lists and dicts and so on.

In Fortran you can overload the "+" operator for string concatenation, if you like.

> I mean strings that allow you to do "a+b" or similar simple concatenation

Meet "//", the character concatenation operator. Part of Fortran at least since the FORTRAN 77 standard.

With the F2003 additions I mentioned, one can do stuff like

  program stringtest
    implicit none
    character(:), allocatable :: s
    s = "hello"
    s = s // " world"
    print *, s
  end program stringtest

where the first executable statement (s = "hello") allocates space for "hello" on the heap, and the second statement reallocates that heap space to now have room for the previous contents + " world".

And since Fortran allocatables are a bit like C++ RAII, they are automatically deallocated when they go out of scope.

Is this as convenient as doing string handling in, say, python? IMHO, no, but better than plain C + stdlib.

> 1) What makes a language like Fortran so intimidating?

FORTRAN 77 (and FORTRAN 66) was a pretty primitive language. Source code still used line numbers, no malloc, no recursion (there is a workaround, though), very cumbersome text manipulation.

When Pascal and C got popular in the 70s and 80s, FORTRAN 77 felt ancient in comparison.

I guess the jokes originate in the 80s, and from then on they have lived in the folklore, told to new generations. Fortran 90 came only in 1992 (and then later 95/03/08) and while it is much modernized, I don't think the people telling the jokes have yet looked at it.

1. I think it's that most people remember the bad old Fortran, with horrors like EQUIVALENCE (telling the compiler to use the same memory for various arrays that you just _knew_ would never be used at the same time, honest! OTOH, back in the bad old days of not much memory, you didn't have much choice) and COMMON blocks, as well as the fixed format layout and stuff others have already mentioned. Early versions of Fortran didn't necessarily support recursion. Spaces weren't significant, and Fortran had no notion of what Algol 68 called "stropping" to mark keywords, hence the infamous

    DO 100 I = 1.10

which the programmer thinks sets up a DO loop to run ten times but instead assigns 1.10 to a variable called DO100I, thanks to the period that should be a comma. Then there was the infamous H (Hollerith) format item; to get a literal string int formatted output you had to use it and had to count characters rather than using a string literal, so

    100  FORMAT(10HHELLO WORLD)

has an off-by-one error.

2. Pointers. Fortran explicitly states it will make assumptions that let it ignore impediments to optimization that pointers can cause. C has the "strict aliasing rule" and the "restrict" keyword that help, but not enough.

Forgot one really fun aspect of old Fortran. It was call by reference, with the following fun result:

    ....
    CALL MUNG(2)
    I = J + 2
    ...
    SUBROUTINE MUNG(N)
    N = 42
    RETURN
    END

After passing the constant 2 to MUNG, later uses of 2 will actually give you the value 42. Have fun debugging that!

1) Old Fortran code was intimidating. New Fortran isn't.

2) C can be faster than Fortran (not by a lot mind you). But when it comes to math-y type things, Fortran code can be made very, very fast, and can be parallelized with little to no effort.

One interesting feature of Fortran that might help with the second question is how restricted the use of pointers is. A Fortran compiler has very strong guarantees that any two arrays do not overlap, hence some optimizations can be easier to prove safe.

> One interesting feature of Fortran that might help with the second question is how restricted the use of pointers is.

There is no restrictions in the use of pointers in Fortran, the compiler knows pointers can overlap. The restriction is when arrays are passed as arrays (passed by reference internally), not pointers.

Oh, there are. In particular, actual variables and arrays can be pointed to only if explicitly declared as "target".

1) What makes a language like Fortran so intimidating?

I wonder the same thing: there is irrational contempt towards Fortran here on Hacker News. I think it says more about the attitude than it does about Fortran.

2) What makes Fortran so much 'faster' at computation than C?

two things: the compilers are excellent, and produce really fast machine code, and intel has invested tremendous amount of engineering, with focus on exploiting the newest features of their processors (such as AVX2). The new ifort compiler comes out every six months. Others like PGI have produced a Fortran compiler which can generate NVidia GPU code. Fortran compiler technology and Fortran the language standard / features are on the cutting edge of the domain Fortran is designed to handle, computing. And since Fortran can actually handle strings and has regex support, I've often wondered what it would be like for web applications...

1) What makes a language like Fortran so intimidating?

I'm not sure, I would like to know the answer to this. At least for modern Fortran.

2) What makes Fortran so much 'faster' at computation than C?

I don't know if the computation of Fortran is always faster than C (I thought they were comparable), but at least in development time, it was a huge improvement for me. I was forced to use Fortran 2003 at university for numerical simulations etc and expected it to be terrifying but found it very pleasant. Instead it was when programming C later on that I got slightly frustrated.

- It's easy to learn. No need to learn about pointers etc.

- It's very math friendly. The fact that you can easily extract and use sub matrices/array is probably my favorite feature. In C I needed to write loops, pass around array length or matrix sizes, etc. Multi dimensional arrays got annoying to work with and ended up writing matrices as column-major vectors.

- It has some nice built in functions such as matrix multiplications (no loops for this). It also has great math libraries like BLAS/LAPACK

- Offers OOP

I haven't made use yet of the advantage I hear most often i.e. for HPC.

"What makes a language like Fortran so intimidating?"

Some versions of Fortran are optimised at compiler level for hardware, hence question #2 is moot. [0] Note the level of optimisation on linux [1] required to speed the code up.

[0] https://en.wikipedia.org/wiki/Intel_Fortran_Compiler

[1] https://software.intel.com/en-us/articles/using-intel-compil...

I don't think giving an answer to a question makes that question moot.

"What makes Fortran so much 'faster' at computation than C"

What I mean is the reason C isn't faster is because of the hardware support at processor level and extra library support for example in IFort. Is writing/re-writing a problem in another language when there is an existing well documented body of code is premature optimisation?

I think what they meant was that the specific answer made the question uninteresting.

Doesn't ICC do exactly the same thing though? I'm fairly sure you still get the performance disparity.

re 1. It is (too) simple and lacks higher level features

re 2. It is simple so easier to optimise.

Regarding 1 again, I can't find it right now but the fact that Fortran could not even read it's own source code was one of the motivations for Ratfor; a C-like preprocessor for Fortran. By the esteemed Brian Kernighan.

https://en.wikipedia.org/wiki/Ratfor

Reply on news.ycombinator.com