Path: utzoo!attcan!uunet!cs.utexas.edu!wuarchive!texbell!nuchat!sugar!ficc!peter From: peter@ficc.uu.net (Peter da Silva) Newsgroups: comp.unix.questions Subject: Re: stupid unix questions Message-ID: <4Q536Rxds13@ficc.uu.net> Date: 1 May 90 23:13:08 GMT References: <15758@phoenix.Princeton.EDU> <1990Apr29.222031.1043@diku.dk> <3653@castle.ed.ac.uk> <1990Apr30.053057.2943@smsc.sony.com> <15849@phoenix.Princeton.EDU> Reply-To: peter@ficc.uu.net (Peter da Silva) Organization: Xenix Support, FICC Lines: 20 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. / \ 'U` Have you hugged your wolf today? \_.--._/ Disclaimer: commercial solicitation by email to this address v is acceptable.