Blockquote
Part of the advantage of Python is that it is interactive. We will fix that for Fortran with LFortran. Finally, Python has more mature tooling, allowing rapid prototyping.
The amount of work he has done to 1. produce a LLVM based Fortran compiler/interpreter, 2. generate much needed enthusiasm for the language is amazing.
I was wondering what other developer tools would make Fortran competitive with Python? I’m looking at LFortran + Web Assembly integration, so perhaps a development of these tools could be greatly sped up by adapting tools from javascript, typescript, node.js and Rust communities.
Example: VSCode as a recommended IDE, use of the Javascipt D3 for plotting, etc.
Modern Fortran is a complement to these other technologies; I think it is the right language for verified implementations of mathematical algorithms, implemented as library code for use in other languages.
This runs LFortran fully in the browser in WebAssembly (WASM). You have to click the “Run LFortran” button. It parses the code, and prints AST and ASR. The full LFortran C++ compiler runs (it’s quite amazing). And it’s immediate. Try modifying the code and rerun. You can try compiler errors too. Ignore the black box, I used a template html from Emscripten. I didn’t get LLVM working in WASM yet, that seems like a big task. Although others seem to have done that. The alternative is to write a direct ASR->WASM backend, here are some relevant links:
Once LFortran can generate WASM and runs in the browser, it will work in Jupyterlite, which fully runs in the browser. People can use it to create demos on their static pages. We can use it for the standard committee, by implementing some new feature proposal in LFortran and host a static website where anyone can try out the feature.
So there are a lot of interesting ideas that can be done.
I am also looking for people to help make the above html page look good. Here is one idea how it can look like:
That page has a nice editor, that you can edit the code, it gets compiled to WASM and you can execute it. It’s very nice and fast. This can be done with Fortran now.
I’m definitely interested in Fortran + wasm integration. My question was related to the Python tools you alluded to in that other post.
Obviously, the plotting capabilities are critical. VSCode integration (I think there are already Fortran language servers) isn’t all that hard. Full desktop applications in Fortran can be delivered with Electron, once wasm + Fortran integration is complete.
The purist in me isn’t terribly fond of web standards, but the pragmatist in me realizes it is the only way for a “niche” language like Fortran can hope to compete.
Added: There are a lot of interesting projects that combine Rust with Typescript. Deno is one of them.
If you want to help, figuring out how to compile LLVM itself to WASM would be a huge help. We need to see how fast it is in WASM, and how big the .wasm file will be. Right now LFortran is immediate and the .wasm file is about 1 MB, so it is small. If LLVM makes it 20 MB, then maybe it makes sense to write our own backend, which would keep the size small. Also if LLVM suddenly makes the compilation slow, that would be another reason. Here is a Julia repl in WASM: Julia - A fresh approach to technical computing., I think it has LLVM underneath, and that seems immediate also. So I think LLVM might be fast enough.
Regarding the other tools, what I was alluding to:
Language servers that just work (yes, there is one for Fortran and I can’t figure out how to make it work…)
Package managers (Conda/pip)
Tons of libraries that are easy to install and just work (kdtree)
Jupyter notebooks with tutorials. Plotting, widgets, etc.
So fpm+LFortran can fix a lot of these issues, and potentially more robustly. Installing Python packages that require C, C++ and Fortran parts using pip used to be a nightmare (I don’t know if things have improved lately, but I think it’s almost impossible to fix robustly, without something like Cargo or fpm or Spack). Thus the motivation for Conda that just installs the binary. But with fpm, we can install from source, and we will be able to mix Fortran, C and C++, as long as they are packages as an fpm package. So I think the potential is huge. We just have to take advantage of it.
I’ve got a lot on my plate ATM, but I will take a look at this. Perhaps seeing if the Fortran standard library can compile to wasm would be a good test.
No worries. I have a lot on my plate too, I fully understand.
LFortran can’t compile stdlib yet, we are working on it. Note that I am asking how to compile LLVM itself to WASM, so that it can run in the browser. Not about WASM backend in LLVM. See my comment above Questions about Fortran software tools - #2 by certik where I explain the difference.
I’m not sure about this one and it may be not a “tool” in the narrower sense, but I feel like what makes a language simple to use is if there is only one compiler. Fortran has many compilers and none of them can compile every code (personal experience: ifort has too many bugs with new features and gfortran has issues with parallel netCDF) + it is complicated to maintain several compilers with their libs on a single machine.
I don’t know if this would be possible to achieve for Fortran, but having one gold standard compiler which is capable of compiling everything would make my life easier. For example Rust has “the compiler” and other languages only have one (main) compiler, too, like Java for example, or one Interpreter (Python).
Ideally THE Fortran Compiler should be open source, so the manufacturers of all CPUs are able to contribute beside other people and companies.
I assume what @themos meant was that it is healthy to have multiple compilers. (He is a NAG compiler developer.) I agree. However, see below.
@Carltoffel yes, what you are saying makes a lot of sense. Most languages have only one main open source compiler that everybody contributes to. That has pros and cons. The pros are what you mentioned. In my view, the biggest advantage is that everybody contributes to it and the community uses it and given how small our community is, working on just one open source compiler instead of 3 or 4 makes a lot of sense.
The con is that it is actually really helpful to make sure your Fortran code compilers with multiple compilers. The more the better, because it ensures that the code is not tied to any compiler and thus is truly multiplatform. The code lives on its own at that point, independent of any one compiler. That’s a huge positive of having multiple compilers.
Also having a culture of multiple compilers makes it easier to create a new one, you are not completely locked in into the main one.
Having multiple compilers does not hurt and Fortran already has it, so that’s what we have and our (my) goal at fortran-lang is to provide a medium where we can all collaborate.
At the same time, I still want to have an open source community compiler that can compile everything, compiles quickly, has excellent optimizations, works interactively, and provides a platform to build other tools that we need around Fortran.
Right now, Python is the hot item. What will happen if language fashion changes and there becomes a viable reason to move on from Python? Lots of people will be stuck doing unproductive porting work.
Fortran will be a reasonable choice since it doesn’t aspire to be a general purpose language (not that this is impossible). So long as new languages desire to interface to C, Fortran compilers that follow the C interface for library code will continue to work.
Fortran as a teaching language for elementary mathematics and imperative programming has yet to be explored.
I composed a reply three times and each time discarded them. I have an opinion on the merits of having a language defined de-facto by one compiler, as do many other people.
While I understand the benefits of multiple compilers, I’m not sure it is a viable option given how rapidly the PL language landscape is evolving. Languages with one compiler can pretty easily pump out 2 fairly major updates a year. If you want to go with multiple compilers and a committee, you are lucky to get 2 a decade.
Maybe a 3-year cycle instead of a 5-year cycle would be good for Fortran standards, as has been proposed, but given the gradual pace at which Fortran features are adopted, I don’t think a much faster cycle is needed. If a new standard has many new features, they will be added to compilers over time, so the language that is accessible to programmers will change more often than every 5 years.
I agree with Themos here. I’ve been involved with Fortran for over 45 years, and 25 of those were spent in computing services in the university sector in the UK. Having multiple compilers is a big plus with not only Fortran but also other standard languages like C and C++. With Fortran our (Jane Sleightholme and myself) lead development compiler is the Nag one. We also currently use use Intel, gfortran, Cray and Nvidia. Sadly we no longer have access to the IBM compiler. On the C interop front we use gcc, g++, Microsoft C++, Sun/Oracle C and C++, and Nvidia C and C++. Look at the interpretation requests at standards meetings for all three languages - Fortran, C and C++.
Please describe what in the world is the C++ committee doing right now.
Having a standard committee is not a choice to make. It happens to any language that is to be taken seriously.
and this is what happens to such languages. And this is why the Aerospace industry never designs systems with a single point of failure. And this is why the critical infrastructure should never rely on a language like Julia with a siloed committee and a single platform, vulnerable to the single point of failure catastrophes, to build applications.
Some things depend on us, others not. There is several Fortran compilers since the early 60’s and
a standardization committee was created for that reason at the same time. This was the price of success.
Fortran is an industrial language and stability and perenniality are essential. There is advantages and inconvenients, but that will not change as long as Fortran is used. It is not fashionable, for better or for worse.
Wikipedia lists only 23 programming languages with ISO standards, some of them moribund, and not including such popular and serious languages as Python and Java. Julia is taken seriously in scientific computing.
