A teaser quote:
Knuth has shown us here how to program intelligibly, but not wisely.
I agree with agreeing with the idea of literate programming, but not the execution. In theory, it allows for easy to follow code that’s well explained - in practice, it leads to unmaintainable mixed nests of TeX and whatever programming language that’s much more difficult to refactor or extend, especially so to people not immersed in it.
Sometimes, code can document itself.
[Comment removed by author]
I’d like to see more of it in science for that reason. The current de facto standard is a paper accompanied by a poorly commented source dump, with little cross-referencing between the two. If you’re lucky, the paper might have pseudocode, which might be possible to heuristically match up with something in the code dump, but often not. The disconnect is pretty unsatisfying.
The closest I’ve seen in recent use is that iPython notebooks are sometimes used for a kind of literate programming.
One comment I saw last time I saw this posted, was that Knuth’s code was written to explain literate programming, and not to solve the problem. That is to say, in introductory CS classes programs are written using methodologies and techniques unnecessary for the scale of the problem for the purpose of teaching the technique, not how to solve the problem, and Knuth is doing the same.
That claim isn’t that convincing to me, because explaining literate programming wasn’t Knuth’s primary goal— writing TeX wasn’t some kind of toy classroom example to show off literate programming, but a completely new publishing system that solved a need he had.
The author (and McIlroy) are missing the point of literate programming, “the problem is not writing software, is living with changing software”
wise engineering solution would produce […] reusable parts.
So what is reusable about the solution? It only works for English words. What happens if the goal changes or If I want to count only nouns? or how many different inflections of a verb occur in the text. What can I use of McIlroy’s solution towards that goal?
I agree with @calvin that mixing TeX with the PL would increase the difficulty (and ‘energy barrier’) to refactor the program; but McIlroy’s ‘solution’ is a testament as to why we “keep reinventing flat tires”.
What happens if the goal changes
Then the shorter simpler code would be easier to adapt.
how many different inflections of a verb occur in the text
Not only is this a vastly different goal, but it’s also very specific, and I find premature planning harmful. You can’t predict the future, and the changes you’ll need to make will probably be different from what you imagine, so if you write a framework now, not only will you have to support it all the time until the change is needed, in the midst of a sea of constanly refactored code, but when that time comes you’ll have to change it anyway.
The only solution is to plan for change in general. Solve your specific problem while keeping the code as simple and architecturally sane as possible, and making changes will be easy, even if they require reëngineering half of the code.
What can I use of McIlroy’s solution towards that goal?
Now, both solutions are example code and shouldn’t be taken at face value. That said, you can write a small program (possibly in awk) to prepend the first form to verb inflections, producing pairs of words such as “run ran”, insert it into the pipeline and change uniq(1) and sort(1) arguments as appropriate.
I had seen the “More shell, less egg” post in 2012 and found it interesting, also the comments there. So I wrote a Python program for it and also a shell (bash) script. (My solutions do not exactly match the problem definition, though, w.r.t. the definition of a word.) They are here: