I don’t follow: aren’t you effectively restating the blog post’s argument? How did the blog post miss the point?
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.
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.
Source: big Perl evangelist back in the 1900s.
You were really ahead of your time.
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.
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.
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.
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
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.
Both have important points.
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.
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.
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...
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!