9  Size

Scsh can justifiably be criticised for being a florid design. There are a lot of features -- perhaps too many. The optional arguments to many procedures, the implicit backquoting, and the syntax/procedure equivalents are all easily synthesized by the user. For example, port->strings, run/strings*, run/sexp*, and run/sexps* are all trivial compositions and curries of other base procedures. The run/strings and run/sexps forms are easily written as macros, or simply written out by hand. Not only does scsh provide the basic file-attributes procedure (i.e., the stat() system call), it also provides a host of derived procedures: file-owner, file-mode, file-directory?, and so forth. Still, my feeling is that it is easier and clearer to read

(filter file-directory? (directory-files))
than

(filter (lambda (fname)
          (eq? 'directory 
               (fileinfo:type (file-attributes fname))))
        (directory-files))
A full library can make for clearer user code.

One measure of scsh's design is that the source code consists of a large number of small procedures: the source code for scsh has 448 top-level definitions; the definitions have an average length of 5 lines of code. That is, scsh is constructed by connecting together a lot of small, composable parts, instead of designing one inflexible monolithic structure. These small parts can also be composed and abstracted by the programmer into his own computational structures. Thus the total functionality of scsh is greater than more traditional large systems.