Review of APoSD and comments on prior discussions
William Adams
When I first read it, I paused after each chapter and read through my current project, applying the lesson of that chapter to the code as a whole, updating and re-writing as appropriate --- somewhere around the middle of the book, the changes and modifications became smaller and fewer so that by the end of the book, no further changes were warranted on that basis, this despite the project being rather odd in that it is essentially a front-end for a small subset of an existing language (G-code, the commands used for controlling CNC machines).
After all of this, the thing I am left wondering is if this sort of reimplementation is a typical problem-space?
Having read through the discussion here, I would like to revisit a couple of points/make some comments:
- Surprised Literate Programming came up so seldom (made a specific response at the first instance, the other notable instance was by <axiomcas@g.....com> with a response by <brooks.moses@d....net>)
John Ousterhout, Aug 21, 2018, 12:30:15 PM
>I've never felt that graphs are a particularly useful way of describing software structure.
>The interactions between classes end up so complicated that the graph becomes an unreadable mess.
>Also, I'm not sure that the complexity of a graph representation of software correlates with its
>practical complexity (the graph representation might look very complicated, but the software might
>still be pretty easy to maintain).
As a visual person, I find this statement quite frustrating/depressing --- the visually-oriented romantic idealist in me wants some mystical solution like to _The Glass Bead Game_ envisioned by Hermann Hesse. I would like to think that some mechanism could be implemented where problem decomposition so that each element to which a problem is decomposed fits on a single screen, and there is some obvious hierarchy/overview/navigation mechanism to make clear the relationships would afford a useful and expressive graph functionality, except that I wrote almost 100 pages of code and documentation and only saw fit to include one image which actually expressed code (and that was a simple loop which plotted an arc).
As a counterpoint, the radio interview at: https://se-radio.net/2022/07/episode-520-john-ousterhout-on-a-philosophy-of-software-design/ noted the example of:
>...just export 12 dials to the user say, and then, and not only are you punting the problem,
>but you can say, oh, I’m actually doing you a favor, because I’m giving you the ability
>to control all of this....
has an amusing example in history/folklore:
https://www.folklore.org/Calculator_Construction_Set.html
William Adams
\noindent\begin{tabular}{lllllll}\toprule
& \multicolumn{3}{c}{line} & \multicolumn{3}{c}{arc}
\\\cmidrule(lr){2-4}\cmidrule(lr){5-7}
& \multicolumn{1}{c}{cut}& \multicolumn{1}{c}{dxf}& \multicolumn{1}{c}{gcode}& \multicolumn{1}{c}{cut}& \multicolumn{1}{c}{dxf}& \multicolumn{1}{c}{gcode}\\\midrule
cut & cutline\hphantom{dxf} & & cutlinegc & cutarc\hphantom{dxf} & & cutarcgc \\
dxf & cutlinedxf & dxfline\hphantom{gc} & & cutarcdxf & dxfarc\hphantom{gc} & \\
gcode & cutlinegc & \hphantom{dxflinegc} & linegc\hphantom{cut} & cutarcgc & \hphantom{dxfarcgc} & arcgc\hphantom{cut} \\\cmidrule(ll){2-4}\cmidrule(ll){5-7}
& \multicolumn{3}{c}{cutlinedxfgc} & \multicolumn{3}{c}{cutarcdxfgc}\\\bottomrule
\end{tabular}
and then noting:
>that certain commands (\verb|dxflinegc|, \verb|dxfarcgc|, \verb|linegc|, \verb|arcgc|) are unlikely to be needed, and may not be implemented. Note that there may be additional versions as required for the convenience of notation or cutting, in particular, a set of \verb|cutarc|<quadrant><direction>\verb|gc| commands was warranted during the initial development of \verb|arc|-related commands.
which maybe is a strategy worth mentioning.