[squeak-dev] talk on Newspeak online

[Igor Stasenko]

2008/5/8 Igor Stasenko <siguctua@...>:
>  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.

[Klaus D. Witzel]

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.

> It
> helps to understand what X gives and what it takes away. Also, the
> particular X can be quite different from X in $(language_name).
>
> What we are talking about here is _instance creation discipline_. Like
> any other discipline, it eliminates some freedoms in the interest of
> order and predictability. The question is always whether the gains of
> the latter compensate for the loss of former. I imagine 30 years ago
> there were people decrying the loss of goto and the freedom it brings.
>
> Here is what disciplined instance creation brings:
>
> 1. Better class usability. The first question one has when looking at
> an unfamiliar class is "how do I use it?". The next one is often "how
> does it work?" Answering both depends on knowing how an instance is
> created and initialized. A Newspeak class declaration always provides
> the answer. In contrast, in Smalltalk you can only guess what instance
> creation messages can produce a valid instance. Presumably, the ones
> in the class will. Maybe the inherited ones too. At least some of
> them. Or will they?
>
> 2. Assurance that the instance you get is initialized properly as
> intended by the class author.
>
> 3. Easier change management. When I need to add a Boolean flag to an
> instance, I add one line to the class saying
>
>    isFoo ::= false.
>
> This is the only change, other than actually using the flag, to ensure
> that the slot is there and properly initialized in all instances. I
> don't need to add a word to the class declaration to declare the
> variable, and then hunt down all possible initialization methods (what
> are they? did I cover all of them?) to ensure the initial value is
> always set. Furthermore, as the system mutates the existing instances,
> it can use this new declaration to initialize the slot in the old
> instances to at least have a value of proper type.
>
> In my experience, all of the above are significant benefits that make
> it easier to build reliable programs.
>
> On a more philosophical note, whether a "language shouldn't care or
> enforce rules aka 'constructors'". A language should help the
> developer use its facilities. Some rules and the structures they
> enforce may be helpful, even if they are not part of the language
> core. Objects are the primary facility of Smalltalk/Newspeak, and
> their creation is a common operation. Proper initialization is indeed
> concern of a developer, but it *can* in fact be eased with language
> semantics. Again, this is not a hypothetical proposition, this is my
> experience report.
>
> As for the "useful" case of skipping superclass initialization--again,
> goto proponents had various use cases of how indispensable it was. The
> two cases are not that far from each other. You lose some
> capabilities, but in the larger picture of writing more predictable
> software the loss is more of a "good riddance" to the ability to
> introduce non-local idiosynchrasies.
>
> Regarding "static constructor messages", I fail to see the problem.

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

> A
> message name is static by its nature, in that it is a human-readable
> reference to a certain behavioral contract. A "+" refers to a contract
> promising to perform an addition-like operation. "x:y:" refers to a
> contract to create a vector-like entity from components that carry a
> certain meaning. Patterns for adapting contracts with mismatching
> names have long existed, and can be applied to instance creation as
> well as they have been elsewhere.
>
> Cheers,
>
> --Vassili
>
>

[Igor Stasenko]

2008/5/8 Klaus D. Witzel <klaus.witzel@...>:

> 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*.
>

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.

[Klaus D. Witzel]

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

> 2008/5/8 Klaus D. Witzel <klaus.witzel@...>:
>> 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*.
>>
>
> C++ is crap, Java is crap, anyone wants to argue?

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? ;)

> 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?

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 ;)

> 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

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.
>

[Igor Stasenko]

2008/5/8 Klaus D. Witzel <klaus.witzel@...>:

> On Thu, 08 May 2008 12:30:54 +0200, Igor Stasenko wrote:
>
>
> > 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? ;)
>

Is it just only because *crap* is rude word or because it not
precisely characterizing problems? ;)

>
> > 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
>

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

>
>
> > 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 ;)
>
>
>
> > 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
> >
>
>  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 :|
>

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 :)

>
>
> > 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?
>

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.

[danil.osipchuk]

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 :)

Vassily has shown several benefits of using newspeak constructors that were not discussed further, and  it doesn't look like a simple cut of a razor. The single place to describe slots and ease of migration are strong points.
For most of us good news are that  Newspeak is being developed by a small team of incredibly experienced Smalltalk/Language architects for their own needs and they know what they do for sure. Vassily says it works and works well. They say - we listen :) The whole thing is their own business, but they kindly convinced management to release the result to the public. It is disappointing that such a great initiative is being described in not so nice terms.
Personally  I  anticipate  Newspeak's release it it happens as the next great thing after Smalltalk (unfortunately Self was not released *properly* to be in between).

cheers,
  Danil

--
Best regards,
Igor Stasenko AKA sig.

[Klaus D. Witzel]

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

> 2008/5/8 Klaus D. Witzel wrote:
>> On Thu, 08 May 2008 12:30:54 +0200, Igor Stasenko wrote:
>>
>> > 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? ;)
>>
>
> Is it just only because *crap* is rude word or because it not
> precisely characterizing problems? ;)

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

>>
>> > 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
>
> 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

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.

>
>>
>> > 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 ;)
>>
>>
>> > 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
>> >
>>
>>  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 :|
>>
>
> 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 :)
>

Sure.

>>
>> > 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?
>>
>
> 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 ;)

> 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 ;)

[Igor Stasenko]

2008/5/8 Klaus D. Witzel <klaus.witzel@...>:

> On Thu, 08 May 2008 14:06:09 +0200, Igor Stasenko wrote:
>
>> 2008/5/8 Klaus D. Witzel wrote:
>>>
>>> On Thu, 08 May 2008 12:30:54 +0200, Igor Stasenko wrote:
>>>
>>> > 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? ;)
>>>
>>
>> Is it just only because *crap* is rude word or because it not
>> precisely characterizing problems? ;)
>
> Both, of course; you know me by now ;) The third is [OT] your new role
> (being on the board ;)
>

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.

>>>
>>> > 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
>>
>> 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
>
> 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.
>

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 :)

>> 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 ;)
>
>
>

--
Best regards,
Igor Stasenko AKA sig.

[Vassili Bykov-2]

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

[Igor Stasenko]

2008/5/9 Vassili Bykov <smalltalkbigot@...>:

> 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?
>

Point taken. :)

> 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
>

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.

> 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.
>

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.

> 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.
>

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.

[Simon Michael]

> 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..

[Florin Mateoc]

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.

> 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.
>

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

> 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 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