5 ms·

I'm not defending javascript, but I just want to answer the "wat" by saying these are all just jabs at its type coercion rules, the fact that an array is an obj

I'm not defending javascript, but I just want to answer the "wat" by saying these are all just jabs at its type coercion rules, the fact that an array is an object, and that the toString method for each type usually isn't that helpful by default. None of this matters most of the time, but yeah it's still funny. In case you want to laugh harder: https://getify.github.io/coercions-grid/ https://getify.github.io/coercions-grid/

eyelidlessness 4y ago
When I first saw this video, besides laughing constantly I also generally anticipated what was coming next because I was intimately familiar with JS type coercion esoteria. A decade later with a near decade long strict personal rule to never rely on implicit type coercion (with one exception, undefined/null, because it’s almost always what you’d want/intend), quite a lot of that memorization has fallen out of my head, and I’m prepared to let it stay that way. Because yep, it pretty much reduces to the category Type Coercion Rules. But that category in JS is so absurd that normal absurdities feel like minor tomfoolery. (And lest I paint myself as the typical HN anti-JS crusader, I do almost all of my work and personal dev in JS/TS, mostly without complaint.)
- TheRealPomax 4y ago
  And even that last one you can now finally explicitly account for with the incredibly unfortunately syntaxed, but critically useful, double question mark.
  - eyelidlessness 4y ago
    Yeah, and I also make exceptions for == null and != null where it aids readability of the code. Linter blocks any other type coercive comparison, but allows that one (and honestly I think it should be mandated, but I haven’t had a need to push that lever for a long time either).
- illiarian 4y ago
  I once read the spec to see why the hell type coercion was the way it was... And it kinda made sense? But this was 5-6 years ago and I forgot all the details. Because without going into deep dark corners of the spec it doesn't really make sense. At all :)
rektide 4y ago
Browbeating JS with this derision has/had become almost an article of faith amongst online circles. It's clearly not great behavior but generally it doesnt really have much impact on day to day. Yet people love making themselves feel better by latching on to criticism. Signaling your greatness & expertness by beating up on others.
- ParetoOptimal 4y ago
  What if it's not beating up on others, but being very critical of languages because you believe language choice actually does matter?
  - xdennis 4y ago
    That's completely fair, but I FEEL (don't know for sure) that many people who criticize JavaScript don't know it very well and don't pick meaningful things to criticize, but things like its rubbish type coercions (which doesn't have a big impact in real life).
  - rektide 4y ago
    You should a) pick big impact items to argue your case b) still acknowledge strengths & successes amid your critique. Also if you are facing the world's most popular language & a very successful one people build all sorts of stuff with without complaint, it's a big barrier. I think most language bigots lack a good narrative. They have a language they love, or a language they hate, but they harp upon specific issues. But to I think most coders, choice of language is actually pretty far down the list, especially if you ask them to ignore the ecosystem of packages/tooling & focus on the language itself. Trying to go beyond scoring points & telling a story about life being actually authentically really different on one path or another keeps being harder and harder to se, as we keep marching through the decades & seeing few really really strong distinct clear advantages anywhere, no one really excelling at their claimed bag, in an unreplicateable way that shows it really is the language, not just ecosystem. (rust being one genuine exception)
- goto11 4y ago
  If you use JavaScript you need to be aware of these pitfalls, otherwise it will bite you. The video just does it in an entertaining way.
titzer 4y ago
Implicit conversions are very pernicious. In Virgil, the only implicit conversions that happen are promotions, i.e. representation changes that don't change values, like float -> double, int -> larger int, int -> double (where no rounding occurs), etc. AFAICT this is a pretty sane model.
ParetoOptimal 4y ago
> None of this matters most of the time, but yeah it's still funny. Implicit type coercion doesn't matter most of the time? You don't often have bugs because of it?
- sublinear 4y ago
  In the browser all user input, API responses, and application state is validated and sanitized before it ever gets to the application logic. On the backend all requests and database values are similarly validated and sanitized before any logic occurs. Anything less is bad code regardless of what languages are used.
  - kerkeslager 4y ago
    > In the browser all user input, API responses, and application state is validated and sanitized before it ever gets to the application logic. Good thing there are never any bugs in validation and sanitization code!
    - sublinear 4y ago
      You shouldn't roll your own for this. From what I've had to do web-wise, here's a few tools. First, for the APIs, you need documentation: https://swagger.io/ https://swagger.io/ From which you can generate JSON schemas and use those to validate in the browser and on the backend. https://www.npmjs.com/package/jsonschema https://www.npmjs.com/package/jsonschema As well you should be writing a few more schemas for your application state and leverage the regex validation of your input components... Speaking of which, you also need to sanitize out some potentially nasty input. https://www.npmjs.com/package/dompurify https://www.npmjs.com/package/dompurify Obviously this isn't everything and not perfect, but a lot of this tedium can be automated away if you have a few good examples of the happy path and some basic tests in place to prevent quick and dirty changes from poking holes in these layers.
    - jeffhuys 4y ago
      Sigh. I hate this type of "conversation". Go back to reddit.
cmrdporcupine 4y ago
It's not just implicit conversions. It's misuse of operators, too. Using the '+' operator string append is the kind of thing that language designers get initially seduced by ("it just makes sense" "so convenient" "neat") but the reality is that combined with implicit type coercions it's just a recipe for exotic and unexpected behaviours. Precedence rules and expectations for 'string append' vs 'add numbers' is different. And then if you through in 'multiplication = repeat.' It's ... now you have this Wat-talk video (which is a classic which I always share with people when the topic of this comes up.) Maybe I'm just getting stuffy as I get old, but the older I get the more .. explicit.. I want my PL semantics to be.

eyelidlessness 4y ago

When I first saw this video, besides laughing constantly I also generally anticipated what was coming next because I was intimately familiar with JS type coercion esoteria. A decade later with a near decade long strict personal rule to never rely on implicit type coercion (with one exception, undefined/null, because it’s almost always what you’d want/intend), quite a lot of that memorization has fallen out of my head, and I’m prepared to let it stay that way. Because yep, it pretty much reduces to the category Type Coercion Rules. But that category in JS is so absurd that normal absurdities feel like minor tomfoolery. (And lest I paint myself as the typical HN anti-JS crusader, I do almost all of my work and personal dev in JS/TS, mostly without complaint.)

TheRealPomax 4y ago
And even that last one you can now finally explicitly account for with the incredibly unfortunately syntaxed, but critically useful, double question mark.
- eyelidlessness 4y ago
  Yeah, and I also make exceptions for == null and != null where it aids readability of the code. Linter blocks any other type coercive comparison, but allows that one (and honestly I think it should be mandated, but I haven’t had a need to push that lever for a long time either).
illiarian 4y ago
I once read the spec to see why the hell type coercion was the way it was... And it kinda made sense? But this was 5-6 years ago and I forgot all the details. Because without going into deep dark corners of the spec it doesn't really make sense. At all :)

rektide 4y ago

Browbeating JS with this derision has/had become almost an article of faith amongst online circles. It's clearly not great behavior but generally it doesnt really have much impact on day to day. Yet people love making themselves feel better by latching on to criticism. Signaling your greatness & expertness by beating up on others.

ParetoOptimal 4y ago
What if it's not beating up on others, but being very critical of languages because you believe language choice actually does matter?
- xdennis 4y ago
  That's completely fair, but I FEEL (don't know for sure) that many people who criticize JavaScript don't know it very well and don't pick meaningful things to criticize, but things like its rubbish type coercions (which doesn't have a big impact in real life).
- rektide 4y ago
  You should a) pick big impact items to argue your case b) still acknowledge strengths & successes amid your critique. Also if you are facing the world's most popular language & a very successful one people build all sorts of stuff with without complaint, it's a big barrier. I think most language bigots lack a good narrative. They have a language they love, or a language they hate, but they harp upon specific issues. But to I think most coders, choice of language is actually pretty far down the list, especially if you ask them to ignore the ecosystem of packages/tooling & focus on the language itself. Trying to go beyond scoring points & telling a story about life being actually authentically really different on one path or another keeps being harder and harder to se, as we keep marching through the decades & seeing few really really strong distinct clear advantages anywhere, no one really excelling at their claimed bag, in an unreplicateable way that shows it really is the language, not just ecosystem. (rust being one genuine exception)
goto11 4y ago
If you use JavaScript you need to be aware of these pitfalls, otherwise it will bite you. The video just does it in an entertaining way.

titzer 4y ago

Implicit conversions are very pernicious. In Virgil, the only implicit conversions that happen are promotions, i.e. representation changes that don't change values, like float -> double, int -> larger int, int -> double (where no rounding occurs), etc. AFAICT this is a pretty sane model.

ParetoOptimal 4y ago

> None of this matters most of the time, but yeah it's still funny. Implicit type coercion doesn't matter most of the time? You don't often have bugs because of it?

sublinear 4y ago
In the browser all user input, API responses, and application state is validated and sanitized before it ever gets to the application logic. On the backend all requests and database values are similarly validated and sanitized before any logic occurs. Anything less is bad code regardless of what languages are used.
- kerkeslager 4y ago
  > In the browser all user input, API responses, and application state is validated and sanitized before it ever gets to the application logic. Good thing there are never any bugs in validation and sanitization code!
  - sublinear 4y ago
    You shouldn't roll your own for this. From what I've had to do web-wise, here's a few tools. First, for the APIs, you need documentation: https://swagger.io/ https://swagger.io/ From which you can generate JSON schemas and use those to validate in the browser and on the backend. https://www.npmjs.com/package/jsonschema https://www.npmjs.com/package/jsonschema As well you should be writing a few more schemas for your application state and leverage the regex validation of your input components... Speaking of which, you also need to sanitize out some potentially nasty input. https://www.npmjs.com/package/dompurify https://www.npmjs.com/package/dompurify Obviously this isn't everything and not perfect, but a lot of this tedium can be automated away if you have a few good examples of the happy path and some basic tests in place to prevent quick and dirty changes from poking holes in these layers.
  - jeffhuys 4y ago
    Sigh. I hate this type of "conversation". Go back to reddit.

cmrdporcupine 4y ago

It's not just implicit conversions. It's misuse of operators, too. Using the '+' operator string append is the kind of thing that language designers get initially seduced by ("it just makes sense" "so convenient" "neat") but the reality is that combined with implicit type coercions it's just a recipe for exotic and unexpected behaviours. Precedence rules and expectations for 'string append' vs 'add numbers' is different. And then if you through in 'multiplication = repeat.' It's ... now you have this Wat-talk video (which is a classic which I always share with people when the topic of this comes up.) Maybe I'm just getting stuffy as I get old, but the older I get the more .. explicit.. I want my PL semantics to be.