A Forlorn Hope of Fortran Modernisation | Hacker News Reader

A Forlorn Hope of Fortran Modernisation

amenzwa.github.io

28 pointsElzair19 comments

I feel like the author is just wasting the reader's time. This thing is 88 printed pages (probably 50 if he had used a reasonable font size) of somewhat dubious history of programming languages, a section of options, and then a long section on his fantasy ideal language to replace Fortran. Finally, in the conclusion, he does a rug pull. The conclusion is that he wants is something like this:

https://martinfowler.com/bliki/IntentionalSoftware.html

Quoting the overlong piece:

> subversion and sedition—Right so, I now divulge my most subversive idea regarding programming language syntax: every programmer on every project ought to be free to choose the syntax he favours. [emphasis in original]

Only he doesn't mention the prior art at all, I'm not sure if he's even aware of it.

Fortran seems to attract a lot of this sort of thing, perhaps because the language has had no real leadership since the ISO committee began jumping the shark in the 2000’s.

I loved how the Fortress language was coming slong till Oracle killed it. It was an interesting mix if Fortran and functional programming ideas with thoughtful ideas on parallelization.

Fortress (programming language) - Wikipedia "Fortress (programming language) - Wikipedia" https://en.wikipedia.org/wiki/Fortress_(programming_language...

It’s a tragedy. I feel the work they were doing was important. At least we got this talk from guy steele

https://www.youtube.com/watch?v=lw6TaiXzHAE

Yes. I was loving how it was shaping up.

I think the OP's thoughts are really deep, but I disagree on some points.Personally, I think the suggestion in the OP about switching Fortran to row-major is a separate issue. I have doubts about whether scientific languages should make such a switch. Rather, I consider it Fortran's competitive advantage. You can directly bring mathematical thinking into it. There are also cache related concerns.

Because it's an array oriented language, I think the need for a tracing GC is relatively low. The advantage of GC comes into play when object graphs are complex, but looking at old Fortran code, arrays mostly operate outside that domain.

In reality, the biggest problem is that Python has become too mainstream, and hardware performance has improved too much. Old numerical computation books were mostly in Fortran, but now they're in Python. The reason is simpler than you might think. Python has a strong ecosystem for visualization packages. Beyond just interfacing with Fortran, Python is more powerful as a working environment. And most scientists, who prioritize building their careers around papers with smaller scale computations rather than large scale Fortran dominated calculations requiring massive equipment, have gravitated toward Python, which lets them quickly sketch ideas.

And realistically, Python's greatest strength is that while it's inadequate in almost every area, it can do almost everything. I think that's the most important factor in language choice. Once you learn Python, you can do EDA, ETL, numerical computation, build websites, create apps with Qt, and much more. There are performance bottlenecks due to the GIL, but most tasks don't actually require that level of performance.

Fortran can push hardware to its limits when used well, but as such hardware intensive tasks increasingly shift toward large scale collaborative work, I think it's been losing its competitive edge.

It's not that Fortran is bad, but realistically, being able to do many things matters more. Before Python became widely used, programming books had too many languages for each domain. Math had Maple, and so on. But Python, honestly, just works because you can do a lot with it if you're willing to sacrifice a bit of performance. Many people say 'performance is important,' but I question whether there are really that many tasks where performance matters that much

p.s This is my post about the difference between row-major and column-major order.(https://www.makonea.com/en-US/blog/why-c-family-nested-for-l...)

I agree with the explanation you give at that link.

For linear algebra, the Fortran convention, "column-major" is indeed superior.

This is most obvious when computing a matrix-vector product, i.e. a linear transformation of a vector, which is a very common operation.

In schools this operation is typically taught in the wrong way, i.e. by computing scalar products of row vectors from the matrix with the column vector operand.

This naive method is inefficient. The correct method that must be used in computers is to avoid scalar products, but use the so-called AXPY operation (from its BLAS name. i.e. scalar A times vector X Plus vector Y), where the operands are column vectors from the matrix and the column vector that is the second operand of the matrix-vector product.

Therefore, to compute the product one needs to read columns from the matrix, so for maximum throughput the elements of a column must be stored sequentially.

In schools, also the matrix-matrix product is taught in the wrong way, with scalar products between row vectors and column vectors.

The correct way also avoids the inefficient scalar products and replaces them with tensor products of column vectors.

hank you for your response. I didn't know there was a pattern called AXPY. I was vaguely aware that something like that was used, but I didn't know it was called AXPY. Thanks to you, I've learned a new term. I'll save this for myself as well. Thank you for the kind explanation

> remove bit twiddling — System programming languages like C, C++, Odin, and Zig need to manipulate bits, but a scientific DSL like Fortran does not need bit twiddling operators like &, |, ~, and so on. Bits are, after all, hardware-level concepts.

Yeah no, your language will be DOA if you don't have bit twiddling, because you can't write arbitrary binary file parser / writer without some sort of bit manipulation.

Even matlab have bit twiddling function

Also bit twiddling is very useful in a scientific language when you want to "simulate" a lower level embedded processor, typically fixed or floating DSP or controls code. For example MATLAB/simulink are very commonly used as a high level language before porting the algorithm to a DSP, FPGA, or ASIC, and for this they support bit twiddling and integer/fixed point arithmetic.

Those who don't have bit twiddling instructions are doomed to rebuild them badly via heavier actions and compiler optimizations.

That brings up some weird memories.. I saw 2 different researchers do bit manipulation in Matlab by printing the binary data as hexadecimal string, doing string manipulation on it and convert it back to binary

This point was weird, since Fortran has never had bitwise operators, as such. (It has had bitwise intrinsic functions since the “mil-spec” extensions in the late 70’s.)

"At present, no language can rival, let alone surpass, Fortran when it comes to implementing long-lived, large-scale, massively-parallel scientific and engineering applications; not even C and C++."

Huh??? A tremendous amount of scientific computing happens in C, C++, and many other languages. I have worked with Fortran, worked with Fortran-heavy labs in academia, and this is just a nonsensical thing to say.

But he didn’t say “scientific computing”. There are not “many other languages” that are used for the stuff that he did describe. Nevertheless, his claim is incorrect. C, C++, Julia, and Fortran are all routinely used for these purposes, sometimes with parts written in assembly. Nothing else, really. The “scientific computing” that people do with Python, Matlab, etc. is not this.

And of these four languages that are successful in this arena, only Fortran and Julia are enjoyable to program in. Between those two, Julia is far more fun and flexible (but brings other drawbacks, of course).

> FORTRAN stands for “formula translator”, which hints at its mathematical lineage.

A choice of name doesn’t provide a “mathematical lineage”, and there’s no sense in which Fortran is any more “mathematical” than other programming languages - if anything, it’s less mathematical than the functional languages.

Articles like this are written by the kind of people Max Planck referred to. Like the physical sciences, computer science advances one funeral at a time.

Ctran and Fortran look similar if you ignore much of the flexibility of C and help the optimizer out re memory overlap. Wave the checkbook and you’ll have programmers. Way easier than COBOL.

Small mistakes in TFA:

> Simula (1962) the first object-oriented (OO).

No, Simula (1962) was not object-oriented. Only its successor "Simula 67", which was described publicly in some papers in the first half of 1968, was the first "object-oriented" language, by inventing the "virtual" procedures and functions, and also class inheritance. Simula 67 inherited most of its concepts and terminology, including keywords like "class" and "new", from a crucial paper published by C. A. R. Hoare in November 1965-11, "Record Handling". Except for its new object-oriented features and for the features taken from Hoare, Simula 67 was a language very similar to ALGOL 60.

> ALGOL (1958)

"ALGOL" did not exist in 1958. In December 1958, a description of IAL (International Algebraic Language) was published. IAL is the predecessor of ALGOL 60, which was published in May 1960.

A significant part of ALGOL 60 was already present in IAL (1958), but some important parts of IAL were deleted and some new very important features were added in ALGOL 60. The differences between IAL and ALGOL 60 are comparable with the differences between C and C++, i.e. they are related languages, but they are also very different.

ALGOL 60 introduced the concept of "block" with local variables that are allocated upon block entry and released upon block exit. This required the use of stacks and stack pointers and it allowed the implementation of recursive procedures. ALGOL 60 also introduced several other less important, but still significant features, like the "while" loops.

But ALGOL 60 lost a very important feature of IAL (1958) and this loss has crippled many modern programming languages, which have followed too subserviently ALGOL 60. In IAL, unlike in the followers of ALGOL 60, the result of a function could consist of multiple values, i.e. a function could have both multiple input parameters and multiple output parameters and the syntax of assignment allowed the assignment of the output parameters to multiple variables.

Besides ALGOL 60, IAL (1958) had another descendant, the language JOVIAL (Jules' Own Version of IAL), which was used extensively by the US Military and later it had an important influence on the Department of Defense requirements for the programming language that eventually became Ada (1979).

> Note that the original stylised name “FORTRAN” changed to the modern form “Fortran” with the publication of the Fortran 1990 standard.

In fact, the early names of many programming languages, like FORTRAN, ALGOL and COBOL were not printed in capitals, except where good typography was not available, e.g. when using a typewriting machine.

Where normal typographic features where available, like in a book or in a journal, the names of the programming languages used a capital only for the initial letter, while the following letters were written with small capitals.

Nowadays the number of people familiar with the use of small capitals has decreased a lot and many low quality fonts do not include small capitals (in which case the word processor simulates the small capitals with smaller big capitals, which do not look as good as true small capitals).

Because of this, like with Fortran, many words that in the past used small capitals are written now with lower-case letters.

The article also claims that Common Lisp's last standard was from 2005 (the real standard is from 1994). In my own criticism I summed this up as "somewhat dubious history of programming languages" because trying to list it all detracted from my main complaint. The author wrote 88 pages (printed using its set font size) just to do a rug pull on page 86 or so where it turned out he was wanting to convince the reader of some other idea entirely.

Reply on news.ycombinator.com