Balance of metrics

Hi all,

I would like to express the idea from the code review thread here from
a positive perspective.

I really love most of the micro-tweak performance changes Levente and
others have made to Squeak over the years.  Combined with spur and the
new memory model the system became wonderfully fast and fun to use.
And, with the 64-bit, powerful!  As a community of expert developers,
it's understandable for the metric of performance to be the top
metric.  However, I believe many are are also cognizant of the IDE's
potential to be something with incredible potential for regular users,
even directly out of the box. [1]

In that vision, the class library itself has potential to be one of
their primary "widgets" where, as users who may not write code but do
sometimes read code and interact directly with API's, because the
widget is beautifully appealing for them to read and use, it becomes
another metric worth consideration.

  Top-Layer API -- crafted for consumption, convenience, calls the "core" API
     Core API -- fast, efficient (the seam between top-l and implementation)
         (private methods --  implementation stuff)

I believe a tangible, well-crafted top-layer could be like a layer of
gold for Squeak-appeal, if we wanted it to be.  All we need are a
little beautification of select methods, some deliberate commenting,
possibly some method attribute structure and...  widget think.

What do you think?  Is there a potential treasure of appeal, within
fairly easy grasp, hidden in plain sight for Squeak?  I'm interested
in your thoughts.

 - Chris

[1] -- Did the Etoys integration get done for this release?  If so,
are there are any easy and appropriate ways to leverage this in a
"wow" way for the release?

> I would like to express the idea from the code review thread here from
> a positive perspective.

Nice move :)


> I believe a tangible, well-crafted top-layer could be like a layer of
> gold for Squeak-appeal, if we wanted it to be.  All we need are a
> little beautification of select methods, some deliberate commenting,
> possibly some method attribute structure and...  widget think.
>
> What do you think?  Is there a potential treasure of appeal, within
> fairly easy grasp, hidden in plain sight for Squeak?  I'm interested
> in your thoughts.

I mostly agree with you, but this is actually a very ambitious project.
It is difficult to get people (me included) motivated to do such small
changes all over the place...

And any design issue is thorny for a communauty, as we do not all have
the same aesthetic.


> [1] -- Did the Etoys integration get done for this release?  If so,
> are there are any easy and appropriate ways to leverage this in a
> "wow" way for the release?
+1


My own suggestion for the next release would be for it to look a bit
more lively, colorful and inhabited than the empty grey box we got lately.

Stef

I'm actually just trying to establish a desirable direction on our
compass than push for any action toward an ambitious project.  The
top-layer of the library still has some beauty and elegance left.

> And any design issue is thorny for a communauty, as we do not all have the
> same aesthetic.

Indeed.  I will continue to object to changes which move it away from
mass-appeal and compatibility.

 - Chris

> On 12-03-2018, at 11:20 AM, Chris Muller <[hidden email]> wrote:
> ot all have the
>> same aesthetic.
>
> Indeed.  I will continue to object to changes which move it away from
> mass-appeal and compatibility.

One thing I believe would help a bit with this (and other problems) would be a proper way to make private methods. It's just plain wrong that one can send messages that refer to code which is a part of some internal process which is not meant for 'outside' use.

Eliot & I were talking about it a while back and  IIRC thought that it would be practical these days to have an "I'm sending this message to myself" send, along with some futzing when doing lookup. With inline caching I don't think it would have any measurable effect on performance. Basically if the method is private then it simply isn't 'seen' during lookup unless the send is a self-send. Or something like that.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Furnulum pani nolo = I don't want a toaster.

tim,


well, I think the compiler complains if you send messages starting with 'pvt' to something other than self, right?

Other than that, I think there's too much merit in "vars are private, messages are public" than to introduce an outright restrictive messaging model.

You'll never know what part of your objects interface is gonna being needed down the road. Rather, I think it's a good challenge to code every method as if it was public interface. I know that's hardly possible, but for the vast majority of cases, it's gonna work and won't hurt.

That being said, I think that we should make the "documentation" browse mode more prominent (when you click the "source" button to the right in the browser), and then have methods that rely on internal preconditions (what else is a "private method") be documented a tiny bit better in the future. Something along the lines "if you call this make sure that bambooozle is set to knorzbar".


Best regards
        -Tobias


> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Useful Latin Phrases:- Furnulum pani nolo = I don't want a toaster.

I don't want to buy this record, it is scratched.

>
>
>

> On 12-03-2018, at 11:48 AM, Tobias Pape <[hidden email]> wrote:
>
> well, I think the compiler complains if you send messages starting with 'pvt' to something other than self, right?

That's the wrong way round though; it requires the sender to know too much. And it can't work to stop (ab)use of #perform: type sneakiness.
>
> Other than that, I think there's too much merit in "vars are private, messages are public" than to introduce an outright restrictive messaging model.

Personally I'd be more inclined to go for "methods are private unless explicitly set to public" as a way to aggressively make people think about what they're doing!

>
> You'll never know what part of your objects interface is gonna being needed down the road.

Well you ought to at least think about it a bit, and the nice thing is that stuff can be changed, what this being Smalltalk.

And while I'm being all dictatorial, I really hate to see code like

  self foo bim baz wibble at: weeble state count + 1

ie chains of accessors that imply far too much knowledge of the type of what you get returned. Should be more like

  self wibbleStateAt: weeble nextState

with suitable delegations though whatever foo is, and its baz, and its wibble, and so on.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: FA: Failsafe Armed

welcome to java world, where everyone is making everything final, because, why yes, nobody should use that but my code!
I've been bitten by that, and I've always appreciate the kind of responsibility that Smalltalk gives to the client of objects: "you send that message, you're gonna be responsible for it".

It's more about educating Smalltalk programmers about the responsibility they bear. We try that in our courses here, and, sure, some people are like "what the heck, I'm just do whatever", which clearly would be helped against by private methods. But I strongly resist being dictated by this minority of Smalltalk user. Rather,
 - Better tooling
 - Better documentation and
 - Better live interaction
are IMHO the keys here. Otherwise you end up with TypedSmalltalk, because, well, yeah, the compiler surely knows better than you what your program should look like, and while we're at it, we're gonna pretty print your methods the way the system prescribes no matter what style is actually appropriate for the code you've written.
[side note]
tim, I hope you understand I'm not ranting about you, au contraire.
[/side note]
Where was I? Oh yeah, the safety argument.
There's a German road security specialist who says, the way to make driving the safest is to put a point stick right on the driving wheel so that should you brake too hard, it'll puncture your skull. That way, nobody would ever dare to drive too fast or dangerously. Casualties  would certainly drop, considering everything.
[side note]
No, I'm not making this up
[/side note]
The other method he suggests is better education and better awareness, combined with better helpers (viz. tools)

I'd rather have the latter, in Smalltalk, than a pointy stick. :)

>
>>
>> You'll never know what part of your objects interface is gonna being needed down the road.
>
> Well you ought to at least think about it a bit, and the nice thing is that stuff can be changed, what this being Smalltalk.

That's the nice thing about a living system: you can experiment with it and see what actually happens. that supplements upfront thinking with on-the-go experience. I think keeping messages open is still key here.

Clearly, Law of Demeter! We teach that our students every year in quite some detail with quite some emphasis.

But I think both points are orthogonal here. :)

-tobi


>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: FA: Failsafe Armed

HCF!

>
>
>

> On 12-03-2018, at 12:42 PM, Tobias Pape <[hidden email]> wrote:
>
>
>> On 12.03.2018, at 20:26, tim Rowledge <[hidden email]> wrote:
>>
>> Personally I'd be more inclined to go for "methods are private unless explicitly set to public" as a way to aggressively make people think about what they're doing!
>
> welcome to java world, where everyone is making everything final, because, why yes, nobody should use that but my code!

I'm a long way from a java expert, having taken a look at it in the late 90's and reeled in horror, but I thought 'final' was a way to say that no subclass can be made, or no subclass can over-ride a method? Is it used for runtime privacy?

> I've been bitten by that, and I've always appreciate the kind of responsibility that Smalltalk gives to the client of objects: "you send that message, you're gonna be responsible for it".

My problem here is that people just don't seem to take that responsibility often enough.

> Where was I? Oh yeah, the safety argument.
> There's a German road security specialist who says, the way to make driving the safest is to put a point stick right on the driving wheel so that should you brake too hard, it'll puncture your skull. That way, nobody would ever dare to drive too fast or dangerously. Casualties  would certainly drop, considering everything.
> [side note]
> No, I'm not making this up
> [/side note]

That's a very old joke indeed, along with "What's the most dangerous part of a car? The nut that holds the steering wheel"

> The other method he suggests is better education and better awareness, combined with better helpers (viz. tools)
>
> I'd rather have the latter, in Smalltalk, than a pointy stick. :)

Yes indeed but see my previous point.
>>
>>

Good to hear. It needs applying massively in the image.  :-(

>
> But I think both points are orthogonal here. :)

Maintaining orthogonality is important. Save the orthogones!


>>
>> Strange OpCodes: FA: Failsafe Armed
>
> HCF!

If you have NetFlix and you are lucky you might be able to watch the really rather fun series called Halt and Catch Fire. It's one of those historidramas that is completely not how it happened and yet completely true to what happened. I loved it. PARC and Smalltalk even get a mention!


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
The colder the X-ray table, the more of your body is required on it.

No. You caught me, but this is my personal equivalent :P :D

>
>> I've been bitten by that, and I've always appreciate the kind of responsibility that Smalltalk gives to the client of objects: "you send that message, you're gonna be responsible for it".
>
> My problem here is that people just don't seem to take that responsibility often enough.

Yes, that is true. So it is an education problem.

With our students I see that those who are willing to:
 - explore the image
 - take the risk of _sometimes_ grill it (they soon make backups :D)
 - and _take on_ the responsibility
will deliver the best code. This list is ordered, by the way, it starts with willingness to explore.
Some students say "I didn't imagine squeak could do that", and then either "so I didn't search" or "tell me what will make it work", which are both, equally disappointing and annoying.
Luckily, this is a minority.

>
>> Where was I? Oh yeah, the safety argument.
>> There's a German road security specialist who says, the way to make driving the safest is to put a point stick right on the driving wheel so that should you brake too hard, it'll puncture your skull. That way, nobody would ever dare to drive too fast or dangerously. Casualties  would certainly drop, considering everything.
>> [side note]
>> No, I'm not making this up
>> [/side note]
>
> That's a very old joke indeed, along with "What's the most dangerous part of a car? The nut that holds the steering wheel"

That guy said it in a rather serious tone (but maybe that just a trope..)

Yes!

That being said, I'd like to invite you all to read the following, IMHO very succinct and well written essay: http://web.cecs.pdx.edu/~black/publications/egal.pdf

I especially like the concept of autognosis, which would, if applied, help here a bit, I think.


>>
>> But I think both points are orthogonal here. :)
>
> Maintaining orthogonality is important. Save the orthogones!

Orthothropes!


Best regards
        -Tobias
>
>
>>>
>>> Strange OpCodes: FA: Failsafe Armed
>>
>> HCF!
>
> If you have NetFlix and you are lucky you might be able to watch the really rather fun series called Halt and Catch Fire. It's one of those historidramas that is completely not how it happened and yet completely true to what happened. I loved it. PARC and Smalltalk even get a mention!

I heard good of it, yes.
>
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> The colder the X-ray table, the more of your body is required on it.

*shiver*

Tim Rowledge wrote on: Mon, 12 Mar 2018 11:29:08 -0700

> Eliot & I were talking about it a while back and  IIRC thought that it would
> be practical these days to have an "I'm sending this message to myself"
> send, along with some futzing when doing lookup. With inline caching I
> don't think it would have any measurable effect on performance. Basically
> if the method is private then it simply isn't 'seen' during lookup unless
> the send is a self-send. Or something like that.

Self does have such a bytecode, as you might expect from the name of the
language. And the semantics was subtly different from pushing "self" on
the stack and then doing a normal send to that, but it isn't what I
wanted to talk about.

For Self 1.0 multiple inheritance with priorities was implemented and so
was privacy. Inheritance was done with "parrent slots" which had "*" at
the end of their names. So if an object has a slot named "mommy*" with
the value "globals rectangle" then it inherits rectangle behavior. If it
also has a slot named "daddy***" with the value "globals texture" then
it also inherits texture behavior, but not as strongly (more "*" makes
inheritance weaker). If you send a message that is both rectangle-like
and texture-like the first will be chosen.

But you might have parents with the same priorities and in that case a
"tie breaker rule" is applied. When you combined this with private vs
public slots, then it was often the case that the actual method that got
executed was not at all what the programmer expected. Each feature
seemed simple enough, but their combination was too complicated.

David Ungar liked to say this was Randy Smith's fault for going away to
England and leaving him and his students at Stanford to play around
without proper supervision. When the group moved to Sun and Randy joined
them, they removed parent priorities, the tie breaker rule (it was now
an error for there to be more than one possible method, so the program
would have to be manually rewritten to eliminate the ambiguity) and
privacy was no longer enforced (though they stayed on as documentation
and showed up in the Self 4 GUI as bold face vs normal method names).

The subjective languages Us and Korz were later attempts to properly
deal with these problems.

-- Jecel