Hacker Newsnew | past | comments | ask | show | jobs | submit | ivanpribec's commentslogin

Reminds me of spreadsheet-fortran (https://github.com/lwsinclair/spreadsheet-fortran), a project creating a VisiCalc lookalike in FORTRAN 66, which even runs on a PDP-11.


I can see the subtle distinction you make. The flang notes on array composition provide a good introduction to the way array expressions (https://flang.llvm.org/docs/ArrayComposition.html) are treated.

But in practice it looks like the elemental function must be in the same translation unit for vectorization to occur with compilers popular today. Explicit options like !$omp declare simd are a different matter (and have different pitfalls).


*same translation unit as the call site


The "!omp simd" works very well IMO. In general however, the auto-vectorizer tends to do a pretty good job.


The NumPy part is a misconception. Fortran is used in SciPy however.


Isn’t a chunk of Numpy’s C code just f2c’d Fortran code, though?


Personally, I like to think of Fortran as the language of large-scale numerical PDE and eigenproblem solvers. Most scientific and engineering problems boil down to one of these two.


At least in the US national lab system Fortran is nominally being phased out in a lot of projects. It's just gotten too hard to find highly skilled Fortran programmers to maintain these complicated projects, so a lot of codebases are gradually being moved away from it. However the reality is it's mostly aspirational; some of the large codebases have at least made big progress towards migrating onto C++ but the tail is very long indeed and it's still entrenched with many of the greybeard HPC folks. It's also tough to imagine some of the big legacy codes that are still heavily used in the nuclear industry (e.g. MNCP) migrating away due to the sheer amount of experimental validation that has been done on the existing Fortran code.

I personally know and like Fortran in its modern form, at least within its little niche. But the ability to maintain these codes long term is really important and it's tough to see that being viable with the supply of professional-level developers withering to nothing.


I don't get this. It's highly difficult to find vast troves of military reserves (ie: bodies who can do military stuff) in war time. That's what bootcamp and sergeants are for.

Hell my sister (print sales) joined a new firm and she had to spend six weeks in an intense classroom style training program the company ran to get new staff prepared for the nuances of their product.

It seems straightforward to setup a Fortran internal bootcamp for experienced developers at these massive legacy institutions, worth the upfront investment...no?


Yeah, all of that is part of the long tail. Fortran isn't going away, but with younger people who grew up without Fortran getting into leadership positions momentum is in the favor of moving HPC and sometimes more mundane computational code to C++. It's not just that developers are harder to find, it's that C++ is also offering advantages with better tooling, better libraries and community support, etc. Leveraging (and contributing to) open source is also important for DoE, which is tough in Fortran.

Of course you could make the case for even more modern languages like Rust etc as well, but the national labs are still on the conservative side when making decisions for their big projects. C++ does hit a nice sweet spot in terms of performance, features, and longevity despite the warts.


The problem is who is willing to do this?

If you go into such a bootcamp as a fresh grad, you basically pigeonhole yourself into working in that niche forever. You would have a massive setback when switching jobs compared to taking a bogstandard Java job or whatever.


There are loads of people who'd be willing to do this at a national lab. The bigger problem is that very few national labs are located in places many young people want to live. For the ones that are (LBL), it's competitive to get a job there.

You're also wrong about the setback and being stuck in that niche. Once you learn the first language, more likely than not you'll have opportunities to continue to grow and develop in the role and learn new things. Most people are pretty adaptable.


National labs should be able to attract people who can learn Fortran well enough to maintain those codes. After all the hard part is the math, not the programming.


The hard part is probably getting those who are good at the math to be interested in crap like Fortran.


You'd be surprised. People who aren't particularly interested in programming qua programming don't typically have strongly held opinions about it. Using the same programming language as the group you're working in is usually the main consideration. Speaking from experience as someone who has worked in an applied math group where the predominantly used language was Fortran.


I don’t think it’s fair to call Fortran “crap”, especially given most of the alternatives.


Bjarne Stroustrup on Fortran users [1]:

> Fortran is harder to compete with. It has a dedicated following who [...] care little for programming languages or the finer points of computer science. They simply want to get their work done.

[1] https://ieeexplore.ieee.org/document/4263269



For "broadcasting" an array along a particular axis, you'll need to use the function "spread(source,dim,ncopies)". But mixed array/scalar expressions are indeed supported.


OpenMP support in Fortran will improve as flang matures. In OpenMP 5.0 "#pragma omp requires unified_shared_memory" was introduced. At LLNL, they are are currently building El Capitan (https://www.datacenterknowledge.com/supercomputers/lawrence-...), a supercomputer using AMD MI300A accelerators which support this concept. LLNL is also one of the OpenMP ARB members (https://www.openmp.org/about/members/).


They do. Some national HPC centers offer Fortran courses including elements of Fortran 2018 [1,2], including the latest features. (Disclaimer: I work at one.) The Intel Fortran compiler already includes some Fortran 2023 features [3].

[1] https://doku.lrz.de/programming-with-fortran-10746212.html [2] https://doku.lrz.de/prace-course-advanced-fortran-topics-107... [3] https://www.intel.com/content/www/us/en/developer/articles/r...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: