icsu8209@caesar.cs.montana.edu (Glassy) (02/05/90)
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-etcbillwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (02/05/90)
From icsu8209@caesar.cs.montana.edu (Glassy): > large languages which seem difficult to use because of > 3) sheer humungousness (Ada). You want a BIG language? Try COBOL with its 500 or so keywords; Ada only has 63. By the way, studies have shown (CACM, I forget the exact issue) that there is practically nothing that can be directly trimmed from Ada 83 without fundamentally weakening its capabilities. However, there will probably be a consolidation of the concepts of package and task into the single concept of an object, either in this revision (Ada 9X) or the next. Bill Wolfe, wtwolfe@hubcap.clemson.edu
kers@hplb.hpl.hp.com (Kers) (02/05/90)
William Thomas Wolfe writes: From icsu8209@caesar.cs.montana.edu (Glassy): > large languages which seem difficult to use because of > 3) sheer humungousness (Ada). You want a BIG language? Try COBOL with its 500 or so keywords; Ada only has 63. Surely we're beyond assuming that the number of "keywords" in a language is any real measure of its "size"? For a (contrived) example, suppose that I have two languages. One has the enormous total of twenty words; each work is a complete utterance in itself. The other has just four words: jack, jill, pail, and crown. But utterances are all of the form ((jack | jill)* pail)* crown A denotational semantics exists mapping all utterances in this languages to usefully distinct meanings. (Unfortuately, the semantics is too large to fit into the margin of this page.) Which language is "bigger"?
hankd@pur-ee.UUCP (Hank Dietz) (02/05/90)
In article <3069@caesar.cs.montana.edu> icsu8209@caesar.cs.montana.edu (Glassy) writes: >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). ... >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 :) .) I classify languages based on the types of programs they were designed to implement... the following is a QUICKIE PARTIAL LIST. Notice that some languages appear in more than one group. (I've also marked languages I've actually used with a tick suffix.) I'm curious if others generally agree with my list: Teaching languages: (Simple, fast-compile because student programs usually don't get any further than that, only one programming idiom to force good programming style, often has friendly graphics) Pascal', Karel', RatFor', various language subsets introduced in textbooks -- especially data structure/algorithm textbooks, Smalltalk', Logo' Prototyping: (For testing/defining algorithms, highly interactive, inefficient execution in many cases due to high-level primitives) BASIC', Lisp', Prolog', APL', SetL', CSP', FP', Id' Numerical applications: ForTran', other languages also called "Fortran" (;-), Sisal', APL' String/text processing: (Text manipulation, pattern/image orientation) CoBOL', SNOBOL', Awk', sed', Teco', Emacs (any version)', Lisp', Prolog' General purpose: (Usually big languages with many alternative idioms, synthesized as best from other languages, usually merging numerical and string processing, e.g., ForTran and CoBOL) Algol', PL/I', Ada', Scheme' (and other "efficient" Lisp dialects ;-) Systems: (Support for large program development and maintenance, efficient execution, low-Level HW access) BLISS, BCPL, B, C', C++', PL/M', Ada', Modula (pick any number ;-), various assembly languages AI: (Artificial intelligence languages... really symbol-oriented) Lisp', Prolog', SAIL', OPS5 CAI: (Computer-Aided Instruction) Pilot', Plato', PILE' Mathematical exploration: (Tools for numeric visualization and/or symbolic transformation) Macsyma, MuMath', IGL', NGL', Lotus, any language with a name ending in "calc" Control of automatic test equipment: Gaelic, Atlas' Query languages: (The database/dictionary is THE data/knowledge structure) DBase, Ingres, SEQUEL, Forth', MUMPS, Prolog', OPS5 Asynchronous parallelism: (Typically associated with MIMD execution) CSP', Occam', Linda, Concurrent C', Euclid Synchronous parallelism: (Typically associated with SIMD execution) Glypnir, Actus, Parallel C', C*', *Lisp SPMD parallelism: (Single program, multiple data -- multiple paths through same code) PL/I', Ada', The Force', EPEX', BBN Uniform System, XPC', PCF Fortran Languages designed for automatic parallelization: (Language constructs to help flow analysis for parallelization) Refined Languages (Refined C, Fortran, Pascal, and Lisp)', Blaze', Sisal' -hankd@ecn.purdue.edu