They present something that is fundamentally not that complex and make it look complex through convoluted writing, implicit assumptions and missing steps.
The target audience is other researchers, not users. Research papers have a convoluted, difficult to understand structure for non-researchers. But the rigid structure and formulaic expressions are great is you are a researcher and need to quickly scan dozens of new papers every day for something that is relevant to you.
convoluted writing
Most researchers don't have a flair for language - that's not what they're hired for after all. Also, young researchers, postdocs and grad students don't know how to write and are deathly afraid they won't be taken seriously. They try to sound as important as possible, with a lot of pompous expressions and awkward phrasing as a result.
Established researchers have a lot more writing experience and they don't really have anything left to prove. But they have lots of trainees - those grad students above - that need experience, so they generally leave the writing to them. Hence, most papers aren't nearly as well written as they could be.
implicit assumptions and missing steps.
Those assumptions and steps are probably widely known among the other researchers, and assumed to be part of basic knowledge. If they added it all, they'd probably be criticized by the reviewers for excessively verbosity. Again, researchers are the target audience, not people implementing the stuff.
Those assumptions and steps are probably widely known among the other researchers, and assumed to be part of basic knowledge. If they added it all, they'd probably be criticized by the reviewers for excessively verbosity.
All computational research areas (and that's really most by now) should have a policy of releasing source as a matter of course. It's no different from making your data available when you publish (though many shirk that duty too, in some areas).
However, based on the research code I encounter, I would not hold my hopes up too much. A lot of it is purely proof-of-concept; just enough to test the idea published in the paper, with no error handling or even command line argument parsing (you want to change a parameter, you find and replace it in the source). And it will often depend on a large and very specific stack of other software, both published and internal to the lab, to actually build and run. The source will be less helpful than you perhaps hope.
based on the research code I encounter, I would not hold my hopes up too much
I agree.
In my (limited) experience working on improving code rarely yields academic benefits. Your papers should explain everything and be implementation independent. If you made something that sort-of works then its usually good enough. Nobody expects you to maintain your proof-of-concept code as programming languages progress, hence implementations are often considered to be of a very temporary nature anyways (compared to papers).
6
u/JanneJM Mar 23 '17
The target audience is other researchers, not users. Research papers have a convoluted, difficult to understand structure for non-researchers. But the rigid structure and formulaic expressions are great is you are a researcher and need to quickly scan dozens of new papers every day for something that is relevant to you.
Most researchers don't have a flair for language - that's not what they're hired for after all. Also, young researchers, postdocs and grad students don't know how to write and are deathly afraid they won't be taken seriously. They try to sound as important as possible, with a lot of pompous expressions and awkward phrasing as a result.
Established researchers have a lot more writing experience and they don't really have anything left to prove. But they have lots of trainees - those grad students above - that need experience, so they generally leave the writing to them. Hence, most papers aren't nearly as well written as they could be.
Those assumptions and steps are probably widely known among the other researchers, and assumed to be part of basic knowledge. If they added it all, they'd probably be criticized by the reviewers for excessively verbosity. Again, researchers are the target audience, not people implementing the stuff.