I just wrote the title of this post and realized that I am in for a
major mess. Anyway, here is the story.
I gave two talks about CL in a seminar at NYU. They went pretty well,
especially the first one (macros and macro-characters can do miracles
to dazzle an unsuspecting audience). The second one raised one
controversial point and one not so controversial one. I'd like to get
an opinion on these issues from the people reading this message.
Question 1.
One of the things I like the most in CLOS is that slot
names are paramount. You do not have to mess around with 'class
qualifiers' to get the right slot from the right class. A couple of
people very keen on their "newly reinvented wheel avec forced
indentation rules" said that CLOS behavior is as ambiguous as in their
"new round shape". I must say that I did not have a convincing answer
(i.e. I am perfectly at ease with myself, but I could not find a good
argument at the time).
Question 2.
The separation between generic functions and classes puzzled people to
no end. Although the power of multimethods was evident during the
talk, a second issue was brought up that kind of made sense to me.
From a certain point of view, it *does* make sense to couple methods
with classes, since this buys you some "organizational" effect which
may turn out to be of use in certain contexts.
So, since I am usually better at posing questions than answer them,
there they are. I'd appreciate comments about this issues.
Cheers
--
Marco Antoniotti =============================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
From: Russell Senior
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <86pugu5ghv.fsf@coulee.tdb.com>
>>>>> "Marco" == Marco Antoniotti <·······@cs.nyu.edu> writes:
Marco> Question 2. The separation between generic functions and
Marco> classes puzzled people to no end. Although the power of
Marco> multimethods was evident during the talk, a second issue was
Marco> brought up that kind of made sense to me. From a certain point
Marco> of view, it *does* make sense to couple methods with classes,
Marco> since this buys you some "organizational" effect which may turn
Marco> out to be of use in certain contexts.
Check out a paper by Giuseppe Castagna titled: ``Covariance and
contravariance: conflict without a cause''. It is available online
somewhere and is also included in an interesting book by the same guy:
_Object Oriented Programming, A Unified Foundation_, Birkhauser 1997.
--
Russell Senior ``The two chiefs turned to each other.
·······@aracnet.com Bellison uncorked a flood of horrible
profanity, which, translated meant, `This is
extremely unusual.' ''
From: Marco Antoniotti
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <y6c7l31md8o.fsf@octagon.mrl.nyu.edu>
Russell Senior <·······@aracnet.com> writes:
> >>>>> "Marco" == Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> Marco> Question 2. The separation between generic functions and
> Marco> classes puzzled people to no end. Although the power of
> Marco> multimethods was evident during the talk, a second issue was
> Marco> brought up that kind of made sense to me. From a certain point
> Marco> of view, it *does* make sense to couple methods with classes,
> Marco> since this buys you some "organizational" effect which may turn
> Marco> out to be of use in certain contexts.
>
> Check out a paper by Giuseppe Castagna titled: ``Covariance and
> contravariance: conflict without a cause''. It is available online
> somewhere and is also included in an interesting book by the same guy:
> _Object Oriented Programming, A Unified Foundation_, Birkhauser 1997.
>
Thanks for the pointer. However the argument in the discussion I
reported were of a much more mundane variety. :)
Cheers
--
Marco Antoniotti =============================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
From: Rob Warnock
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <960irh$2tpj0$1@fido.engr.sgi.com>
Russell Senior <·······@aracnet.com> wrote:
+---------------
| Check out a paper by Giuseppe Castagna titled: ``Covariance and
| contravariance: conflict without a cause''. It is available online
| somewhere...
+---------------
<URL:http://www.dmi.ens.fr/~castagna/pub.html> lists his papers,
including that one:
G. Castagna. "Covariance and contravariance: conflict
without a cause." ACM TOPLAS 17(3):431-447, March 1995.
Abstract: <URL:http://www.dmi.ens.fr/~castagna/abstr.html#cov>
PostScript: <URL:ftp://ftp.ens.fr/pub/dmi/users/castagna/covariance.ps.Z>
-Rob
-----
Rob Warnock, 31-2-510 ····@sgi.com
SGI Network Engineering <URL:http://reality.sgi.com/rpw3/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
In article <···············@octagon.mrl.nyu.edu>, Marco Antoniotti
<·······@cs.nyu.edu> wrote:
> I just wrote the title of this post and realized that I am in for a
> major mess. Anyway, here is the story.
>
> I gave two talks about CL in a seminar at NYU. They went pretty well,
> especially the first one (macros and macro-characters can do miracles
> to dazzle an unsuspecting audience). The second one raised one
> controversial point and one not so controversial one. I'd like to get
> an opinion on these issues from the people reading this message.
>
> Question 1.
> One of the things I like the most in CLOS is that slot
> names are paramount. You do not have to mess around with 'class
> qualifiers' to get the right slot from the right class. A couple of
> people very keen on their "newly reinvented wheel avec forced
> indentation rules" said that CLOS behavior is as ambiguous as in their
> "new round shape". I must say that I did not have a convincing answer
> (i.e. I am perfectly at ease with myself, but I could not find a good
> argument at the time).
I don't understand this question.
> Question 2.
> The separation between generic functions and classes puzzled people to
> no end. Although the power of multimethods was evident during the
> talk, a second issue was brought up that kind of made sense to me.
> From a certain point of view, it *does* make sense to couple methods
> with classes, since this buys you some "organizational" effect which
> may turn out to be of use in certain contexts.
The "only" organizational benefit you get is that
methods would be textual near (or inside) *their* classes.
If methods are defined outside (which is true for
several object-systems) the benefit is not anymore there.
I'd say this is just an issue of the development
environment and what options you have to browse
methods and classes. You can query the Lisp system
to give the necessary information.
On the Lisp machine I'd just do:
Command: Show Class Methods CLIM:SHEET :Direct Yes
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
From: Tim Bradshaw
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <ey3elxa2o6i.fsf@cley.com>
* Rainer Joswig wrote:
> The "only" organizational benefit you get is that
> methods would be textual near (or inside) *their* classes.
> If methods are defined outside (which is true for
> several object-systems) the benefit is not anymore there.
I think there's a catastrophic disadvantage as well: a class and its
methods define all the functionality that class can ever have. If you
want to define more functionality you have to subclass. Imagine, for
instance you are writing an inspector, or a system to ship objects
over a network, which will be added to an existing system: how do you
do this if you don't have the sources to the original system? Even if
you *do* have the sources, you have to go in and basically spuriously
modify the definitions of all the classes you care about. Horrible.
--tim
In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
wrote:
> * Rainer Joswig wrote:
> > The "only" organizational benefit you get is that
> > methods would be textual near (or inside) *their* classes.
> > If methods are defined outside (which is true for
> > several object-systems) the benefit is not anymore there.
>
> I think there's a catastrophic disadvantage as well: a class and its
> methods define all the functionality that class can ever have. If you
> want to define more functionality you have to subclass. Imagine, for
> instance you are writing an inspector, or a system to ship objects
> over a network, which will be added to an existing system: how do you
> do this if you don't have the sources to the original system? Even if
> you *do* have the sources, you have to go in and basically spuriously
> modify the definitions of all the classes you care about. Horrible.
I agree fully. I think this is a big disadvantage.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
From: glauber
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <95skqv$cfp$1@nnrp1.deja.com>
In article <···············@cley.com>,
Tim Bradshaw <···@cley.com> wrote:
> * Rainer Joswig wrote:
> > The "only" organizational benefit you get is that
> > methods would be textual near (or inside) *their* classes.
> > If methods are defined outside (which is true for
> > several object-systems) the benefit is not anymore there.
>
> I think there's a catastrophic disadvantage as well: a class and its
> methods define all the functionality that class can ever have. If you
> want to define more functionality you have to subclass. Imagine, for
> instance you are writing an inspector, or a system to ship objects
> over a network, which will be added to an existing system: how do you
> do this if you don't have the sources to the original system? Even if
> you *do* have the sources, you have to go in and basically spuriously
> modify the definitions of all the classes you care about. Horrible.
Well, if the original classes were designed right, you shouldn't have to
modify their source code in order to sublass them. Or, closer to the truth,
if your modifications are within the scope that the developer of the original
classes decided to allow you to make, then you don't have to modify (or even
have) the source code.
However, i agree with you, Lisp's way is much more flexible.
--
Glauber Ribeiro
··········@my-deja.com http://www.myvehiclehistoryreport.com
"Opinions stated are my own and not representative of Experian"
Sent via Deja.com
http://www.deja.com/
From: Barry Margolin
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <cUkg6.38$z55.1732@burlma1-snr2>
In article <············@nnrp1.deja.com>,
glauber <··········@my-deja.com> wrote:
>Well, if the original classes were designed right, you shouldn't have to
>modify their source code in order to sublass them. Or, closer to the truth,
>if your modifications are within the scope that the developer of the original
>classes decided to allow you to make, then you don't have to modify (or even
>have) the source code.
He wasn't talking about modifying the class, he was talking about adding
*new* functionality. For instance, suppose there's a class of graphical
objects, and you want to add a method for computing the area of the
objects.
With typical OO systems, you'd either have to define an ordinary function
that takes the object as a parameter and then dispatches on the type by
itself, or define a subclass of each class that adds the area method. In
CLOS, you can simply add your own methods to existing classes. The package
system can be used to avoid collisions when different applications each try
to add their own methods to classes that they all use.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
>>>>"BM" == Barry Margolin schrieb am Wed, 07 Feb 2001 23:30:16 GMT:
BM> He wasn't talking about modifying the class, he was talking about
BM> adding *new* functionality. For instance, suppose there's a
BM> class of graphical objects, and you want to add a method for
BM> computing the area of the objects.
I think Tim is right, it's a bound-and-discipline-thing. I guess most
of the puzzled people Marco was referring to would count "adding new
functionality" as modifying (the behaviour of) the class.
Another source of confusion might be that on first glance the
multi-dispatch methods of CLOS look much like ordinary functions,
especially with the decoupling of the methods from the class.
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"If you're so special, when why aren't you dead?"
-- Breeders, "I Just Wanna Get Along"
From: Tim Bradshaw
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <ey3ae7y2b5i.fsf@cley.com>
* glauber wrote:
> Well, if the original classes were designed right, you shouldn't have to
> modify their source code in order to sublass them. Or, closer to the truth,
> if your modifications are within the scope that the developer of the original
> classes decided to allow you to make, then you don't have to modify (or even
> have) the source code.
The point is that I don't want to have to modify the definitions of
the classes -- I may not even know what their definitions *are*, and I
certainly do not want so subclass them. I just want to write some
methods which specialise on the existing classes so they can partake
in some new protocol.
--tim
"glauber" <··········@my-deja.com> wrote in message
·················@nnrp1.deja.com...
> Well, if the original classes were designed right, you shouldn't have to
> modify their source code in order to sublass them. Or, closer to the
truth,
> if your modifications are within the scope that the developer of the
original
> classes decided to allow you to make, then you don't have to modify (or
even
> have) the source code.
Well, I've always thought omniscient prescience was an extremely useful
attribute for a designer, too. It's a shame that we can't seem to find many
designers that have this attribute :-).
> However, i agree with you, Lisp's way is much more flexible.
It's not only more flexible, it allows you do bypass a lot of the coding
that is needed to make sure that the classes were "designed right". In
order to do something like Tim's inspector example "right" in Java or C++,
you'd have to dispatch the inspection of internals back to the inspected
object. This assumes that one wants to inherit some sort of "Inspectable"
interface into the inspected object's class (not necessarily desirable if
you had a small object, so it is unlikely that you'd be able to ever have a
C++ designer allow you to inspect a Point, for instance). In addition, if
you wanted to load (or update) new object types dynamically, you'd have to
have the machinery to all each object to return a ref to it's Inspectable
interface. All-in-all, a lot of extra code hassle to go through for
something that could be taken care of in Lisp by just supplying another
method. In programming, small is indeed beautiful and so it's not only
flexibility that Lisp helps you with...
faa
From: Michael Livshin
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <s3d7cuuq3w.fsf@bigfoot.com.cmm>
Tim Bradshaw <···@cley.com> writes:
> * Rainer Joswig wrote:
> > The "only" organizational benefit you get is that
> > methods would be textual near (or inside) *their* classes.
> > If methods are defined outside (which is true for
> > several object-systems) the benefit is not anymore there.
>
> I think there's a catastrophic disadvantage as well: a class and its
> methods define all the functionality that class can ever have. If you
> want to define more functionality you have to subclass.
there are class-based OO languages that don't have this limitation.
two examples I know of are Tom and E.
multiple dispatch is still very nice, though.
--
(only legal replies to this address are accepted)
Portions of this broadcast have been prerecorded.
From: Tim Bradshaw
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <ey366im2axo.fsf@cley.com>
* Michael Livshin wrote:
> there are class-based OO languages that don't have this limitation.
> two examples I know of are Tom and E.
> multiple dispatch is still very nice, though.
Yes, I don't think this is a multiple dispatch issue, although clearly
a language with multiple dispatch makes the everything-in-the-class
idea impossible, rather it's a bondage-and-discipline issue -- this is
*my* class, I made it and *you* aren't going to corrupt its precious
bodily fluids by defining your filthy methods on it, oh no.
--tim
From: Lars Lundb�ck
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <3A83978F.679DFAC9@era.ericsson.se>
Tim Bradshaw wrote:
> *my* class, I made it and *you* aren't going to corrupt its precious
> bodily fluids by defining your filthy methods on it, oh no.
>
Enjoyed the film?
From: Pierre R. Mai
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <871yt84845.fsf@orion.bln.pmsf.de>
"Lars Lundbäck" <·············@era.ericsson.se> writes:
> Tim Bradshaw wrote:
>
> > *my* class, I made it and *you* aren't going to corrupt its precious
> > bodily fluids by defining your filthy methods on it, oh no.
> >
>
> Enjoyed the film?
"You can't fight in the war room!"
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
From: Tim Bradshaw
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <nkjofwcdou9.fsf@tfeb.org>
"Lars Lundb�ck" <·············@era.ericsson.se> writes:
> Enjoyed the film?
Many times. Not as good as A matter of Life and Death though...
From: Kent M Pitman
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <sfwy9v6904h.fsf@world.std.com>
Tim Bradshaw <···@cley.com> writes:
> [... in systems that bundle methods and classes ... ] a class and its
> methods define all the functionality that class can ever have. If you
> want to define more functionality you have to subclass.
I think there's also a philosophical issue (hence the subject line for
this thread, i guess) which is whether behavior is always intrinsic to
an object.
I got into a big argument with someone a long time ago at the first
meeting of x3h7, an ansi group trying to standardize some oo
behaviors. The person was insisting that all behavior in the world
must be packaged within a class. I asked whether that means a rock's
behavior is best described by the creator of class rock. It sure
seems to me that there are lots of things I can do to rocks that are
not primitive to rockness. Big rocks I can use them as tables and
chairs. Small rocks I can throw. On and on. It's plain that there
are abstract actions (like "throw") which are not going to be defined
primitively on rocks and yet that will want to be done with rocks.
Consider, too, integers. Suppose I add a float class later. Surely
integer will include no methods anticipating floats. Or maybe float was
added first, and integer later. Neither can really anticipate the other.
Yet there will be operations on both that need to be done.
You can, of course, lock your object system and say that functions on
rocks must necessarily use a different kind of dispatching for arguments
like this than for primitive objects. But that just needlesesly complicates
the world--two different dispatch systems to accomodate a philosophical
unbendingness by people who refuse to acknowledge the truth about the world,
which is that some actions come too late for proper packaging.
Some things are simply true of the universe and no amount of insistence
by language designers will beat them back. The Scheme community often
rails against the use of dynamic variables, talking about how they inhibit
good parallelism, slowing down context switches, ec. But in the end, there
are things in the world that need dynamic state and if you don't put the
support for dynamic state into the language, the user will be doomed to
insert it into his/her program. At that point, of course, it will be opaque
to the compiler because users have many ways to write something when they
are "implementing" (rather than "expressing") an idea.
For things that you can reasonably anticipate that most typical users of
a system will need (and I daresay dispatch on types from outside the
type definition is among this set), I think it's best for the core system
to specify a way to talk about this because then the core system can optimize
the compilation, and users can all use an easily recognizable notation that
they share in commmon.
Kent M. Pitman writes:
> I asked whether that means a rock's
>behavior is best described by the creator of class rock. It sure
>seems to me that there are lots of things I can do to rocks that are
>not primitive to rockness. Big rocks I can use them as tables and
>chairs. Small rocks I can throw. On and on. It's plain that there
>are abstract actions (like "throw") which are not going to be defined
>primitively on rocks and yet that will want to be done with rocks.
>
>Consider, too, integers. Suppose I add a float class later. Surely
>integer will include no methods anticipating floats. Or maybe float was
>added first, and integer later. Neither can really anticipate the other.
>Yet there will be operations on both that need to be done.
An OO zealot would say that rocks should be defined as a subclass of
material object. The ability to use something as a table or to throw it
would be defined in the material object (let's call it Thing, to avoid
overloading the word "object") class. Of course the method use-as-table
would have to generate an exception if the thing wasn't at least a little flat.
I don't think it's always practical to think of all the superclasses ahead of
time, so I'm not an OO zealot. But I do think an omniscient observer
would find it a convenient way to describe the world.
From: Howard Stearns
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <3A8D5AD2.216B2559@curl.com>
In the method-table world, who own's the commutative binary methods
named "winner" between the classes rock, paper and scissors?
How does "objects own their behavior" apply here?
[answer: it doesn't. Unless maybe you want to define a subclass of
Material called RockPaperScissor that owns all the methods. In this
case, you'd better be omniscient about new players or new games, and
you'd better have multiple inheritance to support different sets of
players appearing in different combinations for different games.]
DvdAvins wrote:
>
> Kent M. Pitman writes:
>
> > I asked whether that means a rock's
> >behavior is best described by the creator of class rock. It sure
> >seems to me that there are lots of things I can do to rocks that are
> >not primitive to rockness. Big rocks I can use them as tables and
> >chairs. Small rocks I can throw. On and on. It's plain that there
> >are abstract actions (like "throw") which are not going to be defined
> >primitively on rocks and yet that will want to be done with rocks.
> >
> >Consider, too, integers. Suppose I add a float class later. Surely
> >integer will include no methods anticipating floats. Or maybe float was
> >added first, and integer later. Neither can really anticipate the other.
> >Yet there will be operations on both that need to be done.
>
> An OO zealot would say that rocks should be defined as a subclass of
> material object. The ability to use something as a table or to throw it
> would be defined in the material object (let's call it Thing, to avoid
> overloading the word "object") class. Of course the method use-as-table
> would have to generate an exception if the thing wasn't at least a little flat.
>
> I don't think it's always practical to think of all the superclasses ahead of
> time, so I'm not an OO zealot. But I do think an omniscient observer
> would find it a convenient way to describe the world.
Howard Stearns wrote:
>In the method-table world, who own's the commutative binary methods
>named "winner" between the classes rock, paper and scissors?
>
>How does "objects own their behavior" apply here?
Rocks, papers, and scissors are never inherrently winners. Games have winners.
The subclass of Game that is RockPaperScissors has variable Material1 and
Material2. RockPaperScissors also has a method for determining its winner based
on the class of Material1 and Material2. Other subclasses of Game will have
other methods for determining the winner.
From: Kent M Pitman
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <sfw3ddegtsq.fsf@world.std.com>
········@aol.com (DvdAvins) writes:
>
> Howard Stearns wrote:
>
> >In the method-table world, who own's the commutative binary methods
> >named "winner" between the classes rock, paper and scissors?
> >
> >How does "objects own their behavior" apply here?
>
> Rocks, papers, and scissors are never inherrently winners. Games
> have winners. The subclass of Game that is RockPaperScissors has
> variable Material1 and Material2. RockPaperScissors also has a
> method for determining its winner based on the class of Material1
> and Material2. Other subclasses of Game will have other methods for
> determining the winner.
Is it your position that this is more intuitive than the CL approach
of allowing the generic functions to sit outside and, if you'll pardon
the informal way of expressing it, simply saying the "obvious" thing.
From: Tim Bradshaw
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <ey3lmr6grbp.fsf@cley.com>
* Kent M Pitman wrote:
> ········@aol.com (DvdAvins) writes:
>>
>> Howard Stearns wrote:
>>
>> >In the method-table world, who own's the commutative binary methods
>> >named "winner" between the classes rock, paper and scissors?
>> >
>> >How does "objects own their behavior" apply here?
>>
>> Rocks, papers, and scissors are never inherrently winners. Games
>> have winners. The subclass of Game that is RockPaperScissors has
>> variable Material1 and Material2. RockPaperScissors also has a
>> method for determining its winner based on the class of Material1
>> and Material2. Other subclasses of Game will have other methods for
>> determining the winner.
> Is it your position that this is more intuitive than the CL approach
> of allowing the generic functions to sit outside and, if you'll pardon
> the informal way of expressing it, simply saying the "obvious" thing.
Ah but you misunderstand. The issue is not about intuition, it is
about *purity*. Purity is far more important than any human issue.
Languages that are pure are just inherently superior. It is far
better to use a pure functional language which expresses all temporal
operations in terms of monads -- a concept so obscure that it is
believed to only ever have been understood by three people -- because
you can *prove theorems* about monads whereas introducing impurities
like assignment means you can no longer prove theorems and thus all
programming is immediately impossible. Of course not even the three
people who understand monads have ever been able to write a program
using them which described any useful temporal behaviour, but that's
OK because there's a theorem that says it is in fact possible to do
this.
Also pure languages are simpler to implement, as everyone knows. All
that multiple inheritance / multiple dispatch, dynamic typing rubbish
leads to endless implementation complexities and of course makes it
hard to prove theorems about your programs, let alone, horrors, about
implementation correctness. If your implementation is not provably
correct what use is it to anyone? None at all, I suggest. I myself
use only languages implemented in the most rigorous fashion by
programmers -- we prefer to refer to them as computational theorists
-- who drink nothing but triple-distilled spring water.
Purity, Simplicity, Provability: let these be your watchwords, and let
us hear no more talk of `intuition' or `informality' or `obviousness':
these terms have no place in our pure new world of thought.
--tim
From: Thomas A. Russ
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <ymisnleqhw1.fsf@sevak.isi.edu>
ROTFL
Reminds me a bit of Doug Adams.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
From: Kent M Pitman
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <sfwbss2xjf1.fsf@world.std.com>
Tim Bradshaw <···@cley.com> writes:
> Also pure languages are simpler to implement, as everyone knows.
Languages are implemented only once, programs many times.
It amazes me that the community that is pushing all that purity is often
the one that does all that theoretical stuff. Can't they compute
the algorithmic complexity of a marketplace system that is optimized
for language production rather than language use. Sigh.
> Purity, Simplicity, Provability: let these be your watchwords, and let
> us hear no more talk of `intuition' or `informality' or `obviousness':
> these terms have no place in our pure new world of thought.
Once again, I think the problem those people are having is the foolish
assumption that there is something unscientific about intuition and
natural concepts and all that. That it's not rigorously specified does
not mean that somehow being concerned about its complexity is unimportant.
As I've said many times: small programming languages make for large
programs. Large programming languages make for small programs. Surely
an overgeneralization, but its purpose is merely to highlight the obvious
truth that if you start from nothing, you have more stuff to build before
you have something...
Bleah.
What REALLY steams me is that people take this definition of aesthetics
as self-obvious and make no attempt to survey the space of possible
aesthetic spaces and to show that this one is uniquely determined or even
most appropriate ... I think simplicity is good, but I'd apply it elsewhere
in the system. Just like the pressure/volume trade-off, I don't see how
you can both make life easy on the compiler writer AND also on the
programmer. I think they just like languages where they get to be the
implementors. Someone needs to go read "Crossing the Chasm" to understand
why I don't buy that as a plan for a growth market.
From: Marco Antoniotti
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <y6celwy154g.fsf@octagon.mrl.nyu.edu>
Kent M Pitman <······@world.std.com> writes:
...
>
> What REALLY steams me is that people take this definition of aesthetics
> as self-obvious and make no attempt to survey the space of possible
> aesthetic spaces and to show that this one is uniquely determined or even
> most appropriate ... I think simplicity is good, but I'd apply it elsewhere
> in the system. Just like the pressure/volume trade-off, I don't see how
> you can both make life easy on the compiler writer AND also on the
> programmer. I think they just like languages where they get to be the
> implementors. Someone needs to go read "Crossing the Chasm" to understand
> why I don't buy that as a plan for a growth market.
I read that. Interesting book and very well written.
How does it apply to Lisp, I do not know. Maybe only in the sense
that AI as a whole, never got to "whole product" status before
fizzling on "the market".
OTOH, why do I see shelves of books about the new wheel on the block
that forces you to indent rigidly, and has no usable concept of
statically bound variable, but not about CL?
It is time for deep brooding :{
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
From: Patrick Wray
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <59mj6.915$v4.40777@ozemail.com.au>
"Marco Antoniotti" <·······@cs.nyu.edu> wrote in message
····················@octagon.mrl.nyu.edu...
>
> OTOH, why do I see shelves of books about the new wheel on the block
> that forces you to indent rigidly, and has no usable concept of
> statically bound variable, but not about CL?
It didn't grow out of any abstract notions of purity that force programmers
to bend over backwards to get simple things done (like Scheme did). But at
the same time, it doesn't "feel" "impure" or cobbled together (like Perl or
C++ often do). It doesn't strive to be a world unto itself. It plays nicely
with native code, and it ports across operating systems without any hassle.
I'd rather see energy being spent on making CL better at the things Python
does well. But the popularity of Python isn't hard to understand. It offers
a nice combination of potency, practicality and simplicity - and it's not
ugly. So people like it.
From: Marco Antoniotti
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <y6c8zn5421w.fsf@octagon.mrl.nyu.edu>
"Patrick Wray" <······@my-deja.com> writes:
> "Marco Antoniotti" <·······@cs.nyu.edu> wrote in message
> ····················@octagon.mrl.nyu.edu...
> >
> > OTOH, why do I see shelves of books about the new wheel on the block
> > that forces you to indent rigidly, and has no usable concept of
> > statically bound variable, but not about CL?
>
> It didn't grow out of any abstract notions of purity that force programmers
> to bend over backwards to get simple things done (like Scheme did).
This is C.L.L. not comp.lang.scheme :)
> But at
> the same time, it doesn't "feel" "impure" or cobbled together (like Perl or
> C++ often do). It doesn't strive to be a world unto itself. It plays nicely
> with native code,
Common Lisp environment are expected to "produce" native code.
> and it ports across operating systems without any hassle.
>
> I'd rather see energy being spent on making CL better at the things Python
> does well.
What are the things that Python does well that CL doesn't do as well?
> But the popularity of Python isn't hard to understand. It offers
> a nice combination of potency, practicality and simplicity - and it's not
> ugly. So people like it.
Well.....
>>> x = 3
>>> x
3
>>> def f1():
... print x
...
>>> f1()
3
>>> def f2():
... print x
... x = 33
... print x
...
>>> f2()
Traceback (innermost last):
File "<stdin>", line 1, in ?
File "<stdin>", line 2, in f2
NameError: x
>>>
Need I say more?
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
From: Patrick Wray
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <tLDj6.1182$v4.55739@ozemail.com.au>
"Marco Antoniotti" <·······@cs.nyu.edu> wrote in message
····················@octagon.mrl.nyu.edu...
>
> "Patrick Wray" <······@my-deja.com> writes:
>
> This is C.L.L. not comp.lang.scheme :)
Speaking of scope, it's not comp.lang.python either ;-)
> > I'd rather see energy being spent on making CL better at the things
Python
> > does well.
>
> What are the things that Python does well that CL doesn't do as well?
At the language level, I don't think Python can teach Lisp anything. I was
thinking of the convenience of interacting with its environment, where
Python has a few advantages. (How much they're worth depends largely on
one's purpose).
> > But the popularity of Python isn't hard to understand. It offers
> > a nice combination of potency, practicality and simplicity - and it's
not
> > ugly. So people like it.
>
> Well.....
[demonstration of scope ambiguity in Python]
> Need I say more?
Dunno. I prefer to disambiguate scope in my own code, rather than let the
environment decide what I mean.
>>> class SomeScope:
... pass
...
>>> SomeScope.x = 3
>>> SomeScope.x
3
>>> def f1():
... print SomeScope.x
...
>>> f1()
3
>>> def f2():
... print SomeScope.x
... SomeScope.x = 33 # Did you want this?
... x = 'Now for something completely different!' # Or this?
... print x
... print SomeScope.x
...
>>> f2()
3
Now for something completely different!
33
>>>
From: Marco Antoniotti
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <y6celwuvifw.fsf@octagon.mrl.nyu.edu>
"Patrick Wray" <······@my-deja.com> writes:
> "Marco Antoniotti" <·······@cs.nyu.edu> wrote in message
> ····················@octagon.mrl.nyu.edu...
> >
> > "Patrick Wray" <······@my-deja.com> writes:
> >
> > This is C.L.L. not comp.lang.scheme :)
>
> Speaking of scope, it's not comp.lang.python either ;-)
>
> > > I'd rather see energy being spent on making CL better at the things
> Python
> > > does well.
> >
> > What are the things that Python does well that CL doesn't do as well?
>
> At the language level, I don't think Python can teach Lisp anything. I was
> thinking of the convenience of interacting with its environment, where
> Python has a few advantages. (How much they're worth depends largely on
> one's purpose).
>
> > > But the popularity of Python isn't hard to understand. It offers
> > > a nice combination of potency, practicality and simplicity - and it's
> not
> > > ugly. So people like it.
> >
> > Well.....
>
> [demonstration of scope ambiguity in Python]
>
> > Need I say more?
>
> Dunno. I prefer to disambiguate scope in my own code, rather than let the
> environment decide what I mean.
Meaning?
> >>> class SomeScope:
> ... pass
> ...
> >>> SomeScope.x = 3
> >>> SomeScope.x
> 3
> >>> def f1():
> ... print SomeScope.x
> ...
> >>> f1()
> 3
> >>> def f2():
> ... print SomeScope.x
> ... SomeScope.x = 33 # Did you want this?
> ... x = 'Now for something completely different!' # Or this?
> ... print x
> ... print SomeScope.x
> ...
> >>> f2()
> 3
> Now for something completely different!
> 33
> >>>
I rest my case
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
From: Patrick Wray
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <OOkk6.2229$v4.95280@ozemail.com.au>
"Marco Antoniotti" <·······@cs.nyu.edu> wrote in message
····················@octagon.mrl.nyu.edu...
>
> "Patrick Wray" <······@my-deja.com> writes:
>
> > Dunno. I prefer to disambiguate scope in my own code, rather than let
the
> > environment decide what I mean.
>
> Meaning?
When an assignment to a global variable inside a function creates and
initialises a local variable of the same name, and fools the language into
forgetting about the global one, it makes sense not to use globals without
wrapping them in some kind of namespace. (Most Python isn't written this way
though. Inside class scope, everything is referenced explicitly with "self"
but if you want to use procedural style, classes and modules can serve as
namespaces).
You're right, though. This is one of Python's warts. Its worst practical
consequence is not that it gets in the way of doing useful work, but that it
allows guys on usenet to point at it and say things like:
> I rest my case
Nothing further, your honour.
From: Johann Hibschman
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <mtzofhuciy.fsf@astron.berkeley.edu>
Patrick Wray writes:
> You're right, though. This is one of Python's warts. Its worst practical
> consequence is not that it gets in the way of doing useful work, but that it
> allows guys on usenet to point at it and say things like:
Thankfully, with Python 2.1, it has full lexical scoping.
--
Johann Hibschman ······@physics.berkeley.edu
From: Marco Antoniotti
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <y6c66i54aov.fsf@octagon.mrl.nyu.edu>
Johann Hibschman <······@physics.berkeley.edu> writes:
> Patrick Wray writes:
>
> > You're right, though. This is one of Python's warts. Its worst practical
> > consequence is not that it gets in the way of doing useful work, but that it
> > allows guys on usenet to point at it and say things like:
>
> Thankfully, with Python 2.1, it has full lexical scoping.
Cool. Let's keep reinventing the wheel.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
From: Dorai Sitaram
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <96ui38$9vm$1@news.gte.com>
In article <···············@octagon.mrl.nyu.edu>,
Marco Antoniotti <·······@cs.nyu.edu> wrote:
>
>Johann Hibschman <······@physics.berkeley.edu> writes:
>
>> Thankfully, with Python 2.1, it has full lexical scoping.
>
>Cool. Let's keep reinventing the wheel.
Let's not conveniently forget that Lisp
reinvented lexical scoping too. Lexical scoping makes
too much good sense for it to be avoided by a language
simply because some other language has it.
From: Marco Antoniotti
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <y6chf1oucgb.fsf@octagon.mrl.nyu.edu>
····@goldshoe.gte.com (Dorai Sitaram) writes:
> In article <···············@octagon.mrl.nyu.edu>,
> Marco Antoniotti <·······@cs.nyu.edu> wrote:
> >
> >Johann Hibschman <······@physics.berkeley.edu> writes:
> >
> >> Thankfully, with Python 2.1, it has full lexical scoping.
> >
> >Cool. Let's keep reinventing the wheel.
>
> Let's not conveniently forget that Lisp
> reinvented lexical scoping too.
True. But that was back in 1984.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
From: Kellom{ki Pertti
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <xfzy9v0ladv.fsf@arokyyhky.cs.tut.fi>
Marco Antoniotti <·······@cs.nyu.edu> writes:
> ····@goldshoe.gte.com (Dorai Sitaram) writes:
> > Let's not conveniently forget that Lisp
> > reinvented lexical scoping too.
> True. But that was back in 1984.
... when Lisp was in its mid-twenties or so? Based on that I would say
that the Python crowd is progressing rather faster.
--
Pertti Kellom�ki, Tampere Univ. of Technology, Software Systems Lab
From: Joe Marshall
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <u25odp1s.fsf@content-integrity.com>
Marco Antoniotti <·······@cs.nyu.edu> writes:
> ····@goldshoe.gte.com (Dorai Sitaram) writes:
> > Let's not conveniently forget that Lisp
> > reinvented lexical scoping too.
> True. But that was back in 1984.
Huh? Joel Moses discusses the issues of lexical scoping in
AI Memo 199, ``The Function of FUNCTION in LISP, or Why the Funarg
Problem Should be Called the Environment Problem'' which dates to
1970.
If I recall correctly, the MacLisp compiler used lexical scope (but
the interpreter used dynamic), and this convention remained until
Common Lisp decided to bite the bullet.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
From: Marco Antoniotti
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <y6cd7ccqb46.fsf@octagon.mrl.nyu.edu>
Joe Marshall <···@content-integrity.com> writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
> > ····@goldshoe.gte.com (Dorai Sitaram) writes:
> > > Let's not conveniently forget that Lisp
> > > reinvented lexical scoping too.
> > True. But that was back in 1984.
>
> Huh? Joel Moses discusses the issues of lexical scoping in
> AI Memo 199, ``The Function of FUNCTION in LISP, or Why the Funarg
> Problem Should be Called the Environment Problem'' which dates to
> 1970.
>
> If I recall correctly, the MacLisp compiler used lexical scope (but
> the interpreter used dynamic), and this convention remained until
> Common Lisp decided to bite the bullet.
Well, yes. I maliciously inferred that Dorai was referring to Scheme :)
CL "officially" bit the bullet with the publication of CLtL1
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
From: Kent M Pitman
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <sfwelwqg7m0.fsf@world.std.com>
Joe Marshall <···@content-integrity.com> writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
> > ····@goldshoe.gte.com (Dorai Sitaram) writes:
> > > Let's not conveniently forget that Lisp
> > > reinvented lexical scoping too.
> > True. But that was back in 1984.
>
> Huh? Joel Moses discusses the issues of lexical scoping in
> AI Memo 199, ``The Function of FUNCTION in LISP, or Why the Funarg
> Problem Should be Called the Environment Problem'' which dates to
> 1970.
>
> If I recall correctly, the MacLisp compiler used lexical scope (but
> the interpreter used dynamic), and this convention remained until
> Common Lisp decided to bite the bullet.
Yes, but I regard one of the key contributions of Steele and/or the
Common Lisp committee (not sure whose idea it was) when putting CLTL
together was to observe that having well-defined semantics in a Lispy
world of mixed compiled and uncompiled stuff meant you couldn't be
depending on knowing whether something is interpreted or compiled.
Further, although the compiler was not dynamically scoped, I've never
been comfortable with calling it lexically scoped. The way we always
used to talk about it was just that the "specialness" was compiled
away. However, LAMBDA did not create lexical closures; you had to use
*FUNCTION instead of FUNCTION if you wanted pseudo-closures, and it
was easy to trick *FUNCTION into doing the wrong thing because of the
way it worked; my recollection is that it used kind of a value/return
model, which meant that if you started one, did a side-effect, and
then started a nested one, the nested one would not yet see the value
from the side-effect... or some such thing. If anyone really cares, I
can dig up the example of the screw case; I know I have it on file.
And further still, one of the absolute most controversial elements of
Common Lisp when it first came along was "lexical scoping". It was talked
about as untested (even though the "compiler semantics", and I use the
term loosely) of Maclisp had been around for a decade. People were very
concerned that the lack of specials would be a problem; witness Stallman's
design of lisp-based Gnu Emacs, which carries vestiges of that concern
through to this day. We made appeals to the fact that it was "tested"
in Algol and in Scheme, and we made the obvious claims about how lexical
scoping led to more modular proofs of correctness, but nothing substitutes
for direct personal experience. Though my point in this context is only
to observe that had the compiler's semantics been "lexical scoping", we'd
have just pointed to that and said "you've been using it all along". I'm
sure people said that somewhere in the myriad arguments on this, but I don't
think it carried much weight with the users.
On one level Maclisp was a fun language and very powerful. It is the
language I learned on, and it ran on a machine (the PDP10) that was in
many ways a true Lisp Machine (half-word instructions, hardware
pointer indirection checking, etc.). But in fairness to other more modern
dialects of Lisp, and to other languages, there were some senses in which
Maclisp was less a language and more just a toolbox, with a very untamed
notion of semantics. Various kinds of objects behaved completely differently
depending on what global switches were set, and this was a mess if you tried
to load modules that disagreed on how the global switches ought be set.
This "flexibility" gave the language a great deal of usefulness, but not a
great deal of stability, and its incessant series of changes both by
implementors and by users toggling its internal switches may not be the
only factor but must surely have been a measurable contributor to the need
for the cast-in-concrete stability of the Common Lisp that followed.
From: Janis Dzerins
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <87wvak73j8.fsf@asaka.latnet.lv>
Kellom{ki Pertti <··@arokyyhky.cs.tut.fi> writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
> > ····@goldshoe.gte.com (Dorai Sitaram) writes:
> > > Let's not conveniently forget that Lisp
> > > reinvented lexical scoping too.
> > True. But that was back in 1984.
>
> ... when Lisp was in its mid-twenties or so? Based on that I would say
> that the Python crowd is progressing rather faster.
The progress has not started yet.
--
Janis Dzerins
If million people say a stupid thing it's still a stupid thing.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> >>> x = 3
> >>> x
> 3
> >>> def f1():
> ... print x
> ...
> >>> f1()
> 3
> >>> def f2():
> ... print x
> ... x = 33
> ... print x
> ...
> >>> f2()
> Traceback (innermost last):
> File "<stdin>", line 1, in ?
> File "<stdin>", line 2, in f2
> NameError: x
> >>>
>
> Need I say more?
Yes. You need to say `global x'. Later versions of Python improved
the error message.
From: Marco Antoniotti
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <y6c3dd94ani.fsf@octagon.mrl.nyu.edu>
Hrvoje Niksic <·······@arsdigita.com> writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> > >>> x = 3
> > >>> x
> > 3
> > >>> def f1():
> > ... print x
> > ...
> > >>> f1()
> > 3
> > >>> def f2():
> > ... print x
> > ... x = 33
> > ... print x
> > ...
> > >>> f2()
> > Traceback (innermost last):
> > File "<stdin>", line 1, in ?
> > File "<stdin>", line 2, in f2
> > NameError: x
> > >>>
> >
> > Need I say more?
>
> Yes. You need to say `global x'. Later versions of Python improved
> the error message.
I did not have to say 'global x' in f1().
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
Marco Antoniotti <·······@cs.nyu.edu> writes:
> I did not have to say 'global x' in f1().
Because you didn't change `x'. In Lisp terms, you can think of
assignment in a function creating an implicit `let' block from the
beginning to the end of the function. `global x' disables it.
From: Marco Antoniotti
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <y6czofh2mx4.fsf@octagon.mrl.nyu.edu>
Hrvoje Niksic <·······@arsdigita.com> writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> > I did not have to say 'global x' in f1().
>
> Because you didn't change `x'. In Lisp terms, you can think of
> assignment in a function creating an implicit `let' block from the
> beginning to the end of the function. `global x' disables it.
I do not think that is an appropriate description of the behavior.
Anyway, looks like the wheel is being re-invented again (the new wheel
on the block avec forced indentation going lexical), so this
discussion is just for fun. :)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
Marco Antoniotti <·······@cs.nyu.edu> writes:
> > Because you didn't change `x'. In Lisp terms, you can think of
> > assignment in a function creating an implicit `let' block from the
> > beginning to the end of the function. `global x' disables it.
>
> I do not think that is an appropriate description of the behavior.
Feel free to correct me. I'm pretty sure that's exactly what happens.
> Anyway, looks like the wheel is being re-invented again (the new
> wheel on the block avec forced indentation going lexical), so this
> discussion is just for fun. :)
It takes experience to be bitter and funny at the same time. I think
I'd rather be constructive instead.
Kent M Pitman <······@world.std.com> writes:
| As I've said many times: small programming languages make for large
| programs. Large programming languages make for small programs.
This is highly dependent on your definition of `large'. IIRC the C++
standard is about 800 pages, which, in my book, counts as large.
Still, I wouldn't say that this will make programs written in C++ much
smaller than, say, programs written in Scheme (choosen as an example
because of its small standard not because of any particular flaws or
virtues of the language).
You might say that C++ has a big standard that specifies a small
language. I probably wouldn't disagree.
Boris
--
·····@uncommon-sense.net - <http://www.uncommon-sense.net/>
Magic is always the best solution -- especially reliable magic.
From: Marco Antoniotti
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <y6c66i941wt.fsf@octagon.mrl.nyu.edu>
Boris Schaefer <·····@uncommon-sense.net> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> | As I've said many times: small programming languages make for large
> | programs. Large programming languages make for small programs.
>
> This is highly dependent on your definition of `large'. IIRC the C++
> standard is about 800 pages, which, in my book, counts as large.
> Still, I wouldn't say that this will make programs written in C++ much
> smaller than, say, programs written in Scheme (choosen as an example
> because of its small standard not because of any particular flaws or
> virtues of the language).
>
> You might say that C++ has a big standard that specifies a small
> language. I probably wouldn't disagree.
And Scheme has a small standard that specifies a language that you
need to extend with everything that is in the ANSI CL standard.
So here we have
Scheme: small standard => small language
C++: large standard => small / medium size language
CL: large standard => large language
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
From: Kent M Pitman
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <sfwhf1s274u.fsf@world.std.com>
Boris Schaefer <·····@uncommon-sense.net> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> | As I've said many times: small programming languages make for large
> | programs. Large programming languages make for small programs.
>
> This is highly dependent on your definition of `large'. IIRC the C++
> standard is about 800 pages, which, in my book, counts as large.
> Still, I wouldn't say that this will make programs written in C++ much
> smaller than, say, programs written in Scheme (choosen as an example
> because of its small standard not because of any particular flaws or
> virtues of the language).
Well, it's hard to have a discussion that takes every possible issue into
account, and sometimes one holds some issues constant in order to focus.
I think you're right to observe that there are other factors in play as well,
and it's certainly possible to needlessly bloat a language spec with no good
effect. Some might say that of CL, but I would have to disagree. There is
very little in CL that is not offering power or leverage. There is a lot in
the C++ spec that I often say is an "apology" for (or at least "consequence
of") some ill-chosen design decisions at the lower level.
One might say that Scheme has chosen certain abstractions to give it high
leverage for its size, and I wouldn't disagree with that insofar as it goes.
However, I don't think the abstractions it gives you go far enough to avoid
a lot of very common boilerplate at the beginning of Scheme programs, trying
to climb from the platform offered by the language to any platform level
that is worth programming at. Whether that's a simple matter of including
libraries or a matter of writing code doesn't really matter to me. You're
plainly not ready to roll even by 1985 standards when you have a conforming
Scheme in front of you; you are with CL.
I would agree, if someone challenged me on this, that CL has not kept pace
as well as it should with the more recent needs of the garden variety
programmer and that Java is a better example of a "large language" which
enables small programs in today's domains. I do think the language glue of
Java is pathetic and holds the Java programmer back enormously given the
raw power of the available libraries in Java--it's still VERY hard to connect
them even though the power you get if you do manage it is quite good.
But my point is that to whatever degree CL falls short, I would fix it by
making it larger, not smaller. Because that would make user programs smaller.
Typically.
That it doesn't make C++ user programs smaller is a statement about
bad design. Perhaps the ratio of size of spec to size of various
kinds of typical programs would be one interesting measure of the
power of the language. I think Perl would show well in that arena,
especially if allowed to choose typical programs against the
planned-for user base for the language, and perhaps it should. Honestly,
I'm not quite sure what kind of programs C++ was intended for.
Maybe window systems? But then, I remember hearing someone say in 1985
when the Zetalisp "New Error System" (NES) came along [it was the conceptual
parent of the CL condition system, and a real shift in the way error handling
was done in Lisp] that `at last there was a second use for Flavors [the
CLOS analog], so now it was clear that Flavors weren't just good for one
thing'. Some technologies take a while to find their place in the world.
> You might say that C++ has a big standard that specifies a small
> language. I probably wouldn't disagree.
Close.
I might, too, say that C++ feels to me some element of "too many cooks spoil
the brew in it", with some elements of the language tripping over some
others... the whole thing with memory leaks and stuff is an example of
a simple memory management paradigm that worked for small systems not really
growing up with the language. Java fixed this as right as it could have;
C++ has tried to stick its head in the sand. I'm sure there are other
examples. Method dispatch, too, trying to stick to the static paradigm
of C++ just doesn't hold up in complex situations; Java didn't fix this as
well as it should have.
If these languages really did beat out Lisp on all points, I'd just pack it
up here and go use them. I'm not really stuck on Lisp. I just hate getting
beaten out by inferior work.
From: Tim Bradshaw
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <ey3hf1sgo7g.fsf@cley.com>
* Kent M Pitman wrote:
> I might, too, say that C++ feels to me some element of "too many cooks spoil
> the brew in it", with some elements of the language tripping over some
> others...
I think that languages like C++ tend to suffer from seeking
specialised solutions to general problems, rather than generalised
ones. The specialised solution works for one bit of the problem but
another bit is still there, so you invent another solution for that,
and soon the language is a patchwork of little hacks, none of which
work very well.
Lisp I think has worked out that not only are these specialised
solutions not any kind of answer but that some of these problems
simply don't have general solutions -- things like object copying and
equality are obvious examples. So instead of solutions it tends to
provide tools from which a custom solution can be made, which will
suit a given program very well.
Lisp is actually a much lower-level language than C++ because it
provides these toolkits rather than prepackaged solutions, and I hope
that Lisp becomes still lower level by providing more tools like this.
The lack of general solutions to these problems also dooms languages
which seek to provide solutions into either failing or becoming
infinitely large, or both, something which seems to be happening to
both Java and C++.
--tim
From: David Thornley
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <xhAk6.602$S7.51755@ruti.visi.com>
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> wrote:
>Boris Schaefer <·····@uncommon-sense.net> writes:
>
>> This is highly dependent on your definition of `large'. IIRC the C++
>> standard is about 800 pages, which, in my book, counts as large.
>> Still, I wouldn't say that this will make programs written in C++ much
>> smaller than, say, programs written in Scheme (choosen as an example
>> because of its small standard not because of any particular flaws or
>> virtues of the language).
>
C++ may not be an improvement over Scheme, but it is over C. The
object orientation helps, templates help, and the STL adds a lot
to the language. Pity about the odd corners of the language, though.
>I would agree, if someone challenged me on this, that CL has not kept pace
>as well as it should with the more recent needs of the garden variety
>programmer and that Java is a better example of a "large language" which
>enables small programs in today's domains. I do think the language glue of
>Java is pathetic and holds the Java programmer back enormously given the
>raw power of the available libraries in Java--it's still VERY hard to connect
>them even though the power you get if you do manage it is quite good.
>
Agreed. I have some resentment towards Java, which is based on the
concept that if they were going to break C compatibility, they should
have done a much better job. C++ had C compatibility as a design
goal, which means I'm not as bothered by keeping the C switch statement.
Java didn't, and so the Java folks have no excuse.
>But my point is that to whatever degree CL falls short, I would fix it by
>making it larger, not smaller. Because that would make user programs smaller.
>Typically.
>
At some point it might be a good idea to start calling things libraries,
partly as a stealth move, and partly to emphasize that you really
don't need to know about this library unless you intend to use it.
>That it doesn't make C++ user programs smaller is a statement about
>bad design. Perhaps the ratio of size of spec to size of various
>kinds of typical programs would be one interesting measure of the
>power of the language. I think Perl would show well in that arena,
>especially if allowed to choose typical programs against the
>planned-for user base for the language, and perhaps it should.
Depends. Perl is a very fast, easy, way to write certain sorts of
programs, but you pay for it if you try to make the programs bigger
or more general (mostly, in my experience, due to the data structures,
but I've never been brave enough to try object-oriented Perl). It's
like a host of specialized languages since people started finding
alternatives to assembler language: very useful in certain areas
and much less so outside of them. It happens that Perl is an
excellent language for an important class of problems.
Honestly,
>I'm not quite sure what kind of programs C++ was intended for.
Anything. It is intended to be general purpose, an improved C.
It succeeds at that: it's usually much less painful to use C++
than C, in my experience. (Until you get bit by something in those
dark corners, of course, but you can usually stay away from them
with a bit more work.)
>Maybe window systems? But then, I remember hearing someone say in 1985
>when the Zetalisp "New Error System" (NES) came along [it was the conceptual
>parent of the CL condition system, and a real shift in the way error handling
>was done in Lisp] that `at last there was a second use for Flavors [the
>CLOS analog], so now it was clear that Flavors weren't just good for one
>thing'. Some technologies take a while to find their place in the world.
>
>> You might say that C++ has a big standard that specifies a small
>> language. I probably wouldn't disagree.
>
>Close.
>
Much of the standard is about things that are generally useful, but
difficult to learn, not well described in most books, and which wasn't
reliably part of implementations until recently (or isn't yet,
depending on what you've got to support). If you learn the language
well and use a conforming implementation, you can get a lot of
mileage out of it. (Note that learning the language well includes
learning lots of the traps.)
>I might, too, say that C++ feels to me some element of "too many cooks spoil
>the brew in it", with some elements of the language tripping over some
>others... the whole thing with memory leaks and stuff is an example of
>a simple memory management paradigm that worked for small systems not really
>growing up with the language. Java fixed this as right as it could have;
>C++ has tried to stick its head in the sand. I'm sure there are other
>examples. Method dispatch, too, trying to stick to the static paradigm
>of C++ just doesn't hold up in complex situations; Java didn't fix this as
>well as it should have.
>
The big rap on C++ is that it is descended from, and mostly compatible
with, C. The other problem is its evolutionary design. Some things
got more or less frozen early on and did not work well with later
decisions. Consider the addition of lexical scoping to Lisp (IMNSHO
one of the biggest improvements over the earlier Lisps). That scope
of change was never feasible for C or C++, due to the necessity to
keep supporting older code (some of it really badly written). For
example, look at the introduction of "long long" to the latest C
standard.
Stroustrup tried to design C++ to not rule out garbage collection,
and in fact there are packages that will do GC with C++, and these
packages seem to have some success. Stroustrup writes (in "Design
and Evolution of C++") that multiple dispatch was the thing he
most wanted to bring in from Lisp, but he couldn't figure out a way
to do it that was compatible with his other design goals.
>If these languages really did beat out Lisp on all points, I'd just pack it
>up here and go use them. I'm not really stuck on Lisp. I just hate getting
>beaten out by inferior work.
I don't think one language ever beats out another on all points. There
are situations in which COBOL is the way to go (and I am prepared to
work hard to avoid ever being in that situation again).
Lisp, for example, puts certain demands on a system that C doesn't.
The core functionality necessary to run Common Lisp efficiently is
significantly larger and more complicated. This allows a CL program
to be much more compact and robust than a C program, but it means
that it is more difficult to port a CL implementation. If I want
to write a program that runs on many different platforms, including
platforms I just don't have access to, I write it in C. If I want
to write a program for my own use, and CL is available, and it isn't
for a little problem that is in the domain of a more specialized
language, I'll use CL.
Lots of applications in any language can be most efficiently written
by starting with some sort of framework and building on it, and so
the ability to extend a framework is (I think) a very important
feature of a general-purpose language. I have to rate C++ higher
on that than most other languages I'm familiar enough with to judge,
the only higher scores going to CL and Forth.
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
········@visi.com (David Thornley) writes:
[many wise words]
Thanks for the good post. I see far too many "ra ra <my favourite language>!"
postings and too many "bleah bleah <the stupid language>" postings.
The true situation, as usual, is one of trade offs depending on one's
goals. Even VB (ack!) has its uses.
> I don't think one language ever beats out another on all points.
This is good to keep in mind when participating in the comp.lang.* groups.
In keeping with this thread: using classes for encapsulation is *not* brain
dead.
That Lisp has a more general solution for extending and changing
behaviour is just great, and its power is quite amazing.
The "class as a namespace" solution used by most OO languages, however, has a
certain simplicity that is easy to understand and lends itself greatly to
organizing a design in a maintainable way, at least for many kinds of problems.
When you need multiple dispatch you really really need it, but the advantages
of good software organization should not be ignored either.
Often also, the ability to dynamically change a system's behaviour on the fly
can be considered a bad bad thing. Consider systems (air traffic control,
perhaps), where every change must be reviewed, tested, regression tested,
integration tested like hell before it gets anywhere near deployed. The source
code is the *only* description of what the system actually will do, and changes
to it are zealously monitored, tracked, version controlled, etc.
Changing a running system on the fly is great when you need that, but one does
one the risk of having the only real description of a system be the system's
running image.
The real point of this post is to fight against the simplistic attitude of
"Lisp good, everything else bad" that I have been seeing in this thread. I like
Lisp a lot -- it is probably my favourite language. But reality is in shades of
gray rather than black and white.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
From: Christopher C Stacy
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <x8llmr0mp0v.fsf@world.std.com>
>>>>> On 20 Feb 2001 22:53:35 -0800, Ray Blaak ("Ray") writes:
Ray> The "class as a namespace" solution used by most OO languages, however, has a
Ray> certain simplicity that is easy to understand and lends itself greatly to
Ray> organizing a design in a maintainable way, at least for many kinds of problems.
Ray> When you need multiple dispatch you really really need it, but the advantages
Ray> of good software organization should not be ignored either.
It sounds like you are conflating several different concepts in
Lisp (and CLOS). Generic function namespace, multiple inheritence,
and multi-method dispatch are things that work together,
but they are not all the same thing.
In what way does the availability of multiple-dispatching
constitute a disadvantage towards good software organization?
Ray> The real point of this post is to fight against the simplistic attitude of
Ray> "Lisp good, everything else bad" that I have been seeing in this thread.
On the contrary, the experienced people on this newsgroup usually
claim that different tools are best suited for different problems,
but that they have found Lisp to be in most ways far superior to the
more popular general-purpose languages (such as C++ or Java).
From: Ray Blaak
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <uelwrhov0.fsf@infomatch.com>
Christopher C Stacy <······@world.std.com> writes:
> In what way does the availability of multiple-dispatching
> constitute a disadvantage towards good software organization?
It doesn't.
My point was that the idea of classes "owning" their methods, while having
disadvantages related to ease of extension, also has advantages related to
conceptual understanding and organization.
> On the contrary, the experienced people on this newsgroup usually
> claim that different tools are best suited for different problems,
> but that they have found Lisp to be in most ways far superior to the
> more popular general-purpose languages (such as C++ or Java).
And I agree with them.
This thread was discussing the superiority of CLOS's approach to OO
programming. I was attempting to keep the ideas presented from being too one
sided, namely that some of the "inferior" approaches also have their place.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
From: David Thornley
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <XOVk6.425$V6.9269@ruti.visi.com>
In article <·············@infomatch.com>,
Ray Blaak <·····@infomatch.com> wrote:
>Christopher C Stacy <······@world.std.com> writes:
>> In what way does the availability of multiple-dispatching
>> constitute a disadvantage towards good software organization?
>
>It doesn't.
>
What bugs me is diagrams. For C++ or Java, the UML class diagrams
work well. They don't work well for CLOS programs (kinda negating
the "U" in the acronym, but that's marketing for you). This is
because CL has a much more freewheeling attitude towards classes
and methods than C++, and, having used both, I prefer the CLOS
approach. C++ and Java are limited in ways that can be annoying
but make them easier to diagram.
So, does anybody know of a good class diagram technique for CLOS?
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
From: Kent M Pitman
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <sfw66i31tff.fsf@world.std.com>
Ray Blaak <·····@infomatch.com> writes:
> My point was that the idea of classes "owning" their methods, while having
> disadvantages related to ease of extension, also has advantages related to
> conceptual understanding and organization.
In those cases where the packaging is what you want.
I don't think it helps the conceptual understanding nor organization
of generic arithmetic, for example. Even CLOS comes up a mite short
for not having a notation to specify that an operator is commutative,
but at least it's not forcing you to see any asymmetries where they
don't exist in multiplying an integer with a float or vice versa.
Kent M Pitman <······@world.std.com> writes:
> Ray Blaak <·····@infomatch.com> writes:
>
> > My point was that the idea of classes "owning" their methods, while having
> > disadvantages related to ease of extension, also has advantages related to
> > conceptual understanding and organization.
>
> In those cases where the packaging is what you want.
>
> I don't think it helps the conceptual understanding nor organization
> of generic arithmetic, for example.
Absolutely. One should the approach that works best for the particular
situation.
There are no absolute rules, except for this rule.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
From: Joe Marshall
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <3dd8f49g.fsf@content-integrity.com>
Ray Blaak <·····@infomatch.com> writes:
> The real point of this post is to fight against the simplistic
> attitude of "Lisp good, everything else bad" that I have been seeing
> in this thread.
``Lisp good, everything else bad'' is probably correct to a
first-order approximation.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
From: ········@hex.net
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <wksnl83rwg.fsf@mail.hex.net>
>>>>> "Joe" == Joe Marshall <···@content-integrity.com> writes:
Joe> Ray Blaak <·····@infomatch.com> writes:
>> The real point of this post is to fight against the simplistic
>> attitude of "Lisp good, everything else bad" that I have been
>> seeing in this thread.
Joe> ``Lisp good, everything else bad'' is probably correct to a
Joe> first-order approximation.
.. And you've got to wonder what other option would be likely in
comp.lang.lisp.
This is, for better or worse, the place where advocates of Lisp would
be most likely to "hang out."
This is a place where people would sensibly ask "How do I do
#\WHATEVER in Lisp?" and where others would sensibly answer "Here's
how."
The answer "That's a stupid thing to do with Lisp" almost certainly
isn't going to be the _first_ order approximation of what one would
expect as a response.
The better "first-order approximation" is:
Lisp: Good/Interesting/Relevant
Everything else: _Less Interesting/Relevant_.
The notion of "other stuff bad" is an approximation most probably of
some lower order.
--
(concatenate 'string "cbbrowne" ·@ntlug.org")
http://vip.hyperusa.com/~cbbrowne/lisp.html
"I'd say the probability of Windows containing a backdoor is about the
same as a spreadsheet containing a flight simulator."
-- Phil Hunt <·····@vision25.demon.co.uk>
From: Kent M Pitman
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <sfwd7cag71q.fsf@world.std.com>
········@hex.net writes:
> The better "first-order approximation" is:
> Lisp: Good/Interesting/Relevant
> Everything else: _Less Interesting/Relevant_.
>
> The notion of "other stuff bad" is an approximation most probably of
> some lower order.
Or, to sound somewhat like a broken record (is there a more modern
term for that in these post-vinyl, almost post-physical-media days
of music?), here's my take:
Good and bad exist only in a context, never in the absolute.
The notion of what is good or bad cannot be lifted from the ecosystem
of one language and plopped into the ecosystem of another language and
expected to be judged the same. When we look at what is good and bad
in other languages, we necessarily experience a kind of relativistic
frame of reference problem where ours looks good and theirs looks bad
because what's in our language was DESIGNED for our language, while what
is in other languages was NOT designed for our language, and the very
lack of coordinated design of everything in the far-away frame of
reference makes it probable that on average all things in that frame of
language will be less good for our purposes than all things in ours;
however, paradoxically, they'll experience the same observation.
Rather than having vague discussions like "x is good", it might be
wise to either pick a clear context in which to do the judging--not
just a context of a goal problem to solve, but also a goal environment
of a complete linguistic ecosystem in which to do the judging. You'll
probably (almost necessarily) pick either Lisp's or C++'s when juding
Lisp against C++, for example, and either choice will be unfair to the
other. But it will at least underscore the unfairness of the
question, which has a vaguely Heisenbergian quality, making it
impossible to both discuss an issue of comparative elegance clearly
and to be fair about that discussion at the same time...
From: Tim Bradshaw
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <nkjn1bgnwoc.fsf@tfeb.org>
········@visi.com (David Thornley) writes:
> C++ may not be an improvement over Scheme, but it is over C. The
> object orientation helps, templates help, and the STL adds a lot
> to the language. Pity about the odd corners of the language, though.
I think this is quite a contentious statement. I much prefer C over
C++ (I *like* C), and although I'm a Lisp person so my opinion
probably doesn't count, I know a fair number of C/C++ people who are
of the same opinion, one of my favourite quotes being `the best thing
about C++ compilers is that they will compile C too' (which I suspect
is not really true of course).
Of course personal preference doesn't make for `better', in fact I
don't know what does. Perhaps project success or something -- at
least some of the people I'm referring to above are basing their
opinions on having decided to do a substantial system in C++ and it
being a hideous nightmare, although this may be because the language,
as implemented by compilers, was so unstable for about 10 years --
perhaps it has stabilised now.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> ········@visi.com (David Thornley) writes:
>
> > C++ may not be an improvement over Scheme, but it is over C. The
> > object orientation helps, templates help, and the STL adds a lot
> > to the language. Pity about the odd corners of the language, though.
>
> I think this is quite a contentious statement. I much prefer C over
> C++ (I *like* C), and although I'm a Lisp person so my opinion
> probably doesn't count, I know a fair number of C/C++ people who are
> of the same opinion, one of my favourite quotes being `the best thing
> about C++ compilers is that they will compile C too' (which I suspect
> is not really true of course).
<aol>Me too!</aol>
I think C is just fine in its role as a low-level
language. C++ is a wrong-level language.
The best thing about C++ is that you can use Common Lisp to
prototype stuff before you do the C++ implementation. (Take a look at
the standard template library for a good example :-)
--
Raymond Wiker
·············@fast.no
From: Will Deakin
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <3A93C807.1060807@pindar.com>
Tim wrote:
> although this may be because the language, as implemented by compilers,
> was so unstable for about 10 years -- perhaps it has stabilised now.
Uhhhh, no.
:)w
>>>>> David Thornley writes:
>>
DT> C++ may not be an improvement over Scheme, but it is over C.
[snip]
Kent M Pitman <······@world.std.com> wrote:
KP> I'm not quite sure what kind of programs C++ was intended for.
DT> Anything. It is intended to be general purpose, an improved C.
DT> It succeeds at that: it's usually much less painful to use C++
DT> than C, in my experience. (Until you get bit by something in those
DT> dark corners, of course, but you can usually stay away from them
DT> with a bit more work.)
I just don't see this. I've programmed in C++, professionally,
for 3 years, on a Telco app. What I saw was horrendous. And that's
meant to be exactly one of the types of applications C++ was designed
for (it did, after all, come to us from AT&T.)
IMO, C is a far better language, which should be used as follows:
* use C to implement Unix
* use C to implement a Lisp kernel, or Python/Perl/Whatever HLL you like
* use C to write device drivers to talk to your hardware
Then use your HLL to call out to those drivers (I'm thinking of things
like voice cards) and write your app in it.
C++ is a siren song. It *looks* like a HLL in which you ought to
be able to write an application, but it really isn't.
DT> C++ had C compatibility as a design goal [...]
I'm not sure what `compatibility' can possibly mean for a language
which didn't even standardize its name mangling convention, so you
can't link libraries of 2 different vendors together.
This is not to say C++ = bad, Lisp = good. It's to say
C++ = bad irrespective of everything else.
Alain Picard
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
From: Raymond Toy
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <4nzofgb1ek.fsf@rtp.ericsson.se>
>>>>> "Alain" == Alain Picard <·······@optushome.com.au> writes:
Alain> I'm not sure what `compatibility' can possibly mean for a language
Alain> which didn't even standardize its name mangling convention, so you
Alain> can't link libraries of 2 different vendors together.
I thought this was a conscious design decision that allowed each
vendor to implement the details of classes in whatever appropriate
way. Then the language would have had to specify implementation details.
Ray
From: Joe Marshall
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <y9v0dphe.fsf@content-integrity.com>
Alain Picard <·······@optushome.com.au> writes:
> IMO, C is a far better language [than C++], which should be used as follows:
> * use C to implement Unix
I would have to agree that Unix written in anything but C would simply
not be Unix. A `unix' written in Lisp would deprive the user of the
experience of leaking resources, core dumps, race conditions, shell
kludges, and all the other things that contribute to the unix
experience.
> * use C to implement a Lisp kernel, or Python/Perl/Whatever HLL you like
> * use C to write device drivers to talk to your hardware
These things can be done in Lisp, and they are much easier to do in
Lisp if you have enough control over your compiler.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Joe Marshall <···@content-integrity.com> writes:
> I would have to agree that Unix written in anything but C would simply
> not be Unix. A `unix' written in Lisp would deprive the user of the
> experience of leaking resources, core dumps, race conditions, shell
> kludges, and all the other things that contribute to the unix
> experience.
Does anybody know in what language the Unix domain for Apollo's Domain
OS was written in? It might have been pascal.
--
Lieven Marchand <···@wyrd.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.
From: Kellom{ki Pertti
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <xfzsnl8kunh.fsf@arokyyhky.cs.tut.fi>
Alain Picard <·······@optushome.com.au> writes:
> I'm not sure what `compatibility' can possibly mean for a language
> which didn't even standardize its name mangling convention, so you
> can't link libraries of 2 different vendors together.
I would be very surprised if you could take object files produced by
two Common Lisp implementations, and just link them together to a
working binary.
--
Pertti Kellom\"aki, Tampere Univ. of Technology, Software Systems Lab
From: David Thornley
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <WJVk6.424$V6.9182@ruti.visi.com>
In article <··············@localhost.apana.org.au>,
Alain Picard <·······@optushome.com.au> wrote:
>>>>>> David Thornley writes:
>>>
>DT> C++ may not be an improvement over Scheme, but it is over C.
>
>KP> I'm not quite sure what kind of programs C++ was intended for.
>
>DT> Anything. It is intended to be general purpose, an improved C.
>DT> It succeeds at that: it's usually much less painful to use C++
>DT> than C, in my experience. (Until you get bit by something in those
>DT> dark corners, of course, but you can usually stay away from them
>DT> with a bit more work.)
>
>I just don't see this. I've programmed in C++, professionally,
>for 3 years, on a Telco app. What I saw was horrendous. And that's
>meant to be exactly one of the types of applications C++ was designed
>for (it did, after all, come to us from AT&T.)
>
In that case, we have different experiences with C++. Myh professional
experience has been positive.
I have this nagging feeling that having to make sure the software
works on three different systems probably keeps us from the worst
of the pitfalls. Had we been writing on one system for one compiler
only, we would have been much more tempted to use more of the language,
including the parts that should say "Here There Be Dragons" (both
because the standard creates little traps there, and because
implementors haven't managed to get it to work yet. Sample
trap: try designing a class that can have an exception thrown in
its constructor and still be destructable without mucking things
up.)
>IMO, C is a far better language, which should be used as follows:
> * use C to implement Unix
> * use C to implement a Lisp kernel, or Python/Perl/Whatever HLL you like
> * use C to write device drivers to talk to your hardware
>
If you're saying that Common Lisp is a better language than C++ for
most things, I'd agree. I'd also agree that C is the best thing we've
got as a portable assembler language.
>C++ is a siren song. It *looks* like a HLL in which you ought to
>be able to write an application, but it really isn't.
>
Again, this is not my experience, or the experience of my friends.
People have used C++ very successfully to write applications.
(Not that this is the only possible result....)
>DT> C++ had C compatibility as a design goal [...]
>
>I'm not sure what `compatibility' can possibly mean for a language
>which didn't even standardize its name mangling convention, so you
>can't link libraries of 2 different vendors together.
>
Source-level compatibility. You can use a subset of ISO C (1990
version) that is very nearly as good as using the whole thing, and
the program means almost the exact same thing in C and C++.
This was an important part of the adoption of C++: you could start
with compiling C code and progress as you liked.
As far as the name mangling goes, that's only the tip of the
iceberg. There are a whole lot of compatibility issues involved,
including the layout of stuff that's not visible to the programmer.
If name mangling were standardized, we'd run into problems with
different padding in classes and structs, different vtable layouts,
that sort of thing. It would require that the standard specify
the implementation details, and that would be a bad idea right
now, and for a long time to come.
>This is not to say C++ = bad, Lisp = good. It's to say
>C++ = bad irrespective of everything else.
>
That's not my experience. There's been a lot of stuff written in
C++ that would have been much harder in C, and I've worked on
some of it. (And most of it would have been easier in Common
Lisp.)
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
On Wed, 21 Feb 2001 20:41:26 GMT, David Thornley <········@visi.com> wrote:
>In article <··············@localhost.apana.org.au>,
>Alain Picard <·······@optushome.com.au> wrote:
>>>>>>> David Thornley writes:
>>>>
>>DT> C++ may not be an improvement over Scheme, but it is over C.
>>
>>KP> I'm not quite sure what kind of programs C++ was intended for.
>>
>>DT> Anything. It is intended to be general purpose, an improved C.
>>DT> It succeeds at that: it's usually much less painful to use C++
>>DT> than C, in my experience. (Until you get bit by something in those
>>DT> dark corners, of course, but you can usually stay away from them
>>DT> with a bit more work.)
>>
>>I just don't see this. I've programmed in C++, professionally,
>>for 3 years, on a Telco app. What I saw was horrendous. And that's
>>meant to be exactly one of the types of applications C++ was designed
>>for (it did, after all, come to us from AT&T.)
>>
>In that case, we have different experiences with C++. Myh professional
>experience has been positive.
For small projects (i.e. a single team working on less than 1m lines of
code,) I'd agree. It beats C hands down.
>I have this nagging feeling that having to make sure the software
>works on three different systems probably keeps us from the worst
>of the pitfalls. Had we been writing on one system for one compiler
>only, we would have been much more tempted to use more of the language,
>including the parts that should say "Here There Be Dragons" (both
>because the standard creates little traps there, and because
>implementors haven't managed to get it to work yet. Sample
>trap: try designing a class that can have an exception thrown in
>its constructor and still be destructable without mucking things
>up.)
Three target platforms definitely help. The problems seem to appear
when you have 10m lines of code, much of it legacy, some of which was
only built to run on a single platform. A random programmer comes into
your office and asks "why doesn't this run?" Often, the only valid
answers are "why do you think it should?" or "why did you write that?"
>>IMO, C is a far better language, which should be used as follows:
>> * use C to implement Unix
>> * use C to implement a Lisp kernel, or Python/Perl/Whatever HLL you like
>> * use C to write device drivers to talk to your hardware
>>
>If you're saying that Common Lisp is a better language than C++ for
>most things, I'd agree. I'd also agree that C is the best thing we've
>got as a portable assembler language.
>
>>C++ is a siren song. It *looks* like a HLL in which you ought to
>>be able to write an application, but it really isn't.
>>
>Again, this is not my experience, or the experience of my friends.
>People have used C++ very successfully to write applications.
>(Not that this is the only possible result....)
Yep, it's great for small apps, and even "scalable" if you can get
enough databases and interprocess communication between the various
blocks of code.
>>DT> C++ had C compatibility as a design goal [...]
>>
>>I'm not sure what `compatibility' can possibly mean for a language
>>which didn't even standardize its name mangling convention, so you
>>can't link libraries of 2 different vendors together.
>>
>Source-level compatibility. You can use a subset of ISO C (1990
>version) that is very nearly as good as using the whole thing, and
>the program means almost the exact same thing in C and C++.
>This was an important part of the adoption of C++: you could start
>with compiling C code and progress as you liked.
>
>As far as the name mangling goes, that's only the tip of the
>iceberg. There are a whole lot of compatibility issues involved,
>including the layout of stuff that's not visible to the programmer.
>If name mangling were standardized, we'd run into problems with
>different padding in classes and structs, different vtable layouts,
>that sort of thing. It would require that the standard specify
>the implementation details, and that would be a bad idea right
>now, and for a long time to come.
Well, C++ is still based in the concept of a standalone executable:
the linker and loader are not a part of the language. I don't
think the standard should specify implementation details, but the
language must exist in reality: multiple platforms, build versions,
shared libraries and the like.
>>This is not to say C++ = bad, Lisp = good. It's to say
>>C++ = bad irrespective of everything else.
>>
>That's not my experience. There's been a lot of stuff written in
>C++ that would have been much harder in C, and I've worked on
>some of it. (And most of it would have been easier in Common
>Lisp.)
You're more of an optimist than me. I'm been using C++ for
fifteen years or so, and have seen several projects that would
have failed in C, but limped through in C++. I fear most would
have been easier in CL only in the sense that the mediocre
programmers would have quit in frustration rather than been
encysted by C++'s encapsulation and prophyatic measures.
-- mmn
>>>>> David Thornley writes:
DT> In article <··············@localhost.apana.org.au>,
DT> Alain Picard <·······@optushome.com.au> wrote:
>>
>> I just don't see this. I've programmed in C++, professionally,
>> for 3 years, on a Telco app. What I saw was horrendous. And that's
>> meant to be exactly one of the types of applications C++ was designed
>> for (it did, after all, come to us from AT&T.)
>>
DT> In that case, we have different experiences with C++. Myh professional
DT> experience has been positive.
[snip]
DT> That's not my experience. There's been a lot of stuff written in
DT> C++ that would have been much harder in C, and I've worked on
DT> some of it. (And most of it would have been easier in Common
DT> Lisp.)
Sigh. Others for which I have tremendous respect have said things
much like the above. I can only conclude that I'm a lousy C++
programmer. :-( I find it *incredibly* hard to write correct,
extensible code in it. I'm sure that I can implement new
functionality at least 5X faster in CL, and I'm not exagerating.
I guess this is a dead horse being flogged. Far be it from me
to tell others what to program in---I guess I feel jealous and
frustrated that most jobs are in a language which makes me miserable.
I'm counting my blessings to have (mostly) escaped that world!
--ap
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
Kent M Pitman wrote:
> ...
> One might say that Scheme has chosen certain abstractions to give it high
> leverage for its size, and I wouldn't disagree with that insofar as it goes.
> However, I don't think the abstractions it gives you go far enough to avoid
> a lot of very common boilerplate at the beginning of Scheme programs, trying
> to climb from the platform offered by the language to any platform level
> that is worth programming at. Whether that's a simple matter of including
> libraries or a matter of writing code doesn't really matter to me. You're
> plainly not ready to roll even by 1985 standards when you have a conforming
> Scheme in front of you; you are with CL.
>
> I would agree, if someone challenged me on this, that CL has not kept pace
> as well as it should with the more recent needs of the garden variety
> programmer and that Java is a better example of a "large language" which
> enables small programs in today's domains. I do think the language glue of
> Java is pathetic and holds the Java programmer back enormously given the
> raw power of the available libraries in Java--it's still VERY hard to connect
> them even though the power you get if you do manage it is quite good.
> ...
Taking a cue from Kent and others, I've tried to train myself to make
clear distinctions between language, implementation, and libraries.
Alas, that leaves me somewhat unfit to try to see how the three can work
together to "avoid a lot of very common boilerplate at the beginning of"
the program, as Kent notes for Scheme.
Noting that CL has not kept pace with system/module/package/autoload
technologies, are there any design principles that this community could
adopt to determine:
What belongs in a library?
What is a reasonable amount of boilerplate?
How do libraries change vs extend the language or other libraries used
by the same program?
There are several (interrelated) issues that overlay this:
Bondage and Discipline: some people *prefer* to have only one way of
doing things, even if that way isn't ideally suited for the problem at
hand. Are constructs in the language or certain libraries (e.g.,
provided by the implementation or some super-language definition)
somehow more pre-eminent in providing the "standard" way to do things?
Relates to...
Language change: Lisp allows the language to be extended within itself.
Heck, even C++ and Java let classes be subclassed with different
behavior. Some things (at minimum, the meaning of identifiers) can
actually be changed, not just extended, in one configuration vs another.
Namespace vs class encapsulization: Lisp is unusual in separating these
two. See next...
Cross language: lowest common denominator?
Locating modules: "net" languages like Java and Curl build location and
identification semantics into the library loading mechanism. The Emacs
elisp implementation provides certain autoloading conventions.
Versioning: The Symbolics SCT system mechanism allowed for versioned
files to be recorded in versioned system dependencies, yet aspects of
this were dropped in later systems. In the other direction, Curl not
only provides for versioned packages, but allows a single program to
multiply inherit different versions of the "same" package. There is
limited persistence, and this, too must work with different versions of
the type definitions. The idea is to keep code working verbatim. Only
experience will tell how well this works in practice, or even how
important it is.
Kernalization: what's minimum? What's provided by the implementation?
Any thoughts on basic principles or ontology?
>········@aol.com (DvdAvins) writes:
>
>>
>> Howard Stearns wrote:
>>
>> >In the method-table world, who own's the commutative binary methods
>> >named "winner" between the classes rock, paper and scissors?
>> >
>> >How does "objects own their behavior" apply here?
>>
>> Rocks, papers, and scissors are never inherrently winners. Games
>> have winners. The subclass of Game that is RockPaperScissors has
>> variable Material1 and Material2. RockPaperScissors also has a
>> method for determining its winner based on the class of Material1
>> and Material2. Other subclasses of Game will have other methods for
>> determining the winner.
>
>Is it your position that this is more intuitive than the CL approach
>of allowing the generic functions to sit outside and, if you'll pardon
>the informal way of expressing it, simply saying the "obvious" thing.
No. It is my position that it is a more consitantly coherant approach, but
only if you think it's profitable to spend an enormous amount of time
modeling your local universe before you start to code. For very complex
systems that require many programmers and are maintained by more
programmers yet, that forethought may be worthwhile. It allows a cleaner
division of labor. But for most projects I think it is overkill. I prefer
working
in a system where changing the way I want to think about something
doesn't require me to start from scratch.
From: Kent M Pitman
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <sfwy9v6sib8.fsf@world.std.com>
········@aol.com (DvdAvins) writes:
> Kent M. Pitman writes:
>
> > I asked whether that means a rock's
> >behavior is best described by the creator of class rock. It sure
> >seems to me that there are lots of things I can do to rocks that are
> >not primitive to rockness. Big rocks I can use them as tables and
> >chairs. Small rocks I can throw. On and on. It's plain that there
> >are abstract actions (like "throw") which are not going to be defined
> >primitively on rocks and yet that will want to be done with rocks.
> >
> >Consider, too, integers. Suppose I add a float class later. Surely
> >integer will include no methods anticipating floats. Or maybe float was
> >added first, and integer later. Neither can really anticipate the other.
> >Yet there will be operations on both that need to be done.
>
>
> An OO zealot would say that rocks should be defined as a subclass of
> material object. The ability to use something as a table or to throw it
> would be defined in the material object (let's call it Thing, to avoid
> overloading the word "object") class. Of course the method use-as-table
> would have to generate an exception if the thing wasn't at least a little flat.
>
> I don't think it's always practical to think of all the superclasses ahead of
> time, so I'm not an OO zealot. But I do think an omniscient observer
> would find it a convenient way to describe the world.
I get what you're saying but I think these are arguments created by
people who use static languages that don't get code loaded anew in
mid-session or that don't conjure new code on the fly. The closed world
assumption of a static language is that the space of available operations
became fixed/known in the past, and so is amenable to this kind of analysis.
The interesting characteristic of the web, and of Lisp, is that new info
comes along all the time for which you'd like not to exit your image but
rather would want to just keep running. It's a sure thing that the data
you could handle yesterday is not the full set of things you'll have to
handle tomorrow. Static programming and encapsulation says you should shut
down and re-define your system to account for this new knowledge, but that's
not very practical for adaptive systems.
*I*, by the way, am an OO zealot. However, I don't accept the notion that
an object-oriented system is defined by the presence of encapsulation. I
think an object-oriented system is defined by the presence of "objects",
that is, by the presence of data layouts that have identity. Pinning
the implementation of those objects to something like encapsulation seems
to me an abstraction violation.
From: Tim Bradshaw
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <ey366iai7xi.fsf@cley.com>
* DvdAvins wrote:
> I don't think it's always practical to think of all the superclasses ahead of
> time, so I'm not an OO zealot. But I do think an omniscient observer
> would find it a convenient way to describe the world.
I think that, while assuming all-knowingness might be safe for
deities, it's probably not safe for language or class designers. One
could also get into all sorts of interesting philosophical discussions
based on the possible infinity of purposes to which a given object
could be put -- perhaps in static languages all correct class
definitions must necessarily be infinite?
--tim
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Question 1.
> One of the things I like the most in CLOS is that slot
> names are paramount. You do not have to mess around with 'class
> qualifiers' to get the right slot from the right class. A couple of
> people very keen on their "newly reinvented wheel avec forced
> indentation rules"
Do you mean Python here?
> said that CLOS behavior is as ambiguous as in their
> "new round shape". I must say that I did not have a convincing answer
> (i.e. I am perfectly at ease with myself, but I could not find a good
> argument at the time).
I have to agree with Rainer on this question - I have no idea what
you're asking. Try again?
Cheers,
M.
--
[Perl] combines all the worst aspects of C and Lisp: a billion
different sublanguages in one monolithic executable. It combines
the power of C with the readability of PostScript.
-- Jamie Zawinski
From: Marco Antoniotti
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <y6c4ry5mc7b.fsf@octagon.mrl.nyu.edu>
Michael Hudson <·····@cam.ac.uk> writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> > Question 1.
> > One of the things I like the most in CLOS is that slot
> > names are paramount. You do not have to mess around with 'class
> > qualifiers' to get the right slot from the right class. A couple of
> > people very keen on their "newly reinvented wheel avec forced
> > indentation rules"
>
> Do you mean Python here?
No, I wasn't talking about CMUCL compiler. :) :)
> > said that CLOS behavior is as ambiguous as in their
> > "new round shape". I must say that I did not have a convincing answer
> > (i.e. I am perfectly at ease with myself, but I could not find a good
> > argument at the time).
>
> I have to agree with Rainer on this question - I have no idea what
> you're asking. Try again?
This is a rather tricky one and I believe it is there because of the
heritage of CL as a AI language. Of course it is a by-product of
multiple inheritance.
AFAIR all the earliest "frame" languages with inheritance where
interested in specifying attributes of "classes" (I am overly
simplifying here) which would somewhat maintain a certain "coherence"
when subject to inheritance. Such coherence manifested itself in the
more or less well accepted rule (within the field) that "when a slot
is inherited" it has (1) to be unique in the sub-class and (2)
it had to be looked up using some well defined algorithm.
The uniqueness requirement is very important and it is also the reason
why I personally "believe" that CLOS programming model is easier to
understand than C++.
Then C++ came along, first with single inheritance (let's not forget
that) and then with multiple-virtual-nonvirtual-public-private-protected
inheritance. In this camp the concern was all about "how much space
does an instance take up". Moreover type issues got in the picture as
well.
As history goes, the "unique" slot approach (based mostly on the name
of the slot) is not being taught anymore, therefore as soon as you try
to explain the CPL and the way slots are inherited in CLOS, you get
the question: how do I get to the slot defined in the superclass?
I'd like to hear what people think about this.
As far as history goes we have C++ with its mostly unrememberable
rules and exceptions about inheritance, Java which does it better (I
must say I like the single data inheritance, multiple interface
inheritance rule), the last wheel on the block avec strict indentation
rules does it like frame languages of 1985 vintage, skipping the CPL
and getting into name conflicts because it does not go the all way
down the uniqueness path.
That's all folks.
Cheers
--
Marco Antoniotti =============================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
In article <···············@octagon.mrl.nyu.edu>, Marco Antoniotti
<·······@cs.nyu.edu> wrote:
> This is a rather tricky one and I believe it is there because of the
> heritage of CL as a AI language. Of course it is a by-product of
> multiple inheritance.
>
> AFAIR all the earliest "frame" languages with inheritance where
> interested in specifying attributes of "classes" (I am overly
> simplifying here) which would somewhat maintain a certain "coherence"
> when subject to inheritance. Such coherence manifested itself in the
> more or less well accepted rule (within the field) that "when a slot
> is inherited" it has (1) to be unique in the sub-class and (2)
> it had to be looked up using some well defined algorithm.
Frame languages like KEE's Units have several complex
inheritance schemes.
> The uniqueness requirement is very important and it is also the reason
> why I personally "believe" that CLOS programming model is easier to
> understand than C++.
>
> Then C++ came along, first with single inheritance (let's not forget
> that) and then with multiple-virtual-nonvirtual-public-private-protected
> inheritance. In this camp the concern was all about "how much space
> does an instance take up". Moreover type issues got in the picture as
> well.
>
> As history goes, the "unique" slot approach (based mostly on the name
> of the slot) is not being taught anymore, therefore as soon as you try
> to explain the CPL and the way slots are inherited in CLOS, you get
> the question: how do I get to the slot defined in the superclass?
>
> I'd like to hear what people think about this.
Ah, now I understand. There are several issues here.
- merging slot descriptions to an effective slot description (CLOS)
- renaming slots in subclasses (like in Eiffel)
- hiding slots of superclasses (like in C++)
- etc.
My basic mental CLOS model is that the descriptions of the superclasses
are merged and form the class. It helps to think of
classes in terms of objects (class as an instance of a meta-class).
So the class itself is a "simple" object - and not a complex
assembly of objects (class) and super (super class) objects.
Or as in C++, where it is like a complex internal structure created
inside the compiler (where classes are not objects at runtime
and no MOP is available).
I've not done much programming in the C++ style of slot
inheritance - it might be interesting to compare effects of these
approaches when designing large libraries or frameworks.
Basically this is exercise 3.2 in AMOP (see also section 4.2.3
Example: Encapsulated Methods), how to extend CLOS+MOP
with encapsulated slots.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Question 2.
> The separation between generic functions and classes puzzled people to
> no end. Although the power of multimethods was evident during the
> talk, a second issue was brought up that kind of made sense to me.
> From a certain point of view, it *does* make sense to couple methods
> with classes, since this buys you some "organizational" effect which
> may turn out to be of use in certain contexts.
they're separate, but GFs are like classes in some ways; classes HAVE
slot definitions; GFs HAVE methods. A GF is a kind of class, in a
way, defining a framework for a function object, denoting semantic
similarities among its methods. It's also a metaclass, iirc, which
seems to tie everything together at some level, though I don't know if
that concept would help your students.
dave
From: Jean-Louis Leroy
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <m3itmlipfm.fsf@enterprise.starfleet>
Marco Antoniotti <·······@cs.nyu.edu> writes:
> The separation between generic functions and classes puzzled people to
> no end. Although the power of multimethods was evident during the
> talk, a second issue was brought up that kind of made sense to me.
> From a certain point of view, it *does* make sense to couple methods
> with classes, since this buys you some "organizational" effect which
> may turn out to be of use in certain contexts.
Most people strongly associate encapsulation, inheritance and
polymorphism with classes, probably for historical reasons.
They merge into one issue what really is a combination of three
simpler issues that gain by being examined one by one.
Class and encapsulation. In languages that elect to support
encapsulation in the language, it's quite natural to have the class be
the main unit of encapsulation. Some languages add extra mechanisms:
package-private in Java, friend in C++. OO purists usually mock that
extra flexibility, not realizing that they actually provide for better
encapsulation.
Other languages rely on programmer discipline to produce
encapsulation. IMO that is quite acceptable. The programmer who
accesses fields directly, without pausing, will not hesitate to hack
C++ headers and move things to public sections.
Class and inheritance. That's a pretty natural association, which
reflects how the human mind works.
Class and polymorphism. There's the big mistake. Probably caused by
the metaphor of objects 'talking' to each other and passing
'messages'. A metaphor just as useful and just as disastrous as
picturing atoms as solar systems.
The result is sometimes hilarious. '+' is a message in Smalltalk. When
you say '2 + 3/4' the SmallInteger receiver '2' initiates a
negociation with Fraction '3/4' to decide what will the result type
be. The symmetric between the arguments is broken. CLOS, otoh, takes a
rules-based approach.
From a practical POV tieing polymorphism to classes is
disastrous, even in situations where the multimethod is actually a
monomethod (iow only one argument is truly needed in the selection
process).
C++ makes it very difficult to build three-tier apps. For example, you
want to create a Window suitable for editing a Business Object: a
PersonWindow for a Person, a DogWindow for a Dog, etc.
In C++ the easiest way is tp add a virtual function in some root
class, responsible for returning the right Window. But of course
that's not three-tier anymore.
Thus you end up using patterns like AbstractFactory to solve what is
essentially a non-problem in Lisp and other languages that have
out-of-class polymorphism.
Back to your question. IMO you've just encountered a very common case
of purity blindness. "Everything is an object". "All code must be in
methods". "Look ma, *my* language is *pure*".
Multimethods are bad because code outside classes is bad. The result
is nonsensical classes like Java's Math class. What's the meaning of
saying 'new Math', eh? Math is a class that is the description of no
object. After the Singleton, here's the Nihilon!
--
Jean-Louis Leroy
http://users.skynet.be/jll
On 8 Feb 2001, Jean-Louis Leroy wrote:
[snip]
> Class and encapsulation. In languages that elect to support
> encapsulation in the language, it's quite natural to have the class be
> the main unit of encapsulation. Some languages add extra mechanisms:
> package-private in Java, friend in C++. OO purists usually mock that
> extra flexibility, not realizing that they actually provide for better
> encapsulation.
Erhm...is it that they aren't *realizing* or they *don't* agree that "they
actually provide for better encapsulation"?
I've noticed that in Python the main large-scale unit of encapsulation and
generalization seems to be the module rather than the class or the object.
I don't know that this is a *problem* mind, but it certainly encourages a
rather different style.
(Of course, there's nothing stopping a pure OO system from building
further encapsulation features -- Smalltalk has done that a number of
times in a number of ways.)
[snip]
> Class and polymorphism. There's the big mistake. Probably caused by
> the metaphor of objects 'talking' to each other and passing
> 'messages'. A metaphor just as useful and just as disastrous as
> picturing atoms as solar systems.
Er...picturing atoms as solar systems seems often useful and rarely
disasterous.
> The result is sometimes hilarious. '+' is a message in Smalltalk. When
> you say '2 + 3/4' the SmallInteger receiver '2' initiates a
> negociation with Fraction '3/4' to decide what will the result type
> be.
No. #+ and #/ are both binary messages and have the same level of
precedence. So the actually evaluation goes like:
(2 + 3) / 4
#/ is sent to the result of sending 2 the message #+ with three as an
argument.
The classic way of implementing generalized arithmetic (e.g., 2 + 3.0) is
to use double dispatch (i.e., the initial receiver sends itself to the
argument). While there are some problems with this (most notably the
explosion of methods it naively requires) it certain *works* ;) and isn't
that hard to understand.
*Clearly* multip-dispatch is neater, espeically in this kind of case. But
I'm not sure I see a huge conceptual *breakdown*.
> The symmetric between the arguments is broken.
Well, in that *one* of the "arguments" is the receiver and the
"others" are arguments, sure. But, um, I'm not sure how to put this that
isn't sort of boring...in Smalltalk addition is accomplished by a message
not by functions. Granted, this message are eponymous with the standard
name for addition, and you might not *like* using messages to model
computations, but it's a reasonable model and seems to work well in
practice.
[snip]
> Back to your question. IMO you've just encountered a very common case
> of purity blindness. "Everything is an object". "All code must be in
> methods". "Look ma, *my* language is *pure*".
[snip]
Well, purity can be nice, if done well. There are costs associated with it
as there are costs associated with multi-paradigm systems.
Cheers,
Bijan Parsia.
From: Tim Bradshaw
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <ey3y9vekodr.fsf@cley.com>
* Bijan Parsia wrote:
> Er...picturing atoms as solar systems seems often useful and rarely
> disasterous.
I can't think of a case where it's useful...
--tim
In article <···············@cley.com>, Tim Bradshaw wrote:
>* Bijan Parsia wrote:
>
>> Er...picturing atoms as solar systems seems often useful and rarely
>> disasterous.
>
>I can't think of a case where it's useful...
>
>--tim
to explain how electrons orbit the nucleus of an atom, rough
aproxamation but it can get the basic idea across to a small child.
marc
From: Andreas Eder
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <m38zndmurm.fsf@elgin.eder.de>
····@oscar.eng.cv.net (Marc Spitzer) writes:
> In article <···············@cley.com>, Tim Bradshaw wrote:
> >* Bijan Parsia wrote:
> >
> >> Er...picturing atoms as solar systems seems often useful and rarely
> >> disasterous.
> >
> >I can't think of a case where it's useful...
> >
> >--tim
>
> to explain how electrons orbit the nucleus of an atom, rough
> aproxamation but it can get the basic idea across to a small child.
>
> marc
Well, the thing is, electrons don not orbit the nucleus of an
atom. This is just the thing that gives people the headache in
understanding what really happens. Mental pictures like that are just
too simple and too wrong to be useful.
Andreas
--
Wherever I lay my .emacs, there�s my $HOME.
In article <··············@elgin.eder.de>, Andreas Eder wrote:
>····@oscar.eng.cv.net (Marc Spitzer) writes:
>
>> In article <···············@cley.com>, Tim Bradshaw wrote:
>> >* Bijan Parsia wrote:
>> >
>> >> Er...picturing atoms as solar systems seems often useful and rarely
>> >> disasterous.
>> >
>> >I can't think of a case where it's useful...
>> >
>> >--tim
>>
>> to explain how electrons orbit the nucleus of an atom, rough
>> aproxamation but it can get the basic idea across to a small child.
>>
>> marc
>
>Well, the thing is, electrons don not orbit the nucleus of an
>atom. This is just the thing that gives people the headache in
>understanding what really happens. Mental pictures like that are just
>too simple and too wrong to be useful.
>
>Andreas
>--
>Wherever I lay my .emacs, there�s my $HOME.
I don't know, I think it is in the same class as Pi=22/7 that I got in
grade school. Things were corrected in high school and fixed some
more in college. But it got the basic point across in a limmited and
slightly incorrect fashion and the details were fixed later when I had
the math skills to understand what Pi is and how it is calculated.
marc
From: Tim Bradshaw
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <nkj3ddk2kea.fsf@tfeb.org>
····@oscar.eng.cv.net (Marc Spitzer) writes:
> to explain how electrons orbit the nucleus of an atom, rough
> aproxamation but it can get the basic idea across to a small child.
>
Yes, it's an incredibly rough approximation: you have to explain how
only certain orbits are allowed, but multiple electrons can inhabit
(and do inhabit) the same orbit, according to some rather strange
rules involving spin, how electrons can jump between orbits &c.
It does explain the `matter is mostly empty space' thing pretty well,
but it seems to fail pretty badly at most other things. I suspect this
is why the Bohr model didn't last very long (and was never intended as
mroe than a hack I think).
--tim
My other last post on this digression :)
On 12 Feb 2001, Tim Bradshaw wrote:
> ····@oscar.eng.cv.net (Marc Spitzer) writes:
>
> > to explain how electrons orbit the nucleus of an atom, rough
> > aproxamation but it can get the basic idea across to a small child.
> >
>
> Yes, it's an incredibly rough approximation:
Not for many of hydrogen. See my other post.
> you have to explain how
> only certain orbits are allowed,
It was just assumed by Bohr. The model is not very explanatory.
> but multiple electrons can inhabit
> (and do inhabit) the same orbit, according to some rather strange
> rules involving spin, how electrons can jump between orbits &c.
No, the model doesn't do any of this, nor does it purport to.
> It does explain the `matter is mostly empty space' thing pretty well,
> but it seems to fail pretty badly at most other things.
Not at all. If you check the sources I posted, you'll find that the Bohr
model is predictively accurate for hydrogen, introduced a number of ideas
that were carried on in quantum mechanics, and, sutibly modified, can be
used to explain the organization of the Periodic table. Furthermore, the
main problem with extending it (as far as I can tell) to multi-electron
atoms is the interaction between the electrons make the equations way to
complicated for anything but rough approximations. I think that's kind of
interesting.
> I suspect this
> is why the Bohr model didn't last very long (and was never intended as
> mroe than a hack I think).
It was hardly a hack, although it was not an explanatory theory. It was a
key stepping stone to full quantum mechanics. Indeed, it properly can be
seen as *introducing* the non-classical aspects of quantum mechanics (this
is how the Bohr model proper differs from a strict, Rutherfordian,
planetary model, i.e., where the particles obey classical mechanics). One
of the quantum numbers is the one Bohr used.
Cheers,
Bijan Parsia.
From: Tim Bradshaw
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <nkju25z4n4o.fsf@tfeb.org>
Bijan Parsia <·······@email.unc.edu> writes:
>
> It was hardly a hack, although it was not an explanatory theory. It was a
> key stepping stone to full quantum mechanics. Indeed, it properly can be
> seen as *introducing* the non-classical aspects of quantum mechanics (this
> is how the Bohr model proper differs from a strict, Rutherfordian,
> planetary model, i.e., where the particles obey classical mechanics). One
> of the quantum numbers is the one Bohr used.
It *was* a hack, and Bohr thought it was. I don't really have time to
get into an offtopic argument (and you've expressed unwillingness
too!), and my books are all 400 miles away (and unread for the best
part of 20 years so it would take me too long even if it was worth
it). The only things I'll say here is that the Einstein photoelectric
effect paper was a much more interesting precursor to QM than the Bohr
model, and anyway the interesting things about the Bohr model are the
restrictions in terms of allowable orbits &c and *not* the
solar-system bit of it -- the solar-system bit is useful if you
already understand the equations that govern such a system, but not
really otherwise -- a model of atoms as little organ pipes or
something would be more useful to a naive person.
Anyway, I think we should agree to differ here...
--tim
On 11 Feb 2001, Tim Bradshaw wrote:
> * Bijan Parsia wrote:
>
> > Er...picturing atoms as solar systems seems often useful and rarely
> > disasterous.
>
> I can't think of a case where it's useful...
Well, by "picturing atoms as solar systems" I understood to mean, rougly,
"the Bohr model of the atom". It was historically useful, and is still
certainly pedegogically useful. It's handy for working through valences
(IIRC) in the periodic table.
(This is interesting:
http://dbhs.wvusd.k12.ca.us/Electrons/Bohr-Model-part1.html)
If we mean "We can apply celestial mechanics to electron orbits" well
that's clearly useless.
Another: http://csep10.phys.utk.edu/astr162/lect/light/bohr.html
"The most important properties of atomic and molecular structure may be
exemplified using a simplified picture of an atom that is called the Bohr
Model. This model was proposed by Niels Bohr in 1915; it is not completely
correct, but it has many features that are approximately correct and it is
sufficient for much of our discussion. The correct theory of the atom is
called quantum mechanics; the Bohr Model is an approximation to quantum
mechanics that has the virtue of being much simpler. (Here is a more
realistic discussion of what atomic orbitals look like in quantum
mechanics.)"
Cheers,
Bijan Parsia.
From: Jean-Louis Leroy
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <m37l2xijmo.fsf@enterprise.starfleet>
Bijan Parsia <·······@email.unc.edu> writes:
> > Class and encapsulation. In languages that elect to support
> > encapsulation in the language, it's quite natural to have the class be
> > the main unit of encapsulation. Some languages add extra mechanisms:
> > package-private in Java, friend in C++. OO purists usually mock that
> > extra flexibility, not realizing that they actually provide for better
> > encapsulation.
>
> Erhm...is it that they aren't *realizing* or they *don't* agree that "they
> actually provide for better encapsulation"?
What often happened is that the other party didn't realize, then, when
given examples where not using 'friend' resulted in more things
wrongly put in the public interface, he'd still argue that friendship
is bad.
> > Class and polymorphism. There's the big mistake. Probably caused by
> > the metaphor of objects 'talking' to each other and passing
> > 'messages'. A metaphor just as useful and just as disastrous as
> > picturing atoms as solar systems.
>
> Er...picturing atoms as solar systems seems often useful and rarely
> disasterous.
...*if* you know that it's a metaphor.
> > The result is sometimes hilarious. '+' is a message in Smalltalk. When
> > you say '2 + 3/4' the SmallInteger receiver '2' initiates a
> > negociation with Fraction '3/4' to decide what will the result type
> > be.
>
> No. #+ and #/ are both binary messages and have the same level of
> precedence. So the actually evaluation goes like:
>
> (2 + 3) / 4
Oops. My example was not meant to be read as Smalltalk but as math.
> The classic way of implementing generalized arithmetic (e.g., 2 + 3.0) is
> to use double dispatch (i.e., the initial receiver sends itself to the
> argument). While there are some problems with this (most notably the
> explosion of methods it naively requires) it certain *works* ;) and isn't
> that hard to understand.
I wish I had my copy of the Blue Book here. I seem to remember that
addition was described that way. I vaguely remember a #generality
selector...
--
Jean-Louis Leroy
http://users.skynet.be/jll
On 11 Feb 2001, Jean-Louis Leroy wrote:
> Bijan Parsia <·······@email.unc.edu> writes:
>
> > > Class and encapsulation. In languages that elect to support
> > > encapsulation in the language, it's quite natural to have the class be
> > > the main unit of encapsulation. Some languages add extra mechanisms:
> > > package-private in Java, friend in C++. OO purists usually mock that
> > > extra flexibility, not realizing that they actually provide for better
> > > encapsulation.
> >
> > Erhm...is it that they aren't *realizing* or they *don't* agree that "they
> > actually provide for better encapsulation"?
>
> What often happened is that the other party didn't realize, then, when
> given examples where not using 'friend' resulted in more things
> wrongly put in the public interface, he'd still argue that friendship
> is bad.
Ah. I didn't realize that this was a *specific* person. "OO purists often
mock..." seemed to include, e.g., "Anyone who likes a pure OO language" :)
> > > Class and polymorphism. There's the big mistake. Probably caused by
> > > the metaphor of objects 'talking' to each other and passing
> > > 'messages'. A metaphor just as useful and just as disastrous as
> > > picturing atoms as solar systems.
> >
> > Er...picturing atoms as solar systems seems often useful and rarely
> > disasterous.
>
> ...*if* you know that it's a metaphor.
No. We *are* talking about the Bohr model of the atom, yes? Not some goofy
"electons are little plants with little people on them" thing?
http://csep10.phys.utk.edu/astr162/lect/light/bohr.html
The bohr model is an simplier approximation of quantum mechanics. It's
useful in roughly the same way that Newtonian mechanics is useful (as
compared to relativistc mechanics). If you only work in areas where the
approximation is fine, then you don't even need to know that it's only an
approximation (of course, I don't *endorse* ignorance!)
[snip]
> > The classic way of implementing generalized arithmetic (e.g., 2 + 3.0) is
> > to use double dispatch (i.e., the initial receiver sends itself to the
> > argument). While there are some problems with this (most notably the
> > explosion of methods it naively requires) it certain *works* ;) and isn't
> > that hard to understand.
>
> I wish I had my copy of the Blue Book here. I seem to remember that
> addition was described that way. I vaguely remember a #generality
> selector...
Here's the class comment from Squeak's Number class:
"All my subclasses participate in a simple type coercion mechanism that
supports mixed-mode arithmetic and comparisons. It works as follows: If
self<typeA> op: arg<typeB>
fails because of incompatible types, then it is retried in the following
guise:
(arg adaptTypeA: self) op: arg adaptToTypeA.
This gives the arg of typeB an opportunity to resolve the incompatibility,
knowing exactly what two types are involved. If self is more general,
then arg will be converted, and viceVersa. This mechanism is extensible
to any new number classes that one might wish to add to Squeak. The only
requirement is that every subclass of Number must support a pair of
conversion methods specific to each of the other subclasses of Number."
IIRC, squeak changed from classic double-dispatch to this model around
v.2. A classic, naive double-dispatch would resolve
self<typeA> op: arg<typeB>
as somethign like
arg<typeB> opUsingSelf'sType: self<typeA>
Which requries a method in each number class for each operation/type
combo. An explosion of methods. The generality model only requires the
coversion methods for each number type. Much less tedious, but still
annoying compared to multiple-dispatch.
An actual #adaptToFoo method looks like this:
adaptToFraction: rcvr andSend: selector
"If I am involved in arithmetic with a Fraction, convert me to a
Fraction."
^ rcvr perform: selector with: self asFraction
I've been toying with a semi multiple-dispatch design for Smalltalk which
delegates to a GenericFunction object.
self<typeA> op: arg<typeB>
as
GenericFunction evaluate: #op: with: self with: arg
I'm not sure what it would take to make this efficent, pleasent, or useful
yet :)
Cheers,
Bijan Parsia.
From: Will Deakin
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <3A87DBC3.8030304@pindar.com>
Bijan Parsia wrote:
> The bohr model is an simplier approximation of quantum mechanics. It's
> useful in roughly the same way that Newtonian mechanics is useful (as
> compared to relativistc mechanics).
No. The Bohr model is a best guess of what was going on circa
1915 and can provide a historical perspective or handwavingly
obsfucate quantum mechanics.
Newtonian mechanics *is* useful as it is the asymptotic limit of
relativistic mechanics at low speeds (v << c).
:)will
On Mon, 12 Feb 2001, Will Deakin wrote:
> Bijan Parsia wrote:
>
> > The bohr model is an simplier approximation of quantum mechanics. It's
> > useful in roughly the same way that Newtonian mechanics is useful (as
> > compared to relativistc mechanics).
> No. The Bohr model is a best guess of what was going on circa
> 1915 and can provide a historical perspective or handwavingly
> obsfucate quantum mechanics.
This is way off topic now, so this is my last post on this
topic. I'd like *some* reasonable citation for your view, please. I
confess to being 12 years or so out of physics, but I did point to
http://csep10.phys.utk.edu/astr162/lect/light/bohr.html
And the following quote:
"The most important properties of atomic and molecular structure may be
exemplified using a simplified picture of an atom that is called the Bohr
Model. This model was proposed by Niels Bohr in 1915; it is not completely
correct, but it has many features that are approximately correct and it is
sufficient for much of our discussion."
Now this is an Astronomy Course, not a course on atomic structure. But a
simplified model may be of great use precisely where the finer details do
not matter.
Another search turned up:
http://wine1.sb.fsu.edu/chm1045/notes/Struct/Bohr/Struct03.htm
"Bohr's model of the atom was important because it introduced quantized
energy states for the electrons. However, as a model it was only useful
for predicting the behavior of atoms with a single electron (H, He+, and
Li2+ ions). Thus, a different model of the atom eventually replaced Bohr's
model. However, we will retain the concept of quantized energy states."
This suggests that it may still be of use for predicting the behavior of
single electron atoms.
http://www.rwc.uc.edu/koehler/biophys/6a.html
"While the Bohr Model of the atom is primarily of historical interest to
the working physicist, it displays the essential qualities of the atom as
intuitively as possible."
Of course, it may be of more than historical interest to the working
chemist or astronomer.
http://www.chem.ualberta.ca/~plambeck/che/p101/p01222a.htm
(The two "preceeding" pages are of interest too.)
"The approach of Bohr embodied in the Bohr model of hydrogen was capable
of giving quantitative relationships with regard to the energy levels
accessible to electrons in the hydrogen atom."
No small feat. I.e., it *is* accurate there.
"The simplest extension of the Bohr model is to the one-electron ions such
as He+ and Be2+.... For these one-electron ions the Bohr model again
accurately predicts the observed line spectrum."
So, like Newtonian mechanics, the Bohr model works for a certain range of
cases. A small range perhaps, but I'm not arguing for the general
usefulness but for the correctness of it.
"Attempts to extend the Bohr model of hydrogen to atoms containing more
than one electron, however, gave results which did not agree with the
experimental line spectrum frequencies observed. Moreover, the Bohr
approach still did not explain why only certain orbits were permitted
while others were not, and why the permitted orbits differed from atom to
atom. To explain this we must now move on to the quantum theory of atoms."
And it breaks down rather quickly. But it hardly seems deceptive or
misleading to start with the Bohr model. Many of the key insights of the
Bohr model extend to quantum mechanics (like, uhm, *quantum states*).
Indeed, in the descriptions I've read browsing around, it's illuminating
to start with the assumption that the atom is like the solar system and
then strive to account for the places where it diverges. Indeed, that's
how many of the key equations are explicated.
Hardly *useless* that.
I'm not saying that the Bohr model is the be all and end all. I'm not
saying it's *as useful* as Newtonian mechanics. I'm just saying that it's
neither significant "harmful" and may be of use in a variety of
circumstances including, but not limited to, pedegogy.
> Newtonian mechanics *is* useful as it is the asymptotic limit of
> relativistic mechanics at low speeds (v << c).
And the Bohr model correctly predicts the behavior of one electron atoms.
http://edie.cprost.sfu.ca/~rhlogan/bohr.html
"The model did accurately predict the parameters of a one electron system
like the Hydrogen atom, but with multi-electron atomic systems the
predicted parameters were not forthcoming. For these reasons the Bohr
model was not the definitive answer as to what an atom looked
like. However, it was a step in the right direction. The model is still
used as a way of keeping up with the number of electrons in the various
shells or orbits."
Which is one of the uses I proposed.
Which you can see being used here:
http://www.jccc.net/~dpatter/powerpoint/ut2review/tsld107.htm
And here:
http://www.psinvention.com/periodic.htm
"The VRML 1.0 representations of the atoms are pictural aids only. They
are a slight modification of the Bohr model which shows the solar system
view of the atom. This is helpful to understand the bonding capabilities
of each atom, but in no way is actually how the atom appears."
---
http://www.treasure-troves.com/physics/BohrModel.html
"Rather amazingly, the Bohr model correctly describes the most important
properties of the hydrogen atom, most importantly producing the Balmer
formula, that are obtained using the full quantum mechanical machinery of
the Schrdinger equation."
For a cool side by side view of the bohr and schrodinger models:
http://www.colorado.edu/physics/2000/applets/schroedinger.html
---------
Anyway, enough digression. If someone wishes to show that the Bohr model
and its modifications are simply useless (including for mere study) and/or
harmful, please supply *some* references. I was *unable* to find anyone
coming out and saying "Oh, don't teach the Bohr model of the atom."
Note that understanding the *failures* of the Bohr model can be as useful
as using its successes.
Cheers,
Bijan Parsia.
From: Will Deakin
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <3A890ED9.6070204@pindar.com>
Just to continue this daftness a little further.
First:
Bijan Parsia wrote:
> The bohr model is an simplier approximation of quantum mechanics.
Which is what you would like to discuss.
Followed by:
> It's useful in roughly the same way that Newtonian mechanics is
> useful (as compared to relativistc mechanics).
Which is what I would like to discuss.
To some extent at least, I think we are talking at cross
purposes. My point is that Newtonian mechanics is orders of
magnitude more used and useful than Bohr's model.
[...elided references pointing to the use of Bohr's model...]
> confess to being 12 years or so out of physics, but I did point to
> http://csep10.phys.utk.edu/astr162/lect/light/bohr.html
>
Whatever. I've been out of Physics for about five years.
> So, like Newtonian mechanics, the Bohr model works for a certain range of
> cases. A small range perhaps, but I'm not arguing for the general
> usefulness but for the correctness of it.
(sigh). No. Newtonian mechanics mechanics works in the majority
of cases. The Bohr's model does not.
> And it breaks down rather quickly. But it hardly seems deceptive or
> misleading to start with the Bohr model. Many of the key insights of the
> Bohr model extend to quantum mechanics (like, uhm, *quantum states*).
This is a moot point. I would say it was misleading. But again
this is personal prejudice.
> I'm not saying that the Bohr model is the be all and end all. I'm not
> saying it's *as useful* as Newtonian mechanics.
I agree with this.
> I'm just saying that it's neither significant "harmful" and may
> be of use in a variety of circumstances including, but not limited
> to, pedegogy.
I disagree. However, don't stress -- take a chill pill. This is a
matter of opinion over which I (and it seems that some other
people) disagree with you about. In my case it's just not very
strongly or something that keeps me awake a night.
For that matter I might change my mind and agree with you next week.
> I'd like *some* reasonable citation for your view, please.
This is a tricky one because AFAIK there are none. If I was to
search Phys. Rev. Lett., say, and find no reference to Bohr's
model I would then have not found a reasonable citation for the
view that the Bohr's model is a chocolate teapot.
Having studied physics for a bit (solid state physics, optics,
&c.) and read hundreds, maybe a thousand or so papers and a
half-a-dozen or so theses I cannot recall the use of the Bohr's
model in any sensible or useful way. However, I can think of many
that use of newtonian mechanics. Or Gallilean transformations or
the corpuscular and wave theories of light ... burble burble.
So my citations are anecdotal. Anyway, having spent enough time
on this already,
Addio e distinti saluti,
:) Will
From: Howard Stearns
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <3A82B58D.D3919B07@curl.com>
Marco Antoniotti wrote:
> I gave two talks about CL in a seminar at NYU.
> ... The second one raised one
> controversial point and ... I'd like to get
> an opinion on these issues ...
> ...
> Question 2.
> The separation between generic functions and classes puzzled people to
> no end. Although the power of multimethods was evident during the
> talk, a second issue was brought up that kind of made sense to me.
> From a certain point of view, it *does* make sense to couple methods
> with classes, since this buys you some "organizational" effect which
> may turn out to be of use in certain contexts.
Here's how I answered the same question from a coworker this very week:
IFF an operation is clearly owned by a single object, which you also
happen to own the source for, then generic functions and classes can
certainly be organized into the same files and proximate definitions.
You are no worse off than in method-table style OOPLs.
If that's the situation, and fascism^H^H^H^H^H^H^Hrestrictive disiplines
makes you feel warm and fuzzy, then you can can define a package that
has no DEFMETHOD and defines a shadowing DEFCLASS macro that includes
single dispatch method definition. You can even make the the dispatch
be on an implicit first argument of 'self' if you like.
You can also paint the world blue and say, "Look how nicely everything
is organized! Everything is the same pretty shade of blue!" I find no
comfort in trying to pretend the world is blue:
1. I *do* need to sometimes add behavior to a class I don't own. Maybe
the the class is defined by a library that also defines operators that
return and consume such classes. It is often disgusting or
inefficient, and sometimes impossible, for me to add the behavior
through delegation/shadow-networks or through wrapper/container classes.
2. There *are* operations that are just as much a part of the behavior
of the class of one argument as of the class of another argument. How
does it make the world clearer by being forced to define the behavior in
both places, where one of the "definitions" is just a code-bloating,
bookkeeping, dispatch/glue method? How do you decide which class gets
the junk and which gets the "real" method?
Even in these cases, generic functions can be located in IDE's (through
"Edit Definition" commands) and can be identified as being related to
particular classes (through reflective MetaObject Protocols). The same
organizational information is present as in the method-table paradigm,
but generalized.
This situation presents two common examples from the "language wars":
1. Languages develop in the real world, with real time constraints and
real mistakes by their creators. Backers latter justify design flaws
after the fact by trying to find some benefit to a restriction. That
doesn't make the design right. (Look at the praise for single dispatch
and "interfaces" in Java!)
2. No language is optimal for every situation, and one should try to use
the right tool for the job. If a language can provide some signficant
benefit by imposing a restrictive discipline, than it's fine to use that
language for a task that actually fits that paradigm. However, if (a
big IF?) you can have all the same benefits with a "more colorful" view
of the world, then it's just plain stupid to restrict yourself.
Alas, I confess that my argument was apparently unpersuasive to my
coworker, and I don't know why.
From: Thomas A. Russ
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <ymiu265rrvu.fsf@sevak.isi.edu>
Howard Stearns <·······@curl.com> writes:
> You can even make the the [single] dispatch
> be on an implicit first argument of 'self' if you like.
I'm sorry, but 'self' is deprecated. You need to make it dispatch on
'this' instead.
:) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :)
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
From: Marco Antoniotti
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <y6cn1bvbxp5.fsf@octagon.mrl.nyu.edu>
···@sevak.isi.edu (Thomas A. Russ) writes:
> Howard Stearns <·······@curl.com> writes:
>
> > You can even make the the [single] dispatch
> > be on an implicit first argument of 'self' if you like.
>
> I'm sorry, but 'self' is deprecated. You need to make it dispatch on
> 'this' instead.
>
Isn't Newspeak wonderful? :)
Cheers
--
Marco Antoniotti =============================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
From: Marco Antoniotti
Subject: Re: Two philosophical questions about inheritance and objects.
Date:
Message-ID: <y6c1yt9mbqk.fsf@octagon.mrl.nyu.edu>
Howard Stearns <·······@curl.com> writes:
> Marco Antoniotti wrote:
...
> > with classes, since this buys you some "organizational" effect which
> > may turn out to be of use in certain contexts.
>
> Here's how I answered the same question from a coworker this very week:
>
> IFF an operation is clearly owned by a single object, which you also
> happen to own the source for, then generic functions and classes can
> certainly be organized into the same files and proximate definitions.
> You are no worse off than in method-table style OOPLs.
>
...
I agree with what I deleted. :)
> This situation presents two common examples from the "language wars":
>
> 1. Languages develop in the real world, with real time constraints and
> real mistakes by their creators. Backers latter justify design flaws
> after the fact by trying to find some benefit to a restriction. That
> doesn't make the design right. (Look at the praise for single dispatch
> and "interfaces" in Java!)
Well, I do see the point in Java restriction. But then again it is
what it is. A restriction :) Note that such restriction is really a
fix to the lack of "uniqueness" in slot names present in non AI/Lisp
worlds.
> 2. No language is optimal for every situation, and one should try to use
> the right tool for the job.
Granted. I'd rather use Esteres if I were working on reactive systems.
> If a language can provide some signficant
> benefit by imposing a restrictive discipline, than it's fine to use that
> language for a task that actually fits that paradigm. However, if (a
> big IF?) you can have all the same benefits with a "more colorful" view
> of the world, then it's just plain stupid to restrict yourself.
>
> Alas, I confess that my argument was apparently unpersuasive to my
> coworker, and I don't know why.
Now you see why I asked these questions. :)
Cheers
--
Marco Antoniotti =============================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
On 07 Feb 2001 14:48:40 -0500, Marco Antoniotti <·······@cs.nyu.edu> wrote:
> I gave two talks about CL in a seminar at NYU. They went pretty well,
> especially the first one (macros and macro-characters can do miracles
> to dazzle an unsuspecting audience). The second one raised one
> controversial point and one not so controversial one. I'd like to get
To deal with such "philosophical" issues I find it useful to check
resources that provide the big picture on CLOS and its design, rather than
focusing on its features and usage.
I recently run across a couple such resources. The first is a chapter by
David Moon in the book:
"Object-Oriented Concepts, Databases and Applications"
W. Kim and F.H. Lochovsky (editors)
ACM Press, 1989
ISBN 0-201-14410-7
The second resource is a videotaped lecture on CLOS by Daniel Bobrow. I
don't have the exact references handy. But since they are both available at
the CS department's library, I can check them if you are interested.
> One of the things I like the most in CLOS is that slot
> names are paramount. You do not have to mess around with 'class
> qualifiers' to get the right slot from the right class. A couple of
> people very keen on their "newly reinvented wheel avec forced
> indentation rules" said that CLOS behavior is as ambiguous as in their
> "new round shape". I must say that I did not have a convincing answer
Huh... I don't understand the question.
> The separation between generic functions and classes puzzled people to
> no end. Although the power of multimethods was evident during the
This is one of the things that Bobrow explains clearly in the above
mentioned lecture. He illustrates the most important CLOS design decisions,
and then shows how major features of the language are a consequence of such
decisions.
If I remember correctly, the separation between generic functions and
classes is a "natural" consequence of the decision of using function calls
for invoking object behavior instead of message sending, as was done in
earlier Lisp object-oriented extensions.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/