Hacker News Reader

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

> 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

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

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/

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.

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

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.

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.