[HN Gopher] Why Fortran is a scientific powerhouse
___________________________________________________________________
Why Fortran is a scientific powerhouse
Author : todsacerdoti
Score : 42 points
Date : 2023-01-10 19:11 UTC (3 hours ago)
(HTM) web link (craftofcoding.wordpress.com)
(TXT) w3m dump (craftofcoding.wordpress.com)
| warinukraine wrote:
| Are there any more informed folks in here that would like to
| discuss how "having an ISO standard" would improve Julia?
| Moissanite wrote:
| Julia is too "trendy" in certain circles (finance bros) for a
| lot of scientific computing types to take it seriously and
| invest a lot of time into it. There are the same sort of
| community brigading problems that people complain about Rust
| for, but without the balancing effect of "this language is
| considered the future by many giant companies who actually have
| some motivation for being cautious with their choices".
|
| I first heard about Julia in about 2012, and while visibility
| has grown massively, I haven't seen anyone putting it into
| production or widespread use in any company or academic group
| except for where you have someone who wants to be an
| "influencer" trying their luck.
| warinukraine wrote:
| > I haven't seen anyone putting it into production
|
| I keep hearing this meme. My company uses it in production.
| StefanKarpinski wrote:
| Ah yes, nobody uses Julia in production... except these
| companies https://juliahub.com/case-studies/ and many more--
| it's impossible to keep up. It's 2023, Julia was #21 on the
| TIOBE index at some point last year. Claiming that nobody
| uses Julia in production at this point is getting to be
| rather silly.
| Moissanite wrote:
| Found a few (energy and pharma) I've heard of who aren't in
| the already mentioned "finance bro" category, or academia -
| but those are singular use-cases. The fact that the list of
| notable use-cases is small enough to be worth compiling is,
| itself, telling.
| dinero_rojo wrote:
| Yeah, I was also wondering about that. My understanding is that
| ISO standards were necessary in the past to somewhat ensure
| that multiple implementations of the same language would be
| compatible with each other, Julia doesn't really seem to have
| that issue today. Would be very interested to hear of any other
| benefits.
| ryanobjc wrote:
| ISO standards for programming languages have been essentially
| totally obsoleted for new languages. Open source is the
| reason: previously you'd only have proprietary
| implementations, so you'd need a standard to ensure they were
| compatible. Now the standard for rust, python, etc IS the
| default implementation. Bug for bug compatibility and all
| that.
| adgjlsfhk1 wrote:
| It would be great! We'd only be able to improve the language
| every 3 years and you would have to pay a few thousand dollars
| to make a pull request!
| trollerator23 wrote:
| Ew
| j_m_b wrote:
| It's also big in molecular dynamic and quantum molecular
| simulations. Think protein folding, protein engineering, small
| molecule drug discovery.
| dalke wrote:
| I've worked in small molecule drug discovery for about 25 years
| and have only used one Fortran program directly, DGEOM95. And
| that was in the late 1990s.
|
| Otherwise, it's mostly C, C++, and Python, with a smattering of
| other languages, at least in the areas I work in.
|
| Back in the mid-1990s, we decided to use C++ for NAMD because
| none of us knew FORTRAN that well, it was a greenfield project,
| and the previous in-house MD codes were in C.
| college_physics wrote:
| Well, if people are serious about fortran as an ongoing idiom
| (and why not, the points made in the post are quite valid) they
| should seriously think about the community aspect.
|
| Development is increasingly a collective endeavour and frequently
| open source affair (and should definetely be so for publicly
| funded science) but fortran is still in the world of Von Neumann
| level geniouses punching algorithms on cards...
| whatshisface wrote:
| The way funding works in science means nobody can develop a
| scientific language that's better than Fortran and interoperable
| with it. Slicing off small amounts of researcher time to improve
| a decades-old solution is the only way things can be done.
| leephillips wrote:
| Julia is better than Fortran and interoperable with it (in the
| sense that it's easy to call Fortran from within Julia).
| [deleted]
| hprotagonist wrote:
| because it goes brrrrrr really well on numerical problems, and
| because there's 60 years of bugfixes in the libraries.
|
| that's more than enough for staying power.
| machina_ex_deus wrote:
| Here's the real reason: they are all copying code from each
| other. Tons of tons of code. Literally all climate global
| circulation models share a lot of code.
|
| If the author had actually seen how crap the climate models look,
| maybe he'll realize the argument is actually backwards and
| climate models are bad.
|
| I've tried code reviewing some of these models just to get an
| idea of how reliable they are. My mind was blown by the extremely
| poor quality of the code combined with literally no redundancy
| between different models in some parts. If some code written in
| 1990 just made a slight mistake, nearly all climate models would
| have the same bias.
|
| And I did find some distributing surface level inaccuracies, such
| as constants being taken from very old inaccurate measurements in
| the 1980s physics books (at least according to the comment), some
| constants being very low precision compared to the accuracy
| required (some constants with only 2 decimals of precision), and
| some things that aren't constant at all and should depend on
| temperature/pressure/CO2 levels/height.
|
| And these are important in a system that actually spends huge
| efforts to model factors with much weaker impact.
| chmaynard wrote:
| * * *
| pantsforbirds wrote:
| Personally I think it's because it's the easiest language to
| write fast code with for vector calculations. It's extremely easy
| to work with Fortran array processing and you don't have to worry
| about pointer aliasing and promising the compiler you won't do it
| like you do with C. Fortran makes it extremely easy to convert
| scientific calculations into array or vector based code that is
| about as optimized as the best C would be, but requiring much
| less domain knowledge.
|
| The downside is Fortran really sucks to work with if you need
| data structures that aren't array based. I'd much rather do non
| numeric, or work that needs more abstract data structures in C or
| C++.
| jononomo wrote:
| The best software engineer I ever worked with, whom I'll call
| Steve, ended up working in Fortran after we parted ways. He had a
| Ph.D. from Harvard in Computer Science and we met at a research
| lab at Harvard Medical School. Interestingly, both of Steve's
| parents as well as his uncle were professors of Computer Science
| at top schools. By the time he was 18 years old Steve had a dozen
| years of programming experience under his belt
|
| On one occasion he was on a team that was collaborating with a
| team from MIT that had contributed some software to the project
| that Steve disapproved of. So, one weekend, Steve entirely re-
| wrote the software that the MIT team had contributed.
| Unfortunately, this turned out to be a firing offense because he
| had humiliated the collaborators.
|
| (One thing to note about Steve is that he was on the spectrum --
| as smart as they come, but not good at reading social and
| political situations.)
|
| Steve was not out of a job for long, however -- he was fired in
| the morning and by that afternoon he had accepted a job with a
| proprietary trading desk on Wall Street (he had a connection).
| His salary at least doubled.
|
| A year after that incident Steve called me up and asked me to
| come down and join him at the prop trading desk, so I did. We had
| a good ride until the 2008 financial crisis and then our entire
| division (several prop trading desks) was fired on Jan 2nd, 2009.
|
| It was difficult to get a job on Wall Street in early 2009
| because everyone was laying people off and going belly up. But
| Steve immediately landed a $400,000/year job with an options
| trading house. When we were catching up over coffee a few months
| later he mentioned to me that one of his projects was designing a
| trading system that needed to solve 500,000 differential
| equations per second. I just wished him luck and thanked God that
| I had moved into coaching the LSAT instead.
|
| Unfortunately, Steve only lasted about 18 months at the options
| trading house -- he had a disagreement with another engineer
| about the best way to implement parallel processing for a certain
| situation and Steve was not one to give an inch when he thought
| he was right. So he got fired.
|
| The conclusion that Steve drew from this was that he never again
| wanted to work with someone who did not have a Ph.D., so he moved
| to a division of NASA that was doing research on how to model the
| melting of glaciers, and which is apparently a space that is full
| of people with Ph.Ds.
|
| It turns out that Fortran is the best tool for modeling glaciers,
| so Steve ended up doing heavy mathematical programming in
| Fortran. As far as I know, this is what he is still working on.
|
| Of course, Steve transitioned a couple of years ago and he (she?)
| now goes by Jessica.
| milliams wrote:
| > Of course, Steve transitioned a couple of years ago and he
| (she?) now goes by Jessica.
|
| It is generally considered polite to refer to people post-
| transition by their new pronoun. So, "she".
| UncleOxidant wrote:
| > It turns out that Fortran is the best tool for modeling
| glaciers,
|
| Is it the best language for this, or is there just more
| existing code for modeling glaciers in Fortran than in any
| other language?
| [deleted]
| gumby wrote:
| > P.S. Fortran often appears on those "outdated languages" lists,
| but the lists are often compiled by people who have little or no
| clue about anything to do with computing, let alone programming
| languages.
|
| So true!
| amelius wrote:
| > languages like Julia are attempting to unseat it
|
| Isn't it CUDA that is taking this role?
| krastanov wrote:
| CUDA is great for big dense matrices, which is incredibly
| important. But there is a lot more to scientific computing than
| big dense matrices.
|
| Also, CUDA is low-level a library by one vendor for one class
| of hardware. Not a language. Languages serious about scientific
| computing already have multiple interfaces for CUDA at various
| level of abstraction.
| amelius wrote:
| There is cuSparse for sparse matrices:
|
| https://docs.nvidia.com/cuda/cusparse/
| plegresl wrote:
| There is a Fortran version of CUDA:
| https://developer.nvidia.com/cuda-fortran
| BeetleB wrote:
| From my time in academia, there are two reasons:
|
| 1. It's fast.
|
| 2. It's tolerant of poor programmers.
|
| Regarding item 2: People who want to specialize in scientific
| computing _intentionally_ avoid becoming good programmers. Most
| of them are not in CS, but in some other engineering or in
| science. They want to focus on their discipline (e.g. climate
| science as this example gives). They don 't care about code
| quality, or even SW practices (e.g. when I was in grad school a
| little over a decade ago, I couldn't get a single one of my
| colleagues to use version control - and some of them had
| codebases in the tens of thousands of lines).
|
| They are not judged by the quality of their code, but by the
| results their code produces. They don't show their code in their
| papers, but the plots/tables. So they'll use the language that
| puts up the least barriers, and is performant. Hence, Fortran.
|
| (Incidentally, many of them don't care about reproducibility.
| They'll modify their large codebase, spit out some results,
| publish them, and then add new features, and will never check if
| the modified codebase will continue to give the same results for
| the same inputs).
|
| All the other reasons in the article? Insignificant factors.
|
| _Edit:_ Note that I 'm not saying that if you code in Fortran
| you're a poor programmer or use poor practices. And I'm sure
| there are good Fortran code bases around.
| akira2501 wrote:
| It's maybe the same reason a lot of mechanics drive junk cars.
| Their expertise blinds them to the risk they're accepting by
| operating so close to the margin.
|
| It's also maybe the reason code is ever written professionally.
| The coders often don't have this domain expertise for their
| particular product and add in things like unit tests, data
| reproduction tests and insane amounts of logging in order to
| reduce the amount of risk inherent in the code itself.
| msla wrote:
| > They don't show their code in their papers, but the
| plots/tables.
|
| Which is a reproducibility crisis in and of itself, as you
| mentioned, if not an outright inducement to dishonesty.
| TillE wrote:
| I was toying with the idea of getting into computational
| chemistry about 15 years ago, as a rare person with a strong
| background in both CS and chemistry. The main reason I didn't
| was because grad school didn't sound like much fun, but the
| prospect of working with a bunch of lousy code wasn't
| encouraging either.
| mrazomor wrote:
| > They are not judged by the quality of their code, but by the
| results their code produces.
|
| How much are software engineers judged by the code quality? And
| how much by the end results (shipped features/projects)?
|
| There's a large gap between good code quality (i.e. keep the
| soft. engs. happy) and passable maintenance (i.e. features and
| bugfixes are not terribly late -- keep the execs/business
| happy).
|
| When it comes to Fortran, I wish it long life. It found a great
| fit and does its job well. Numerical math has many
| peculiarities. I'm happy we have stable libraries for it. Long
| live Fortran!
| BeetleB wrote:
| > How much are software engineers judged by the code quality?
| And how much by the end results (shipped features/projects)?
|
| Many differences:
|
| 1. Everyone can tell if the SW is doing what it should.
| Ensuring correctness in the long run can lead to seeing gains
| in maintaining code quality. With a lot of scientific output,
| many people will just trust the output of the program. Crappy
| code quality is not easy to perceive.
|
| 2. In many code bases, backwards compatibility is important.
| Hopefully you'll have many users. With most scientific
| computation code bases, the user base is tiny (often 1). So
| no one cares if you break something when you add a feature.
| Couple it with bullet 1 above, no one even _notices_ if you
| broke something. With regular SW projects, the need for
| backwards compatibility can once again drive good SW
| practices.
|
| I'm not saying all Fortran programmers are bad. Just that it
| is very tolerant of bad ones, and so they are highly
| overrepresented.
|
| > I'm happy we have stable libraries for it.
|
| As someone who couldn't stomach Fortran, as far as numerical
| work goes, plenty of other languages can utilize those same
| libraries. Having stable numerical libraries is not unique to
| Fortran. In fact, a colleague wasted way too much time during
| his PhD taking his group's 40K Fortran code base and porting
| it to C++.
| karencarits wrote:
| R is also very popular among scientists, and I think that
| workflowr, Rmarkdown, and Quarto are going to increase
| transparency and code sharing among scientists. As you
| mentioned, most researchers just want things to work so that
| they can focus on their results, and integrating processing and
| writing is a good way to do that
| jononomo wrote:
| Doesn't "tolerant of poor programmers" just mean "even better
| for strong programmers"?
| BeetleB wrote:
| > Doesn't "tolerant of poor programmers" just mean "even
| better for strong programmers"?
|
| Not sure. BASIC is very tolerant of poor programmers as well.
| sidlls wrote:
| And usual it depends on the context. "Strong programmer"
| practices don't actually bring much to the table with respect
| to scientific computing. Regression testing (alluded to
| above), for example, is actually (mostly) implicit, as future
| results depend on the continued stable output of past
| results. If the new code caused the old code to produce
| different outputs for the new result, it would show
| somewhere. At least it did when I was doing computational
| astrophysics in academia.
| BeetleB wrote:
| > If the new code caused the old code to produce different
| outputs for the new result, it would show somewhere. At
| least it did when I was doing computational astrophysics in
| academia.
|
| For libraries others use, sure.
|
| For mere code bases that stay in one professor's team and
| have been there for 20+ years - not really. As an example,
| I know one computational group where it often took several
| hours (possibly days) to generate a single data point in
| the curve they were trying to produce. None of that team's
| grad students was willing to waste computational resources
| to see if their code changes would break prior data points.
| RosanaAnaDana wrote:
| This is effectively the same argument for why R is such a
| powerful language. It's the fastest route from theory to
| implementation for many scientists.
___________________________________________________________________
(page generated 2023-01-10 23:00 UTC)