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