head isn't needed because we can already do it with the command line options for sed.
Sigh ... fine except for the fact that sed(1) did not exist when head(1) was written. So you missed the point of my example. FWIW: if you want to pick nits, in this case, the solution with the former is redundant with the latter. IMO, That's ok as it follows in the basic tradition. UNIX has a number of ways to do similar things/solve the same problem, because it offers tools, the system designers do not try to dictate a singular solution.
As I fear by the reaction, many of you have missed the point of what I was trying to say. I guess I did not do that clearly. Let me try in a shorter form.
The basic idea of the original Unix was that was small and simple and in Dennis' words, 'ran on modest hardware.' The designers of UNIX also did not try to solve any one particular problem but offered a set of tools for a >>programmer<< take upon her/himself to do so.
The issue is that the target >>user<< of UNIX had devolved from that of a 'programmer' but rather the elusive 'end user' and her/his view/requirements tend to be "solve my problem now -- I don't care how - just do it I don't want to think about it - make it go away." So over time, we hid a lot of the simplicity in features that were built on features (often warts) that were built on other features (often other warts). Mashey had a great visual in his "small is beautiful" talk using a 'build slide' in PPT terms that demonstrated the problem.
I was commenting on the OPs post of the paper picking on UNIX, the UNIX Shell, and where we are today vs. 50+ years ago. My other point is the authors need to get over themselves and recognize that they are not making a really new argument. Folks were not too happy with many of the BSD 'features' either, but now those same features (like head(1) or BSD sockets(3)) are considered SOP for nay new UNIX and you have to have them - even if there are other if not 'better' ways of doing the same thing.