6 ms·

I disagree. While Python, for instance, certainly has its quirks, it doesn't have multiple ways of declaring a function, each with their own scope and hoisting

I disagree. While Python, for instance, certainly has its quirks, it doesn't have multiple ways of declaring a function, each with their own scope and hoisting gotchas. In Python, self isn't ambiguous the way this is in JavaScript. Python's datatypes are straight forward, unlike JavaScript, where 1 + "1" produces a valid result. In Python, 9999999999999999 is precisely 9999999999999999, however in JavaScript this is true: 9999999999999999 == 10000000000000000.

BigJono 9y ago
I've been a professional Javascript dev for over 5 years and never once run into a bug due to any of these problems. I agree that they are problems, but their impact on day to day use of the language is zero. If you want examples of real problems that give good front end devs hell day in and day out, start looking at some of the libraries, tooling and abhorrent "best practices" that get thrown out and cargo culted to death by the community. The language itself is the last problem with JS
- hnzix 9y ago
  I've spent days tracking down a bug around a color picker widget, turns out JS was implicitly casting my string value to octal. I've worked with heaps of toy languages like Lingo, vbscript and ActionScript, and nothing has made me as viscerally angry as JavaScript (ok maybe PHP's complete lack of naming consistency). JS is an accident of history that has somehow become the de facto standard. I guess worse really is better.
  - k__ 9y ago
    That's like saying group XY of people is bad because you got mugged by one person of that group one time. While I understand that a problem like this is unnerving, it isn't the rule.
    - hnzix 9y ago
      Wait, did you just call me racist for not liking JavaScript?
      - k__ 9y ago
        A chauvinist. People throwing around strawmen in here like nobodies business. We can do this with all languages and tell ourselve we're using the "superior" language.
  - kaoD 9y ago
    > turns out JS was implicitly casting my string value to octal How exactly? I'm really curious. AFAIK it's pretty hard for a JS string to be casted into anything (pretty easy the other way around though). I guess maybe parseInt can do that, but that's neither casting not implicit.
    - hnzix 9y ago
      Looks like it's been fixed in ES5. From memory I was performing an operation on a html color string and if you clicked a color with a certain prefix it would crash. I could easily reproduce the bug but it took me forever to work out why JS was choking. I think I added in some ridiculous string padding to prevent the auto casting. https://stackoverflow.com/questions/2547836/why-doesnt-an-octal-literal-as-a-string-cast-to-a-number https://stackoverflow.com/questions/2547836/why-doesnt-an-oc...
      - rwaldron 9y ago
        > Looks like it's been fixed in ES5 That was published 9 years ago.
    - phpnode 9y ago
      Presumably by calling parseInt('010') which used to detect zero leading strings as octal.
- mythrwy 9y ago
  I enjoy Javascript, have also programmed in it professionally for a little longer than you, didn't read all the docs in depth, don't have a great memory, and it on (admittedly less and less all the time) rare occasions still surprises me with unexpected or downright bizarre behavior. (But I also use other languages and thus know what sanity looks like).
- innocentoldguy 9y ago
  Sure, you can work around JavaScript's warts, but it is one thing to say the warts can be circumvented and quite another to claim that JavaScript is on par with well-designed languages like Python. I do agree with you that the JavaScript community's issues you mentioned are hell to deal with; however, in my opinion, JavaScript's internal weaknesses are one of the driving factors behind this churn.
skrebbel 9y ago
Both ESLint and TypeScript solve all of that except the integer thing. But I'd wager that the "no integers over 2^53" is seldomly a problem, and in most other languages there's a similar problem at 2^64. If you reasonably expect to get integers above 2^53, you probably want to think about how to deal with integers above 2^64 as well. So really it's the exact same thing except JavaScript's numbers are easier to complain about on the internet.
- kolinko 9y ago
  Actually, in Python integers have no upper limit (sic!). I did some Ethereum front- and backend development in both Python and in JS, and this made a lot of difference in the readability of the code. In Python, the only problems we encountered was when writing into ndb, which has 64 ints by default, whereas in JS, we had to use BigNumbers everywhere.
  - skrebbel 9y ago
    Oh wow, really? I feel pretty stupid now. All languages I've used in anger have an upper limit for integers so I'd just assumed this was pretty much general. I see now that it works in Ruby just like in Python. Pretty cool! Learn something new each day :-)
- detaro 9y ago
  It's a bit annoying when doing interop between languages that have the (more common) 2⁶⁴ limit and JS - int64 for IDs etc is fairly common and you then always have to remember to convert them, e.g. by putting IDs as strings in JSON output instead of as a number.
k__ 9y ago
Just because JS' _this_ doesn't behave like in other languages doesn't make it bad, I mean it's behaviour is well defined. JavaScript is more dynamic than most languages and yes this may be hard to grasp for the average developer, especially when they come from languages that are considered "more mature".
- rwaldron 9y ago
  > behaviour is well defined. True, and we could go one step further: it's unambiguously defined, with invariant rules that can be used to prove a conformant implementation.
  - heavenlyblue 9y ago
    Yet we still struggle with making sure we've got all of the tools that could check the mistakes I have accidentally made before I had shipped the code. XMPP had been defined as formally: where have we ended up with it now?
undecidabot 9y ago
Just wanted to make a few counter-arguments: > re: it doesn't have multiple ways of declaring a function... Python does have multiple ways of declaring a function, the usual `def` syntax and via `lambda`. Lambdas are restricted to one line (due to Python's whitespace sensitivity), which can be inconvenient (but hey at least no one can abuse it right?). Python functions also have a scoping gotcha: you can read the variables in the outer scope, but if you write to it (without declaring it as nonlocal) it actually treats that as a separate variable declaration (this is due to its assignment syntax). > re: Python's datatypes are straight forward... While Python's type system is nowhere as lenient as JavaScript's, there is at least one unexpected case which works: `True + 1` produces as valid result (2). Also, having to explicitly cast non-strings is rather inconvenient when concatenating stuff to produce a string (even Java doesn't require this). Thankfully, Python has a decent string formatting function built-in. > re: 9999999999999999 is precisely 9999999999999999 It'll still fail if those are floating points. Yes, I am aware that Python has decimal and rational types in its standard library. My point is, no matter what language it is, programmers need to be aware of the data types and data structures they are dealing with. FWIW, I don't think JS is better (or worse) than Python (as long as we're talking about "modern" JS with modules). Python also has its fair share of major issues, notably v2 vs v3, which is slowly becoming a non-issue as everyone (finally!) migrates to 3.
tastyham 9y ago
Python has at least 4 ways to define a function: you can have a plain function, a bound instance method, a bound class method, and a lambda, which is similar to the same options js has. Python's type handling is much better, but that can be mostly avoided in JS by understanding and avoiding the cases where js typing sucks. Other than Python's superior type handling and standard library they seem like very similar languages to me.
rwaldron 9y ago
9999999999999999 > Number.MAX_SAFE_INTEGER === true JavaScript numbers are IEEE754 double precision floating point format.

BigJono 9y ago

I've been a professional Javascript dev for over 5 years and never once run into a bug due to any of these problems. I agree that they are problems, but their impact on day to day use of the language is zero. If you want examples of real problems that give good front end devs hell day in and day out, start looking at some of the libraries, tooling and abhorrent "best practices" that get thrown out and cargo culted to death by the community. The language itself is the last problem with JS

hnzix 9y ago
I've spent days tracking down a bug around a color picker widget, turns out JS was implicitly casting my string value to octal. I've worked with heaps of toy languages like Lingo, vbscript and ActionScript, and nothing has made me as viscerally angry as JavaScript (ok maybe PHP's complete lack of naming consistency). JS is an accident of history that has somehow become the de facto standard. I guess worse really is better.
- k__ 9y ago
  That's like saying group XY of people is bad because you got mugged by one person of that group one time. While I understand that a problem like this is unnerving, it isn't the rule.
  - hnzix 9y ago
    Wait, did you just call me racist for not liking JavaScript?
    - k__ 9y ago
      A chauvinist. People throwing around strawmen in here like nobodies business. We can do this with all languages and tell ourselve we're using the "superior" language.
- kaoD 9y ago
  > turns out JS was implicitly casting my string value to octal How exactly? I'm really curious. AFAIK it's pretty hard for a JS string to be casted into anything (pretty easy the other way around though). I guess maybe parseInt can do that, but that's neither casting not implicit.
  - hnzix 9y ago
    Looks like it's been fixed in ES5. From memory I was performing an operation on a html color string and if you clicked a color with a certain prefix it would crash. I could easily reproduce the bug but it took me forever to work out why JS was choking. I think I added in some ridiculous string padding to prevent the auto casting. https://stackoverflow.com/questions/2547836/why-doesnt-an-octal-literal-as-a-string-cast-to-a-number https://stackoverflow.com/questions/2547836/why-doesnt-an-oc...
    - rwaldron 9y ago
      > Looks like it's been fixed in ES5 That was published 9 years ago.
  - phpnode 9y ago
    Presumably by calling parseInt('010') which used to detect zero leading strings as octal.
mythrwy 9y ago
I enjoy Javascript, have also programmed in it professionally for a little longer than you, didn't read all the docs in depth, don't have a great memory, and it on (admittedly less and less all the time) rare occasions still surprises me with unexpected or downright bizarre behavior. (But I also use other languages and thus know what sanity looks like).
innocentoldguy 9y ago
Sure, you can work around JavaScript's warts, but it is one thing to say the warts can be circumvented and quite another to claim that JavaScript is on par with well-designed languages like Python. I do agree with you that the JavaScript community's issues you mentioned are hell to deal with; however, in my opinion, JavaScript's internal weaknesses are one of the driving factors behind this churn.

skrebbel 9y ago

Both ESLint and TypeScript solve all of that except the integer thing. But I'd wager that the "no integers over 2^53" is seldomly a problem, and in most other languages there's a similar problem at 2^64. If you reasonably expect to get integers above 2^53, you probably want to think about how to deal with integers above 2^64 as well. So really it's the exact same thing except JavaScript's numbers are easier to complain about on the internet.

kolinko 9y ago
Actually, in Python integers have no upper limit (sic!). I did some Ethereum front- and backend development in both Python and in JS, and this made a lot of difference in the readability of the code. In Python, the only problems we encountered was when writing into ndb, which has 64 ints by default, whereas in JS, we had to use BigNumbers everywhere.
- skrebbel 9y ago
  Oh wow, really? I feel pretty stupid now. All languages I've used in anger have an upper limit for integers so I'd just assumed this was pretty much general. I see now that it works in Ruby just like in Python. Pretty cool! Learn something new each day :-)
detaro 9y ago
It's a bit annoying when doing interop between languages that have the (more common) 2⁶⁴ limit and JS - int64 for IDs etc is fairly common and you then always have to remember to convert them, e.g. by putting IDs as strings in JSON output instead of as a number.

k__ 9y ago

Just because JS' _this_ doesn't behave like in other languages doesn't make it bad, I mean it's behaviour is well defined. JavaScript is more dynamic than most languages and yes this may be hard to grasp for the average developer, especially when they come from languages that are considered "more mature".

rwaldron 9y ago
> behaviour is well defined. True, and we could go one step further: it's unambiguously defined, with invariant rules that can be used to prove a conformant implementation.
- heavenlyblue 9y ago
  Yet we still struggle with making sure we've got all of the tools that could check the mistakes I have accidentally made before I had shipped the code. XMPP had been defined as formally: where have we ended up with it now?

undecidabot 9y ago

Just wanted to make a few counter-arguments: > re: it doesn't have multiple ways of declaring a function... Python does have multiple ways of declaring a function, the usual `def` syntax and via `lambda`. Lambdas are restricted to one line (due to Python's whitespace sensitivity), which can be inconvenient (but hey at least no one can abuse it right?). Python functions also have a scoping gotcha: you can read the variables in the outer scope, but if you write to it (without declaring it as nonlocal) it actually treats that as a separate variable declaration (this is due to its assignment syntax). > re: Python's datatypes are straight forward... While Python's type system is nowhere as lenient as JavaScript's, there is at least one unexpected case which works: `True + 1` produces as valid result (2). Also, having to explicitly cast non-strings is rather inconvenient when concatenating stuff to produce a string (even Java doesn't require this). Thankfully, Python has a decent string formatting function built-in. > re: 9999999999999999 is precisely 9999999999999999 It'll still fail if those are floating points. Yes, I am aware that Python has decimal and rational types in its standard library. My point is, no matter what language it is, programmers need to be aware of the data types and data structures they are dealing with. FWIW, I don't think JS is better (or worse) than Python (as long as we're talking about "modern" JS with modules). Python also has its fair share of major issues, notably v2 vs v3, which is slowly becoming a non-issue as everyone (finally!) migrates to 3.

tastyham 9y ago

Python has at least 4 ways to define a function: you can have a plain function, a bound instance method, a bound class method, and a lambda, which is similar to the same options js has. Python's type handling is much better, but that can be mostly avoided in JS by understanding and avoiding the cases where js typing sucks. Other than Python's superior type handling and standard library they seem like very similar languages to me.

rwaldron 9y ago

9999999999999999 > Number.MAX_SAFE_INTEGER === true JavaScript numbers are IEEE754 double precision floating point format.