Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!caesar.cs.montana.edu!icsu8209
From: icsu8209@caesar.cs.montana.edu (Glassy)
Newsgroups: comp.lang.misc
Subject: Evaluating Programming Languages
Message-ID: <3069@caesar.cs.montana.edu>
Date: 4 Feb 90 22:36:18 GMT
Sender: news@caesar.cs.montana.edu
Reply-To: icsu8209@caesar.cs.montana.edu (Glassy)
Distribution: usa
Organization: Montana State University, Dept. of Computer Science, Bozeman MT 59717
Lines: 74

I would like to develop some set of criteria for evaluating
programming languages (both microscopically, on the 'feature' level,
and macroscopically, examining the language in toto).

I view a programming language as a tool.  A program represents the
tool in action;  to paraphrase Abelson & Sussman in "Structure and
Interpretation of Computer Programs", a program specifies the
evolution of a computational process.

Intuitively, then, for Language X to be an effective tool for
Application Y, X must enable me to specify the evolution or behavior
of process Y in a clear (and hopefully simple) way.  Also, the machine
code produced for Y must be fast enough to do job Y in an appropriate
amount of time.  Yes, I assume someone could write a space-shuttle
guidance package in Smalltalk-80, but if it runs too slowly, kiss
another shuttle good-bye... 

My starting point for a set of assessment criteria, is to try to
classify some of the common languages in (reasonable?) groups.

The languages I've used or read about seem to fall into about 5 distinctive
categories:  

a.  Homegrown:   FORTRAN', C', BASIC', FORTH'
b.  Algol:       Algol-60, Pascal', Modula
c.  Functional:  Lisp', Scheme, APL
d.  Monsters:    Algol-68, PL/1, Ada'
e.  Others:      Smalltalk, SNOBOL'

(For reference, I've only written programs in the languages listed
with a '.  I trust that partisans of each language will correct any
misperceptions I may have of _their_ fave :) .)

Each of the five classes have certain properties:

The homegrown (Made in the USA) languages represent in a fairly simple
and direct way, the underlying architecture of the machines upon which
 they are conceptually based.  Thus, producing efficient code for
these languages is a relatively straightforward (though non-trivial)
task.

("BASIC? Efficient? Hah!"  --true, degenerate BASICs like IBM BASICA
are not paragons of efficiency; the version of Dartmouth BASIC I first
learned to program with (HP 2000 Level F, c. 1980), seemed to cook
right along, though...)

The Algol family represent a more scientific-, and less engineering-oriented
approach to programming.  These languages appear to have been
_designed_, rather than simply glued together.

The functional languages represent programming as a mathematical discipline.
As such, they are more orthogonal and are syntactically simpler than
(a) or (b) above.

The monsters are, well... languages in which every useful feature was thrown in
except the kitchen sink; and in Ada, it looks like even that was
included.  These are large languages which seem difficult to use because of
  1) difficult-to-predict feature interaction (PL/1),
  2) orthogonality taken to its (logical? illogical?) extreme (Algol-68), 
and
  3) sheer humungousness (Ada).

And the others are languages that represent directions in software application
that seem different from all the rest.

I don't agree with some of the design decisions embodied in some
of the languages listed above, but I do have a keen appreciation for
the sorts of compromises language designers have made.  My
question to you is, how do -you- classify different languages, and
assess their relative value for a particular application?

Lou Glassy

;;standard-disclaimers-etc