Indeed, inferred typing is what people asked to implement in LFortran for easy interactive use, and then have an option for LFortran to fill in all the types, so that you can copy & paste the generated code to a production code.
It’s a little bit of a Pandora’s box, so for now LFortran does not do any inferred typing, although it would be quite easy to implement. Later we can revisit and play with it.
P.S. One could implement a similar feature for implicit typing, to let the compiler fill in the types. I feel a modern way is inferred typing, but we could choose to embrace implicit typing. The issue with it is that I don’t think it’s possible to create an array variable as an implicit type, i.e., this works:
i = 1
print *, i
end
but this does not:
i = [1, 2]
print *, i
end
and it would be nice to make it work for interactive use. With inferred typing, this could be made to work.
Hi @rcs, thanks for your posts, just wanted to reply to a few of your points:
Indeed, I also think it’s intuitive why Python is doing well (that is why I started using it 20 years ago). And it is also intuitive why Fortran is not doing well.
In order to fix it, we have to first understand and be willing to look at the unpleasant truth about Fortran.
Regarding what sets Fortran apart: we have that at the top of the Fortran page as well as LFortran page. If there is something that you would change, please let us know.
With regard to the 2008-2018 standards: I have desperately awaited every little piece of it and very often it was “too little too late” especially in the oop arena. The projects I am running at the moment are only compilable with intel because gfortran doesn’t catch up, pgi is nowhere near gfortran and for nag I don’t have the money. But intel has taken weeks out of my lifetime just for tracking down ices. Just recall the deaster around the 18 release.
I feel exactly the same way. We have the same issues, only NAG and Intel can compile some of our codes, and Intel only works with some versions (not too old, not too new). Yes, we have tracked all the ICEs and reported them. Yes, it took us a lot of effort also. Yes, the new features are “too little too late”.
The situation is dire and it’s easy to see how many people simply give up on Fortran.
However, in my opinion there are two parts to success:
Be able to look at the cold unpleasant truth and be able to admit that the above issues are real and they are largely responsible for the current situation.
And then work on fixing these. We have made large progress in just the past year on fixing all of these issues. I am happy to discuss any details if you are interested.
BTW I am under 50 as well … but I think fortran and this community still have to reach the critical mass.
We have not reached the size and the impact that we want yet. However I think we might have reached the critical mass already: defined as “big enough momentum to keep growing until we get the mass we want”.
Summary: yes, the situation is tough, but I am optimistic. We have the momentum to fix these issues and we are fixing them.
I just turned 36. I look forward to programming Fortran at 72. F2056 will be goood. Sure, Python 7.x will have finally implemented antigravity but will still be incompatible with Python 6.x.
Dealing With Software Collapse (2019) by Konrad Hinsen discusses some difficulties in using the Python ecosystem for a long-term scientific project.
I had started using Python in 1993 with version 1.3. In
2007, the current version was 2.5, but in spite of a significant
evolution of the language during those 14 years, I only had
to adapt my code once to change the name of a variable that
had become a new keyword. Numerical Python had been
around for ten years with continuous improvements, but no
breaking changes and few major bugs. It had just been superseded by NumPy a year before, and everyone, including
myself, was at some stage of migration, but since NumPy
had a compatibility module for Numeric, that wasn’t much
of an issue. My own MMTK had evolved enormously but
without ever introducing breaking changes. My very first
simulation scripts from 1997 still worked fine. netCDF had
an excellent track record of stability as well. In short, I had
no reason to expect any trouble.
But then, over the seven years of the project, I ended up
spending a lot of time catching up with dependencies. New
releases of NumPy and matplotlib made my code collapse,
and the increasing complexity of Python installations added
another dose of instability. When I got a new computer in
2013 and installed the then-current versions of everything,
some of my scripts no longer worked and, worse, one
of them produced different results. Since then, software
collapse has become an increasingly serious issue for my
work. NumPy 1.9 caused the collapse of my Molecular
Modelling Toolkit, and it seems hardly worth doing much
about it because the upcoming end of support for Python 2
in 2020 will be the final death blow., since porting the code
to Python 3 would almost be a complete rewrite.
But if I were to attempt a rewrite, would I still choose the
Python ecosystem, whose time scale of change has become
too fast for the kind of work that I do? I have seen some
of my colleagues move back to C or Fortran in a quest
for stability. Should I do the same? But then, working with
complex molecules in these languages is no fun, and I’d
miss the convenience of all those nice tools and libraries
that exist in the Python universe. It’s not an easy choice.
The only conclusion I have drawn so far is to make my
software much more modular, to prevent collapse from
affecting all of it. Today I would definitely no longer start
a “molecular modelling toolkit” project combining lots of
distinct functionality in one package.
I often find working with a large amount of older code that used implicit typing (very carefully, I rarely find errors) that numeric routines require a very large set of declarations, and I automated changing them by using a nastly script that compiles them with gfortran with all the warnings on and gathers up the lines for undeclared variables and writes the declarations. Works well but underneath the surface is quite an ugly beast, and not perfect so I often run it one function at a time. Are you saying Lfortran will do that automatically?
It seems like a natural for reformatters but I have not seen one that does it. Anyone have something that does that cleanly and reliably? I think I am hearing Lfortran will thelp take care of that. That would be nice. Several compilers now write automatic interfaces for non-module source files but as far as I know none nicely writes a list of implicitly typed variables with declarations. If I missed something share!
Neat idea, thanks. For example, with gfortran and Intel Fortran, the program
program xassoc
implicit none
associate (x => 2.0, y=>3.0, i => 2, j => 3)
print*,"x, y, x/y =",x,y,x/y
print*,"i, j, i/j =",i,j,i/j
end associate
end program xassoc
gives output
x, y, x/y = 2.00000000 3.00000000 0.666666687
i, j, i/j = 2 3 0
Since names assigned to a constant cannot be redefined inside the block, they act like PARAMETERs.
Dealing With Software Collapse (2019) by Konrad Hinsen discusses some difficulties in using the Python ecosystem for a long-term scientific project.
It is amusing that at Python dot org site, MMTK is listed as a success story, with a testimonial by Konrad Hinsen that must have been written earlier than the paper above.
I started developing MMTK in 1996. I had some experience with mainstream simulation packages for biomolecules that were written in Fortran and had their origins in the 1970s. Those packages were too cumbersome to use and in particular to modify and extend. Since my research work is focused on the development of new simulation techniques, modifiability was a particularly important criterion.
…
For the low-level part, Fortran 77 was eliminated because of its archaic character, lack of memory management, and portability issues in C-Fortran interfacing. C++ was a candidate, but ultimately not chosen because portability between compilers was still an issue in 1996, and because I considered the benefits of C++ for the small amount of compiled code in the project insufficient to compensate for the complexity of the language.
The lesson may be that the suitability of a computer language for a long-lived project should be evaluated not only when the project is completed but also many years later. One hopes that for a similar project started today, modern Fortran would be a viable candidate.
for nag I don’t have the money. But intel has taken weeks out of my lifetime just for tracking down ices.
I am sorry! I work for NAG and couldn’t help noticing the irony in this juxtaposition. I am wondering how much a week of a developer’s time is worth. The cost of a good tool is surely not greater. I have been thinking about the amount of money I have spent on tools that do not help me earn a living and I will end up using for a few hours a year (drills, saws, lawnmowers, strimmers, pressure washers, hammers, wrenches, soldering irons) and yet when it comes to software tools… I can’t be the only one!
During his talk, Edelman presented an example in which a group of researchers decided to scrap their legacy climate code in Fortran and write it from scratch in Julia. There was some discussion around performance tradeoffs they might encounter in the move to a high level programming language. The group was willing to accept a 3x slowdown for the flexibility of the language. Instead, said Edelman, the switch produced 3x speedup.
I would like to see details about the 3x speedup. Like Matlab, Julia has a for-profit company promoting it. The companies that make Fortran compilers are not promotional about the language per se.
I am subscribed to some promotional emails from Julia Computing. The ending few paragraph is typically something like:
About Julia and Julia Computing
Julia is the fastest high performance open source computing language for data, analytics, algorithmic trading, machine learning, artificial intelligence, and other scientific and numeric computing applications. Julia solves the two language problem by combining the ease of use of Python and R with the speed of C++. Julia provides parallel computing capabilities out of the box and unlimited scalability with minimal effort. Julia has been downloaded by users at more than 10,000 companies and is used at more than 1,500 universities. Julia co-creators are the winners of the 2019 James H. Wilkinson Prize for Numerical Software and the 2019 Sidney Fernbach Award. Julia has run at petascale on 650,000 cores with 1.3 million threads to analyze over 56 terabytes of data using Cori, one of the ten largest and most powerful supercomputers in the world.
Julia Computing was founded in 2015 by all the creators of Julia to develop products and provide professional services to businesses and researchers using Julia.
Need Help with Julia?
We provide products, training and consulting to make Julia easy to use, easy to deploy and easy to scale in your organization. Email us: info@juliacomputing.com
I am wondering how many Fortran programmers are award winning scientists and engineers, and how many bytes of data has been processed using Fortran. Yet the community remains almost invisible.
The growth of Julia does make me worried whether Fortran will remain relevant in the future. The table below contains some of their growth stats. For comparison our Fortran Discourse has generated 2.7k posts since first introduced.
Julia adoption accelerated at a rapid pace in 2020.
Julia adoption accelerated at a rapid pace in 2020.
Total Cumulative as of Jan 1, 2020
Total Cumulative as of Jan 1, 2021
Change
Number of Julia Downloads (JuliaLang + Docker + JuliaPro)
12,950,630
24,205,141
+87%
Number of Julia Packages
2,787
4,809
+73%
GitHub stars (Julia language repo + registered packages)
99,830
161,774
+62%
YouTube views (Julia language channel)
1,562,223
3,320,915
+113%
Published citations of Julia: A Fast Dynamic Language for Technical Computing (2012) + Julia: A Fresh Approach to Numerical Computing (2017)
Great for Julia. It’s probably somewhere in the low-to-middle part of the S-curve right now.
I don’t see Julia competing with Fortran. When they started, their branding made it seem so (“As fast as C, as easy as Python”, my words), but I think this came from a kind of an identity crisis, an impostor syndrome. Julia is much more mature today and has its own niche.
Julia’s tagline even says so: “A fresh approach to technical computing”. This means programming with Julia should feel different than Fortran or Python, and indeed it does. Many people love it, some don’t. I try Julia every 2 years or so, and so far I haven’t felt like it’s for me. Maybe that will change. I think I will try it again this year.
To try to compete with other languages–be it Python, Julia, or Rust–is a futile exercise. They each bring their own thing to the table, just like Fortran does. Instead, see what we can learn from them. What do we like about these languages and their ecosystems and communities, and what do we not like? What can we try to emulate or reuse? What should we focus on improving?
If a Fortran programmer wants some interactive computing, do some plotting, make a quick and easy GUI, or do some machine learning or automatic differentiation, should they be able to do that? Sure! But is Fortran in trouble if Python or Julia are better for any or all of these tasks? Of course not.
Fortran is not a mainstream language. Fortran was a mainstream language when computing was niche. But when computing became mainstream, Fortran became a niche language. So far, fortran-lang is the only organized effort that I know of (in this century, at least) that attempted to make Fortran more approachable to new users. All of these will and already do help (not all are fortran-lang efforts):
Fortran has already a GTK 4 library (GTK 4.0.0 was released for Christmas).
But shhh! It’s a secret… You can already use it (git clone the gtk4 branch of gtk-fortran on GitHub). I think the official release will be around Spring, with the next minor GTK 4 release for the release of GNOME 40. I am still working on some peripheral tools.
I hope to have some time to try to “fpm” it…
Note also that GTK 4.0.1 is available on very few Linux distributions for the moment, Fedora being the main one (I am developing gtk-4-fortran in a virtual Fedora 33 machine, with VirtualBox).
I enjoyed that article. I personally do not like Python for the very reason mentioned in the article. The transition from 2 to 3 was a fiasco.
I’d much rather implement computational algorithms in Fortran, and then use the well designed C interface to link to whatever scripting language is popular. I think Fortran + Javascript makes a surprisingly effective development environment for data analysis.
Fortran does the number crunching, Javascript does the data collection, cleaning, and visualization. Someone even wrote a book about it: Data Wrangling in Javascript.
Someone already created a Node/Fortran interface.
Online book describing how to do data analysis in javascript: https://js4ds.org/
