Just like no one really uses ed anymore, the C shell is pretty much dead and many userspace programs have had their edges rounded over the years, but the experience of trying to imagine working around their foibles gives the perspective necessary to helpfully advise someone trying to learn an acceptable shell today (except that they'll have more use for their effort at some point) because they're pretty much the same kind of transition. Compare these highlights to that ed page:
>Pipes are not the be-all and end-all of program communication. Our favor-ite Unix-loving book had this to say about the Macintosh, which doesn’t have pipes: "The Macintosh model, on the other hand, is the exact opposite. The system doesn’t deal with character streams. Data files are extremely high level, usually assuming that they are specific to an application. When was the last time you piped the output of one program to another on a Mac? (Good luck even finding the pipe symbol.) Pro-grams are monolithic, the better to completely understand what you are doing. You don’t take MacFoo and MacBar and hook them together." Yeah, those poor Mac users. They’ve got it so rough. Because they can’t pipe streams of bytes around how are they ever going to paste artwork from their drawing program into their latest memo and have text flow around it? How are they going to transfer a spreadsheet into their memo? And how could such users expect changes to be tracked automatically? They cer-tainly shouldn’t expect to be able to electronically mail this patched-together memo across the country and have it seamlessly read and edited at the other end, and then returned to them unscathed. We can’t imagine how they’ve been transparently using all these programs together for the last 10 years and having them all work, all without pipes.
>This morning I read an article in the Journal of Human-Computer Interaction, “Expertise in a Computer Operating System,” by Stephanie M. Doane and two others. Guess which operating system she studied? Doane studied the knowledge and performance of Unix novices, intermediates, and expert users. Here are few quotes: “Only experts could successfully produce composite commands that required use of the distinctive features of Unix (e.g. pipes and other redirection symbols).” In other words, every feature that is new in Unix (as opposed to being copied, albeit in a defective or degenerate form from another operat-ing system) is so arcane that it can be used only after years of arcane study and practice. “This finding is somewhat surprising, inasmuch as these are fundamental design features of Unix, and these features are taught in elementary classes.”
In both cases, we have someone moving from a relatively monolithic, high-level, restricted, commercialized system that focuses on uniformity, error-bar tolerance, and DWIM/intuitiveness of the intended or common use-case over giving every capability equal billing to one that focuses on completeness, atomicity, and implementation simplicity/efficiency. Learning this transition has two phases because the best way to keep going with the learner's current knowledge has two phases: Before making the transition they probably learned the old system through self-tutoring and exploration; the stakes were low enough and the environment painstakingly organized to be similar enough that a little curiosity and a little induction from past experience explained basically every level of the user-visible stack, and the slab of composed foundation functions that made the first-blush system run were either walled off fully or guarded to wave away novices. Pre grokking the new software, though, the user lacks the idioms that make it possible to write a more complete computing system out of less code, and so don't know when to apply what even if they've read up on most of the pieces they need already. It's like a transition from an upper-class aerospace engineer or hedge fund manager exploring Animal Kingdom Park to making a trek through the indian jungle. Even if you're carrying a reference tome on the region there are intangibles you're just missing, so you're far more likely to get lost and confused or hurt yourself if you don't walk right in the footsteps of someone expeeienced for a good long while. It's similar with the terminal: When you're successful, things are clearer and simpler than a jumbled heavyweight gui, but when you make the "mistakes" that come along with not almost entirely knowing what you're doing it can be unhelpful, mystifying, and rarely dangerous, because the experienced users happen to be the most-engaged target market. Not everyone has Apple money, after all.
The phase change back to effective exploration, and actual use over learning through apeing, only comes after they've got both most of the terrain and most of the problem-solving strategies in their head all at once to hit a self-sustaining critical mass. Something akin to the Khan(academy) flipped method is what I think is most important to remember when teaching: most experienced users think in terms of learning new skills through integrating new components, while beginners tend to know less about the implications of recombining the utilities they're already aware of in the less common and simple ways than show up as line snippets in crash courses. New users can read a man page as well as you can recite it by heart, but what they really need tutoring in is how to know they're reading the right part of the right page and what your experience says to do with it.
Just getting that all off my chest as someone who didn't have anyone to teach me and used to be spectacularly bad at teaching others, so someone might learn from my mistakes.
