The article did not discuss this, but to me, one of the bigger differences between Fortran and more modern languages is the difference between functions and subroutines. Yes, they are not synonyms in Fortran and serve different purposes. I think this would trip up more people initially than the clunky syntax.
It is also a bit funny that the author complains about older Fortran programs requiring SCREAMING_CASE, when if anything this is an improvement over previous and current practices. Too many Fortran codes have overly terse variable names that often were just single characters or impenetrable abbreviations for obscure terms. I have had to create cheat sheets for each program to figure out what each variable was.
Sun Microsystems had a great quote about this back in the day [1]:
> Consistently separating words by spaces became a general custom about the tenth century A.D., and lasted until about 1957, when FORTRAN 77 abandoned the practice.
What practical difference ever existed, beyond the fact that a subroutine does not return a value? AFAIK variable scope was handled identically. Recursion was likewise identical (forbidden originally).
pklausler 5 hours ago [-]
Spaces don't matter in fixed-form Fortran source files, so I don't get that at all. And case doesn't matter in either source form.
atrettel 4 hours ago [-]
Yes, sorry for the confusion. To be clear, the quote is directly about spaces not being significant in the source code in general, but I was commenting more about how this mindset affects variable names in practice. At least in my experience, many codes would benefit from variables names that use underscores.
whynotmaybe 3 hours ago [-]
> difference between functions and subroutines.
Waitaminit, is that why we have "sub" in Visual Basic ?
dhosek 2 hours ago [-]
Pascal also distinguishes between functions and subroutines (procedures)
thatjoeoverthr 3 hours ago [-]
Yes! QBasic also, IIRC.
adzm 3 hours ago [-]
it was a great improvement over GOSUB... which i probably have not thought about in forever
thatjoeoverthr 4 hours ago [-]
I actually had a fantastic experience with Fortran lately. I ported a compute kernel from python/numpy to Fortran 2018, partially due to the GIL and partly so I could use Intel's compiler. The performance improvement was tremendous. Several times faster per core, then multiplying further because I could take advantage of threading. In all, the 3 day project increased actual throughput 450x.
(I considered JAX, but the code in question was not amenable to a compute graph. Another option was to thread by fork, and use IPC.)
I liked the language itself more than expected. You have something like "generics" with tensors. Suppose you pass a parameter, N, and you also would like to pass a tensor, and you would like to specify the tensor's shape (N, N). You can do this; the parameter type constraints can reference other parameters.
Tensors and various operations are first-class types, so the compiler can optimise operations easily for the system you're building on. In my case, I got 80% improvement from ifx over gfortran.
Invocation from Python was basically the same as a C library. Both Python and Fortran have facilities for C interop, and Numpy can be asked to lay out tensors in a Fortran compatible way.
Part of what eased the port was that Numpy seems to be a kind of "Fortran wrapper". The ergonomics on tensor addressing, slicing and views is identical.
prennert 4 hours ago [-]
I did something similar many years ago. I was amazed that Fortran was not more discussed as an option to write performant code within a Python / numpy codebase.
At the time everyone seems to default to using C instead. But Fortran is so much easier! It even has slicing notations for arrays and the code looked so much like Numpy as you say.
3uruiueijjj 2 hours ago [-]
I've never found anything to back this up, but my impression was that both the Python / Numpy and Fortran 90 slicing operations were directly inspired by MATLAB (although most of the ideas go back to at least Algol 68).
It also helps that Fortran compatibility is a must for pretty much anything that expects to use BLAS.
foxglacier 23 minutes ago [-]
Yea, Fortran is nice to use for so-called "scientific" computing. It has high performance as well as some handy intrinsic functions like DOT_PRODUCT and TRANSPOSE but the best features to me are colon array slicing syntax like Python/Numpy and arrays being indexed from 1 which makes converting math equations into code more natural without constantly worrying about off-by-one errors.
I wouldn't call multi-dimensional arrays tensors though. That's a bit of a bastardization of the term that seemed to be introduced by ML guys.
It wasn't until I started using Fortran that I realized how similar it is to BASIC which must have been a poor-man's Fortran.
vatsachak 3 hours ago [-]
I can't believe they thought so hard about how threads work in the first programming language
I thought that was going to be what the article was about (or perhaps Lady Ada Lovelace’s ideas for programming).
jleyank 5 hours ago [-]
If you're interested in safer code when working with older versions of Fortran, add 'implicit none' at the top. This will eliminate the integer vs. float automatic assignment and make variable definition much tighter. Back when I mucked about with Fortran (previous century really), we tried to do the memory allocation and I/O in C and the compute in Fortran. That would play well with both superscalar and vector machines.
Neywiny 3 hours ago [-]
Pro tip: ctrl-f or find in page helps a lot. The author talks about implicit none and shows it in code.
layer8 4 hours ago [-]
You didn’t read the article?
jleyank 4 hours ago [-]
All of it, no. But I never used Fortran 90 yet used implicit none. Might have been an extension from SGI or a mini super but I recall using it.
dhosek 2 hours ago [-]
Just looking at Fortran code fills the back of my mouth with the sensation I got from being around the printed IBM manuals in the basement computer lab at UIC of being around dust and powdered printer paper.
stevenjgarner 2 hours ago [-]
One of oldest HIGH-LEVEL programming languages. "Programming" originally meant physically flipping switches or plugging cables into boards. Eventually, this moved to binary (1s and 0s), and eventually to Assembly.
gorfian_robot 2 hours ago [-]
a Jacquard Machine has entered the chat ...
sdsd 2 hours ago [-]
Semi-related, I've wanted to learn Plankalkül for some time but have had immense difficulty "getting it". Has anyone on here gotten the hang of it?
5555624 4 hours ago [-]
This makes me feel old. I learned Fortran on the Dartmouth Time-Sharing System back in 1980. While I think of Fortran now and again and think about re-learning, I haven't thought of DTSS in years.
leephillips 1 hours ago [-]
Wow, me too. Maybe more like 1982.
silverfrost 2 hours ago [-]
Real programmers can write FORTRAN in any language...
RyanOD 3 hours ago [-]
First language I learned while in college in the 1990s. While I enjoyed the class, I have a funny picture of me kicking the FORTRAN book across my dorm room after I turned in my final project.
Hizonner 4 hours ago [-]
I'm not sure one line of that would compile in FORTRAN 66, even if you indented it properly. Been so long I'm not sure...
Fortran, the language, is also older than FLOW-MATIC.
FLOW-MATIC's claim to fame was beating Fortran at releasing a working implementation (and having syntax that looked like English, but that's not something to be proud of). Plankalkül, however, has not yet been implemented so if we're only counting releases of working software, it isn't a contender.
dizzant 9 hours ago [-]
> a quick introduction to a few modern Fortran features: declaring variables, printing and reading to and from the terminal, if and select case, and stop
Pretty much sums up this one. Can't say that I agree if/select/stop are "modern" features.
9 hours ago [-]
aj7 5 hours ago [-]
Arrays that actually make sense!
vzaliva 6 hours ago [-]
This is an excellent idea. But I wold go with Fortran 4 if you looking at authenticity.
ginko 9 hours ago [-]
I expected this to be about Plankalkül or something devised by Babbage.
riskassessment 4 hours ago [-]
I was expecting a system like Leibniz notation, Boolean Algebra, Begriffsschrift, or the notation system in Principia Mathematica
IAmBroom 4 hours ago [-]
Yeah, "oldest" needs an asterisk.
Edit: and just three paragraphs in, the author admits they didn't even bother using the oldest version of FORTRAN itself.
It is also a bit funny that the author complains about older Fortran programs requiring SCREAMING_CASE, when if anything this is an improvement over previous and current practices. Too many Fortran codes have overly terse variable names that often were just single characters or impenetrable abbreviations for obscure terms. I have had to create cheat sheets for each program to figure out what each variable was.
Sun Microsystems had a great quote about this back in the day [1]:
> Consistently separating words by spaces became a general custom about the tenth century A.D., and lasted until about 1957, when FORTRAN 77 abandoned the practice.
[1] https://docs.oracle.com/cd/E19957-01/802-2998/802-2998.pdf
Waitaminit, is that why we have "sub" in Visual Basic ?
(I considered JAX, but the code in question was not amenable to a compute graph. Another option was to thread by fork, and use IPC.)
I liked the language itself more than expected. You have something like "generics" with tensors. Suppose you pass a parameter, N, and you also would like to pass a tensor, and you would like to specify the tensor's shape (N, N). You can do this; the parameter type constraints can reference other parameters.
Tensors and various operations are first-class types, so the compiler can optimise operations easily for the system you're building on. In my case, I got 80% improvement from ifx over gfortran.
Invocation from Python was basically the same as a C library. Both Python and Fortran have facilities for C interop, and Numpy can be asked to lay out tensors in a Fortran compatible way.
Part of what eased the port was that Numpy seems to be a kind of "Fortran wrapper". The ergonomics on tensor addressing, slicing and views is identical.
At the time everyone seems to default to using C instead. But Fortran is so much easier! It even has slicing notations for arrays and the code looked so much like Numpy as you say.
It also helps that Fortran compatibility is a must for pretty much anything that expects to use BLAS.
I wouldn't call multi-dimensional arrays tensors though. That's a bit of a bastardization of the term that seemed to be introduced by ML guys.
It wasn't until I started using Fortran that I realized how similar it is to BASIC which must have been a poor-man's Fortran.
https://en.wikipedia.org/wiki/Jacquard_machine
FLOW-MATIC's claim to fame was beating Fortran at releasing a working implementation (and having syntax that looked like English, but that's not something to be proud of). Plankalkül, however, has not yet been implemented so if we're only counting releases of working software, it isn't a contender.
Pretty much sums up this one. Can't say that I agree if/select/stop are "modern" features.
Edit: and just three paragraphs in, the author admits they didn't even bother using the oldest version of FORTRAN itself.
So, "oldest" means "rather early".
https://en.wikipedia.org/wiki/Plankalk%C3%BCl