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

Writing code for both computers and humans

tonymottaz.com

Post reply on HN
Print view View original

11–20 of 32 posts

Re: Writing code for both computers and humans

#11

Post by cxr »

stinos wrote: post #8
jinwoo68 wrote: post #3

I don't think what the author says is the intent of the code. isNaN() returns true not just for NaN but for anything that is "not a number"[1]. For example, it returns true for things like "hello". So it just canonicalizes everything that is not a number into NaN. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Funny. If this is effectively so, the code is actually fairly ok and clearly expresses the intent for humans yet the OP claiming exactly that managed to still misunderstand the code because they made up a precondition ('defaultValue is going to be a number') probably exactly because they refused to 'To answer this question, you need to start looking around for clues' so they missed the clue [1]; or maybe rather the c…

> dynamically typed so[...]

People accustomed to strongly typed languages and thinking mostly of monolithic apps always pin things on dynamic typing even where it's not the cause. It's not about dynamic typing in this case.

What's going on here is partially because of separate compilation and partially because of mobile code (as Lars Bak explains[1]). Even if developing in a strongly typed language, the machinery would still have to take care to deal with the same thing. In fact, this isn't even JS; this file is TypeScript—and this expression being strongly typed is almost certainly exactly why this code was written this way: because `useControlledState` demands it. If `useControlledState` were just vanilla JS and no one were doing typechecking during development and build, there would have been no problem with passing something else as an argument, because it will of course evaluate to NaN anyway when undergoing the number treatment.

(This is kind of subtle, but it's not that subtle. Too many people make this mistake, and there's probably something that needs to be done about that; "because dynamic languages" has become something of a thought-terminating cliché that leads people to the wrong conclusions—as demonstrated even in the interview, at the point where Bak felt prompted to point this out.)

1. Inside V8 — A Javascript Virtual Machine. Going Deep: Expert to Expert. Accessed July 3, 2020. https://channel9.msdn.com/Shows/Going+Deep/Expert-to-Expert-...>.

Re: Writing code for both computers and humans

#12

Post by jalk »

anonzzzies wrote: post #7
jinwoo68 wrote: post #3

I don't think what the author says is the intent of the code. isNaN() returns true not just for NaN but for anything that is "not a number"[1]. For example, it returns true for things like "hello". So it just canonicalizes everything that is not a number into NaN. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

This is my issue with js; isNaN looks related to NaN in a 1-1 mapping as in, testing ‘x is NaN’ but it doesn’t. So the naming is confusing as it does more than that, isNotNumeric() or so.

Seems like the author fell into this trap

Re: Writing code for both computers and humans

#13

Post by stinos »

cxr wrote: post #11
stinos wrote: post #8

Earlier quoted context omitted.

Funny. If this is effectively so, the code is actually fairly ok and clearly expresses the intent for humans yet the OP claiming exactly that managed to still misunderstand the code because they made up a precondition ('defaultValue is going to be a number') probably exactly because they refused to 'To answer this question, you need to start looking around for clues' so they missed the clue [1]; or maybe rather the c…

> dynamically typed so[...] People accustomed to strongly typed languages and thinking mostly of monolithic apps always pin things on dynamic typing even where it's not the cause. It's not about dynamic typing in this case. What's going on here is partially because of separate compilation and partially because of mobile code (as Lars Bak explains[1]). Even if developing in a strongly typed language, the machinery wou…

Funny. Seems I fell into the same trap I just sketched, making wrong assumptions because of not looking around in the code. But to be honest from your explanation I still cannot tell whether I merely used incorrect terminology wrt dynamic typing (but the general principle still holding) or whether this code guarantees that defaultValue is in fact always a numeric type?

Re: Writing code for both computers and humans

#14

Post by cxr »

cxr wrote: post #11
stinos wrote: post #8

Earlier quoted context omitted.

Funny. If this is effectively so, the code is actually fairly ok and clearly expresses the intent for humans yet the OP claiming exactly that managed to still misunderstand the code because they made up a precondition ('defaultValue is going to be a number') probably exactly because they refused to 'To answer this question, you need to start looking around for clues' so they missed the clue [1]; or maybe rather the c…

> dynamically typed so[...] People accustomed to strongly typed languages and thinking mostly of monolithic apps always pin things on dynamic typing even where it's not the cause. It's not about dynamic typing in this case. What's going on here is partially because of separate compilation and partially because of mobile code (as Lars Bak explains[1]). Even if developing in a strongly typed language, the machinery wou…

PS: Gilad Bracha makes a similar point in this interview about pluggable types:

Newspeak and Pluggable Types. Software Engineering Radio. IEEE Computer Society. https://www.se-radio.net/2009/07/episode-140-newspeak-and-pl...>.

Re: Writing code for both computers and humans

#15

Post by lordwiz »

This communicates an important idea, Well-written code is not only correct and efficient, but it is also readable, maintainable, and understandable to other programmers.

This culture should be encouraged more to make other developer's life easier, The thing I do nowadays is that I would often switch perspectives now and then, When switching perspectives, if i become confused, i would work on making the code more meaningful.

Even if we are doing a solo project, if we come back to the code after a long while, the code should be greeting us with wide open hands rather than looking like an unexplored jungle.

Re: Writing code for both computers and humans

#16

Post by cxr »

stinos wrote: post #13
cxr wrote: post #11

Earlier quoted context omitted.

> dynamically typed so[...] People accustomed to strongly typed languages and thinking mostly of monolithic apps always pin things on dynamic typing even where it's not the cause. It's not about dynamic typing in this case. What's going on here is partially because of separate compilation and partially because of mobile code (as Lars Bak explains[1]). Even if developing in a strongly typed language, the machinery wou…

Funny. Seems I fell into the same trap I just sketched, making wrong assumptions because of not looking around in the code. But to be honest from your explanation I still cannot tell whether I merely used incorrect terminology wrt dynamic typing (but the general principle still holding) or whether this code guarantees that defaultValue is in fact always a numeric type?

This code doesn't. It guarantees that within `useControlledState`[1], `defaultValue` is either NaN, an actual number, a number-like string, or something else that can be coerced into one[2]. If `defaultValue` is, for example, `true` or even an empty array, then the result of the expression `isNaN(defaultValue) ? NaN : defaultValue` will pass through `true` or the empty array.

1. https://github.com/adobe/react-spectrum/blob/main/packages/%...>

2. whether one of those non-numbers is prevented from actually making an appearance at this point for other _reasons_ is a different question, but the fact remains that one making its way through is not something that would be stopped from proceeding further by the isNaN check here

(Addendum to, I hope, clarify: I'll reiterate that it's the type annotations on the `useControlledState` call site parameterized as `useControlledState` (and the TypeScript team's decision to type `isNaN` to take only parameters with a number type) that "guarantees" `defaultValue` is a number. But that guarantee is a soft one, i.e. not a guarantee at all, precisely because of mobile code and separate compilation; I can contrive a project right now that uses the Adobe Spectrum library and pass whatever I want to it—it's not like the Adobe devs' compilers are going to be able to stop me.)

Re: Writing code for both computers and humans

#17

Post by carapace »

earthboundkid wrote: post #6
HuangYuSan wrote: post #4

Earlier quoted context omitted.

And a comment on its own would be enough anyway

Yeah, ideally you’d have some kind of static typing to restrict the code to only use Number, and then a comment that says what the function does in case of NaN.

Yeah!

There was a thread the other day about a linter that flagged useless code and all the odd bugs it caught, and I think it would have flagged this snippet, eh?

"Interesting bugs caught by no-constant-binary-expression"

https://news.ycombinator.com/item?id=38196644

https://eslint.org/blog/2022/07/interesting-bugs-caught-by-n...

Re: Writing code for both computers and humans

#18

Post by [deleted] »

cxr wrote: post #16
stinos wrote: post #13

Earlier quoted context omitted.

Funny. Seems I fell into the same trap I just sketched, making wrong assumptions because of not looking around in the code. But to be honest from your explanation I still cannot tell whether I merely used incorrect terminology wrt dynamic typing (but the general principle still holding) or whether this code guarantees that defaultValue is in fact always a numeric type?

This code doesn't. It guarantees that within `useControlledState`[1], `defaultValue` is either NaN, an actual number, a number-like string, or something else that can be coerced into one[2]. If `defaultValue` is, for example, `true` or even an empty array, then the result of the expression `isNaN(defaultValue) ? NaN : defaultValue` will pass through `true` or the empty array. 1. https://github.com/adobe/react-spectru…

[deleted]

Re: Writing code for both computers and humans

#19

Post by lo_zamoyski »

jinwoo68 wrote: post #3

I don't think what the author says is the intent of the code. isNaN() returns true not just for NaN but for anything that is "not a number"[1]. For example, it returns true for things like "hello". So it just canonicalizes everything that is not a number into NaN. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Yeah, indeed, and this makes a whole lot more sense.

I can sympathize with the argument of the OP, but I wouldn't exaggerate its profundity either. The intent was opaque enough for the OP that he got it completely wrong, and even under the OP's assumptions, the intent was still more opaque than necessary. Furthermore, you're still passing around `NaN`, which is sort of an analogue of passing around `null`. This example suggests that perhaps a better language construct ought to be used, like the `Option` type.

Re: Writing code for both computers and humans

#20

Post by layer8 »

jinwoo68 wrote: post #3

I don't think what the author says is the intent of the code. isNaN() returns true not just for NaN but for anything that is "not a number"[1]. For example, it returns true for things like "hello". So it just canonicalizes everything that is not a number into NaN. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Even if the author was right about the intent, I would disagree with them that “this is how to write code with empathy for other programmers”, because the code would just make me think “I must be missing something” (and indeed the author did miss something).

My theory, by the way, was that the expression is normalizing the possible NaN representations to a definite one, possibly to prevent transporting information via the NaN representation.

Such “what the …?” code should have a comment explaining the intent (e.g. “replace non-numeric values by NaN”). If it is used in multiple places, that’s a good opportunity to define a function for it, so the intent only needs to be documented in a single place. (In programming languages with annotations as a language construct, annotations could alternatively also be used for referencing the documentation of a coding pattern from multiple places.)

Post reply on HN