4 ms·

I find myself uncertain about the thesis. Code that is clear and expressive to a human should not be assumed to also be efficient and optimal for a computer. A

by Kalium 12y ago

I find myself uncertain about the thesis. Code that is clear and expressive to a human should not be assumed to also be efficient and optimal for a computer. As writers say, know your audience.

al2o3cr 12y ago
True enough - but code that humans can't read is far more difficult to debug, to profile, and to optimize. Efficiency can be improved after the code is working, but improving readability on a prematurely-optimized codebase frequently involves `rm -rf`.
azdle 12y ago
> Code that is clear and expressive to a human should not be assumed to also be efficient and optimal for a computer. Yes, but most of the time it's more important that a human can understand it easily than it is for it to be the most efficient code in the world.
aswanson 12y ago
"Code that is unreadable by other engineers, even if it's functional, is bad code."
- Retra 12y ago
  Code is designed to solve problems. If someone can't read your code, they are going to have a hard time using it to solve their problems. If you don't document edge cases, modes of failure, intent and methodology... then it is worse code than it could be. Somebody won't be able to use it because they won't be able to tell if it solves their problem. A few weeks ago I read a quote about someone saying that good code should be 'self-documenting' and that it should be obvious what it does. This is a red herring -- it assumes you wrote code that works perfectly. If there is a bug in your 'self-documenting' code, then how is someone supposed to know if it is wrong or not?
robbrown451 12y ago
I didn't see what you are seeing in the thesis. There was nothing that said that the sole end goal of programming is to be expressive to humans (whether those humans be yourself, other coders or end users). As for audience, when coding you can consider your audience to be both humans that follow you, as well as the machine it is running on.
- Kalium 12y ago
  One of the ideas mentioned is that code that's readily understood by humans is code that will be efficient for computers. I'm not sure I agree with this.
- aswanson 12y ago
  As well as your future self, weeks from now, to avoid having to say 'What the fuck was I thinking when I wrote this?'.

by Kalium 12y ago

I find myself uncertain about the thesis. Code that is clear and expressive to a human should not be assumed to also be efficient and optimal for a computer. As writers say, know your audience.

al2o3cr 12y ago

True enough - but code that humans can't read is far more difficult to debug, to profile, and to optimize. Efficiency can be improved after the code is working, but improving readability on a prematurely-optimized codebase frequently involves `rm -rf`.

azdle 12y ago

> Code that is clear and expressive to a human should not be assumed to also be efficient and optimal for a computer. Yes, but most of the time it's more important that a human can understand it easily than it is for it to be the most efficient code in the world.

aswanson 12y ago

"Code that is unreadable by other engineers, even if it's functional, is bad code."

Retra 12y ago
Code is designed to solve problems. If someone can't read your code, they are going to have a hard time using it to solve their problems. If you don't document edge cases, modes of failure, intent and methodology... then it is worse code than it could be. Somebody won't be able to use it because they won't be able to tell if it solves their problem. A few weeks ago I read a quote about someone saying that good code should be 'self-documenting' and that it should be obvious what it does. This is a red herring -- it assumes you wrote code that works perfectly. If there is a bug in your 'self-documenting' code, then how is someone supposed to know if it is wrong or not?

robbrown451 12y ago

I didn't see what you are seeing in the thesis. There was nothing that said that the sole end goal of programming is to be expressive to humans (whether those humans be yourself, other coders or end users). As for audience, when coding you can consider your audience to be both humans that follow you, as well as the machine it is running on.

Kalium 12y ago
One of the ideas mentioned is that code that's readily understood by humans is code that will be efficient for computers. I'm not sure I agree with this.
aswanson 12y ago
As well as your future self, weeks from now, to avoid having to say 'What the fuck was I thinking when I wrote this?'.