> Incidentally, this problem set the scene for a wizard duel between two computer scientists several decades ago. In 1986, Jon Bentley asked Donald Knuth to show off “literate programming” with a solution to this problem, and he came up with an exquisite, ten-page Knuthian masterpiece. Then Doug McIlroy (the inventor of Unix pipelines) replied with a one-liner Unix shell version using tr, sort, and uniq.
Since this writing and other linked resources present only one side of the affair, I will mention: the presentation in Pearls was quite unfair to Knuth, and the conclusions commonly made of it somewhere between moderately and entirely unsound. (That is, as conclusions from the paper. I speak of unsoundness of logic only: these conclusions may be supportable from other sources.)
Knuth was challenged to demonstrate literate programming, and so that was what he demonstrated. He showed building something from the ground up assuming a very minimal environment, with problem analysis and all: of course that ended up more verbose than a Unix pipeline that glosses over problem analysis and starts with most of the tools you need to make a probably-acceptable solution!
McIlroy himself admitted a few years later that he had been “a little unfair” to criticise on engineering grounds what had only been an illustration of technique. Even in the paper, Bentley did admit a degree of culpability for this mismatch in his “criticism of programs” paragraph. (“He admires the execution of the solution, but faults the problem on engineering grounds. (That is, of course, my responsibility as problem assigner; Knuth solved the problem he was given on grounds that are important to most engineers-the paychecks provided by their problem assigners.)”)
But I do wish that Knuth had been given the opportunity to write a review of McIlroy’s review, for simultaneous publication.
1986 was very early days for modern operating systems. I suspect that the hardware environment(low resource) would be surprising to many phone owners here. So the efficacy had to do with the tools low-level bindings, too
Indeed. In 1986, Knuth was exclusively using the SAIL DEC10, running the WAITS OS. This environment limited him to approximately half a megabyte of data space (heap plus stack plus globals), and half a megabyte of code space. All statically linked, so all library and runtime stuff had to fit.
Also of note is that most CPUs of the day didn't execute instructions orders of magnitude faster than bandwidth to main memory, as is the case today; it was early days for worrying about making algorithms "cache aware". So, for instance, there was no big penalty for "pointer chasing" in linked lists as there is today. Additionally, the severe memory size limits affected various time vs. space tradeoffs in algorithm design.
WEB is not a totally different programming language, it is a way to write programs. It is a hybrid (in the form presented in that article, though later versions were centered on other languages or language agnostic) of TeX and Pascal. The code that was written was proper Pascal, the documentation was proper TeX, and there was extra syntax for WEB use in naming and referencing code definitions. The WEB system had two additional components (and these terms are still used in many WEB-derived systems): WEAVE, TANGLE.
WEAVE takes a WEB source file and generates proper TeX out of it. TANGLE takes a WEB source file and generates proper Pascal.
The code written in WEB (and variants) is not necessarily in proper order for compilation, and can contain references to other blogs which are included as text-inclusions. I've never used WEB proper, but in org-mode there is org-babel. Its syntax is something like this (from memory, I use shortcuts so I don't have to memorize all the details and type them out):
To handle user input, the program will read from a file.
#+NAME: open-file (a better name would be used in a real program)
#+BEGIN_SRC lisp :noweb yes
(with-open-file (f filepath)
<<parsing>>)
#+END_SRC
elsewhere
The actual parsing will look like:
#+NAME: parsing
#+BEGIN_SRC lisp :noweb yes
...
#+END_SRC
And the order of these can be reversed, the correct output will be produced with a few other settings and options. With org-babel, when you tangle the org file it will generate one or more source files based on the options and settings you've used throughout the org file itself. Instead of WEAVE, you would just use the standard org export settings.
Since this writing and other linked resources present only one side of the affair, I will mention: the presentation in Pearls was quite unfair to Knuth, and the conclusions commonly made of it somewhere between moderately and entirely unsound. (That is, as conclusions from the paper. I speak of unsoundness of logic only: these conclusions may be supportable from other sources.)
Knuth was challenged to demonstrate literate programming, and so that was what he demonstrated. He showed building something from the ground up assuming a very minimal environment, with problem analysis and all: of course that ended up more verbose than a Unix pipeline that glosses over problem analysis and starts with most of the tools you need to make a probably-acceptable solution!
McIlroy himself admitted a few years later that he had been “a little unfair” to criticise on engineering grounds what had only been an illustration of technique. Even in the paper, Bentley did admit a degree of culpability for this mismatch in his “criticism of programs” paragraph. (“He admires the execution of the solution, but faults the problem on engineering grounds. (That is, of course, my responsibility as problem assigner; Knuth solved the problem he was given on grounds that are important to most engineers-the paychecks provided by their problem assigners.)”)
But I do wish that Knuth had been given the opportunity to write a review of McIlroy’s review, for simultaneous publication.