If you are using "beginner" to refer to the time spent, this is true.
However, if you use "beginner" to the knowledge gained, it might not be. If you only ever make webpages, even if you have made 100s you could still be a novice programmer because you never branched out enough to learn new programming concepts.
If a programming language makes it easy to do something moderately, but it is hard to do it well. Programmers who only know that language are likely to have a gap in their stills. Floating point (in most languages) is easy to gets the basics working, but are hard to do well and very hard to do perfectly. This leads to a lot of programmers not learning floating point well.
General purpose programming languages are complex tools.
In this specific case representing non-integer numbers effectively on a binary device is complex. If you use a different representation than IEEE floats you just give a different set of corner cases and unexpected outcomes.
Don't let a novice build software you need to be correct without supervision, and if you are a novice expect to make mistakes, just like if I were to build a website I wouldn't expect my style choices to render appropriately on a wide range of devices... that's complex too!
Whether or not that's true, you can remove "beginning" from my statement as it's not necessary (done, just edited, thanks): most programmers, most of the time, don't need the speed of floating-point everywhere (compared to fixed-point/scaled integers, or rationals, or interval arithmetic, or whatever), and when they do, the language could let them easily opt into it with a declaration like "use float" or whatever.
Every option here has tradeoffs and drawbacks: fixed point arithmetic suffers from a very limited precision range, rationals aren't even the same number set, cauchy sequences are precise but comparatively very slow… there's no one size fits all solution that's right in every circumstance.
Except, of course, at lower levels of abstraction - where IEEE floats are what the hardware implements. Lower level languages use 8-, 16-, 32-bit integers, they use IEEE floats and doubles, and they make these choices for pretty solid reasons.
Higher level languages make different choices (arbitrary precision integers are common in interpreted languages, eg). Libraries support all kinds of options up and down the stack.
Of course, but low-level languages call their floats...floats. Certain higher-level languages often call them numbers or decimals, which is why this confusion happens in the first place. It's like if a language had uint8 but called it Integer - yes, there are many uses for uint8, but there are also many cades where it's the wrong thing to use and it shouldn't be possible to use it accidentally.
In what way are rationals not the same number set? In the strictest sense basically none of the proposed versions have the same number set, but in a broad sense, they all represent a useful subset of rationals, right?
Could you elaborate what your intended meaning was? It felt to me like you were singeling out 'rationals' as not being the same number set. Maybe we also think of something different when talking about 'rationals'?
Maybe I also missed something obvious, so I'd like to satisfy my curiosity!
I meant that rationals are a subset of the reals, and while floats are also a subset of exact reals a "typical" fixed bitwidth implementation will have a significantly greater range in floats than rationals.
I don't know that it's necessarily as significant a difference as I'd first considered it to be, though.
Agree. But experts/intermediates often gloss over language semantics in pursuit if getting something done. For me, floating point by-default is more often a nuisance
That doesn't really matter. Even if you had 20 years of experience in C++ or whatever, you could confidently write JavaScript code with floating point bugs in it, because "the type is called Number, obviously that isn't floating point". Beginner programmers might actually realise this sooner, since veterans aren't going to be writing console.log(0.3+0.2) as part of learning the language.
- An experienced programmer would know that IEEE FP hardware is ubiquitous. Why would a language eschew that hardware capability by default? If anything, I would assume that any unfamiliar general-purpose language DOES start from that point (using IEEE float to represent non-integer numbers) because of historical precedent.
- "Number" is about as vague as you can get for a type name. Maybe personal bias here, but I find that vagueness invites research up front. "Time to read the documentation."
(I still expect a language newbie to get various bugs in new Javascript code, because the footguns in that language differ from the footguns in something like C++.)
Should we really optimize for someone writing in a new language without reading anything about it? Like, if he/she doesn’t even know that js numbers are floats, just don’t even let them close to a program.
However, if you use "beginner" to the knowledge gained, it might not be. If you only ever make webpages, even if you have made 100s you could still be a novice programmer because you never branched out enough to learn new programming concepts.
If a programming language makes it easy to do something moderately, but it is hard to do it well. Programmers who only know that language are likely to have a gap in their stills. Floating point (in most languages) is easy to gets the basics working, but are hard to do well and very hard to do perfectly. This leads to a lot of programmers not learning floating point well.