3 ms·

My favorite thing about JS now coming into wider use is how it drives a certain class of older hackers bonkers. It has 0 and -0! The default namespace is globa

by moron 14y ago

My favorite thing about JS now coming into wider use is how it drives a certain class of older hackers bonkers. It has 0 and -0! The default namespace is global! It has a === operator, for crying out loud! For folks who spent a bunch of time writing AbstractPatternVisitorHandlerFactory classes, it probably looks like the end of the world at the hands of a bunch of freakin' degenerates.

emarcotte 14y ago
Or folks to just don't like hidden surprises when trying to do trivially simple things?
- jonpacker 14y ago
  If you take an hour to sit down and understand the type coercion, all of these "hidden surprises" magically disappear.
  - redbad 14y ago
    1. Understanding JavaScript type coercion correctly, including (emphasizing!) all of the corner cases that actually matter, is not an hour's task. 2. The fact that pathological-condition-X of a language is in theory understandable with sufficient study is a total red herring in a broad discussion of that language.
    - ZenPsycho 14y ago
      Understanding all the corner cases of how C deals with integers is a huge undertaking, as the C Integer Quiz thread showed us. But in practice, it's not actually a problem since you just learn to avoid using features of the language that involve type coercion. Just simply don't mix types. only use === and !==, use a templating library instead of the + operator to construct strings. jslint can catch the rest. If you truly find the way javascript behaves surprising- in the sense that you are trying to do something reasonable, and it surprises you, I have to wonder what on earth you are trying to do that would invoke type coercion to begin with, and why you need to do it that way.
      - wmf 14y ago
        If parts of the language are so confusing that they should be avoided, arguably they should be removed completely.
        rwallace 14y ago
        They should, were it not for the backward compatibility requirement.
      - riffraff 14y ago
        I think there is a bit of an issue with _the code you don't write_ , because you rely on third parties. Today, I spent five minutes tracking down a SyntaxError: Unexpected token u It was honestly hard to read this as "don't give an un-itialized value to this function or it will end up being passed to JSON.parse that will happily treat undefined as a string". I'd take a NullPointerException with a proper stacktrace everyday.
        ZenPsycho 14y ago
        in chrome, error objects have stack traces attached. All you would have needed to do is wrap the problem code in a try/catch, catch the error, and print out the stack trace, assuming you can't figure out how to find the stack trace just using chrome's web debugger. https://code.google.com/p/v8/wiki/JavaScriptStackTraceApi https://code.google.com/p/v8/wiki/JavaScriptStackTraceApi
        riffraff 14y ago
        You are missing my point, the issue is not that the error does not have a stacktrace, it's that it looks like: SyntaxError: Unexpected token u foo.js:123 h foo.js:456 g foo.js:789 f The issues are * no reference to JSON.parse which is where the error occurred * the error is not "object has no attribute toString", which would have made it clear what it's happening, but something else derived from having silently coerced "undefined" to string, which obscures what is happening. As I wrote, it was a five minutes thing, not hours, but it's five minutes I would not have spent if it had been: TypeError: Cannot read property 'toString' of undefined: [native code] JSON.parse [native code] h foo.js:456 g foo.js:789 f
  - deleted 14y ago
    [deleted]
  - div 14y ago
    While I share your "just sit down and learn something instead of complaining" sentiment, in this case I think it's pretty difficult to memorize all the different ways that javascript does type coercion. Sure you get to know the most common pitfalls, but it just feels like even experienced JS programmers get bitten every now and then. By now I'm sure everyone has seen the WAT talk (https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat) which illustrates some of the more obscure (and funny) coercions. It's ok to say that JS's type coercion is a misfeature, good programmers learn to not throw out the baby with the bathwater.
  - stcredzero 14y ago
    If you take [time-span] to understand the [x], all of these "hidden surprises" magically disappear. Rewritten as a general programming language "smell". (That said, I do enjoy me some Javascripting, and I have a side-project with it.)
blub 14y ago
It's not that at all. I use JS almost daily and the unfortunate conclusion is that it's just poorly designed. The data structures are lacking and have bizarre corner cases. I don't know if what it features as OO can be called OO and I don't care much, but the abstraction mechanisms are inferior to what I'm used to. Performance is unpredictable and sometimes I'm forced to write less readable code. Refactoring is a scary adventure, debugging is subpar, code navigation is cumbersome.. The things that I do like about it are availability and that it's cross-platform.
- smacktoward 14y ago
  Re "poorly designed", in fairness, its original designer (Brendan Eich) had to put the whole language together by himself in ten days under a mandate from his overlords at Netscape corporate that he make it look kind of like Java while not looking too much like Java (see http://www.computer.org/csdl/mags/co/2012/02/mco2012020007.html http://www.computer.org/csdl/mags/co/2012/02/mco2012020007.h..., http://www.jwz.org/blog/2010/10/every-day-i-learn-something-new-and-stupid/#comment-1021 http://www.jwz.org/blog/2010/10/every-day-i-learn-something-...). Given those circumstances, the amazing thing is that JavaScript has held up as well as it has.
dalke 14y ago
I struggle to think of someone who considers themself as a "hacker" and would use "AbstractPatternVisitorHandlerFactory classes."
deleted 14y ago
[deleted]
redbad 14y ago
These things, like default global namespace, aren't just bad to a particular class of gray-beard enterprise developers who build AbstractFactoryFactories and are correspondingly easy to ridicule. They're _bad_ bad, net-negative properties of a language. I'm not sure why you would (appear to) defend them. Can you please clarify?
- deleted 14y ago
  [deleted]
- marknutter 14y ago
  I imagine the OP isn't defending them, but just remarking about how sick they are of hearing people bitch about javascript.

by moron 14y ago

emarcotte 14y ago

Or folks to just don't like hidden surprises when trying to do trivially simple things?

jonpacker 14y ago
If you take an hour to sit down and understand the type coercion, all of these "hidden surprises" magically disappear.
- redbad 14y ago
  1. Understanding JavaScript type coercion correctly, including (emphasizing!) all of the corner cases that actually matter, is not an hour's task. 2. The fact that pathological-condition-X of a language is in theory understandable with sufficient study is a total red herring in a broad discussion of that language.
  - ZenPsycho 14y ago
    Understanding all the corner cases of how C deals with integers is a huge undertaking, as the C Integer Quiz thread showed us. But in practice, it's not actually a problem since you just learn to avoid using features of the language that involve type coercion. Just simply don't mix types. only use === and !==, use a templating library instead of the + operator to construct strings. jslint can catch the rest. If you truly find the way javascript behaves surprising- in the sense that you are trying to do something reasonable, and it surprises you, I have to wonder what on earth you are trying to do that would invoke type coercion to begin with, and why you need to do it that way.
    - wmf 14y ago
      If parts of the language are so confusing that they should be avoided, arguably they should be removed completely.
      - rwallace 14y ago
        They should, were it not for the backward compatibility requirement.
    - riffraff 14y ago
      I think there is a bit of an issue with _the code you don't write_ , because you rely on third parties. Today, I spent five minutes tracking down a SyntaxError: Unexpected token u It was honestly hard to read this as "don't give an un-itialized value to this function or it will end up being passed to JSON.parse that will happily treat undefined as a string". I'd take a NullPointerException with a proper stacktrace everyday.
      - ZenPsycho 14y ago
        in chrome, error objects have stack traces attached. All you would have needed to do is wrap the problem code in a try/catch, catch the error, and print out the stack trace, assuming you can't figure out how to find the stack trace just using chrome's web debugger. https://code.google.com/p/v8/wiki/JavaScriptStackTraceApi https://code.google.com/p/v8/wiki/JavaScriptStackTraceApi
        riffraff 14y ago
        You are missing my point, the issue is not that the error does not have a stacktrace, it's that it looks like: SyntaxError: Unexpected token u foo.js:123 h foo.js:456 g foo.js:789 f The issues are * no reference to JSON.parse which is where the error occurred * the error is not "object has no attribute toString", which would have made it clear what it's happening, but something else derived from having silently coerced "undefined" to string, which obscures what is happening. As I wrote, it was a five minutes thing, not hours, but it's five minutes I would not have spent if it had been: TypeError: Cannot read property 'toString' of undefined: [native code] JSON.parse [native code] h foo.js:456 g foo.js:789 f
- deleted 14y ago
  [deleted]
- div 14y ago
  While I share your "just sit down and learn something instead of complaining" sentiment, in this case I think it's pretty difficult to memorize all the different ways that javascript does type coercion. Sure you get to know the most common pitfalls, but it just feels like even experienced JS programmers get bitten every now and then. By now I'm sure everyone has seen the WAT talk (https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat) which illustrates some of the more obscure (and funny) coercions. It's ok to say that JS's type coercion is a misfeature, good programmers learn to not throw out the baby with the bathwater.
- stcredzero 14y ago
  If you take [time-span] to understand the [x], all of these "hidden surprises" magically disappear. Rewritten as a general programming language "smell". (That said, I do enjoy me some Javascripting, and I have a side-project with it.)

blub 14y ago

It's not that at all. I use JS almost daily and the unfortunate conclusion is that it's just poorly designed. The data structures are lacking and have bizarre corner cases. I don't know if what it features as OO can be called OO and I don't care much, but the abstraction mechanisms are inferior to what I'm used to. Performance is unpredictable and sometimes I'm forced to write less readable code. Refactoring is a scary adventure, debugging is subpar, code navigation is cumbersome.. The things that I do like about it are availability and that it's cross-platform.

smacktoward 14y ago
Re "poorly designed", in fairness, its original designer (Brendan Eich) had to put the whole language together by himself in ten days under a mandate from his overlords at Netscape corporate that he make it look kind of like Java while not looking too much like Java (see http://www.computer.org/csdl/mags/co/2012/02/mco2012020007.html http://www.computer.org/csdl/mags/co/2012/02/mco2012020007.h..., http://www.jwz.org/blog/2010/10/every-day-i-learn-something-new-and-stupid/#comment-1021 http://www.jwz.org/blog/2010/10/every-day-i-learn-something-...). Given those circumstances, the amazing thing is that JavaScript has held up as well as it has.

dalke 14y ago

I struggle to think of someone who considers themself as a "hacker" and would use "AbstractPatternVisitorHandlerFactory classes."

deleted 14y ago

[deleted]

redbad 14y ago

These things, like default global namespace, aren't just bad to a particular class of gray-beard enterprise developers who build AbstractFactoryFactories and are correspondingly easy to ridicule. They're _bad_ bad, net-negative properties of a language. I'm not sure why you would (appear to) defend them. Can you please clarify?

deleted 14y ago
[deleted]
marknutter 14y ago
I imagine the OP isn't defending them, but just remarking about how sick they are of hearing people bitch about javascript.