Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stranger Things, JavaScript Edition

livecodestream.dev

Post reply on HN
Print view View original

41–50 of 58 posts

Re: Stranger Things, JavaScript Edition

#41

Post by tempodox »

sproketboy wrote: post #16

" ['1', '7', '11'].map(parseInt); For what you would expect the output to be: [1, 7, 11] However, things get a bit off here, and the actual result is: [1,NaN,3] At first, this may look up very weird, but it actually has an elegant explanation. " The elegant explanation is that JavaScript was taken over by psychopaths like bajcmartinez. JavaScript is fine for button onClick code. Outside of that it's garbage.

You can criticize the language to your heart's content but calling people names makes you look really bad.

Re: Stranger Things, JavaScript Edition

#42

Post by janpot »

I tend to avoid parseInt unless I explicitly need a specific radix. I find the Number function much more reliable in parsing numbers.

    ['1', '7', '11'].map(Number)
And if I explicitly need integers I can always filter the result

    ['1', '7', '11'].map(Number).filter(Number.isInteger)
It also doesn't silently parse '123thisisnotanumber' or `0x11`

Re: Stranger Things, JavaScript Edition

#43

Post by golergka »

jdlshore wrote: post #9

This code snippets are the JavaScript equivalent of the Obsfucated C contest: amusing for insiders, a source of smug satisfaction for language warriors, and ultimately of no consequence to day-to-day practitioners. There is a relatively small list of "gotchas" in JavaScript that stem from the early days of the language. They are easily avoided. Use a linter, "use strict," use ===, and be explicit about your type conv…

> easily avoided

Not always. Don't forget about this, arrow functions and the fact that popular mocking frameworks can automatically mock regular class methods but not arrow methods.

Re: Stranger Things, JavaScript Edition

#44

Post by decentralised »

sproketboy wrote: post #16

" ['1', '7', '11'].map(parseInt); For what you would expect the output to be: [1, 7, 11] However, things get a bit off here, and the actual result is: [1,NaN,3] At first, this may look up very weird, but it actually has an elegant explanation. " The elegant explanation is that JavaScript was taken over by psychopaths like bajcmartinez. JavaScript is fine for button onClick code. Outside of that it's garbage.

I think the parseInt example is more of a gotcha of point-free syntax. Normally it would be written as ['1','7','11'].map(e => parseInt(e))

Re: Stranger Things, JavaScript Edition

#45

Post by number6 »

LandR wrote: post #4

This article is written like these flaws in javascript are just a quirky feature. No, they are an embarrassment. They don't make the language cool or interesting, they aren't tricks. They are logically incoherent nonsense.

The cooles trick in JS is that they fixed the off-by-one error using dates. Since Month are stored in an array the 5th month is... April! How did all other Languages get this one wrong? I don't know. That's the stuff that makes JS cool and interesting!

Re: Stranger Things, JavaScript Edition

#46

Post by enobrev »

The solution to Scenario #1 is still going to break. As far as I'm concerned, if you're using parseInt, you MUST explicitly define the radix. Not doing so Will absolutely bite you in the ass.

In some cases, the parseInt rules go sideways when your number string starts with a 0 (zero). That's going to be a rare occurrence that happens months after you write this code, works just fine on your machine, and is going to take days to find.

Per MDN [1]:

If radix is undefined, 0, or unspecified, JavaScript assumes the following:

1. If the input string begins with "0x" or "0X" (a zero, followed by lowercase or uppercase X), radix is assumed to be 16 and the rest of the string is parsed as a hexidecimal number.

2. If the input string begins with "0" (a zero), radix is assumed to be 8 (octal) or 10 (decimal). Exactly which radix is chosen is implementation-dependent. ECMAScript 5 clarifies that 10 (decimal) should be used, but not all browsers support this yet. For this reason, always specify a radix when using parseInt.

3. If the input string begins with any other value, the radix is 10 (decimal).

1: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: Stranger Things, JavaScript Edition

#47

Post by bajcmartinez »

zdragnar wrote: post #23
sproketboy wrote: post #16

" ['1', '7', '11'].map(parseInt); For what you would expect the output to be: [1, 7, 11] However, things get a bit off here, and the actual result is: [1,NaN,3] At first, this may look up very weird, but it actually has an elegant explanation. " The elegant explanation is that JavaScript was taken over by psychopaths like bajcmartinez. JavaScript is fine for button onClick code. Outside of that it's garbage.

parseInt has an optional second argument. map provides two arguments. Why is this an example of psychopathic design?

it's just something unexpected that can happen because of the way you can pass functions as callbacks. I liked this example because the result looks really weird, and it can really happen to anyone, it's a mistake you can easily make and can go unnoticed.

Re: Stranger Things, JavaScript Edition

#48

Post by masswerk »

tempodox wrote: post #39
josefx wrote: post #38

Earlier quoted context omitted.

If that is a combination of octal and decimal how is 058 not a parser error?

`072` is interpreted as octal, and `058` is interpreted as decimal (7·8+2 = 58). Ah, the dumpster fire that is JavaScript.

Prefixing octal numbers by zero was a common convention. The real dumpster fire was all those intermediate years without an octal notation in strict mode. (If you needed them, either forget strict mode, or choose between converting to meaningless decimals or using strings and feeding them through parseInt. What's sane about this?)

However, 058 should have been a parse error.

Re: Stranger Things, JavaScript Edition

#49

Post by sergeykish »

SimeVidas wrote: post #13
gitgud wrote: post #12

Common confusion has to do with how JS overloads the "+" operator. '9' + 1 = "91" +'9' + 1 = 10 It's all very weird though...

What would you expect string + number to do?

ruby

    >> +"2"
    => "2"
    >> "2" + 1
    TypeError (no implicit conversion of Integer into String)
python

    >>> +"2"
    TypeError: bad operand type for unary +: 'str'
    >>> "2" + 1
    TypeError: can only concatenate str (not "int") to str
lua

    > +"2"
    stdin:1: unexpected symbol near '+'
    > "2" + 1
    3.0

Re: Stranger Things, JavaScript Edition

#50

Post by sergeykish »

erik_seaberg wrote: post #25
weare138 wrote: post #21

Earlier quoted context omitted.

Kind of depends on the language. Perl converts the string to an integer if you use a math operator on a numeric string. Python just throws an error.

When I want either addition or string concatenation, I know it, I can't think of a use case where I'm happy getting either randomly. Perl got this right: 2 + 2 == 4 2 . 2 eq 22 You can even declare that failed conversions should throw: use warnings FATAL => qw(numeric)

Yes, perl is consistent

perl

    print "2" + 1
    3
    print "2" - 1
    1
js

    > "2" + 1
    "21"
    > "2" - 1
    1
Post reply on HN