Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!uceng!dmocsny
From: dmocsny@uceng.UC.EDU (daniel mocsny)
Newsgroups: comp.lang.c
Subject: Re: Language principles
Message-ID: <3526@uceng.UC.EDU>
Date: 3 Feb 90 00:30:02 GMT
References: <490@dino.cs.iastate.edu>
Distribution: na
Organization: College of Engg., Univ. of Cincinnati
Lines: 36

In article <490@dino.cs.iastate.edu> hascall@cs.iastate.edu (John Hascall) writes:
[...]
>    SIMPLICITY:  A language should be as simple as possible.  There
>       should be a minimum number of concepts with simple rules for
>       their combination.
[...]
>     What do you think of the list?  What's missing?  What's
>       extra?  What's insightful?  What's just plain wrong?

I agree that a language should be as "simple" as possible, but how
simple can a language be, and still be a useful tool for building the
complex applications users demand? (Note: I include libraries in what
I refer to as "language," since the programmer must assimilate their
calling syntax just like the underlying language itself.) If the
application is inherently complex, the complexity has to show up
somewhere. If the complexity isn't in the "concepts" or the "rules
for their combination," then it will be in the sheer number and
detail of those combinations. TANSTAAFL and all that.

I think "simple" languages and programs are useful primarily for
complex (i.e., expert) users, people who are willing to spend 10x as
much effort poring through manuals as actually running anything. The
other 99% of humans have other responsibilities and interests besides
keeping the computer happy. They require "bells and whistles", such as
a program that takes care of its own errors, and can explain clearly
at any time how the user may take advantage of it.  Writing programs
such as this forces the programmer to confront an enormous amount of
detail. If the language does not embed this detail in its "simple"
syntax, then it has to embed it in its libraries.

So perhaps "simplicity" is not so much what we want, but grace in
handling the complexity we can't avoid? In other words, striking a
reasonable balance between capability and complexity. 

Dan Mocsny
dmocsny@uceng.uc.edu