Object-Oriented Programming != Holy Grail

More in the ongoing "I have seen the future, and it is
object-oriented" debate. But first, a word from our sponsor:


>[Gentle readers: try and keep your flames tasteful. I have to say that
>most of the complaints about Lisp seem a little out of date -- modern
>Scheme systems have static typing, good compilers, etc. -John]


In article 91-11-066 Bob Hathaway writes:
>Yes, my opinion is biased towards the OO paradigm, but so is the
>programming language community, in my opinion. Look at the books, the new
>software engineering methodologies, the latest trends, all point to
>object-oriented. I am a programming languages 'person' and after covering
>the field, OO beats all other existing methodologies in almost every
>respect, and if it doesn't, I can just add it as a new OO feature.


Depending on what you mean by "just adding it as a new OO feature,"
this is either vacuous or erroneous. If you mean that anything someone can
do with his wiz-bang new language, you can do also, that is obvious: any
programming language worth its salt is Turing-equivalent, so in that
respect, OO-languages are no different than non-OO-languages. If you mean
that adding object-oriented features to <insert-favorite-Algol 60-derivative
here> will put to rest all programming issues, I think you're being silly.
For example:


>If it exists in the real world, it exists in the object-oriented one too
>(really want a formal pattern matcher, implement a proglog object).


Well, that's exactly the problem: what would a good logic-
programming "object" (i.e., language) look like? What sort of "messages"
(i.e., programs) should it accept? How should its methods operate? (I.e.,
how do I implement it?)


>Functional programming solves mathematical problems in a clean way. Is
>this general purpose? No, it leaves out simple statement sequences and
>and only allows single (constant) assignments, this has yet to be shown
>that it can solve even simple problems (i.e. violates every software
>engineering principle I can think of except provable code), let alone
>complex ones (just ask a functional programmer if they would like to
>bootstrap their compiler, they'll tell you they wrote it in C and it will
>stay that way (unless they upgrade to C++)).


This tells me that you know very little about functional
programming. For example, consider ML, one of the more interesting
languages of the more "functional" character. The New Jersey/SML compiler,
developed by AT&T and available via ftp from "princeton.edu" and
"research.att.com", is a boot-strapped C-to-ML compiler; the actual ML
compiler is written in ML. So yes, bootstrapped functional language
compilers exist.


ML has expressions that write to and read from a mutable store; this
is the notion of "assignment" to a "variable" that you refer to, above.
Sequencing is also not incompatible with functional programming. Although
it is not actually implemented this way, we could introduce sequencing into
ML via the "function" named ";", in the following manner:


fun ; (a, b) = b


infix ;


Then the expression "e1 ; e2" is really a function call to ";" which
simply returns its second argument. The infix notation is a mere syntactic
convenience. So we see that statement sequencing isn't really the
imperative notion people usually consider.


ML's exception-handling mechanism (similar to Common Lisp's "throw" and
"catch" forms) are more advanced than anything I've seen from the object-
oriented community, although this form of exception-handling is not incomp-
atible with an object-oriented paradigm.


As far as "software engineering principles" goes, I see no reason to
consider today's programming methodology a bed of Procrustes to which all
new programming languages must be made to fit. New tools obviously demand
new methods of use.


>How about LISP based systems (boy do I expect it here): Are they general
>purpose? Not really, they are interpreted and run several hundred times
>slower than compiled code (although this could change). They usually
>don't have static typing, so you have no choice, dynamic typing or naught.
>They have an unnatural syntax, big violation here. Recently, they claim
>to have 'Multi-Methods' and claim they are more powerful than method
>passing in traditional OO. But, these are just function calls at
>run-time, and their system works at run-time, so what are they really? you
>guessed it, function calls! If you add dynamic typing to C++ guess what
>you get when you invoke a function dynamically??? This is not better than
>object-oriented message passing, in fact, this is a joke. As far as other
>nice features of Lisp based (OO) languages, functional, logic, etc., just
>identify them, if they're useful we can add them to almost any programming
>language. Want logic-style pattern matching, type inferencing, user
>defined control-structures, meta-level access, just ask or provide, don't
>go to something really weird(unusable).


This tells me that you know very little about Lisp. Lisp compilers
have been around since the mid-Seventies, and are readily available today.
In fact, some Lisp systems (like most Scheme implementations I've seen) run
interactively by incrementally compiling the user's input. (BTW, New
Jersey/SML does this as well). As far as complaining about "function calls
at run time," I prefer that my functions are called at run time as opposed
to compile time; that's called "program execution." :-)


I think what you are really complaining about is some sort of
run-time function-binding. But this is exactly what happens when you pass a
message to an object in a traditional OO language: at run time, you decide
what sort of object instance you're passing the message to, look in the
class/method table, and call the appropriate function. It's instructive to
note that this process can be implemented exactly, with no performance
penalty, directly in C; this is why some C++ systems are simply C preproces-
sors. In that respect, object-oriented programming is nothing more than
some syntactic sugar for a well-established programming technique, just as
functional programming and logic programming are.


>Standard 3rd generation programming (by CS reconning) falls apart when
>large or complex systems are involved, and incremental improvements
>for abstraction and reuse (etc.) to solve these problems often go by
>another name, yes, you guessed it, Object-Oriented! In fact if we add
>up all of the new facilities we would like to add to existing programming
>languages, this is also a common definition of object-oriented programming.
>I think its pretty easy to defend future directions of programming languages
>and compilers as object-oriented, if that is its very definition. And if
>object-oriented programming languages are what we need to write compilers
>for, then we as compiler writers have a good direction to focus on (I also
>think this is a good direction to focus hardware and systems on too).
>And for a last word, I've worked with and seen quite a few compilers and
>am well aware of their strong and weak points, and the weakest,
>most bug-ridden, maintenance nightmarish point (Don't ever do this) is:
> They Were All Data Structure Oriented:
> Lack of encapsulation: unstructured, indescriminant, and undocumented
> access to primary data structures.
> Solution to 97% of all compiler related bugs and problems(by my best guess):
> Encapsulation as provided by object-oriented programs.


This is reminds me of the snake-oil that AI researchers have been
peddling for years: "This latest, greatest, up-to-datest AI paradigm will
solve all our problems, and bring on the Utopia!"


Let's get serious for a moment here. Object-oriented programming is
very nice, and is the appropriate approach to many problems. It is not,
however, the last word in language design. Many important programming
language problems remain.
--

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