[WARNING: the author of this little post will take great
exception with anyone who construes the following text as an invitation
to a language war.]
I've seen Flavors' use in Genera (the Symbolics "OS") held up
as a great example of Object Oriented Design. Are there any similarly
complex systems being used that have been written in CLOS (apart from
CLOS itself that is)?
I have Symbolics manuals from both the message passing days and
the generic methods/functions days. I think the OOPy interface to the
window system was nice-ish.
Another question I have is motivated by comments by Henry Baker
(ftp://ftp.netcom.com/pub/hb/hbaker/CritLisp.html) and by some ideas from
Gabriel (http://www.ai.mit.edu/articles/good-news/subsection3.3.6.html).
They both insist, without justification, that OOP support is a sensible
and basic thing to add to a language. I'm not quite sure I buy this.
For example, I largely view C++ as a way to protect yourself from armies
of indifferent programmers. I've used classes as a convenient way to
bundle things up, but is this really more than sugar?
I guess my larger question is "Is OOP anything more than
syntactic sugar to make good programmer's jobs a bit easier?" C++
doesn't make a bad C programmer a good programmer (any more than Lisp
will, either). And OOPing up a language introduces all sorts of problems
for the language implementer (especially with respect to method dispatch
for generic methods and inheritance trees). When I first heard about
"Object Oriented Programming" everyone was all ga-ga over it, but
when I got to it I didn't quite see what all the excitement was about.
Then I thought it was ok. Now I find I don't quite see the point again.
I guess I just think there's got to be some better way.
I'd also be interested in knowing if anyone is working on the
"Next Generation" lisp envisioned in both Baker's and Gabriel's
papers. I've been thinking of doing the same thing myself.
As I said above, this isn't an attempt to start a flame, so let's
NOT get into "My language can beat up your language" arguments, please.
My kill file is big enough as it is. I'm just interested in other
people's (POLITE) thoughts on the matter.
--
William S. Annis Programmer
Ofc: 608 262-6163 ·······@neurosim.wisc.edu
Department of Neurology Neurosimulation Lab
In article <···········@news.doit.wisc.edu>, ·······@neurosim.wisc.edu wrote:
> I've seen Flavors' use in Genera (the Symbolics "OS") held up
> as a great example of Object Oriented Design. Are there any similarly
> complex systems being used that have been written in CLOS (apart from
> CLOS itself that is)?
Sure, for an interesting design see CLIM (and Silica). Newer
Common Lisp stuff on stock hardware is CLOS-based. For example
the complete UI code for Macintosh Common Lisp is written with CLOS.
Still, good CLOS-based design is not common. Good design
is tough. It is about finding the right abstractions and
having a language that can express them. We have to deal
with complexity and so we might need to develop tools
that helps us dealing with complexity.
There is a certain CLOS style. You can see it in CLOS itself.
The excellent book "The Art of the Metaobject Protocol"
is also a first class book which introduces object-oriented
design with CLOS.
Many times you will see imperative designs with later added
object layers. In Common Lisp you can go the opposite way.
At the core you have objects and classes. This framework
is extensible and might even expose its implementation.
At a higher level you have functions - functions that
simplify using the framework and will hide you from details.
We are now at a level where we are talking about objects
and common *tasks*. The third level introduces syntactic
forms that capture common usage patterns.
CLOS works this way:
1) make-instance 'standard-class
2) ensure-class
3) defclass
CLIM is another example for this design. Instead of defining
high-level object-oriented interfaces on top
of traditional imperative code, CLIM is radically objects
down to the core. OOP makes CLIM flexible. But the
higher-level makes it usable with macros
like WITH-OUTPUT-AS-PRESENTATION.
> when I got to it I didn't quite see what all the excitement was about.
> Then I thought it was ok. Now I find I don't quite see the point again.
> I guess I just think there's got to be some better way.
Well, Common Lisp is a multi-paradigm language (like C++) but
with the capability of integrating the different paradigms
into one larger system. This flexibility make it
so easy to come up with domain specific languages. The CLOS
designers sure had a hard time to design an OOP-extension
that brings the experimentation phase to an end. There
were many OOP extensions for Lisp. The trick was cool:
Build an extensible object system. You need a language
for "configuration". Why not start with CLOS?
You can get very far in Common Lisp without OOP. Very far.
The key to this is the power of macros and functions. CLOS adds
classes with inheritance and generic functions with
method combination. Now we can deal at a language level
with a greater complexity level (still we need more
development tools to make efficient use of it -
browsers are just the beginning - reuse is currently
to hard). CLIM is the extension
of domain objects into the area of user interface programming.
Instead of dealing with special objects that implement
the user interface, the programmer works on domain
objects. Presentation types, PRESENT and ACCEPT are
the keys to that.
But there are different paradigms available.
Prototype-based OOP reuses objects by delegation.
Even more exotic are logic-based extensions
like LOOM or CLASSIC. These offer additional capabilities
like automatic classification and the answering
of queries. In many ways these are more advanced
then what we are currently using. But they are even
more difficult to learn than Common Lisp and CLOS
alone.
But one thing is clear, we are beginning to see
books that can explain the power of macros -
but we have yet to see a book that introduces
the Common Lisp Object System to the programmers
and users. Available books (although excellent) don't
cover large scale OOP design in Common Lisp with
real world examples. There is no book about programming
user interfaces in CLIM. There is no book how
to develop object-oriented 3d graphics in CLOS.
There is no book that describe how to design and extend
an advanced web server in CLOS.
You have to study the source code! You have to read
the manuals!
Rainer Joswig
From: William Paul Vrotney
Subject: Re: OOP, Flavors and CLOS: or What's the big deal?
Date:
Message-ID: <vrotneyE2K62E.BnK@netcom.com>
In article <···········@news.doit.wisc.edu> ·······@brain (William Annis) writes:
>
> [WARNING: the author of this little post will take great
> exception with anyone who construes the following text as an invitation
> to a language war.]
>
> I've seen Flavors' use in Genera (the Symbolics "OS") held up
> as a great example of Object Oriented Design. Are there any similarly
> complex systems being used that have been written in CLOS (apart from
> CLOS itself that is)?
>
> I have Symbolics manuals from both the message passing days and
> the generic methods/functions days. I think the OOPy interface to the
> window system was nice-ish.
>
> Another question I have is motivated by comments by Henry Baker
> (ftp://ftp.netcom.com/pub/hb/hbaker/CritLisp.html) and by some ideas from
> Gabriel (http://www.ai.mit.edu/articles/good-news/subsection3.3.6.html).
> They both insist, without justification, that OOP support is a sensible
> and basic thing to add to a language. I'm not quite sure I buy this.
> For example, I largely view C++ as a way to protect yourself from armies
> of indifferent programmers. I've used classes as a convenient way to
> bundle things up, but is this really more than sugar?
>
> I guess my larger question is "Is OOP anything more than
> syntactic sugar to make good programmer's jobs a bit easier?" C++
> doesn't make a bad C programmer a good programmer (any more than Lisp
> will, either). And OOPing up a language introduces all sorts of problems
> for the language implementer (especially with respect to method dispatch
> for generic methods and inheritance trees). When I first heard about
> "Object Oriented Programming" everyone was all ga-ga over it, but
> when I got to it I didn't quite see what all the excitement was about.
> Then I thought it was ok. Now I find I don't quite see the point again.
> I guess I just think there's got to be some better way.
>
I don't know if there is a better way, but you are not alone in thinking
that OOP is much ado about almost nothing. For myself, the only real
significant application of OOP was in the NeXTSTEP operating system. If
this is in fact one of the greatest achievements of OOP then the fact that
NeXT died and NeXTSTEP is not doing that great says that the whole world
either does not appreciate the concept or can't afford it. NeXTSTEP uses
Objective-C.
The Symbolics Flavors of windows was OK but one had to learn a whole bunch
of stuff just to do some simple thing. The old INTERLISP window system was
just a few pages of function calls. Is was very quick and easy to
understand and use. And you could do whatever you needed with it. It
certainly makes you wonder why it was necessary to introduce something like
Flavors.
Lets look at the properties of OOP, they are
1. Inheritance
2. Encapsulation
3. Polymorphism
As I recall there are actually 5 properties, but I can't remember what the
other two are this late at night, perhaps someone can add the other two.
One definition of OOP languages is that procedure and data is replaced by
messages and objects. But objects traditionally, especially in Lisp, was
just another form of data and message passing in practically all OOP
languages reduces to a function call. So even this definition of OOP is
wanting.
As it turns out these properties are easy to simulate or even do pretty well
in Lisp without OOP. (2.) is easy to do without OOP; just the ordinary Lisp
struct has this property. (3.) is a given in Lisp lambda expressions. (1.)
can be simulated in many programming languages and in Common Lisp almost
duplicated without OOP. In Common Lisp you can "include" one struct in
another and get the effect of inheritance.
In C++, considered to be one of, if not the most popular OOP languages. As
for (2.) in C++ the same applies to C++ structs as Lisp structs. (3.) C++
doesn't do very well. Virtual functions are weak and C++ can not even
effectively do dynamic binding in all its glory. And even (1.) C++ does not
do very well. I've been told to avoid multiple inheritance in C++ since
there can occur problems with the layout of data.
The Meta Object Protocol, one of the greatest insights in OOP seems to be
largely ignored by most of the programming world. Smalltalk, hailed as the
most OO of OOP languages is considered by many as going overboard with the
idea. And Java, it's hard to tell where Java is headed these days.
One could look at OOP from another less gloomy perspective, like predict the
future of software ICs, or optimize implementations using MOP strategies.
But until some of this future magic happens in a big way one has to wonder.
--
William P. Vrotney - ·······@netcom.com
From: Kelly Murray
Subject: Re: OOP, Flavors and CLOS: or What's the big deal?
Date:
Message-ID: <599rsm$kj9@sparky.franz.com>
> I guess my larger question is "Is OOP anything more than
> syntactic sugar to make good programmer's jobs a bit easier?" C++
1. OOP is significantly more than just syntactic sugar.
2. CLOS is significantly more than other OO languages.
3. CLOS MOP is significantly more ... than anyone would want!
With inheritance, you can change the base class structure or behavior
and the changes are reflected to all other subclasses or derived classes.
This is difficult if not impossible to achieve without support from the
language itself in the form of some OO construct.
A) Lisp makes it relatively easy to define your own OO constructs.
CLOS goes way beyond this capability by allowing these changes
to occur at runtime while the program is running.
This is hard to do efficiently without very low-level
compiler support.
If you consider objects that have Persistence,
you will appreciate the considerable power OOP
and furthermore dynamic OOP gives.
Consider how hard would it be to change the date format
for something like a HTTP (webserver) access log
and the code that analyzes the log info for
1) a procedural language,
2) an OO language,
3) a dynamic OO language.
The MOP goes way beyond even this to allow changes
to the IMPLEMENTATION of the OOP system itself.
This is insane except to someone who wants to define their
own OOP system as a computer scientist.
Just build your own damn system then (see A above)
I say leave CLOS alone so the rest of the world
can understand and appreciate it!
-Kelly Murray ···@franz.com http://www.franz.com
From: Will Ware
Subject: Re: OOP, Flavors and CLOS: or What's the big deal?
Date:
Message-ID: <E2KB7M.5FM@world.std.com>
William Annis (·······@brain) wrote:
: ...invitation to a language war.]
Well here we go then:
: I guess my larger question is "Is OOP anything more than
: syntactic sugar to make good programmer's jobs a bit easier?"
The word "programmers" is plural, and the apostrophe should go
after the "s", i.e. "good programmers' jobs".
: When I first heard about
: "Object Oriented Programming" everyone was all ga-ga over it, but
: when I got to it I didn't quite see what all the excitement was about.
: Then I thought it was ok. Now I find I don't quite see the point again.
The big selling point was supposed to be that you could reuse source
code without rewriting it. Lots of people had lots of legacy code lying
around that seemed to work for its original intent, but when they tried
rewriting it for new applications, it usually broke. So C++ and other
OOP languages have a bag of tricks that's supposed to make any new code
reusable. One fairly cool thing that happened was that people saw they
could write large libraries of "base objects" that supplied most of the
functionality other people would want in their objects.
I've never made a big effort myself to write reusable code. Absent any
applicable experience, my impression is that the standard OOP ideas are
good, but you need to spend time planning carefully to use them well.
The publicity for OOP has certainly fizzled, I don't know if OOP itself
has done so. But C++ hype was displaced by Java hype, and Java also
claims to be an OOP language. I suspect that the rigors of writing really
reusable code are probably being widely ignored, partly due to ignorance
and laziness, but also because it takes thinking and planning, and lots
of programmers' jobs require them to throw stuff together too quickly.
The result is that there are few big OOP success stories.
--
-------------------------------------------------------------
Will Ware <·····@world.std.com> web <http://world.std.com/~wware/>
PGP fingerprint 45A8 722C D149 10CC F0CF 48FB 93BF 7289
[Will Ware]
> I've never made a big effort myself to write reusable code. Absent any
> applicable experience, my impression is that the standard OOP ideas are
> good, but you need to spend time planning carefully to use them well.
I think this is a very important point. An OO programming language
may arguably make it easier to write reusable code, but the buck stops
with the programmer: you have to make the effort, and if you don't
care enough to do the job right -- well, "real programmers can write
FORTRAN in any language".
My guess is that the programmer is more important than the language.
-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
In article <···········@news.doit.wisc.edu>, ·······@neurosim.wisc.edu wrote:
> I've seen Flavors' use in Genera (the Symbolics "OS") held up
>as a great example of Object Oriented Design. Are there any similarly
>complex systems being used that have been written in CLOS (apart from
>CLOS itself that is)?
I don't know offhand of any of the scale of Genera, but that's not to say
that they don't exist, but rather that I don't move and shake in circles
that use Lisp that much. I think perhaps the largest, most complex systems
that I tinker with in CLOS these days are CL-HTTP (a freely available HTTP
1.1 server written in Common Lisp) and LOOM (a _very_ nice
description-logics-based knowledge representation system, also written in
Common Lisp).
> Another question I have is motivated by comments by Henry Baker
>(ftp://ftp.netcom.com/pub/hb/hbaker/CritLisp.html) and by some ideas from
>Gabriel (http://www.ai.mit.edu/articles/good-news/subsection3.3.6.html).
>They both insist, without justification, that OOP support is a sensible
>and basic thing to add to a language. I'm not quite sure I buy this.
I would agree with Baker and Gabriel on the "sensible" point, but "basic"
seems easily debatable to me, given the difficulty of first marrying an
object model to whatever paradigm the language already supports (e.g.
imperative programming, logic programming, constraint satisfaction,
functional programming, etc. ad nauseam) and second addressing the
efficiency issues that are either inherent to the model (e.g. runtime
redefinition of a class lattice) or arise from the aforementioned marriage
(e.g. making generic functions efficient in marrying objects with a
functional language).
I suppose that my feeling that OOP support is "sensible" accrues from
several sources, but can, in its essence, be boiled down to two points:
1) It's helped me structure my own work, and
2) It's become a significant marketing point.
While you may blanch at my #2, consider the level of support available in
the C++ and Java markets (seminars, books, development tools, commercial
and free code libraries, etc.) Now consider whether those things would
exist if there weren't a _perceived viable market_ for those languages.
>For example, I largely view C++ as a way to protect yourself from armies
>of indifferent programmers. I've used classes as a convenient way to
>bundle things up, but is this really more than sugar?
This is the point at which I have to wonder how far you wish to extend your
argument/question. After all, isn't any "high-level" language just sugar, a
convenient way to bundle up a bunch of assembly language instructions?
Isn't an automatic transmission just sugar, a convenient way to bundle up a
bunch of gear shifts?
Incidentally, in the world of professional programming that I've been part
of for the past 15 years or so, "protecting yourself from armies of
indifferent programmers" is an _incredibly_ valuable thing to be able to
do, and if a tool or technique can demonstrate efficacy in that regard to
me, I can then justify expenditures easily double those that I can justify
merely on the basis of personal preference.
> I guess my larger question is "Is OOP anything more than
>syntactic sugar to make good programmer's jobs a bit easier?"
It depends largely, IMHO, upon how transparent the support is. The more
transparent, the more likely it seems to me that the language will directly
impact how you think about designing and implementing software--and, as
Alan Perlis once pointed out, "a programming language that doesn't change
the way you think about programming isn't worth learning."
>C++
>doesn't make a bad C programmer a good programmer (any more than Lisp
>will, either). And OOPing up a language introduces all sorts of problems
>for the language implementer (especially with respect to method dispatch
>for generic methods and inheritance trees). When I first heard about
>"Object Oriented Programming" everyone was all ga-ga over it, but
>when I got to it I didn't quite see what all the excitement was about.
>Then I thought it was ok. Now I find I don't quite see the point again.
>I guess I just think there's got to be some better way.
For certain (perhaps even many) problem domains, there are any number of
better ways. I don't think it's an accident that the language that many
people regard as the great-granddaddy of all object-oriented languages,
Simula, had a clear focus on creating simulations, and that Simula's direct
conceptual descendant, Smalltalk, was also documented in
increasingly-complex terms culminating in the construction of a simulation.
At its core, object-oriented programming is a fantastic way to think
about--well--objects, and their properties and behaviors and what happens
when you toss a bunch of them in the same place at the same time. And yes,
the concepts have evolved over time. In particular, a lot of people seem to
be realizing that consistency of interface to an object--sometimes referred
to as "protocol"-- is important. The distributed object people, such as the
Object Management Group and the Java folks, especially seem to realize
this.
> I'd also be interested in knowing if anyone is working on the
>"Next Generation" lisp envisioned in both Baker's and Gabriel's
>papers. I've been thinking of doing the same thing myself.
I used to think that Dylan was it, but of course, it suffered from being
identified with Lisp in any fashion, and from Apple's lack of willingness
to allocate their implementation the resources that it needed in order to
deliver on its promises.
> As I said above, this isn't an attempt to start a flame, so let's
>NOT get into "My language can beat up your language" arguments, please.
>My kill file is big enough as it is. I'm just interested in other
>people's (POLITE) thoughts on the matter.
Hopefully this qualifies. Equally hopefully I can express my vague
puzzlement at your question, my sense of "of course it's sugar at some
level; isn't everything?" without seeming inflamatory.
>--
>William S. Annis Programmer
>Ofc: 608 262-6163 ·······@neurosim.wisc.edu
>Department of Neurology Neurosimulation Lab
--
Paul Snively "In other words--and this is the rock-solid
Macintosh and AI Codesmith principle on which the whole of the
·····@chelsea.ios.com Corporation's Galaxywide success is founded--
their fundamental design flaws are completely
hidden by their superficial design flaws."
-- Douglas Adams
-----BEGIN PGP PUBLIC KEY BLOCK-----BY SAFEMAIL-----
Version: 1.0b4
mQBPAzJueSYAAAECAKlnh2CHtDLbRHGpY8BYoMExIyV5BnVRhAEG7ek2Odp09AZB
YAS43fJngVdEPLXb3zApuRyKmrpUMIhiF3KhCOEAEQEAAbABh7QkUGF1bCBTbml2
ZWx5IDxjaGV3eUBjaGVsc2VhLmlvcy5jb20+sAED
=ER+w
-----END PGP PUBLIC KEY BLOCK-----
In article <···········@news.doit.wisc.edu>, ·······@neurosim.wisc.edu wrote:
>From: ·······@brain (William Annis)
> I've seen Flavors' use in Genera (the Symbolics "OS") held up
>as a great example of Object Oriented Design. Are there any similarly
>complex systems being used that have been written in CLOS (apart from
>CLOS itself that is)?
CLIM (Common Lisp Interface Manager) is written in CLOS, and makes use of the
features of CLOS at every level. I've never used it in more than a cursory
manner, but I've heard many people say that it's very elegant and expressive.
> Another question I have is motivated by comments by Henry Baker
>(ftp://ftp.netcom.com/pub/hb/hbaker/CritLisp.html) and by some ideas from
>Gabriel (http://www.ai.mit.edu/articles/good-news/subsection3.3.6.html).
>They both insist, without justification, that OOP support is a sensible
>and basic thing to add to a language. I'm not quite sure I buy this.
>For example, I largely view C++ as a way to protect yourself from armies
>of indifferent programmers. I've used classes as a convenient way to
>bundle things up, but is this really more than sugar?
Is anything above assembly language really anything more that just layer
upon layer of sugar? From a CLOS perspective, I view OOP as a boon to
programming more abstractly, and as a time-saver. Anything you do with class
and GFs you could do yourself with defstructs and functions - you'd just have
to do more work yourself.
I think it is a very sensible thing to have in a language, but I disagree that
it has to be a basic part of any language. I do think, however, that if a
language is going to support an object system, it should do so from the start,
or be designed very carefully if it is added later. C++ suffers in many ways
from being grafted on top of C, with the requirement of maintaining
much compatibility with C.
Dylan is a nice language which integrates OOP support as a basic part of
the language, and I think it does it very nicely.
> I'd also be interested in knowing if anyone is working on the
>"Next Generation" lisp envisioned in both Baker's and Gabriel's
>papers. I've been thinking of doing the same thing myself.
Dylan could have been it, if not for Apple's indifference. I think any new
Lisp standard will need to move in a direction away from Common Lisp, i.e.
away from becoming a huge, monolithic language. The
small-core-language-with-rich-libraries approach that Dylan took makes much
more sense in the current age of component technology.
> As I said above, this isn't an attempt to start a flame, so let's
>NOT get into "My language can beat up your language" arguments, please.
>My kill file is big enough as it is. I'm just interested in other
>people's (POLITE) thoughts on the matter.
Languages are all just tools - use which ever one fits. Like any tools, some
do one job better than others, and some are more enjoyable to use than others.
-Adam
From: Adam Alpern
Subject: Re: OOP, Flavors and CLOS: or What's the big deal?
Date:
Message-ID: <32b9b5c2.686550747@news>
On 16 Dec 1996 19:11:58 GMT, ·······@brain (William Annis) wrote:
> I've seen Flavors' use in Genera (the Symbolics "OS") held up
>as a great example of Object Oriented Design. Are there any similarly
>complex systems being used that have been written in CLOS (apart from
>CLOS itself that is)?
CLIM (the Common Lisp Interface Manger) is written entirely in CLOS,
and makes use of it at every level. I've never used it in more than a
cursory manner, but I've heard many people say that it's very elegant
and expressive. Not as complex as an OS, but there aren't anymore
LISP-based OS's anymore (except for OpenGenera).
> Another question I have is motivated by comments by Henry Baker
>(ftp://ftp.netcom.com/pub/hb/hbaker/CritLisp.html) and by some ideas from
>Gabriel (http://www.ai.mit.edu/articles/good-news/subsection3.3.6.html).
>They both insist, without justification, that OOP support is a sensible
>and basic thing to add to a language. I'm not quite sure I buy this.
>For example, I largely view C++ as a way to protect yourself from armies
>of indifferent programmers. I've used classes as a convenient way to
>bundle things up, but is this really more than sugar?
Is anything above the level of assembler really anything more than
layer upon layer of sugar? I view OOP support as a time-saver, and a
boon to programming more abstractly. When the language supports data
hiding and encapsulation, like C++, I also view it as a layer of
protection, as you do.
I think it's certainly a "sensible" thing to do, to add OOP support to
a language. I don't think it needs to be basic though - OOP can go too
far, abstracting every little thing into a class. That road ultimately
leads to *more* complex programs (I've seen it happen several times
with neophyte C++ programmers).
I do think, however, that if a language is going to support OOP, every
attempt should be made to integrate it seemlessly with the language.
In the case of Dylan, this meant designing a language that was
thoroughly object-oriented from the very start.
> I'd also be interested in knowing if anyone is working on the
>"Next Generation" lisp envisioned in both Baker's and Gabriel's
>papers. I've been thinking of doing the same thing myself.
Dylan could have been it, if not for Apple's indifference and
misdirection.
> As I said above, this isn't an attempt to start a flame, so let's
>NOT get into "My language can beat up your language" arguments, please.
>My kill file is big enough as it is. I'm just interested in other
>people's (POLITE) thoughts on the matter.
I hope this qualifies. I view programming languages as tools to get
things done - some are better than others at some tasks, worse at
others. That's probably why most people who've been programming for a
while know several. I know 2 languages thorougly (LISP/CLOS and C/C++)
and use them daily, and I dabble in a 1/2 dozen others.
-Adam
From: Chris Bitmead
Subject: Re: OOP, Flavors and CLOS: or What's the big deal?
Date:
Message-ID: <m3k9qd88vz.fsf@thepla.net>
·······@brain (William Annis) writes:
> I guess my larger question is "Is OOP anything more than
> syntactic sugar to make good programmer's jobs a bit easier?" C++
> doesn't make a bad C programmer a good programmer (any more than Lisp
> will, either). And OOPing up a language introduces all sorts of problems
> for the language implementer (especially with respect to method dispatch
> for generic methods and inheritance trees). When I first heard about
> "Object Oriented Programming" everyone was all ga-ga over it, but
> when I got to it I didn't quite see what all the excitement was about.
> Then I thought it was ok. Now I find I don't quite see the point again.
> I guess I just think there's got to be some better way.
As a lisp programmer I can perhaps understand why you wouldn't
immediately see the usefulness of OOP, since you may be used to
functional programming. But even so, consider the lisp statement
"(write something)". This is fundamentally OO, because write works for
any type of object. This is basicly what OO is all about, and it's an
important part of any good language, lisp included.