I do not like it as a design choice, but there are many languages with a dynamic number type like this, and it does not matter for most use of the language.
Ironically, it is heavily optimized in spite of this. For example, JS arrays are sparse, but runtimes like V8 optimize them to be packed, if possible (if the array contains only integer indices and no holes). Integers also stay integers, if the runtime is fairly confident that they won't suddenly become floats. Moreover, if the runtime finds out that some JS objects don't change their shape (i.e. have the same properties and their inferred types), their relative addresses are cached, so the runtime doesn't need to look them up every single time.
What does it matter if it performs well or not, when it doesn't even have separate types for an integer and a float.
I do not like it as a design choice, but there are many languages with a dynamic number type like this, and it does not matter for most use of the language.
That's true, but it does matter for medical equipment, which the op mentioned.
deleted by creator
Ironically, it is heavily optimized in spite of this. For example, JS arrays are sparse, but runtimes like V8 optimize them to be packed, if possible (if the array contains only integer indices and no holes). Integers also stay integers, if the runtime is fairly confident that they won't suddenly become floats. Moreover, if the runtime finds out that some JS objects don't change their shape (i.e. have the same properties and their inferred types), their relative addresses are cached, so the runtime doesn't need to look them up every single time.
deleted by creator
ah man that makes me uncomfortable