Hacker News Reader

Comment by masklinn | Hacker News Reader

I'm not sure that's a good idea, because then they'd be made very sad by constructors, by prototypes being something completely different[0], by not having mixins[1], by single-inheritance, by dynamic inheritance[2], by the lack of blocks (and non-local returns), etc…

Essentially, by javascript not being a very good Self.

[0] IIRC in Self the prototype is the object you copy, objects linked through parent slots are either mixins or traits.

[1] although it doesn't have a lobby, which makes the difference between traits and mixins, js's prototypes are probably closer to self's traits.

[2] that's being added in ES6, yay. But still single, boo.

View on HN

I think that the claims that "JavaScript is like Self" or that "JavaScript is like Scheme" are attempts to legitimize what really isn't a very good language to being with. I think that this is also done out of ignorance, to a large extent. People hear about Scheme and Self being held in high regard, hear about some very vague similarities with JavaScript, and then assume that JavaScript is somehow like Scheme and Self, even if they've never used Scheme or Self. The supposed similarities only extend to JavaScript supporting anonymous functions and closures (just like numerous other languages) in the case of Scheme, or merely just sharing some terminology with Self. So there isn't any real basis to these claims.

I think that the claims that "JavaScript is like Self" or that "JavaScript is like Scheme" are attempts to legitimize what really isn't a very good language to being with.

I think it can be helpful to say that JavaScript is "like" Scheme if the purpose is to think harder about JavaScript and some of the consequences enabled by its features. On the other hand, I don't think JavaScript really is a Lisp, and it's a terrible idea to say so for the purpose of justifying all of its design choices.

http://raganwald.com/2013/07/19/javascript-is-a-lisp.html

I am aware of that.

On my case, the remark I made had more to do with the fact that many developers tend to be unaware that these concepts also exist in other languages and could learn a bit by seeing them on the languages they originated from.

Even when JavaScript only took tiny details from them.

MI still sends shivers down my spine, having spent time in the C++. Just say no.

So C++ got multiple inheritance wrong... That doesn't mean it must be rejected in all cases.

What are the cases where MI is better than mix-ins or component architectures?

Maybe just in some corner cases.

However Eiffel, OCaml and Python MI implementations seem to be implemented in a more sane way.

NewtonScript had a neat concept of heterogeneous multiple inheritance: Its "objects" had a prototype-like inheritance chain and a container inheritance chain.

If client-side JavaScript had this design, there would be no need for the DOM to have a special event mechanism that lives outside of method handling: DOM elements would simply have method handlers and the dispatch system would handle prototype and container inheritance.

> NewtonScript had a neat concept of heterogeneous multiple inheritance: Its "objects" had a prototype-like inheritance chain and a container inheritance chain.