3 ms·

People often insist on this point, and I still don't get it. Honestly it comes across as intentionally exaggerating a claim beyond reason, in order to make it s

People often insist on this point, and I still don't get it. Honestly it comes across as intentionally exaggerating a claim beyond reason, in order to make it sufficiently counterintuitive to sound clever. The point of the program is to get the computer to perform some task; the way we get the program into the computer is to write code. You can say we're writing code for the compiler if you want to be pedantic; or you can say we're writing code for humans too, which is a perfectly valid point. But what do you actually mean by insisting that no, the code isn't for the computer at all, it's solely for other humans? It's clearly the language we use to communicate with the computer to tell it what to do; the fact that there's a translation step (performed by the computer) between what we write and what the computer executes doesn't change that in any relevant way.

pjerem 5y ago
> But what do you actually mean by insisting that no, the code isn't for the computer at all, it's solely for other humans? By insisting on this, I mean that, at any given time, if I have the choice to write code that is easily readable by an human XOR a code that is easy to execute (fast), I will always choose the first. And it’s not a dogmatic ideology : sure there are tradeoffs where writing efficient code is needed, sure it depends on the industry you work. But in general, when needed, it’s much easier to make a readable code faster than to make a fast code easier to read. I’ve seen so much « optimized for machine » code in my career. Probably written by really smart person who chased the millisecond perfection. But 90% of this code is « one shot execution » where millisecond doesn’t change anything and is probably wasted anyway by the surrounding framework/library/context…
- retsibsi 5y ago
  That seems reasonable enough when you unpack it; I just don't see the point of stating it in falsely absolute terms. Maybe (almost certainly) I'm too much of a literalist, but instead of saying 'always' and then clarifying in the next line that of course you don't mean always -- or saying that code is for humans not computers, when you mean that code is for humans and computers -- why not say what you mean the first time around. Maybe it'll be a bit less pithy, but it will also drag you into fewer discussions with people like me :)

pjerem 5y ago

> But what do you actually mean by insisting that no, the code isn't for the computer at all, it's solely for other humans? By insisting on this, I mean that, at any given time, if I have the choice to write code that is easily readable by an human XOR a code that is easy to execute (fast), I will always choose the first. And it’s not a dogmatic ideology : sure there are tradeoffs where writing efficient code is needed, sure it depends on the industry you work. But in general, when needed, it’s much easier to make a readable code faster than to make a fast code easier to read. I’ve seen so much « optimized for machine » code in my career. Probably written by really smart person who chased the millisecond perfection. But 90% of this code is « one shot execution » where millisecond doesn’t change anything and is probably wasted anyway by the surrounding framework/library/context…

retsibsi 5y ago
That seems reasonable enough when you unpack it; I just don't see the point of stating it in falsely absolute terms. Maybe (almost certainly) I'm too much of a literalist, but instead of saying 'always' and then clarifying in the next line that of course you don't mean always -- or saying that code is for humans not computers, when you mean that code is for humans and computers -- why not say what you mean the first time around. Maybe it'll be a bit less pithy, but it will also drag you into fewer discussions with people like me :)