Re: Is Ada likely to survive ?

[ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe)]

Brian Rogoff <bpr@shellx.best.com> writes:

>On 5 Aug 1997, Richard A. O'Keefe wrote:
>> Let's face it, before Prolog there _was_ no "logic programming paradigm".

>Irrelevant,

Well, *I* think it's relevant, or I wouldn't have written it.

>and arguably false.

So *argue* it.  You _could_ talk about AbSys/AbSet, but it was only
_retrospectively_ that they were described as logic programming languages.

>Even if one accepts that that paradigm
>began with Prolog that doesn't mean one should have to identify Prolog with
>the logic programming paradigm. 

Attacking a proposition no-one advanced is not a good way to argue.
It remains true that for practical purposes, the "logic programming
paradigm" began with (Marseilles) Prolog, and to the extent that
interest has left Prolog, it is to the extent and for the reason that
there are now _better_ logic programming languages there.

>> I don't *want* people "developing the Ada paradigm" (and there
>> _is_ an Ada paradigm distinct from the "imperative" paradigm in
> 
>I disagree with this. If there is an "Ada paradigm", distinct from 
>CLU, Modula-X, Oberon, Theta, etc., then it becomes *meaningless* to 
>talk about "paradigms" distinct from programming languages. Perhaps 
>if you said what you believe the "Ada paradigm" is, I would change 
>my mind. 

A paradigm is simply a mindset, and is sometimes set forth in a rationale.
I know nothing about Theta, or Modula-X (I do know Modula, Modula-2, and
Modula-3, and have reference material for the latter two handy).  I have
read most of the Oberon-related PhD theses and have the "Project Oberon"
book in front of me right now (three hand-spans away, about a hand-span
up and to the right).  The Oberon paradigm is "multum in parvo", "don't
put it in unless you can't do without".  It's an imperative language,
but the mindset is *importantly* different from the Pascal mindset.
There is, for example, an Oberon *system*, and the language wasn't really
designed to be separate from the system.  Fundamentally, I think the
Oberon paradigm is something like "if you can't describe the whole thing
to someone, redesign and simplify it until you can".  The Ada paradigm is
"make it possible to build things no one human being can ever master, and
add whatever you have to (carefully) so that they _can_ delimit and master
the bits they need."  Ada and Oberon have almost opposite approaches to
interfaces, for example.  The Oberon approach minimises the amount of
redundancy.  This makes an already small system smaller.  The Ada approach
uses redundancy in a controlled way, with the aim of limiting the amount
of the system you need to read.

I'm not talking about micro-level paradigms (are there boxes you can alter
the contents of, is the basic language extension a command, a function, or
a relation) but a level further up, about what kind of components you want
to make a software system out of and how you connect them.  Where are the
child packages in Oberon?  Where are the generics?  On the other hand,
where is the dynamic loading of modules in Ada?

>> general) in a hundred different directions.  All this development
>> of the paradigm is great for filling the shelves with PhDs, but
>> lousy for people who actually want to *use* the wretched thing.

>Some development is great for users. Anna and Larch like tools, for 
>example, which require no changes to the base language, would be quite  
>useful. I believe that you are interpeting "extensions" as being 
>"incompatible language changes" which is not entirely what I had in 
>mind. 

I regard Anna and Larch as *tools* not *extensions*, but we are in
vehement agreement that they would be lovely things to have.

-- 
Four policemen playing jazz on an up escalator in the railway station.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.