I’m not very fond of the Fortran MEX interface, I have to say. Instead I’ve always just gone with the option of tagging a procedure as bind(c) and writing a C MEX file. But I know this is not everyone’s cup of (Julia specifically, promotes itself as solving this kind of two-language problem).
Recently I invested a little time in creating Python bindings to a Fortran library, and I’m loving the dynamism and fast iteration cycle, but simultaneously frightened by the lack of static typing and the ease with which one can accidentally overwrite variables.
Several people I’ve spoken with have mentioned the MATLAB license being the main factor driving them away. I really liked using MATLAB at university. Friends working at smaller engineering companies have also lamented their management was not willing to buy the license. The differences with Octave are just large enough to create portability issues, especially if you need something out of one of the many toolboxes.
I agree that the MATLAB licence is a barrier. But I don’t see why Python is so much more used than Julia (which is also free). Julia’s syntax is also quite close to Matlab and Fortran, column-major ordering, 1-index based arrays, etc.
In my opinion what is needed are (much) better compilers for existing languages, not necessarily new languages. New languages are cool and it’s important to explore new ideas. And ultimately you never know if you can make it as a new language unless you try it. As long as the expectation is that you will most likely not make it, then there is no problem. As the blog post says, it’s not enough to be a little bit better, you must be a lot better.
So that is why my personal strategy was to stick to Fortran and Python, and develop the same compiler with different front-ends for those (LFortran/LPython). The door is open to add new syntax and create a new language if somebody wanted. Especially Python with its extensible decorator syntax can create almost any semantics within CPython itself, and supported natively with a compiler. I think a lot of Julia features (such as multiple dispatch) can be emulated in CPython to ensure it is just Python, and then support with a compiler at maximum speed (as fast or faster than Julia). Julia made the choice of bundling the compiler with the runtime (JIT), which has pros and cons. I personally much prefer strictly ahead-of-time compilation. But one can certainly imagine creating a subset-of-Python compiler with JIT that might support a large subset of features of Julia. I don’t know if Julia has some features that fundamentally cannot be done in Python in the above manner. Certainly some syntax is easier in Julia. And certainly for design and new ideas it’s good to think in terms of a new language and syntax so that one is not constrained by existing languages.
Which I think is the correct one. I hope that LFortran can evolve into the dominant Fortran compiler at least in the open source space. If nothing else, you and your co-workers have demonstrated that interactive Fortran is doable. I think that feature alone would attract a lot of people who have moved away from Fortran to Python etc. back because once people try a scripting language be it Python, Matlab or whatever going back to the edit/compile/fix programming errors/compile again, link, run and fix run time errors cycle of Fortran development is not worth the efffort. Also, since we have IMPLICIT NONE, how about an INFERRED TYPE that would allow the language to back out of both default implicit typing and IMPLICIT NONE. I see something like INFERRED TYPE being the middle ground between explicit and implicit typing.
I think fortran folks would also enjoy Odin-lang. If you haven’t used them, give Zig and C3 a try too. I do enjoy Zig a lot but I think Odin is a fortranner’s(?!) cup of tea.
I’d argue that having to fix errors before running a program is a feature, not a bug. The edit/run/wait/(get an error message because you forgot to import module foo) cycle of Python can also be annoying. At least when a Fortran program has compiled, you know that the compiler has caught such errors. With Fortran or C it is simple to create a workflow with something like make where you only compile what is needed and then run the executable if it was created.
Yes, inferred type is an option we can implement. Possibly only in interactive mode and then one can ask the compiler to print out correct Fortran that you can copy & paste into your production code.
Zig and Julia has been an inspiration for me when I created LFortran. I’ve been also trying to encourage the Fortran Standards Committee to look at these other languages and maybe learn from them. In my opinion there is a lot to learn from them. But let’s just say not everyone agreed with me. I have not played with Odin yet.
It could be confusing if in LFortran x = 3 creates an integer variable x while in regular Fortran, with implicit mapping, it creates a real variable x. Maybe you could let LFortran supply the needed end associate when the user writes associate (x => 3)
Re. inferred typeing. Why don’t we just make inferred typeing the default, get rid of implicit typeing unless you add a -std=legacy complier option. I’m trying to think of a case for a legacy code where integers are assumed to be I through N and are initialized as such that replacing implicit typeing with inferred typeing would break anything. I’ll be the first to admit that there are probably cases where that can occur, I just can’t think of one at the moment.
Powerful editors with linters can nowadays signal “forgot to import module” type of errors while you are still typing. And with type hints, catching errors is further improving.
From my experience, the only real issue I have with Python is speed. Also sometimes funky code due to over-flexible nature of the language.
The only real issues I have with Fortran is lack of syntactic sugar in some cases (like f-strings) and some advanced features (like generics).
Folks, do not underestimate the power of syntactic sugar.
It’s so ABSOLUTELY RIDICULOUS so many sitting on the J3 and WG5 committee blatantly diss and deflect proposals or suggestions or ideas or discussions on enhancements to the Fortran languages as mere “syntactic sugar”, often without any understanding or effort into the hard work or intellectual analysis the person(s) making the proposals or suggestions have made prior to their statements.
And the whole premise of “syntactic sugar” is real BULLSHIT, there is no other, better way to put it:
“FORTRAN” by Backus and team back in the 1950s itself was “syntactic sugar” on top of assembly language, if you really think about it.
Or going back, once humankind learned to count beyond the digits on their hands obtained following eons of biological evolution, an abacus, the slide rule, the computer, on and on are all mere syntactic sugar in terms of devices or means of inter human communication and exchange of goods and ideas. Why bother with them?
Then there is the even sillier argument regarding “cost”!! Oh, nothing is free, there is cost (one-time) to put together the semantics and syntax and to document them by a committee. Again, it’s an utter FAILURE of IMAGINATION to not see the benefits of the effort.
Backus through Van Rossum had the vision to see the benefits with FORTRAN through Python and the limited cost of their efforts led to IMMEASURABLE and near INFINITE benefits with computing.
Proper “vision” leads to tremendous benefits.
A lack of “vision” leads to bean counting toward managed decline and ultimately obsolescence.
I more than fully agree, but it has to be well thought out and well designed. Shorter and fewer lines of code are easier to read and understand, and result in fewer bugs. It also increases acceptance of the language.
I’ve found the Odin FAQ’s to share some common philosophy with Fortran, for instance when it comes to exception handling (see Idioms for exception handling) but also in other points like simplicity. It looks like a neat little language; I’ll definitely give it a try in the future.
The Anaconda Python distribution has many packages, such as Numpy, pandas, Matplotlib, Scikit-learn, and it is convenient for getting started. Economist Paul Romer has noted that this comes at a cost.
If you teach a course that requires Python, you’ve encountered students on macOS who are trapped by Anaconda. Typically, they were told to install Anaconda in a first course on Python or data analytics. After that course is over, they discover that they can’t get an official version of Python to run.
Many of these students have not used the command line. Many do not understand the difference between a text editor and a word processor. If they ask ChatGPT for help, it responds with instructions that they do not understand and that wouldn’t work anyway. In my experience, most give up.
This post gives them a simple way to recover the ability to run an official version of Python. It requires neither commands from the terminal nor edits to files. All that’s required is to drag and drop a file.
In a previous post, I wrote that Anaconda got in my way when I was trying to learn Python. After I wrote that, I tried to recall the specifics. What was it that I started doing with the official Python tools that I didn’t do with Anaconda? Mostly, I broke the rules and made a mess.
I recommend new users to install conda from conda-forge: https://conda-forge.org/download/ on all platforms and learn how to use that. It does not interfere with system Python, so you can use both.
As a bonus, you can install fpm, lfortran, flang, gfortran and other Fortran tooling easily on all platforms.
(Julia specifically, promotes itself as solving this kind of two-language problem).
