🚀 go-pugleaf

In article <2A702840.22262@noiro.acs.uci.edu> cedman@714-725-3165.nts.uci.edu (Carl Edman) writes:
   That is the biggest problem of tcsh - it is compatible with csh which means  
   that it has almost all the csh brain damage.

Amen.

   ...

   > ... is this something special or just another free shell?
   > Whats the associated programming language like?  (If its
   > not Bourne Shell, ksh, REXX, perl or csh compatible -
   > forget it, there are too many shell language
   > alternatives already!)

*

   Combines the best of all imaginable worlds by having almost all the interactive  
   features of tcsh (only the most fancy custom command line completion stuff  
   introduced in the most recent tcsh is not in zsh yet) in addition to many  
   useful ones of its own. But it is based on sh/ksh, not csh which means that it  
   is can also be used for programming tasks.

Please excuse the religion, but ...

I would argue that "combining the best of all imaginable worlds" is
not possible. Having zillions of featues may be in some respects an
Asset, but it is also a liablity because

(1) features increase the size of the program making it difficult to
    write and then debug and also resource-intensive at run time. 

    On the other hand, a smaller language/system wwith no more than the
    basic set of facilities (and perhaps the essential creature
    comforts) is much easier to write, debug and makes fewer demands
    of the system under which it runs. (Or, if it is the system,
    leaves more resources available for the applications.)

(2) more features makes the language harder to utilize. One of the
    chief motivations for RISC architectures was the difficulty of
    implementing a compiler that actually used the "arbitrary-
    mode addressing" capibility of a VAX. Not many people use  '^' as
    a synonym for '!' with /bin/sh and I suppose that equally few
    people change $histchars (which is normally '!') in /bin/csh or
    use its ability to do a one's complement or left or right shift.

    On the other hand, a minimal system gets close to 100% usage by
    most users and it becomes harder for the system to develop "dark
    corners" or misfeatures. More telling, a minimal system's poor
    design tends to show itself quickly and be fixed by a redesign
    (which should not be too difficult is a small system) whereas a
    heavily featured language tends to get "fixed" by by adding even
    more features which are supposed to make up for deficient features
    in the original design. [unfortunately even good software can grow
    this manner. Witness Unix IPC.]

(3) features often interact poorly with each other. Given a language
    with n features, there are, at worst, n! possible interactions between
    features. Csh has something like 20 history constructs (including
    modifiers), which is probablly why Bill Joy did not catch all the
    bugs (Read csh-whynot).

    Reducing the number of features tends to minimize the number of
    interactions.