5 ms·

The biggest problem with JS for me is not its quirks, but the way that until you know--and I mean, really know--the language, you WILL make absolutely horrific

The biggest problem with JS for me is not its quirks, but the way that until you know--and I mean, really know--the language, you WILL make absolutely horrific errors, on every single level of development. It does not matter how good you are at writing C, Java, or Python. Oh, what, you thought == was for comparison? Wrong. Oh, you didn't wrap your all your code in an anonymous, self-calling function? You lose. Oh, what you thought it was okay to leave off semicolons and var statements because they aren't required? Sorry. Hmm, you didn't know how to manage dependencies between scripts? Should have studied harder. You tried to iterate over an array? Ridiculous. Your brain exploded when trying to write a series of asynchronous functions in continuation style? A pity, really. People who are good at JS like JS because it makes them special. They can lord their knowledge of the quirks over "lesser" developers who come to JS expecting it to act like a sane language. It took an entire industry about a decade just to learn how to tame it. Sure, JS turned out to be really extensible to new paradigms, but hey, so is the lambda calculus. A good language makes good programming look natural. Like Python. JS is the opposite.

chris_wot 14y ago
Define "natural". Firstly, == is indeed for comparison, just with an implicit cast beforehand. You don't need to wrap all your code in an anonymous self calling function, but to get the most out of it you need to - given the way it was designed, this makes sense. You speak like C syntax is "natural" - I remember grappling with pointers and references, it took some time for me to get it fully. It's not like Python doesn't have it's quirks. I find it ironic that those who use Python/Ruby/Clojure/etc want to often ridicule those who use JavaScript. They've got their own form of elitism. Get over it, seriously.
- deleted 14y ago
  [deleted]
- artmageddon 14y ago
  What the parent was saying regarding the == vs === is that unlike other languages it's very easy to get burned if you don't know the difference and when to properly use it. I'm hardly proficient at JS and not knowing that would've screwed me over.
  - chris_wot 14y ago
    Can you give me a concrete example?
    - mnarayan01 14y ago
      0 == false or even better "0" == false edit: I should note that I don't think JS is a horrible language or anything, but it does have more than its share of oddities.
      - chris_wot 14y ago
        I guess I'm still confused... Where abouts in your code will you be comparing a string or integer to a Boolean? Incidentally, there are quirks - the worst is with having to define a "that" variable, I guess I just don't see these JavaScript issues as all that terrible. Unlike PHP's type coersion system, Javascript's is quite sensible.
        lucian1900 14y ago
        The point is that comparisons between things of different types should be errors. Implicit coercion is never sensible.
        Turing_Machine 14y ago
        4 / 2.5 should be an error? Okay, then. Never mind that essentially no language in widespread use enforces that.
        lucian1900 14y ago
        That case is also potentially problematic, but perhaps better solved by having float division / and integer division // as separate operators. Perhaps my "never" was too strong.
        mnarayan01 14y ago
pretoriusB 14y ago
>Oh, what, you thought == was for comparison? Wrong. Actually true. And truer to the dynamic spirit of Javascript than ===. Sometimes things don't have to be absolutely equal to be equal, "1" and 1 will do just fine. You can sanitise at another level. >Oh, you didn't wrap your all your code in an anonymous, self-calling function? You lose. You loose nothing. You merely expose some names to the global namespace. Which might just be just one name, anyway, sans the anonymous self-calling function. (e.g window.ns = {}, ns.doSomething = function() ... >Oh, what you thought it was okay to leave off semicolons and var statements because they aren't required? Sorry. Sorry for nothing much. A lot of people leave them off with no problem at all. The few edge cases are not unlike any other language's edge cases. >Hmm, you didn't know how to manage dependencies between scripts? Should have studied harder. Or not. If you got the result you want. >You tried to iterate over an array? Ridiculous. You probably mean the "for i in" idiom. Which is perfectly fine over an array. The only problem arises if someone has extended the Array prototype, which you shouldn't do anyway. And even that can be bypassed with one extra hasOwnProperty check. Not to mention it's solved in ES6. >Your brain exploded when trying to write a series of asynchronous functions in continuation style? A pity, really. Well, that's just because Node async style is amateur hour BS, like trying to do closures in C or logic programming in PHP. Doable, but not supported by the language. Use Go or Dart or Haskell or C# or Scala or Tornado etc for your async needs.
- davedx 14y ago
  > Well, that's just because Node async style is amateur hour BS, like trying to do closures in C or logic programming in PHP. Doable, but not supported by the language. Use Go or Dart or Haskell or C# or Scala or Tornado etc for your async needs. If async programming in JavaScript "isn't supported by the language": what good is it, then?
  - pretoriusB 14y ago
    Who said Javascript is good for async programming? It was designed to be easy to use with callbacks for website UI style events (which is not quite the same as async programming). The Node async is just a half-thought implementation of async on top of a VM that doesn't really support it. The thing it has going for it is traction (and some people new to async are amused by the callback style and find it "challenging", whatever). Scala/Dart/Go/Rust/Haskell/etc have a better async story. ES6 will add some promising stuff in the future (no pun intended).
davedx 14y ago
The worst one for me with JavaScript lately is trying to build some form of object orientation into my code. There's no canonical way to even implement a constructor, for christ's sake. I haven't even dared to touch trying to use it for polymorphism. Or composition, for that matter. I'm staying the hell away from it for anything simpler than UI code. If JavaScript was a nicer language I would be spending more time in Node.JS, but it's not, so I'm sticking with Rails.
- chris_wot 14y ago
  You're forcing class based inheritance onto a language that specialises in prototypical inheritance... however, try http://tobyho.com/2010/11/22/javascript-constructors-and/ http://tobyho.com/2010/11/22/javascript-constructors-and/
- ufo 14y ago
  I actually don't mind this problem much, although that might be my "functional programming" bias. You only really need a "canonical" way to do things if you will be wanting to use features that depend on your classes being implemented in a predictable way. For example, class inheritance or implementing "super" method functionality. > I haven't even dared to touch trying to use it for polymorphism. Its not at hard as it sounds, since you have first class functions and closures. You can often handle functions directly instead of needing to create objects for everything.
pretoriusB 14y ago
>People who are good at JS like JS because it makes them special. They can lord their knowledge of the quirks over "lesser" developers who come to JS expecting it to act like a sane language. It took an entire industry about a decade just to learn how to tame it. Sure, JS turned out to be really extensible to new paradigms, but hey, so is the lambda calculus. All those points are moot. It's like pointing C's many flaws (or PHP's myriads). Or Ruby's. Or Javas. All languages have several syntactic or semantic issues. It didn't "took the industry a decade to learn Javascript". It took the industry a decade to have: 1) Mostly compatible implementation of JS and the DOM. 2) Powerful enough computers and JS VM so it can be used for fancy stuff. 3) A reason to use it (AJAX and involved web apps). Nothing of which has anything to do with Javascript's "difficulty" or "quirkiness" as a language.
d0m 14y ago
There are quirks in every languages - python obviously included. And please, don't forget that you're using a very old version of the Javascript language. It's a little bit like if I'm arguing about the errors and quirks of Python 1.5. Languages evolve and learn from their mistakes. Unfortunately, old browsers are stuck with old javascript versions. Some people have to write code in java 1.4 or python 1.5, they aren't People who are good at [python or java] like [python or java] because it makes them special. And that being said, most people coming from [name your favorite language] believe that Javascript works the same way as their language. It's a different language and require a different knowledge. In fact, javascript' similarity to algol might be one of the biggest problem of the language. Have you tried working with C++ without learning the language? And here are some Python cool "features": def foo(x=[]): x.append(2) print x foo() foo() Guess x? To take your term "You lose". print 3/2 What's the result? If you answered 1.5, sorry, you're wrong. We're using Python <2.2 here, and it gives 1. Here's another one, what does it do: for i in range(10): print "*", print Is it ""? Sorry, a comma at the end doesn't include a "\n" but automatically insert a space. Anyhow, have fun here: http://stackoverflow.com/questions/530530/python-2-x-gotchas-and-landmines http://stackoverflow.com/questions/530530/python-2-x-gotchas...
- w0utert 14y ago
  No language is perfect, but if those are the worst examples you can come up with for Python, there really is no comparison with the insane JavaScript WTF's I've seen. Default list/dictionary arguments are plain evil in Python, no disagreeing there. I've been bitten by something like the following before, which is similar to your snippet: x = y = [] x.append(2) print x print y As for your other examples: except for Pascal/Delphi, I have never used a language that has separate division operators for floats and integers, so at least for me it's only natural that 3/2 == 1, how else would I do integer division? The print example is just very weak, I can hardly even call it a WTF. Yes it's a little odd, but you're not going to hit weird runtime bugs like when you are comparing things in JavaScript, for example. I'm frankly very surprised by the almost complete absence of real Python WTF's in the Stack Overflow discussion you linked, I would have expected more. If anything, it actually shows how clean and predictable Python is.

chris_wot 14y ago

Define "natural". Firstly, == is indeed for comparison, just with an implicit cast beforehand. You don't need to wrap all your code in an anonymous self calling function, but to get the most out of it you need to - given the way it was designed, this makes sense. You speak like C syntax is "natural" - I remember grappling with pointers and references, it took some time for me to get it fully. It's not like Python doesn't have it's quirks. I find it ironic that those who use Python/Ruby/Clojure/etc want to often ridicule those who use JavaScript. They've got their own form of elitism. Get over it, seriously.

deleted 14y ago
[deleted]
artmageddon 14y ago
What the parent was saying regarding the == vs === is that unlike other languages it's very easy to get burned if you don't know the difference and when to properly use it. I'm hardly proficient at JS and not knowing that would've screwed me over.
- chris_wot 14y ago
  Can you give me a concrete example?
  - mnarayan01 14y ago
    0 == false or even better "0" == false edit: I should note that I don't think JS is a horrible language or anything, but it does have more than its share of oddities.
    - chris_wot 14y ago
      I guess I'm still confused... Where abouts in your code will you be comparing a string or integer to a Boolean? Incidentally, there are quirks - the worst is with having to define a "that" variable, I guess I just don't see these JavaScript issues as all that terrible. Unlike PHP's type coersion system, Javascript's is quite sensible.
      - lucian1900 14y ago
        The point is that comparisons between things of different types should be errors. Implicit coercion is never sensible.
        Turing_Machine 14y ago
        4 / 2.5 should be an error? Okay, then. Never mind that essentially no language in widespread use enforces that.
        lucian1900 14y ago
        That case is also potentially problematic, but perhaps better solved by having float division / and integer division // as separate operators. Perhaps my "never" was too strong.
      - mnarayan01 14y ago

pretoriusB 14y ago

>Oh, what, you thought == was for comparison? Wrong. Actually true. And truer to the dynamic spirit of Javascript than ===. Sometimes things don't have to be absolutely equal to be equal, "1" and 1 will do just fine. You can sanitise at another level. >Oh, you didn't wrap your all your code in an anonymous, self-calling function? You lose. You loose nothing. You merely expose some names to the global namespace. Which might just be just one name, anyway, sans the anonymous self-calling function. (e.g window.ns = {}, ns.doSomething = function() ... >Oh, what you thought it was okay to leave off semicolons and var statements because they aren't required? Sorry. Sorry for nothing much. A lot of people leave them off with no problem at all. The few edge cases are not unlike any other language's edge cases. >Hmm, you didn't know how to manage dependencies between scripts? Should have studied harder. Or not. If you got the result you want. >You tried to iterate over an array? Ridiculous. You probably mean the "for i in" idiom. Which is perfectly fine over an array. The only problem arises if someone has extended the Array prototype, which you shouldn't do anyway. And even that can be bypassed with one extra hasOwnProperty check. Not to mention it's solved in ES6. >Your brain exploded when trying to write a series of asynchronous functions in continuation style? A pity, really. Well, that's just because Node async style is amateur hour BS, like trying to do closures in C or logic programming in PHP. Doable, but not supported by the language. Use Go or Dart or Haskell or C# or Scala or Tornado etc for your async needs.

davedx 14y ago
> Well, that's just because Node async style is amateur hour BS, like trying to do closures in C or logic programming in PHP. Doable, but not supported by the language. Use Go or Dart or Haskell or C# or Scala or Tornado etc for your async needs. If async programming in JavaScript "isn't supported by the language": what good is it, then?
- pretoriusB 14y ago
  Who said Javascript is good for async programming? It was designed to be easy to use with callbacks for website UI style events (which is not quite the same as async programming). The Node async is just a half-thought implementation of async on top of a VM that doesn't really support it. The thing it has going for it is traction (and some people new to async are amused by the callback style and find it "challenging", whatever). Scala/Dart/Go/Rust/Haskell/etc have a better async story. ES6 will add some promising stuff in the future (no pun intended).

davedx 14y ago

The worst one for me with JavaScript lately is trying to build some form of object orientation into my code. There's no canonical way to even implement a constructor, for christ's sake. I haven't even dared to touch trying to use it for polymorphism. Or composition, for that matter. I'm staying the hell away from it for anything simpler than UI code. If JavaScript was a nicer language I would be spending more time in Node.JS, but it's not, so I'm sticking with Rails.

chris_wot 14y ago
You're forcing class based inheritance onto a language that specialises in prototypical inheritance... however, try http://tobyho.com/2010/11/22/javascript-constructors-and/ http://tobyho.com/2010/11/22/javascript-constructors-and/
ufo 14y ago
I actually don't mind this problem much, although that might be my "functional programming" bias. You only really need a "canonical" way to do things if you will be wanting to use features that depend on your classes being implemented in a predictable way. For example, class inheritance or implementing "super" method functionality. > I haven't even dared to touch trying to use it for polymorphism. Its not at hard as it sounds, since you have first class functions and closures. You can often handle functions directly instead of needing to create objects for everything.

pretoriusB 14y ago

>People who are good at JS like JS because it makes them special. They can lord their knowledge of the quirks over "lesser" developers who come to JS expecting it to act like a sane language. It took an entire industry about a decade just to learn how to tame it. Sure, JS turned out to be really extensible to new paradigms, but hey, so is the lambda calculus. All those points are moot. It's like pointing C's many flaws (or PHP's myriads). Or Ruby's. Or Javas. All languages have several syntactic or semantic issues. It didn't "took the industry a decade to learn Javascript". It took the industry a decade to have: 1) Mostly compatible implementation of JS and the DOM. 2) Powerful enough computers and JS VM so it can be used for fancy stuff. 3) A reason to use it (AJAX and involved web apps). Nothing of which has anything to do with Javascript's "difficulty" or "quirkiness" as a language.

d0m 14y ago

There are quirks in every languages - python obviously included. And please, don't forget that you're using a very old version of the Javascript language. It's a little bit like if I'm arguing about the errors and quirks of Python 1.5. Languages evolve and learn from their mistakes. Unfortunately, old browsers are stuck with old javascript versions. Some people have to write code in java 1.4 or python 1.5, they aren't People who are good at [python or java] like [python or java] because it makes them special. And that being said, most people coming from [name your favorite language] believe that Javascript works the same way as their language. It's a different language and require a different knowledge. In fact, javascript' similarity to algol might be one of the biggest problem of the language. Have you tried working with C++ without learning the language? And here are some Python cool "features": def foo(x=[]): x.append(2) print x foo() foo() Guess x? To take your term "You lose". print 3/2 What's the result? If you answered 1.5, sorry, you're wrong. We're using Python <2.2 here, and it gives 1. Here's another one, what does it do: for i in range(10): print "*", print Is it ""? Sorry, a comma at the end doesn't include a "\n" but automatically insert a space. Anyhow, have fun here: http://stackoverflow.com/questions/530530/python-2-x-gotchas-and-landmines http://stackoverflow.com/questions/530530/python-2-x-gotchas...

w0utert 14y ago
No language is perfect, but if those are the worst examples you can come up with for Python, there really is no comparison with the insane JavaScript WTF's I've seen. Default list/dictionary arguments are plain evil in Python, no disagreeing there. I've been bitten by something like the following before, which is similar to your snippet: x = y = [] x.append(2) print x print y As for your other examples: except for Pascal/Delphi, I have never used a language that has separate division operators for floats and integers, so at least for me it's only natural that 3/2 == 1, how else would I do integer division? The print example is just very weak, I can hardly even call it a WTF. Yes it's a little odd, but you're not going to hit weird runtime bugs like when you are comparing things in JavaScript, for example. I'm frankly very surprised by the almost complete absence of real Python WTF's in the Stack Overflow discussion you linked, I would have expected more. If anything, it actually shows how clean and predictable Python is.