[bryanlarsen]

You're right about some of the warts of javascript. John specifically discusses these in a different blog post. http://ejohn.org/blog/javascript-as-a-first-language/

Some of these warts are surprisingly easy to work around: for instance, they always use "===" and don't even tell the student about "==" until much later.

In other cases I just think you're wrong. For instance, I think that the prototype system is simpler and easier to understand than classical objects, while at the same time being more powerful.

[joeroot]

Thanks for the blog post, I hadn't seen that before. As I said before, these things are subjective. In my opinion, the prototype model is too far removed from the classical object model to ever teach effectively with it. Primarily, my dislike of it within a classroom comes from the fact that it demolishes any chance of real typing. I think this is a serious issue when teaching children, both from a pure CS stand point and from an engineering principles stand point. It may make life easier for some programmers, its quick and light, but for teaching I think its inappropriate. I don't believe that in using it, the student gains no real insight into either CS or engineering. That being said, I'm no prototyping expert, so any counter argument would be informative!

[ehsanu1]

A prototypal language can easily simulate classical OOP. The converse is not true. Take a look at how CoffeeScript implements classes. There are also a plethora of libraries that provide various class/inheritance models, with whatever taste of complexity you'd like.

You also want "real typing". Do you mean strong typing or static typing? In either case, the language will fight you all the way, being intrinsically weekly/dynamically typed, and so it is somewhat orthogonal to prototypes vs classical OOP.

IMO, if you want to teach type theory, you ought to be doing it in a language like Haskell anyways. Which might not the best thing to expose an absolute beginner to. ;)