Hacker News Reader

Comment by pdpi | Hacker News Reader

(2020)

It seems to me that both McIlroy’s original critique and this blog post miss the point by a mile. It’s completely meaningless to compare the relative merits of the two solutions, because Knuth’s ultimate goal isn’t to produce a solution.

Doing a presentation on literate programming has to deal with two more or less contradictory concerns — you need a sufficiently simple problem that your audience can follow along, but you need your solution to be complex enough that you can actually illustrate LP.

A sorted frequency table is a simple enough problem statement, a trie is a sufficiently elaborate solution that doesn’t feel too contrived while also being familiar enough that the audience can follow along. Knuth’s approach was pretty much the perfect way to hit both of those requirements!

View on HN

> It seems to me that both McIlroy’s original critique and this blog post miss the point by a mile. It’s completely meaningless to compare the relative merits of the two solutions, because Knuth’s ultimate goal isn’t to produce a solution.

I don’t follow: aren’t you effectively restating the blog post’s argument? How did the blog post miss the point?

Perhaps by misrepresenting the blog post's argument, the comment is reinforcing the blog post's point about the importance of reading primary sources.

> A sorted frequency table is a simple enough problem statement, a trie is a sufficiently elaborate solution that doesn’t feel too contrived while also being familiar enough that the audience can follow along.

As one of the essays linked yesterday noted, Knuth did not pick the problem, he specifically asked the editor to do so, such that he would not necessarily select a problem perfectly suited to LP.

Also shell pipelines are very flexible, but there is a limit of what you can achieve with this approach. This complexity limit is the reason why they invented more flexible scripting languages like perl and python.

Python (and any other general purpose languages) shouldn't be considered a replacement for shell pipelines but rather an extension tool. Actually, the pipelines survived 50 years in big part due to how easy to extend them: just define something that can read from stream of bytes, and write to another one (use what ever language you like).

The origin of composing simple programs that do one thing well is likely was originated as the consequence of the introduction of shell pipelines (or the genius pre-designed property).

Pipelines is a good example of "less is more" concept.

Perl was the other language mentioned and it was in fact marketed as the One Tool to Rule, with examples given of how to replace your "complex and brittle" shell pipelines with a few lines of Perl.

Source: big Perl evangelist back in the 1900s.

> Source: big Perl evangelist back in the 1900s.

You were really ahead of your time.

Would you agree that 1795 was in the 1700s?

No, it's the 18th century.

I think people genuinely get confused that the century that has dates like 19XX was the 20th century, so they say "1900s" to cover for it. But that has an established meaning, namely 1900-1909.

> But that has an established meaning, namely 1900-1909.

I'm not going to claim to know the history of how terminology develops. But I don't think I have ever come across someone using "XX00s" to refer solely to the first 10 years of that time period.

The general rule of thumb for reading numbers is to treat every trailing 0 as a marker of an insignificant figure, so a number like "1,000,000" is presumed to have 1 significant figure and not 6. By this rule, the most natural interpretation of 1900s is that it encompasses 1900-1999.

A word or phrase doesn't really have a single established meaning if enough people use it to mean something else. Unless we're talking about "literally", in which case the damn kids had better get off my lawn.

"But that has an established meaning, namely 1900-1909"

Not to anyone I have ever known. I have never before this post today heard anyone say that "the nineteen hundreds" means 1900-1909. It always refers to 1900-1999.

I've only ever heard of 1900-1909 referred to as "the aughts" ( https://en.wikipedia.org/wiki/Aughts ) - which, admittedly, always sounded weird to me, but I wasn't alive then.

https://en.wikipedia.org/wiki/1700s

1700s may refer to:

- The century from 1700 to 1799, almost synonymous with the 18th century (1701–1800)

- 1700s (decade), the period from 1700 to 1709

Yes, I was just poking fun at the ambiguity.

https://old.reddit.com/r/yourjokebutworse

I recently started this project: https://github.com/codevin/featureplus (Only getting objectives right now).

I now realize that my motivations are same as literate programming. My focus is to get features integrated into codebase. A developer should only do incremental programming, which will insert code into centrally hosted codebase.

At least it made me dig beyong McLlroy's ~rebuttal.

Both have important points.

I don't know, isn't this kind of demonstrating a chain saw by chopping up a carrot, seems like it would be somewhat easier for the presenter since they don't need to get an actual log, but at the expense of really misleading the audience.

I’d say it’s more like demonstrating how a chainsaw is useful for felling a tree, by using a log as a stand-in so you don’t have to deal with all the other complexities of felling an actual tree.

Yeah maybe you're right, I just remember all those hello world examples with advanced design patterns and how that gets people all excited to overengineer and overcomplicate everything.

Edit: I'm a bit tired of all these "this is not something that you would actually ever do" caveats, well, don't show it then?

I think a key difference between what you’re describing and Knuth’s program is that those design patterns don’t actually serve a purpose, they don’t solve a problem and just add incidental complexity. Knuth’s trie is an actual solution to the word frequency problem that doesn’t add much incidental complexity — it just tackles the fundamental complexity from first principles, so all of that complexity is staring you in the face. Once you have well-motivated complexity to make sense of, you also have a well-motivated use for LP.

"Edit: I'm a bit tired of all these "this is not something that you would actually ever do" caveats, well, don't show it then?"

Because solving real world problems in a solid way is often too complicated for a presentation, but to show something special you sometimes have no other choice to come up with non real solution that show the principle. But I agree that you can do this in a bad or good way.

Yeah or is it like the infomercials where people show you these awesome gadgets that solve problems that you actually don't have, just to sell you a bunch of crap so that they can make money.

Yes. Literate programming is an incredibly useful tool, if you do happen to have the problem it solves, that is textual communicating with people with a very large difference in knowledge from yours.

But almost nobody has to solve this on practice. The ones that do have recreated the idea again and again (today's most common iteration are Jupyter notebooks), because it's a great idea. But they are always a waste of time for most people.

> Yeah or is it like the infomercials where people show you these awesome gadgets that solve problems that you actually don't have, just to sell you a bunch of crap so that they can make money.

Except that they do solve problems people have, just not problems you have. They are meant for, or at least often employed by, the disabled community.

https://www.vox.com/the-goods/2018/9/20/17791354/products-pe...

Reply on news.ycombinator.com