[squeak-dev] talk on Newspeak online

[Andreas Raab]

Wilkes Joiner wrote:
> Understandably, he doesn't want to unleash Newspeak right now.  I'm
> hoping that they will release just the FFI vm enhancements.  Assuming
> that would be relatively simple to release independently.

Someone wake me up when that happens ;-)

Cheers,
   - Andreas

[Vassili Bykov-2]

On Sun, Apr 20, 2008 at 6:42 AM, Damien Pollet <damien.pollet@...> wrote:

> On Sat, Apr 19, 2008 at 4:15 PM, Bert Freudenberg <bert@...> wrote:
>  > Certainly. However, Gilad said they do not intend to release it.
>  >
>  >  - Bert -
>  >
>  >  On 19.04.2008, at 15:40, Wilkes Joiner wrote:
>  >
>  > > Really interesting talk.
>  > >
>  > > Is there anyway that the FFI his team created could be merged back
>  > > into the main squeak vm?
>
>  Hmm, I understood the contrary, that he was trying to convince his
>  management that opensource was the way to go…

That is correct.

--Vassili

[Marcel Weiher-3]

On Apr 17, 2008, at 23:42 , Michael Haupt wrote:

> Gilad Bracha's talk on the Newspeak language (which he gave at the
> Hasso-Plattner-Institut in Potsdam, Germany on March 11) is now online
> at http://www.tele-task.de/page50_lecture3490.html.

Despite what the error messages say, the problem with the video on Mac  
OS X does not appear to be the format, but the network connection.  I  
had the same error message others reported and now I am in a different  
(network) environment and the talk plays just fine.  (I guess it's  
possible that when the network connection fails, it retries in some  
unsupported format...)

Marcel

[Andreas Raab]

Andreas Raab wrote:
> Wilkes Joiner wrote:
>> Understandably, he doesn't want to unleash Newspeak right now.  I'm
>> hoping that they will release just the FFI vm enhancements.  Assuming
>> that would be relatively simple to release independently.
>
> Someone wake me up when that happens ;-)

Josh just pointed out that it may be time to open at least one eye ;-)

   http://gbracha.blogspot.com/2008/05/future-of-newspeak.html

Also, some interesting papers referenced here:

   http://bracha.org/Site/Newspeak.html

Cheers,
   - Andreas

[Igor Stasenko]

I read Gilad's blog and having some concepts which i think is
redundant and smell like javaisms.
For instance, i don't share the view, that all fields in class
instance should be initialized and initialized once, by constructor
(instance factory method).
What about lazy initialization?
What if superclass initializes ivar with something, then using that
ivar during rest of initialization phase, and then at subclass
initialization it can be overridden by another value, after done
initializing superclass.
I think that language shouldn't care or enforce rules aka
'constructors', its totally redundant to me. Developer should know
himself, how and where initialize ivars, not in compiler/constructor.

Declaring private/public fields looking redundant too: they should be
always private.
Instead, accessors #foo, #foo: can be made public or private by the will.
But if you make field public, then it's accessors became public as
well? But what if i want #foo to be public, but #foo: to be private?

--
Best regards,
Igor Stasenko AKA sig.

[danil.osipchuk]

Igor, could you please give a link to the article where Gilad speaks about it?

(I can not find anything related in his blog)

 

Danil

2008/5/7 Igor Stasenko <siguctua@...>:

I read Gilad's blog and having some concepts which i think is
redundant and smell like javaisms.
For instance, i don't share the view, that all fields in class
instance should be initialized and initialized once, by constructor
(instance factory method).
What about lazy initialization?
What if superclass initializes ivar with something, then using that
ivar during rest of initialization phase, and then at subclass
initialization it can be overridden by another value, after done
initializing superclass.
I think that language shouldn't care or enforce rules aka
'constructors', its totally redundant to me. Developer should know
himself, how and where initialize ivars, not in compiler/constructor.

Declaring private/public fields looking redundant too: they should be
always private.
Instead, accessors #foo, #foo: can be made public or private by the will.
But if you make field public, then it's accessors became public as
well? But what if i want #foo to be public, but #foo: to be private?

--
Best regards,
Igor Stasenko AKA sig.

[Michael Haupt-3]

Hi Danil,

On Wed, May 7, 2008 at 11:26 AM, danil osipchuk
<danil.osipchuk@...> wrote:
> Igor, could you please give a link to the article where Gilad speaks about
> it?
> (I can not find anything related in his blog)

probably you will find what you are looking for by looking at the
beginning of this very thread. ;-)

Best,

Michael

[Damien Cassou-3]

On Wed, May 7, 2008 at 10:22 AM, Igor Stasenko <siguctua@...> wrote:

> I read Gilad's blog and having some concepts which i think is
>  redundant and smell like javaisms.
>  For instance, i don't share the view, that all fields in class
>  instance should be initialized and initialized once, by constructor
>  (instance factory method).
>  What about lazy initialization?
>  What if superclass initializes ivar with something, then using that
>  ivar during rest of initialization phase, and then at subclass
>  initialization it can be overridden by another value, after done
>  initializing superclass.
>  I think that language shouldn't care or enforce rules aka
>  'constructors', its totally redundant to me. Developer should know
>  himself, how and where initialize ivars, not in compiler/constructor.

More on constructors in newspeak:
http://gbracha.blogspot.com/2007/08/object-initialization-and-construction.html.

In Smalltalk, we have no constructor. However, when we want to
initialize data from an instance creation method we have to use
accessors:

Person class>>name: aString birthdate: aDate
  ^ self new
         name: aString;
         birthdate: aDate;
         yourself

Another solution is to use a specific method like #setName:birthdate:.
However, these solutions pollute the interface of the Person class:
the developer is forced to add these methods to the public interface
of the Person class.

I believe Newspeak's solution may fix that point. What do you think?

--
Damien Cassou
Peter von der Ahé: «I'm beginning to see why Gilad wished us good
luck». (http://blogs.sun.com/ahe/entry/override_snafu)

[danil.osipchuk]

I've seen Gilad's presentation, but I can not remember if he spoke about constructors there either. And I had impression from that talk that variables (my memory is not good though :-) ) in newspeak are similar to Self's slots - access through message send only, so where do private/public ivars come from?

 

Danil

2008/5/7 Michael Haupt <mhaupt@...>:

Hi Danil,

On Wed, May 7, 2008 at 11:26 AM, danil osipchuk
<danil.osipchuk@...> wrote:
> Igor, could you please give a link to the article where Gilad speaks about
> it?
> (I can not find anything related in his blog)

probably you will find what you are looking for by looking at the
beginning of this very thread. ;-)

Best,

Michael

[Michael Haupt-3]

Hi Danil,

sorry, I misunderstood you there. :-)

Best,

Michael

On Wed, May 7, 2008 at 11:39 AM, danil osipchuk
<danil.osipchuk@...> wrote:

> I've seen Gilad's presentation, but I can not remember if he spoke about
> constructors there either. And I had impression from that talk that
> variables (my memory is not good though :-) ) in newspeak are similar to
> Self's slots - access through message send only, so where do private/public
> ivars come from?
>
> Danil
>
>
> 2008/5/7 Michael Haupt <mhaupt@...>:
>
>
>
> > Hi Danil,
> >
> >
> > On Wed, May 7, 2008 at 11:26 AM, danil osipchuk
> > <danil.osipchuk@...> wrote:
> > > Igor, could you please give a link to the article where Gilad speaks
> about
> > > it?
> > > (I can not find anything related in his blog)
> >
> > probably you will find what you are looking for by looking at the
> > beginning of this very thread. ;-)
> >
> > Best,
> >
> > Michael
> >
> >
>
>
>
>
>

[Nikolay Suslov]

Hello,
here is the article introducing the Newspeak Programming Platform (http://bracha.org/newspeak.pdf)
with some code examples.

Nikolay

On Wed, May 7, 2008 at 11:39 AM, danil osipchuk <danil.osipchuk@...> wrote:

I've seen Gilad's presentation, but I can not remember if he spoke about constructors there either. And I had impression from that talk that variables (my memory is not good though :-) ) in newspeak are similar to Self's slots - access through message send only, so where do private/public ivars come from?

 

Danil

2008/5/7 Michael Haupt <mhaupt@...>:

Hi Danil,

On Wed, May 7, 2008 at 11:26 AM, danil osipchuk
<danil.osipchuk@...> wrote:
> Igor, could you please give a link to the article where Gilad speaks about
> it?
> (I can not find anything related in his blog)

probably you will find what you are looking for by looking at the
beginning of this very thread. ;-)

Best,

Michael

[Klaus D. Witzel]

On Wed, 07 May 2008 10:22:46 +0200, Igor Stasenko wrote:

> I read Gilad's blog and having some concepts which i think is
> redundant and smell like javaisms.

;)

> For instance, i don't share the view, that all fields in class
> instance should be initialized and initialized once, by constructor
> (instance factory method).
> What about lazy initialization?

Lazy in the sense of, a) initialize them with nil [in the constructor]  
then later b) assign them anything else? That's always possible, isn't it.  
I don't see much a problem here, except the *cause* of such language  
design decision. The latter is concerned with 1) modularity-ness of each  
and every constituent 2) non-staticness of each and every constituent and  
3) mixin-able-ness of every class (aka behavior-bearing object). To  
highlight just one problem in this >= 3 dimension time-space, which AFAICT  
is not solved yet (or perhaps just not published yet) in Newspeak: its  
*constructor* selector (the symbol) is for sure a *static* symbol  
constituent, violating non-staticness desideratum ... that is to say, even  
in a very-highly modularized Newspeak system you have to know the  
constructor message name of the things you import/mixin so, what about  
when they are changed behind your back ? (in a library you use, for  
example)

...
> Declaring private/public fields looking redundant too: they should be
> always private.

Except when you do not want to disappoint the zillions of flies around  
you? (who, by "law of gravity", cannot err ...)

> Instead, accessors #foo, #foo: can be made public or private by the will.
> But if you make field public, then it's accessors became public as
> well? But what if i want #foo to be public, but #foo: to be private?

This is not a valid question for obtaining a Certified Javanese credit!  
You failed ! ;)

/Klaus

>

[Igor Stasenko]

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

> On Wed, 07 May 2008 10:22:46 +0200, Igor Stasenko wrote:
>
>
> > I read Gilad's blog and having some concepts which i think is
> > redundant and smell like javaisms.
> >
>
>  ;)
>
>
> > For instance, i don't share the view, that all fields in class
> > instance should be initialized and initialized once, by constructor
> > (instance factory method).
> > What about lazy initialization?
> >
>
>  Lazy in the sense of, a) initialize them with nil [in the constructor] then
> later b) assign them anything else? That's always possible, isn't it. I
> don't see much a problem here, except the *cause* of such language design
> decision.

So, instead of polluting code with initializers (__which is optional__)
as in Damien's note:

Person class>>name: aString birthdate: aDate
 ^ self new
        name: aString;
        birthdate: aDate;
        yourself

they proposing to pollute code with nil initializers everywhere
(__which is mandatory__)?
I don't see how latter is better than smalltalk.

>The latter is concerned with 1) modularity-ness of each and every
> constituent 2) non-staticness of each and every constituent and 3)
> mixin-able-ness of every class (aka behavior-bearing object). To highlight
> just one problem in this >= 3 dimension time-space, which AFAICT is not
> solved yet (or perhaps just not published yet) in Newspeak: its
> *constructor* selector (the symbol) is for sure a *static* symbol
> constituent, violating non-staticness desideratum ... that is to say, even
> in a very-highly modularized Newspeak system you have to know the
> constructor message name of the things you import/mixin so, what about when
> they are changed behind your back ? (in a library you use, for example)
>
>  ...

To me it looks like people see a fallen tree across the road here.
I don't see much problem with smalltalk's approach. Proper
initialization will be always a concern of developer. There is no way
how we can ease his task with language sugars/semantics, because there
always can be cases, which don't fit to developer's plan of how things
needed to be initialized. So, the less we constrain him here - the
better.
For instance: useful case - omit calling superclass initialization.

>
>
> > Declaring private/public fields looking redundant too: they should be
> > always private.
> >
>
>  Except when you do not want to disappoint the zillions of flies around you?
> (who, by "law of gravity", cannot err ...)
>

I don't see how message-driven design (which Newspeak claiming is)
should care about declaring state properties.
State in message-driven system is a behavioral component, not declarative one.

>
>
> > Instead, accessors #foo, #foo: can be made public or private by the will.
> > But if you make field public, then it's accessors became public as
> > well? But what if i want #foo to be public, but #foo: to be private?
> >
>
>  This is not a valid question for obtaining a Certified Javanese credit! You
> failed ! ;)
>

I don't need Certified Javanese credit :)

>  /Klaus
>


--
Best regards,
Igor Stasenko AKA sig.

[Klaus D. Witzel]

On Wed, 07 May 2008 15:48:56 +0200, Igor Stasenko wrote:

> 2008/5/7 Klaus D. Witzel :
>> On Wed, 07 May 2008 10:22:46 +0200, Igor Stasenko wrote:
>>
>> > I read Gilad's blog and having some concepts which i think is
>> > redundant and smell like javaisms.
>> >
>>
>>  ;)
>>
>> > For instance, i don't share the view, that all fields in class
>> > instance should be initialized and initialized once, by constructor
>> > (instance factory method).
>> > What about lazy initialization?
>> >
>>
>>  Lazy in the sense of, a) initialize them with nil [in the constructor]  
>> then
>> later b) assign them anything else? That's always possible, isn't it. I
>> don't see much a problem here, except the *cause* of such language  
>> design decision.
>
> So, instead of polluting code with initializers (__which is optional__)
> as in Damien's note:
>
> Person class>>name: aString birthdate: aDate
>  ^ self new
>         name: aString;
>         birthdate: aDate;
>         yourself
>
> they proposing to pollute code with nil initializers everywhere
> (__which is mandatory__)?
> I don't see how latter is better than smalltalk.

Didn't mean better/worther; mentioned nil initializing only because this  
can be done in *every* programming language which deserves the *language*  
attribute ;-) thereby ignoring the language designer's good wishes ;)

>
>> The latter is concerned with 1) modularity-ness of each and every
>> constituent 2) non-staticness of each and every constituent and 3)
>> mixin-able-ness of every class (aka behavior-bearing object). To  
>> highlight
>> just one problem in this >= 3 dimension time-space, which AFAICT is not
>> solved yet (or perhaps just not published yet) in Newspeak: its
>> *constructor* selector (the symbol) is for sure a *static* symbol
>> constituent, violating non-staticness desideratum ... that is to say,  
>> even
>> in a very-highly modularized Newspeak system you have to know the
>> constructor message name of the things you import/mixin so, what about  
>> when
>> they are changed behind your back ? (in a library you use, for example)
>>
>>  ...
>
> To me it looks like people see a fallen tree across the road here.

Hhm. what's that mean.

> I don't see much problem with smalltalk's approach. Proper
> initialization will be always a concern of developer. There is no way
> how we can ease his task with language sugars/semantics, because there
> always can be cases, which don't fit to developer's plan of how things
> needed to be initialized. So, the less we constrain him here - the
> better.

Unless a language designer puts inheritance into the developer's hands and  
promises that the language then still provides  
modularity+messaging+you_name_it (unlike Squeak/Smalltalk which doesn't  
implement anything related to modularity nor slots).

I think that Newspeak language design is one approach, Squeak/Smalltalk  
implementation is another.

> For instance: useful case - omit calling superclass initialization.

Not possible in Newspeak, since by *naming* the superclass (at the  
"declarative" time of subclassing) in Newspeak one *must* also name  
super's constructor (the *static* symbol that I reflected upon in the  
above and again in the next sentence), or else accept the default one  
(#new); similiar to how it is in Javanese ;)

FWIW, the superclass' slot name can be anything (message based, of course)  
but, the constructor's message selector is the *static* thing that user of  
a module has to know about ...

>
>>
>> > Declaring private/public fields looking redundant too: they should be
>> > always private.
>> >
>>
>>  Except when you do not want to disappoint the zillions of flies around  
>> you?
>> (who, by "law of gravity", cannot err ...)
>>
>
> I don't see how message-driven design (which Newspeak claiming is)
> should care about declaring state properties.
> State in message-driven system is a behavioral component, not  
> declarative one.

Didn't understand a word :( what has *state* to do with a scope-bound  
privilege? Can you reformulate using a) global visibility of a slot v.s.  
b) ... v.s. c) ... v.s. x) local visibility of a slot. TIA.

>
>>
>> > Instead, accessors #foo, #foo: can be made public or private by the  
>> will.
>> > But if you make field public, then it's accessors became public as
>> > well? But what if i want #foo to be public, but #foo: to be private?
>> >
>>
>>  This is not a valid question for obtaining a Certified Javanese  
>> credit! You
>> failed ! ;)
>>
>
> I don't need Certified Javanese credit :)

Congratulations ;)

>
>>  /Klaus
>

[Igor Stasenko]

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

> On Wed, 07 May 2008 15:48:56 +0200, Igor Stasenko wrote:
>
> > >
> > >  ...
> > >
> >
> > To me it looks like people see a fallen tree across the road here.
> >
>
>  Hhm. what's that mean.
>
>

Means that people keep staring at it or starting building new road
instead of just jumping over and continue moving :)

>
> > I don't see much problem with smalltalk's approach. Proper
> > initialization will be always a concern of developer. There is no way
> > how we can ease his task with language sugars/semantics, because there
> > always can be cases, which don't fit to developer's plan of how things
> > needed to be initialized. So, the less we constrain him here - the
> > better.
> >
>
>  Unless a language designer puts inheritance into the developer's hands and
> promises that the language then still provides
> modularity+messaging+you_name_it (unlike Squeak/Smalltalk which doesn't
> implement anything related to modularity nor slots).
>

_Implement_ - exactly!. A modularity is related to implementation not
to language syntax - right?
I think smalltalk can be made modular very easily, by reviewing role
of globals and classes/metaclasses.
But smalltalk syntax don't need to be changed to support modularity.

>  I think that Newspeak language design is one approach, Squeak/Smalltalk
> implementation is another.
>
>
>
> > For instance: useful case - omit calling superclass initialization.
> >
>
>  Not possible in Newspeak, since by *naming* the superclass (at the
> "declarative" time of subclassing) in Newspeak one *must* also name super's
> constructor (the *static* symbol that I reflected upon in the above and
> again in the next sentence), or else accept the default one (#new); similiar
> to how it is in Javanese ;)
>

And similar to C++. But it is really needed time to time to have
different order of initialization, or do partial initialization.
Its not a point of good/bad design , its a point of simply allowing or
disallowing that.


>  FWIW, the superclass' slot name can be anything (message based, of course)
> but, the constructor's message selector is the *static* thing that user of a
> module has to know about ...
>

Hmm, can classes have multiple constructors? Or just #new if not
defined by developer and #myUberConstructor if defined?

> >
> > I don't see how message-driven design (which Newspeak claiming is)
> > should care about declaring state properties.
> > State in message-driven system is a behavioral component, not declarative
> one.
> >
>
>  Didn't understand a word :( what has *state* to do with a scope-bound
> privilege? Can you reformulate using a) global visibility of a slot v.s. b)
> ... v.s. c) ... v.s. x) local visibility of a slot. TIA.
>

Writing 'v.s' in java and other rudimentary languages tells compiler
to find a field with name 's' and check scope/visibility rules.

In message-based system, if i write 'object s' , error is possible
only at runtime, since compiler knows nothing about object: does it
having #s message? and what it does? does it private or public? Makes
no sense at all.

So, in message-based system you really can tell compiler to check the
caller context of message, and if caller context is wrong - generate
exception. And this is nothing to do with slots, its only applicable
to methods, because only messages we have, and messages computed by
methods.
Unless you put slot == method.


--
Best regards,
Igor Stasenko AKA sig.

[Klaus D. Witzel]

On Wed, 07 May 2008 18:21:19 +0200, Igor Stasenko wrote:

> 2008/5/7 Klaus D. Witzel <klaus.witzel@...>:
>> On Wed, 07 May 2008 15:48:56 +0200, Igor Stasenko wrote:
>>
>> > >
>> > >  ...
>> > >
>> >
>> > To me it looks like people see a fallen tree across the road here.
>> >
>>
>>  Hhm. what's that mean.
>>
> Means that people keep staring at it or starting building new road
> instead of just jumping over and continue moving :)

Heh! :)

>
>>
>> > I don't see much problem with smalltalk's approach. Proper
>> > initialization will be always a concern of developer. There is no way
>> > how we can ease his task with language sugars/semantics, because there
>> > always can be cases, which don't fit to developer's plan of how things
>> > needed to be initialized. So, the less we constrain him here - the
>> > better.
>> >
>>
>>  Unless a language designer puts inheritance into the developer's hands  
>> and
>> promises that the language then still provides
>> modularity+messaging+you_name_it (unlike Squeak/Smalltalk which doesn't
>> implement anything related to modularity nor slots).
>>
>
> _Implement_ - exactly!.

I'm glad you've recognized that subtle difference :)

> A modularity is related to implementation not
> to language syntax - right?

Right. And Smalltalk didn't suggest one (except that they introduced  
categories which where unkown by programmers of that time).

> I think smalltalk can be made modular very easily, by reviewing role
> of globals and classes/metaclasses.

Yes, I think so too. But we've also seen the (almost) neverending debates  
on how to do that here on squeak-dev :(

> But smalltalk syntax don't need to be changed to support modularity.

Except when you also want to address what the zillion of flies have now?  
And show them a better (read: message-based) way to do it (do it in a  
dogmatic way, the flies seem to *love* dogmata).

>>  I think that Newspeak language design is one approach, Squeak/Smalltalk
>> implementation is another.
>>
>> > For instance: useful case - omit calling superclass initialization.
>> >
>>
>>  Not possible in Newspeak, since by *naming* the superclass (at the
>> "declarative" time of subclassing) in Newspeak one *must* also name  
>> super's
>> constructor (the *static* symbol that I reflected upon in the above and
>> again in the next sentence), or else accept the default one (#new);  
>> similiar to how it is in Javanese ;)
>>
>
> And similar to C++.

Right.

> But it is really needed time to time to have
> different order of initialization, or do partial initialization.
> Its not a point of good/bad design , its a point of simply allowing or
> disallowing that.

Nothing against that but, do you have examples for the Newspeak team?

>
>>  FWIW, the superclass' slot name can be anything (message based, of  
>> course)
>> but, the constructor's message selector is the *static* thing that user  
>> of a
>> module has to know about ...
>>
>
> Hmm, can classes have multiple constructors? Or just #new if not
> defined by developer and #myUberConstructor if defined?

This is another area of Newspeak for which I have (as yet?) not much  
background info. AFAICT they don't want class variables nor class methods,  
that's for sure. So all that remains (all that their syntax can be used  
for in that branch of the language) is, to declare alternate  
constructor(s) that's for sure.

>
>> >
>> > I don't see how message-driven design (which Newspeak claiming is)
>> > should care about declaring state properties.

You've cut away your subject of your state properties: private/public  
modifiers.

>> > State in message-driven system is a behavioral component, not >  
>> declarative one.
>> >
>>
>>  Didn't understand a word :( what has *state* to do with a scope-bound
>> privilege? Can you reformulate using a) global visibility of a slot  
>> v.s. b)
>> ... v.s. c) ... v.s. x) local visibility of a slot. TIA.
>>
>
> Writing 'v.s' in java and other rudimentary languages

You lost me a 2nd time, this time on 'v.s.'; my use of that phrase was as  
abbreviation for 'versus'.

Let me try it again: I didn't see what your *state* has to do with  
Newspeak scope/visibility modifiers (private/public). Perhaps you meant  
*slots*.

[Vassili Bykov-2]

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