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