2 ms·

> It’s already suspicious by virtue of having a hand-wavy "Int" type (what size/signedness is that?) That is a common misunderstanding by people who haven’t sp

> It’s already suspicious by virtue of having a hand-wavy "Int" type (what size/signedness is that?) That is a common misunderstanding by people who haven’t spent time with high level languages. In any language more precise numeric types allows for faster arithmetic operations if used appropriately. This is the primary reason Java is still a few times faster than JavaScript when comparing application benchmarks focusing on arithmetic and why those performance differences drop considerably when comparing non-arithmetic operations. The lower level the language is, closer to the metal, the more important these performance cases matter. This is also acceptable from a design perspective because you need to also be worried about memory management, pointer arithmetic, type conversion, and various other low level concerns anyways. The whole point of a high level language is to not worry about those things. The compiler/interpreter does that heavy lifting. For example Java and C# are both garbage collected so you, by default, don’t get a say in memory management. If you wanted that control then just use C++. A major pain point in Java is conversion of numeric types. JavaScript only has one numeric type, that is really shitty in all respects, and writing numeric operations in JavaScript is so much cleaner and more fluid in the code.

scoutt 6y ago
This is correct, and applies (and is helpful) to many cases. But the moment you need to shift an "Int", or do bitwise operations or transmit it in a network packet (think about endianness, etc.), is the moment you may regret that the compiler is doing too much heavy-lifting for you.
- a1369209993 6y ago
  If it actually is a unlimited-width integer, bit logic/shifting can work fine, and network packets have to be x&0xFF,x>>8&0xFF,etc anyway. But that's painful for direct translation to machine code (what happens when I try to return 340'282'366'920'938'463'463'374'607'431'768'211'456 from a function?), so either it's secretly a fixed-width integer (and they're being deliberately vague about what width, which is suspicious), or the language defaults to possibly allocating memory (and possibly getting a OOM error) on every single arithmetic operation, which is a catastrophically undesirable property in a systems programming language.

scoutt 6y ago

This is correct, and applies (and is helpful) to many cases. But the moment you need to shift an "Int", or do bitwise operations or transmit it in a network packet (think about endianness, etc.), is the moment you may regret that the compiler is doing too much heavy-lifting for you.

a1369209993 6y ago
If it actually is a unlimited-width integer, bit logic/shifting can work fine, and network packets have to be x&0xFF,x>>8&0xFF,etc anyway. But that's painful for direct translation to machine code (what happens when I try to return 340'282'366'920'938'463'463'374'607'431'768'211'456 from a function?), so either it's secretly a fixed-width integer (and they're being deliberately vague about what width, which is suspicious), or the language defaults to possibly allocating memory (and possibly getting a OOM error) on every single arithmetic operation, which is a catastrophically undesirable property in a systems programming language.