> The prototype object model is half-baked in JavaScript.

Exactly. Not just half-baked but half-assed too, the entire concept of constructors doesn't belong for starters.

Javascript's prototypal system was never a philosophy, it was just a way to quickly get an object system up and running (which is why delegation has to be hand-rolled, delegating ctors stinks, and most of the native objects can't be derived from at all), essentially a terrible implementation detail people had to deal with out of necessity.

> With the lack of a clone operation, in order to define new objects types you had to go through hacky stuff, like explicitly setting up .prototype properties.

As you link to io, JS IO's clone way back (in ES5 I think?) in Object.create. I don't think it's very good, though I think IO's clone is even worse as it really do what you'd intuit in reading the word (I think JS's naming is less confusing, though hardly great).

In Self, the "clone" operation would simply do a shallow copy (unless you'd overridden it). So you'd have an object, "clone" it, and you'd get a copy of that with the same slots set to the same value.

A prototype then would simply be an existing "reference" instance you'd copy, and you'd get the same parent slots, meaning you'd get the same parents (what Javascript and Io mis-call prototypes).

Valid critique in legacy sense, the class syntax of course mitigates much of it. But why would you want to delegate constructors?

> But why would you want to delegate constructors?

Because if you inherit from something you probably want to run the super object's constructor so that yours is fully initialised?

Ah, so you mean calling the superclass constructor. To me, the wording ”delegate a constructor” means ”to entirely shift responsibility for constructing an instance to something that isn’t the actual constructor”, which made me think of something else than the normal way extending constructors work.