...what? I mean, maybe some theoretical physicists spend all day doing maths and not simulating it, but almost all the physicists I know spend large amounts of time writing software; anything experimental or observational tends to produce large volumes of data with extremely bespoke analysis, and anything non-experimental probably involves lots of simulations.
People usually have a shock when they start their PhD and find they have to learn to program, fast.
You don't need to be an expert to write working software. You don't even need to be an expert to write good software - you do need to be knowledgeable in that field to write maintainable software, but even experts in the field often write bad software in the name of expedience.
Yes it was more a joke about the terrible quality of code produced by physics. Obviously they write stuff that works for some bizarre value of 'works'. Of course this being HN everyone took it super seriously ;)
I once had to untangle a hairball of stuff made by someone with enough titles that his last name tended to fall off the line or be clipped. Having a degree in physics or mechanical engineering does not automatically make you a (good) programmer.
Dijkstra would have had a fit.
It was interesting software (finite element analysis) but until it was just about completely rewritten absolutely un-maintainable. Which was a bit of a problem because it was also buggy.
> I once had to untangle a hairball of stuff made by someone with enough titles that his last name tended to fall off the line or be clipped.
In my experience, the problem rather is that in science, the intention of the code is to be able to run well enough such that one or two papers can be made out of it and after that, it may be forgotten.
For this purpose, this kind of coding is actually decent and (unluckily) investing time in good software engineering practises would mean that you have less time for writing papers.
In this sense, I would be cautious to call this kind of code "bad", but rather say that if you write code for a company, the priorities are very different.
That code was old rather than bad. And I had the distinct feeling that whoever wrote it simply did not have a lot of background in software and had a job to be done no matter how it got done. And then that code started a life of its own because the software did work most of the time. Edge cases (sometimes literally edge cases: edges of networks of steel trusses) would sometimes give the weirdest results and upon closer inspection you'd find lots of errors in the rest of the output, just not large enough to immediately cause suspicion.
In the end it all worked out and it was a very good lesson in trying to keep the output stable while refactoring the code. This was well before 'TDD'.
My argument is that it doesn't automatically make you a bad programmer either - you do need to be knowledgeable in that field to write maintainable software, but even experts in the field often write bad software in the name of expedience.
Counter point, most great programmers I know are physicists turned programmers. Although they made the full switch and it wasn't to support their research.
