Interesting thread between Bob Harper & William Cook

[David Nolen]

http://wcook.blogspot.com/

These are from a private exchange so I think Bob Harper comes off as being overly curmudgeonly. If you ignore that I think William Cook's points are quite good with regards to OOP.

David

[Paul deGrandis]

I was just about to post this to the list.

It's interesting to see William's definition of OO emerge as,
"Representing data and behavior as collections of higher-order
functions *is* the essence of OO."

This mostly holds true with the core notions of OO as set by Smalltalk
and later by The Gang of Four, but I think there is a significant
difference between the "essence of OO" and OOP realized. I also
wouldn't necessarily attribute higher-order to object orientation.

I think Steve Yegge, Paul Graham, and Rich Hickey all elegantly speak
to this conceptual drift:
http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html
http://www.paulgraham.com/noop.html
(Just look at Clojure's rationale or any piece about "Clojure does OO
better than Java")

I also really liked Bob's news release about changing intro CS courses
at CMU.
http://www.infoq.com/news/2011/03/oop-out-at-cmu

Paul

[Patrick Logan]

My favorite quote in that series comes from an anonymous comment...

"OO has been a success because it's a useful way for *humans* to think
about problems. Type theorists didn't know that."

Which is not to say they have to be at odds with each other, but for
much of this history of popular programming, they have been largely
ignorant of each other. And that's arguably evident in that exchange.

Twenty years ago or so there was a lot made of the American
("mechanical", "pragmatic") compared to the European ("theoretical",
"pure") schools of programming. A quick search did not turn up
anything for me. Does anyone have a recollection or a reference?

-Patrick

[David Nolen]

On Sat, Mar 3, 2012 at 5:32 PM, Patrick Logan <patric...@gmail.com> wrote:

"OO has been a success because it's a useful way for *humans* to think
about problems. Type theorists didn't know that."

I disagree that OO's success is primarily because it's how people *think*. Trying to teach OO concepts to students has done enough to dispell that fantasy, at least for me. That said, OO's success has far more to do with not limiting (or not overly complicating) what we want to *express*. 

IMO, this William Cook essay is a pretty stunning and approachable read on the nuances on the subject:

http://www.cs.utexas.edu/users/wcook/Drafts/2009/essay.pdf

 

[Michael J. Forster]

Hi,

While this might consistent with the popular "definition" of OO and
even with Smalltalk 80, I'm disappointed that Cook, who is familiar
with the history of Smalltalk and who has met Alan Kay, perpetuates
the following misunderstanding about what Kay considered to be the
essence of OO:

Emails with Bob Harper #6
... "message passing" simply means "calling a function value
selected form a structure of functions"

Cheers,

Mike

[David Nolen]

On Sat, Mar 3, 2012 at 5:31 PM, Michael J. Forster <mi...@sharedlogic.ca> wrote:

   Emails with Bob Harper #6

   ... "message passing" simply means "calling a function value
selected form a structure of functions"

Cheers,

Mike

Then explain what you think the actual difference is. Personally, I don't see how the subject won't get mired in irrelevant implementation details.

David

[Patrick Logan]

First, that person's quote is far too brief for me to be sure what was intended. But generally it's indicative of people being effective with the common OOPLs, at least combined with a few good practices.

Second, I think I would have expressed something more like what you just wrote, David. Something that would be supported by nearly all of my posts to comp.object through the 90's and into the 2000's. ie. I am far from the opinion that "OOP lets you just model the real world "

I am simply of the "black-diamond run" school of OOP... ie. OOP's "edge" is merely the dynamic message send and method selector. Not much more than that.

-Patrick

[Michael J. Forster]

On Sat, Mar 3, 2012 at 5:27 PM, David Nolen <dnolen...@gmail.com> wrote:
[...]

>
> Then explain what you think the actual difference is. Personally, I don't
> see how the subject won't get mired in irrelevant implementation details.
>
> David
>

Hi,

Cook equates passing a message with calling a function, even if
decoupled by use of a lookup. Yes, that's what ST-80 does, and, yes,
that's what Steele and Sussman arrived at in Scheme's eval/appy core
while exploring Hewitt's Actor Model. However, that's not what Kay
was after (nor is Scheme an Actor language). Kay was very clear about
his goal: FEXPRS (see below).

My concern is, precisely, that people think this an "irrelevant
implementation" detail, when it is, in fact, a profound shift.
Witness: 1) the difference between Erlang messaging and STM; and 2)
the difference between the lambda calculus and the vau calculus of
John Shutt's Kernel.

"I could hardly believe how beautiful and wonderful the idea of LISP
was. I say it this way because LISP had not only been around enough to
get some honest barnacles, but worse, there were deep flaws in its
logical foundations. By this, I mean that the pure language was
supposed to be based on functions, but its most important components
-- such as lambda expressions, quotes, and conds -- were not functions
at all, and instead were called special forms. Landin and others had
been able to get quotes and cons in terms of lambda by tricks that
were variously clever and useful, but the flaw remained in the jewel.
In the practical language things were better. There were not just
EXPRs (which evaluated their arguments), but FEXPRs (which did not).
My next questions was, why on Earth call it a functional language? Why
not just base everything on FEXPRs and force evaluation on the
receiving side when needed?

I could never get a good answer, but the question was very helpful
when it came time to invent Smalltalk, because this started a line of
thought that said 'take the hardest and most profound thing you need
to do, make it great, an then build every easier thing out of it.'"

Alan Kay,
The Early History of Smalltalk.,
in: Bergin, Jr., T.J., and R.G. Gibson.
History of Programming Languages - II,
ACM Press, New York NY, and
Addison-Wesley Publ. Co., Reading MA 1996,
pp. 511-578

Cheers,

Mike

[David Nolen]

You're just skirting around the issue. Alan Kay just wanted to see if we could eliminate special forms. Of course it turned out to not really be practical. In Smalltalk and even in Haskell if is still handled in a special manner.

So in what way is OOP not pervasive higher order functional programming again and vice versa?

[Michael J. Forster]

On Sat, Mar 3, 2012 at 6:07 PM, David Nolen <dnolen...@gmail.com> wrote:
> You're just skirting around the issue. Alan Kay just wanted to see if we
> could eliminate special forms. Of course it turned out to not really be
> practical. In Smalltalk and even in Haskell if is still handled in a special
> manner.

Not my intention. And Kay was after more than that: As the second
paragraph suggests, eliminating special forms was a step toward his
goal. That they fell short of that goal in the name of efficiency on
hardware of the day is something he has acknowledged. Today, Erlang
and Kernel take it further.

> So in what way is OOP not pervasive higher order functional programming
> again and vice versa?

I didn't claim it wasn't. Nor did I state a preference for any
definition of OO (my preference would be to drop it in favour of
precise definitions of the various and different notions that lay
claim to it). Cook's papers and posts shed some welcome light on
procedural data abstraction in contrast to ADTs -- that they are
different, complementary, and useful -- despite the fact that they
have both been considered to be OO by different people at one time or
another.

No, what I said, in different words, was that I was disappointed that
Cook swept "messaging" under the rug, because understanding it as more
than function lookup and application is significant. It was the key
aspect of Smalltalk 72 that intrigued, separately, Carl Hewitt and Joe
Armstrong. Now, we see it emerging again in Kernel, and it's not just
higher order functional programming.

Cheers,

Mike

[David Nolen]

On Sat, Mar 3, 2012 at 10:11 PM, Michael J. Forster <mi...@sharedlogic.ca> wrote:

Not my intention. And Kay was after more than that:  As the second
paragraph suggests, eliminating special forms was a step toward his
goal.  That they fell short of that goal in the name of efficiency on
hardware of the day is something he has acknowledged.  Today, Erlang
and Kernel take it further.

Kernel is slow. The fundamental control forms in Erlang don't use message passing.

 

No, what I said, in different words, was that I was disappointed that

Cook swept "messaging" under the rug, because understanding it as more
than function lookup and application is significant.  It was the key
aspect of Smalltalk 72 that intrigued, separately, Carl Hewitt and Joe
Armstrong.  Now, we see it emerging again in Kernel, and it's not just
higher order functional programming.

I only understand messaging as a form of late binding. Higher order function invocation is precisely that - a form of late binding. In fact static-y OO languages like JavaScript actually require you to wrap actions in functions in order to get the benefits of messaging!

For example where in Ruby we can do this:

coll.map(&:message)

In JavaScript we need:

coll.map(function(x) { return x.message(); }

David

[Kartik Agaram]

Some of the tone of that exchange seems to be infecting this thread,
which is most distracting.

> So in what way is OOP not pervasive higher order functional programming
> again and vice versa?

Cook says something similar as well: "To me, saying 'OO is crap' is
equivalent to saying 'collections of functions are crap'."
(http://wcook.blogspot.com/2012/03/emails-with-bob-harper-6.html)

I speculate that such reductionist arguments are not persuasive to Bob
Harper. This is more a battle of different aesthetics than anything
else. FP concepts hang well together, but adding OO concepts seems
redundant. And vice versa. Perhaps "OO is crap" means, "giving just
plain collections of functions a high-falutin' name is crap".

[Kartik Agaram]

"I took a peek at the new chapters in your book about dispatch and
inheritance. It is not a satisfactory presentation at all. In the rest
of the book you describe computation models abstractly, but in your OO
sections you manage to describe some low-level implementation
techniques for objects without capturing their conceptual essence at
all." (http://wcook.blogspot.com/2012/03/emails-with-bob-harper-11.html)

Without reading the chapters he's referring to, that sounds like a
reductionist argument from the FP side. Which seems like more evidence
for my thesis.

[David Nolen]

I hope the tone here is a tad less contentious! :)

Having tried both OO and FP approaches and wondered at their similarity, I wonder if people simply enjoy drawing distinctions where perhaps none exist. The William Cook essay just confirmed a long held suspicion for *me*. If people don't agree then I'm asking for reasoned arguments why the conclusions doesn't sit well with you!

David

[Michael J. Forster]

On Sat, Mar 3, 2012 at 9:32 PM, David Nolen <dnolen...@gmail.com> wrote:
> On Sat, Mar 3, 2012 at 10:11 PM, Michael J. Forster <mi...@sharedlogic.ca>
> wrote:
>>
>> Not my intention. And Kay was after more than that:  As the second
>> paragraph suggests, eliminating special forms was a step toward his
>> goal.  That they fell short of that goal in the name of efficiency on
>> hardware of the day is something he has acknowledged.  Today, Erlang
>> and Kernel take it further.
>
>
> Kernel is slow. The fundamental control forms in Erlang don't use message
> passing.

Well, I didn't claim FEXPRs were practical... yet :-D

And, true, Erlang does provide HOF for _sequential_ programming, while
messaging is the control flow for concurrent programming.

[...]

> I only understand messaging as a form of late binding. Higher order function
> invocation is precisely that - a form of late binding. In fact static-y OO
> languages like JavaScript actually require you to wrap actions in functions
> in order to get the benefits of messaging!

No disagreement; I'm only emphasising that Kay, in his original
definition of OO, was aiming for a step beyond function invocation.
(By now, I hope that you get that I'm not trying to belabour
defintions. :-)

Cheers,

Mike

[Michael J. Forster]

Yeesh. Yes, I think (hope) that David knows that I quite appreciate
the time and thoughtfulness he's investing in conversing with me.

Mike

[Kartik Agaram]

On Sat, Mar 3, 2012 at 15:10, David Nolen <dnolen...@gmail.com> wrote:
> IMO, this William Cook essay is a pretty stunning and approachable read on
> the nuances on the subject:
> http://www.cs.utexas.edu/users/wcook/Drafts/2009/essay.pdf

Thanks; I'm struggling with it (http://arclanguage.org/item?id=15999)

On Sat, Mar 3, 2012 at 13:39, Paul deGrandis <paul.de...@gmail.com> wrote:
> I also really liked Bob's news release about changing intro CS courses
> at CMU. http://www.infoq.com/news/2011/03/oop-out-at-cmu

This post led me to Barbara Liskov's turing award lecture:
http://www.infoq.com/presentations/liskov-power-of-abstraction

Among other things, I realized that she was inventing ADTs around the
same time Alan Kay was building smalltalk and so inventing OO. That
was an interesting historical context to William Cook's essay.

[Hernan Wilkinson]

In Smalltalk the if is treated differently just for performance, but there is no problem to eliminate that and treat it just as a message send, and you can do it pretty easily configuring the Smalltalk compiler.

In fact, if you do "aBoolean perform: #ifTrue: with: [....]" there is a real message send and you can even debug the #ifTrue: inplementation

Sent from a device I don't want to advertise

[Manuel Simoni]

On Sunday, March 4, 2012 4:32:42 AM UTC+1, David Nolen wrote:

Kernel is slow.

It took me a while to wrap my head around the towering levels of

wrongness in this sentence.  Or should I say, not-even-wrongness? ;-P

Some thoughts:

* A programming language cannot be slow, an implementation can be.

Saying that a programming language is slow doesn't make sense.  See

next point:

* Existing Kernel implementations may or may not be slow, but we don't

  know because nobody has done realistic benchmarks yet.

Furthermore, the JVM/Hotspot shows that by putting enough manpower

behind an implementation you can make almost anything fast.

* Fexprs may pose challenges to efficient implementation. Or not.

It is easy to assume that fexprs must be slower than common

preprocessing macros because they have to do more work at runtime,

whereas macros perform their work at compile-time.  But we don't know

(see previous point).

* Fexprs may make efficient implementation easier.  Or not.

In fact, fexprs may in some cases be faster than preprocessing

macros.  Why?  One of the most important resources for raw performance

is the CPU's instruction cache.  Preprocessing macros cause an

increase in code size relative to fexprs, putting pressure on the

i-cache.  It *may* (I haven't done any benchmarks) be entirely

possible that an application written using fexprs outperforms one

written macros if it has a better i-cache behavior.

Also, fexprs make a language semantics and implementation radically

simpler.  Given that a large part of the work of e.g. writing a JIT is

staying compatible with the non-JIT semantics of a language, it could

be easier to write a JIT for a language like Kernel than for a more

complicated one.  We don't know (yet).

* What is performance anyway?

Focus on raw performance is so pre-concurrency-crisis.  It's generally

agreed that the way forward is to make use of more cores - even if it

means running slightly slower on a single core.

And even if raw performance mattered, a lot of time programs are

waiting for IO.  This is why people write servers in e.g. Perl or

MapReduce tasks in Sawzall.  If your app is waiting for the OS kernel

to finish IO requests for 80% of the time, making the language

implementation faster can only give you a boost for the other 20%.

See also Proebsting's Law.

http://research.microsoft.com/en-us/um/people/toddpro/papers/law.htm

* Focus on performance considered harmful (?)

Finally, I should also say that a focus on raw performance to the

detriment of cool language features is the antithesis of the Lisp

spirit - which to me means having the cool, mind-bending features and

*then* figuring out how to make them fast.

In conclusion: Kernel's fexprs are much too new a topic to say

anything about their performance.  But they're so exciting, that even

if they're slower than macros, I would find them still worth having in

the language.  Fexprs are fun expressions.

Manuel

[David Nolen]

Excellent points! Yes we don't yet know efficient implementation techniques for fexprs.

That said performance simply matters for me and I imagine for many others. My interest in programming languages includes using them for building interactive applications / simulations / games.

And I don't think performance is antithetical to the spirit of Lisp. The literature around compiling functional programs so they run quickly is simply too grand and fun.

I await such literature for fexprs!

David

[Daniel Yokomizo]

On Mon, Mar 5, 2012 at 8:34 AM, Manuel Simoni <msi...@gmail.com> wrote:
> On Sunday, March 4, 2012 4:32:42 AM UTC+1, David Nolen wrote:
>>
>> Kernel is slow.
>
>
> It took me a while to wrap my head around the towering levels of
> wrongness in this sentence.  Or should I say, not-even-wrongness? ;-P
>
> Some thoughts:
>
> * A programming language cannot be slow, an implementation can be.

Of course a PL can be slow. Some part of its semantics may be defined
on an NP hard algorithm or some arbitrary resource intensive function.

OTOH I agree that most complaints are about particular
implementations, instead of PL definitions.

True. My recent, explorations on a Self-ish language is stuck on
parallel GC for huge heaps with thousands of concurrent mutators. The
fast sequential part was trivial compare to this one.

> And even if raw performance mattered, a lot of time programs are
> waiting for IO.  This is why people write servers in e.g. Perl or
> MapReduce tasks in Sawzall.  If your app is waiting for the OS kernel
> to finish IO requests for 80% of the time, making the language
> implementation faster can only give you a boost for the other 20%.
>
> See also Proebsting's Law.
> http://research.microsoft.com/en-us/um/people/toddpro/papers/law.htm
>
> * Focus on performance considered harmful (?)
>
> Finally, I should also say that a focus on raw performance to the
> detriment of cool language features is the antithesis of the Lisp
> spirit - which to me means having the cool, mind-bending features and
> *then* figuring out how to make them fast.
>
> In conclusion: Kernel's fexprs are much too new a topic to say
> anything about their performance.  But they're so exciting, that even
> if they're slower than macros, I would find them still worth having in
> the language.  Fexprs are fun expressions.
>
> Manuel

Daniel

[Manuel Simoni]

On Monday, March 5, 2012 1:45:11 PM UTC+1, David Nolen wrote:

Yes we don't yet know efficient implementation techniques for fexprs.

David, why are you implying that fexprs are inefficient without providing any benchmarks or even scope for such a claim?

PicoLisp, a Lisp interpreter with fexprs, outperforms CLisp on some benchmarks, and is less than an order of magnitude slower than SBCL - one of the fastest dynamic language compilers.

http://picolisp.com/5000/!wiki?NeedForSpeed

Manuel

[Michael J. Forster]

On Mon, Mar 5, 2012 at 6:45 AM, David Nolen <dnolen...@gmail.com> wrote:
> Excellent points! Yes we don't yet know efficient implementation techniques
> for fexprs.
>
> That said performance simply matters for me and I imagine for many others.
> My interest in programming languages includes using them for building
> interactive applications / simulations / games.

[...]

If performance is the overriding interest, perhaps the list should
have been named "ll-right-now" ;-)

Mike

[David Nolen]

On Mon, Mar 5, 2012 at 8:06 AM, Manuel Simoni <msi...@gmail.com> wrote:

On Monday, March 5, 2012 1:45:11 PM UTC+1, David Nolen wrote:

Yes we don't yet know efficient implementation techniques for fexprs.

David, why are you implying that fexprs are inefficient without providing any benchmarks or even scope for such a claim?

I've found no literature on improving the performance of fexprs because as far as I can tell they don't exist and plenty of literature going back to Smalltalk on why they're slow. You're a Kernel enthusiast why don't *you* provide the benchmarks.

 

PicoLisp, a Lisp interpreter with fexprs, outperforms CLisp on some benchmarks, and is less than an order of magnitude slower than SBCL - one of the fastest dynamic language compilers.

http://picolisp.com/5000/!wiki?NeedForSpeed

Manuel

Less than an order of magnitude is not exactly what I would call impressive. Being even greater than 2X slower is a show stopper for many applications.

David

[David Nolen]

I think the efficient implementation of programming languages is a fascinating subject and very relevant for ll-next. Not everyone needs to share that interest. Just because I think Kernel is "slow as molasses ... it runs", shouldn't discourage anyone from looking more closely into it.

David

[Manuel Simoni]

On Monday, March 5, 2012 2:38:25 PM UTC+1, David Nolen wrote:

On Mon, Mar 5, 2012 at 8:06 AM, Manuel Simoni <msi...@gmail.com> wrote:

On Monday, March 5, 2012 1:45:11 PM UTC+1, David Nolen wrote:

Yes we don't yet know efficient implementation techniques for fexprs.

David, why are you implying that fexprs are inefficient without providing any benchmarks or even scope for such a claim?

 

I've found no literature on improving the performance of fexprs because as far as I can tell they don't exist

Again, you're implying that the performance of fexprs needs improvement, without evidence.

 

and plenty of literature going back to Smalltalk on why they're slow.

Links please.

 

You're a Kernel enthusiast why don't *you* provide the benchmarks.

I provided a link to a benchmark of a Lisp with fexprs beating a traditional Lisp in the post you just replied to.

Manuel

[David Nolen]

On Mon, Mar 5, 2012 at 8:52 AM, Manuel Simoni <msi...@gmail.com> wrote:

On Monday, March 5, 2012 2:38:25 PM UTC+1, David Nolen wrote:

On Mon, Mar 5, 2012 at 8:06 AM, Manuel Simoni <msi...@gmail.com> wrote:

On Monday, March 5, 2012 1:45:11 PM UTC+1, David Nolen wrote:

Yes we don't yet know efficient implementation techniques for fexprs.

David, why are you implying that fexprs are inefficient without providing any benchmarks or even scope for such a claim?

 

I've found no literature on improving the performance of fexprs because as far as I can tell they don't exist

Again, you're implying that the performance of fexprs needs improvement, without evidence.

 

and plenty of literature going back to Smalltalk on why they're slow.

Links please.

I've already mentioned the special handling of basic control forms.

http://axisofeval.blogspot.com/2012/02/yet-another-kernel-interpreter.html ;)

 

 

You're a Kernel enthusiast why don't *you* provide the benchmarks.

I provided a link to a benchmark of a Lisp with fexprs beating a traditional Lisp in the post you just replied to.

Manuel

Are we reading the same thing? picolisp is consistently slower then SBCL. It would also be far more convincing to see a much more comprehensive set of Alioth benchmarks.

In anycase this discussion is veering off course for me :)

Cheers,

David