5 ms·

People who "hate on JavaScript" tend to know the language very well. They also know at least several other languages very well. This knowledge makes JavaScript'

People who "hate on JavaScript" tend to know the language very well. They also know at least several other languages very well. This knowledge makes JavaScript's many flaws much more obvious, and much less justifiable. The basic fact is that prototype-based OO, for example, is much less practical than class-based OO. Experienced developers comprehend JavaScript's attempt at it just fine. This understanding doesn't change its inferiority, however. This is exactly why so many developers need to compensate for JavaScript's lack of desired functionality in this area by trying to fake class-based OO using the limited functionality that JavaScript does offer. The same goes for many other aspects of JavaScript. Bad tools are still bad, even in the hands of experts. I'm not really sure what you're talking about when you mention "evolving standards". If anything, JavaScript's standards haven't evolved well at all. Harmony is only now proposing the addition of core functionality that has been present in other languages for decades now, and should have been in JavaScript from the very beginning, too. JavaScript is merely "evolving" to where it should have been many years ago.

catnaroek 13y ago
To be honest, I am not so convinced about classes as units of program organization either. Classes conflate in a single mechanism several concepts: 1. Types (classes) 2. Encapsulation (private, protected) 3. Polymorphism (virtuals) 4. Code reuse (inheritance) While it is much better than prototypal inheritance, it is still less than ideal. On the other hand, there are languages like Haskell and ML which compartmentalize better these concepts: 1. Types: algebraic data types and type synonyms 2. Encapsulation: modules 3. Polymorphism: type constructors (parametric), type classes (ad-hoc, Haskell only) 4. Code reuse: derived type classes (Haskell only), functors (ML only) The result of providing these features independently from one another is a net increase in flexibility. You can have, say, a module that exports two or more types, and a single function inside that module that can manipulate the internals of both types. === Edit: And Rust gets this right as well, of course! 1. Types: structs and enums 2. Encapsulation: modules and crates 3. Polymorphism: generics (parametric) and traits (ad-hoc) 4. Code reuse: trait inheritance and trait instances for generic types
nbouscal 13y ago
I'm extremely confused by this post. You claim to know JavaScript very well, which is fine, but then you go on to say that developers "fake class-based OO using the limited functionality that JavaScript does offer." That doesn't square with the fact that prototypal OO is strictly more expressive than class-based OO. You can implement class-based OO in a prototypal OO language. You cannot do the converse. A lot of people who know JavaScript and several other languages very well don't hate on JavaScript. JavaScript has more than it's share of warts, obviously. We all know the story: it was written in a week, etc. It also has more than it's share of good parts, though, and if used correctly it is a very expressive language. In my experience, the haters are more frequently people who don't know the language as well. Clearly our experiences differ. I find it hard to believe, though, that anyone experienced in both languages would claim that JavaScript was worse than PHP, and PHP is still the most common back-end web language.
- catnaroek 13y ago
  > That doesn't square with the fact that prototypal OO is strictly more expressive than class-based OO. You can implement class-based OO in a prototypal OO language. You cannot do the converse. Actually, you can implement prototypal OO in a class-based language. First of all, you need a single class with two members variables and a member function. The member variables are a pointer or reference to a base object, and a hashmap from strings (member names) to objects (member values). In C++, this would be a std::unordered_map<std::string, boost::any>. The member function is an overload of the subscript operator (operator []) that takes a string argument and checks whether the hashmap contains the string as a key. If string is indeed a key, then its associated value is returned. Otherwise, the same subscript operator is evaluated for the base object and the same string. If there is no base object, then either an exception is thrown or a special undefined value is returned. The feasibility of doing this is no big surprise. After all, dynamically typed languages are a very, very restricted subset of statically typed languages: http://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/ http://existentialtype.wordpress.com/2011/03/19/dynamic-lang... . The main reason why users of class-based languages do not do this is that this breaks type safety for very little gain. Actually, the supposed encoding of class-based OO in a prototypal language is not correct from an operational semantics point of view. In a statically typed OO language, methods and member variables must be known to exist, so they are directly used. The prototypal "encoding" fundamentally relies on testing at runtime whether methods or member variables exist, because it uses the mechanism described two paragraphs above. So it actually does something different than what statically typed class-based OO languages do. > It also has more than it's share of good parts, though, and if used correctly it is a very expressive language. For me, an expressive language is not a language that lets me encode hacks (after all, even C can do that), but a language that lets me encode mechanically checkable assurances that my code will work in specific ways. This allows other programmers to reuse my code with full confidence that it will work in the way they expect it to.

catnaroek 13y ago

To be honest, I am not so convinced about classes as units of program organization either. Classes conflate in a single mechanism several concepts: 1. Types (classes) 2. Encapsulation (private, protected) 3. Polymorphism (virtuals) 4. Code reuse (inheritance) While it is much better than prototypal inheritance, it is still less than ideal. On the other hand, there are languages like Haskell and ML which compartmentalize better these concepts: 1. Types: algebraic data types and type synonyms 2. Encapsulation: modules 3. Polymorphism: type constructors (parametric), type classes (ad-hoc, Haskell only) 4. Code reuse: derived type classes (Haskell only), functors (ML only) The result of providing these features independently from one another is a net increase in flexibility. You can have, say, a module that exports two or more types, and a single function inside that module that can manipulate the internals of both types. === Edit: And Rust gets this right as well, of course! 1. Types: structs and enums 2. Encapsulation: modules and crates 3. Polymorphism: generics (parametric) and traits (ad-hoc) 4. Code reuse: trait inheritance and trait instances for generic types

nbouscal 13y ago

I'm extremely confused by this post. You claim to know JavaScript very well, which is fine, but then you go on to say that developers "fake class-based OO using the limited functionality that JavaScript does offer." That doesn't square with the fact that prototypal OO is strictly more expressive than class-based OO. You can implement class-based OO in a prototypal OO language. You cannot do the converse. A lot of people who know JavaScript and several other languages very well don't hate on JavaScript. JavaScript has more than it's share of warts, obviously. We all know the story: it was written in a week, etc. It also has more than it's share of good parts, though, and if used correctly it is a very expressive language. In my experience, the haters are more frequently people who don't know the language as well. Clearly our experiences differ. I find it hard to believe, though, that anyone experienced in both languages would claim that JavaScript was worse than PHP, and PHP is still the most common back-end web language.

catnaroek 13y ago
> That doesn't square with the fact that prototypal OO is strictly more expressive than class-based OO. You can implement class-based OO in a prototypal OO language. You cannot do the converse. Actually, you can implement prototypal OO in a class-based language. First of all, you need a single class with two members variables and a member function. The member variables are a pointer or reference to a base object, and a hashmap from strings (member names) to objects (member values). In C++, this would be a std::unordered_map<std::string, boost::any>. The member function is an overload of the subscript operator (operator []) that takes a string argument and checks whether the hashmap contains the string as a key. If string is indeed a key, then its associated value is returned. Otherwise, the same subscript operator is evaluated for the base object and the same string. If there is no base object, then either an exception is thrown or a special undefined value is returned. The feasibility of doing this is no big surprise. After all, dynamically typed languages are a very, very restricted subset of statically typed languages: http://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/ http://existentialtype.wordpress.com/2011/03/19/dynamic-lang... . The main reason why users of class-based languages do not do this is that this breaks type safety for very little gain. Actually, the supposed encoding of class-based OO in a prototypal language is not correct from an operational semantics point of view. In a statically typed OO language, methods and member variables must be known to exist, so they are directly used. The prototypal "encoding" fundamentally relies on testing at runtime whether methods or member variables exist, because it uses the mechanism described two paragraphs above. So it actually does something different than what statically typed class-based OO languages do. > It also has more than it's share of good parts, though, and if used correctly it is a very expressive language. For me, an expressive language is not a language that lets me encode hacks (after all, even C can do that), but a language that lets me encode mechanically checkable assurances that my code will work in specific ways. This allows other programmers to reuse my code with full confidence that it will work in the way they expect it to.