13 ms·

My favorite Knuth story, attributed to Alan Kay (if you're around, would love confirmation): When I was at Stanford with the AI project [in the late 1960s] one

My favorite Knuth story, attributed to Alan Kay (if you're around, would love confirmation): When I was at Stanford with the AI project [in the late 1960s] one of the things we used to do every Thanksgiving is have a computer programming contest with people on research projects in the Bay area. The prize I think was a turkey. [John] McCarthy used to make up the problems. The one year that Knuth entered this, he won both the fastest time getting the program running and he also won the fastest execution of the algorithm. He did it on the worst system with remote batch called the Wilbur system. And he basically beat the shit out of everyone. And they asked him, "How could you possibly do this?" And he answered, "When I learned to program, you were lucky if you got five minutes with the machine a day. If you wanted to get the program going, it just had to be written right. So people just learned to program like it was carving stone. You sort of have to sidle up to it. That's how I learned to program." [0] http://www.softpanorama.org/People/Knuth/index.shtml http://www.softpanorama.org/People/Knuth/index.shtml

mschaef 8y ago
There's another interesting story about Knuth that's worth repeating here. http://www.leancrew.com/all-this/2011/12/more-shell-less-egg/ http://www.leancrew.com/all-this/2011/12/more-shell-less-egg... The tl;dr is that Knuth wrote an elaborate implementation of a program to solve a particular problem, and Doug McIlroy replaced it entirely with a six step shell pipeline. (Knuth's program was written using his literate programming tools, could be typeset in TeX, and involved some precise work with data structures and algorithms.) I love this story as an example both of Knuth's genius and perspective, but also as a way to show what his level of dedication can achieve. It's an amazing intellectual accomplishment. I also love this story as a demonstration what those of us without that skill and dedication can achieve using the advancements built on the work of Knuth and others.
- sobellian 8y ago
  I love that story, although I think the takeaway needs to be slightly updated. It's quite possible that a sorted word count was easiest to do with bash and unix utilities in 1992. Now, it's easier and more comprehensible in your favorite scripting language (which I'm assuming isn't bash). The real lesson is to program using the most powerful tools at your disposal.
  - gmfawcett 8y ago
    That's a good lesson, but we shouldn't stop there. Knuth is a computer scientist, but also an artist: writer, musician, typographer, and creative programmer. His insights into programming-as-literature have infused an often-soulless industry with something soulful. He began with the popular notion that programming should be a creative, playful act, and tried to elevate mere playfulness into the realm of fine art. An incredible detour in an amazing career, and an enriching lesson of a different kind.
    - billfruit 8y ago
      And a theologian, he has has written works on divinity, etc..
  - mschaef 8y ago
    > It's quite possible that a sorted word count was easiest to do with bash and unix utilities in 1992. Now, it's easier and more comprehensible in your favorite scripting language It'd be interesting to see how true this is in reality. I'm not at all convinced that most scripting languages can do this quite as concisely as bash and the Unix userland. (But, being honest, this problem seems very well aligned to that tooling's strenghts.)
    - sobellian 8y ago
      Well, what is easy or comprehensible isn't necessarily concise. Bash is great for code golf but I know few people who prefer to code in it.
      - sobellian 8y ago
        And for completeness, a Ruby implementation: puts STDIN.read .split(/[^A-Za-z]+/) .group_by(&:downcase).transform_values(&:size) .sort_by(&:last).reverse .take(ARGV[0].to_i) .map{ |l| l.join("\t") }.join("\n") Wordier than the bash script, but still pretty short and fairly trivial. Anyone could make this in five minutes.
    - 8y ago
- gmfawcett 8y ago
  To his great credit, Knuth included McIlroy's critique, in full and without response, when he published Literate Programming. Knuth also conceded in an earlier chapter that literate programming was probably a crazy idea and that promoting it was perhaps an act of madness! It's delightful that we live in a world where there's room both for industrial-strength Fabergé eggs and hack-it-together pipelines. :)
- vram22 8y ago
  That's a good one. It's one of the classic examples of the Unix philosophy and how pipelines can be powerful, although of course not applicable in all cases, and they have their issues too - which often becomes an argument on HN (about text streams vs. object pipes a la PowerShell, etc.). I had seen it a while ago and blogged about it here, with solutions (approx.) in Python and shell: The Bentley-Knuth problem and solutions: https://jugad2.blogspot.com/2012/07/the-bentley-knuth-problem-and-solutions.html https://jugad2.blogspot.com/2012/07/the-bentley-knuth-proble... Also, previous HN thread about it here: Revisiting Knuth and McIlroy's word count programs (2011) (franklinchen.com) https://news.ycombinator.com/item?id=15264997 https://news.ycombinator.com/item?id=15264997
  - henrik_w 8y ago
    There is also the book "Exercises in Programming Style" that uses the term frequency problem to illustrate 33 different programming paradigms (including a shell solution). https://www.amazon.com/Exercises-Programming-Style-Cristina-Videira/dp/1482227371/ https://www.amazon.com/Exercises-Programming-Style-Cristina-...
    - vram22 8y ago
      Cool. Will check that out.
- svat 8y ago
  That was quite unfair criticism, and even Doug McIlroy knew it (as he admitted later). The background is this: - Bentley, the author of the column, invited Knuth to demonstrate literate programming using a program of his choice. - Knuth insisted that to be fair, Bentley ought to specify the program to be written; else someone might object that Knuth chose a program that would be good for literate programming. - Bentley chose (what we'd now call) the term frequency problem (list the top k most frequent words in a text file), and accordingly Knuth wrote a system program for solving just this one particular task. (Did everything from opening the input file to formatting the output, etc.) - Doug McIlroy was asked to “review” this program, the way works of literature are reviewed. He happens to be the inventor of Unix pipes. Towards the end of his review, along with many other points (e.g. Knuth didn't include diagrams in cases where most of us would appreciate them, something I still struggle with when reading TeX and other programs), he used the opportunity to demonstrate his own invention, a shell pipeline using now-standard Unix tools (tr, sort, uniq, sed). There are a few things wrong with this criticism: - The main thing is that DEK wrote the program he was asked to write, so pointing out that he shouldn't have written that program is a criticism of the one who chose the program (Bentley mentioned this when printing McIlroy's review). - At the time, Unix wasn't even widely available outside Bell Labs and a few places; it definitely wasn't available to Knuth or most of the column's readers. - Knuth's program, fine-tuned for the task, is more efficient than the shell pipeline. - Even if you use a shell pipeline, someone has to write the “standard” programs that go into it (the "tr", "sort", "uniq" and "sed" above), and literate programming can be used there. In fact, Knuth did exactly that a few years later, rewriting Unix's “wc” (IIRC) and compared the resulting program with that of Sun Unix's wc, and his LP version had, among things, better error handling. (He's explained it by saying that in conventional programming, if you have a small function and 90% of it is error-checking, it looks like the function is “about” error-checking, so there's a psychological resistance to doing too much of that, while with LP you move the error-handling to a separate section entirely about error-checking and then you tend to do a better job. BTW, TeX's error handling is phenomenally good IMO; the opposite of the situation with LaTeX.) All that said, there is some valid criticism that Knuth prefers to write monolithic programs, but that works for him. He seems not to consider it a problem that to change something you have to understand more-or-less the entire program; he seems to prefer doing that anyway (he reads other people's code a lot: in Peter Seibel's Coders at Work, he was the only person interviewed who read others' programs regularly).
- mci 8y ago
  > He has fashioned a sort of industrial-strength Fabergé egg—intricate, wonderfully worked, refined beyond all ordinary desires, a museum piece from the start. Curiously, I independently came up with this metaphor in my review of The MMIX Supplement to The Art of Computer Programming [1]: "You can marvel at its intricacies like one marvels at a Fabergé egg." [1] https://www.amazon.com/gp/customer-reviews/R25NHN9UP7PLJI/ https://www.amazon.com/gp/customer-reviews/R25NHN9UP7PLJI/
- ineedasername 8y ago
  McIlroy's critique is both astute on it's own yet perhaps not relevant in the context of what Knuth had been asked to do, namely present an example of literate programming. That's not to say the McIlroy's script can't have a literate form, only that it wouldn't serve as a good exemplar. It all serves as a good reminder of how Knuth's work should be used & viewed: It shouldn't be taken as insight into how to manage and develop for software projects. It's more useful as teaching tools for how to think about solving problems. In my mind it's the difference between "pure" science and practical engineering, though I'm not sure that's a perfect analogy. To try another analogy, it's like Knuth was asked to make a custom set of clothes. And McIlroy's critique seems like saying "Not everyone can afford custom made clothes, and the GAP produces perfectly serviceable clothes that are far more practical in most situations" It's correct, sure, but rather besides the point in the context of the original request.
  - mschaef 8y ago
    > perhaps not relevant in the context of what Knuth had been asked to do, namely present an example of literate programming. Agreed... if that was the goal, then McIlroy's example was terrible (in that it didn't use literate programming at all).
- jeklj 8y ago
  Yes, I love this story too. It really demonstrates so much. And oh, the hackles it raises. :)
  - mschaef 8y ago
    > And oh, the hackles it raises. :) The main reason I like the story is that it's good fodder for discussion about priorities in software development. After all, counting words isn't exactly an interesting problem in 2018, but deciding the effective use of libraries and programmer time is still very interesting.
seanmceligot 8y ago
I once had to write a program for a class didn't have access to a compiler. I wrote it all in notepad and double checked everything more thoroughly than I ever would have done otherwise. When I got the computer lab the compiler found one or two type-o's and the program ran perfectly the first time. The experience changed how I write code. It's worth trying out at least one time.
- DanHulton 8y ago
  I used to sit in my grade 12 English class working out polygon fill-and-shade routines on graph paper instead of whatever nonsense Shakespeare we were going through at the time. Worked out really well for me - I'm employed well as a programmer, and I got to come to Shakespeare basically fresh when I was old enough to actually appreciate the work.
  - ams6110 8y ago
    How old is that? I'm over 50 and I still can't get into Shakespeare. Watching a performance is OK, though not something I'd choose to do on my own, but reading the plays? Can't get into it at all.
    - munificent 8y ago
      Have you tried an annotated one? Shakespeare is full of, essentially, in-jokes and memes from the 1500s. There is a ton of depth in his writing that you'll totally miss if you don't know all of that context.
      - crooked-v 8y ago
        Also, lots of bawdy humor that gets glossed over by staid and respectable modern productions. For example: the "bite your thumb" gesture that gets used in a few plays is pretty much the equivalent of somebody from today giving a double middle finger while sticking their tongue out.
    - deleted 8y ago
      [deleted]
JackFr 8y ago
> He did it on the worst system with remote batch called the Wilbur system. I think you mean WYLBUR. I had the "opportunity" to work with WYLBUR once in 1993, and I remember it to this day. "the worst system with remote batch" dramatically understates how bad it was. Hearing this raises Knuth even higher in my estimation. https://en.wikipedia.org/wiki/ORVYL_and_WYLBUR https://en.wikipedia.org/wiki/ORVYL_and_WYLBUR
- jhayward 8y ago
  > He did it on the worst system with remote batch called the Wilbur system. How funny, because Wylbur was a large improvement on the default at the time, MVS's TSO (Time-Sharing Option). Wylbur was miles easier and faster than TSO. So, not actually 'the worst system with remote batch' because that trophy would go to TSO.
todd8 8y ago
I’ve posted this comment on HN before, but this is my best Knuth story: In the 70's I had a co-worker, perhaps the best programmer in the department, that had gone to school with Knuth. He told me that one day while in college Knuth was using one of the available key-punch machines to punch his program on cards. My friend was ready to punch his program so he stood nearby to wait for Knuth to finish. Knuth, working on a big program, offered to Keypunch my friends program before finishing his own because my friend's program was shorter and Knuth could keypunch quite fast. While watching over Knuth's shoulder, my friend noticed Knuth speeding up and slowing down at irregular intervals. Later he asked him about that and Knuth replied that he was fixing the bugs in my friend's Fortran as he punched it out.
svat 8y ago
Probably my favourite is along similar lines: read “The Summer Of 1960 (Time Spent with don knuth)” for a great story of Knuth as “this tall college kid” (consider the fact that Knuth first encountered a computer at college), from “Stories about the B5000 And People Who Were There”: http://ed-thelen.org/comp-hist/B5000-AlgolRWaychoff.html#7 http://ed-thelen.org/comp-hist/B5000-AlgolRWaychoff.html#7 (PDF scan: https://www.computerhistory.org/collections/catalog/102724640 https://www.computerhistory.org/collections/catalog/10272464... page 7) And about the story you shared, Knuth has elaborated in an interview (with typical humility, he plays it down): http://www.informit.com/articles/article.aspx?p=1193856 http://www.informit.com/articles/article.aspx?p=1193856
ams6110 8y ago
Most people who learned to program on batch-oriented systems developed those habits. When you had to wait hours or even overnight for your compile to run, you spent a lot of time at your desk checking the code for syntax errors, and running the logic in your head.
- deleted 8y ago
  [deleted]
throwaway427 8y ago
Knuth with the original "git gud".
stenecdote 8y ago
Knuth has said that the story as told above is apocryphal. I quote from here (http://www.informit.com/articles/article.aspx?p=1193856 http://www.informit.com/articles/article.aspx?p=1193856): > Donald: The story you heard is typical of legends that are based on only a small kernel of truth. Here’s what actually happened: John McCarthy decided in 1971 to have a Memorial Day Programming Race. All of the contestants except me worked at his AI Lab up in the hills above Stanford, using the WAITS time-sharing system; I was down on the main campus, where the only computer available to me was a mainframe for which I had to punch cards and submit them for processing in batch mode. I used Wirth’s ALGOL W system (the predecessor of Pascal). My program didn’t work the first time, but fortunately I could use Ed Satterthwaite’s excellent offline debugging system for ALGOL W, so I needed only two runs. Meanwhile, the folks using WAITS couldn’t get enough machine cycles because their machine was so overloaded. (I think that the second-place finisher, using that "modern" approach, came in about an hour after I had submitted the winning entry with old-fangled methods.) It wasn’t a fair contest. > As to your real question, the idea of immediate compilation and "unit tests" appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about. Nothing needs to be "mocked up."

mschaef 8y ago

There's another interesting story about Knuth that's worth repeating here. http://www.leancrew.com/all-this/2011/12/more-shell-less-egg/ http://www.leancrew.com/all-this/2011/12/more-shell-less-egg... The tl;dr is that Knuth wrote an elaborate implementation of a program to solve a particular problem, and Doug McIlroy replaced it entirely with a six step shell pipeline. (Knuth's program was written using his literate programming tools, could be typeset in TeX, and involved some precise work with data structures and algorithms.) I love this story as an example both of Knuth's genius and perspective, but also as a way to show what his level of dedication can achieve. It's an amazing intellectual accomplishment. I also love this story as a demonstration what those of us without that skill and dedication can achieve using the advancements built on the work of Knuth and others.

sobellian 8y ago
I love that story, although I think the takeaway needs to be slightly updated. It's quite possible that a sorted word count was easiest to do with bash and unix utilities in 1992. Now, it's easier and more comprehensible in your favorite scripting language (which I'm assuming isn't bash). The real lesson is to program using the most powerful tools at your disposal.
- gmfawcett 8y ago
  That's a good lesson, but we shouldn't stop there. Knuth is a computer scientist, but also an artist: writer, musician, typographer, and creative programmer. His insights into programming-as-literature have infused an often-soulless industry with something soulful. He began with the popular notion that programming should be a creative, playful act, and tried to elevate mere playfulness into the realm of fine art. An incredible detour in an amazing career, and an enriching lesson of a different kind.
  - billfruit 8y ago
    And a theologian, he has has written works on divinity, etc..
- mschaef 8y ago
  > It's quite possible that a sorted word count was easiest to do with bash and unix utilities in 1992. Now, it's easier and more comprehensible in your favorite scripting language It'd be interesting to see how true this is in reality. I'm not at all convinced that most scripting languages can do this quite as concisely as bash and the Unix userland. (But, being honest, this problem seems very well aligned to that tooling's strenghts.)
  - sobellian 8y ago
    Well, what is easy or comprehensible isn't necessarily concise. Bash is great for code golf but I know few people who prefer to code in it.
    - sobellian 8y ago
      And for completeness, a Ruby implementation: puts STDIN.read .split(/[^A-Za-z]+/) .group_by(&:downcase).transform_values(&:size) .sort_by(&:last).reverse .take(ARGV[0].to_i) .map{ |l| l.join("\t") }.join("\n") Wordier than the bash script, but still pretty short and fairly trivial. Anyone could make this in five minutes.
  - 8y ago
gmfawcett 8y ago
To his great credit, Knuth included McIlroy's critique, in full and without response, when he published Literate Programming. Knuth also conceded in an earlier chapter that literate programming was probably a crazy idea and that promoting it was perhaps an act of madness! It's delightful that we live in a world where there's room both for industrial-strength Fabergé eggs and hack-it-together pipelines. :)
vram22 8y ago
That's a good one. It's one of the classic examples of the Unix philosophy and how pipelines can be powerful, although of course not applicable in all cases, and they have their issues too - which often becomes an argument on HN (about text streams vs. object pipes a la PowerShell, etc.). I had seen it a while ago and blogged about it here, with solutions (approx.) in Python and shell: The Bentley-Knuth problem and solutions: https://jugad2.blogspot.com/2012/07/the-bentley-knuth-problem-and-solutions.html https://jugad2.blogspot.com/2012/07/the-bentley-knuth-proble... Also, previous HN thread about it here: Revisiting Knuth and McIlroy's word count programs (2011) (franklinchen.com) https://news.ycombinator.com/item?id=15264997 https://news.ycombinator.com/item?id=15264997
- henrik_w 8y ago
  There is also the book "Exercises in Programming Style" that uses the term frequency problem to illustrate 33 different programming paradigms (including a shell solution). https://www.amazon.com/Exercises-Programming-Style-Cristina-Videira/dp/1482227371/ https://www.amazon.com/Exercises-Programming-Style-Cristina-...
  - vram22 8y ago
    Cool. Will check that out.
svat 8y ago
That was quite unfair criticism, and even Doug McIlroy knew it (as he admitted later). The background is this: - Bentley, the author of the column, invited Knuth to demonstrate literate programming using a program of his choice. - Knuth insisted that to be fair, Bentley ought to specify the program to be written; else someone might object that Knuth chose a program that would be good for literate programming. - Bentley chose (what we'd now call) the term frequency problem (list the top k most frequent words in a text file), and accordingly Knuth wrote a system program for solving just this one particular task. (Did everything from opening the input file to formatting the output, etc.) - Doug McIlroy was asked to “review” this program, the way works of literature are reviewed. He happens to be the inventor of Unix pipes. Towards the end of his review, along with many other points (e.g. Knuth didn't include diagrams in cases where most of us would appreciate them, something I still struggle with when reading TeX and other programs), he used the opportunity to demonstrate his own invention, a shell pipeline using now-standard Unix tools (tr, sort, uniq, sed). There are a few things wrong with this criticism: - The main thing is that DEK wrote the program he was asked to write, so pointing out that he shouldn't have written that program is a criticism of the one who chose the program (Bentley mentioned this when printing McIlroy's review). - At the time, Unix wasn't even widely available outside Bell Labs and a few places; it definitely wasn't available to Knuth or most of the column's readers. - Knuth's program, fine-tuned for the task, is more efficient than the shell pipeline. - Even if you use a shell pipeline, someone has to write the “standard” programs that go into it (the "tr", "sort", "uniq" and "sed" above), and literate programming can be used there. In fact, Knuth did exactly that a few years later, rewriting Unix's “wc” (IIRC) and compared the resulting program with that of Sun Unix's wc, and his LP version had, among things, better error handling. (He's explained it by saying that in conventional programming, if you have a small function and 90% of it is error-checking, it looks like the function is “about” error-checking, so there's a psychological resistance to doing too much of that, while with LP you move the error-handling to a separate section entirely about error-checking and then you tend to do a better job. BTW, TeX's error handling is phenomenally good IMO; the opposite of the situation with LaTeX.) All that said, there is some valid criticism that Knuth prefers to write monolithic programs, but that works for him. He seems not to consider it a problem that to change something you have to understand more-or-less the entire program; he seems to prefer doing that anyway (he reads other people's code a lot: in Peter Seibel's Coders at Work, he was the only person interviewed who read others' programs regularly).
mci 8y ago
> He has fashioned a sort of industrial-strength Fabergé egg—intricate, wonderfully worked, refined beyond all ordinary desires, a museum piece from the start. Curiously, I independently came up with this metaphor in my review of The MMIX Supplement to The Art of Computer Programming [1]: "You can marvel at its intricacies like one marvels at a Fabergé egg." [1] https://www.amazon.com/gp/customer-reviews/R25NHN9UP7PLJI/ https://www.amazon.com/gp/customer-reviews/R25NHN9UP7PLJI/
ineedasername 8y ago
McIlroy's critique is both astute on it's own yet perhaps not relevant in the context of what Knuth had been asked to do, namely present an example of literate programming. That's not to say the McIlroy's script can't have a literate form, only that it wouldn't serve as a good exemplar. It all serves as a good reminder of how Knuth's work should be used & viewed: It shouldn't be taken as insight into how to manage and develop for software projects. It's more useful as teaching tools for how to think about solving problems. In my mind it's the difference between "pure" science and practical engineering, though I'm not sure that's a perfect analogy. To try another analogy, it's like Knuth was asked to make a custom set of clothes. And McIlroy's critique seems like saying "Not everyone can afford custom made clothes, and the GAP produces perfectly serviceable clothes that are far more practical in most situations" It's correct, sure, but rather besides the point in the context of the original request.
- mschaef 8y ago
  > perhaps not relevant in the context of what Knuth had been asked to do, namely present an example of literate programming. Agreed... if that was the goal, then McIlroy's example was terrible (in that it didn't use literate programming at all).
jeklj 8y ago
Yes, I love this story too. It really demonstrates so much. And oh, the hackles it raises. :)
- mschaef 8y ago
  > And oh, the hackles it raises. :) The main reason I like the story is that it's good fodder for discussion about priorities in software development. After all, counting words isn't exactly an interesting problem in 2018, but deciding the effective use of libraries and programmer time is still very interesting.

seanmceligot 8y ago

I once had to write a program for a class didn't have access to a compiler. I wrote it all in notepad and double checked everything more thoroughly than I ever would have done otherwise. When I got the computer lab the compiler found one or two type-o's and the program ran perfectly the first time. The experience changed how I write code. It's worth trying out at least one time.

DanHulton 8y ago
I used to sit in my grade 12 English class working out polygon fill-and-shade routines on graph paper instead of whatever nonsense Shakespeare we were going through at the time. Worked out really well for me - I'm employed well as a programmer, and I got to come to Shakespeare basically fresh when I was old enough to actually appreciate the work.
- ams6110 8y ago
  How old is that? I'm over 50 and I still can't get into Shakespeare. Watching a performance is OK, though not something I'd choose to do on my own, but reading the plays? Can't get into it at all.
  - munificent 8y ago
    Have you tried an annotated one? Shakespeare is full of, essentially, in-jokes and memes from the 1500s. There is a ton of depth in his writing that you'll totally miss if you don't know all of that context.
    - crooked-v 8y ago
      Also, lots of bawdy humor that gets glossed over by staid and respectable modern productions. For example: the "bite your thumb" gesture that gets used in a few plays is pretty much the equivalent of somebody from today giving a double middle finger while sticking their tongue out.
  - deleted 8y ago
    [deleted]

JackFr 8y ago

> He did it on the worst system with remote batch called the Wilbur system. I think you mean WYLBUR. I had the "opportunity" to work with WYLBUR once in 1993, and I remember it to this day. "the worst system with remote batch" dramatically understates how bad it was. Hearing this raises Knuth even higher in my estimation. https://en.wikipedia.org/wiki/ORVYL_and_WYLBUR https://en.wikipedia.org/wiki/ORVYL_and_WYLBUR

jhayward 8y ago
> He did it on the worst system with remote batch called the Wilbur system. How funny, because Wylbur was a large improvement on the default at the time, MVS's TSO (Time-Sharing Option). Wylbur was miles easier and faster than TSO. So, not actually 'the worst system with remote batch' because that trophy would go to TSO.

todd8 8y ago

I’ve posted this comment on HN before, but this is my best Knuth story: In the 70's I had a co-worker, perhaps the best programmer in the department, that had gone to school with Knuth. He told me that one day while in college Knuth was using one of the available key-punch machines to punch his program on cards. My friend was ready to punch his program so he stood nearby to wait for Knuth to finish. Knuth, working on a big program, offered to Keypunch my friends program before finishing his own because my friend's program was shorter and Knuth could keypunch quite fast. While watching over Knuth's shoulder, my friend noticed Knuth speeding up and slowing down at irregular intervals. Later he asked him about that and Knuth replied that he was fixing the bugs in my friend's Fortran as he punched it out.

svat 8y ago

Probably my favourite is along similar lines: read “The Summer Of 1960 (Time Spent with don knuth)” for a great story of Knuth as “this tall college kid” (consider the fact that Knuth first encountered a computer at college), from “Stories about the B5000 And People Who Were There”: http://ed-thelen.org/comp-hist/B5000-AlgolRWaychoff.html#7 http://ed-thelen.org/comp-hist/B5000-AlgolRWaychoff.html#7 (PDF scan: https://www.computerhistory.org/collections/catalog/102724640 https://www.computerhistory.org/collections/catalog/10272464... page 7) And about the story you shared, Knuth has elaborated in an interview (with typical humility, he plays it down): http://www.informit.com/articles/article.aspx?p=1193856 http://www.informit.com/articles/article.aspx?p=1193856

ams6110 8y ago

Most people who learned to program on batch-oriented systems developed those habits. When you had to wait hours or even overnight for your compile to run, you spent a lot of time at your desk checking the code for syntax errors, and running the logic in your head.

deleted 8y ago
[deleted]

throwaway427 8y ago

Knuth with the original "git gud".

stenecdote 8y ago

Knuth has said that the story as told above is apocryphal. I quote from here (http://www.informit.com/articles/article.aspx?p=1193856 http://www.informit.com/articles/article.aspx?p=1193856): > Donald: The story you heard is typical of legends that are based on only a small kernel of truth. Here’s what actually happened: John McCarthy decided in 1971 to have a Memorial Day Programming Race. All of the contestants except me worked at his AI Lab up in the hills above Stanford, using the WAITS time-sharing system; I was down on the main campus, where the only computer available to me was a mainframe for which I had to punch cards and submit them for processing in batch mode. I used Wirth’s ALGOL W system (the predecessor of Pascal). My program didn’t work the first time, but fortunately I could use Ed Satterthwaite’s excellent offline debugging system for ALGOL W, so I needed only two runs. Meanwhile, the folks using WAITS couldn’t get enough machine cycles because their machine was so overloaded. (I think that the second-place finisher, using that "modern" approach, came in about an hour after I had submitted the winning entry with old-fangled methods.) It wasn’t a fair contest. > As to your real question, the idea of immediate compilation and "unit tests" appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about. Nothing needs to be "mocked up."