Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!arclight.uoregon.edu!enews.sgi.com!news.xtra.co.nz!news.mel.connect.com.au!news.netspace.net.au!not-for-mail
From: "Coby Beck" <cb...@mercury.bc.ca>
Newsgroups: comp.lang.lisp
Subject: Re: CLOS is hard. Let's go shopping  (Was Re: Lisp in Python)
Date: Tue, 15 Oct 2002 08:45:59 +1100
Organization: Netspace Internet
Lines: 56
Message-ID: <aofdtr$1op$1@otis.netspace.net.au>
References: <pan.2002.09.24.02.42.59.437455.20476@debian-rs.org> <kw8z1sdj00.fsf@merced.netfonds.no> <Sf6k9.264268$5r1.11134744@bin5.nnrp.aus1.giganews.com> <y6c65wu5fjl.fsf@octagon.valis.nyu.edu> <87adm5q5uc.fsf@fbigm.here> <ouyy99psxw9.fsf@panix3.panix.com> <3D921A59.4187DEB9@motorola.com> <q5rfzvxvm11.fsf@hector.lesours> <3241980399066215@naggum.no> <uv6hegdzjml.fsf@suspiria.ai.mit.edu> <87it0tio6n.fsf@acm.org> <uv6vg4r9nyd.fsf@suspiria.ai.mit.edu> <ey3wup5yt99.fsf@cley.com> <uv64rc8ppn8.fsf@suspiria.ai.mit.edu> <3D978406.7080609@nyc.rr.com> <uv6u1jpbwxh.fsf@suspiria.ai.mit.edu> <ey38z118hej.fsf@cley.com> <uv6it0558c1.fsf@suspiria.ai.mit.edu> <3DAAEAE7.50207@web.de> <uv61y6t564o.fsf@suspiria.ai.mit.edu>
NNTP-Posting-Host: thesoftwaresmith.com.au
X-Trace: otis.netspace.net.au 1034631932 1817 210.15.192.190 (14 Oct 2002 21:45:32 GMT)
X-Complaints-To: usenet@otis.netspace.net.au
NNTP-Posting-Date: Mon, 14 Oct 2002 21:45:32 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000


"Jeremy H. Brown" <jhbr...@ai.mit.edu> wrote in message
news:uv61y6t564o.fsf@suspiria.ai.mit.edu...
> Pascal Costanza <costa...@web.de> writes:
> > This is an example where you are in deep trouble! The following will
> > produce a compile-time error and Java provides no way of dealing with
> > this situation.
> >
> > public class myClass implements intFromVendorA, intFromVendorB {
> > }
> >
> > Of course, this is an exceptional situation and doesn't occur too
> > often in practice - but when it occurs you have lost...
>
> Honestly, I'd guess this type of situation happens more often than
> confusing situations in CLOS.  There are two distinctions I'd make:
>
> a) this isn't complicated in the way that CLOS MI prediction is
>    complicated; it's a simpler corner case.
> b) "when it occurs you have lost" is, of course, not a sentence you
>    have to say as often WRT to CLOS due to its greater flexibility.
>
> So maybe you've just identified one of the key simplicity-vs.-power
> issues that make it easier to "master" Java than CLOS: whenever
> something potentially confusing comes up, Java simply says "you can't
> do that", while CLOS provides a mechanism (a perhaps
> necessarily-complex one) for managing the situation.

I think you are touching here on a guiding principle in the design of lisp:
freedom and flexibility over simplicity and safety[1]  Where other languages
avoid difficult problems lisp addresses them and IMO does so with only the
complexity that is necessary to define the problem precisely.  But really
this should not be any problem whatsoever for anyone who does not really
want that freedom - just don't use it.  But when the day comes and you need
it, lo and behold it is there!

I can't tell you how many times that has happened to me as I learn more and
more lisp, some quirky seeming syntax or extra keyword agrument to a
function I never understood and never investigated is suddenly exactly what
I needed.  That is a great feeling for me when programming.  As for CLOS,
like the rest, just use as little or as much as you need.  If as you say,
you must thouroughly understand something before you are comfortable using
it then bite the bullet and put in the effort!

As for "mastery" well, its not easy to define and who cares anyway and my
philosophy is that when you need to use it, there is little difference
between knowing it by heart and knowing how to find out quickly.  Memorizing
dusty corners is not, by and large, an efficient use of brain cells.

--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")

[1] safety in terms of not letting the programmer get themself in trouble