Hacker News Reader

Comment by umvi | Hacker News Reader

TIL JavaScipt doesn't have an integer type and uses double under the hood to store integers. Yet another footgun to add to the massive stack.

View on HN

JavaScript also has newish BigInt support: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe.... It even has syntax: 42n.

Given that it's a dynamic scripting language, I think double was the best choice they could have made. It gives serious number crunching performance, an integer range up to 2^53, and, of course, double precision floating point math. The only better choice they could have made would have been to make it static/strongly typed with various numeric types.

Not quite true. They do use an integer data representation if the number is an integer, it just silently changes to a float if its necessary. So `let x = 2;` the type would be 'number' but the data would just be an integer.

That’s an implementation detail.

JavaScript, the language, doesn’t (AFAIK; I don’t keep track of this rapidly moving target) have integers (but does have integer arrays, nowadays. See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Type...)

If the type were integer,

  let x = 2
  let y = x / 8

would have y = 0, but its value will be 0.25.

That's perfectly reasonable; there's nothing to say that `/` has type `int -> int -> int` even in a strongly-typed language. I wouldn't bat an eyelid to discover that `/` had type `int -> int -> float` in any language. The problem is when you discover that `+` does not have type `int -> int -> int` (e.g. when you try and increment a very large integer and floating point stops being able to represent it).

> I wouldn't bat an eyelid to discover that `/` had type `int -> int -> float`

I'd bat both eyelids, that's the kind of surprising design decision that would turn me away from a language. To my knowledge, no major programming language does this, and there's wisdom in the principle of least surprise.

edit: I am of course mistaken, Python does exactly this. Corrected by chrisseaton again!

> I'd bat both eyelids, that's the kind of surprising design decision that would turn me away from a language. To my knowledge, no major programming language does this, and there's wisdom in the principle of least surprise.

Lol prepare to bat your eyelids.

    % python
    Python 3.8.5 (default, Jul 21 2020, 10:48:26) 
    [Clang 11.0.3 (clang-1103.0.32.62)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> 1 / 2
    0.5

I'll bat my eyelids, but only after I kick myself ;-P

If you're up for a game of No True Scotsman, can you name me a statically typed language that does the same?

Visual basic

I don't think so. According to this, in Visual Basic, the '/' operator isn't defined for integer types.

https://docs.microsoft.com/en-us/dotnet/visual-basic/languag...

Integers are right there in the table on the page you're linking to.

If you don't believe me, perhaps you'll believe output from the machine.

https://tio.run/##K0vSTc4vSv3/3zc/pTQnVcEjNScnn4szuDRJwTcxM0...

* edited for guideline compliance

Looks like you're right. In my defense the page I linked states that The / operator is defined only for the Decimal, Single, and Double data types. I suppose it accepts integer types by means of 'widening'?

> Did you read it?

The HN guidelines ask that you don't do that.

I've edited my comment for guideline compliance.

I don't think it settles anything, but a trivial function that divides two integers and returns the result compiles to this:

  IL_0000:  ldarg.1     
  IL_0001:  conv.r8     
  IL_0002:  ldarg.2     
  IL_0003:  conv.r8     
  IL_0004:  div         
  IL_0005:  ret

conv.r8 is an explicit conversion to double precision float in the target language, MSIL.

I was already convinced by your earlier tio.run example, but I'm still a bit baffled by the page saying The / operator is defined only for the Decimal, Single, and Double data types.

Nim https://play.nim-lang.org/#ix=2zbk

Interesting, thanks. I see Nim uses '/%' for integer division. [0] I can't say I like that decision.

[0] https://nim-lang.org/docs/manual.html#types-preminusdefined-...

Unsigned integer division. In practice I haven’t seen this operator used anywhere yet.

Have I gone mad? (EDIT: it appears I have.)

```

GHCi, version 8.6.5: http://www.haskell.org/ghc/ :? for help

Prelude> 1 / 2

0.5

```

This is because 1 and 2 are polymorphic and get instantiated to floats here. Witchcraft.

I think you're still right though. I know Haskell has an unusual approach to numbers, but it looks like the resultant type is indeed different from the type of the operands. I got this from typeOf (/):

    Note: there are several potential instances:
    instance RealFloat a => Fractional (Complex a)
    -- Defined in ‘Data.Complex’
    instance HasResolution a => Fractional (Data.Fixed.Fixed a)
    -- Defined in ‘Data.Fixed’
    instance Integral a => Fractional (Ratio a)
    -- Defined in ‘GHC.Real’
    ...plus two others

There are many instances for Fractional, but the resultant type of the (/) operator is always the same as the operands:

    GHCI> :i (/)
    class Num a => Fractional a where
      (/) :: a -> a -> a
      ...
            -- Defined in ‘GHC.Real’
    infixl 7 /

The key is that integer types aren't Fractional, so the Haskell 2010 defaulting rules[1] cause the literals to be interpreted as Double. With an appropriate default declaration GHC could have picked Ratio Integer, Complex Double, etc. instead, but without one Integer and Double are the only options and Integer wouldn't satisfy the constraints.

[1] https://www.haskell.org/onlinereport/haskell2010/haskellch4....

Julia? There's an integer division operator, but the default is... More complex:

https://docs.julialang.org/en/v1/manual/integers-and-floatin...

Python2 did it the other way, wasnt it?

(/ 1 2) #=> 1/2 Clojure as well, though it's a rational not a float.

Interesting, thanks

Double represents consecutive integers up to 2^53 - that's even larger than Java's int so it's more than fine for almost all purposes.

I can't help but compare JS to python though. For every footgun in JS, the same footgun does not exist in python including this one.

Interesting - I view it the opposite way. In JavaScript, you need to know the details of exactly one numeric type: the regular, standard IEEE 754 float that's used by Java, Python, C++ (generally), and every other programming language under the sun. That's it! There is only one way to do it ;)

These days, if you need huge integers, you can use BigInt, but if you want to use it in an expression that also contains floating point values, then you need to explicitly convert it. Explicit is better than implicit.

I just find it counter intuitive, that's all. The expectation is that high level scripting languages have BigInt enabled by default (since that's what Ruby/Python do). Not so with JS.

The expectation is that sorting an array of integers in place:

    [1,3,2,4,5,7,6,8,9,10].sort()

produces an array with the numbers in ascending order (since that's what Ruby/Python do). Not so with JS (try it out).

A agree there is a perfectly logical reason for every quirky behavior, but I've been surprised (in a bad way) so many times by JS's counter-intuitive behavior that I now have a mental collection of gotchas where JS deviates from expectation.

Consider this:

JavaScript actually has a formal specification. Ruby and Python have no formal specification. I can tell you (with reference to the specification) exactly what a JavaScript program does. JavaScript may seem wacky on the surface, but actually it's all worked out. Nobody can tell you what a Ruby or Python program does.

And you think JavaScript is the footgun?

Well yes, in theory if all the developers read JS's formal specification JS would be better. But in practice developers just wing it without reading anything, and only go to read things when getting an unexpected result. And so we get the follow outcome - python behaves as expected in more cases than JS behaves as expected.

"Theory is great in theory, but in practice, practice is better"

I mean, if you define "whatever Ruby and Python do" to be intuitive, then, sure, every other language is going to have "a long list of weird footguns".

JS has many quirks, but I like that the numeric representation is extremely simple and explicit (even compared to Python).

That's a problem with the specification of sort, not with javascript using double by default. But yeah, that sort example is seriously bonkers.

Array.sort converts to UTF-16 code units, or some such weirdness, by default. If you are sorting anything other than strings, you will want to pass in a comparison function.

[1,3,2,4,5,7,8,9,10].sort((a,b) => a - b) gives you the behavior one would expect.

I suppose you already know that, though. Agreed there are lots of quirks.

Except it also has bitwise operators which is definitely weird.

And those bitwise operators are defined to convert the number into a 32-bit signed integer as part of the process. Which is why foo | 0 is a way of converting a number to an integer (as long as it's not too large ...).

I agree Python is the better language, but they have quite different origin stories. JavaScript was thrown together in very short order, and has gradually evolved since then. It was a good enough first-to-market scripting language for the browser, got standardised, and has been the client-side scripting language of the web ever since. It's evolved somewhat since its early days but is backward compatible.

If I understand correctly, Python had a more considered initial design, and had a clean-break overhaul in Python3, allowing it to evolve without accumulating as much cruft and inconsistency. (Python is famous for its philosophy of there should be one—and preferably only one—obvious way to do it.) People use Python by choice: unlike JavaScript where browsers support no other scripting languages, Python won out over its rivals in fair contest.

All things considered, JavaScript isn't that bad. Used correctly it can be elegant and powerful. It has some nasty dark corners, but it generally provides all you need to avoid them, if you know your way around. With modern JIT engines it can even be pretty fast. Its curious use of doubles is just the kind of thing modern JIT engines are able to be smart about, compiling down to use integer operations where possible.

Python just has its own footguns, like mutable default arguments or how lambdas close over variables in comprehensions.

While I think everyone can agree this is just yet another terrible design decision in JavaScript, at least there are libraries to give you this, and it looks like BigInt will eventually be native to JS:

https://github.com/peterolson/BigInteger.js/

> While I think everyone can agree this is just yet another terrible design decision in JavaScript

I disagree. Double was the best choice they could have made for a dynamically typed language.

Reply on news.ycombinator.com