Re: Grammar for future languages (2)

"Jacco van Muiswinkel" <jaccom@knoware.nl> writes:
>Lets cautiously analyse what "the world" wants from a programming
>language.
>
>1. Reliable code
>2. Readable sources
>3. No hassles
>4. Short development time
>5. Portable code
>
  <<SNIP>>


O.K. This is good, but it is also old hat. Even if some language
proposed or existing scored very high on the above desiderata, the
"world" might or might not adopt it or even know about it.


In my opinion, the more relevant question is "How does the world want
to compute?" Once this is answered, and there will certainly be more
than one answer to that question, the design of a programming
language flows from


      1) The model of computing chosen or assumed,
      2) The current level of technology available to
            implement such a model,
      3) The mentioned desiderata of Jacco (and more),
      4) The cultural readiness of some segment (sub-culture) of
            the computing community to embrace, or at least to
            adopt the computing model.
      5) The general availability of a decent implementation at
            a "ripe" time for (4).


To validate this, consider the four points above in
relation to:


        a) The Algol family of languages,
        b) Old model commercial languages, (COBOL, RPG, ...)
        c) Newer model commercial languages "4 GL" (DBASE, PowerBase, ...)
        d) APL and related array-theoretic languages, such as Nial,
        e) The BCPL family of languages such as C, C++.
        f) The Lisp family (Lisp, ML, Scheme ...)


For example, APL was adopted because of the computing model it
offered, a model of computing in which Algol-60 would have been
next to useless. The fact that is was and is well-nigh a "write-
once" "read-never" language was not and is not particularly
relevant. It was adopted, because a particular sub-culture
in computing was fascinated by the mathematical formalism of
the APL notation (me too!,) and the computing model of interactive
dynamic numeric computation, with a permanent workspace state was
eminently useful. So the language was suitable to the computing model,
it was available, and people who did numerical research, and had
the access to IBM 360 computing centers on weekends were able to
use the implementation that was available.




In the case of Modula-3, the language features assume that the
computing model is the "stand-alone" large scale networked
workstation system, with separate compilation, linking of compiled
modules with linkage editors, manipulating data that is described to
a compiler, but these descriptions are discarded during the
compilation process, and programs are developed by multi-person teams
on a long-time scale.


Modula-3 addresses itself to the problems of such an environment,
i.e. dealing with binary tupe consistency on a ntework, limiting the
propogation of data structure descriptions across program modules,
etc.


Insofar as it is successful, Modula-3 is contributing to the
evolution of the large scale networked computing model. Of course,
information- hiding under this model of computing and is very
important.


Now consider Oberon, which is a very similar language to Modula-3,
but designed from the premise of a very different model of computing.
The consequence of this different model of computing, is that many of
the "good" and "innovative" features of Modula-3, are as relevant to
the kind of programs that the Oberon model of computing would
encourage or require. So you can't really compare these closely
related languages by evaluating language features, rather, you have
to ask "which is the desirable model of computing?", and "what
computing sub-cultures are ready to adopt this model?"


In my opinion, I would like to see more discussion on the kinds of
computing environments (models) that are possible/desirable,
how language features relate to these models, and what kinds of
computing model a language (say M-3) is or is not suitable for.


I would like to see less discussion on where a semicolon should or
should not go, or if the keywords set is well chosen, or whether
late-binding of methods are a help or a hindrance.




-------------------------------------------------------------
Parzival Herzog . email: ariadne@mbnet.mb.ca .
Five Doves Software Inc. . .
Winnipeg MB Canada . .
--

Return to the comp.compilers page.
Search the comp.compilers archives again.