From mboxrd@z Thu Jan 1 00:00:00 1970 From: Noah Evans Subject: Re: [9fans] insularity To: 9fans@cse.psu.edu Message-id: <286242286f27.286f27286242@cwru.edu> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Date: Wed, 17 Mar 2004 11:52:05 -0500 Topicbox-Message-UUID: 33c4f802-eacd-11e9-9e20-41e7f4b1d025 Sorry to pile on to the discussion. As rob said It's a fundamental difference in perspective. Plan 9 was more or less inscrutible to me until I read the Unix Programming Environment and Software Tools. why wasn't there a tar z? why wasn't there tab completion? Where was my history and job control? These things are obvious to people who are familiar with the philosophy(I always think of boyd's comments to hapless newbies :)), if you use a long command combination often enough you should write a shell script or a shell function. essentially adding to your productive vocabulary. But this philosophy is lost on people who are used to the windows/consumer Unix world because they're used to solutions that violate the tools method of solving problems. A really bad habit of mine is relying on the history to do things, Rather than spend the initial cost of effort to write a shell function and remember it, I'm constantly using Bash's tab completion and history functions to avoid having to expend any effort organizing my patterns of use and solving problems. Everything I do is an ad hoc solution. With Plan 9 I'm forced to do it right, because the people who implemented the OS religiously keep the cruft out. But, as Dave said, it's a long and arduous process whose benefits are hardly apparent when you set out(i.e. "why should I use du and awk to walk a tree when you could use find" is the first question that hits every new user familiar with Unix). You only realize in hindsight. The problem comes when people who are used to the ad hoc way of doing things like this come in contact with Plan 9. The majority of the people on this list are so immersed in the tools philosophy that it's like breathing to them. The intracacies and nuances are natural to them. When you pit this mastery against the sense of entitlement that comes from mainstream systems you get conflicts like this. People expect canned solutions not pointers to *how* to solve things. But this is all obvious and has been discussed to death in the archives. The real issue is how to solve this problem. I propose that we emphasize the tools philosophy to clarify the underlying philosophy and justifications in introductions to new users. It's already there really, but scattered in other explanations rather than dealt with systematically. Now that I'm thinking about it, I think this is what ESR and Jim Choate mean when they talk about a lack of documentation --but not in the way they think. Plan 9 *is* sufficiently documented assuming that you make it past the first "conceptual hump", understanding the basis of the tools philosophy. One way of solving this would be to use existing books like the "Unix Programming Environment" or "Software Tools" with their code updated for Plan 9. I think a lot of people avoid those books because they don't believe they need to learn ancient Unix or Ratfor. And it's a shame because they miss the conceptual forest for the trees of individual system implementations and cruft. I'll gladly contribute anything I can if we can agree on a roadmap. Noah