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.
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.
I did a PhD and Post-doc in computational chemistry (focusing on quantum chemical simulations) in the late 2000s/early 2010s and nearly all the software I used was written partially or wholly in Fortran including Gaussian, Q-Chem, Quantum Espresso, and NWChem. Most of the professors I worked with only knew Fortran and had no interest in learning C/C++. The one exception was a professor who was in the process of porting her group's in-house molecular mechanics software from Fortran to C/C++ (don't remember which) so they could get it running on GPUs easily.
I think one of the driving factors in this is that, as other people in this thread have discussed, most of the people writing this software are not software developers and have no interest in being software developers. The scientists trained in the 60s/70s/80s learned Fortran, who then founded their own research groups and taught their students Fortran, who are now running their own groups using Fortran because it's what they know. Some folks use Python for data analysis after their simulations run, but even that was rare 10 years ago.
Agreed! Those quantum mechanics people do love Fortran. I talked a bit with Schrödinger (the company) around 1997 about a job in molecular visualization, and decided I didn't want to be the lone non-Fortran developer in a company.
I'll add another factor to your consideration. Quantum chemistry is mathematically and numerically more challenging than molecular dynamics, and requires a more advanced understanding of chemistry than MD does of chemistry or physics.
I suspect this makes MD codes easier to implement, and more open to multi-disciplinary development, than QC codes.
This thought comes from my experience. My PI at Illinois was Klaus Schulten, who was a postdoc in Karplus's lab at Harvard. Karplus's group developed CHARMM, written in Fortan.
Our lab also used Axel Brunger's X-PLOR, another Fortran code. I know we had a source license to X-PLOR.
If the factor you described were the dominate one, we should have been a Fortran shop.
Yet in the late 1980s/early 1990s (before my time) there were grad students in the group writing their own MD codes, one in C and another in Occam. (Occam was developed for writing parallel algorithms on a transputer. The transputer was seen as the future of parallel computing. The grad students before me built their own hardware around the transputer.)
My generation then developed NAMD using C++. The primary author, Mark Nelson, who had been maintaining one of the older codes, and was annoyed with it. He was grad student from CS (or EE?), with software industry experience before going to grad school. Two other grad students - Bill Humphrey and I - were in physics but had undergrad CS training. Plus, the group itself was multidisciplinary, with Laxmikant Kale's group in the CS department, who developed the Charm++ language. (Also, we collaborated with John Board's group from the EE department at Duke, to use their multipole package for long-distance electrostatics; that was in C or C++.)
Which means in our group alone there were at least three locally-developed MD codes. Each one targeted a different way of handling parallelism.
This was possible because the core MD engine is pretty simple. Adding different integration types, and parameterizing the force field, and developing faster approximate methods to handle hydrogen dynamics, and other aspects of MD are not so simple, but the core is still something many undergrads could write.
While QM codes require a more specialized knowledge that I certainly never learned, and which isn't easy to pick up by non-chemists, leading to a more isolated development culture passed on in the way you describe.
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.
I’m not a wizard but I’m pretty old. After years of scientific programming in Fortran Julia was very easy to switch to. This is not like switching to a (conventional) Lisp or APL, The syntax is quite familiar; you need not use any part of the type system, until you learn more and want to take advantage of it. You’ll need to sprinkle in a few dots to reproduce Fortran‘s array expressions, in places.
How do you get on with package management? That is probably the area where Julia had the most opportunity to trounce Fortran, and yet that is the part of the language I've never managed to get comfortable with.
The package manager is one of my favorite things about Julia. From its integration with Git to the ability to effortlessly reproduce the precise environment in which any program was run, it’s programming language package management, finally, done right:
Thanks - you inspired me to find the right search term for my issue ("CI/CD in Julia"). Basically, the idea of using the REPL (at all, and particularly for package management) never sat well with me; I was looking for the equivalent of "requirements.txt".
Fortran is better than Julia and interoperable with Julia and any language. Any language as of today is better than Julia.
Currently, Julia is a collection of nerd lies and false promises. Look at the recent Julia Discourse post "What is the status of AutoDiff in Julia"? Then read how gloriously the top response describes the situation. Read a few lines more, and you realize there is yet to be a single AutoDiff tool that works effectively and flawlessly in Julia.
"Deny the weakness until we fix it" is a typical speaking pattern among JuliaComputing leaders. There is a good reason for it. JuliaComputing is a for-profit company. They have to find a way to return the stakeholders' million-dollar investments. The easiest way for them is to take a Machiavellian approach rather than being realistic, honest, and fair. I know the nerd culture very well. I am familiar with their denial of their weaknesses and flaws, and their nightmares of being the runner-up. I work with them daily. And JuliaComputing staff is a nerd community from head to tail. For a longer list of Julia's flaws that JuliaComputing pushes under the rug, see https://yuri.is/not-julia/
Regarding fairness and honesty, JuliaComputing staff are responsible for >99% of web posts (including HackerNews) that speak highly of Julia and bash any other language, particularly C++, Fortran, MATLAB, Python, R, Rust.
It seems like you have some emotional baggage involved here.
I use Julia every day (for scientific computing). I have never worked with or for the Julia Computing folks, but don't agree with your characterization of them. I like Fortran too, but personally I would rather use Julia if I have the choice.
> 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.
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.
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.
> 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!
> 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++.
> Everyone can tell if the SW is doing what it should
I am not sure that would be a majority opinion. Robocat’s Law: software complexity increases until it can’t be understood by anybody.
> Fortran code base and porting it to C++
I once tried to counsel a PhD friend to use Mathematica to model their engineering problem, however instead she listened to other people in the civil engineering department to use C++, and she spent most of her time learning C++ and not enough time on her models.
> I am not sure that would be a majority opinion. Robocat’s Law: software complexity increases until it can’t be understood by anybody.
Plenty of banks don't understand how their software works. But they can see that at the end of the day it calculates the right amount of money. (If it doesn't, eventually the client complains, or eventually your manager complains, depending on which direction it was wrong in). For a lot of these scientific modelling systems there's no such sanity check.
> How much are software engineers judged by the code quality?
Difference is of course that most software engineers work on some commercial project with relative little effect on the world politics, and not bleeding edge science that affects current world politics, thus it ought be higher requirements for scientific computing than commercial computing.
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.
> 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.
No. Do you prefer to consider all failure conditions upfront, or only as and when they happen? When two things are similar but not exactly the same, how much do you want to distinguish between them? Programming language design picks positions on these axes, and the answers for poor programmers and strong programmers tend to be different.
Fastest until you include the runtime. (And even then, it falls pretty far behind both Python and Julia in terms of ease-of-use.) The main advantage of R is there's a package for everything, because of how old it is. But it's not especially easy to read or learn. (Or especially hard either--it's definitely easier than most languages, it's just no longer on the cutting edge of that.)
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.
It seems very bold to me to assume that someone who spends their professional life around cars is "blind" to the reality of the cars they drive, when a much more likely explanation is that experts can more accurately evaluate things in their area of expertise than laypeople.
No, of course not. They're not that hard to find; though, and they're pretty willing to talk about their trade.
I didn't say blind to the reality, but blind to the risk specifically. Are you suggesting that there isn't additional risk to driving a car that's older and has known mechanical issues? The expert assumes they can fix them as they break, which is probably true, but they often don't consider the myriad circumstances they can break in and the additional problems that can impose.
This isn't an insult to mechanics, but just an observation of the behavior and of the outcomes. Or are you suggesting experts are impervious to analysis?
> I didn't say blind to the reality, but blind to the risk specifically.
Are you referring to some non-real type of risk, then? I think you may be, and given that this is a subject outside of your wheelhouse you may want to consider that possibility as well.
> Are you suggesting that there isn't additional risk to driving a car that's older and has known mechanical issues?
I'm suggesting that experts may be able to both predict and price those risks more accurately than non-experts. This should be non-controversial.
Consequently, cars which look to you as a nonexpert highly risky may not be. If that is true, as seems likely to me, the rest of your analogy falls apart.
> Or are you suggesting experts are impervious to analysis?
I'm suggesting that more likely explanations than "the experts are wrong and I am right" exist.
> Are you referring to some non-real type of risk, then?
No, I was concerned that's what you were attempting to project into my argument, so I wanted to make it clear.
> I think you may be, and given that this is a subject outside of your wheelhouse you may want to consider that possibility as well.
You continue to prosecute this as if it's an insult that I've laid out and that basic logic couldn't possibly apply to an exceptionally obvious situation. Older equipment brings higher risk. If you can't accept that basic premise, then there's not much for us to discuss here.
> I'm suggesting that experts may be able to both predict and price those risks more accurately than non-experts. This should be non-controversial.
"May be." Well.. precisely. So, here's a possibly illuminating set of questions.. how do you tell the difference between the two? What is the expected ratio of the two groups? What mechanisms might you use to determine this?
> Consequently, cars which look to you as a nonexpert highly risky may not be. If that is true, as seems likely to me, the rest of your analogy falls apart.
I said "additional risk." You're trying very hard to be insulted on behalf of another group and you keep dragging the argument towards that end without seriously considering what I'm saying. I get it, you think my opinion is shallow and unearned, but all you're doing is muddying the conversation with this odd back and forth rather than present _any_ data which could simply make your point for you.
> I'm suggesting that more likely explanations than "the experts are wrong and I am right" exist.
That's hardly my explanation and you're being pretty uncharitable to try to twist this conversation into this made up point. Further, you're presuming that everyone who works on cars is some level of "expert" which would obviate their decisions from any scrutiny from someone who doesn't. That's obviously a flawed point of view with an entire human history of counter examples that thankfully have informed our modern ideas of safety and technological management.
> Older equipment brings higher risk. If you can't accept that basic premise, then there's not much for us to discuss here.
Ok, not much to discuss here then: you are quite wrong in cases mechanics encounter all the time, and too confident to seriously examine the possibility of your wrongness. Good luck out there.
Strictly, not really. Consider, we rarely (ever?) see the actual needles that go into taking samples. Or the conditions in the polling place where surveys were given/taken.
Worse, reproducibility in the "if you click go on this project, you will see it gives the answers I say it does," is of dubious value. Rather, the reproduction is supposed to be "use your models and change assumptions in such a way, you should see these updates."
We are at a time where exact reproduction feels possible, but that is typically not as useful as you'd think. A lot of the robustness of old experiments comes from building them all over again.
Tbh, you'd need a lot more than just the code to reproduce results today. Last year I spent a couple of weeks getting some academic code to work, due to dependency issues. Rolling back drivers, rolling back libraries, trying specific combinations of drivers and library versions, and what have you. How fast the code ran also depended on the various combinations.
The code was not ancient, but written 12 months prior to me trying to build it. (Deep Learning project)
This is one of the places that IMO Julia really shines. It uses a combination of a Project.toml to track dependencies and a Manifest.toml that tracks all the versions of the entire dependency tree which makes it trivial to install all of the package versions.
What is missing? Is this confined to the software environment, or also covering like data accessibility and workflow documentation?
Asking as a scientist interested in reproducible research. Julia has been so much better than python at least in terms of dependency hell, but I still rely on some python packages through PyCall and I feel like that isn’t handled as nicely as Pkg.jl…
It contains a reference to source code in the package server that is disconnected from the package author so it's retrievable in the event of a left-pad-like event. This is what's queried upon download in order to ensure that no funny business could lead to a security threat down the line either. It's kept on the package servers as an immutable source of truth referenced by the UUID and SHA.
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
I'm a scientist, and a programmer, but I don't code in Fortran. I've noticed a "brain drain" of programmers out of science and traditional engineering (mechanical, electrical, etc), simply due to the disparities in pay and mobility. Anybody who's good enough at coding to do it for money is at risk of bailing out of science altogether.
The best way to convince someone to learn SW practices is by giving them the hope of finding a better paying job.
I think there's actually a shortage of good training for scientific programmers, which probably has to come from people who are immersed in it.
On the other hand, is the grass really greener on the other side? One can read plenty of blogs and forum posts from programmers on the commercial side, complaining about the quality of code and coding practices, that they have to work on. I've read about banks running on COBOL and hacked together Excel workbooks.
> Anybody who's good enough at coding to do it for money is at risk of bailing out of science altogether.
No. Tons of people in academia are in academia because they believe in free knowledge and because they want to work as public servants outside the realm of for-profit economy. Most of us tolerate being payed little when working conditions are ok and there is freedom. The reason there are so few good programmers (or that they are in small pockets, or that most good software projects from academia are actually non-research side projects), is because software dev and maintenance it is not at all incentivized, chronically underfunded and understaffed. Short-term project-based financing structure makes any sustained software development hazardous.
OTOH lets put the ugly project web-pages aside and browse through our distribution's package repository for foundational software. How many of them have been passed from hand to hand through generations of academic workers? Quite a lot..
The problem is not that "we are not good at it" or anything. It's just that nobody's giving a shit, so people do it in their "free time" and so the landscape looks a lot like free software. In fact there is a big intersection.
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.
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.
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.
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.
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.
Edit: To be clear; when I first heard about Julia I was excited and a bit sad it had come into my awareness a bit too late for me to use in my PhD. However, since then I see it come up more and more, yet the core UX things which were regarded as "not quite as good as python" seem to persist. Some things need to change in order for the language to get over the next hump of acceptance, and I feel like a community who are very hostile to outside opinions is a major one.
Ah, what an excellent catch-22! If you don't have a list of notable use cases, people claim that there are no serious users. If you make a list of notable use cases, then the fact that you compiled such a list is "telling". Debunking oft-repeated falsehoods is significantly different from being "hostile to outside opinions".
Is there a list of Python users somewhere? What about Fortran?
You are exemplifying one of the points from my original post quite well though, so thanks, I guess.
For others who might not know you as a co-creator of the language with a strong financial interest in its success, don't you think your comments on Julia ought to carry a disclaimer?
Your group have clearly done fantastic work, but having such centralised (and "vocal") management makes it feel more like Julia is a start-up whose product is a language, rather than a language which a spin-out company is commercialising a bit. I trust the former far less than the latter.
Yes! You can find them all over. https://brainstation.io/career-guides/who-uses-python-today#.... for example. People compile incomplete lists for the answer of "do people use X?" It's never expected that the lists are complete. This is the most bizarre comment thread I've ever read.
> but having such centralised (and "vocal") management makes it feel more like Julia is a start-up whose product is a language, rather than a language which a spin-out company is commercialising a bit
Okay... then just read a different source? There's tons of these things online. Stefan just referenced the one he knows the URL of because he's involved with it. But here's a random one. https://www.datacamp.com/blog/the-rise-of-julia-is-it-worth-.... Each package ecosystem tends to have a list, like SciML has a (very incomplete, probably less than 2% listed here according to analytics) list https://sciml.ai/showcase/. There's lists all over.
I used Julia in production on my old job. My friend uses it in her current job in production (they have a product based on Julia). Neither of those companies are on the list.
I doubt any list you'll get is complete. It's more a list of examples
In one of the recent JuliaCon presentations I caught that ASML uses Julia for their telemetry in production. Seems weird to use Julia for telemetry specifically, until you understand that for ASML telemetry involves heavy physics modelling. Lenses, robotics arms, chemical reactions, lasers, it's all part of what "telemetry" is at ASML.
You have to understand, random commenters in HN have very high standards, not like those amateurs at ASML /s
> 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.
Isn’t that either ironic or hypocritical? Rejecting something out of hand because too many people like it is just as superficial as embracing something on account of many people liking it.
Either try it and reject it, or ignore it. But Too Trendy is not a good reason.
Not particularly my opinion, just an observation - when I've brought it up with physicist friends, they only knew the language as something Quants play with. Then again, physicists are weird - they seem to reach for C++ more often than Fortran.
May I introduce a counterexample? I worked for 21 years as a computational physicist for the DoD. I never saw or heard about anyone using a C++ program. Everything was in Fortran, except for a special-purpose C dialect that we used for programming the Connection Machine. I understand that C++ is used in analysis of high energy physics experiments, though (although I’ve also heard that it‘s being phased out).
I know of some large-scale physics simulations that are using Julia, and it’s widely considered the language to use for new projects. It’s what I use now for my physics hobby projects. I’d never heard about its finance-bro associations. And if I had, why would I give a crap?
Ah, but you see, Julia is both too popular and not popular enough! It's too popular with the wrong people (bad unserious people) and not popular enough with the right people (good serious people).
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++.
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.
Steve could work in Java/Python/C++/etc/etc/etc backward and upside down, but he was extremely happy with Fortran, from my brief discussion about it with him -- and if he had thought there was a better tool for approaching the problem then you can be absolutely certain that he would have died on that hill.
Why “Of course”? Do all autistic people have gender dysphoria in your experience?
Also, this person’s name is Jessica and their gender is ‘she’. It would be appropriate to simply refer to her as Jessica, not referring to their old name at all. Also most trans people do not agree that they have changed gender, as your post suggests. Instead, they view themselves as have been misgendered at birth. Thus, to refer to their past by their old pronouns is to continue to misgender them in the present. So please don’t.
Finally the persons gender here is no more important than their race, religion, or countless other unimportant things that you didn’t mention. Maybe leave the whole transgender thread out of any future conversations.
As a non-US person i think OP story was quite interesting, including the gender transition part (because it very much adds to picturing the personality of that steve / jessica and also reflects on a current trend in the US) and the way he told it pretty comprehensive (using other pronouns would have made it much more difficult to follow for example). Please don’t try and censor someone’s speech whose view you don’t agree with, especially when the person is simply telling a story in the chronological order.
Ah yes, this is the justification for referring to African Americans as the N word when taking about them in the past because in the past that was considered a reasonable description. You don’t use the N word just because you are taking about an African American in the 18th century and you don’t use a transitioned person’s misgendered pronouns with the excuse that it is “chronologically accurate”.
This story would have been entirely as informative if the story had simply been about a woman called Jessica.
So yes, I will censor bigoted views. I will censor Nazi propaganda. I will censor racism. And I will censor outing transgender persons.
Your comments are bordering on inflammatory, and are not in the spirit of HN. The OP was not using real names, and has a right to tell their story, so no harm has been done to anyone. As far as censoring goes, we should leave that to the moderators please. Thank you.
OPs comments are inflammatory. They provide an example of how not to treat a transgender person. Again, you don’t get to call someone an N-word just because you changed their name.
They do not have a right to tell a bigoted story on a public forum. They might be permitted, but don’t confuse that with a right.
i assume you are in good faith so i'm just going to ask a simple question : how do you tell the story of someone who changed their name and gender, without stating their original name and gender ?
Let's take OPs story as an example. This is a thread in response to "Why Fortran is a scientific powerhouse." Here is that exact story.
---
The best software engineer I ever worked with, whom I'll call Jessica, ended up working in Fortran after we parted ways. She had a Ph.D. from Harvard in Computer Science and we met at a research lab at Harvard Medical School. Interestingly, both of Jessica's parents as well as her uncle were professors of Computer Science at top schools. By the time she was 18 years old Jessica had a dozen years of programming experience under her belt.
On one occasion she was on a team that was collaborating with a team from MIT that had contributed some software to the project that Jessica disapproved of. So, one weekend, Jessica entirely re-wrote the software that the MIT team had contributed. Unfortunately, this turned out to be a firing offense because she had humiliated the collaborators.
(One thing to note about Jessica is that she was on the spectrum -- as smart as they come, but not good at reading social and political situations.)
Jessica was not out of a job for long, however -- she was fired in the morning and by that afternoon she had accepted a job with a proprietary trading desk on Wall Street (she had a connection). Her salary at least doubled.
A year after that incident Jessica called me up and asked me to come down and join her 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 Jessica immediately landed a $400,000/year job with an options trading house. When we were catching up over coffee a few months later she mentioned to me that one of her projects was designing a trading system that needed to solve 500,000 differential equations per second. I just wished her luck and thanked God that I had moved into coaching the LSAT instead.
Unfortunately, Jessica only lasted about 18 months at the options trading house -- she had a disagreement with another engineer about the best way to implement parallel processing for a certain situation and Jessica was not one to give an inch when she thought she was right. So she got fired.
The conclusion that Jessica drew from this was that she never again wanted to work with someone who did not have a Ph.D., so she 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 Jessica ended up doing heavy mathematical programming in Fortran. As far as I know, this is what she is still working on.
---
In removing the dead-naming and misgendering, did I reduce the usefulness of this story in any way, as a response to "Why Fortran is a scientific powerhouse"? No.
You might ask why I didn't remove the bit about "being on the spectrum". I left this is because, as an Autistic person myself, I too suffer such discrimination in the workplace.
I object to this version because in my view "Jessica" is and always was a man. I understand that not everyone sees it this way, but that's the way I see it. I view biological sex to be a real fact about the world and it is unambiguously binary.
Also, I take the words of the Bible seriously: "Male and female created he them; and blessed them, and called their name Adam, in the day when they were created.” (KJV)
During the time I knew him, Steve was married to a woman and focused on becoming a father. He himself would have described himself as a man.
Finally, the fact that Steve was "on the spectrum" is central to understanding him fully, and the fact that he transitioned is telling because a surprisingly large percentage of men who transition in midlife are extremely intelligent and are on the spectrum. I believe that including the details about his personality and his transition allows a fuller picture of the man to snap more coherently into place, while also shedding light on the current cultural moment.
Also, I simply don't agree that using pronouns that align with a person's biological sex is analogous to using the n-word, and I'm sorry that you feel that way.
I mean no offense to anyone (although I won't go out of my way to stop people from taking offense where none is intended) and there is no engineer I have ever held in higher regard than Steve/Jessica. I saw him pull off absolutely mind-bending feats of engineering and if I had to bet then I would say that every time he put his foot down and died on a hill over an engineering disagreement that he was absolutely in the right from a technical point of view.
> I view biological sex to be a real fact about the world and it is unambiguously binary.
Then you are misinformed and out of date.
>Also, I take the words of the Bible seriously
You do realize that Genesis says nothing about which of them has a penis, or if a penis is required? Is it possible that God has a bigger imagination and vision than you do?
>I mean no offense to anyone
I have told you that your are offending an entire group of people, and your response is "I mean no offense to anyone." You do mean offense. Have the courage to say so.
you're missing a huge part of the story. The fact that the person decide to change their gender is a huge thing. She was born a man, behaved like one for decades, met people under that gender. Then she decided that her real gender was a woman.
I don't understand how you can think of gender transition as something not worth mentioning when depicting the life of a person. It is a huge decision in life, and probably tells a lot, for example about the suffering that person has been living internaly for years.
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...
The natural niche that Fortran has found for itself is largely closed-source, non-collaborative. Same with Ada. The tools continue to be developed because companies spend enough money on them. They don't really need an open community to survive, and the community doesn't really need most of what these tools offer either. I don't expect anything to change unless there's money to be made in doing so.
Agree that this the present situation, just speculating about possible future paths that might see fortran become relevant to more people
> the community doesn't really need most of what these tools offer either
not so sure about that. speaking only about the python universe I could see fortran being an easier alternative to C/C++ for implementing compute intensive stuff and python being the user friendly layer.
about the money: it would be no different than other open source computing stacks, so yes, no cigar. the main reason to add another option is potential productivity gains if one could enable more science oriented developers to develop performant libraries.
Your example about being an alternative to C/C++ for Python-wrapped libraries is a good one. In fact, that's already mostly how Fortran is used - wrapped. That future is here already, and it looks the way it currently does.
> if people are serious about fortran as an ongoing idiom
> Development is increasingly a collective endeavour and frequently open source affair
I disagree with the premise that these two things are linked. Fortran is alive and well in the closed-source corporate world, and it will continue that way indefinitely. It's used by scientists and engineers, not developers, so it's unaffected by changes in the development world. I think it's cool that people want Fortran to find a broader audience, and I think it would help, but it's not necessary for it to continue being used.
> the closed-source corporate world ... will continue that way indefinitely
the lifespans of corporates is well known to get shorter and shorter. Lean periods, in particular, prompt people to re-examine the economics of various technology choices (The world of HPC is full of such extinction events, Unix workstations disappeared in favor of Wintel etc. Having survived previous events does not guarantee eternal survival).
On the other hand the line between "developers" and scientists/engineers will get further blurred and complacent corporates may at some point feel being completely starved of the relevant talent. Just today there was a front page HN discussion about ML augmented PDE solvers. It was not written in fortran.
Put it this way. If C and C++ stop being popular, they'll still survive anyway. Same with Fortran. You just don't see Fortran as often because it's not a general-purpose language like the other two. You'll also never see Fortran as often because people who write Fortran don't share.
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.
I don't think this reflects the OP's concern: It's not that code-reuse is bad in and of itself, it's that the code being reused is being reused without maintenance or review.
You're pointing out a place where I think many software engineers are either untrained, unprofessional, or both. There's already a large body of discourse around the problems that come from these practices—licensing violations, security breaches, and stupendously dumb bugs.
Professional rigor is a thing I wish our industry had more of, but in practice you don't see much rigor outside of safety critical applications because there is rarely incentive for it.
I think that's pretty clearly not the point. As someone who has worked with legacy scientific code written in Fortran, the copying is not the issue, it's blindly copying code that was written 50 years ago, probably by a graduate student, and not reviewed or revised in any way since. As the parent comment points out, if everyone reuses that code, the same errors propagate. It's not the type of reuse that comes with a nice GitHub repo and an established mechanism for reporting and fixing bugs.
In my case, one of the Fortran files essential to my group's research has 11 (!) versions with only filenames like file.f.goodworking (that's literally one of the extensions) to differentiate them and no version control or history.
You know more about the subject than I do, but I don't think you're entirely contradicting one of the author's key points: It's incredibly hard to rewrite a system from scratch - and in effect, to just write a system from scratch.
But it would make sense to have a "professional scientific fortran programmer" go in and do some housecleaning to make things right, without whining, "Why can't I just rewrite it in Java???" Heck, it sounds like fun to me, but that's because I'm basically a professional janitor, and hey, hurricanes and polar vortexes and all that.
So why doesn't that happen? Is testing improvements too expensive? Do scientific programmers just have no respect for the craft whatsoever? Is there nobody with the necessary interdisciplinary skill set?
My experience with academics is that most don't know / don't understand the benefits of coding things in a better way, so they don't even consider hiring someone to help.
The other issue is that the incentives aren't necessarily aligned. They don't get payed to share their code or to make their code reusable. The code is used to publish one or a couple of paper and then thrown away. Maybe someone else will reuse it in the future but the original author doesn't necessarily gain much from that
The way I see it is analogically to writing secure and memory safe code before people knew these things matter.
You needed someone with an incentive to go over code, find the bugs, break into computers and for the entire industry to mature from using strcat to having bug bounties and fuzzing and protect zero. It didn't happen over night and there had to be incredible incentives on the attacker / bug finder to exist, to probe and test the parts that aren't tested, and to serve as the devil's advocate.
The analogy is that it is hard to find bugs which happen silently. Computation inaccuracies are a huge class of bugs that also happen silently. There are no incentives to look at old code.
There's just nothing like it for climate models, and the default behavior of code development is that whatever isn't tested or validated by something will always stagnate with bugs.
The code copy just makes everything worse because implementing the same thing in two different ways by different people is actually good at catching bugs.
So even if I wouldn't have trusted a single climate model, I might trust several climate models developed independently.
The way it works now is that they always prefer to rely on code of others, because academia is driven by citations, and creating new models from scratch means you're missing out mutual citations.
It's a systematic problem, the same way security had been a systemic problem: current methodology just doesn't produce code that fits the requirements. Nobody had neither the incentive nor even the idea that these things should work differently.
Admitting that this is a systemic problem is just a politicized subject.
There are plenty of people saying these models are problematic but getting those working on the models to admit that enough such that the entire system can change its methodology, that won't happen because of human reasons.
> The way it works now is that they always prefer to rely on code of others, because academia is driven by citations, and creating new models from scratch means you're missing out mutual citations.
Ah! This is the interesting point that stands out, as I hadn't anticipated such an incentive. It's a nasty one.
I guess that you need at least some scientific knowledge about the project's subject in order to work with the domain and maintain the code, but not on an expert level, because that would be a waste of resources put a great scientist on maintaining and polishing old code (even if it is important).
And why would a good programmer agree to suffer to the whims of a Professor that is clueless about programming even if the domain itself is important and interesting?
> So why doesn't that happen? Is testing improvements too expensive? Do scientific programmers just have no respect for the craft whatsoever? Is there nobody with the necessary interdisciplinary skill set?
Academia relies on paying grad students peanuts and dangling the carrot of being able to get citations under their name to make up for it. There's no way to publish a paper by cleaning up code, much less get cited for doing so.
Bear in mind there's basically zero "general" funding available. Everything has to be paid out of a specific grant and they want to see it being used for that specific purpose, which likely ends with publishing a paper.
But the short version is yes, academia has no respect for the craft. Papers are what matters, so code will always be the minimum necessary to publish a paper, which is generally: copy someone else's fortran/numpy code, tweak it enough until it runs (once, on your laptop) and gives the result you were looking for, publish.
That is too late You CAN'T start with a developer that, hopefully, do good code. You MUST make good code to be the default, from the start. Is the only chance of lasting improvements.
ie: Is necessary a "Rust/Ada for Fortran", and this ALSO must make, somehow, make some significant impact in current Fortran developers, make them salivate for the chance of do the change.
But iterate on Fortran(C/C++..) and hope that will be better? NEVER will work.
I think the issues you’re mentioning are potentially impacting the world policies (and not a lot of things fall in that category). So if you have some time, it would probably be a great idea to write a detailed post sharing your concerns somewhere.
A writeup would be nice, but frankly, the issues he's mentioning are "to be expected" for anyone who has spent enough time in academia. They were the same issues I'd see in physics and engineering. I wouldn't expect the climate folks to be any different. Why would they? There's no incentive for them to be.
This appears to be an example of modern software engineering principles, or even the notion of basic automation, not having reached climate researchers.
I'm not surprised.
Electrical engineers, engineers in general, insurance mathematicians, physicists.
They write code. System critical code. Code that puts fundamental research, lives, and trillions of dollars at stake. They're very good at keeping track of the complexity. Not always so good at relaying it. They're sometimes legally required to test. Testing sometimes means doing the same manual thing excessively. That happens. Sometimes not.
To this day, I can't believe how many extremely smart people write code for a living, but because of their training, they don't think of themselves as "software developers". So they don't read up on what software developers do to not kill themselves. (Of course, #notall...)
Eh - sorry. I worked with both engineering and physics professors and PhD students when I was in grad school. Everything the top comment says about climate science applies equally well to those disciplines (in academia).
It's not because climate science folks are less rigorous, or less capable. It's because academia indirectly punishes those who do care about SW quality and correctness.
> I think the issues you’re mentioning are potentially impacting the world policies
That said, the climate models tell us very little useful information we didn't already know. I don't think they have much policy impact. Climate change as a phenomenon is not proved by computer modeling, but by real world measurements and established theory about atmospheric processes.
Irregardless of the code quality, the uncertainties in the model are enormous. (No code can simulate the earth without uncertainties.) We can't use such a tool to finetune our response. Gambling for 2.5°C and getting 5°C is too great a risk.
We need to cut emissions as quickly as we are politically able to achieve.
I agree large scale modeling generally should be taken with a (big) grain of salt. Looking at you epidemiologist and economists...
> That said, the climate models tell us very little useful information we didn't already know. I don't think they have much policy impact.
You're wrong in thinking so, these models have an enormous impact since they are what are being used as 'scientific evidence' for the current 'climate change' craze. Without these models there would be only those measurements you mention which in no way indicate the type of trends which the models are being used to warn about. All the measurements show is that it sometimes gets really warm, sometimes really cold, sometimes really windy and sometimes really dry. Measurements do not show a steadily and unerringly upward climbing curve of 'sometimes really warm' and - important in this context - they do not show the current period to be the extreme which it is made out to be. Taking the continental USA as an example - an area for which much data has been collected in a standardised fashion for a long time, making such comparisons possible - it is noticeable that most temperature records - high but also low are found in the early 1900's, mostly centred around 1936 [1]. If you look at newspapers from around that time the tone was comparable to what it is now (in more ways than one given the threat of war on the horizon but that is unrelated to this issue). Looking back further it can be seen that the average temperature has been steadily dropping (as "average over many years", not "average of the last 5 years") since about 8000 years ago when the climatic optimum is to be found [2] somewhere. It is also noticeable that this temperature decline does not follow a straight line, sometimes the average temperature was supposedly - these measurements can only show averages over longer time frames, not year by year - higher than the average during the optimum, sometimes they were lower. The trend is clear and is pointing downwards towards the coming glaciation, whenever that may be. Without the models to use as 'evidence' there would be no 'climate deniers' (an astoundingly dishonest term since most people who are called such do not deny anything about climate, they just do not trust these model calculations with good reason) since current phenomena would just be "weather", not "proof of climate change" - just like they were in the early 1900's.
These models are The Science™ for climate alarmists, no more and no less. They are not the oracles of wisdom as they are made out to be since they suffer from the Garbage In, Garbage Out problem like so many other simulations. As such they are not good tools to use to direct policies but more clubs to wield against recalcitrant opponents.
Does this mean the climate does not change? No, it does not, it changes as it always has and may change in the direction the model calculations show, at least for a while - look at the variations in [2] for an indication of such changes - and it makes sense to prepare for the consequences of a warmer - or colder - climate when possible. Does this mean there is no need to cut 'emissions'? No, it does not mean that either, there are other good reasons to reduce those since these emissions do not just consist of CO₂ but encompass other substances which are actually polluting. It does mean that the laser focus on 'cutting emissions' is most likely the wrong approach since there are far more effective ways to prepare for the effects of a changing climate. No amount of emission reduction will stop the next Katrina disaster but raising levies will, no amount of extra carbon taxation will solve the problems caused by drought but investing in desalination plants [3] will, no milestone in electrification of road vehicles will help with dealing with increased precipitation but upgrading storm drain systems will, etc.
There are other reasons to want to reduce the dependence on fossil fuels as can be seen in Europe which had become unhealthily dependent on...
> they are what are being used as 'scientific evidence'
No, you're wrong about this. The scientific evidence for climate change is multi-faceted and abundant.
All science involves some modelling. No model captures all forces on a system. Despite this, we are able to determine causal relationships based on simple models and empirical observation.
99% of experts consider the evidence for climate change caused by human carbon emissions convincing. Do you think that would be the case if the only evidence was a large, opaque, uncertain, buggy program?
No, actually the comparison is rather apt given the way some subjects are treated - as quasi-religious dogma where criticism is being treated as heresy. Critics of the leading narrative around the changing climate are called "climate deniers" who are "anti-Science" and either uneducated knuckle-draggers or nefarious plotters in the pockets of the enemy - usually the fossil fuel industry. Critics of the narrative around SARS2 are called "anti-vaxxers" and "Science-deniers" who do not "listen to The Science™" and probably are *-ists and *-phobes as well.
The parallel is clear, this is how critics of the narrative around the movement of the Earth, Sun, stars and planets were treated in the 1600's. In that case it was the power of the established Church which saw its monopoly on "truth" threatened by some upstart with a telescope. If his revelations about the orbits of the planets was accepted it would undermine their interpretation of scripture which would undermine their authority so they lashed out to silence the heretic. There is a striking resemblance to the way critics of current narratives are treated, as heretics who need to be silenced before their wayward teachings can poison the populace. This is now how science tends to be done and it is not how science (with a small 's') should be done. Everything should be open to criticism, theories should be mercilessly attacked. The more these attacks falter, the strong the theory will be. Should the attacks succeed in proving the theory wrong everybody will benefit from it.
In the discussion around climate models this means the models need to be subjected to rigorous and merciless testing to find their flaws. They should be tested against historical data, the code should be scrutinised for everything from simple errors to the use of fudge factors and 'magical constants' or 'damping mechanisms' or any other such unproven/unprovable manipulations of the data. If the models withstand these tests and actually manage to follow historical data on which they have not been tested to a reasonable degree of accuracy they will be the stronger for it and their predictive ability will be far higher. This would be a good thing for everyone involved.
Ah, the fabled /9[789]%(.9)?/ argument raises its ugly head again. This claim has several sources, let's have a look at them.
In 2009, the University of Illinois sent a survey [1] online to about 10200 scientists (of many disciplines) with the following two questions:
1: Do you agree that global temperatures have generally risen since the pre-1800s?
2: Do you think that human activity is a significant contributing factor?
3146 responses were received of ~10,200, and of that 31%, 90% said yes to the first question while 82% said yes to the second question. When narrowed down to actual experts in the field (mostly meteorologists) 64% answered 'yes' to the second question. Of the 3146 responses 77 were selected which came from self-professed 'climate experts'. Of these 77 individuals 75 answered 'yes' to the second question. 75/77 = 0.97 -> 97% of experts agree
In reality a self-professed "expert" group of 2.4% of the answerers were selected who in turn formed 0.8% of those who received the survey. The well-known saying about statistics - there's lies, damned lies and statistics [2] - comes to mind here.
Then there was the '2013 Cook study' [3] entitled 'Quantifying the consensus on anthropogenic global warming in the scientific literature' which is often cited as another source for the '97%'. Cook and his team searched the Web of Science for the phrases "global warming" and "global climate change", then categorised the results to what they considered to be their level of endorsement of anthropogenic global warming. While Cook's conclusion - “Cook et al. (2013) found that over 97 percent [of papers he surveyed] endorsed the view that the Earth is warming up and human emissions of greenhouse gases are the main cause.” - was taken for gospel by those who were looking for more endorsement of the earlier '97%' study. What is it based on? Cook created a category called “explicit endorsement without quantification” (papers in which the author did not say whether 1 percent or 50 percent or 100 percent of the warming was caused by man). He had also created a category called “implicit endorsement” for papers that imply (but don’t say) that there is some man-made global warming without quantification of the effect. These were the categories used to calculate the '97%'. Many scientists whose papers were classified in these categories protested to Cook [4] for being selective in which papers were cited and misrepresentation of their positions on the subject of anthropogenic climate change.
Cook's data is available in the study [3], the positions on anthropogenic global warming look like this:
Explicitly endorse AGW 50+% = 0.54%
Explicitly endorse – does not quantify = 7.72%
Explicitly endorse AGW without minimizing it = 24.36%
No Position = 66.73%
Implicit minimizes/rejects AGW = 0.45%
Explicit minimizes/rejects AGW = 0.13%
Explicitly minimizes/rejects AGW as <50% = .08%
These 7 groups are summarised in 4 categories by Cook:
Endorse AGW 32.6%
No AGW Position 66.4%
Reject AGW .7%
Uncertain on AGW .3%
The study arrives at the '97% endorsement' by leaving out the 66% who do not have a position which leaves the 32.6% who endorse some form of AGW against the 0.7% who reject it. Apart from the mentioned problems with the categorisation this is another example of lies, damned lies and statistics [2].
In short, don't use the /9[789]%(.9)?/ argument in an attempt to appeal to authority, especially not in the context of a discussion around the viability of global climate models as evidence for future climate change. First because of the mentioned reasons but also because the '97%' argument has no bearing on the validity of climate models since it just - rightly or wrongly - claims that '...
You claim your standpoint is scientific. But the only peer reviewed article you cite is the one that contradict your claims!
There's no doubt a scientific consensus that human carbon emissions are causing global warming. There are multiple extremely heavyweight sources for this, starting with the IPCC reports.
I'm not a climatologist and can't claim to know the extensive literature. But I do understand the proposed mechanism, I trust people are generally not falsifying data, and I don't see any reason for why thousands of scientists and the IPCC would conspire to make up a lie like that.
On the other hand, the fossile fuel industry has a very clear incentive, and it's well documented they have financed researchers supporting their interests.
I did study meteorology (but not climatology). I do understand the proposed mechanism but I do not trust the models, mostly because I know the limitations of weather and climate models and recognise the magnitude of 'fudge factors' in play when these models are proposed. In many ways they resemble the old joke about the theoretical physicist who was charged with figuring out how to increase the milk production of cows. Although many farmers, biologists, and psychologists had tried and failed to solve the problem before him, the physicist had no trouble coming up with a solution on the spot. “First,” he began, “we assume a spherical cow ... ”.
You mention the clear incentives the fossil fuel industries have in toning down the environmental impact - I explicitly use that term instead of 'climate impact' which has replaced it in popular media since I consider the former to be a known and proven problem - their products have. This is certainly the case and stands without doubt. You do not mention the clear incentives the 'green' industry has in pushing climate panic. Don't you think this is a factor or do you simply agree with their messaging? Does it bother you that several fossil fuel giants have jumped on the 'green' bandwagon so they get to play both sides in this game of charade?
> There's no doubt a scientific consensus that human carbon emissions are causing global warming.
Sure, when you increase the emission of greenhouse gases there is some impact. How large this impact is is less clear, nor is it clear that the increased CO₂ concentration in the atmosphere is the main cause of the recent warm spell or whether it is caused by it. Historical climate records show CO₂ concentration trailing temperature changes, not leading them, the theory being that change in concentration is caused by the change in seawater temperature with colder water absorbing CO₂ (and other gases) which is released when the water warms up again. Another factor in play is the concentration of water vapour in the atmosphere - it shares 3 of the 4 main absorption areas in the spectrum with CO₂ - as is cloud cover (which has a significant effect on the planet's albedo (reflection coefficient)). Since temperature, CO₂ concentration, water vapour concentration and cloud cover are related and interdependent a change in one causes a change in the others. These relationships have not been not taken into account in most models until recently [1] while they are sure to play a role. There are many other factors which are either not taken into account or set at assumed values.
[1] this is one of the areas in which climate models have been improved in the last years: 'Cloud feedbacks have been confirmed as a primary source of these differences, with low clouds making the largest contribution. New observational and modelling evidence strongly supports a combined water vapour-lapse rate feedback of a strength comparable to that found in General Circulation Models (approximately 1 W m–2 °C–1, corresponding to around a 50% amplification of global mean warming). The magnitude of cryospheric feedbacks remains uncertain, contributing to the range of model climate responses at mid- to high latitudes.'(https://www.ipcc.ch/site/assets/uploads/2018/02/ar4-wg1-chap...)
One thing that is worth keeping in mind is that the end result can end up still being right.
Academic Fortran is horrible but it's also (hopefully) maintained by people who know what they're looking for — egregious errors are like errors, things like "this is constant when it shouldn't be" sounds more like a modelling assumption.
People got relatively good climate (well, temperature) estimates from the 80s (if you input the right CO2 data for the future), but I'd image the modern ones more subtle predictions could be quite wobbly (i.e. people complain about them having way too many parameters but I'd imagine many of these are for specific "tasks" rather than massively dominating the overall model)
There are two individual claims, that should be inspected individually:
1. Data from the field showing warming up / other real world observations. I'm not disputing this. This has been corroborated by many different methods without any clear single point of failure.
2. Given 1, what is the probability that the reason for the observed effects are CO2.
This is the crucial policy question, and the problem is that the evidence for 2 is actually purely from these models.
It's easy to take the conjunction fallacy here and immediately jump to 1&2 being more probable than 1 alone, but it's wrong thinking.
The problem is only magnified, in my opinion, by the fact that only few parameters have even had the same kind of detailed analysis that CO2 had. And then the code has clear bias towards the narrative, and the forcing of CO2 in the model is extremely detailed in the parts where the narrative says it's important (radiation forcing) while neglecting many other effects, and taking various things that actually depend on CO2 to be constant.
And finally the problem is that the policy decisions are the complete opposite if 2 is wrong: if we're heading towards more chaotic weather and CO2 isn't the culprit, you would want to rely on fossil fuels instead of the weather (a.k.a solar and wind) for energy.
However, there is a strong first principles model on greenhouse gases effects in the atmosphere: CO2, Methane, and others. All produced as byproducts of agriculture and industrial revolution technologies with ballpark accounting going back to 1800s. In addition there are mass balances accounting for carbon uptake by biomass from satellite imagery.
This isn’t a shot in the dark using excel linest(atmospheric _co2, global_average_temperature) trend plots and calling it a day.
There is sound first principles model to solar thermal energy retention. It may not predict the global average temperature in the next 15 years within 0.2C but you have got to be kidding me bringing up that intro to statistics caveat “correlation!=causation”.
Like do you know how inaccurate most physics modeling is and still tends to be useful?
> One thing that is worth keeping in mind is that the end result can end up still being right.
“ On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.” - Charles Babbage
I think OP means "restrict". If you put that on every pointer by default, that would be the equivalent of what FORTRAN does. Do modern C compilers still assume aliasing in that case?
I was under the impression that inadvertently causing aliasing via by-ref arguments in Fortran is also effectively UB, and any diagnostics that compilers might produce are best-effort and will not catch non-trivial cases.
What would the "right thing" be in this case, in cases where the compiler cannot detect at compile-time? Will it actually check all variables in scope for aliasing when entering the function?
If your pointers turn out to overlap then maybe you get "impossible" stale reads or something, but you don't get demons flying out of your nose like in C.
I don't know how Fortran is any more, I didn't get as far as Fortran 77 since it wasn't 1977 yet.
But students seemed to hate the old Format statements to get your printouts with.
Properly done, a few lines of code could output reams of concise tabular data, but you had to be careful you didn't print out reams of gibberish instead. Those mainframe printers could chew through kilos of paper.
OTOH, for a single page report, a customized printout of meaningful consolidated, summarized data, it could basically take up a whole page of Format statements and even more print statements in the code.
A *whole* page.
And there was no such thing as What-You-See-Is-What-You-Get for printing, it was what you expect is what you hope to get.
Now it's the modern day in the chem lab, and with 10GB of modern scientific software on top of Windows, which requires a high-end desktop for this, I have not stopped wanting to print.
And my data is cloud-ready like never before.
But I have no use for that. After my data has lived a full life, it will go to heaven by itself. Seems like it could also expose my data to hell.
What about my printout?
"Low-code" derivative of Microsoft's Report Definition Language. You've got a template and a GUI and you can even move blocks around. What you see is even less of what you get. There are two main features not shared by Fortran:
1. You will *always* need some kind of iteration before you arrive at your final page format.
2. The code generated is *pages and pages* of XML to get a single printed page.
If I had something as performant as Fortran Format statements it sure would have saved a lot of time.
162 comments
[ 3.9 ms ] story [ 282 ms ] threadIsn't it CUDA that is taking this role?
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.
https://docs.nvidia.com/cuda/cusparse/
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.
I think one of the driving factors in this is that, as other people in this thread have discussed, most of the people writing this software are not software developers and have no interest in being software developers. The scientists trained in the 60s/70s/80s learned Fortran, who then founded their own research groups and taught their students Fortran, who are now running their own groups using Fortran because it's what they know. Some folks use Python for data analysis after their simulations run, but even that was rare 10 years ago.
I'll add another factor to your consideration. Quantum chemistry is mathematically and numerically more challenging than molecular dynamics, and requires a more advanced understanding of chemistry than MD does of chemistry or physics.
I suspect this makes MD codes easier to implement, and more open to multi-disciplinary development, than QC codes.
This thought comes from my experience. My PI at Illinois was Klaus Schulten, who was a postdoc in Karplus's lab at Harvard. Karplus's group developed CHARMM, written in Fortan.
Our lab also used Axel Brunger's X-PLOR, another Fortran code. I know we had a source license to X-PLOR.
If the factor you described were the dominate one, we should have been a Fortran shop.
Yet in the late 1980s/early 1990s (before my time) there were grad students in the group writing their own MD codes, one in C and another in Occam. (Occam was developed for writing parallel algorithms on a transputer. The transputer was seen as the future of parallel computing. The grad students before me built their own hardware around the transputer.)
My generation then developed NAMD using C++. The primary author, Mark Nelson, who had been maintaining one of the older codes, and was annoyed with it. He was grad student from CS (or EE?), with software industry experience before going to grad school. Two other grad students - Bill Humphrey and I - were in physics but had undergrad CS training. Plus, the group itself was multidisciplinary, with Laxmikant Kale's group in the CS department, who developed the Charm++ language. (Also, we collaborated with John Board's group from the EE department at Duke, to use their multipole package for long-distance electrostatics; that was in C or C++.)
Which means in our group alone there were at least three locally-developed MD codes. Each one targeted a different way of handling parallelism.
This was possible because the core MD engine is pretty simple. Adding different integration types, and parameterizing the force field, and developing faster approximate methods to handle hydrogen dynamics, and other aspects of MD are not so simple, but the core is still something many undergrads could write.
While QM codes require a more specialized knowledge that I certainly never learned, and which isn't easy to pick up by non-chemists, leading to a more isolated development culture passed on in the way you describe.
https://lwn.net/Articles/871490/
I use Julia every day (for scientific computing). I have never worked with or for the Julia Computing folks, but don't agree with your characterization of them. I like Fortran too, but personally I would rather use Julia if I have the choice.
that's more than enough for staying power.
So true!
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.
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!
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++.
I am not sure that would be a majority opinion. Robocat’s Law: software complexity increases until it can’t be understood by anybody.
> Fortran code base and porting it to C++
I once tried to counsel a PhD friend to use Mathematica to model their engineering problem, however instead she listened to other people in the civil engineering department to use C++, and she spent most of her time learning C++ and not enough time on her models.
Plenty of banks don't understand how their software works. But they can see that at the end of the day it calculates the right amount of money. (If it doesn't, eventually the client complains, or eventually your manager complains, depending on which direction it was wrong in). For a lot of these scientific modelling systems there's no such sanity check.
Difference is of course that most software engineers work on some commercial project with relative little effect on the world politics, and not bleeding edge science that affects current world politics, thus it ought be higher requirements for scientific computing than commercial computing.
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.
Not sure. BASIC is very tolerant of poor programmers as well.
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.
It seems very bold to me to assume that someone who spends their professional life around cars is "blind" to the reality of the cars they drive, when a much more likely explanation is that experts can more accurately evaluate things in their area of expertise than laypeople.
I didn't say blind to the reality, but blind to the risk specifically. Are you suggesting that there isn't additional risk to driving a car that's older and has known mechanical issues? The expert assumes they can fix them as they break, which is probably true, but they often don't consider the myriad circumstances they can break in and the additional problems that can impose.
This isn't an insult to mechanics, but just an observation of the behavior and of the outcomes. Or are you suggesting experts are impervious to analysis?
Are you referring to some non-real type of risk, then? I think you may be, and given that this is a subject outside of your wheelhouse you may want to consider that possibility as well.
> Are you suggesting that there isn't additional risk to driving a car that's older and has known mechanical issues?
I'm suggesting that experts may be able to both predict and price those risks more accurately than non-experts. This should be non-controversial.
Consequently, cars which look to you as a nonexpert highly risky may not be. If that is true, as seems likely to me, the rest of your analogy falls apart.
> Or are you suggesting experts are impervious to analysis?
I'm suggesting that more likely explanations than "the experts are wrong and I am right" exist.
No, I was concerned that's what you were attempting to project into my argument, so I wanted to make it clear.
> I think you may be, and given that this is a subject outside of your wheelhouse you may want to consider that possibility as well.
You continue to prosecute this as if it's an insult that I've laid out and that basic logic couldn't possibly apply to an exceptionally obvious situation. Older equipment brings higher risk. If you can't accept that basic premise, then there's not much for us to discuss here.
> I'm suggesting that experts may be able to both predict and price those risks more accurately than non-experts. This should be non-controversial.
"May be." Well.. precisely. So, here's a possibly illuminating set of questions.. how do you tell the difference between the two? What is the expected ratio of the two groups? What mechanisms might you use to determine this?
> Consequently, cars which look to you as a nonexpert highly risky may not be. If that is true, as seems likely to me, the rest of your analogy falls apart.
I said "additional risk." You're trying very hard to be insulted on behalf of another group and you keep dragging the argument towards that end without seriously considering what I'm saying. I get it, you think my opinion is shallow and unearned, but all you're doing is muddying the conversation with this odd back and forth rather than present _any_ data which could simply make your point for you.
> I'm suggesting that more likely explanations than "the experts are wrong and I am right" exist.
That's hardly my explanation and you're being pretty uncharitable to try to twist this conversation into this made up point. Further, you're presuming that everyone who works on cars is some level of "expert" which would obviate their decisions from any scrutiny from someone who doesn't. That's obviously a flawed point of view with an entire human history of counter examples that thankfully have informed our modern ideas of safety and technological management.
Ok, not much to discuss here then: you are quite wrong in cases mechanics encounter all the time, and too confident to seriously examine the possibility of your wrongness. Good luck out there.
Which is a reproducibility crisis in and of itself, as you mentioned, if not an outright inducement to dishonesty.
Worse, reproducibility in the "if you click go on this project, you will see it gives the answers I say it does," is of dubious value. Rather, the reproduction is supposed to be "use your models and change assumptions in such a way, you should see these updates."
We are at a time where exact reproduction feels possible, but that is typically not as useful as you'd think. A lot of the robustness of old experiments comes from building them all over again.
The code was not ancient, but written 12 months prior to me trying to build it. (Deep Learning project)
Asking as a scientist interested in reproducible research. Julia has been so much better than python at least in terms of dependency hell, but I still rely on some python packages through PyCall and I feel like that isn’t handled as nicely as Pkg.jl…
The best way to convince someone to learn SW practices is by giving them the hope of finding a better paying job.
I think there's actually a shortage of good training for scientific programmers, which probably has to come from people who are immersed in it.
On the other hand, is the grass really greener on the other side? One can read plenty of blogs and forum posts from programmers on the commercial side, complaining about the quality of code and coding practices, that they have to work on. I've read about banks running on COBOL and hacked together Excel workbooks.
No. Tons of people in academia are in academia because they believe in free knowledge and because they want to work as public servants outside the realm of for-profit economy. Most of us tolerate being payed little when working conditions are ok and there is freedom. The reason there are so few good programmers (or that they are in small pockets, or that most good software projects from academia are actually non-research side projects), is because software dev and maintenance it is not at all incentivized, chronically underfunded and understaffed. Short-term project-based financing structure makes any sustained software development hazardous.
OTOH lets put the ugly project web-pages aside and browse through our distribution's package repository for foundational software. How many of them have been passed from hand to hand through generations of academic workers? Quite a lot..
The problem is not that "we are not good at it" or anything. It's just that nobody's giving a shit, so people do it in their "free time" and so the landscape looks a lot like free software. In fact there is a big intersection.
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.
I keep hearing this meme. My company uses it in production.
Edit: To be clear; when I first heard about Julia I was excited and a bit sad it had come into my awareness a bit too late for me to use in my PhD. However, since then I see it come up more and more, yet the core UX things which were regarded as "not quite as good as python" seem to persist. Some things need to change in order for the language to get over the next hump of acceptance, and I feel like a community who are very hostile to outside opinions is a major one.
You are exemplifying one of the points from my original post quite well though, so thanks, I guess.
For others who might not know you as a co-creator of the language with a strong financial interest in its success, don't you think your comments on Julia ought to carry a disclaimer?
Your group have clearly done fantastic work, but having such centralised (and "vocal") management makes it feel more like Julia is a start-up whose product is a language, rather than a language which a spin-out company is commercialising a bit. I trust the former far less than the latter.
Yes! You can find them all over. https://brainstation.io/career-guides/who-uses-python-today#.... for example. People compile incomplete lists for the answer of "do people use X?" It's never expected that the lists are complete. This is the most bizarre comment thread I've ever read.
> but having such centralised (and "vocal") management makes it feel more like Julia is a start-up whose product is a language, rather than a language which a spin-out company is commercialising a bit
Okay... then just read a different source? There's tons of these things online. Stefan just referenced the one he knows the URL of because he's involved with it. But here's a random one. https://www.datacamp.com/blog/the-rise-of-julia-is-it-worth-.... Each package ecosystem tends to have a list, like SciML has a (very incomplete, probably less than 2% listed here according to analytics) list https://sciml.ai/showcase/. There's lists all over.
I doubt any list you'll get is complete. It's more a list of examples
lol, no.
You have to understand, random commenters in HN have very high standards, not like those amateurs at ASML /s
Isn’t that either ironic or hypocritical? Rejecting something out of hand because too many people like it is just as superficial as embracing something on account of many people liking it.
Either try it and reject it, or ignore it. But Too Trendy is not a good reason.
I know of some large-scale physics simulations that are using Julia, and it’s widely considered the language to use for new projects. It’s what I use now for my physics hobby projects. I’d never heard about its finance-bro associations. And if I had, why would I give a crap?
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++.
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.
It is generally considered polite to refer to people post-transition by their new pronoun. So, "she".
Is it the best language for this, or is there just more existing code for modeling glaciers in Fortran than in any other language?
Also, this person’s name is Jessica and their gender is ‘she’. It would be appropriate to simply refer to her as Jessica, not referring to their old name at all. Also most trans people do not agree that they have changed gender, as your post suggests. Instead, they view themselves as have been misgendered at birth. Thus, to refer to their past by their old pronouns is to continue to misgender them in the present. So please don’t.
Finally the persons gender here is no more important than their race, religion, or countless other unimportant things that you didn’t mention. Maybe leave the whole transgender thread out of any future conversations.
This story would have been entirely as informative if the story had simply been about a woman called Jessica.
So yes, I will censor bigoted views. I will censor Nazi propaganda. I will censor racism. And I will censor outing transgender persons.
They do not have a right to tell a bigoted story on a public forum. They might be permitted, but don’t confuse that with a right.
---
The best software engineer I ever worked with, whom I'll call Jessica, ended up working in Fortran after we parted ways. She had a Ph.D. from Harvard in Computer Science and we met at a research lab at Harvard Medical School. Interestingly, both of Jessica's parents as well as her uncle were professors of Computer Science at top schools. By the time she was 18 years old Jessica had a dozen years of programming experience under her belt.
On one occasion she was on a team that was collaborating with a team from MIT that had contributed some software to the project that Jessica disapproved of. So, one weekend, Jessica entirely re-wrote the software that the MIT team had contributed. Unfortunately, this turned out to be a firing offense because she had humiliated the collaborators.
(One thing to note about Jessica is that she was on the spectrum -- as smart as they come, but not good at reading social and political situations.)
Jessica was not out of a job for long, however -- she was fired in the morning and by that afternoon she had accepted a job with a proprietary trading desk on Wall Street (she had a connection). Her salary at least doubled.
A year after that incident Jessica called me up and asked me to come down and join her 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 Jessica immediately landed a $400,000/year job with an options trading house. When we were catching up over coffee a few months later she mentioned to me that one of her projects was designing a trading system that needed to solve 500,000 differential equations per second. I just wished her luck and thanked God that I had moved into coaching the LSAT instead.
Unfortunately, Jessica only lasted about 18 months at the options trading house -- she had a disagreement with another engineer about the best way to implement parallel processing for a certain situation and Jessica was not one to give an inch when she thought she was right. So she got fired. The conclusion that Jessica drew from this was that she never again wanted to work with someone who did not have a Ph.D., so she 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 Jessica ended up doing heavy mathematical programming in Fortran. As far as I know, this is what she is still working on.
---
In removing the dead-naming and misgendering, did I reduce the usefulness of this story in any way, as a response to "Why Fortran is a scientific powerhouse"? No.
You might ask why I didn't remove the bit about "being on the spectrum". I left this is because, as an Autistic person myself, I too suffer such discrimination in the workplace.
Also, I take the words of the Bible seriously: "Male and female created he them; and blessed them, and called their name Adam, in the day when they were created.” (KJV)
During the time I knew him, Steve was married to a woman and focused on becoming a father. He himself would have described himself as a man.
Finally, the fact that Steve was "on the spectrum" is central to understanding him fully, and the fact that he transitioned is telling because a surprisingly large percentage of men who transition in midlife are extremely intelligent and are on the spectrum. I believe that including the details about his personality and his transition allows a fuller picture of the man to snap more coherently into place, while also shedding light on the current cultural moment.
Also, I simply don't agree that using pronouns that align with a person's biological sex is analogous to using the n-word, and I'm sorry that you feel that way.
I mean no offense to anyone (although I won't go out of my way to stop people from taking offense where none is intended) and there is no engineer I have ever held in higher regard than Steve/Jessica. I saw him pull off absolutely mind-bending feats of engineering and if I had to bet then I would say that every time he put his foot down and died on a hill over an engineering disagreement that he was absolutely in the right from a technical point of view.
Then you are misinformed and out of date.
>Also, I take the words of the Bible seriously
You do realize that Genesis says nothing about which of them has a penis, or if a penis is required? Is it possible that God has a bigger imagination and vision than you do?
>I mean no offense to anyone
I have told you that your are offending an entire group of people, and your response is "I mean no offense to anyone." You do mean offense. Have the courage to say so.
I don't understand how you can think of gender transition as something not worth mentioning when depicting the life of a person. It is a huge decision in life, and probably tells a lot, for example about the suffering that person has been living internaly for years.
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...
> the community doesn't really need most of what these tools offer either
not so sure about that. speaking only about the python universe I could see fortran being an easier alternative to C/C++ for implementing compute intensive stuff and python being the user friendly layer.
about the money: it would be no different than other open source computing stacks, so yes, no cigar. the main reason to add another option is potential productivity gains if one could enable more science oriented developers to develop performant libraries.
> if people are serious about fortran as an ongoing idiom
> Development is increasingly a collective endeavour and frequently open source affair
I disagree with the premise that these two things are linked. Fortran is alive and well in the closed-source corporate world, and it will continue that way indefinitely. It's used by scientists and engineers, not developers, so it's unaffected by changes in the development world. I think it's cool that people want Fortran to find a broader audience, and I think it would help, but it's not necessary for it to continue being used.
the lifespans of corporates is well known to get shorter and shorter. Lean periods, in particular, prompt people to re-examine the economics of various technology choices (The world of HPC is full of such extinction events, Unix workstations disappeared in favor of Wintel etc. Having survived previous events does not guarantee eternal survival).
On the other hand the line between "developers" and scientists/engineers will get further blurred and complacent corporates may at some point feel being completely starved of the relevant talent. Just today there was a front page HN discussion about ML augmented PDE solvers. It was not written in fortran.
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.
Right, code reuse is dangerous and something to be avoided. From now on, let's write everything from scratch.
You're pointing out a place where I think many software engineers are either untrained, unprofessional, or both. There's already a large body of discourse around the problems that come from these practices—licensing violations, security breaches, and stupendously dumb bugs.
Professional rigor is a thing I wish our industry had more of, but in practice you don't see much rigor outside of safety critical applications because there is rarely incentive for it.
In my case, one of the Fortran files essential to my group's research has 11 (!) versions with only filenames like file.f.goodworking (that's literally one of the extensions) to differentiate them and no version control or history.
But it would make sense to have a "professional scientific fortran programmer" go in and do some housecleaning to make things right, without whining, "Why can't I just rewrite it in Java???" Heck, it sounds like fun to me, but that's because I'm basically a professional janitor, and hey, hurricanes and polar vortexes and all that.
So why doesn't that happen? Is testing improvements too expensive? Do scientific programmers just have no respect for the craft whatsoever? Is there nobody with the necessary interdisciplinary skill set?
The other issue is that the incentives aren't necessarily aligned. They don't get payed to share their code or to make their code reusable. The code is used to publish one or a couple of paper and then thrown away. Maybe someone else will reuse it in the future but the original author doesn't necessarily gain much from that
You needed someone with an incentive to go over code, find the bugs, break into computers and for the entire industry to mature from using strcat to having bug bounties and fuzzing and protect zero. It didn't happen over night and there had to be incredible incentives on the attacker / bug finder to exist, to probe and test the parts that aren't tested, and to serve as the devil's advocate.
The analogy is that it is hard to find bugs which happen silently. Computation inaccuracies are a huge class of bugs that also happen silently. There are no incentives to look at old code.
There's just nothing like it for climate models, and the default behavior of code development is that whatever isn't tested or validated by something will always stagnate with bugs.
The code copy just makes everything worse because implementing the same thing in two different ways by different people is actually good at catching bugs.
So even if I wouldn't have trusted a single climate model, I might trust several climate models developed independently.
The way it works now is that they always prefer to rely on code of others, because academia is driven by citations, and creating new models from scratch means you're missing out mutual citations.
It's a systematic problem, the same way security had been a systemic problem: current methodology just doesn't produce code that fits the requirements. Nobody had neither the incentive nor even the idea that these things should work differently.
Admitting that this is a systemic problem is just a politicized subject.
There are plenty of people saying these models are problematic but getting those working on the models to admit that enough such that the entire system can change its methodology, that won't happen because of human reasons.
Ah! This is the interesting point that stands out, as I hadn't anticipated such an incentive. It's a nasty one.
And why would a good programmer agree to suffer to the whims of a Professor that is clueless about programming even if the domain itself is important and interesting?
Academia relies on paying grad students peanuts and dangling the carrot of being able to get citations under their name to make up for it. There's no way to publish a paper by cleaning up code, much less get cited for doing so.
Bear in mind there's basically zero "general" funding available. Everything has to be paid out of a specific grant and they want to see it being used for that specific purpose, which likely ends with publishing a paper.
But the short version is yes, academia has no respect for the craft. Papers are what matters, so code will always be the minimum necessary to publish a paper, which is generally: copy someone else's fortran/numpy code, tweak it enough until it runs (once, on your laptop) and gives the result you were looking for, publish.
That is too late You CAN'T start with a developer that, hopefully, do good code. You MUST make good code to be the default, from the start. Is the only chance of lasting improvements.
ie: Is necessary a "Rust/Ada for Fortran", and this ALSO must make, somehow, make some significant impact in current Fortran developers, make them salivate for the chance of do the change.
But iterate on Fortran(C/C++..) and hope that will be better? NEVER will work.
This appears to be an example of modern software engineering principles, or even the notion of basic automation, not having reached climate researchers.
I'm not surprised.
Electrical engineers, engineers in general, insurance mathematicians, physicists.
They write code. System critical code. Code that puts fundamental research, lives, and trillions of dollars at stake. They're very good at keeping track of the complexity. Not always so good at relaying it. They're sometimes legally required to test. Testing sometimes means doing the same manual thing excessively. That happens. Sometimes not.
To this day, I can't believe how many extremely smart people write code for a living, but because of their training, they don't think of themselves as "software developers". So they don't read up on what software developers do to not kill themselves. (Of course, #notall...)
It's not because climate science folks are less rigorous, or less capable. It's because academia indirectly punishes those who do care about SW quality and correctness.
That said, the climate models tell us very little useful information we didn't already know. I don't think they have much policy impact. Climate change as a phenomenon is not proved by computer modeling, but by real world measurements and established theory about atmospheric processes.
Irregardless of the code quality, the uncertainties in the model are enormous. (No code can simulate the earth without uncertainties.) We can't use such a tool to finetune our response. Gambling for 2.5°C and getting 5°C is too great a risk. We need to cut emissions as quickly as we are politically able to achieve.
I agree large scale modeling generally should be taken with a (big) grain of salt. Looking at you epidemiologist and economists...
You're wrong in thinking so, these models have an enormous impact since they are what are being used as 'scientific evidence' for the current 'climate change' craze. Without these models there would be only those measurements you mention which in no way indicate the type of trends which the models are being used to warn about. All the measurements show is that it sometimes gets really warm, sometimes really cold, sometimes really windy and sometimes really dry. Measurements do not show a steadily and unerringly upward climbing curve of 'sometimes really warm' and - important in this context - they do not show the current period to be the extreme which it is made out to be. Taking the continental USA as an example - an area for which much data has been collected in a standardised fashion for a long time, making such comparisons possible - it is noticeable that most temperature records - high but also low are found in the early 1900's, mostly centred around 1936 [1]. If you look at newspapers from around that time the tone was comparable to what it is now (in more ways than one given the threat of war on the horizon but that is unrelated to this issue). Looking back further it can be seen that the average temperature has been steadily dropping (as "average over many years", not "average of the last 5 years") since about 8000 years ago when the climatic optimum is to be found [2] somewhere. It is also noticeable that this temperature decline does not follow a straight line, sometimes the average temperature was supposedly - these measurements can only show averages over longer time frames, not year by year - higher than the average during the optimum, sometimes they were lower. The trend is clear and is pointing downwards towards the coming glaciation, whenever that may be. Without the models to use as 'evidence' there would be no 'climate deniers' (an astoundingly dishonest term since most people who are called such do not deny anything about climate, they just do not trust these model calculations with good reason) since current phenomena would just be "weather", not "proof of climate change" - just like they were in the early 1900's.
These models are The Science™ for climate alarmists, no more and no less. They are not the oracles of wisdom as they are made out to be since they suffer from the Garbage In, Garbage Out problem like so many other simulations. As such they are not good tools to use to direct policies but more clubs to wield against recalcitrant opponents.
Does this mean the climate does not change? No, it does not, it changes as it always has and may change in the direction the model calculations show, at least for a while - look at the variations in [2] for an indication of such changes - and it makes sense to prepare for the consequences of a warmer - or colder - climate when possible. Does this mean there is no need to cut 'emissions'? No, it does not mean that either, there are other good reasons to reduce those since these emissions do not just consist of CO₂ but encompass other substances which are actually polluting. It does mean that the laser focus on 'cutting emissions' is most likely the wrong approach since there are far more effective ways to prepare for the effects of a changing climate. No amount of emission reduction will stop the next Katrina disaster but raising levies will, no amount of extra carbon taxation will solve the problems caused by drought but investing in desalination plants [3] will, no milestone in electrification of road vehicles will help with dealing with increased precipitation but upgrading storm drain systems will, etc.
There are other reasons to want to reduce the dependence on fossil fuels as can be seen in Europe which had become unhealthily dependent on...
No, you're wrong about this. The scientific evidence for climate change is multi-faceted and abundant.
All science involves some modelling. No model captures all forces on a system. Despite this, we are able to determine causal relationships based on simple models and empirical observation.
99% of experts consider the evidence for climate change caused by human carbon emissions convincing. Do you think that would be the case if the only evidence was a large, opaque, uncertain, buggy program?
[1] https://en.m.wikipedia.org/wiki/Scientific_consensus_on_clim...
Appeals to popularity have obvious pitfalls.
The parallel is clear, this is how critics of the narrative around the movement of the Earth, Sun, stars and planets were treated in the 1600's. In that case it was the power of the established Church which saw its monopoly on "truth" threatened by some upstart with a telescope. If his revelations about the orbits of the planets was accepted it would undermine their interpretation of scripture which would undermine their authority so they lashed out to silence the heretic. There is a striking resemblance to the way critics of current narratives are treated, as heretics who need to be silenced before their wayward teachings can poison the populace. This is now how science tends to be done and it is not how science (with a small 's') should be done. Everything should be open to criticism, theories should be mercilessly attacked. The more these attacks falter, the strong the theory will be. Should the attacks succeed in proving the theory wrong everybody will benefit from it.
In the discussion around climate models this means the models need to be subjected to rigorous and merciless testing to find their flaws. They should be tested against historical data, the code should be scrutinised for everything from simple errors to the use of fudge factors and 'magical constants' or 'damping mechanisms' or any other such unproven/unprovable manipulations of the data. If the models withstand these tests and actually manage to follow historical data on which they have not been tested to a reasonable degree of accuracy they will be the stronger for it and their predictive ability will be far higher. This would be a good thing for everyone involved.
Ah, the fabled /9[789]%(.9)?/ argument raises its ugly head again. This claim has several sources, let's have a look at them.
In 2009, the University of Illinois sent a survey [1] online to about 10200 scientists (of many disciplines) with the following two questions:
1: Do you agree that global temperatures have generally risen since the pre-1800s?
2: Do you think that human activity is a significant contributing factor?
3146 responses were received of ~10,200, and of that 31%, 90% said yes to the first question while 82% said yes to the second question. When narrowed down to actual experts in the field (mostly meteorologists) 64% answered 'yes' to the second question. Of the 3146 responses 77 were selected which came from self-professed 'climate experts'. Of these 77 individuals 75 answered 'yes' to the second question. 75/77 = 0.97 -> 97% of experts agree
In reality a self-professed "expert" group of 2.4% of the answerers were selected who in turn formed 0.8% of those who received the survey. The well-known saying about statistics - there's lies, damned lies and statistics [2] - comes to mind here.
Then there was the '2013 Cook study' [3] entitled 'Quantifying the consensus on anthropogenic global warming in the scientific literature' which is often cited as another source for the '97%'. Cook and his team searched the Web of Science for the phrases "global warming" and "global climate change", then categorised the results to what they considered to be their level of endorsement of anthropogenic global warming. While Cook's conclusion - “Cook et al. (2013) found that over 97 percent [of papers he surveyed] endorsed the view that the Earth is warming up and human emissions of greenhouse gases are the main cause.” - was taken for gospel by those who were looking for more endorsement of the earlier '97%' study. What is it based on? Cook created a category called “explicit endorsement without quantification” (papers in which the author did not say whether 1 percent or 50 percent or 100 percent of the warming was caused by man). He had also created a category called “implicit endorsement” for papers that imply (but don’t say) that there is some man-made global warming without quantification of the effect. These were the categories used to calculate the '97%'. Many scientists whose papers were classified in these categories protested to Cook [4] for being selective in which papers were cited and misrepresentation of their positions on the subject of anthropogenic climate change.
Cook's data is available in the study [3], the positions on anthropogenic global warming look like this:
These 7 groups are summarised in 4 categories by Cook: The study arrives at the '97% endorsement' by leaving out the 66% who do not have a position which leaves the 32.6% who endorse some form of AGW against the 0.7% who reject it. Apart from the mentioned problems with the categorisation this is another example of lies, damned lies and statistics [2].In short, don't use the /9[789]%(.9)?/ argument in an attempt to appeal to authority, especially not in the context of a discussion around the viability of global climate models as evidence for future climate change. First because of the mentioned reasons but also because the '97%' argument has no bearing on the validity of climate models since it just - rightly or wrongly - claims that '...
There's no doubt a scientific consensus that human carbon emissions are causing global warming. There are multiple extremely heavyweight sources for this, starting with the IPCC reports.
I'm not a climatologist and can't claim to know the extensive literature. But I do understand the proposed mechanism, I trust people are generally not falsifying data, and I don't see any reason for why thousands of scientists and the IPCC would conspire to make up a lie like that.
On the other hand, the fossile fuel industry has a very clear incentive, and it's well documented they have financed researchers supporting their interests.
You mention the clear incentives the fossil fuel industries have in toning down the environmental impact - I explicitly use that term instead of 'climate impact' which has replaced it in popular media since I consider the former to be a known and proven problem - their products have. This is certainly the case and stands without doubt. You do not mention the clear incentives the 'green' industry has in pushing climate panic. Don't you think this is a factor or do you simply agree with their messaging? Does it bother you that several fossil fuel giants have jumped on the 'green' bandwagon so they get to play both sides in this game of charade?
> There's no doubt a scientific consensus that human carbon emissions are causing global warming.
Sure, when you increase the emission of greenhouse gases there is some impact. How large this impact is is less clear, nor is it clear that the increased CO₂ concentration in the atmosphere is the main cause of the recent warm spell or whether it is caused by it. Historical climate records show CO₂ concentration trailing temperature changes, not leading them, the theory being that change in concentration is caused by the change in seawater temperature with colder water absorbing CO₂ (and other gases) which is released when the water warms up again. Another factor in play is the concentration of water vapour in the atmosphere - it shares 3 of the 4 main absorption areas in the spectrum with CO₂ - as is cloud cover (which has a significant effect on the planet's albedo (reflection coefficient)). Since temperature, CO₂ concentration, water vapour concentration and cloud cover are related and interdependent a change in one causes a change in the others. These relationships have not been not taken into account in most models until recently [1] while they are sure to play a role. There are many other factors which are either not taken into account or set at assumed values.
[1] this is one of the areas in which climate models have been improved in the last years: 'Cloud feedbacks have been confirmed as a primary source of these differences, with low clouds making the largest contribution. New observational and modelling evidence strongly supports a combined water vapour-lapse rate feedback of a strength comparable to that found in General Circulation Models (approximately 1 W m–2 °C–1, corresponding to around a 50% amplification of global mean warming). The magnitude of cryospheric feedbacks remains uncertain, contributing to the range of model climate responses at mid- to high latitudes.'(https://www.ipcc.ch/site/assets/uploads/2018/02/ar4-wg1-chap...)
Academic Fortran is horrible but it's also (hopefully) maintained by people who know what they're looking for — egregious errors are like errors, things like "this is constant when it shouldn't be" sounds more like a modelling assumption.
People got relatively good climate (well, temperature) estimates from the 80s (if you input the right CO2 data for the future), but I'd image the modern ones more subtle predictions could be quite wobbly (i.e. people complain about them having way too many parameters but I'd imagine many of these are for specific "tasks" rather than massively dominating the overall model)
1. Data from the field showing warming up / other real world observations. I'm not disputing this. This has been corroborated by many different methods without any clear single point of failure.
2. Given 1, what is the probability that the reason for the observed effects are CO2.
This is the crucial policy question, and the problem is that the evidence for 2 is actually purely from these models.
It's easy to take the conjunction fallacy here and immediately jump to 1&2 being more probable than 1 alone, but it's wrong thinking.
The problem is only magnified, in my opinion, by the fact that only few parameters have even had the same kind of detailed analysis that CO2 had. And then the code has clear bias towards the narrative, and the forcing of CO2 in the model is extremely detailed in the parts where the narrative says it's important (radiation forcing) while neglecting many other effects, and taking various things that actually depend on CO2 to be constant.
And finally the problem is that the policy decisions are the complete opposite if 2 is wrong: if we're heading towards more chaotic weather and CO2 isn't the culprit, you would want to rely on fossil fuels instead of the weather (a.k.a solar and wind) for energy.
The Berkely earth group went in with basically exactly the same question, did everything from scratch and broadly replicated the IPCC curves
Sorry to recite a common wisdom that "correlation does not mean causation".
Do you have a competing theory? No one has been able to propose one that fits as well as greenhouse gases, and god knows people have tried.
This isn’t a shot in the dark using excel linest(atmospheric _co2, global_average_temperature) trend plots and calling it a day.
There is sound first principles model to solar thermal energy retention. It may not predict the global average temperature in the next 15 years within 0.2C but you have got to be kidding me bringing up that intro to statistics caveat “correlation!=causation”.
Like do you know how inaccurate most physics modeling is and still tends to be useful?
“ On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.” - Charles Babbage
A big complaint about C was optimization failures from pointer aliasing, but that was fixed a decade ago.
Use by mistake the same variable in separate restrict declarations, and UB dameons will be summoned.
This link shows an excerpt of this parallelization/optimization work for Fortran (Do scroll down...it's amazing).
https://dblp.org/pid/59/1867.html
This is by design.
I don't know how Fortran is any more, I didn't get as far as Fortran 77 since it wasn't 1977 yet.
But students seemed to hate the old Format statements to get your printouts with.
Properly done, a few lines of code could output reams of concise tabular data, but you had to be careful you didn't print out reams of gibberish instead. Those mainframe printers could chew through kilos of paper.
OTOH, for a single page report, a customized printout of meaningful consolidated, summarized data, it could basically take up a whole page of Format statements and even more print statements in the code.
A *whole* page.
And there was no such thing as What-You-See-Is-What-You-Get for printing, it was what you expect is what you hope to get.
Now it's the modern day in the chem lab, and with 10GB of modern scientific software on top of Windows, which requires a high-end desktop for this, I have not stopped wanting to print.
And my data is cloud-ready like never before.
But I have no use for that. After my data has lived a full life, it will go to heaven by itself. Seems like it could also expose my data to hell.
What about my printout?
"Low-code" derivative of Microsoft's Report Definition Language. You've got a template and a GUI and you can even move blocks around. What you see is even less of what you get. There are two main features not shared by Fortran:
1. You will *always* need some kind of iteration before you arrive at your final page format.
2. The code generated is *pages and pages* of XML to get a single printed page.
If I had something as performant as Fortran Format statements it sure would have saved a lot of time.