3 ms·

A counterpoint: I've programmed JavaScript long enough and on large enough codebases to know that JavaScript leaves much be desired. Problems: 1) It's a la

A counterpoint: I've programmed JavaScript long enough and on large enough codebases to know that JavaScript leaves much be desired. Problems: 1) It's a language that has stood still since November 2000 as far as standards go. 2) No sane package system (see #1) *everybody invents their own* 3) Expression problem, altering prototypes is ridiculously powerful, but it's monkey-patching (see #1) 4) Browser environment is a ball-and-chain for the language's evolution (see #1) 5) Lack of rich datatypes (no sets) (see #1) 6) Object identity based equality (see #1) 7) Little facility to define new rich datatypes (see #1) And on and on. The reasons JavaScript isn't totally crippled given these and more issues is that the language is wonderfully small, has first class functions, functions have variable arity, supports apply/call, its functions are modifiable objects, the context of a function call can be rebound, and it has prototypal inheritance. From these powerful bits people have created a many, many libraries that make JavaScript programming downright fun. But to say that JavaScript is an especially capable PL is, to me at least, a bit of joke- it was clearly designed to run in a very limited scope, in the browser. And remember, this is critique from someone that has used JavaScript in large UI projects day in and day out since 2005 (before jQuery!).

Raphael_Amiard 16y ago
I mostly agree with your critique of javascript. I do not actually agree with 7. You do have the possibility of defining any datatypes you'd ever need. You just don't have the possibility of defining literal support for them. All your other points are right on, but i feel that most are more the result of the history and constraints of javascript than anything else. #3 is a language problem but is also the most arguable of your points. Ruby allows monkey patches and is one of the most appreciated languages in existence today. Also viable approachs to give the power of monkey patching without the drawbacks are just being thought today. Protocols in clojure looks good but still need the appreciation of time i'd say. #6 is stupid i agree Every other point are more the result of the history, and most importantly of the use case of javascript: - No sane package system sucks but a package system is hard to get right in a file based browser environnement. - Browser environnement, well yes, but that's precisely what we are talking about, you can't really say it's a problem, it's the very reason we're using javascript in the first place - Lack of rich datatypes is really bad. The lack of sets, but also of propers hash maps sucks. But more generally javascript lacks a proper standard library. Something that python definitely has. But it's also definitely harder to get right in a browser environnement, when you have got to ensure support from every browser on every platform. But anyway, thanks for a proper critique of javascript.
- pjscott 16y ago
  The lack of sets as a data type at the language level is a serious problem with JS. Most languages which implement sets as a library make some assumption about the elements: they're ordered, for example, or they all have a unique string serialization. If you want to make a set data type in JavaScript, the language doesn't give you any of those assumptions. You might end up just using linear search of unordered arrays. (This is actually very fast for small sets, but still.) I wrote some more about this here: http://finger-tree.blogspot.com/2010/09/sets-in-javascript.html http://finger-tree.blogspot.com/2010/09/sets-in-javascript.h... And here is a library that offers sets in JS: http://github.com/PeterScott/simplesets-nodejs http://github.com/PeterScott/simplesets-nodejs If you're using Node.js, you can get it with npm. It could be adapted to the browser pretty easily. This is what I use, and it makes my life so much easier.
- loewenskind 16y ago
  >Also viable approachs to give the power of monkey patching without the drawbacks are just being thought today. No, they're actively being used: http://msdn.microsoft.com/en-us/library/bb383977.aspx http://msdn.microsoft.com/en-us/library/bb383977.aspx
othermaciej 16y ago
> 1) It's a language that has stood still since November 2000 as far as standards go. That used to be true, but ECMA-262 5th edition was just published in December, 2009: http://www.ecma-international.org/publications/standards/Ecma-262.htm http://www.ecma-international.org/publications/standards/Ecm... And the next version is under active develpment; it will likely address many of your other points.

Raphael_Amiard 16y ago

I mostly agree with your critique of javascript. I do not actually agree with 7. You do have the possibility of defining any datatypes you'd ever need. You just don't have the possibility of defining literal support for them. All your other points are right on, but i feel that most are more the result of the history and constraints of javascript than anything else. #3 is a language problem but is also the most arguable of your points. Ruby allows monkey patches and is one of the most appreciated languages in existence today. Also viable approachs to give the power of monkey patching without the drawbacks are just being thought today. Protocols in clojure looks good but still need the appreciation of time i'd say. #6 is stupid i agree Every other point are more the result of the history, and most importantly of the use case of javascript: - No sane package system sucks but a package system is hard to get right in a file based browser environnement. - Browser environnement, well yes, but that's precisely what we are talking about, you can't really say it's a problem, it's the very reason we're using javascript in the first place - Lack of rich datatypes is really bad. The lack of sets, but also of propers hash maps sucks. But more generally javascript lacks a proper standard library. Something that python definitely has. But it's also definitely harder to get right in a browser environnement, when you have got to ensure support from every browser on every platform. But anyway, thanks for a proper critique of javascript.

pjscott 16y ago
The lack of sets as a data type at the language level is a serious problem with JS. Most languages which implement sets as a library make some assumption about the elements: they're ordered, for example, or they all have a unique string serialization. If you want to make a set data type in JavaScript, the language doesn't give you any of those assumptions. You might end up just using linear search of unordered arrays. (This is actually very fast for small sets, but still.) I wrote some more about this here: http://finger-tree.blogspot.com/2010/09/sets-in-javascript.html http://finger-tree.blogspot.com/2010/09/sets-in-javascript.h... And here is a library that offers sets in JS: http://github.com/PeterScott/simplesets-nodejs http://github.com/PeterScott/simplesets-nodejs If you're using Node.js, you can get it with npm. It could be adapted to the browser pretty easily. This is what I use, and it makes my life so much easier.
loewenskind 16y ago
>Also viable approachs to give the power of monkey patching without the drawbacks are just being thought today. No, they're actively being used: http://msdn.microsoft.com/en-us/library/bb383977.aspx http://msdn.microsoft.com/en-us/library/bb383977.aspx

othermaciej 16y ago

> 1) It's a language that has stood still since November 2000 as far as standards go. That used to be true, but ECMA-262 5th edition was just published in December, 2009: http://www.ecma-international.org/publications/standards/Ecma-262.htm http://www.ecma-international.org/publications/standards/Ecm... And the next version is under active develpment; it will likely address many of your other points.