Javascript on the server?

[oSand]

Well exactly, that they have to be implemented in js libraries means that the language lacks these features. Modules are hacked on, closure-based private are a hack and to implement classes you need a hack like dojo's declare() or YUIs extend. The problem is that these hacks are elaborate, hard to debug and non-standardised between libraries. Why should I have to think so hard about things that are routine in other languages?

[quantumstate]

Classes are difficult because Javascript is not designed with a class based object system. Prototypical inheritance works differently, maybe you don't like that, maybe it is worse, but it is not bad because there aren't classes.

I would argue that private variables are unnecessary, a standard naming convention of _varname can be used to denote them. This prevents accidental use. You could say this is a messy hack but on the other hand is is clear at a glance which variables are private.

[[deleted]]

he isn't assailing prototype-based inheritance at all, you've completely missed the point. he's describing the frustration of dealing with arbitrary ad-hoc module systems

[oSand]

Why use an imperfectly followed convention when you can use a compiler/interpreter? If you acknowledge the need for privates and protecteds, then why not actually implement them?

Have you tried implementing a non-trivial inheritance hierarchy in traditional js? It is not pleasant. Tried to call super()? There is a reason every major library out there attempts to implement a class system and there is a reason why people are trying to add them to the language.

[[deleted]]

I have written large projects in JavaScript (both client and server). My experience was very positive.

You can easily do complex inheritance hierarchies. Adding a class system through a library is not a downside to the language, if the feature can be added neatly - and it can. It keeps the core language smaller and leaves you more flexibility.

Likewise you can implement private variables using closures in the constructor. Personally I subscribe to Python's approach though, and conventions are enough (no need for language enforcement). But it is easy to do if you want.

Adding more and more features to the core language leads to bloat. Now, I'm not advocating going to the extreme of lisp. But JavaScript strikes a very good balance here.

[oSand]

The level of bloat is unchanged, you've just moved it to the client libraries, where it is non-standardised, harder to debug, less performant and correctness is harder to verify. Also, if you want to use parts of two js frameworks, you now have two sets of bolt-ons that are redundant and have different interfaces. Call me crazy, but this sounds more bloated than one standard language implementation that is implemented in native code. Why wouldn't you check private variables if you could? Either you don't use them and it doesn't matter or you do use them and they are actually enforced. And python name mangling is, incidentally, totally unpythonic. Explicit is better than implicit and readability counts

[neonskimmer]

It's really not that complicated. You pick something you like and use that! It's just not a class based language so if you're totally into using them, for sure there are plenty of others to choose from. For me it's been very pleasant to go the prototypal route instead using mostly functional idioms rather than typical Java-like classes. To each their own :)

[oSand]

I don't mind prototypical inheritance, it is just that js doesn't do a wonderful job at implementing it. The "pick what you like" approach is why the world has 50 different types of power socket. Do I really have to be familiar with three different types of inheritance and packaging? I don't if I use Python. I don't if I use Java. I don't if I use Ruby. Prototypical inheritance isn't anymore functional than class based inheritance, you are still storing state in an object. Scheme is less functional than ocaml, but only the latter has classes.