I look forward to a copy of the book as soon as my bookstore can get it.
These views generally result in my being labeled a Luddite by the Unix priesthood. But Ned Ludd was right --- the new machines did not make conditions better for ordinary working folk: the people whose conditions were immediately improved were those who owned the machinery, and whose profits thereby increased. Similarly, the change to Unix will, in the short term at least, do more to provide employment for our computers minders than to improve the average astronomer's relationship with her computer. Unix does have its advantages, but few of these are intrinsic --- in the sense that they could not be implemented within other operating systems --- and to my mind they are far outweighed by the disadvantages.
Alright, I have to admit it. I don't like Unix (or is it "unix"?) Of course one can get used to almost anything. But is "rm" (pronounced "remove") really synonymous with "delete". Do I call the deleters when I want to move house. How would my first cousins once-deleted feel? And any real language is at least pronounceable. I have only been able to come up with one algorithm for creating Unix command names: think of a good English word to describe what you want to do, then think of an obscure near- or partial-synonym, throw away all the vowels, arbitrarily shorten what's left, and then, finally, as a sop to the literate programmer, maybe reinsert one of the missing vowels. Mnemosyne, goddess of memory, must be rolling in her grave. (She was, incidentally, the mother of the muses, including Urania, the muse of astronomy.) It is notable that all the machines I have used interactively in the past spoke to me in plain English. OK, they didn't necessarily have a big vocabulary, but typing HELP was always likely to return a menu of commands that was almost identical from machine to machine and whose function was immediately obvious. Although there are some really powerful features in Unix --- such as the pipe --- what I see (and interact with) is a user interface designed by adolescents and constructed deliberately so as to make access to the machine as difficult as possible for a novice. Is this really a suitable foundation for an international standard?
In reply to this criticism one is normally reminded that Unix was invented for a PDP7, which had about as much memory as an earthworm and CPU power to match. That is, the user interface was designed to minimize the time required to decode a command. That meant short, fixed-case, commands, and no minimum matching. But 1969 is a long time ago, and both memory and speed have improved a thousandfold since then. This response thus goes directly to the core of the case against Unix. It is old-fashioned. Why is the world now, 25 years later, adopting as a long-term standard a primitive operating system designed when the capabilities of today's machines were then undreamed of? Actually, the answer is easy. Operating systems cost hardware manufacturers, and therefore consumers (us), money. Unix is free, and whatever its defects at least no one blames the hardware manufacturers. So in a world that thinks megaflops or Specmarks are the only indicator of computer power, Gresham's law holds --- bad software drives out the good.
[This lemming-like rush to adopt Unix just now seems slightly curious. It will be ironic if it eventuates that Starlink has felt it necessary to adopt Unix just as Unix is itself superseded. Yet that appears to be a real possibility. Windows NT has been designed with distributed processing and interoperability as the major drivers. Here are two quotes from IEEE Spectrum, December 1993: "... Windows NT, by covering almost all the latest RISC processors, opens the way to a consistent computing environment. Delighted early users are already contemplating making it their new standard." And: "Thus Unix will go on evolving, but largely in order to keep up with Windows NT".]
Even the commands that are pronounceable are idiosyncratic to say the least. How can one understand "biff"?. As people never tire of telling me, it is the name of a programmer's dog (but you'll note, just in case you thought this might help you to memorize the command, this name starts with a lower case letter). It comes coupled with a twee American icon, that is meaningless in the UK context. And there are other examples. Grep suggests to me that the author of this one had been reading too much Robert Heinlein (you grok?), or possibly --- and this is in fact quite likely --- was under the influence of psychotropic substances at the time. Unix seems to consist largely of arcanae which be learnt only by taking instruction direct from a priesthood who seem largely to be stuck in the anal-retentive stage. When yesterday's six-year olds take over Unix development (in four or five years) I fully expect to see new commands ldo, nja, mch and rfl. After turtles, dinosaurs. Will the command tRex devour your competitor's data?
As intimated above, Unix documentation, or the lack thereof, is a serious problem. There is no effective way to find out how to use Unix, other than sitting next to an adept and asking for help (and you know what these people are like. Don't you? Haven't you ever been in a computing centre to pick up some output late at night? Dirty cups half full of stale machine coffee, many with cigarette butts floating in them, the floor littered with Twinkies wrappers, insane giggling over some semi-pornographic picture cleverly printed out on a line printer using different characters overprinted to get the greyscale effect... Grab your output and run!). I remember on one occasion being logged into a Unix machine to send some mail, and, not knowing the command name, being unable to log out. It was an expensive 8000-mile long telephone connection, but the machine steadfastly refused to respond to "help" (or log, logout, logoff or quit). Finally someone suggested I type "man" (hey man, what the hell do I do now?), and it said "Documentation is held in the user area in room 932" (or something like that). Which didn't really help. Anyway, have you ever tried to use man? It's fine as long as you know what you are looking for. How would you ever find out the name of command given just the function you wanted to execute? You can't. I just tried to find out what the librarian was called, and man was silent on this issue. Sure it gives you pages of information about "ar", but nowhere can you find out that it is the pages about "ar" that you need to read. Oh, say the adepts, you just use "apropos". Apropos (or even "apropos") means "apt, appropriate", which, even if you knew the command existed, would not immediately suggest a way to find out information about something. In addition to their other failings, the authors of this command are illiterate. On occasion, as in this instance, the makers of Unix have gone out of their way to avoid using the appropriate word. What was wrong with `help'?
What next? Oh yes, case-dependence. Well, e.e.cummings made a fortune, or at least a reputation, out of refusing to use capital letters, and I guess Ken Thompson might very well have regarded him highly back in 1969. But it's only convention isn't it? Long after 1969 most terminals (teletypes we called them then) only had capital letters anyway, and I suppose that was stifling creativity or something. So if you want to use lower case letters of course that should be allowed. But why oh why invent a system where the commands MV, mv, Mv and mV can all do different things? Here is my question to Unix apologists. Would you return your old-fashioned sneaker-net mail to the sender if he or she had forgotten to capitalize your name? Even if it contained a cheque?
Well, that's the user interface. As for the applications programs ... Even something fundamental like the SunOS f77 compiler is a disaster. It doesn't include the full standard as a subset (look at their OPEN statement for unformatted direct access if you don't believe me), and it contains, according to my Unix-literate colleagues, several major errors. Gresham's law strikes again. What about the editors? I don't have time to go into that one! One can only conclude that the makers of Unix held, and still hold, the ordinary computer user in total contempt, and this viewpoint seems to me to be mirrored in the attitudes of the people who are inflicting this awful system on the rest of us. Does Unix's enormously steep learning curve have any function other than to deter the faint-hearted, those who may want to use computers without necessarily dedicating their lives to them? It does not seem fanciful to suggest that Unix is primarily about separating out the elite from the proletariat, the real programmers from the quiche-eaters. It is about taking back the mantle of the priesthood, that was lost when manufacturers like DEC introduced operating systems like VMS. But of course it's all worthwhile really, because Unix is a standard, and that means it's the same everywhere, and will never change (see what I mean about self-defeating arguments?)
Let me quote again from IEEE Spectrum: "In reality, however, there are many Unix-based operating systems; the major ones include Apple Computer's AUX, Digital Equipment's Ultrix, Hewlett-Packard's HP-UX, IBM's AIX, the Open Software Foundation's OSF-1, Sun Microsystems' Sun OS and Solaris, and the Santa Cruz Operation's Xenix and SCO Unix. With such an assortment, users [who work] with platforms from several manufacturers [are] caught in the bind of supporting multiple releases of multiple versions of Unix." This monoculture is divided by a supposedly common tongue. Unix is not a standard any more than English is. One of the touted virtues of Unix is that you can unplug any component and plug in something else with the same name, so that you can tailor it to your needs (indeed the Starlink .cshrc does this with your Tex commands!). So while you can go to any VMS system anywhere in the world and be instantly at home, you can't depend on a Unix command to do what you think it should anyway. Sometimes even the options are different. Take the tar command (please!), which is already a nightmare where lower-case `a' means "check first" and upper-case `A' means "delete all my disk files without asking" (or something like that --- I may not have the details exactly right). In some versions of tar these meanings are reversed. This is a virtue?
OK, I admit it, I was joking there. But I'm not joking when I quote from SUN 145:
There is a distressing mindset amongst Unix cognoscenti. Most attacks on Unix are answered with statements to the effect that make and grep are wonderful, that redirection and piping are very clever, and that the whole system is much more "elegant" than VMS. Well, I admit that make is wonderful. Still, it is only an application, and as such could be implemented on any operating system. As for grep... A few days ago I thought to search for each occurrence of the $ character in a piece of code (so that I could move it from its non-standard position at one end of the FORMAT statement to the alternative non-standard position at the other end, to make it work on a Sun). Dutifully I translated "SEARCH [-...]*.FOR", and typed "grep '$' ../*/*.f | lpr" (Note the clever redirection of the output to the line printer.) The following morning I found the entire source code of SPECX in a heap beside the OKI printer. This does not strike me as very elegant! Neither is it elegant that the X-terminal driver is so primitive that it reflects characters immediately rather than waiting until input is requested, nor that everyone has to include keyboard remappings in their .Xthingy files (in fact this part of it is worse than a PC), nor that when talking to an applications program you can't edit the line you are typing except by using the delete key. It is not elegant that logical names --- sorry, environment variables --- are not inherited by programs, so that each program has to include code to parse input and translate the logical name before opening a file or whatever. Well, I'm sure I could go on forever. And the minute you criticize Unix to your Starlink friends they say "Yes, I agree, but I'm not allowed to say that!"
A Starlink mole has suggested to me that project staff are not unaware of the sort of Unix failing detailed here, but that the change to Unix was largely mandated by external pressures. Canute could not hold back the tide (and knew it), and obviously neither can Starlink, even it wants to. It's a pity however that the tide seems to be largely composed of lemmings --- that is, slightly computer-literate users, who are persuaded by the Unix hype, fancy joining the grep-awk priesthood, and mistakenly confuse the time spent learning how to use Unix with productive work. Unfortunately they never have to suffer the defects of the system they have foisted on the rest of us.
Well, it's not really funny. The change to Unix has real implications for astronomers, which have generally not been addressed. Yes, it means that we can all run Unix mega-packages like IRAF and SAO-Image (name your favourite). Unix and C however form a powerful deterrent to the average astronomer to write her or his own code (and the average astronomer's C is much, much worse than his Fortran used to be). The powers-that-be in the software world of course have always felt that "ordinary" users (astronomers in this case) should be using software and not writing it. The cynic might feel that since those same powers nearly all make their living by writing software, and get even more pay when they manage other programmers, then they have a vested interest in bringing about a state of affairs where the rest of us are reduced to mere supplicants, dependent on them for all our software needs. It is clear that Unix does not pose an insuperable barrier --- the ever-expanding armies of hackers out there are evidence enough that the barrier can be scaled given enough time and enthusiasm for the task. But hacking is not astronomy, and hackers are not astronomers, and it is astronomy and astronomers I worry about. We shouldn't have to scale the Unix barrier, and it is all the sadder because, since the advent of a VMS-based Starlink, ordinary astronomers have had something denied to most other scientists in this country --- readily accessible, reliable, user-friendly computing power that can be easily harnessed to a particular astronomical requirement. Maybe VMS does baby its users. Maybe we have paid more per Specmark so that we could use the Specmarks we had efficiently. But along with the rest of the world, we are now losing this nice friendly system. As with instrumentation and the National Observatories, we are having to teach our students how to fit their problems to facilities provided by others, whereas the UK reputation in astronomy was created by fitting the facilities to the problem.