Earlier quoted context omitted.
Computer scientists also assume that you know what inputs your program needs and what is the range of the outputs. That is out of touch with scientific research. We may change overnight completely the inputs, the core logic and the outputs. Having to babysit function signatures, manage memory and types throughout these activities is just draining.
That is also how "computer scientists" and software engineers work. Our time is just valued a lot higher so we've come up with techniques to make our work more efficient and faster, like structuring our code well using types and function signatures. The added bonus is you get science that's you know, repeatable. Because the difference between industrial code and prototype code is that it gets run so often there can't…
One of the hard lessons in the transition was realizing that things that allowed me to work more efficiently when I was a software engineer instead reduce my efficiency in my new career.
You might get a decent analogy of the difference by comparing photographs of the first transistor with pictures of every subsequent transistor. The first transistor's clearly going to be terrible in any production application. But the same characteristics that make it so terrible for practical use were also, to varying degrees, essential to or characteristic of the exploratory process that led to its creation.
It's similar for my R&D code. In order to do my R&D work more efficiently and effectively, I need to do things that would be unholy in production code. This is why there's a separate and essential productionizing step where my output is heavily revamped and possibly even completely rewritten in a different programming language.
re: repeatability, I've discovered that it, too, means something slightly different in a science context than it does in an engineering context.