[squeak-dev] talk on Newspeak online

On Fri, 09 May 2008 21:30:45 +0200, Vassili Bykov wrote:

It seems you have found 1-2 enthusiastic idiots who thought they can  
somehow emulate #primitiveChangeClassTo: fully in Smalltalk-80 :)

> Cheers,
>
> --Vassili
>
>

This thread is all over the map and I don't have time to read it all, so my apologies in advance if I'm rehashing something someone already said.

I've always preferred a prototype/cloning approach rather than the traditional initialization we find in Smalltalk.  I find that there often isn't one properly initialized form of an instance that you need to provide, but several or perhaps many.  One simple example is "Semaphore new" and "Semaphore forMutualExclusion".  It's an example of two differently initialized forms.  Instead of having two different constructor methods (#new and #forMutualExclusion), you could have two different prototypes initialized in the manner you want them and then clone one of them when you need new instances.  Another interesting point is that it's the consumer of the class that determines which form is appropriate to use, not the class itself.  So, at the very least, you do need to support many constructors for any given class (not all of which need be located in the same "module" as the class itself), and perhaps you might want to do the construction in advance and simply clone the appropriate prototype to get new instances.

However, I still use the traditional approach most often simply because I've never bothered to create an easy frameork for creating and organizing such prototypes.

- Stephen

Vassili Bykov wrote: Hi Vassily, it's good to hear from you too.
I think you forgot the new kinds of literals introduced to support
namespaces, plus I suspect that you bear some responsibility for the
increase in complexity in VW as well :)
Come on, you had just mentioned nested classes, isn't that a new concept?
And doesn't the label "Access modifiers" hide a collection of
concepts/features ?
And mixins, are they themselves classes or are they separate concepts
from classes?

And talking about global scope, e.g. Java doesn't have (an objectified)
global scope. So what do people do when they need it? They stick
whatever they need in a class, which is globally visible (I assume this
is true even in Newspeak), and access it indirectly. The only thing you
"gained" is an extra indirection.
Sure, global scope should not be abused. But it is damned convenient.
Very useful as a quick debugging aid. Once again you seem to want to
save us from ourselves, but there are a lot of languages out there that
are already doing just that, thank you very much (they are called crappy
languages). Give us more power, not more guard rails! Ah, you mentioned the "dirty image" curse word! Time for another rant:

Let's take Java, which does not have the concept of snapshotting a fully
loaded and initialized memory dump of their application. Because of
that, they are now scrambling to find ways to "pre-load" stuff in order
to cut those awful startup times that have to be paid again and again by
everybody, every time they use a (large) Java application. Oh, what joy
to spend time loading and compiling and initializing those exact same
classes again and again instead of doing it only once!
I find it mind-boggling that even Smalltalkers are complaining about
this "bad" image idea, when it's one of the major factors in their
superior productivity. Let's not even mention the benefit for
development of living in the same space as both the target application
and the development environment. Even for deployment it is a great
debugging aid to just leave all the tools in the image (just hide them),
so when the inevitable occurs, you are not stranded (like in the crappy
languages) with an unwound stack that you cannot debug.
Of course, one can do stupid things with an image: one can save it with
all kinds of external resources open etc. But, you know, if it hurts,
don't do it. Does this mean we should all give up all the amazing
benefits that we enjoy, simply because somebody could be stupid and use
it poorly? This is like saying that merely because one could take a copy
of a hibernated OS image from a laptop and move it in a different,
inappropriate place where it could break when started, we should all
give up the capability of doing hibernation on our laptops.
And why do you conflate the image "problem" with modifying base classes?
If somebody really wants to, now that we have the full sources to the
Java class libraries, nothing stops anybody from modifying them, putting
them in a jar and the jar in the classpath. Yes, many will shoot
themselves in the foot in the process, but if somebody can make a useful
bugfix/feature that Sun has not thought of, why not?

Of course a Smalltalk app can be separated. It may be painful. I went
through that pain just for kicks with the VW base image when I had too
much time on my hands during the post-internet bubble downturn. I did it
by talking to my target image through tcp-ip, and slowly peeling away.
Craig demonstrated another, more productive way in Squeak. The thing is,
it is possible, and to my mind, the main reason it is not in wide use is
because that dreadful image problem is not as dreadful as it is made out
to be (by some).

Well, I cannot offer you or Stef code, it is a proprietary application.
But I can talk about it, and there is nothing special about the code. It
is not deeply hackish/mop-ish from an implementation point of view. Of
course, it is so from a conceptual point of view.

I think the main insight was that these do not have to be universal
features in the image, they do not need to include the base classes,
anyway the base image code would not know what to do with them. So if we
only need them for application-specific code, we can simply make all our
classes be subclasses of a certain class, let's call it Special, and
restrict our modifications to these subclasses. Well, I lied, there was
a need for a few special base classes (collections), and as a result
there was a little bit of hierarchy duplication because collection-like
classes were created as subclasses of Special.
The rest was achieved by modifying the browsers, to make them aware of
(and to display and make editable) the extra features. This was all the
meta-layer separation that we needed, the wiring was almost never
touched, and all the development happened through normal (but enhanced)
browsers. This had a very natural feeling to it, it almost looked like
Smalltalk itself had those extra properties.

Cheers,

Florin

On Fri, 09 May 2008 21:30:45 +0200, Vassili Bykov wrote:

3*] (myPrototype class) become: myPrototype new;
      copyFrom: myPrototype

A prototype together with its first clone; perhaps the closest  
approximation in Smalltalk-80.

Anyways, thank you Vassili for your time and patience; discussing  
fundamental concepts of language level quality is quite rare here in  
squeak-dev ;)

/Klaus

P.S. hurry up, when can we see the first Newspeak release :)

> Cheers,
>
> --Vassili
>
>

On Fri, May 9, 2008 at 10:31 PM, Florin Mateoc <[hidden email]> wrote:
> I think you forgot the new kinds of literals introduced to support
> namespaces, plus I suspect that you bear some responsibility for the
> increase in complexity in VW as well :)

I bear some responsibility for work in VW. Why work equals increased
complexity is an interesting question, and besides organizational
things it ties right into the concept of an image as a delivery
artifact. Combine it with paying customers who expect their
applications which depend on the last 15 years of the image genesis to
keep working, and you have yourself a nice katamari ball which only
knows how to grow.

> Come on, you had just mentioned nested classes, isn't that a new concept?
> And doesn't the label "Access modifiers" hide a collection of
> concepts/features ?
> And mixins, are they themselves classes or are they separate concepts from
> classes?

I didn't include nesting because it is a relationship rather than a
core entity. It's not a biased exclusion--otherwise I'd have to
include things like inheritance, importing of pool dictionaries by
classes and a few other things.

Access modifiers represent a single concept: acceptance policy of
messages. Just like methods, classes and slots are accessed by sending
messages (and *only* by sending messages). A public class/slot/method
means its accessor message is accepted from any object. For a private
construct, an accessor message is accepted only from the same object.

A mixin is a primary concept. Classes and their inheritance are
derivatives. A subclass is an application of a mixin to a superclass.
Thus, a class in general is a chain of mixin applications beginning
with nil.

> And talking about global scope, e.g. Java doesn't have (an objectified)
> global scope. So what do people do when they need it? They stick whatever
> they need in a class, which is globally visible (I assume this is true even
> in Newspeak), and access it indirectly. The only thing you "gained" is an
> extra indirection.

No, global visibility of classes is not true in Newspeak. Everything,
and that means _everything_ is a message send. A module can only use
library classes it retrieved by sending messages to a library instance
passed as an initialization argument. I already illustrated it in the
last message, but in case it got lost among other points:

class MyApp usingLibrary: library = (
  private Array = library Collections Array.
  private Stream = library Streams Stream.
  ...

This is how MyApp learns "global" class names. Class names are just
accessor methods in their containing class. Here, we assume that the
library is subdivided into submodules such as Collections and Streams,
so that we first retrieve one of those and then the class.

> Sure, global scope should not be abused. But it is damned convenient. Very
> useful as a quick debugging aid.

Nothing prevents you in Newspeak from having *a* scope somewhere to
use as a debugging aid. Except that it will be your own private
debugging aid scope nobody else will see or depend on.

> Ah, you mentioned the "dirty image" curse word! Time for another rant:

There was no such word in what I said. Images are extremely useful as
development workplaces. But not as much as delivery tools. Most people
who know what they are doing are taking care that their work is not
dependent on *the* image. They set up a declarative scheme where a
work image is built from a seed image and sources. Too bad that the
"seed" in case of something like Squeak starts off with the world and
a kitchen sink, and in case of VW it must keep alive the past 15 years
of Smalltalk industry.

Cheers,

--Vassili

2008/5/11 Vassili Bykov <[hidden email]>:
Similar can be easily implemented in smalltalk.
As well as private/public symbol scoping.

I think more fair comparison would be not comparing
implementation-related concepts , but only languages.
Smalltalk is pretty obscure in this regard: it defines only message
sending syntax. blocks & methods and yes, assignment and instance
vars.
The rest is implementation specific.
Even a class 'definition' is nothing more than a message send:

ProtoObject subclass: #Object
        instanceVariableNames: ''
        classVariableNames: 'DependentsFields'
        poolDictionaries: ''
        category: 'Kernel-Objects'.

Can you say the same for NewSpeak?

Its only a question of implementing new method at class side to make a
'private' subclass whatever that may mean to users:

Object privateSubclass: #MyPrivateSubclass
...

> This is how MyApp learns "global" class names. Class names are just
> accessor methods in their containing class. Here, we assume that the
> library is subdivided into submodules such as Collections and Streams,
> so that we first retrieve one of those and then the class.
>

nothing prevents you to use implement similar concepts in smalltalk.

All you need (at least in Squeak) is to provide own implementation of
#bindingOf: method which sent to a class by compiler to resolve names
which not found in local scope, when method being compiled.
So, in smalltalk, it is a choice of implementor to introduce 'private'
symbols or other privileges in own, arbitrary way, not in the way how
other people see the meaning of private symbols.



--
Best regards,
Igor Stasenko AKA sig.

On Sun, May 11, 2008 at 11:26 AM, Igor Stasenko <[hidden email]> wrote:
>  Similar can be easily implemented in smalltalk.
>  As well as private/public symbol scoping.
>
>  I think more fair comparison would be not comparing
>  implementation-related concepts , but only languages.
>  Smalltalk is pretty obscure in this regard: it defines only message
>  sending syntax. blocks & methods and yes, assignment and instance
>  vars.

You are eroding abstraction level boundaries. See ANSI Smalltalk spec
for what's considered as a language-level concept. Classes are a
language-level concept. The fact that they are objects and the use of
messages to define them is implementation.

More importantly, I don't think you realize that the real issue is not
(only) providing a capability. You can layer many capabilities on top
of Smalltalk. The issue is that a capability alone assures nothing,
while it is *assurances* that make abstractions useful by making them
reliable. For example, one could argue that message-based OO
programming could be done in C, obviating the need for something like
Smalltalk. The point is that besides providing a capability to do
message sends, Smalltalk enforces it as the only means of expression.
It also eliminates boilerplate code to perform common operations, thus
streamlining your expression. Same here. Some facilities are provided
and enforced, and their expression streamlined. Whether or not they
can be done in Smalltalk is irrelevant.

Regarding programmatic class creation, it's only a matter of having
reflection facility your code is allowed to use. BTW, it's "Newspeak"
with a lowercase "s", and I thought a "SmallTalker" would notice such
things. :)

>  All you need (at least in Squeak) is to provide own implementation of
>  #bindingOf: method which sent to a class by compiler to resolve names
>  which not found in local scope, when method being compiled.

As long as that's a facility for your own corner of the image, it
won't accomplish what one would need it for. It won't allow an
application written for Foobar 3.8 to coexist with one that wants
Foobar 3.10. There can only be one Foobar in the SystemDictionary, and
that's that. Who said DLL hell was a Windows-only problem?

Cheers,

--Vassili

On Mon, 12 May 2008 00:52:33 +0200, Vassili Bykov wrote:

> On Sun, May 11, 2008 at 11:26 AM, Igor Stasenko wrote:
[...]
>>  All you need (at least in Squeak) is to provide own implementation of
>>  #bindingOf: method which sent to a class by compiler to resolve names
>>  which not found in local scope, when method being compiled.
>
> As long as that's a facility for your own corner of the image, it
> won't accomplish what one would need it for. It won't allow an
> application written for Foobar 3.8 to coexist with one that wants
> Foobar 3.10. There can only be one Foobar in the SystemDictionary, and
> that's that.

Yes, no, and a question:

No: it's relatively easy to create a smallish set of subclasses of  
SharedPool, fix #bindingOf: such that SharedPools are inherited correctly,  
and then distribute (with #declare:) the globals over these SharedPools  
and attach the pools where they are needed. Compiles well and runs well  
[have as yet not tested all classes, see following issue].

Yes: it's almost impossible to now change all the existing tools so that  
they no longer use SystemDictionary's singleton. That is, even now that  
SystemDictionary's instance is empty and two versions of Foobar are  
possible without any conflict, one wouldn't do that because of lack of  
tool support (or unwillingness to really do such Sisyphus change to all  
the existing tools).

Question: say you change a Newspeak module and want that now to be  
effective, for example you now have FastOrderedCollection besides  
OrderedCollection. Since all is message based and the platform argument  
which was passed in at module creation time has gone long time ago, how's  
that done?

My guess: you browse all senders of OrderedCollection, judge and then  
Sisyphus changes the respective method(s), as ordered by Tartarus, right?  
And then?

> Who said DLL hell was a Windows-only problem?

Hhm, that wasn't you ? ;)

> Cheers,
>
> --Vassili
>