Hacker News new | ask | show | jobs
by teux 1299 days ago
Makes sense, and I guess it’s semantics, but if the language/interpreter is handling which numeric types to use for me, should it really be sold as “strongly typed” in the main tagline for the language?

Internally, float and int are completely different types, 2’s compliment vs ieee754. Conglomerating them to a “number” feels like weak typing.

(Disclaimer: I’m a grumpy C++ engineer.)

Edit: it does look like a neat/useable language though!

3 comments

Typing is technically a distinct concept from binary representation, it just happens to be a very useful concept for interpreting bits. If the set of valid operations is known at compile time with no exceptions, I'd call that strong typing regardless of whether the internal representation changes during execution.

The problem I do see with combining int and float is that it means that you always have to be careful with == on any pair of numbers, where a language that does distinguish between the two gives you a clue about when equality will work and when it won't.

But that's a flaw in the number type, not a weakness in the type system.

I will be interesting to see how this combined number data type plays with the Zig/CPP/C interop feature: https://github.com/buzz-language/buzz#call-czig-code
Thanks, yeah that makes a lot of sense. I do tend to conflate the two concepts.
Those are representations, not types. I think they are using the "what can I do with this" definition of type, which is just its public API, and nominality (walks like a duck, quacks like a duck, doesn't mean it's a duck)
They are not ducks, they are two different animals, even if you disregard binary representation.
It may be strong typing, and there are just no ints. This is how JavaScript works: all numbers are f64.
Then what is: 1 << 33
Hmm... it's 2. It seems that the bitwise operators do indeed convert numbers into 32 bit integers (truncating any decimal parts) before applying their operation.