1. 77

    1. 3

      Haha! This is epic!

    2. 12

      I don’t think he was framed. I think the article explains that McIlroy is doing a literature review in the spirit of Knuth’s literate programming, and the shell script was written in the context of reviewing Knuth’s literate program as a program and as literature. The fact that two people who were discussing an article neither of them had read came to a conclusion that isn’t supported by the article is unsurprising (and common in discussing “the classics” of programming literature).

      1. 17

        “Knuth’s 1986 Literate Programming Article Has Been Taken Out of Context” just wasn’t gonna get the clicks.

        1. 15

          This was a newsletter post. It was sent to people who already signed up to receive my emails. I decided to have a bit of fun with the title, and wasn’t expecting it to go so viral outside of my regular readers.

          1. 9

            No snark intended beyond good fun; it was a good article, and yours is the better title. I’m tempted to subscribe.

            1. 9

              All good! As we all know, tone carries 100% perfectly on the internet

          2. 7

            “A programmer tried Literate Programming - you won’t believe what happened next!”

            1. 4

              Wait until a lobster reads the rest of the “premature optimisation” paper.

              1. 3

                What‽ I would have clicked on that in a beartbeat!

              2. 14

                If one reads the original article (which is quite long, both on the LP part and the response, it’s clear no framing was being done. I think the “framing” is the decades-long game of telephone afterwards which boiled down to “Donald Knuth’s 10 page LP opus was replaced by a very small shell script”.

                1. 3

                  (and common in discussing “the classics” of programming literature).

                  My favourite example of this is the diatribes you see sometimes around ‘single exit from a procedure’ and gotos in general. ‘Procedures should be single entry, single exit’ is about avoiding jumping into and out of procedures in unexpected places. It’s not about a single return statement at the end of a function! And ‘goto’ is considered harmful when it’s used to jump into the middle of random functions and in place of structured programming facilities like if/else statements and loops, not when it’s used to implement a state machine!

                  1. 2

                    And ‘goto’ is considered harmful

                    This is exactly what I’ve been thinking about, parts one and two (which I can’t submit to lobsters as I’m a content marketer)

                    1. 1

                      Programmers are no less immune to arguing from authority or cargo-culting than other people.

                      1. 3

                        I think it’s more common in programming than in other fields, that, in comparison to programming, have long-established rigorously-derived bodies of knowledge.

                        1. 1

                          You’d be surprised! From my discussions with people in other industries, cargo culting is pretty universal. Remember, it took decades to get doctors to wash their hands!

                  2. 2

                    I personally think this is a really bad article, but others might be interested to compare to https://lobste.rs/s/xski3m

                    Why is it bad? It fundamentally misunderstands the point @hwayne made in their original article, and moves the discussion even further from the original point of the Knuth/McIllroy matchup.

                    (mods, feel free to merge this submission to the above).

                    1. 1

                      In fact, one of the reasons I sometimes prefer using Perl over Python is that it’s very easy to incorporate into modular Unix tool pipelines. In contrast, Python encourages the creation of monoliths of the type McIlroy criticized.

                      This partly a problem of any interpreted language (even *sh)… we prematurely optimize and try avoid taking the hit of loading up and running the vast machinery of the interpreter… especially in an inner loop.

                      We tend to favour, (include or require) for modularization and reuse… forgetting that there are very strong advantages to processes and pipes as the mechanism.

                      Certainly my earlier ruby code shows strong signs of doing it “all in one big Ruby process”.

                      After watching a bash freak for awhile…. I have decided he does have one Good Point.

                      Decomposing programs into multiple smaller processes and connecting via pipes is A Good Thing and there is no real reason why we can’t do that in ruby / python/ …

                      1. 1

                        Ruby actually took this into account in the design, and the command line usage is very much inspired by perl. Ruby makes it very easy to write small composable “pieces” of software. When shell scripting I often write a helper ruby script to handle some kind of aspect to which shell is not well suited, like passing odd strings or dealing with complex data structures.

                        1. 1

                          Certainly from the earliest days there has been the code golfing / one liner approach.

                          But I’ll admit as I grow a program beyond a one liner, I had a Bad Habit (which I suspect is fairly common) of growing it into a Big All One Process ruby monolith.

                          I’m now actively trying to stop myself from doing that.