Astronomers are, for the most part, terrible programmers. This is true of the general population too, but unfortunately almost every astronomer has to actually write programs. Python and co. are probably more of a help than a hindrance as it replaces things like old-school Fortran, IDL, gnuplot and Matlab. Clever groups are starting to wise up to this and have dedicated programmers supporting astronomers, rather than assuming that the computer is just a glorified calculator that everyone needs to be able to use.
For the record I am a numerical astrophysicist and I read and write plenty of bad code every day.
My understanding is that within the scientific/academic community that taking time to write good code is considered to be a black mark as you are "wasting time" which could be better spent on your main project.
So writing bad code every day, means you are serious about your main line of work!
Can't say I agree with this sentiment, but it is slowly changing.
One problem is that to measure a scientist's output, one typically uses their citation count, and people tend to not cite software (there are exceptions), and software based on other software does not transitively pass on those citations.
I can personally attest to this point of view. My degree is in protein structure, specifically x-ray crystallography, and there were more than a few professors in our department who would specifically deride any post-doc/senior-fellow who "got lost in the technology". By which they meant focusing on writing software instead of writing publications/grants.
At that level it's a brutal time/return calculation, like allowing a long trained neurosurgeon to do any of their own paper work. Far more profitable to have them constantly in surgery.
So it was: "fix that three lines of FORTRAN to change the output for 'table #17' and get back to the bench!" (egads i saw some horrific code)
I don't exactly agree with this. As a scientist myself, the term "terrible programmer" is a little bit harsh.
Scientists (and the general population) are not professional programmers. If the need arises, they hire one. Scientists usually need to jot down a prototype and a model in order to see if their theory works.
It's like comparing a physician with a prepper. A prepper might know how to use some first-aid methods and tools, but is not expected to act as a trauma surgeon or emergency doctor. She has just the right knowledge for the task in hand. Yeah, Python might simply be Hansaplast in this case, but who cares if you are alone? :p
No, because his "terrible-ness" has to do with priorities. A scientist's priority is usually to make a fast prototype or model of her theory. I see it at least in my own field (biomedicine).
IF you need a real software developer for some extended work, you hire one. But to call scientists lousy programmers is like calling every driver on this earth lousy driver (in respect to Formula 1 drivers, for example).
As a scientist, astronomer and professional software engineer, I have to say the grandparent is spot on. I've untangled a lot of really, really bad science code. I've seen the gamut too, having worked in high powered computing on many different models across many different fields. In general the code is just terrible, but it gets the job done. Just not efficiently or sometimes accurately (bugs abound).
Things are changing, slowly but surely. Those of you interested in this sort of work should check out http://rse.ac.uk/, and also https://software-carpentry.org/ (Run a workshop! Improve the software environment around you!)
I don't really understand this persistent "carpentry/craftsman" analogy - it seems to me software dev isn't really like a craft at all. I'd sooner stick to "software engineering".
But it isn't engineering. Not really. The number of things you can measure and plan for in advance of implementation are much, much smaller than the number of things you need to build every day. Engineering is a discipline with thousands of years of practice and study behind it, and the traditional 'best practice' is far more likely to work than ones from the programming world. What's more, once the plans have been written, implementation, even prototyping, are predictable and tend to proceed apace. Engineers do not guess, and they test much less than we do, because unless they're working on the bleeding edge, the results are a forgone conclusion for all but the most intricate constructs.
In programming, the map is the territory, and in the time you can map out and nail down all of the unpredictable bits of a program, you could have written it already. We also don't have the luxury of physical laws. The few natural laws that do apply, the speed of light and time complexity, are so rarified and remote that they don't apply most of the time. We share more with the mathematician than the engineer, but even that comparison rings hollow.
We create programs custom built for a purpose, using rules of thumb and our own aesthetic instincts, that meet a need. Craftsman seems appropriate.
It's true that software differs from many Physical Engineering practices too, but why does this automatically make "craft" appropriate? Are Mathematicians called craftsmen because there is no physical output to their efforts?
> We create programs custom built for a purpose, using rules of thumb and our own aesthetic instincts
Software can be general too, it's not the same as, say, making a small stool or chair. Plus, craftsmen are tied to physical constraints too, much like engineers. I'm not sure I agree with how much s/w depends on "rules of thumb and our own aesthetic instincts" though.
I had to collaborate with some distinguished middle-aged scientists, and Fortran is what they spoke. And given how 'terrible' the code was, I developed great respect for their intellect - how they were able to get such results out of their tangles. (The moral of that story is: do not keep your intellectual property only in code)
'terrible' is the word we use, but they were not professional programmers (and had zero interest in the craft) So fit-for-purpose maybe, 'unstructured' but not 'terrible'.
The same is true for meteorologists. But as someone says later in the thread, Python with its dynamic nature does not protect programmers, even more so for non-professional programmers. But it is not an excuse to not follow common-sense.
Once I did some science. And the reason for my bad quality code is (or I hope that it was) that I used to:
1. write the code
2. get some result
3. forget it. throw it away
And I have never felt any pain for maintaining that code. Until I started developing software for some business. Now the whole team has to work on the same codebase forever improving it with new features. It is totally different workflow compared to my science doing in the past.
The other part of not reusing code is that you tend to be pretty casual about edge cases/testing. If I know the params will be valid and the data set well formed (I made them) then I don't need to write 100 lines of checking.
My test is two simple test runs, did they give me the answer I expected? Yes! Winner. Set off long running job and go home
This is precisely the difference from regular programming: Our code is typically going to be used by a very small number of people, and the inputs are typically very well constrained. It's typically faster to just call up the new prospective user and explain the code than to triple your development time making it rock solid.
For instance, I'm currently working on a project where I have to process 110 GB/s of radio data aggregated from 288 antennas. The data will need intensive cleaning after, so plenty of thought is put into logging the right statistics (since we have to average for 3 months to get the right data). This is where the real effort is being applied.
However, if there happens to be a missing edge case or malformed data packet, I can (and will) just cronjob a (if process hung, pkill and restart) the processor with the next bit of realtime data. Anyone who wants to reuse the algorithm will need our exact same antennas and specialized computing hardware, so why make it portable?
Humans are, for the most part, terrible programmers.
I was just setting up https://github.com/karpathy/arxiv-sanity-preserver (By Andrej Karpathy no less) and the whole experience from spinning up a VM to deploying the code made me realize how pathetic computers are for casual use.
26 comments
[ 3.1 ms ] story [ 65.8 ms ] threadFor the record I am a numerical astrophysicist and I read and write plenty of bad code every day.
So writing bad code every day, means you are serious about your main line of work!
Can't say I agree with this sentiment, but it is slowly changing.
And if you go back 10 years, 9 of the top 10 articles are software programs: https://pubrank.carbocation.com/article?y=2007
At that level it's a brutal time/return calculation, like allowing a long trained neurosurgeon to do any of their own paper work. Far more profitable to have them constantly in surgery.
So it was: "fix that three lines of FORTRAN to change the output for 'table #17' and get back to the bench!" (egads i saw some horrific code)
Scientists (and the general population) are not professional programmers. If the need arises, they hire one. Scientists usually need to jot down a prototype and a model in order to see if their theory works.
It's like comparing a physician with a prepper. A prepper might know how to use some first-aid methods and tools, but is not expected to act as a trauma surgeon or emergency doctor. She has just the right knowledge for the task in hand. Yeah, Python might simply be Hansaplast in this case, but who cares if you are alone? :p
IF you need a real software developer for some extended work, you hire one. But to call scientists lousy programmers is like calling every driver on this earth lousy driver (in respect to Formula 1 drivers, for example).
Don't you mean a programmer? A fine scientist can still be a terrible programmer.
> to call scientists lousy programmers is like calling every driver on this earth lousy driver
Why? Most drivers on earth are fine drivers, terrible F1 drivers.
Maybe most scientists are fine scientists, terrible programmers?
In programming, the map is the territory, and in the time you can map out and nail down all of the unpredictable bits of a program, you could have written it already. We also don't have the luxury of physical laws. The few natural laws that do apply, the speed of light and time complexity, are so rarified and remote that they don't apply most of the time. We share more with the mathematician than the engineer, but even that comparison rings hollow.
We create programs custom built for a purpose, using rules of thumb and our own aesthetic instincts, that meet a need. Craftsman seems appropriate.
> We create programs custom built for a purpose, using rules of thumb and our own aesthetic instincts
Software can be general too, it's not the same as, say, making a small stool or chair. Plus, craftsmen are tied to physical constraints too, much like engineers. I'm not sure I agree with how much s/w depends on "rules of thumb and our own aesthetic instincts" though.
'terrible' is the word we use, but they were not professional programmers (and had zero interest in the craft) So fit-for-purpose maybe, 'unstructured' but not 'terrible'.
My test is two simple test runs, did they give me the answer I expected? Yes! Winner. Set off long running job and go home
For instance, I'm currently working on a project where I have to process 110 GB/s of radio data aggregated from 288 antennas. The data will need intensive cleaning after, so plenty of thought is put into logging the right statistics (since we have to average for 3 months to get the right data). This is where the real effort is being applied.
However, if there happens to be a missing edge case or malformed data packet, I can (and will) just cronjob a (if process hung, pkill and restart) the processor with the next bit of realtime data. Anyone who wants to reuse the algorithm will need our exact same antennas and specialized computing hardware, so why make it portable?
Programs are mathematical proofs. If the mathematical proofs are a weak link in a scientific work, then this is a serious problem.
I was just setting up https://github.com/karpathy/arxiv-sanity-preserver (By Andrej Karpathy no less) and the whole experience from spinning up a VM to deploying the code made me realize how pathetic computers are for casual use.
Computers are a hot mess.
from astronomy import find_planet