Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!bu-cs!bloom-beacon!primerd!hollin!ds
From: ds@hollin.prime.com
Newsgroups: comp.lang.misc
Subject: Changes in Programming Languages
Message-ID: <26600001@hollin>
Date: 16 Oct 89 22:03:00 GMT
Lines: 49
Nf-ID: #N:hollin:26600001:000:2610
Nf-From: hollin.prime.com!ds    Oct 16 18:03:00 1989


A Position Paper
- -------- -----

I believe that programming languages should change little once they are in
widespread use, to encourage portability and programmer productivity.  This
implies that languages should be designed carefully and "shaken out" by alpha
and beta testing prior to release as is done for most real-world software
products.  This can be done formally, as was the case with Ada, or informally,
as was the case with Forth.

Allowing languages to change a lot (as is seen in the Cobol 85 and Fortran 8X
standards efforts) encourages each language to pick up all the semantics of
the others, plus more.  In effect, each language becomes a syntactic variant
of the current "universal language" that PL/I used to represent, and this set
of target semantics keeps getting more complicated.

I would love to see Fortran returned to a simplicity intermediate between
FORTRAN II and FORTRAN IV (with all the ugly stuff retained, so dusty decks
could still be compiled), and new languages designed for vector operations and
other such semantic improvements.

I am in favor of language extensions that make a language more consistent with
its design philosophy or better suited to its users' purposes, but I oppose
extensions that do not fit its design philosophy or that address the needs of
only a very few users.  IMHO, many of the current standards efforts violate
one or both of these principles.

I believe that there is room for a large number of languages, both because new
languages bring us improved expressive power and because certain languages are
best suited for specific applications (Basic and LOGO for beginners; Forth for
programming peripherals and in other small-memory environments; Prolog for
reasoning over a knowledge database; Lisp for list manipulation; SNOBOL, awk,
and Icon for string manipulation; PL/I and Ada for accurate and/or precise
arithmetic calculations, etc.).

I believe that there is much to improve in both the syntax and semantics of
our programming languages.  We should use new languages as the vehicle for
experimenting with such improvements in most cases, not merely tacking them
onto an existing favorite language.  As people play with Eiffel, Edison,
Euler, Y, Miranda, and the hundreds of other new and sometimes obscure
programming languages they will gradually discover the best language features
to use in the various programming environments.  Avoiding incompatible
language extensions is an important tool in achieving progress while
minimizing its negative impact.

David Spector
Prime Computer, Inc.
ds@primerd.prime.com (until the layoff)