3 ms·

> No integers. Fair enough. > Assignment is declaration. Not exactly. You can declare variables separately, if you want. In fact, a "var x = 42" statement wi

by tragic 11y ago

> No integers. Fair enough. > Assignment is declaration. Not exactly. You can declare variables separately, if you want. In fact, a "var x = 42" statement will actually be split into "var x;" at the top of the scope and "x = 42" wherever you actually wrote it by the interpreter. The specified behaviour is a little weird and non-obvious, but once you know it, you know it. > Prototypes. That's a matter of taste (plus the problem of optimisation at the VM level, admittedly). Besides which, you can basically use prototypes to do classes, if that's your bag, and of course we have class syntax now anyway. > Curly brackets & semicolons. Semicolons are optional, which however you complain about below. So are some curly braces. The only alternative to having some kind of block delimiter would be significant whitespace, which is a perfectly legitimate preference but has its own warts. > Semicolon insertion. Around which the rules are fairly simple to understand. It's possible there's just a better way to do it (I know Go has ASI, for instance, but have never heard anyone complain). --- I find this a most peculiar list of JS warts (what, not even a shout out for ==, bizarre implicit type coercions, etc?) There's no doubt it is a deeply flawed language, a big part of learning it is learning about the various spike-pits lying in wait for you, and the extra tooling required to mitigate its flaws comes with its own set of costs. At the end of the day, though, you can write pleasant, readable and - yes - effective code in JS. There are worse languages to be stuck with, as long as you watch out for the spike-pits.

wtbob 11y ago
> You can declare variables separately, if you want. The issue is that 'fop = 1' is not an error (outside of strict mode), even when I mean 'foo = 1.' Automatically creating variables makes what could be compile-time errors run-time instead. > Besides which, you can basically use prototypes to do classes, if that's your bag, and of course we have class syntax now anyway. Which I also find to be a mistake. Generic functions are the right way to do OO. > The only alternative to having some kind of block delimiter would be significant whitespace The block delimiter I prefer is () grin > It's possible there's just a better way to do it (I know Go has ASI, for instance, but have never heard anyone complain). Yes, whereas good practice on JavaScript is to always use semicolons (because its semicolon insertion is wrong), good practice in Go is to never use them (because its semicolon insertion is correct). > not even a shout out for == That was my very first point …
- tragic 11y ago
  > That was my very first point … Bizarrely, I misread it as an overcomplicated ASCII art divider. Looks like I've got a JS VM in my head... The fop typo - while I acknowledge that there are plenty of gotchas of this kind in javascript, a gotcha that will be caught by strict mode barely even counts in the grand scheme of things. Strict mode then gives you slightly better protection than in many otherwise more robust languages (Python and Ruby, for example). On the ASI side, I don't see how it can be 'incorrect' - it's a well specified behaviour obeyed consistently, so far as I can tell, across the vast bulk of implementations. It may be a bad design, but that's a different thing. Go's version is certainly easier to explain in a paragraph or less. I'm assuming by generic functions you're talking about eg. Clojure protocols or Haskell typeclass functions or stuff like that, which I also prefer (I also like round parens). But at this point, you're just criticising JS for not being $LANGUAGE_I_LIKE, which it isn't, obviously, but does not count as a terrible sin in and of itself. I return to my main point - no, JS is not a great piece of language design, but it's hardly 'nuke from orbit' bad. There are certainly things I'd rather be working with, but equally there are worse fates that we could have been stuck with after the browser wars. "Life — the way it really is — is a battle not between good and bad, but between bad and worse".
  - wtbob 11y ago
    > Bizarrely, I misread it as an overcomplicated ASCII art divider. No worries! > Strict mode then gives you slightly better protection than in many otherwise more robust languages (Python and Ruby, for example). I really dislike that aspect of Python; IMHO it's a pretty bad flaw. > On the ASI side, I don't see how it can be 'incorrect' I think it's incorrect in the sense that it's such a bad design that the Right Thing to do is to always use semicolons manually (with the corollary that if the design is such that one never uses them — as with Go — then it must be correct). > I'm assuming by generic functions you're talking about eg. Clojure protocols or Haskell typeclass functions or stuff like that I'm thinking Lisp's multimethods. Behaviour doesn't really belong to one object or another, an uniquely privileging the first argument is just weird. > I return to my main point - no, JS is not a great piece of language design, but it's hardly 'nuke from orbit' bad. If it weren't for the installed base, I think JavaScript would be only two steps ahead of INTERCAL …
jlas 11y ago
> and of course we have class syntax now anyway Even using Class syntax you're still locked into prototypical inheritance model. There is no classical inheritance in JS. (Probably a backward step in UX to call it "Class")
- tragic 11y ago
  Yes, but you're locked into the subset of prototypal inheritance that basically is class inheritance. A class is, fundamentally, just a prototype of a particular kind.
  - chrisweekly 11y ago
    Classical inheritance sucks. https://medium.com/javascript-scene/the-two-pillars-of-javascript-ee6f3281e7f3#.icv7eudft https://medium.com/javascript-scene/the-two-pillars-of-javas...
johnsonjo 11y ago
I think with the "No integers" part that isn't entirely true JavaScript has typed arrays now. So you could get an array of ints that way. I'm not familiar with them and whether they behave in a similar way as an int in a typed language like Java or C++, but from my reading it seems the integer view behaves (output wise) in much the same way as other typed languages integers. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays https://developer.mozilla.org/en-US/docs/Web/JavaScript/Type...

by tragic 11y ago

wtbob 11y ago

> You can declare variables separately, if you want. The issue is that 'fop = 1' is not an error (outside of strict mode), even when I mean 'foo = 1.' Automatically creating variables makes what could be compile-time errors run-time instead. > Besides which, you can basically use prototypes to do classes, if that's your bag, and of course we have class syntax now anyway. Which I also find to be a mistake. Generic functions are the right way to do OO. > The only alternative to having some kind of block delimiter would be significant whitespace The block delimiter I prefer is () grin > It's possible there's just a better way to do it (I know Go has ASI, for instance, but have never heard anyone complain). Yes, whereas good practice on JavaScript is to always use semicolons (because its semicolon insertion is wrong), good practice in Go is to never use them (because its semicolon insertion is correct). > not even a shout out for == That was my very first point …

tragic 11y ago
> That was my very first point … Bizarrely, I misread it as an overcomplicated ASCII art divider. Looks like I've got a JS VM in my head... The fop typo - while I acknowledge that there are plenty of gotchas of this kind in javascript, a gotcha that will be caught by strict mode barely even counts in the grand scheme of things. Strict mode then gives you slightly better protection than in many otherwise more robust languages (Python and Ruby, for example). On the ASI side, I don't see how it can be 'incorrect' - it's a well specified behaviour obeyed consistently, so far as I can tell, across the vast bulk of implementations. It may be a bad design, but that's a different thing. Go's version is certainly easier to explain in a paragraph or less. I'm assuming by generic functions you're talking about eg. Clojure protocols or Haskell typeclass functions or stuff like that, which I also prefer (I also like round parens). But at this point, you're just criticising JS for not being $LANGUAGE_I_LIKE, which it isn't, obviously, but does not count as a terrible sin in and of itself. I return to my main point - no, JS is not a great piece of language design, but it's hardly 'nuke from orbit' bad. There are certainly things I'd rather be working with, but equally there are worse fates that we could have been stuck with after the browser wars. "Life — the way it really is — is a battle not between good and bad, but between bad and worse".
- wtbob 11y ago
  > Bizarrely, I misread it as an overcomplicated ASCII art divider. No worries! > Strict mode then gives you slightly better protection than in many otherwise more robust languages (Python and Ruby, for example). I really dislike that aspect of Python; IMHO it's a pretty bad flaw. > On the ASI side, I don't see how it can be 'incorrect' I think it's incorrect in the sense that it's such a bad design that the Right Thing to do is to always use semicolons manually (with the corollary that if the design is such that one never uses them — as with Go — then it must be correct). > I'm assuming by generic functions you're talking about eg. Clojure protocols or Haskell typeclass functions or stuff like that I'm thinking Lisp's multimethods. Behaviour doesn't really belong to one object or another, an uniquely privileging the first argument is just weird. > I return to my main point - no, JS is not a great piece of language design, but it's hardly 'nuke from orbit' bad. If it weren't for the installed base, I think JavaScript would be only two steps ahead of INTERCAL …

jlas 11y ago

> and of course we have class syntax now anyway Even using Class syntax you're still locked into prototypical inheritance model. There is no classical inheritance in JS. (Probably a backward step in UX to call it "Class")

tragic 11y ago
Yes, but you're locked into the subset of prototypal inheritance that basically is class inheritance. A class is, fundamentally, just a prototype of a particular kind.
- chrisweekly 11y ago
  Classical inheritance sucks. https://medium.com/javascript-scene/the-two-pillars-of-javascript-ee6f3281e7f3#.icv7eudft https://medium.com/javascript-scene/the-two-pillars-of-javas...

johnsonjo 11y ago

I think with the "No integers" part that isn't entirely true JavaScript has typed arrays now. So you could get an array of ints that way. I'm not familiar with them and whether they behave in a similar way as an int in a typed language like Java or C++, but from my reading it seems the integer view behaves (output wise) in much the same way as other typed languages integers. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays https://developer.mozilla.org/en-US/docs/Web/JavaScript/Type...