7 ms·

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 pro

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.

lloeki 10y ago
"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 https://en.wikipedia.org/wiki/Fortran#Fortran_90
cm2187 10y ago
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.
- pjmlp 10y ago
  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
  - cr0sh 10y ago
    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?).
moomin 10y ago
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.
- photon-torpedo 10y ago
  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.
  - germanier 10y ago
    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.
    - alephnil 10y ago
      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".
      - moomin 10y ago
        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.
dagw 10y ago
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?
- neurostimulant 10y ago
  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.
  - gpderetta 10y ago
    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.
vog 10y ago
> 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).
- nicoburns 10y ago
  A third variant: SELECT * FROM my table has a purpose, which is to visually separate SQL statements from table and column names.
  - lostboys67 10y ago
    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
  - vog 10y ago
    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.
    - lostboys67 10y ago
      you do know that some SQL's are case sensitive for table names etc ?
lostboys67 10y ago
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)
- Sean1708 10y ago
  I think you could also use 'implicit none', or something like that, to prevent the implicit typing.
chestervonwinch 10y ago
> 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/ http://www.netlib.org/lapack/double/
david-given 10y ago
> 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.
ams6110 10y ago
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.
pmontra 10y ago
> 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.

lloeki 10y ago

"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 https://en.wikipedia.org/wiki/Fortran#Fortran_90

cm2187 10y ago

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.

pjmlp 10y ago
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
- cr0sh 10y ago
  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?).

moomin 10y ago

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.

photon-torpedo 10y ago
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.
- germanier 10y ago
  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.
  - alephnil 10y ago
    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".
    - moomin 10y ago
      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.

dagw 10y ago

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?

neurostimulant 10y ago
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.
- gpderetta 10y ago
  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.

vog 10y ago

> 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).

nicoburns 10y ago
A third variant: SELECT * FROM my table has a purpose, which is to visually separate SQL statements from table and column names.
- lostboys67 10y ago
  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
- vog 10y ago
  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.
  - lostboys67 10y ago
    you do know that some SQL's are case sensitive for table names etc ?

lostboys67 10y ago

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)

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

chestervonwinch 10y ago

> 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/ http://www.netlib.org/lapack/double/

david-given 10y ago

> 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.

ams6110 10y ago

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.

pmontra 10y ago

> 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.