Hacker News Reader

Comment by bluepizza | Hacker News Reader

Code is primarily for execution. It is very important that it also communicates to people, for the sake of the business that the code supports, but the main thing is the execution.

View on HN

Not intended to be pedantic or contrarian, but I think this falls apart when the code is making sure a signal is sent somewhere (aka communication). If I write a module that allows IPC am I focusing on execution or communication? I understand one can say they were “executing the communication” but at that point we ought to remove execute from the phrase if it has to preface anything you do.

To fully disprove my point, at what point do we never execute something with code so the distinction is even worth mentioning?

OP talks about asking humans what good code looks like, and that's the scope of my response. Code as a communication tool between developers is not its primary reason to exist.

Then why do we keep code after it has been compiled to a functional executable? Why do we (those of us working on teams) have rules limiting how code is written, or even in what language? Why do we study abstraction strategies like OOP and FP? Codifying and then storing a solution is not a necessity essential to a solution, it’s a necessity satisfying an external pressure. My conjecture is that that external pressure is the authors’ need to transmit solutions across time (eg to oneself when it stops running for w/e reason) and space (eg to collaborators), so the solution can be read and understood, revised and extended, in the same way we transmit other ideas in natural language prose or other symbolic systems. If we want to treat this outside of the humanities, we need to abandon high level languages like bash and C and return to manipulating registers and memory directly.

Because we need to change it on a regular basis. We usually only ship binaries - literally what you described.

Reply on news.ycombinator.com