4 ms·

Since code is primarily for communication between humans, I suppose we should look to the humanities and ask them what good writing is, but therein lay a parall

• zdragnar 2y ago
  Well written code in one language looks nothing like good code in a different family. They won't even share a similar syntax, grammar or idioms. The only real lesson to be learned is "write for your audience" in my humble opinion.
  • wryoak 2y ago
    A good analogy for how good prose looks different in different languages, to different cultures or professions, etc.
• bluepizza 2y ago
  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.
  • Gorath 2y ago
    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?
    • bluepizza 2y ago
      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.
  • wryoak 2y ago
    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.
    • bluepizza 2y ago
      Because we need to change it on a regular basis. We usually only ship binaries - literally what you described.
• Dove 2y ago
  I say this often. Code is for people, and the qualities of great code parallel those of great writing: clarity, efficiency, and a sort of profound obviousness and inevitability. The job of software architects is the role Heidegger ascribes to man when he calls us "shepherds of Being". To understand the world as it is, and find the right abstractions to describe it. To constantly evolve those abstractions toward better ones, clearer ones, to seek out ways to represent things that make solutions seem obvious and inevitable. A mathematics professor once said to me that as time went by, the definitions in mathematics became more complex while the theorems became simpler. "Why is that?", I asked, and he replied, "It's progress!" This is the sort of progress that the software architect seeks as well: to set up the problem so excellently that the solutions are smooth and the process is enlightening. Great writing, and great code, are first and foremost about great ideas. About brilliant ideas that change how you view the world for the better.
• dbtablesorrows 2y ago
  No. It needs to be treated as engineering if we want any stability and maturity in this field. Humanities are too subjective.