Larry McVoy scripsit: 'Sfunny, but it seems just the other way about to me. Unix, especially Olde Worlde Unix, is all about memorizing stuff. Creat(2) has no final e. The option to set the field delimiter is -t, except in cut(1) where it's -d and in awk(1) where it's -F. You dump a file to standard output with cat(1); yeah, you can remember the name if you learn the word "catenate", but most of us don't know that word, and it's no easier to memorize "catenate" than "cat" (more fun, but no easier). We all find all this very natural, it ripples off our fingers because we've been doing it for 10 or 20 or 30 or nearly 40 years, and none of the inconsistencies can be fixed because if they were it would break all of our muscle memory and then it wouldn't be so easy at all. Windows folks can't deal with all that memorization. They want it laid out for them: menus dialogs wizards with tabs that make all the options visible, or if not all visible at once, at least easy to see how you can make them visible. And all consistent, or reasonably so. With Windows programs you really can guess what they re going to do, and you will be right most of the time. Unix utilities aren't like that. Even X programs aren't -- indeed, less so than the utilities, unless they use a Windows-mimicking toolkit, which most of them do nowadays. No, what makes Unixicians sont droit et Windowsites sont tort is that Unix lets you make up your own stuff out of existing pieces, and Windows does not. The Windows utilities just do what they do, and if it's not what you want, it's back to the drawing board, so people create TMA-1 monoliths. This tendency is infecting Unix too nowadays, as lots of people have discovered how much easier it is to create TMA-1s on Unix than on Windows, and so they do, and the native tradition of coarse-grained dataflow gets almost lost against the background surviving only in the memories of the Old Farts here gathered. Our tradition's dying unless we do something to keep it alive. What's that going to be? -- I don't know half of you half as well John Cowan as I should like, and I like less than half cowan(a)ccil.org of you half as well as you deserve. http://www.ccil.org/~cowan --Bilbo

Evan de Riel scripsit: Well, I don't have a problem with replacing the shell-and-utilities framework with a more consistent one. The trouble is that the essential idea of that framework, what I called "coarse-grained dataflow" in the last posting, and which has been called "plumbing" since the earliest days, gets lost in the process. Perl-level programming is only incrementally better than C-level (admittedly the increments are good ones, like garbage collection and simple strings and dynamic typing). The only consistent framework I know of that preserves plumbing as a functional programming approach is scsh <http://www.scsh.net/>, and much as I love Scheme personally, it's just too alien to mainstream ways of thinking to have a real chance of survival as anything but a niche of a niche. What I'd really like to see is something that merges Lua and rc(1), a lightweight but powerful language with a lightweight but powerful shell, in a clean way. I even messed around with constructing a unified Yacc grammar to use them jointly, with the notion that a top-end parser could compile the hybrid into pure Lua using a Posix library. But I got bogged down and never went back there. Lua might be *too* lightweight, though: Python comes with a big library of useful stuff, is a fair approximation to Lisp (as Lua is also), and could perhaps be transmogrified into a shell somehow, given how dynamic everything in Python is (even the variable and function declarations are really executable statements). I'll think on it further. -- Barry gules and argent of seven and six, John Cowan on a canton azure fifty molets of the second. cowan(a)ccil.org --blazoning the U.S. flag http://www.ccil.org/~cowan