Integer Division has no Integrity

Quick question: In the programming language of your choice, what is -7/2 ?
Depending on your training in that programming language, that answer might surprise you or not; but if you have a somewhat mathematically inclined brain, the answer might irritate you.

If your answer is anything other than the following, you might really consider switching, but I imagine, it’s one of these:

  • -3 (as integer or as untyped constant like in Go)
  • -4 (as integer)
  • -3.5 (as float or similar)
  • -7/2 (as rational type like in very mathematically inclined languages)

My Point is: “-7/2” in itself is not a legal entity with a “have you read the fine print” character; its nature is very clear and widely understood.
As in: You eat the half of each of the seven cakes in your overly giant fridge and then need to explain your theory of mental sanity to your significant other. Common scenario.

Now if you have been programming for too long, it might be tempting to rationalize: a division operation on two integers must also be an integer, for consistency reasons or the likes. This doesn’t hold, though, as:

a) it’s fundamentally wrong™, because integer numbers are a Ring, not a Field:
They are not closed under the operation of division.
b) that would violate the Principle of Least Astonishment, as integer data types are modeled after integer numbers in the real world; natural Mathematics is the domain-specific language to which your code has to adjust in order to qualify for Clean Code.

Now, (b) comes with the caveat that the real -3.5 is a real number and floating-point arithmetics like IEEE 754 cannot exactly resemble that, so unless you really do rational 7/2 arithmetics like e.g. in Lisp or Clojure, the deviation is still there; but this is the difference between some stolen finger tips of buttercream and half a cake, so this is no joke.

My point overall is, that if cleanliness and understandability is one of your goals, you should at least think about what your code is doing and whether most of any possible readers have the exact same model in their mind than you do;
if they do, just write the shortest way possible, if they might not, an additional cast / rounding operation might ground their expectations.

And speaking of resembling the real-world mathematics, I am not even sure whether the rounding convention for negative numbers is taught consistently throughout the world; our school back then went with “round away from zero”, i.e. -7/2 would become -4, which is rather seldom found (quick search tells me: Python 2 or Ruby. Truncating to -3 is cheaper on the hardware, I suppose.
I will now resist the investigation between rigid definition vs. cultural contract.

Anyway. Enjoy your cake 🙂

Unexpected: Web Sockets close when downloading a file

The browsers work in mysterious ways.

That is, mostly they have certain reasons for behaving why they do, but because so many details are too sophisticated as to have been explicitly defined in some specification (…yet).

Recently, we came across a new problem that was surprisingly non-googleable.

Many of our interactive Web GUIs are based on Web Sockets for real-time updates. As is usual. Now, one live system showed a strange effect, because our Web Socket always broke down when the user clicked on a <a>...</a> link to download a file.

This was strange for multiple reasons, but it boiled down to:

  • It happened under the current Firefox, but not under Chrome
  • It happened not when the link had target = "_blank" (i.e. the link was opening in a new window)
  • The Web Socket closed with the “going away” status code 1001, indicating no further error

And to boil it further down, the solution was to definitely include the download attribute for this particular <a> Element.

The web socket stayed open for both browsers in both of these cases:

<a href="..." target="_blank" rel="noopener noreferrer">
  This leaves the Web Socket intact
</a>

<a href="..." download>
  This also leaves the Web Socket intact
</a>

<a href="...">
  This might close the Web Socket, or not, just as the browser feels today
</a>

(For the rel="noopener noreferrer", see also here.)

The data from the href endpoint was served with the corresponding Content-Disposition and Content-Type HTTP headers. For Chrome, this is enough to identify that link as a download. Firefox was not so sure, it believes that you are actually “going away”.