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.
"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).
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
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), 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.
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.
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
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.
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.)
> 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.
I feel like the author is just wasting the reader's time. This thing is 88 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:
> 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.
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".
> 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.
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.
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.
20 comments
[ 0.35 ms ] story [ 50.0 ms ] threadHuh??? 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.
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).
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...)
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), 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.
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
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.
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.
Fortress (programming language) - Wikipedia "Fortress (programming language) - Wikipedia" https://en.wikipedia.org/wiki/Fortress_(programming_language...
https://www.youtube.com/watch?v=lw6TaiXzHAE
> 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".
> 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.
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.