4 ms·
Code is not literature the same way equations are not mathematics. Take any math or physics book, extract all of the equations, and throw away the text. That's
by daly 10y ago
Code is not literature the same way equations are not mathematics. Take any math or physics book, extract all of the equations, and throw away the text. That's how we write programs... just the equations.
However, look at Physically Based Rendering (http://www.pbrt.org/ http://www.pbrt.org/). It won an Academy Award. It should win a Pulitzer. All of the actual source code is in the book and the book is quite readable.
Or look at Lisp in Small Pieces (https://pages.lip6.fr/Christian.Queinnec/WWW/LiSP.html https://pages.lip6.fr/Christian.Queinnec/WWW/LiSP.html). There you will find a complete lisp system surrounded by enlightening text.
Your confusion stems from the coding constraints of the 1970s. My first machine had 8k of memory, 4k of which was operating system. So programs could not exceed 4k, requiring #include statements. As programs grew they adopt the "pile of sand" (POS) format where the "meaningful" directory names like 'src', 'doc', 'test', etc contain the semantic content.
Of course nobody reads POS code. It wasn't written to communicate to humans.
It's the late 90s... code like humans matter, like your code needs to be understood, maintained, and modified. Write literate programs similar to Physically Based Rendering and Lisp in Small Pieces. Stop programming like your grandfather did. Oh, yeah, and write provable programs... but that's another rant.
- pjmlp 10y ago> Stop programming like your grandfather did. Actually those that had family members working at Burroughs, ETHZ, DEC, Xerox PARC, Texas Instruments or Genera, probably should start coding as their grandfather did. :)
- amelius 10y agoBut I think rendering is a specific kind of programming problem that allows simple mathematical reasoning (even if the equations are complicated). To state it differently, information is only flowing one way, i.e. from the model to the display. Documenting a general computer program is much more involved.
- mpweiher 10y ago> Oh, yeah, and write provable programs Provable wrt to what specification?
- glangdale 10y agoI am rather conflicted to read this advice. I think we all want to do this; on the other hand, I think we also generally cannot afford the time to do it. In the project that I run, many major subsystems have been obsoleted by other algorithms, changes in the underlying hardware, etc. Every hour spent not writing beautiful literate code to communicate with other humans in these cases is an hour saved. And yet, and yet.
- white-flame 10y agoEvery hour saved in skipping code readability is 4 hours wasted later in trying to reverse engineer what the code author was doing. Discarding on-the-job code with no maintenance or bug-fixing is astonishingly rare. Even building different parts of a system often requires some code updates in other portions, even if it's not even executed yet. Also, writing your thoughts into concrete, descriptive comments helps you with rubber-duck debugging, often pointing out weaknesses or edge cases you didn't think of when you were heads-down in the code. It's far faster to fix issues that come up ahead of time than after you've swapped it out of mind.
- otikik 10y agoI have been that second person many times and I agree completely with this comment. When you skip readability you are saving your own dev time at the expense of other future devs'.
- sqeaky 10y agoThat sounds like debt in time against the technical aspects of the system in question. If only we as an industry had some label for this Technical Debt so that we could appeal to practices like refactoring, unit tests and continuous integration to pay it down.
- vorg 10y agoAll business is about borrowing stuff from the future -- getting as much gain as possible now and deferring the costs as far as possible into the future, when someone else needs to pay back the debt, or when it can be defaulted on. Business managers don't let tech workers spend time refactoring because it violates this basic business principle. They will make up some other positive-sounding label, e.g. Agile Development, and bandy that around instead. When the system's technical debt is called in, those managers will have already moved to another system to pull the same con, or they'll replace the system with a fresh one complete with green-card-seeking programmers. The programmers on the old system will be retrenched without payment via stack-ranking, and their health problems caused from stress and lack of sleep forgotten about.
- culturedsystems 10y agoI think the post does a good job of arguing against your position here (and thus of explaining why literate programming has been such a failure). Literate programming misunderstands what code is, and so misunderstands how we go about understanding code. Literate programming imagines code is like a book, i.e., something that we understand by contemplating it. The post argues (I think correctly), that code is more like an organism or a mechanism, which can best be understood by observing it in action, or by interacting with it.
- xyzzy_plugh 10y agoI've never heard "pile of sand" used to describe that layout before. I tried googling but it only brought me back to this post. Do you have any background on this term?