4 ms·

nonsense. code is intended for a computer by definition.

pjerem 5y ago
No. Code is intended for your teammates. Compiled machine code is for your computer. If you were addressing a machine, you would be writing 0s and 1s, because o boy do the machine know how to execute those little ons & offs.
- retsibsi 5y ago
  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 :)
- aequitas 5y ago
  But you end up with compiled machine code by using a computer to compile your high level code into machine code. You tell that computer exactly how you want it to compile your code into machine code. So in the end the code still is for the computer first. I can write a basic function in 10 different ways that basically do the same, but have bugs or small differences in side effects that might not be obvious to a human reader at first glance. Languages just lack the expressiveness to explain those nuances, hence comments.

No. Code is intended for your teammates. Compiled machine code is for your computer. If you were addressing a machine, you would be writing 0s and 1s, because o boy do the machine know how to execute those little ons & offs.

retsibsi 5y ago
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 :)
aequitas 5y ago
But you end up with compiled machine code by using a computer to compile your high level code into machine code. You tell that computer exactly how you want it to compile your code into machine code. So in the end the code still is for the computer first. I can write a basic function in 10 different ways that basically do the same, but have bugs or small differences in side effects that might not be obvious to a human reader at first glance. Languages just lack the expressiveness to explain those nuances, hence comments.