[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Jonathan Rees on OO
At 03:42 PM 12/11/01, Paul Graham wrote:
>I've been talking to a number of smart hackers about the
>the question of what to do about object-oriented programming
>in Arc. Jonathan Rees just sent me a such an excellent
>dissection of the whole problem that (with his permission)
>I put it online:
>Jonathan designed both T and (with Richard Kelsey) Scheme 48,
>and he has thought a lot about these issues. Language
>designers who have worried about the question will likely
>find this clarifies matters. (I recommend it esp. to Scott
>McKay, who seems to think it is a waste of time to define a
>new Lisp that isn't Dylan.)
Allow me to flatly contradict your misstatement of my opinion.
I have *never* asserted that defining a new Lisp is a waste of time.
I *do* think that it is a waste of time for anyone who has not
learned the lessons from CLOS and Dylan, to define a new Lisp. I
have criticized Arc because I don't think you have done your homework.
I think that Proto, e.g., is a *much* better attempt to define a
Rees's characterization of OO looks to me like a strawman built
to look like roughly like Java's model, which he then knocks down.
It might have been better to start with a different take on OO. Just
to pull your chain, here's a thumbnail of the Dylan model, which is
a refined (*) version of the CLOS model in which:
1. Encapsulation is provided by hiding access behind function calls.
2. Protection is provided by the module system, not by classes.
3. Ad hoc polymorphism works "the usual way".
4. Parametric polymorphism works because it is objects all the way
5. Everything is a true object.
6. "All you can do is call a function". There is no access to slots (fields)
without calling a function.
7. Sadly, there are no interfaces in Dylan, although you can use an
abstract class to do a pretty good job of simulating them (Dylan should
have grabbed Flavor's :required-methods or something :-)
8. Code reuse is provided by multiple-inheritance, though this is a tool
that needs to be used carefully.
9. There is no distinguished "method key argument". Objects are functions;
functions are functions.
In Dylan, when you want some state, define a class. When you want a
new operation, define a function. When you want to make the functionality
available to clients, you export it from a module. If you don't want
don't use it. If you don't want polymorphism, don't use it.
As far as I can tell -- to borrow Rees's words -- you and he are anti-OO
zealots trying to convince people like me that we are losers. Sorry, I
don't buy it. Rees is preaching to a choir consisting mainly of you. If
you don't like that OO is a "moving target", then use Arc as an opportunity
to pin it down usefully and then move forward.
(*) So why is Dylan a refined version of CLOS, why did it come out mostly
better than CLOS? Well, duh, it's because several of the really smart guys
who helped design CLOS learned something from doing that, and then went
and designed Dylan. Lest any of you think that I am speaking in code about
myself, I will say for the record that I had *nothing* to do Dylan at the
object system was being designed.