Re: PL/I Versus Ada (Was: Arianne ...)

[tonyk@sseos.lbl.gov (Tony Konashenok)]

In article <3225E4D3.6F5992E1@microware.com>, "Lon D. Gowen, Ph.D." <gowen@microware.com> writes
$! Richard Riehle wrote:
$! >   Well you may have your own idea of object-oriented programming.
$! >   We usually think of encapsulated classes which support extensible
$! >   inheritance, dynamic binding, and polymorphism.  We ordinarily do not
$! >   consider the heroic efforts of a star programmer as being sufficient
$! >   to implement the method.  There are specific, widely-accepted criteria
$! >   for object-oriented programming which are not language-specific.

$! A coder can do OOP without
$! using an OOP language such as C++, Ada 95, etc. (see "Software Engineering"
$! by Ian Sommerville, which is a well-known text on SE ideas).  However,
$! using an OOP language does make the coding of an OOD easier.

Exactly my point! See below.

!$ One of the big (supposed) benifits and one of the most important
$! components of OOD/OOP is this idea of data abstraction.  All languages
$! (even assembly languages) can support data abstraction (and, therefore,
$! functional abstraction too).  Additionally, there are various levels of
$! data abstraction (e.g., all high-level languages--HLLs--use simple data
$! abstractions such as their builtin abilities to manipulate integers,
$! reals, strings, etc.).

I would add to this that a human being (assuming that a programmer is
human) also has certain capabilities of data abstraction [s]he uses in
writing code, and it had better be matched by the programming language.
What I assert here is that PL/I has the abstraction capacities roughly
equivalent to those of human thinking; furthermore, it operates the same
syntactic categories as most humans. Therefore, it is very intuitive.
If you look at meta-languages used here and there to facilitate the
description of logic flow, most of them are very much like PL/I. Not Ada.
Not C++. Oh well, BNF is indeed closer to Ada, but hardly anyone uses
it for intuitive explanations.
Even if one needs greater degree of abstraction, it is always possible to
formulate this abstraction once using the traditional syntactic constructs,
include it in your code, and then reuse it as you please. Just like writing
your own macros in assembly code. PL/I, by the way, has certain features
to help implement object-orientation. GENERIC comes to mind.

$! OOP uses the ideas of data abstraction; and data abstraction, by definition,
$! includes encapsulation (i.e., the ability to group data or operations into
$! separate syntactic containers), functional abstraction, and sometimes
$! information hiding.  There are various groups of OOPLs, which we can break
$! up into two main groups:  pure OOPLs (e.g., smalltalk and Eiffel) and
$! hybrid OOPLs (e.g., C++ and Ada 95).  Generally speaking, an OOPL has the
$! following "features":  data abstraction, inheritance, and a particular
$! type of dynamic binding (i.e., a kind of polymorphism).  The purpose of
$! inheritance is to facilitate the reuse of abstract data types (ADTs).  And,
$! reuse is supposedly beneficial to software development efforts.  Therefore,
$! the big attraction to OOP is through the supposed improvements of ADTs,
$! dynamic binding of requests, and inheritance.

It is certainly true that object-oriented languages afford a greater freedom
of operation with abstract data types. However, excessive use of these does 
not contribute much to comprehensibility of the code. It is an unfortunate
trend in modern programming that writing code is delegated to less and less
qualified people, and many think that the goal is to make writing of code
as simple as it can possibly be. Therefore, many features being promoted are
often an umbrella for quick-and-dirty or, worse yet, too-sloppy-to-think-
it-over approach to coding. Mind you, I have nothing against quick programming
as long as it works, but way too often it leads to an outright hogging of
computing resources, in the style of "toss your old hardware" Windows 95.
Yes, hardware is becoming cheaper and faster, but I, for one, do not have
the money to plunk for a new Pentium. Sorry, I digress...

Tony "Assembler programmers drive stick shifts" Konashenok
Team PL/I