Larry Wall on multiple dispatch (!!!)
Rainer Joswig
http://www.perl.com/pub/a/2007/12/06/soto-11.html?page=2
single dispatch / multiple dispatch
In a sense, multiple dispatch is a way to delay binding even
longer. You not only have to delay binding 'til you know the type of
the object, but you also have to know the types of all rest of the
arguments before you can pick a routine to call. Python and Ruby
always do single dispatch, while Dylan does multiple dispatch. Here is
one dimension in which Perl 6 forces the caller to be explicit for
clarity. I think it's an important distinction for the programmer to
bear in mind, because single dispatch and multiple dispatch are
philosophically very different ideas, based on different metaphors.
With single-dispatch languages, you are basically sending a message to
an object, and the object decides what to do with that message. With
multiple dispatch languages, however, there is no privileged
object. All the objects involved in the call have equal weight. So one
way to look at multiple dispatch is that the objects are completely
passive. But if the objects aren't deciding how to bind, who is?
Well, it's sort of a democratic thing. All the routines of a given
name get together and hold a political conference. (Well, not really,
but this is how the metaphor works.) Each of the routines is a
delegate to the convention. All the potential candidates put their
names in the hat. Then all the routines vote on who the best candidate
is, and the next best, and the next best after that. And eventually
the routines themselves decide what the best routine to call is.
So basically, multiple dispatch is like democracy. It's the worst way
to do late binding, except for all the others.
But I really do think that's true, and likely to become truer as time
goes on. I'm spending a lot of time on this multiple dispatch issue
because I think programming in the large is mutating away from the
command-and-control model implicit in single dispatch. I think the
field of computation as a whole is moving more toward the kinds of
decisions that are better made by swarms of insects or schools of
fish, where no single individual is in control, but the swarm as a
whole has emergent behaviors that are somehow much smarter than any of
the individual components.
(!!!)
Barry Margolin
Rainer Joswig <jos...@lisp.de> wrote:
> So basically, multiple dispatch is like democracy. It's the worst way
> to do late binding, except for all the others.
>
> But I really do think that's true, and likely to become truer as time
> goes on.
Greenspan's Law lives!
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
André Thieme
Or pattern matching, and we have even more freedom and flexibility.
--
André
Kent M Pitman
Interesting reading as a window into someone's mind. Lots of raw data
about how one person's random experiences and preferences/prejudices
and whatnot can drive a person in a certain direction.
The remarks on Lisp on page 1 give one the definite sense that his
info about Lisp is very old, but that he's comfortable sharing it. I
wonder if he'd feel as good about people sharing very old information
about PERL as if it were current.
Make sure to go to page 3 where you can read an unrebutted (as of the
time I post this) respondent say that there is a factor of 500
difference in speed between Lisp and C. Perhaps somebody with more
energy than I have tonight might want to investigate how to post a
correction to that random misinformation.
And Dylan is credited in Wall's remarks with multiple dispatch (even
though his Lisp entry makes no mention of CLOS, which heavily
influenced Dylan). Also, back on page 1, Lisp is passed over as a
failed scripting candidate wannabe, while Dylan is not judged at all
on the basis of its scripting candidate nature, giving the sense that
it is not failed in that regard--even though, if anything, Lisp is
probably much easier to do rapid prototyping with (lots less syntactic
baggage, if nothing else).
He also maligns Lisp and its syntax when talking about TCL, and yet
Lisp has readtables that are hugely more flexible than TCL's strings.
So again, just a confusion/prejudice that makes the piece weaker.
Then again, if you start (as the article does) by saying that in a
scripting language everything is a string and worse-is-better is
preferred, maybe it's best we are out of the running. ... even though
I think emacs-lisp would easily serve as a scripting language. And
Lisp has plenty of support for strings.
Ah well. An interesting read in spite of it all, if only to learn how
one person thinks...
Leslie P. Polzer
Kent, you're preaching to the converted here.
Consider sending this to Mr. Wall or posting it somewhere visibly.
> Then again, if you start (as the article does) by saying that in a
> scripting language everything is a string and worse-is-better is
> preferred, maybe it's best we are out of the running.
Yes, we are, but only because we're miles ahead in a world where worse
is better. I remember the diagram Kenny posted a few days ago:
C -> C++ -> Java -> Python -> Ruby (-> Arc) -> Lisp
*wink*
Anyway, who really cares about that. CL is alive and kicking, and we
surely all benefit from using it.
Leslie
Alan Crowe
> André Thieme <address.good.un...@justmail.de> writes:
>
> > Rainer Joswig schrieb:
> > > http://www.perl.com/pub/a/2007/12/06/soto-11.html?page=2
> > >
> > > single dispatch / multiple dispatch
> >
> > Or pattern matching, and we have even more freedom and flexibility.
>
> Interesting reading as a window into someone's mind. Lots of raw data
> about how one person's random experiences and preferences/prejudices
> and whatnot can drive a person in a certain direction.
>
> The remarks on Lisp on page 1 give one the definite sense that his
> info about Lisp is very old, but that he's comfortable sharing it.
Since you are interested in musing on the diversity of human
experience, let me tell you my tale. I only offer half the
tale, partly for brevity, partly because c.l.l. is not the
place for self-disclosure, and partly to bring out the
contrast with what Larry Wall writes:
> Is LISP a candidate for a scripting language? While you
> can certainly write things rapidly in it, I cannot in good
> conscience call LISP a scripting language. By policy, LISP
> has never really catered to mere mortals.
>
> And, of course, mere mortals have never really forgiven
> LISP for not catering to them.
My tale takes an unhappy turn in 1991 when I fall ill with
Post Viral Fatigue Syndrome. A bad case. It is early 2000
before I think about plotting a route back to work, a goal
that is over the horizon, but perhaps realistic.
I programmed digital signal processing algorithms in C in my
previous job and decide to learn C++ to come up to date.
Not such a smart decision. My concentration is not really
solid enough to survive the disruption of the
edit-compile-run cycle; I would have been better off with
something interpreted. My god, the syntax! Do I want & or
&&? Do they bind tighter than = , shit I mean == . Is *
unary prefix or binary infix? How do I know I've got the
right entry in the precedence table? I used to know this
stuff.
I cope as best I can. Object oriented programming has come
in and I need to learn about it if I'm ever to get back to
work. There are references *and* pointers. I struggle with
the "friend" stuff. I slowly start to realise that I am not
the only person with brain damage.
By March 2001 I've had enough and write in my lab notebook
I've given up trying to learn C++ from Schildt, and now
I'm learning ANSI Common Lisp from Graham.
What a relief. I only have to remember '(' to start a list,
')' to end a list, and ' ' to separate list items. No
operator precedence. No distinction between statements and
expressions. Both
if(antecedent) consequent; else alternative;
and
(antecedent?consequent:alternative)
are replaced by a single form, simpler than either.
No defensive insertion of extra '{' and '}'
because of the sometimes unexpected consequences of the
rules on where the ';' go.
Integers obey n+1 > n
Memory allocation is automagic.
If I'm having a bad day I can just type some forms in at the
REPL. I can keep in practice and not forget what I'm trying
to learn even if I'm not well enough to code. The REPL can
even function as an artificial friend. We chat about
Lisp. What type is this? What does that do? Are the
structures shared? I need to lie down for half an hour,
don't go away, I'll ask you what you know, apropos strings,
when I get back.
CL is a simple language whose ease of use provides me with
enjoyable occupational therapy for my disabling neurological
condition.
That is my reality. That is how CL looks from my 200 square
meters of the planet. It is a big planet, with plenty of
room for other radically different perspectives. We could
start by noting that CL is only simple in the sense that the
complicated stuff is optional, (if you code in CL-USER you
need never find out whether packages are simple or not) and
follow up with "hello world" in Java, to emphasise the
importance of whether complications are optional or
not. Let's not go there.
I want to come back to Larry Wall's perspective
> By policy, LISP has never really catered to mere mortals.
>
> And, of course, mere mortals have never really forgiven
> LISP for not catering to them.
What am I supposed to make of this? Larry Wall is a talented
writer with a fine turn of phrase. Has he got carried away,
crafting a witticism that goes far beyond his intended
meaning? I sense that he is playing to the crowd, crafting a
fine pair of sentences to give voice to a common sentiment,
but it also seems genuine. He is cheer leading for his own
views.
We can reconcile my perspective on CL with many other
views. A swimming pool has a shallow end and deep end. When
a child first visits the seaside and enjoys playing in the
surf as the tide comes gently in over sun warmed sand he may
declare that he likes this shallow end, it is much more fun
than the shallow end at the pool back home. Clearly one can
compare shallow ends while knowing nothing of the depths.
I hope that Kent will smile on me, splashing happily in the
shallows of CL and not feel that my perspective disparages
his work. He may even be pleased that it has an application
he could never have imagined.
I don't see how to reconcile Larry's perspective with
mine. There is something seriously, desperately wrong
here.
It makes me think about the Treviso Arithmetic of 1478. Over
the course of four or five hundred years decimal arithmetic
moved from being the new fangled thing taught in
universities to being something to be mastered by 11 or 12
in preparation for algebra.
Are we living through a period of extremely rapid change in
which a similar change is compressed into less than a
decade? Perhaps Larry and his audience belong to the
pre-transitional generation for whom recursion is scary and
difficult, while I, with an early start I've not discussed,
belong to the post-transitional generation.
Alan Crowe
Edinburgh
Scotland
Andrew Reilly
> I want to come back to Larry Wall's perspective
>
>> By policy, LISP has never really catered to mere mortals.
>>
>> And, of course, mere mortals have never really forgiven LISP for not
>> catering to them.
>
> What am I supposed to make of this? Larry Wall is a talented writer with
> a fine turn of phrase. Has he got carried away, crafting a witticism
> that goes far beyond his intended meaning? I sense that he is playing to
> the crowd, crafting a fine pair of sentences to give voice to a common
> sentiment, but it also seems genuine. He is cheer leading for his own
> views.
Maybe he's just stroking the egos of present-day lisp users, so that they
don't hassle him about his non-lispy design decisions? How can one take
him to task, when he's called you an immortal super-being?
--
Andrew
OMouse
This is simple. You can take him to task for not appealing to the
elites. After all, the elites are the hope of the future! The immortal
super-beings are the ones that make the tools for the mere mortals to
use, so why not give them the greatest tools ever?
-Rudolf
ozan s yigit
> André Thieme <address.good.un...@justmail.de> writes:
>
> > Rainer Joswig schrieb:
> > > http://www.perl.com/pub/a/2007/12/06/soto-11.html?page=2
> > >
> > > single dispatch / multiple dispatch
> >
> > Or pattern matching, and we have even more freedom and flexibility.
> ...
>
> And Dylan is credited in Wall's remarks with multiple dispatch (even
> though his Lisp entry makes no mention of CLOS, which heavily
> influenced Dylan).
>
> ...
hmm, i doubt dylan is mentioned for for credit; it is an interesting
OO language most of his audience would easily remember. actual credit
would go to commonloops, not clos, as remember it, wikipedia and
occasional FAQs notwithstanding.
oz
---
music is the space between the notes. -- claude debussy
Kent M Pitman
> hmm, i doubt dylan is mentioned for for credit; it is an interesting
> OO language most of his audience would easily remember. actual credit
> would go to commonloops, not clos, as remember it, wikipedia and
> occasional FAQs notwithstanding.
Sure. I wasn't really worried about "credit" for CLOS. I'm sure the
genealogy of that facility is well-documented. CLOS does descend from
PCL / Common Loops / LOOPs on one line of parentage and New Flavors on
the other... and New Flavors didn't have multiple dispatch, so I'm
pretty sure it was gotten from the Loops side of the tree (though I
never looked very closely at Common Loops, probably because the name
kept making me [mistakenly] think it was some sort of iteration
facility I didn't need).
All I was caring about for this forum is that LISP was treated as if
it were not in the line of inheritance. There was an apparent attempt
to speak of knowing LISP, and then to parlay that "credential" into a
believable statement about its alleged weaknesses and to add basis to
the notion that its alleged weaknesses were not only present but in
fact 'all-defining'... And then, on top of that, there was a following
mention of something that most people who _do_ know Lisp would say is
a huge feature of it without acknowledging that fact... and so by its
omission in the article to give a further and I think false sense that
Lisp has no redeeming value. Clearly, just one person's opinion, and
I thank him for documenting his opinion. I just think he could have
leaned a little harder on the idea that he had not done the full
research he might have before disparaging Lisp in a way that might
influence people today to act on knowledge that was questionable years
ago and is certainly moreso today.
Alan Crowe offers an entirely other post, personal to himself (and,
importantly, identified as such), that places LISP in a different
and very contrasting light. In it, he writes:
> What am I supposed to make of this? Larry Wall is a talented
> writer with a fine turn of phrase. Has he got carried away,
> crafting a witticism that goes far beyond his intended
> meaning?
I recommend the entirety of Alan's remarks to anyone who missed them.
http://groups.google.com/group/comp.lang.lisp/msg/46574421ae03909d
I've not been through the particular experiences he's been through,
and yet the things he describes have analogs in my universe. I loved
the sentence:
> The REPL can even function as an artificial friend.
and the accompanying text that gives amazing texture to this remark.
John Stoneham
> ...
> CL is a simple language whose ease of use provides me with
> enjoyable occupational therapy for my disabling neurological
> condition.
Alan,
Thank you for sharing such an inspirational post. It reminded me of
why I fell in love with CL in the first place, and made me reprimand
myself for looking elsewhere when I became bored with her beauty.
It will be a long time before I don't think of your post when I code.
Godspeed,
John