# thinking-together

Mariano Guerra

02/03/2023, 3:47 PM
What are some great ways to present code in a book/docs? Especially when the code is growing, being modified, etc.?

Andrew F

02/03/2023, 4:04 PM
Re presentation: If you're showing incremental modifications of a piece of code, I like just bolding the new bits. Maybe comment out deletions: not great style in real code, but helps show the whole diff while still being copy-pastable. Unified diffs or whatever are hard to read and highlighting alone is not adequate IMO (and not always possible)... Otherwise I'm not quite sure what the question is. For reference, Bob went really hard with how he handled code in "Crafting Interpreters". It's all worth reading IMO, but Ctrl-F "build system" if you want to focus on the code part. :)

brett g porter

02/03/2023, 4:19 PM
Long ago, Bruce Eckel also released the toolchain he used for similar purposes in one of his Thinking in Java books. Or if you want to go super-old school, dust off Knuth and use CWeb/Literate Programming

Josh Justice

02/12/2023, 1:19 PM
Years ago I made a tool that would translate a sequence of git commits into markdown it interpreted the commit message as commentary to put between each diff. Seemed like there was potential there. The biggest challenge was that I didn't have great tooling for frictionless editing of past git commits


04/04/2023, 3:17 PM
In a system that supports forward declarations and function redefinition, you can do Knuth-inspired LP-ish function calls with very long names (e.g.
, &c) and then define and redefine those functions—originally with a trivial or naive first pass at implementation, and then later with the "grown up" implementation.
No tangle and weave necessary.