[HN Gopher] Donald Knuth was framed
___________________________________________________________________
Donald Knuth was framed
Author : akalin
Score : 271 points
Date : 2020-02-24 17:23 UTC (5 hours ago)
(HTM) web link (buttondown.email)
(TXT) w3m dump (buttondown.email)
| ben509 wrote:
| These days, though, you can have it both ways with a Jupyter
| notebook or something similar. It's literate, in that you can
| keep thoughts and discussion in markdown cells, and you can
| neatly combine computations in computation cells.
| kick wrote:
| Site's back up.
| aortega wrote:
| You cannot compare Knuth's software with a script that use pre
| compiled tools that have thousands of lines.
|
| If you want to compare both solutions, use the Kolmogorov
| complexity: compress both programs together with any
| tool/compiler it uses and just then, compare both sizes. I bet
| Knuth's solution has an order of magnitude less complexity.
| btilly wrote:
| There are many, many ways to tell this story. However it
| resonates because it fits well with an ongoing dynamic. Which is
| that programmers naturally want to build perfect tools while the
| business need tends to be for a quick and dirty solution that can
| be assembled out of prebuilt pieces.
|
| Except that this one is extreme. It is hard to find any
| programmer who builds a more perfect tool than Knuth. There isn't
| a better known problem where the discrepancy between the perfect
| and the good is this dramatic. Therefore this became the poster
| child for this ongoing type of conflict retold by those who see
| themselves as on the side of the quick and dirty solution built
| out of preassembled pieces. Who, of course, slant the story to
| further fit their prejudices.
|
| This kind of slanting is common. Take a famous WW II example
| where they were looking to improve bomber durability by putting
| more armor plate where the bombers were coming back hit. A wise
| statistician advised them that those were the spots that didn't
| need armor, they should put it on where the bombers were hit and
| _didn 't_ come back. Which, assuming that bombers were hit evenly
| everywhere, was all the places that they didn't find holes.
|
| The reasoning is perfect, and illustrates a key point of
| statistical wisdom. But the retelling of the story almost never
| admits that the advice didn't really make a difference. The
| actual solution to the rate at which bombers were being destroyed
| was to drop chaff - strips of aluminum cut to half the length of
| the German radar - so that the radar systems got overwhelmed and
| the Germans couldn't find the bombers.
| kwillets wrote:
| The ACM had a nice article debunking the Wald story:
| http://www.ams.org/publicoutreach/feature-column/fc-2016-06
| selimthegrim wrote:
| The postscript undebunks it.
| CrazyStat wrote:
| > To be precise, regarding Wald's work on aircraft damage we
| have (1) two short and rather vague mentions in Wallis'
| memoir of work on aircraft vulnerability and (2) the
| collection of the actual memoranda that Wald wrote on the
| subject. That's it! _Everything not in one of these places
| must be considered as fiction, not fact._
|
| (emphasis in the original)
|
| This is a rather extreme take. Ignoring the rather important
| fact that the author of the piece missed at least one
| important source where Wallis gives Wald credit (see the
| postscript), arguing that something must be "considered as
| fiction" because it is not attested to in the (known) written
| sources is unreasonable.
|
| I don't know at what point the postscript was added (it
| appears in the first archive.org snapshot of the page, from
| 2018; the essay was first published in 2016), but it seems
| misleading to leave the whole rant up there and then tack on
| a bit at the end saying "Oh I was wrong by the way."
| pdpi wrote:
| > Which is that programmers naturally want to build perfect
| tools while the business need tends to be for a quick and dirty
| solution that can be assembled out of prebuilt pieces.
|
| Nope, this is nothing of the sort. It's just a case of two
| people solving two different (if related) problems, and
| everybody else trying to draw (by necessity, completely
| worthless) conclusions by comparing solutions to different
| problems.
|
| McIlroy solved the K most common words problem. Knuth used a
| from-the-ground-up solution to that problem as a way to
| illustrate how Literate Programming works. His solution was
| never meant to be as tiny as McIlroy's, it needed enough meat
| on it that LP actually did something non-trivial.
| btilly wrote:
| You missed my point. I was not saying that this story is a
| good example of that ongoing dynamic. But instead that there
| is such a dynamic in our industry, and the telling of the
| story resonates well with it.
| [deleted]
| thrower123 wrote:
| Actually, the real solution was to build fighter escort planes
| that could match the bomber's range, like the P-51 Mustang, or
| to have bases in France or Italy that the other shorter range
| fighters could escort the bomber fleets out of. Once this
| happened, the Luftwaffe was quickly decimated and bomber
| casualties dwindled.
| btilly wrote:
| _Actually_ , the US and UK airforces took very different
| strategies. And different things worked for them.
|
| The US went during the day mostly aiming for precision
| bombing of targets. The UK went at night with mass bombing
| runs.
|
| The UK had horrible casualties until the introduction of
| chaff. After that they shut down the German air defense and
| took out Dresden. The USA had lighter casualties but didn't
| dare hit targets at the same range until they had better
| fighter escorts. Fighter escorts didn't work so well for the
| British because the German planes had better radar.
|
| And while we are at it, the European war was mostly won by
| American manufacturing and Russian soldiers. During the Cold
| War decades, we retold the story in ways that minimized the
| Soviet contribution. But more German soldiers died fighting
| on the Eastern front than were killed by all other countries
| in all other theaters of war _combined._
| derefr wrote:
| > the European war was mostly won by American manufacturing
| and Russian soldiers.
|
| That's one way to think about it. Another way to think
| about it is that WW2 was two separate _campaigns_ : one
| between all the powers you normally think about, and the
| other _just_ between Germany and Russia, an entirely-
| optional war that likely wouldn 't have begun if Germany
| hadn't decided to start it. It's not really that Russia was
| aiding the Western powers in a single fight; it's more that
| an independent, simultaneous Russo-German conflict starved
| Germany of the materiel it needed for its other campaign.
|
| See also: https://nationalinterest.org/feature/what-if-
| hitler-never-in...
| asdkjh345 wrote:
| >an entirely-optional war that likely wouldn't have begun
| if Germany hadn't decided to start it
|
| There is a great deal of consensus among historians that
| it was absolutely inevitable and unpreventable. A
| reasonable minority even support Suvorov's claims that
| the USSR was planning to start the conflict and Germany
| only beat them to it by a couple of weeks.
| vl wrote:
| If Germany didn't invade then the USSR would attack first
| (and WW2 would be over sooner, probably with larger part
| of Europe under Soviet control). Both powers had attack
| plans, Germans executed theirs sooner. Some historians
| claim that Germans got ahead if Soviet attack just by few
| weeks.
| jandrese wrote:
| There's also the point that Germany absolutely needed the
| oil fields to keep their war machine running.
|
| I'm skeptical on the USSR executing on a plan to attack
| Germany only two weeks later given how disorganized they
| were in the face of the German attack. The Russian army
| isn't something you can move across the country in a
| couple of weeks.
| bzbarsky wrote:
| The argument as I've seen it presented was that a large
| part of the army was already moved up close to the border
| and in attack positions, and not set up for defensive
| operations. Which is why, the argument goes, there were
| so many soldiers to surround and cut off.
|
| I'm not endorsing the argument, note; I haven't looked
| into this enough to have anything resembling a useful
| opinion.
| hdjejdjd wrote:
| And while we are at that, if the russians hadn't made a
| deal with the nazis to steal poland, there wouldn't have
| been a war to begin with and all those untold lives would
| be alive.
| vl wrote:
| If they wouldn't split Poland, then both of them would
| have tried to just capture it, and essentially the same
| end result would be achieved. Both powers were primed to
| go to war.
| hdjejdjd wrote:
| It's quite the gift to speak with someone who can see the
| result of historical hypotheticals.
| jmmcd wrote:
| Isn't that exactly what are doing in your previous
| comment?
| btilly wrote:
| If you want hypotheticals, here is what Winston Churchill
| had to say on the topic in a speech to the US Congress
| after the war was won.
|
| _President Roosevelt one day asked what this War should
| be called. My answer was, "The Unnecessary War." If the
| United Stated States had taken an active part in the
| League of Nations, and if the League of Nations had been
| prepared to use concerted force, even had it only been
| European force, to prevent the re-armament of Germany,
| there was no need for further serious bloodshed. If the
| Allies had resisted Hitler strongly in his early stages,
| even up to his seizure of the Rhineland in 1936, he would
| have been forced to recoil, and a chance would have been
| given to the sane elements in German life, which were
| very powerful especially in the High Command, to free
| Germany of the maniacal Government and system into the
| grip of which she was falling.Do not forget that twice
| the German people, by a majority, voted against Hitler,
| but the Allies and the League of Nations acted with such
| feebleness and lack of clairvoyance, that each of
| Hitler's encroachments became a triumph for him over all
| moderate and restraining forces until, finally, we
| resigned ourselves without further protest to the vast
| process of German re-armament and war preparation which
| ended in a renewed outbreak of destructive war. Let us
| profit at least by this terrible lesson. In vain did I
| attempt to teach it before the war._
|
| In his book _The Gathering Storm_ , he adds several more
| points where Hitler could have been easily stopped before
| he started.
| pmoriarty wrote:
| Here's another view, from the economist John Maynard
| Keynes (of Keynesian economics fame), regarding the
| devastating reparations that were imposed by the Allies
| on Germany after the end of WW1:
|
| _...Keynes began work on_ The Economic Consequences of
| the Peace _. It was published in December 1919 and was
| widely read. In the book, Keynes made a grim prophecy
| that would have particular relevance to the next
| generation of Europeans: "If we aim at the impoverishment
| of Central Europe, vengeance, I dare say, will not limp.
| Nothing can then delay for very long the forces of
| Reaction and the despairing convulsions of Revolution,
| before which the horrors of the later German war will
| fade into nothing, and which will destroy, whoever is
| victor, the civilisation and the progress of our
| generation."_
|
| _Germany soon fell hopelessly behind in its reparations
| payments, and in 1923 France and Belgium occupied the
| industrial Ruhr region as a means of forcing payment. In
| protest, workers and employers closed down the factories
| in the region. Catastrophic inflation ensued, and Germany
| 's fragile economy began quickly to collapse. By the time
| the crash came in November 1923, a lifetime of savings
| could not buy a loaf of bread. That month, the Nazi Party
| led by Adolf Hitler launched an abortive coup against
| Germany's government. The Nazis were crushed and Hitler
| was imprisoned, but many resentful Germans sympathized
| with the Nazis and their hatred of the Treaty of
| Versailles._
|
| _A decade later, Hitler would exploit this continuing
| bitterness among Germans to seize control of the German
| state. In the 1930s, the Treaty of Versailles was
| significantly revised and altered in Germany 's favor,
| but this belated amendment could not stop the rise of
| German militarism and the subsequent outbreak of World
| War II._
|
| https://www.history.com/this-day-in-history/keynes-
| predicts-...
| Zimahl wrote:
| Another example people use for the KISS principle is of the
| 'space pen', where the US spent thousands/millions developing a
| pen that works in space whereas the Soviets used a pencil.
| However, almost none of the story is true. Regardless, it gets
| repeated over and over.
| avip wrote:
| We'll be living in a pretty dull place if only true stories
| were allowed.
| Jon_Lowtek wrote:
| Bashir: "Of all the stories you told me, which ones were
| true and which ones weren't?"
|
| Garak: "My doctor, they're all true."
|
| Bashir: "Even the lies?"
|
| Garak: "Especially the lies."
| kyuudou wrote:
| Nah, "truth is often stranger than fiction"
| [deleted]
| bumby wrote:
| I have heard the real reason was to avoid electrical shorts.
| Pencils inevitably have bits of conductive graphite breaking
| off and floating about, potentially damaging electrical
| components
| hwayne wrote:
| Wikipedia has a great article on this:
| https://en.wikipedia.org/wiki/Writing_in_space
| bumby wrote:
| Interesting read! Although it isn't clear what the
| combustion source is based upon, on-orbit conditions are
| generally different from STP and combustion effects may
| not translate
| bumby wrote:
| > assuming that bombers were hit evenly everywhere
|
| I'm not sure a statistician would make that assumption. I've
| only heard this story told in the context of survivorship bias,
| not root cause analysis
|
| Edit: I don't mind the downvotes but please help contribute to
| the discussion by explaining what is disagreed with
| CrazyStat wrote:
| Given the imprecision of WWII-era anti-aircraft guns it's a
| reasonable assumption.
|
| You also _have_ to make some assumption about the initial
| distribution of the hits in order to do an analysis of
| survivorship bias.
| bumby wrote:
| I have no problem with making assumptions but it would
| hopefully be grounded in a domain specific understanding.
|
| If you read some of the replies, you'll see one of the
| fixes involved fighter escorts. This is probably based on
| an assumption that fighters contributed to the downing of
| aircraft. These would probably have a different shot
| distribution than anti aircraft artillery.
|
| Not to belabor the point, but jumping to conclusions on
| assumptions is exactly what good root cause analysis guards
| us against. A random distribution may be reasonable for an
| uninitiated statistician but I'm not sure one with some
| domain background in the problem would make the same
| assumptions.
| Sniffnoy wrote:
| Minor note, the statistician in question was Abraham Wald:
| https://en.wikipedia.org/wiki/Abraham_Wald
|
| Edit: Well, assuming it happened, as going by other comments
| here maybe it didn't!
| geofft wrote:
| Something related that's been on my mind recently: a lot of the
| advantage in building well-designed programs (documented,
| modular, built to be tested, free of smells, etc.) is less about
| getting the program right than about getting _future changes_
| right, either by someone else, or even yourself when you 've
| forgotten how to do it. But future changes only matter _if you
| want to use the existing program as a starting point_.
|
| McIlroy's pipeline is a little bit hard to read, but I would bet
| that most people with moderate experience in building shell
| pipelines could rebuild something equivalent from scratch, even
| if they'd have trouble explaining how the current pipeline works.
| (Or people with experience in Python, Perl, etc. could throw
| together an equivalent script from scratch quickly.)
|
| An implication is that, if you're in a language where you can
| write a productive program to do a task from scratch within (say)
| 30 minutes, there's a lot less of a reason to think about good
| programming design than if you're in a language where doing that
| same task from scratch is likely to take you a day. In the second
| language, most of the value of writing documented and well-
| structured code is so that it takes you 30 minutes when someone
| asks you to modify it. But in the first language, you can throw
| away your code when you're done with it and still solve the
| modified problem within 30 minutes.
|
| Another possible implication: it's better to build reusable
| components (libraries and utilities) than easily-modifiable code.
| Part of why McIlroy's pipeline works so well is that tools like
| "tr" and "uniq" exist - and most of us will never have reason to
| modify the source code of those tools. We need to know what their
| interfaces are, but we don't need to know their internals.
| jackweirdy wrote:
| This comment reminds me of something of a thought-experiment-
| come-hacky-side-project that I can't seem to find.
|
| The premise was, what if you could never edit a function?
| Instead, you had to delete it and recreate it entirely whenever
| changes were needed.
|
| The incentives are twofold - keep functions small, so you don't
| lose too much investment if you have to delete code, and think
| before you start writing, else you waste time.
|
| As I remember, this project came with an AST manipulator that
| would helpfully delete your function if it's unit tests failed.
| fasquoika wrote:
| https://github.com/munificent/vigil
| jeffdavis wrote:
| What you are describing may say more about the problem
| definition than the rate of change. If the software will only
| be used in certain limited situations, then you can make a
| bunch of assumptions and assemble the solution from spare
| parts. As long as your assumptions hold everything is fine.
| When the assumptions fail, someone will tell you, and you can
| rewrite it with the new assumptions in mind.
|
| But some software might be used in a lot of strange
| environments with strange inputs. A lot of effort needs to be
| spent trying to clarify and improve semantic and performance
| edge cases. Using libraries here is not necessarily helpful
| because sometimes you spend more time working around the edge
| cases in the library than you would just re-implementing it.
|
| I recently re-implemented a minheap even though there was
| already a library readily available, because the library
| assumed pointer-width types and I needed it to support longs.
| On my machine, a pointer and a long are the same length, but
| that's not guaranteed.
| geofft wrote:
| Regardless of environment, good software engineering (where
| by "software engineering" I mean "the process of producing
| code that continues to do useful things over time") requires
| a feedback loop from how the software is being used in
| production back to the developers.
|
| If your assumptions are failing, and you know about it, then
| you can deliver new code to match the new assumptions, either
| by rewriting it or by modifying it as makes sense.
|
| If your assumptions are failing and you _don 't_ know about
| it, you're in a terrible position. You can make further
| assumptions about which of your assumptions might fail (e.g.,
| "the software is being compiled on a machine where a long is
| longer than a pointer") and which won't, but those are again
| assumptions - you don't know what changes you haven't thought
| about might come down the pipe (e.g., "the software is being
| translated to JavaScript, which has no longs, only floating
| point" or even "there's now a requirement to use a stable
| sort, so a heap is out of the question"). It's not at all
| clear that building rigid, well-armored software and throwing
| over the wall can even work. If at all possible, effort is
| better spent closing the feedback loop.
| Myrmornis wrote:
| > The actual paper paints LP in a much better light than we
| thought it did....The actual content is effectively his stream-
| of-consciousness notes about what he's doing. He discusses why he
| makes the choices he does and what he's thinking about as primary
| concerns. It's easy to skim or deep-dive the code.
|
| Now imagine if these stream-of-consciousness comments getting in
| the way of the code were written by your colleagues, rather than
| Donald Knuth.
| Jtsummers wrote:
| Like all documentation, in real systems it would be edited over
| time. You do develop documentation for your systems, right?
| Myrmornis wrote:
| My point is that people should be encouraged to keep code
| comments to a minimum, and always strive to first rewrite the
| code so that it is clear (well-chosen variable names, etc).
| LP does the opposite: it encourages verbosity, and tangential
| discussion.
| Jtsummers wrote:
| My point is that literate programming isn't about
| _comments_. Comments are asides, they aren 't the core
| focus of what's being read, the code is. Literate
| programming is about _documentation_ , which should be kept
| _concise_ , but not necessarily _minimal_.
|
| As to whether this leads to tangents or not, that's up to
| the authors to determine how to organize. Appendices or
| rationale sections are a great way to separate the core
| focus from what others may see as extraneous.
| Myrmornis wrote:
| Yes, sorry, I did understand that that was your point. I
| just feel very strongly about the tendency, for people
| (especially new programmers) to be told that it's
| important to comment code heavily.
|
| Yes I've never seen a good solution for documentation in
| the teams I've worked in on larger systems/codebases. I'm
| not really a believer in documentation that evolves in a
| separate git repo (or god forbid, in Confluence) for the
| obvious reason that it gets even more stale than
| documentation that evolves in the same git repo. So that
| would put me in favour of your position here.
|
| But, how can documentation (with appendices or rationale
| sections) be interleaved with code without destroying the
| ability to read the code? I've tried RWeave in R a long
| time ago, and I've even collaborated and published on a
| literate programming tool, and I have always come back to
| the conclusion that I want to read code with the minimum
| of intervening prose.
|
| So my position is documentation should absolutely be
| written and maintained, it should be in the same git repo
| as the code, it should be in a separate file (not in
| comments or docstrings or automagically weaved sections
| using some special syntax), it should be written tersely
| and without much personality, and code reviewers should
| request documentation updates if a PR renders some
| documentation stale or requires new documentation.
|
| So I'm pro documentation, anti LP, and pro minimal code
| commenting.
| FabHK wrote:
| Does anyone have any insight in the computational complexity of
| the two solutions?
|
| The shell script sorts all the words (and then all the counts),
| so has complexity at least O(n log n) in the number of words.
|
| It seems to me an optimal solution could be faster, and I wonder
| what Knuth implemented.
| jesse_m wrote:
| I haven't heard of the leo editor. I have used org mode in Emacs
| for little things. I also came across a reimplmentation of the
| tangling functionality: https://github.com/thblt/org-babel-
| tangle.py
| adonese wrote:
| It seems to be down.
| mark-r wrote:
| For me too. It's a shame given the inflammatory title - I
| really want to know what it means.
| Ari_Rahikkala wrote:
| My guess is it's either about a picture of Donald Knuth, or
| Knuth's reward checks, being put in picture frames.
| ColinWright wrote:
| Neither.
| Ari_Rahikkala wrote:
| Aw. Well, it was worth a shot, that kind of mild homonym
| abuse is kind of direction that these sorts of titles
| usually tend to take. Fortunately the real story is more
| interesting.
| draw_down wrote:
| I've seen similar defenses of Knuth over the years, but I'm still
| inclined to view this McIlroy's way. I think focusing on the
| shell script is a canard, the point is he picked what seemed like
| the right tool for the job. Isn't that what commenters are saying
| here all the time?
|
| Anyway, perhaps I just suffer from a failure of imagination, but
| I can't see why the "Blah"s interspersed with `foo`s and `bar`s
| is meant to be revelatory.
| CrazyStat wrote:
| The job Knuth was asked to do was "write a piece illustrating
| literate programming." A six line shell script is not the right
| tool for that job.
| mhd wrote:
| I think it's meant to promote looking at how a literate
| programming system is mangling program output. It's way more
| complicated and powerful than just "inverted comments" (like
| e.g. CoffeeScript did in recent memory). Composite parts of the
| final program can be presented out of order, sent to different
| output files, etc.
|
| For something slightly more modern than this sample program or
| TeX, there's "A Retargetable C Compiler: Design and
| Implementation", which presentes the code of lcc, a quite
| conformant C compiler (which, IIRC, still enjoys some
| popularity on Windows).
|
| Sadly the strengths of literate programming are rarely useful
| for mere mortal programmers -- we're not often entrenched in
| deriving algorithms and/or presenting something in a didactic
| manner.
| gameswithgo wrote:
| The unix command solution is likely orders of mangnitude slower
| than what Knuth wrote, which given the computer power of the time
| should have seemed fairly relevant.
| giancarlostoro wrote:
| If anyone managed to catch it when it wasn't down, care to share
| a screenshot of the article? I seem to be getting some Heroku
| error now.
|
| > An error occurred in the application and your page could not be
| served. If you are the application owner, check your logs for
| details. You can do this from the Heroku CLI with the command
| aWidebrant wrote:
| Lightly edited: https://rentry.co/zq4r6
| ColinWright wrote:
| It seems to have the "HN Hug of Death" ... here's a snapshot
| summary from memory:
|
| Knuth and McIlroy gave examples of a word count program. Knuth
| used Literate Programming and did it in 8 pages, McIlroy used
| shell utilities and did it in 8 lines.
|
| This post goes back to the original paper and discovers that
| Knuth has been grossly misrepresented as to what he was trying to
| do, and what he achieved.
|
| _Edit_
|
| bonyt's[0] comment[1] has links to copies of the content.
|
| [0] https://news.ycombinator.com/user?id=bonyt
|
| [1] https://news.ycombinator.com/item?id=22406365
| kwillets wrote:
| Just about any 8-line shell script is a good argument for LP.
| hprotagonist wrote:
| so a rebuttal/companion to http://www.leancrew.com/all-
| this/2011/12/more-shell-less-egg...
| pdpi wrote:
| Pretty much, yes.
|
| The argument, in short, is that the problem Knuth is solving
| isn't "find K most common words", but rather "Use the K most
| common words problem as the basis to demonstrate how you use
| Literate Programming". Knuth actually tackles the latter,
| McIlroy's rebuttal is just the former, so doesn't actually
| serve as much of an argument about anything.
| lonelappde wrote:
| There's nothing surprising or underhanded here, and never
| was. It was just too complimentary perspectives.
|
| McIrloy's paper shows the value of good hackery over
| engineering.
|
| Knuth was set back by the blogger's dilemma of trying to
| show a technique that maybe useful in general but isn't
| very useful in a very short program.
| pdpi wrote:
| I didn't mean to imply there was anything underhanded
| about McIlroy's critique. Just that that, because
| McIlroy's code isn't trying to solve the same problem, it
| shouldn't be taken as a rebuttal to Knuth's point, which
| is what, apparently, many people believe it to be.
| projektfu wrote:
| There's lots of interesting facets here. Doug's solution
| requires a working Unix system. You might not have that
| in the problem space.
|
| On the other hand, his solution shows that by assuming
| some nice things about your data, things which Pascal
| does not allow, you can do some useful things with terse
| programming. This is reminiscent of the array programming
| model of APL or J. I haven't written a solution but I'd
| be surprised if it is more than about 15 characters.
|
| In the shell case, the terse program is like a Chinese
| classic. Written in its own jargon requiring basically a
| prior understanding of the program to read it.
| acqq wrote:
| > In the shell case, the terse program is like a Chinese
| classic. Written in its own jargon requiring basically a
| prior understanding of the program to read it.
|
| However, if Knuth wanted to be terse, he could have been
| and write a Pascal program which uses his library
| routines without showing them ! -- in effect using Unix
| solution by Doug is equivalent to "not only you must use
| already pre-written libraries in order to be terse, they
| are even not the plain routines but they are instead
| packed as the whole executables, and to use these
| executables you have to use them on exactly this
| operating system, exactly using this specific shell, all
| that property of AT&T (at that time Linux didn't exist,
| and who had rights to use what wasn't clear, unless
| you've bought something expensive) just to be able to
| call these library routines.
|
| So it can't be considered a serious "critique." At that
| time, under these circumstances, it was just an unfair
| ad.
| tzs wrote:
| From that:> I can't help wondering, though, why he didn't use
| head -${1} in the last line. It seems more natural than sed.
| Is it possible that head hadn't been written yet?
|
| It's possible that it wasn't written yet. It's also possible
| that it did exist but he saw no reason to start using it,
| since "sed Nq" continued to work fine. Heck, it's even one
| less character to type than "head -N"!
|
| BTW, apparently "head -N" is considered to be obsolete
| syntax. The man page for GNU head doesn't even mention it. It
| just gives this: -c, --bytes=[-]K
| print the first K bytes of each file;
| with the leading '-', print all but the last
| K bytes of each file -n, --lines=[-]K print the
| first K lines instead of the first 10;
| with the leading '-', print all but the last
| K lines of each file -q, --quiet, --silent never
| print headers giving file names -v, --verbose
| always print headers giving file names --help
| display this help and exit --version output
| version information and exit
|
| The "info" documentation for GNU head does mention the "-N"
| form, and says it is an obsolete syntax supported for
| compatibility, and says if you must run on hosts that don't
| support the "-n N" form it is simpler to avoid "head" and use
| "sed Nq" instead.
|
| On my Mac, with BSD head, the man page gives only this form:
| head [-n count | -c bytes] [file ...]
|
| Like GNU head, it accepts the -N form.
| lalalandland wrote:
| Unix shell scripting is an obtuse practice that is really hard to
| discover. That short shell script is built on hours of hard
| learned Unix experience that would probably be at least 8 pages
| long, if explained thorough.
| svat wrote:
| I'm glad to see this here, for two reasons: (1) In general it's
| nice when people return to the primary sources rather than
| second-hand accounts, and (2) this particular topic is of
| interest to me; here are a couple of previous comments that were
| somewhat well-received on HN:
|
| https://news.ycombinator.com/item?id=22221592
|
| https://news.ycombinator.com/item?id=18699718
|
| For further context you can look at past and future issues of
| Bentley's column (and its spinoff); a list of them I collected
| here: https://shreevatsa.net/post/programming-pearls/
|
| I guess it's a long-standing tradition in literary reviews for
| reviewers to push their own ideas, rather than confining
| themselves solely to reviewing the work in question. That is what
| happened here. Knuth had written a program that he had been asked
| to write, to demonstrate the programming discipline. But McIlroy,
| as the inventor of Unix pipes and a representative of the Unix
| philosophy (at that time not well-known outside the few Unix
| strongholds: Bell Labs, Berkeley, etc), decided to point out (in
| addition to a good review of the program itself) the Unix idea
| that such special-purpose programs shouldn't be written in the
| first place; instead one must first accumulate a bunch of useful
| programs (such as those provided by Unix), with ways of composing
| them (such as Unix pipes). A while later, John Gilbert described
| this episode this way:
|
| > _Architecture may be a better metaphor than writing for an
| endeavor that closely mixes art, science, craft, and engineering.
| "Put up a house on a creek near a waterfall," we say, and look at
| what each artisan does: The artist, Frank Lloyd Wright (or Don
| Knuth), designs Fallingwater, a building beautiful within its
| setting, comfortable as a dwelling, audacious in technique, and
| masterful in execution. Doug McIlroy, consummate engineer,
| disdains to practice architecture at all on such a pedestrian
| task; he hauls in the pieces of a prefabricated house and has the
| roof up that afternoon. (After all, his firm makes the best
| prefabs in the business.)_
|
| There are other points (not mentioned in this article), e.g. the
| fact that _someone_ had to have written those Unix programs in
| the first place and writing them with literate programming can
| lead to better results, and the fact that Knuth 's idea of using
| a trie (though not a packed/hash trie; that's no longer needed)
| _still_ seems fastest:
| https://codegolf.stackexchange.com/questions/188133/bentleys...
| (please someone prove me wrong; I'd love to learn!)
|
| Knuth gladly included McIlroy's review verbatim when he reprinted
| this paper in his collection _Literate Programming_. BTW here 's
| an 1989 interview of McIlroy
| https://www.princeton.edu/~hos/mike/transcripts/mcilroy.htm where
| he looks back and calls Knuth's WEB "a beautiful idea" and
| "Really elegant", and his review "a little unfair", though of
| course he reiterates _his_ main point.
| smsm42 wrote:
| I'm not sure how it's a fair comparison between ready-made Unix
| tools and written-from-scratch solution. I mean it's like
| somebody asked me to implement a C compiler, and when I produced
| a huge pile of source code would tell me "Idiot, I can do all
| that by just typing "gcc"! Muah-hah-ha!"
| dracodoc wrote:
| I program mainly in R and I always use RMarkdown. I write
| extensively about question definition, notes, reference,
| exploration, different directions in RMarkdown. In the end if I
| ever need to have a script version I have some utility function
| to pick code chunks and output as script.
|
| This serve as a very good documentation and is much better than
| code comments.
| persona wrote:
| Title is a little (?) clickbait... Promoting a YOW talk:
| https://www.youtube.com/watch?v=ATobswwFwQA
|
| -- The other day I was talking with a friend about structured
| editing and literate programming came up. LP was one of Donald
| Knuth's ideas, to structure programs as readable documents
| instead of just machine docs. He was interested in it, I was
| cautiously skeptical. We both knew the famous story about it:
| https://en.wikipedia.org/wiki/Literate_programming
|
| "In 1986, Jon Bentley asked Knuth to demonstrate the concept of
| literate programming by writing a program in WEB. Knuth came up
| with an 8-pages long monolithic listing that was published
| together with a critique by Douglas McIlroy of Bell Labs. McIlroy
| praised intricacy of Knuth's solution, his choice of a data
| structure (Frank M. Liang's hash trie), but noted that more
| practical, much faster to implement, debug and modify solution of
| the problem takes only six lines of shell script by reusing
| standard Unix utilities. McIlroy concluded: >>Knuth has shown us
| here how to program intelligibly, but not wisely. I buy the
| discipline. I do not buy the result. He has fashioned a sort of
| industrial-strength Faberge egg--intricate, wonderfully worked,
| refined beyond all ordinary desires, a museum piece from the
| start."
|
| The program was print out the top K most-used words in a text.
| (and so it goes on...) ---
| hwayne wrote:
| To clarify, it was an email newsletter. The YOW! thing had just
| gotten published so I got that out of the way before diving
| into the meat of the newsletter post, which was about LP.
| kazinator wrote:
| The shell script uses utilities that are written in C, probably
| totaling way more lines of system programming language code than
| Knuth's Pascal solution.
|
| It's a pretty unfair comparison, since the literate programming
| solution was not presented in order to show a code-golfed word
| histogram, but how to annotate code.
|
| The has trie structure was included in it for that purpose, to
| show how you use literate programming to annotate such a thing.
|
| > _First of all, we found that Literate Programming as conceived
| by Knuth not just "text, code, text, code"._
|
| Unfortunately, it's something worse! It's a system in which you
| chop up a program into arbitrary sections, and give these macro-
| like names. The sections are presented in some aribitrary order
| and hierarchically combined together using those macro-like
| names.
|
| Like, say:
|
| _The program 's overall structure is to accept input, performs
| some processing and produce output:_
| accept_input do_processing produce_output
|
| The divisions don't follow function boundaries. A specific loop
| inside a specific function might have its own section, and the
| variable declarations above their own.
|
| It's basically horrible. You can't see the code all in one piece
| at all when editing it. It won't play with your existing tools.
| The generated result won't even have proper indentation.
|
| Web and CWeb are programs geared toward someone who is an
| academic, mainly interested in writing a paper that revolves
| around a small amount of code.
|
| What you're really writing is a paper, such that both the typeset
| paper (with nicely typeset code), and accompanying code pops out
| from the same source. The raison d'etre is that paper though.
|
| You would be suicidal to use this to write an actual application
| that doesn't need to be detailed in an academic paper.
|
| Knuth did somewhat take it to those extremes, but working alone.
|
| If we look at TeX, the bulk of it consists of a single tex.web
| file which is simultaneously not such a large volume of work
| (less than 25,000 lines of code of documentation and data, less
| than a 1024K megabyte) ... yet too large to be all in a single
| file.
| brisky wrote:
| I like the idea that code should look more and more like human
| language. I think that programming languages have gotten much
| more human-friendly nowadays and this trend will continue. I have
| created my own human-like programming language prototype to
| explore these ideas and have implemented TodoMVC with it:
| https://github.com/tautvilas/lingu/blob/master/examples/todo...
| bonyt wrote:
| Site is down, but it looks like archive.org got it.[1] But the
| entire page is blank, because javascript. It has a fallback,
| which has what looks like the article in a noscript tag.
|
| Hastily converted to markdown with pandoc, and put up as a github
| gist:
| https://gist.github.com/tonyb486/eec2f16b06eef4692dac6e56362...
|
| [1]:
| https://web.archive.org/web/*/https://buttondown.email/hille...
| segfaultbuserr wrote:
| > _It looks like archive.org got it. But the entire page is
| blank, because JavaScript._
|
| The AJAXification of the web, even for trivial web pages, is
| defeating archive.org on multiple occasions, it's a huge threat
| to our history preservation. We cannot stop people from
| overusing AJAX, and we need to develop better archival tools.
| DelightOne wrote:
| I'm wondering.. is there a way to use the archive.org tools
| to download the website and later transfer it to my own
| database to not take up too much space in the archive? If
| thats not possible then the archive controller alone is in
| control of history.
| rtkwe wrote:
| > we need to develop better archival tools.
|
| That's the only real solution. Trying to redirect the whole
| ecosystem on to a more convenient path is doomed to fail
| unless your path is actually easier or better in some way.
| marcosdumay wrote:
| > unless your path is actually easier or better in some way
|
| Well, I would argue it is, in nearly every way.
|
| The largest drawback is that by avoiding pulling the
| content with JS you won't automatically deny service to
| people that are trying to avoid trackers... This site looks
| like a medium wannabe, so this is probably important to
| them.
| geofft wrote:
| This is an equivalent problem to the web search problem,
| right? I believe Google indexes webpages by visiting them in
| headless Chrome and dumping the resulting DOM - it seems like
| archive.org could do the same.
|
| https://searchengineland.com/google-will-ensure-googlebot-
| ru...
|
| (Also archive.today solves this somehow, no?)
| a1369209993 wrote:
| Speaking of gratuitously user-hostile websites, the actual
| _text_ of that gist is at
| https://gist.githubusercontent.com/tonyb486/eec2f16b06eef469...
| .
|
| Edit: And now both sites work fine; not sure if gaslight or
| heisenbug.
___________________________________________________________________
(page generated 2020-02-24 23:00 UTC)