This reminds me of something Rich Hickey said about becoming a better developer:
https://gist.github.com/prakhar1989/1b0a2c9849b2e1e912fb
“A wide variety of experiences might lead to well-roundedness, but not to greatness, nor even goodness.”
https://gist.github.com/prakhar1989/1b0a2c9849b2e1e912fb
“A wide variety of experiences might lead to well-roundedness, but not to greatness, nor even goodness.”
Not all academic code is that bad, but the heft is definitely towards that end of the pool.
I got really familiar with the distinction, because I spent a while translating PhD project/demo code into actual products for $JOB. It’s definitely mostly in making things secure, stable, maintainable, and debuggable that you lose most of the time.
Once the paper is written, the data analyzed, the project is done. There is no such thing as "maintainability" because the code isn't used past publication.
yk = C * xk + D * uk
is a lot clearer than
position_at_time_k = output_matrix * state_at_time_k + feedthrough_matrix * input_at_time_k.
The first is an idiom. The second is not.
But as a counterpoint, I only know what you meant by the first expression because I read the second expression.
I actually agree with you in large part, that short variable names can have more meaning within an established set of idioms because they allow you to parse whole statements at once. But there’s a trade-off involved, because mathematics can take symbology further than that’s useful.
For example:
E[i=0;5](i**2)
sum([i**2 for i in range(0,5)])
position = C * state + D * input