Okay - so grad students have very little incentive to write readable code... fine, understandable. They are usually lucky if they can write an algorithm which isn't finely tuned to a very narrow dataset. In that sense, most Ph.D papers are outright fabrications lying about capabilities written by authors seeking paychecks. If people were able to investigate the underlying source code, that would be fairly apparent.
That said, why do so many professional research developers also suck as writing comprehensible code? They have fat paychecks, what's the problem now? There absolutely exist research developers who write very high quality software. They may still use very terse nomenclature (due to high cognitive load), but their code can be logically comprehended by those who do not understand the field. There are a lot of reasons (I think) for this; no incentive to improve, poor understanding of their own discipline, no acknowledgment of the problem, expectation that such work is for "engineers".
In reality - a lot of research developers are simply incompetent, but they find a way to regularly convince others they are not.. often through obfuscation. They're stringing together implementations from various publications (which themselves might be total fabricated lies) with relatively little comprehension.
That's okay, a lot of software engineers are incompetent too.
Own it.
I'm not conflating. The vast majority of research software is written by grad students.
> why do so many professional research developers also suck as writing comprehensible code?
Because incentives aren't aligned. And it's not even clear they should be aligned.
> There absolutely exist research developers who write very high quality software... In reality - a lot of research developers are simply incompetent
There absolutely exist software developers who write very high quality software... In reality - a lot of software developers are simply incompetent.
> If people were able to investigate the underlying source code, that would be fairly apparent... Own it
1. A huge amount of research software is open-sourced and does work as advertised.
2. You don't get it both ways. Either no open source demands, or no expectation that grad students should "own their work" -- and then making demands that they literally don't own their work.
> Shouldn't incentives be better aligned. Should this type of complaining be celebrated?
IMO it's not as clear cut as some people think. Honestly, is the cost worth the cost to tax payers if the super high quality implementation is going to be out-of-date in 3 months?
It depends on the research project and how fast the field is moving.
At base, I wonder if the current system isn't reasonable. If research can't even stay fresh long enough to make it from conference paper to journal paper, maybe we shouldn't be throwing hundreds of thousands of engineering dollars at quality implementations.
All we're talking about is better quality code. This isn't a huge cost. It's usually just a matter of a small change in mindset while coding, and a few minutes refactoring and commenting once the code is working. Those minutes are repaid (and more!) the very next time the author has to revisit that code again. Good quality code saves money, it doesn't cost it.
You can leave error conditions unmanaged, leave the UI as a complete mess, don't worry about internationalisation, none of the things that add serious cost to a commercial project. This is not that.
If research coders aren't aware of code quality currently, maybe it's time that they got taught it? Writing good code will help researchers who write code, not hinder them.
Been there, done that, no. Refactoring a crappy implementation into a high quality, documented code base takes an enormous amount of time. And literally no one in academia cares about it. Industry doesn't care about it either because there's a presumption that any software created while in academia is inferior quality.
If you advise students to do this type of work with the expectation of any type of personal reward, you're a liar. They're basically doing software engineering that academia won't reward them for, and their year of software engineering won't count as job experience if they go into industry. And they aren't being paid software engineering salaries. It's just exploitative.
> All we're talking about is better quality code. This isn't a huge cost
This flies in the face of what the market bears in tech salaries. But no matter; I'll just never pay my software devs more than 30k, and also only give them maybe 20% of their time for actual software development... I'm sure I'll get high quality code! /s
> Those minutes are repaid (and more!) the very next time the author has to revisit that code again.
Which for 99% of research code will literally never happen.
> If research coders aren't aware of code quality currently
Tons of grad students leave academia after their phd, take very high paying jobs in industry, and become valued members of software engineering teams.
Research jobs are not software jobs. The goals and incentives are different. Sometimes it makes sense to create a maintainable research software system, but usually it makes no sense because the code is throw-away for testing an idea. That's OK. No one owes you an epsilon of your product.
I'm talking about Person A just not writing bad code in the first place.
Of course if it doesn't matter if the code runs correctly, by all means don't comment it.
Academics are not rewarded for good software engineering. The incentives are not properly aligned. And more-over, the that's not necessarily a bad thing! Research is research, not engineering.
Stop expecting production quality code out research groups. The purpose of research is to explore ideas, not implement some epsilon of your product.
If you want a perfect exposition in addition to a high quality implementation, there are ways to get it. Pay the consulting fees. Or pay the tuition. Or hire the students, Or if you can't afford that, wait for the thesis/book.
> Is pseudo-code a fucking premium?
In a paper? Well... yes. Categorically, emphatically, yes. If you want to read an exposition where space does not come at an extreme premium, you'll have to wait for the thesis/journal article.
Space comes at a premium for stupid reasons (artificial page limits) but also for good reasons (expositions cost time, which costs money and grad student time, and fuck if I'm doing a 10 year Ph.D. at $7/hr because you're irritated at some python code.
> Can you at least try to give some intuition before showering the reader with equations?
Either 1) no because you're not the intended audience, in which wait for the thesis/TR/dissemination blog post where I'll work every gory detail; or 2) no because the equations are hard for all of us to understand and no one has solved the exposition problem yet.
> How the fuck do you dare to release a paper without source code?
So all the products you work on all totally open source, eh? Either fully commit to Stallmanism while living off less than minimum hourly wage or get off your high horse.
> Why the fuck do you never ever add comments to you code When naming things, are you charged by the character? Do you get a bonus for acronyms? Do you realize that OpenAI having needed to release a "baseline" TRPO implementation is a fucking disgrace to your profession? Jesus christ, who decided to name a tensor concatenation function cat?
Because they're being paid 30k a year at best for 80 hour weeks under intense pressure to implement new ideas and the prop firms and Googles are knocking with 200k comp packages and honest to god 5 day work weeks. Time is (SERIOUS) money when you're slogging through grad school. Again, walk a mile.
And again, really, the point is to test ideas. For every publicly release line of code coming out a research group there's 5x or 10x unreleased code implementing dead ends.
If you want all this, stop bitching at over worked and absurdly under-paid grad students, and start calling your congressman to support higher NSF budgets so research groups can hire more permanent research support staff.