[squeak-dev] talk on Newspeak online

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

On Sun, Apr 20, 2008 at 6:42 AM, Damien Pollet <[hidden email]> wrote:
That is correct.

--Vassili

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

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.

Hi Danil,

On Wed, May 7, 2008 at 11:26 AM, danil osipchuk
<[hidden email]> 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

On Wed, May 7, 2008 at 10:22 AM, Igor Stasenko <[hidden email]> wrote:
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)

Hi Danil,

sorry, I misunderstood you there. :-)

Best,

Michael

On Wed, May 7, 2008 at 11:39 AM, danil osipchuk
<[hidden email]> wrote:

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

Nikolay

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

>

2008/5/7 Klaus D. Witzel <[hidden email]>:
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.

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.

I don't need Certified Javanese credit :)

>  /Klaus
>


--
Best regards,
Igor Stasenko AKA sig.

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

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

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

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.

Congratulations ;)

>
>>  /Klaus
>

2008/5/7 Klaus D. Witzel <[hidden email]>: Means that people keep staring at it or starting building new road
instead of just jumping over and continue moving :)

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

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?

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.

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

Heh! :)

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

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?

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.

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

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

2008/5/8 Vassili Bykov <[hidden email]>:
> 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).
>

Mandatory field initialization is good!
But this is not true in C++ : initialization of fields with intrinsic
types are optional, which always a source of errors and ruining the
whole
concept.

class X {
   int x;
   int y;
  X(int _x) x(_x) {};    // y left uninitialized, compiler don't
cares, users cry in pain
}

All in hands of initial developer. If he wants to make life easy for
users - he's not putting dozens of instance creation methods at class
side,
or does this in a manner, which is easy to understand. This problem
lies in social plane (good documentation, good design e.t.c.), rather
than purely language related.


.. or introduce pain because of inability to make things in a way how
developer sees it.


>  Regarding "static constructor messages", I fail to see the problem. 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.
>

About constructors.

It is really easy to maintain same discipline in smalltalk.
Maybe its hackish, but its possible to implement w/o changing syntax:

MyStrictClass>>new
   self checkConstructor.
    ^ super new

MyStrictClass>>checkConstructor
   | sender |
   [ sender := thisContext sender. sender sender receiver == self ] whileTrue.
    self assert: (self validConstructors includes: sender method selector )

MyStrictClass>>validConstructors
   ^ ( #new )

MyStrictSubClass>>x: aX y:aY
   ^ super new x: aY; y: aY; yourself.

MyStrictSubClass>>validConstructors
   ^ ( #x:y: )

MyStrictSubClass2>>validConstructors
   ^ ( #x:y: #new )  "allow constructors from superclass and from
superclass superclass"


>  Cheers,
>
>  --Vassili
>
>



--
Best regards,
Igor Stasenko AKA sig.

On Thu, 08 May 2008 04:56:11 +0200, Igor Stasenko wrote:

> 2008/5/8 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.

[...big snip...]

> About constructors.
>
> It is really easy to maintain same discipline in smalltalk.
> Maybe its hackish, but its possible to implement w/o changing syntax:

Heh! you seem to have the inlining compiler in mind when you give examples  
like the one below ;)

Anyways, hands up please: who's willing to be conformant, in her/his  
projects, to lengthy instance creation cobb salad (californian) like this?

2008/5/8 Klaus D. Witzel <[hidden email]>:
The one, who want it to be strict. :)

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



--
Best regards,
Igor Stasenko AKA sig.