Many people have no interest in being computer scientists. They want to learn enough software engineering to get something done using a computer. Outside of CS, programming is only a means to an end.
Higher level languages ought not to expose the user/programmer to this sort of thing, even at the expense of performance; for every 'why is it that...' question, there are probably several more buggy programs being used in production environments. Also, it's a confusing distraction for kids trying to learn programming, who may not be able to wrap their heads around the theory of FP implementation, although they may be quite competent to handle the task they're trying to implement in software.
I used to work with a Motorola 56k series DSP, so named because it offers up to 56 bits of integer precision. Dealing with data that's usually represented as gloating point involves a normalization conversion as you describe for the currency unit which soon becomes second nature. But for newcomers to the platform, that step at first seems like an inefficient limitation, adding complexity to an otherwise simple algorithm. Not everybody wants or needs to know how the underlying hardware works, often they just want to implement some fairly trivial math or logic without worrying about accuracy.
I can't bring myself to correct that spelling error :)
There's a ton of stuff on similar level that does matter and it adds up.
Phenomena like knowing O(n) of basic algorithms and data structures. Understanding basic file formats and how they are implemented. Basic knowledge of network protocols and their building blocks. Basic knowledge of assembler. Understanding how IO happens and how your use case is bound (IO or CPU). Knowledge of character code pages, etc.
Nothing of the above is necessary to program in high level language. But if you want to do it well they can't possibly harm you. Or you will get involved with a vendor product that was written by someone who didn't know the above and you will be forced to reverse engineer the goddamn thing just to get your job done. :)
I totally agree where full-time development is concerned. And it's the sort of thing macro languages and so on tend to build in.
There are lot of people that might need to do a bit more programming - more elaborate than what a spreadsheet easily allows, but which doesn't justify becoming/hiring a pro. I was surprised to find last year that there are programming languages designed specifically for knitting, for example.
Many people have no interest in being computer scientists. They want to learn enough software engineering to get something done using a computer. Outside of CS, programming is only a means to an end.
Higher level languages ought not to expose the user/programmer to this sort of thing, even at the expense of performance; for every 'why is it that...' question, there are probably several more buggy programs being used in production environments. Also, it's a confusing distraction for kids trying to learn programming, who may not be able to wrap their heads around the theory of FP implementation, although they may be quite competent to handle the task they're trying to implement in software.
I used to work with a Motorola 56k series DSP, so named because it offers up to 56 bits of integer precision. Dealing with data that's usually represented as gloating point involves a normalization conversion as you describe for the currency unit which soon becomes second nature. But for newcomers to the platform, that step at first seems like an inefficient limitation, adding complexity to an otherwise simple algorithm. Not everybody wants or needs to know how the underlying hardware works, often they just want to implement some fairly trivial math or logic without worrying about accuracy.
I can't bring myself to correct that spelling error :)