peter@ficc.uu.net (Peter da Silva) (05/02/90)
I think it's more a matter of there being three classes of programs. There are
interactive programs, which when well implemented are essentially editors,
and there are batch programs, which act on data (either as a filter, a source,
or a sink), and then there are shells, which act on programs.
Given fast enough hardware, or a slow enough input channel, you can always
discard all your interactive programs and run everything as batch programs
from your shell. This means that batch programs have a longer potential
lifespan, as the race between CPU and I/O makes the tradeoff point wash
backwards and forwards between running batch programs from the shell and
running interactive programs by themselves. You see, having a batch program
at the wrong point in the tide just costs you performance. Having an inter-
active program at the wrong time costs you functionality.
It's all a tradeoff. Use the best tool for the job, but make sure it *is* the
right tool. And if you're not sure... go batch. it's the conservative approach
for the long haul.
As for why programs like EMACS seem to be bucking the trend... they're not.
They're shells.
--
_--_|\ `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>
/ \ 'U` Have you hugged your wolf today? <peter@sugar.hackercorp.com>
\_.--._/ Disclaimer: commercial solicitation by email to this address
v is acceptable.gwyn@smoke.BRL.MIL (Doug Gwyn) (05/02/90)
In article <15849@phoenix.Princeton.EDU> pmullman@phoenix.Princeton.EDU (Peter M. Ullman) writes: >If I find later I have made a mistake, I can snarf the correct parts >off the screen, and just retype the incorrect parts. This sort of thing is what caused us to make the BRL Bourne shell's "history" command display the command history without extra cruft on the beginnings of the lines, unlike csh, and also to make the "whatis" builtin display its output in a form suitable for re-input to the shell, unlike AT&T's Bourne shell's "type" builtin. Similar thought went into the order of execution of the $ENV file vs. .profile, non-use of $ENV by scripts, and so forth, all different from the way ksh does these things. It helps if you're accustomed to a nice interactive terminal like the AT&T 630 where cut-and-paste operations on the text display are quite natural, so that you really do use them frequently. In sicker environments, the advantages of clean user interfaces are not so evident.
gwyn@smoke.BRL.MIL (Doug Gwyn) (05/02/90)
In article <5111@jhunix.HCF.JHU.EDU> doug@jhuvms.bitnet (Douglas W. O'Neal) writes: >Forgot one. Most of the times I have seen ed used, it has been interactive >(usually to make a quick change to a file). Would Mr. Ullman like this >capability taken away to make it more pure? I suppose that's your contribution to the list of stupid UNIX questions. Or did you really not understand a word that he was saying?
seanf@sco.COM (Sean Fagan) (05/03/90)
In article <5111@jhunix.HCF.JHU.EDU> doug@jhuvms.bitnet (Douglas W. O'Neal) writes: >Forgot one. Most of the times I have seen ed used, it has been interactive >(usually to make a quick change to a file). Would Mr. Ullman like this >capability taken away to make it more pure? ed's sole claim to being interactive is its error "message" ('?'). Any program which accepts commands (or data) from stdin, and can produce output on stdout, fits very nicely into unix. It can be interactive, since, unless specified, stdin and stdout are your terminal, or it can be used in a pipe. vi, in all incarnations I've seen, cannot be used in a pipe (emacs might be able to, but I don't think so). I'd also like to point out that the only times *I* use ed, generally, are to do some batch editing of a file. -- -----------------+ Sean Eric Fagan | "It's a pity the universe doesn't use [a] segmented seanf@sco.COM | architecture with a protected mode." uunet!sco!seanf | -- Rich Cook, _Wizard's Bane_ (408) 458-1422 | Any opinions expressed are my own, not my employers'.