Re: [gsoc-mentors] The truth on GSOC, ESUG and bad attitude

On 12 February 2014 00:22, tim Rowledge <[hidden email]> wrote:
>
> On 11-02-2014, at 5:02 PM, Jecel Assumpcao Jr. <[hidden email]> wrote:
>
>> Any discussion of what is Smalltalk and what isn't can't get very far
>> without first clearly defining a few things.
>
> In the same way that Filk is music performed by people that consider themselves to be Filkers, I would suggest that maybe Smalltalk is what is written by people that consider themselves to be Smalltalkers.
>
> Is everything an object? Do objects have classes? Do objects communicate by sending messages and getting back results? Is an image saved and restarted? Can you forget about having to deal with memory allocation? If the answer is yes to those questions then it’s probably a Smalltalk.

Of course, this makes Common Lisp a Smalltalk :) (They certainly have
a whole bunch of characteristics in common, which given Smalltalk's
influences should not be a surprise.) (And no, I don't seriously
consider Common Lisp a Smalltalk, just in case anyone thinks that I
do.)

> Oh and course the big one - do I like it?

Why, yes I do! (To both!)

frank

Dennis Schetinin asked:

> Is Self a Smalltalk? :)

Yes. To quote Mario Wolczko, "Self is like Smalltalk, only more so."

It seems that I have the only copy of his "Self includes: Smalltalk"
paper online:

http://www.merlintec.com/download/mario.pdf

The pages are in the reverse order, which makes it nice to print on
simple printers but a bit complicated to read on a screen.

It is very important to notice that this is *not* like a Lisp or Prolog
implemented on top of Squeak. A casual reading of this paper might give
this impression, but it really is something different. Self is treated
as a kernel Smalltalk which is then expanded into full GNU Smalltalk
compatibility. There aren't two layers, but a single language.

This is in contrast to PEP, which implemented Java by compiling it to
Self bytecodes. That is like NewSpeak using the Squeak VM:

> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.23.6906&rep=rep1&type=pdf

Since this paper ("Towards a Universal Implementation Substrate for
Object-Oriented Languages" by Mario Wolczko, Ole Agesen and David Ungar)
talks about both projects it is easy to get the impression that they
were the same kind of thing and that saying "Self is a Smalltalk" would
be as silly as saying "Self is a Java". The details are important.

-- Jecel

On 12 February 2014 19:05, Eliot Miranda <[hidden email]> wrote:
> Hi Frank,
>
>
> On Wed, Feb 12, 2014 at 1:35 AM, Frank Shearar <[hidden email]>
> wrote:
>>
>> On 12 February 2014 00:22, tim Rowledge <[hidden email]> wrote:
>> >
>> > On 11-02-2014, at 5:02 PM, Jecel Assumpcao Jr. <[hidden email]>
>> > wrote:
>> >
>> >> Any discussion of what is Smalltalk and what isn't can't get very far
>> >> without first clearly defining a few things.
>> >
>> > In the same way that Filk is music performed by people that consider
>> > themselves to be Filkers, I would suggest that maybe Smalltalk is what is
>> > written by people that consider themselves to be Smalltalkers.
>> >
>> > Is everything an object? Do objects have classes? Do objects communicate
>> > by sending messages and getting back results? Is an image saved and
>> > restarted? Can you forget about having to deal with memory allocation? If
>> > the answer is yes to those questions then it’s probably a Smalltalk.
>>
>> Of course, this makes Common Lisp a Smalltalk :) (They certainly have
>> a whole bunch of characteristics in common, which given Smalltalk's
>> influences should not be a surprise.) (And no, I don't seriously
>> consider Common Lisp a Smalltalk, just in case anyone thinks that I
>> do.)
>
>
> Good that you don't think CL is a Smalltalk.  But why?  Generic functions vs
> message sends, instance encapsulation and syntax.   I think generic
> functions are very different to Smalltalk/Self-style message sending
> (Java/C++/JavaScript message sending is much closer to Smalltalk).

Yes, as long as one also remembers that Foote, Johnson and Noble [1]
showed that you can curry generic functions into single-dispatch
message sends.

>  And
> hence method combination is very different in CL to Smalltalk's simple super
> send.

Yes, this is a big difference. Mainly those are macro-like, IIRC. [3]
It's been too long since I last touched Common Lisp!

>  While Newspeak extends Smalltalk's send semantics with
> lexically-scoped sends, the extensions are still very much like Smalltalk
> message sends (polymorphic, dispatching on a single receiver).  The other
> major difference is encapsulation.  In CLOS there isn't any.

Kinda. I mean, sure, slot-value gives you direct access to a slot
(what Smalltalk calls an instance variable, for those following
along). But (slot-value foo 'bar) translates to foo instVarNamed:
'bar'. Seeing slot-value in Common Lisp source ought to make you feel
as queasy as when you see #instVarAt: and friends.

I am half a world away from my copy of AMOP, so I can't find out
whether the MOP lets you intercede slot-value calls. I'm not sure of
the differences between Common Lisp slots and Pharo's Slots, in other
words.

>  Generic
> functions imply that not everything is an object.

Surely generic functions are objects that have an apply method?
Generic functions certainly do imply that functionality doesn't always
belong only to one, privileged, class.

>  But CLOS has a MOP and
> we're in catch-up here.  Pharo is doing good work with Slots.  Finally
> syntax is important.  The mixfix syntax that Smalltalk has is simple and
> powerful.  CLOS has keyword arguments but they're quite different, for
> optional parameters and can have default values and occur in any order.

Yes, Common Lisp has a bit of a mess here. I mean, if you have keyword
arguments, do you really need optionals as well? And then let both
happen in the same function signature?!

>  A
> final significant facility is multiple return values.  Smalltalk has a neat
> hack (providing a block to receive the results), but that's not as
> convenient.

The hack - do you mean 1 in: [:x  | x + 1] ?

Dan Ingalls, IIRC, had an extension or something where you could write
"a, b := self aMethodReturningaPair". Clojure's destructuring
mechanisms [2] is probably the nicest thing I've seen here. A pet hack
I've been working on has a #destructureIn: where you can say

#(1 2) destructureIn: [:x :y | x + 1]

which lets me avoid loads of local variables.

frank

[1] http://www.laputan.org/reflection/Foote-Johnson-Noble-ECOOP-2005.html
[2] http://blog.jayfields.com/2010/07/clojure-destructuring.html
[3] http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html

> --
> best,
> Eliot

On 12 February 2014 22:49, Eliot Miranda <[hidden email]> wrote:
> Hi Frank,
>
>
> On Wed, Feb 12, 2014 at 12:58 PM, Frank Shearar <[hidden email]>
> wrote:
>>
>> On 12 February 2014 19:05, Eliot Miranda <[hidden email]> wrote:
>> > Hi Frank,
>> >
>> >
>> > On Wed, Feb 12, 2014 at 1:35 AM, Frank Shearar <[hidden email]>
>> > wrote:
>> >>
>> >> On 12 February 2014 00:22, tim Rowledge <[hidden email]> wrote:
>> >> >
>> >> > On 11-02-2014, at 5:02 PM, Jecel Assumpcao Jr. <[hidden email]>
>> >> > wrote:
>> >> >
>> >> >> Any discussion of what is Smalltalk and what isn't can't get very
>> >> >> far
>> >> >> without first clearly defining a few things.
>> >> >
>> >> > In the same way that Filk is music performed by people that consider
>> >> > themselves to be Filkers, I would suggest that maybe Smalltalk is
>> >> > what is
>> >> > written by people that consider themselves to be Smalltalkers.
>> >> >
>> >> > Is everything an object? Do objects have classes? Do objects
>> >> > communicate
>> >> > by sending messages and getting back results? Is an image saved and
>> >> > restarted? Can you forget about having to deal with memory
>> >> > allocation? If
>> >> > the answer is yes to those questions then it’s probably a Smalltalk.
>> >>
>> >> Of course, this makes Common Lisp a Smalltalk :) (They certainly have
>> >> a whole bunch of characteristics in common, which given Smalltalk's
>> >> influences should not be a surprise.) (And no, I don't seriously
>> >> consider Common Lisp a Smalltalk, just in case anyone thinks that I
>> >> do.)
>> >
>> >
>> > Good that you don't think CL is a Smalltalk.  But why?  Generic
>> > functions vs
>> > message sends, instance encapsulation and syntax.   I think generic
>> > functions are very different to Smalltalk/Self-style message sending
>> > (Java/C++/JavaScript message sending is much closer to Smalltalk).
>>
>> Yes, as long as one also remembers that Foote, Johnson and Noble [1]
>> showed that you can curry generic functions into single-dispatch
>> message sends.
>>
>> >  And
>> > hence method combination is very different in CL to Smalltalk's simple
>> > super
>> > send.
>>
>> Yes, this is a big difference. Mainly those are macro-like, IIRC. [3]
>> It's been too long since I last touched Common Lisp!
>>
>> >  While Newspeak extends Smalltalk's send semantics with
>> > lexically-scoped sends, the extensions are still very much like
>> > Smalltalk
>> > message sends (polymorphic, dispatching on a single receiver).  The
>> > other
>> > major difference is encapsulation.  In CLOS there isn't any.
>>
>> Kinda. I mean, sure, slot-value gives you direct access to a slot
>> (what Smalltalk calls an instance variable, for those following
>> along). But (slot-value foo 'bar) translates to foo instVarNamed:
>> 'bar'. Seeing slot-value in Common Lisp source ought to make you feel
>> as queasy as when you see #instVarAt: and friends.
>>
>> I am half a world away from my copy of AMOP, so I can't find out
>> whether the MOP lets you intercede slot-value calls. I'm not sure of
>> the differences between Common Lisp slots and Pharo's Slots, in other
>> words.
>>
>> >  Generic
>> > functions imply that not everything is an object.
>>
>> Surely generic functions are objects that have an apply method?
>> Generic functions certainly do imply that functionality doesn't always
>> belong only to one, privileged, class.
>
>
> No, I mean that generic functions can discriminate on anything, including
> singletons, s-exprs, right?  So they're more general than message sending
> and allow one to access the Lisp types CLOS is built from.

They can, yes. But singletons and sexprs are still just objects. So
for instance, discriminating on a particular object is still just a
message send (well, in my head it is), albeit the definition of the
method isn't attached to a class.

>> >  But CLOS has a MOP and
>> > we're in catch-up here.  Pharo is doing good work with Slots.  Finally
>> > syntax is important.  The mixfix syntax that Smalltalk has is simple and
>> > powerful.  CLOS has keyword arguments but they're quite different, for
>> > optional parameters and can have default values and occur in any order.
>>
>> Yes, Common Lisp has a bit of a mess here. I mean, if you have keyword
>> arguments, do you really need optionals as well? And then let both
>> happen in the same function signature?!
>
>
> I'm not sure I'd call CLOS's approach messy.  It /is/ very different.
> Smalltalk's designers put a lot of effort into designing a simple but
> powerful syntax (including for literals).  And in doing that they avoided
> some of CLOS's flexibility.

I didn't say CLOS's approach messy.

I find it odd that Common Lisp
allows both keyword args and optional args, when keyword args are
inherently optional (in Common Lisp, that is). Plus you don't have to
argument-count if you just have keywords (in addition to the normal
parameters).

I think that the before/after/around method combinations to be very neat.

>> >  A
>> > final significant facility is multiple return values.  Smalltalk has a
>> > neat
>> > hack (providing a block to receive the results), but that's not as
>> > convenient.
>>
>> The hack - do you mean 1 in: [:x  | x + 1] ?
>
>
> I mean this idiom:
>
> self accessorsAndAssignmentsForMethod: method
> actuals: {}
> depth: 0
> interpreterClass: interpreterClass
> into: [:theRoots :theAccessors :theAssignments|
> roots := theRoots.
> accessors := theAccessors.
> assignments := theAssignments].
>
> It's nicer to be able to write
>
> roots, accessors, assignments :=
> self accessorsAndAssignmentsForMethod: method
> actuals: {}
> depth: 0
> interpreterClass: interpreterClass
>
> But as an implementor I'm not sure the complexity pulls its weight.  The
> closure hack works well enough.

Yes, this is the hack I meant. And I agree re the closure hack: it
looks a lot like a let binding, too. (It was #into: I was thinking of,
not #in:, obviously) I suppose the only thing I don't particularly
like is that the value comes before the variable, so instead of

(let [f 1]
   ;Clojure stuff)

it's

1 into: [:f |
    "Smalltalk stuff"].

>> Dan Ingalls, IIRC, had an extension or something where you could write
>> "a, b := self aMethodReturningaPair". Clojure's destructuring
>> mechanisms [2] is probably the nicest thing I've seen here. A pet hack
>> I've been working on has a #destructureIn: where you can say
>>
>> #(1 2) destructureIn: [:x :y | x + 1]
>>
>> which lets me avoid loads of local variables.
>
>
> Yes, I use something similar a fair bit
>
>     [:a :b ... | ... ] valueWithArguments: tuple
>
> etc.
>
> And the Selector>>value[:...] hacks are clever too:
>
>     (2 to: n) select: #even

Don't say that to Gilad :) "Inherently reflective" (and therefore
problematic from a stratification point of view) was how he described
them last time I said that I liked them. I think I did at one point
understand why he said that... and I should have written it down.
https://groups.google.com/forum/#!topic/newspeaklanguage/m2PO5RSQwFk
has the conversation.

frank

>> frank
>>
>> [1] http://www.laputan.org/reflection/Foote-Johnson-Noble-ECOOP-2005.html
>> [2] http://blog.jayfields.com/2010/07/clojure-destructuring.html
>> [3]
>> http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html