[squeak-dev] talk on Newspeak online

2008/5/8 Igor Stasenko <[hidden email]>:
>  Btw, no one disallow you from doing following:
>
>  MyStrictClass>>new
>    self isInDevelopmentMode ifTrue: [self checkConstructor].
>     ^ super new
>
>  so, it will cost you 1 extra send in deployed mode :)
>

Sorry for repost,
this example actually shows that developer can easily enforce own
(arbitrary) coding discipline, but without the need in changing
anything in language.

--
Best regards,
Igor Stasenko AKA sig.

On Thu, 08 May 2008 00:17:07 +0200, Vassili Bykov wrote:

> I have considerable experience programming in both Smalltalk and
> Newspeak, and (despite my email address) I'll say that Newspeak is an
> improvement in a number of aspects. That includes constructors.
>
> The knee-jerk reaction of "X is crap because $(language_name) which
> has X is crap" can prevent you from seeing the nature of the issue.

Vassili, this is squeak-dev list here, in which nobody would ever call a  
language which based on Smalltalk (and Self) as being *crap*.

We [yes, I think: we] all admire the tremedous work you folks are doing  
with developing Newspeak on the Squeak platform. I know many of us who  
can't wait to get a full copy of Newspeak on their notebook, same for  
myself (if only to browse for the first time in life a *very*high*modular*  
messaged-based Smalltalk-rooted system ;-)

AFAICT Igor is concerned about reduncancy and stiffness with particular  
language design decisions, on Newspeak constituents which he is used to  
implement himself in Smalltalk, on the fly and in such a way that it  
befits his actual project and not the language designer.

We can come back to this one once Newspeak has been released to the  
public; I think that it will not be released without constructors. For the  
moment, there seem to be people who either misunderstand the value of  
"static constructor messages" or have other concerns with it,

- http://www.google.com/search?q=newspeak+constructor+problem

My concern is that "static", which is unknown in Smalltalk+Self, has been  
introduced in Newspeak at the language level (I think that Igor would call  
this redundant). I have time, for me that can wait until I can play with  
the system for myself ;) One possible solution, without change in language  
design, is (of course) to always accept the default "static constructor  
message" (implicitly #new) and handle the rest as with Smalltalk (just in  
the way that Igor wants it :)

But I suggest that we don't go deeper here in squeak-dev, since there is  
as yet no compulsorily Newspeak language reference manual.

/Klaus

2008/5/8 Klaus D. Witzel <[hidden email]>:
C++ is crap, Java is crap, anyone wants to argue?
And borrowing crappy concept from crappy language produces crap.
Crap, despite how good it looks like outside (syntax sugar) still
stays crap inside. ;)
More about this at the end of message.

>  We [yes, I think: we] all admire the tremedous work you folks are doing
> with developing Newspeak on the Squeak platform. I know many of us who can't
> wait to get a full copy of Newspeak on their notebook, same for myself (if
> only to browse for the first time in life a *very*high*modular*
> messaged-based Smalltalk-rooted system ;-)
>

I'm looking forward to see Newspeak on my box.
But my primary concern is not language problems (and what tricks
authors made to get around them), but paths taken to meet goals of:
- modularity
- locality
- security
- reflectivity
- flexibility of kernel/libraries.


>  AFAICT Igor is concerned about reduncancy and stiffness with particular
> language design decisions, on Newspeak constituents which he is used to
> implement himself in Smalltalk, on the fly and in such a way that it befits
> his actual project and not the language designer.
>

Right. One more point: What about metaprogramming?

Does anyone finds following pattern as bad style of programming? :

MyExternalModule>>new
   Smalltalk platformName = 'Windoze' ifTrue: [ ^ MyWin32ExternalModule new ].
   Smalltalk platformName = 'Mac' ifTrue: [ ^ MyMacExternalModule new ].
   Smalltalk platformName = 'foo' ifTrue: [ ^ MyfooExternalModule new ].
self error: 'Unsupported platform'.

The users of class does not care about subclasses and calling uniform
MyExternalModule>>new which returning a proper instance for working on
current platform.
Interesting, how above looks in Newspeak?

Also, how about creating anonymous instance factories (also known as
classes) on the fly?

AnonClassFactory>> x: aX y: aY
  | newClass |
newClass := ClassBuilder new
                newSubclassOf: self
                type: self typeOfClass
                instanceVariables: ''
                from: nil.
^ newClass new x: aX y: aY

And finally, who told that, ultimately, only classes can create instances?
Its interesting, in what way something like Prototype package can be
implemented in NewSpeak?

Personally, i see that constructors putting flaws in message-oriented
principles of NewSpeak.
They shifting responsibility of message handling from developer's
hands to compiler's hands and introducing unnecessary constrains
forcing future developers to invent schemes how to avoid/sidestep
them.


--
Best regards,
Igor Stasenko AKA sig.

On Thu, 08 May 2008 12:30:54 +0200, Igor Stasenko wrote:

This I what I thought but, you wrote it in your words ;)

> And borrowing crappy concept from crappy language produces crap.
> Crap, despite how good it looks like outside (syntax sugar) still
> stays crap inside. ;)

We'll see what *crap* you will produce (when Newspeak is released) when  
you're asked to then show solutions (in then existing Newspeak code) for

o every class can be mixed in [modulo slot name collision]
o modules are containers with high degree of isolation
o no extra code to make *something* a module
o subclassing guarantees proper initialized subinstances

Can we stick with "redundant" instead of "crap" for the moment? ;)

I once read that Newspeak has sort of (anObject reflect) the mirror  
approch of Self (that is, no #class message).

> Does anyone finds following pattern as bad style of programming? :

Yes, me ;) I dislike your constants (strings and class names as well). I  
know you can do better ;) Also, you must change your method once you have  
one more platform (or after one is renamed to Microhoo ;) I prefer  
production systems that can be changed without compiling existing methods  
(for example, when foo is temporarily not supported but Mac can do part of  
its job for a while).

> MyExternalModule>>new
>    Smalltalk platformName = 'Windoze' ifTrue: [ ^ MyWin32ExternalModule  
> new ].
>    Smalltalk platformName = 'Mac' ifTrue: [ ^ MyMacExternalModule new ].
>    Smalltalk platformName = 'foo' ifTrue: [ ^ MyfooExternalModule new ].
> self error: 'Unsupported platform'.

MyExternalModule>>#newFor: platName
  (Symbol hasInterned: platName ifTrue: [:sym | sel := sym])
    ifFalse: [self error: '*unknown* platform name'].
  subclass := self platsSupported at: sel ifAbsent: [self error:  
'*unsupported* platform name'].
  ^ subclass new

> The users of class does not care about subclasses and calling uniform
> MyExternalModule>>new which returning a proper instance for working on
> current platform.
> Interesting, how above looks in Newspeak?

Preferable the way I rewrote it above (not only because that way it can be  
done in Newspeak ;)

This one addresses my concern: just put (... newSubclassOf: anArgument  
...) into the above and then begin to wonder about what's the constructor  
message selector's name :|

> And finally, who told that, ultimately, only classes can create  
> instances?
> Its interesting, in what way something like Prototype package can be
> implemented in NewSpeak?
>
> Personally, i see that constructors putting flaws in message-oriented
> principles of NewSpeak.

Do you think that it cannot be circumvented by the developer one way or  
the other in Newspeak?

If yes, why not?

> They shifting responsibility of message handling from developer's
> hands to compiler's hands and introducing unnecessary constrains
> forcing future developers to invent schemes how to avoid/sidestep
> them.
>

2008/5/8 Klaus D. Witzel <[hidden email]>:
Is it just only because *crap* is rude word or because it not
precisely characterizing problems? ;)

In fact, this code snippet belongs to VMMaker, not mine. ;)

I would write it with a single line (true ST way of doing things):

MyExternalModule class>>new
 ^ ( self allSubclasses detect: [:class | class supportsPlatform:
Smalltalk platformName ] ifNone: [ self error: 'unsupported platform'
] ) new


Well, a #new is not anyhow better than anything else. Who knows what
anArgument>>#new does? It may or may not create instance, it can
create an instance of different class, it can throw an error it can do
virtually anything :)

Hmm, what is the purpose of language feature then if it need to be
circumvented?
Seems like people forget to use
http://en.wikipedia.org/wiki/Occam's_Razor principles :)


--
Best regards,
Igor Stasenko AKA sig.

On Thu, 08 May 2008 14:06:09 +0200, Igor Stasenko wrote:

Both, of course; you know me by now ;) The third is [OT] your new role  
(being on the board ;)

Ahh, I knew you know how :) But, by the joy offered from implicit-self  
message sends (statement-initial identifiers *are* sent :) one could also  
keep your (VMMaker's) style 1:1 in Newspeak. It's Smalltalk -anyways- even  
when I say I dislike it [the style of your method example].

[OT] is the snippet in Slang? then there could be C-compilation-reason for  
the style.

Sure.

Quick: what's the most circumvented language feature people use when  
smalltalking ;)

> Seems like people forget to use
> http://en.wikipedia.org/wiki/Occam's_Razor principles :)
>

Nah. [OT] people tend to overuse (in the sense of over-cite) the razor  
principle, because its base is *plausible* *facts* which is only given  
when you *do*not* have plenty of choice (i.e. just choose between two).  
Otherwise the principle is synonym to lottery-principle ;)

2008/5/8 Klaus D. Witzel <[hidden email]>:
I trying to be constructive here. I not throwing a words that
*something* is stinks just because i don't like the *thing*,
i providing arguments and explanations why i think its err.. crappy :)
Oh, and i didn't used this word before Vassili started. Well, if
people want to defend their position more aggressively, i answer in
same style. But this not means that my point is not constructive
however.
Please do not take my comments as personal attack or ranting, i just
trying to put arguments and discuss why some things i think having
flaws.
Can't parse your last phrase. Please elaborate.

>> Hmm, what is the purpose of language feature then if it need to be
>> circumvented?
>
> Quick: what's the most circumvented language feature people use when
> smalltalking ;)
>
No idea. Put on desk the aces from you sleeve :)



--
Best regards,
Igor Stasenko AKA sig.

First of all, I take none of this personally or as an offense so don't
worry about the language or what's being said. In fact, it was I who
first referenced "crappy languages", and we seem to agree on what
those are. :)

I'm not arguing against the general thesis that borrowing crappy
features from crappy languages produces crap. But the important
question is whether constructors are a crappy feature in C++ or Java
because the *idea* of disciplined object initialization is flawed, or
because its particular incarnation in those languages is bad. Also,
"borrowing" is a vague notion with an arbitrary attribution. What
makes you believe that Newspeak "borrows" the idea of disciplined
object initialization from C++ or Java and not, say, from CLOS or
Dylan? And what exactly is borrowed, besides the term?

Igor, from trying to follow this thread I got an impression that the
reason for your pushback may be an implicit assumption that Newspeak
"constructors" are the same thing as Java constructors. It's
understandable that anyone here may have misconceptions, and that's
the reason I'm responding in this thread. There is not much
information out there, not because of any secrecy, simply because it's
not written up. I'd be happy to answer any questions that help clarify
things.

Now, as an aside, it's hard to parse a day's worth of posts consisting
mostly of many levels of quoted text and a few lines of actual
content, so excuse me if I missed a prior question worth answering. I
did notice the question about MyExternalModule and how that would look
in Newspeak. There are several possible solutions. Here is one:

class ExternalInterface platform: platform = (
    | platformName = platform platformName. |)
(
    private class MacOSExternalInterface  = ...

    private class LinuxExternalInterface  = ...

    private class Win32ExternalInterface  = ...

    new = (
        platformName = 'MacOS' ifTrue: [^MacOSExternalExternalInterface new].
        platformName = 'Linux' ifTrue: [^LinuxExternalExternalInterface new].
        platformName = 'Win32' ifTrue: [^Win32ExternalExternalInterface new].
        error: 'unknown platform'.
    )
)

I took the liberty of replacing "Module" with "Interface" to avoid
confusion, as I'll be talking about modules in a different sense.

This snippet illustrates many Newspeak things at once: absense of
global state, nested classes and classes-as-modules, read-only slots,
and message privacy. The top-level class ExternalModule plays the role
of a module. The argument 'platform' is a platform object the module
user will provide at the time a module instance is created, for
example as:

    ExternalInterface platform: Smalltalk

The use of '=' in the 'platformName' slot definition identifies it as
a read-only slot: the class will include a getter for it but no
setter.

The three nested classes are private, which means the module will not
respond to messages such as #MacOSExternalInterface if they are sent
by other objects. It will respond to these messages sent from itself,
as in the #new method. And thanks to that #new method, the module is
also a factory that creates an interface instance appropriate for the
platform.

As a user of this, you would likely create an instance of the module
and store in a slot defined as something like (assuming that
ExternalInterface and Smalltalk have been bound to appropriate
objects):

    Interface = ExternalInterface platform: Smalltalk.

And then create instances in the code with "Interface new". To the
rest of the code, "Interface" is no different from a real instantiable
class.

If the classes nested in ExternalInterface were not qualified as
private, it would be possible to retrieve them by sending a getter
message to the module and instantiate directly:

    (ExternalInterface platform: Smalltalk) Win32ExternalInterface new

Some other points.

Regarding freedom vs restrictions and predefined mechanisms, you have
to realize that very often abstraction design is like cutting a
fractal border with a straight knife. No matter how you do it, by
imposing regularities you leave something unnecessary and cut off
something useful. This is why any example like "here is one case where
X is clearly better than the alternatives" never proves anything by
itself, being only an isolated case. It's all a matter of statistics
and priorities.

I'm not sure how "locality" as a positive quality and the ability to
skip superclass initialization as a useful feature go together.

Regarding constructors "implemented" in Smalltalk--it shows two things
at once. 1) there if enough reflection in Smalltalk to implement
something like this, and 2) there is not enough syntactic abstraction
to hide the boilerplate and make it usable. There is a similar issue
with providing list comprehensions within Smalltalk/Newspeak syntax.
It's easy to do the work, but it's impossible to hide all the exposed
wiring, avoid binding names more than once, etc. In the end, it's only
a proof of concept and not a *usable* feature.

And, I completely agree with Klaus about Occam's Razor sometimes being
cited indiscriminately. There might be a place somewhere in the Fifth
Circle where Occam's Razor abusers are implementing a Blue Book VM on
the Turing machine.

Cheers,

--Vassili

2008/5/9 Vassili Bykov <[hidden email]>:
Point taken. :)

I very like the above, especially how NewSpeak provides a ways to hide
details from user but still there are subtleties which not covered
well.
In given example i assumed that ExternalInterface is basic abstract
class, which provides common interface,
while different subclasses providing specialization for each separate platform.

So, as far as i understood, the only constructor which can be used for
ExternalInterface is one which is sit in declaration:
 class ExternalInterface platform: platform

If this correct, then given the rule, that direct subclasses should
use this and only this constructor to initialize superclass, then how
subclass declaration would look like and why it would need to pass
'platform' again to superclass, which is already used in #new to
determine subclass and no more required?

I know, there can be a way around of this, by declaring it like following:

class ExternalInterface platform: platform = (
   | platformName = platform platformName. |)
 (
    private class BasicInterface  = ...
    private class MacOSExternalInterface  = BasicInterface ...   " not
sure if this notation is correct. i mean that MacOSExternalInterface
is subclasss of BasicInterface here"
)

But then this not better than having utility method (which chooses
appropriate specialization) in any other place not bound to any
specific class.
Also, suppose i loaded a module(package) which provides me the classes
above. Now, how i can create own XXXXOSExternalInterface, but place it
in my separate module, but still taken in account by ExternalInterface
if my module is loaded?
So, that ExternalInterface platform: XXXX should return an instance of my class.

----------
Also, there was a more important question, not answered.
The question sounds like following: And finally, who told that,
ultimately, only classes can create instances?

Is it possible to implement something like this
http://www.russell-allen.com/squeak/prototypes/ in NewSpeak?
And if yes, please show some code snippets.

True, but all cases need to be wighted before cutting.
If language enforcing X, it should provide an alternative how people
can implement Y (which being cut down) without much stress.

> I'm not sure how "locality" as a positive quality and the ability to
> skip superclass initialization as a useful feature go together.
>

I see a class chain as a set of objects which sharing same virtual
space. So, there is no need to draw hard borders between them and
there is no problem with initialization.
But of course, if classes are kind of mixins NewSpeak, then you are correct.

I think you are familiar with following, which is one of the razors:

If it looks like a duck, walks like a duck, and quacks like a duck -
it's a duck.

Going back to my question concerning classes and they sole role as
instance factories, it can sound like:

If it looks like a class, walks like a class, and quacks like a class
- it's a class.

And Prototypes using this principle quite well :)

> Cheers,
>
> --Vassili
>
>



--
Best regards,
Igor Stasenko AKA sig.

> Now, as an aside, it's hard to parse a day's worth of posts consisting
> mostly of many levels of quoted text and a few lines of actual


Oh lord yes please god make it stop..

Vassili Bykov wrote:

...
> This snippet illustrates many Newspeak things at once: absense of
> global state, nested classes and classes-as-modules, read-only slots,
> and message privacy. The top-level class ExternalModule plays the role
> of a module. The argument 'platform' is a platform object the module
> user will provide at the time a module instance is created, for
> example as:
>
>  
One thing that I particularly like about Smalltalk is precisely the
small number of features/concepts.
I don't think that more is always better, and all those "crappy"
languages prove it again and again.

Yes, you can always make a case that, as the developer of a piece of code, you want for example something to be read-only. In reality, if your code is to survive and to be shared with others, you will never be able to foresee the needs of all the developers coming after you that will (have to) maintain that code. Smalltalk is a blessing in this regard, because no matter how screwed up the legacy code is, one can always find a way to adapt it to new realities. In big part, this is because Smalltalk does not enforce almost anything, unlike languages that embrace the paradigm that the original developer always knows best (as if the original Java or C# developers always knew best when they built their first version of their class library. Or their second. Or their third...).

To give other examples of "order and discipline" concepts (or, as you
call them, "imposing regularities") that proved much worse than what
they gained: checked exceptions in Java, the non-override default for
methods in C#, and of course, visibility rules in all of them (and now
it seems in Newspeak).

Right now, at work, in a Java project, we cannot (easily) move to newer
versions of SWT because, as we needed access to aspects that the
original developers considered internal machinery (so they did not
expose them as an API),  we had to add stuff to their packages. And now
they sealed their packages. Because they can, and because they know
better. Why do they even bother to distribute the sources?

Not all developers are the same, not even if we only consider the
brilliant ones. Some are more paranoid than others, some are more
over-engineerish than others, some are more frugal, some are more
hackish. If you happen to find yourself downstream from a paranoid one,
and the language supports his or her paranoia, you are out of luck

And here I have to disagree again. I have worked on a large and
successful Smalltalk project, where some such internal machinery was
developed to add all kinds of semantics to the slots: default
values/initializers, constraints (types/values), persistence,
object-graph ownership relations, ... Yes, if you looked, you could see
the wiring. So what! It worked very well and no language will ever come
up with all the useful semantics that one may want to add.
At least Smalltalk lets you do it. Gilad with his pluggable type systems
should know better

Cheers,

Florin

On Thu, 08 May 2008 21:58:42 +0200, Igor Stasenko wrote:

> 2008/5/8 Klaus D. Witzel wrote:
>> On Thu, 08 May 2008 14:06:09 +0200, Igor Stasenko wrote:
[...]
Right, and from his other post it seems like he's using the word like any  
other slot name ;)

NP, back to the issues :)

> Well, if
> people want to defend their position more aggressively, i answer in
> same style. But this not means that my point is not constructive
> however.
> Please do not take my comments as personal attack or ranting, i just
> trying to put arguments and discuss why some things i think having
> flaws.

Sure, I knew we will agree on this :) And I think you know that I  
appreciate your valued critique. So when I ask, don't use "crap" word,  
then I want more/detailed critique, not the metaphors ;)

...
>> [OT] is the snippet in Slang? then there could be C-compilation-reason  
>> for the style.
>>
> Can't parse your last phrase. Please elaborate.

In Slang you wouldn't be able to use metaobjects (your use of #subclasses)  
nor dictionaries (as in my example) so one way to express the [small] case  
list in Slang is with a list of ifTrue's.

...
>>> Hmm, what is the purpose of language feature then if it need to be
>>> circumvented?
>>
>> Quick: what's the most circumvented language feature people use when
>> smalltalking ;)
>>
> No idea. Put on desk the aces from you sleeve :)

Will do but, not in this thread and at another time ;)

2008/5/9 Klaus D. Witzel <[hidden email]>:

[snip]

No, this piece of code is not related to slang part of VMMaker.
It used once to pick a version of code generator for particular platform.


--
Best regards,
Igor Stasenko AKA sig.

2008/5/9 Florin Mateoc <[hidden email]>:
One, big +1 to this post.
The one of reasons why i started looking for something better than
so-called mainstream languages is a freedom in expressing myself in
the way how i like it, not in the way how others think or expect it
should be.

Often a code library having both: a brilliant parts and worthless
cruft. There is a big difference between smalltalk & C++/Java clones
how well you can improve the library and how much efforts it can take.
And regularities 'helping' to make it harder.

Another aspect of visibility rules: they influencing developing
process, imposing the rules how people should use your code.
But when your application ready to run , these rules have nothing to
do in deployed system. They just left at early stages and again,
software left alone, running how it likes and not caring about the
rules.
The above means, that despite how much you did best to protect your
code from faults, there can be always a zillion cases how to put your
software on the knees. A C++/Java is good illustration of that - given
to many rules to 'protect' the code from faults at early stages, there
are still a lot big holes left, how users can abuse your code in a
numerous ways.


--
Best regards,
Igor Stasenko AKA sig.

On Thu, May 8, 2008 at 4:50 PM, Igor Stasenko <[hidden email]> wrote:
> In given example i assumed that ExternalInterface is basic abstract
> class, which provides common interface,
> while different subclasses providing specialization for each separate platform.

Good point. I thought to gloss over this to keep my explanation
shorter but no such luck. :) However, this leads to interesting
follow-up examples.

In your original example, and usually in real cases like this in
Smalltalk, the superclass plays several roles. As a class it captures
the common behavior, sometimes abstract sometimes not. As an object,
it is a factory. As a name in the developer's vocabulary it references
a piece of functionality, or a "module".

In my example an instance of the outer class is really a factory and a
module. I omitted a superclass for capturing common behavior. A more
complete example with more descriptive names would be:

class ExternalInterfaceFactory platform: platform = (
    | platformName = platform platformName. |
) (
    private class ExternalInterface = (...)

    private class MacOSExternalInterface = ExternalInterface (...)

    ...and so on...
)

Now that the pieces are more appropriately named, hopefully it is
clearer how they relate. You create an instance of a factory by
sending #platform: to the outer class, and then you create instances
of the nested classes by sending #new to the factory.

Note that the outer class still combines two roles: a module providing
some functionality and a factory. If need be, they can also be
separated:

class ExternalInterfaceModule platform: platform = (
|
    platformName = platform platformName.
    factory = InterfaceFactory new.
|
) (
    private class InterfaceFactory = ( | | ) (
        new = (
            platformName = 'MacOS' ifTrue: [^MacOSExternalInterface new].
            ...
        )
    )

    private class ExternalInterface = (...)

    private class MacOSExternalInterface = ExternalInterface (...)

    ...and so on...
)

This would now be used in a two-step process, first creating the
module and then retrieving its factory to create instances. A factory
could be designed to support "plugins" for other platforms registered
with a message such as #createInstancesFor:using:. Presumably some or
all of the nested classes would be public in such a scenario to make
them available for subclassing.  A user module might look something
like:

class MyApp platform: platform externalInterface: moduleClass = (
|
    ExternalInterfaceModule = moduleClass platform: platform.
    ExternalInterface = ExternalInterfaceModule factory.
    AbstractExternalInterface = ExternalInterfaceModule ExternalInterface.
|
    Interface createInstancesFor: 'Foobar' using: [^FoobarExternalInterface new]
) (
    private class FoobarExternalInterface  = AbstractExternalInterface (...)
    ...
)

This also illustrates how a class declared under one name can be bound
to a different name within another module, to avoid a name conflict or
on a whim. Here we suppose that in our code we want to write
"ExternalInterface new" to create instances of interfaces, so we bind
that name to a factory. To avoid a conflict, the ExternalInterface
class retrieved from the module is made known as
AbstractExternalInterface.

Regarding prototypes--this isn't a model Newspeak supports *as part of
the language standard*. But before you say "boo!"--neither does
Smalltalk. A particular Smalltalk *system* may allow making a behavior
an instance of itself as an implementation-specific feature.
Smalltalk-80 had no facilities for that. Adrian Kuhn first implemented
his Protalk on VisualWorks last year, but a year or so before he
wouldn't be able to. Eliot had a thought to try self-instantiating
behaviors for a personal project he and I worked on in 2006, and that
was when he fixed the VM to allow that.

All this is to say that I'm being very careful to draw a line between
what a language provides as a standard facility which doesn't cross a
metalevel boundary, and reflective capabilities of certain
implementations. With this caveat--of course, a particular Newspeak
implementation and *in a particular context*--more on this after the
example--could support creation of self-instantiated behaviors. Of
course, it would be done through a controllable mirror interface. For
example:

   newBehavior: Behavior new.
   newMirror: (ObjectReflection reflect: newBehavior).
   newMirror
      objectClass: newBehavior;
      methodAt: #foo put: ...

Unlike the usual model of just changing the class, here the reflection
facility is in control of what reflective capabilities the code
receives in the form of a mirror.  For example, an untrusted
application in a web browser might receive a mirror with no
modification capabilities, or no capabilities at all. Find and watch
Gilad's talk at Google on "objects as software services", it will give
you an idea of what are the priorities for Newspeak.

Cheers,

--Vassili

On Fri, 09 May 2008 18:49:07 +0200, Vassili Bykov wrote:

...
> Regarding prototypes--this isn't a model Newspeak supports *as part of
> the language standard*. But before you say "boo!"--neither does
> Smalltalk. A particular Smalltalk *system* may allow making a behavior
> an instance of itself as an implementation-specific feature.
> Smalltalk-80 had no facilities for that.

Do you mean that the following steps are not possible:

1] myPrototype := Behavior new
2] initialize the instVars of myPrototype properly
3] myPrototype class become: myPrototype

Why shouldn't that be possible, right from the beginning of Smalltalk-80?

> Adrian Kuhn first implemented
> his Protalk on VisualWorks last year, but a year or so before he
> wouldn't be able to.

Adrian mailed me his Squeak implementation in which (IIRC) he makes use of  
Squeak's #primitiveChangeClassTo: as a "safer" way of above step 3] but  
the rest is same as above. My response to him was that I've invented that  
as well ;) In his words from his Protalk page:

Protalk is pure Smalltalk, it relies on two features that had been hiding  
in plain sight since Smalltalk-80
o Every object can possible be used as a class
o The class of an object can change after instantiation

I fully agree with Adrian. FWIW behaviors as instances of themselves seem  
to have been invented by the many, IIRC Dan was mentioned here in  
squeak-dev by someone, some time ago.

Ergo, the facilities for prototypes (behaviors as instances of  
themselves), in Smalltalk #class and #become:, date back to the invention  
of Smalltalk.

FWIW it might be possible that some VMs don't do #become: with all (or  
some non-smi) objects, that would be sad because then the developers who  
use such "crappy" VMs wouldn't be able to use the industrial light+magic  
of Smalltalk ;)

/Klaus

On Fri, May 9, 2008 at 11:27 AM, Klaus D. Witzel <[hidden email]> wrote:
>
> Do you mean that the following steps are not possible:
>
> 1] myPrototype := Behavior new
> 2] initialize the instVars of myPrototype properly
> 3] myPrototype class become: myPrototype
>
> Why shouldn't that be possible, right from the beginning of Smalltalk-80?

Because in step (3) at the same time as "myPrototype class" becomes
myPrototype, myPrototype becomes "myPrototype class". ST-80's become:
swaps identities, not assigns them.

Cheers,

--Vassili

On Thu, May 8, 2008 at 11:04 PM, Florin Mateoc <[hidden email]> wrote:
> One thing that I particularly like about Smalltalk is precisely the small
> number of features/concepts.
> I don't think that more is always better, and all those "crappy" languages
> prove it again and again.

Hi Florin, it's good to see you. Here are lists of core concepts of a
couple of modern Smalltaks, and of Newspeak. I'm skipping secondary
and transient artifacts such as categories, method arguments, temps
and contexts.

Squeak:

Instances
Classes
Traits
Methods
Messages
Assignment
Instance variables
Class variables
Class instance variables
Pool dictionaries
SystemDictionary (global scope)

VisualWorks:

Instances
Classes
Methods
Messages
Assignment
Instance variables
Class shared variables
Class instance variables
Class imports
Namespaces
Namespace shared variables
Namespace imports
Name visibility
Import visibility
SystemDictionary (global scope)

Newspeak:

Instances
Mixins (classes are only applications of mixins)
Methods
Messages
Slots
Access modifiers
Initializers

> Not all developers are the same, not even if we only consider the brilliant
> ones. Some are more paranoid than others, some are more over-engineerish
> than others, some are more frugal, some are more hackish. If you happen to
> find yourself downstream from a paranoid one, and the language supports his
> or her paranoia, you are out of luck

Right. This is an old argument, and my sympathy has always been (and
still is) with the side arguing for less control and paranoia. It
feels funny to seem to argue the opposite. But it often helps to
analyze your own weaknesses. One of the big weaknesses of Smalltalk is
the inability of untangling your application from the rest of the ball
of wax. The proof of this are the niches where it is successful. One
of the characteristics of those is that deployment is very
controllable. You are either on a server or in a position of not
scaring users away by a multi-megabyte monolithic install. "20M for an
RSS reader? You've got to be kidding!" The second important factor,
Dolphin being a pleasant exception, is that the users shouldn't be
scared by ugly and clunky GUIs. Marketing megadollars and
institutional stupidity are big problems, but there are the technical
issues that exacerbate them. Show me how my Smalltalk app can be
separated from image version 3.10.1234 with custom patches to
WorldState and initialization of ClassBuilder circumvented by my very
special subclass, and shipped over the wire to run elsewhere. Funny
that I should be among the least unhappy with the status quo--I've
been paid for working in Smalltalk for 15 years straight. Perhaps if
us Smalltalkers are happy to mediate on the perfection of our navel
with no regard to what happens outside the image, we shouldn't be
concerned with vulgar issues such as relevancy and paid jobs.

> And here I have to disagree again. I have worked on a large and successful
> Smalltalk project, where some such internal machinery was developed to add
> all kinds of semantics to the slots: default values/initializers,
> constraints (types/values), persistence, object-graph ownership relations,
> ... Yes, if you looked, you could see the wiring.

I'd be interested to see an example. I really mean it. Especially
default values/initializers.

Cheers,

--Vassili

Hi florin

I'm thinking about a nice mop interface that would let people define  
such a different slot semantics.
By any chance do you have still in mind how yours were done and how  
you specified their semantics
If you have any information on that direction this would be great.  
(I'm born in CLOS and its designed mop
is also trying to drag me there... :)

Stef