Message from discussion CLOS is hard. Let's go shopping (Was Re: Lisp in Python)
From: Pascal Costanza <costa...@web.de>
Subject: Re: CLOS is hard. Let's go shopping (Was Re: Lisp in Python)
Date: Mon, 14 Oct 2002 17:53:59 +0200
Organization: RHRZ - University of Bonn (Germany)
References: <email@example.com> <firstname.lastname@example.org> <Sf6k9.email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <3D921A59.4187DEB9@motorola.com> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <3D978406.firstname.lastname@example.org> <email@example.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Trace: f1node01.rhrz.uni-bonn.de 1034610839 29618 22.214.171.124 (14 Oct 2002 15:53:59 GMT)
NNTP-Posting-Date: 14 Oct 2002 15:53:59 GMT
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: de-de, de, en-us, en
Jeremy H. Brown wrote:
>>Sorry, but the CLOS features you described as complex seem pretty
>>straightforward to most of us.
> The followup discussion to your post suggests that many people here
> --- actually including yourself --- agree that predicting the
> precedence list in MI situations can be difficult. (The particular
> examples that I ran into comes from Winston & Horn's book "Lisp", 3rd
> edition. I'll append it to this post for the entertainment of the
Hm, generally I think you are right insofar newbies perceive CLOS as
very complex when they look at it as a whole. However, I don't think you
can rightfully conclude that (part of) CLOS is difficult. I just think
that newbies are overwhelmed by the amount of features, and that they
most probably confuse their feelings with a perceived complexity that
doesn't exist in reality - but that can be solved for example by reading
a good tutorial that explains the features in the right order.
> My assumption in my initial post was that claiming language mastery
> implied that one had good intuition not just for the basics of the
> language, but also for the corner cases.
I have never seen any single language that doesn't have "dark corners".
Even a conceptually very simple language like Oberon has problematic
issues that their designers have overlooked for a long time. And that is
a language whose definition spans just a few pages.
You should not judge a language by the way it deals with exceptional
cases; you should not do so just because they are exceptions. You can
judge a language by its regular behavior, and what options a language
provides in case its view on how to resolve exceptional cases conflicts
with your view on how it should be done.
The real power of Common Lisp lies in the fact that for almost all
issues you can think of that might arise you can find a workaround on
your own by exploiting the many hooks that Common Lisp provides.
Especially, the many features of CLOS exist for exactly that reason.
For example, after having studied method combinations in CLOS for a few
days, I was able to come up with my own method combination that
simulates the various Java method call mechanisms, and it was a breeze
after I have understood the essential idea - this is real power! I
wouldn't even think about doing this in other OOP languages I know so
far (except, perhaps, for Smalltalk which I don't know in detail).
>>>PS Is Erik Naggum always so full of poisonous bile?
>>No, it depends on the article, and given your sloppy piece I think he
>>showed admirable restraint.
> Actually, several people, again including yourself, politely pointed
> out what they considered to be the limitations of my post. Erik was
> the only one who felt the need to be belligerent and rude in his
> initial response, and I called him on it.
You should perhaps take into account that Erik always intends to give
statements about the actual contents of your (or anyone else's) posts,
and not statements about you (or anyone else) as a person. I don't think
he always succeeds in doing so, but that's his actual intent. His
initial response _can_ be interpreted according to his stated intent.
> Anyhow, here are some potentially-confusing class precedence examples
> paraphrased from Winston and Horn's "Lisp", 3rd edition.
My conjecture is that you can provide confusing examples for any language.
Would you agree?
Pascal Costanza University of Bonn
mailto:costa...@web.de Institute of Computer Science III
http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)