Unwanted Surprises

Dear KV,

A recent small project at work required me to use JavaScript, and I was surprised to find the following note in the documentation (see https://bit.ly/3Bz3hC0) for a code that sets a timeout: “Also note that if the value isn’t a number, implicit type coercion is silently done on the value to convert it to a number—which can lead to unexpected and surprising results; see Non-number delay values are silently coerced into numbers for an example.”

It is commonly accepted that languages like JavaScript and others will do duck typing, where a type is implied, but this seems to have gone a bit further, coercing any input into a number. My code does not allow user input to go into the timeout routine, so I am not upset, but that bit of doc gave me pause. I just cannot imagine a good reason to do what that does.

Coerced

Dear Coerced,

At least they tell you the results can be surprising, and everyone likes surprises, don’t they?

Like you, KV is at a loss to understand how this type of coercion is anything like duck typing. Just to be sure, I went to find the documentation you mentioned, and what caught my eye was this: “The time, in milliseconds, that the timer should wait before the specified function or code is executed. If this parameter is omitted, a value of 0 is used, meaning execute “immediately,” or more accurately, during the next event cycle.”

Now, we know that the argument expected is a time, in milliseconds, and I don’t know about you, but I have never seen such a time expressed as anything but an integer number—you know, like 42. Why would anyone supply anything but a number? It turns out that JavaScript passes a lot of strings around, or so one might think from reading this hilarious documentation. It turns out that the string “1000” is the same as the number 1000, which is a helpful bit of coercion, but the string “1 second” gets converted to 0, because … well, just because.

It seems to me, and perhaps to you as well, that there really ought to be an error flagged at this point. If you want a number and you get a string, then say so, rather than just “trying to do the right thing,” especially if the results of getting it wrong can be surprising. KV does not like surprises, and really hates them in his code.

An extra funny part of this API is, as you point out, what might happen if it took user input. Imagine a banking website that let you tell it how long you wanted to wait for a call back from an agent, and it had this joke of an API behind an input box. How many people would write “1 second” or “1 minute” or some other value that was going to be coerced to 0?

There is the higher-order question of whether or not loosely typed languages with coercion are really a good idea in the first place. If you don’t know what you’re operating on, or what the expected output range might be, then maybe you ought not to be operating on that data in the first place. But now these languages have gotten into the wild and we will never be able to hunt them down and kill them soon enough for my liking, or for the greater good.

The only recourse we have now is to put our own protections around such APIs and make sure we know what we’re passing through, before we wind up on the wrong side of a coercion.

KV

Related articles

Kode Vicious
The Elephant in the Room
https://queue.acm.org/detail.cfm?id=3570921

Thou Shalt Not Depend on Me
Tobias Lauinger, Abdelberi Chaabane, and Christo B. Wilson
https://queue.acm.org/detail.cfm?id=3205288

Dismantling the Barriers to Entry
Rich Harris
https://queue.acm.org/detail.cfm?id=2790378