Even if this gets nicely marketed and gains a decent amount of traction into the current eBook user market, what will this do to make people want eBooks?
Its not designed to make people want eBooks.
Its designed to provide an alternative existing ebook distributors to increase the share of sales revenue that the publishers of (dying) print periodicals can extract from sales of electronic editions, and to increase the advertising sales that can be realized by those same publishers. One of the big things they trumpet about it is how attractive their platform will be for advertising.
Broadening the ebook market isn't their intent.
However, I'd like to assert that what REALLY drives magazine sales are super catchy headlines and pictures relevant to our interests.
And, no doubt, in addition to being a platform for outside advertisers, their reader will tightly integrate cross-promotional advertising (no doubt, taking into account each user's reading habits to select ads) to place teaser ads for other products to promote impulse buys.
As an alternative, I think that consumers would be better served with a coalition that really investigated the sociology, psychology and technology behind what people really want in digital book readers.
For profit companies don't exist to serve consumers, they exist to serve their investors. Whose going to fund the coalition you propose?
One screen works fine for short text, like newspaper articles and such, but doesn't have the same ease of use when reading novels that are hundreds of pages long!
IME, it works okay for novels, even on the miniature, LCD (rather than eInk) screen of the iPhone. But, yeah, a bigger screen than that, or than most current ebook readers, would be nice -- and there are lots of new e-ink readers with bigger screens that are coming out.
A nice illustration or well chosen photograph can add value to an article. It can set the tone or inform in a concise way.
And epub -- which is, under the hood, basically just XHTML + a specialized adaptation of CSS + a variety of image file formats, including both bitmap (e.g., PNG) and vector (e.g., SVG) which a reader must support -- already supports illustrations and photographs, and most dead-tree newspapers don't use much color, so neither a new format nor a device with features not found in typical ebook readers -- except maybe bigger page size, but bigger paged e-ink-based readers are available -- are needed for that.
Since the whole case they make for the need for a new format and device is that eBook formats and devices like the Kindle, while good for books, aren't good for newspapers and other periodicals, because they don't precisely reproduce the print experience and layout, what is good for eBooks isn't really at issue.
Most malware now a days comes via trojans, and any OS can't protect against that unless it's totally locked down (like iPhone)
There's a middle ground that can maximize protection against trojans (of course, nothing can protect against completely unwary users), and that's using something a model where untrusted apps are (whether by running through app-specific accounts or otherwise) required to be given fairly finely grained permissions on installation before accessing resources.
While Linux distros provided somewhat more protection against users being unknowingly tricked into performing dangerous tasks by providing elegant, non-intrusive ways to provide the control users need without always running as a superuser before Windows did much in that regard, it shares with Windows a fairly all or nothing security model in many regards that is particularly susceptible to trojans.
Witnesses from Trøndelag to Finnmark compared the amazing display to anything from a Russian rocket to a meteor to a shock wave -- although no one appears to have mentioned UFOs yet.
That's because a UFO isn't an explanation -- a UFO is an "unidentified flying object". You could compare it to specific instances of unexplained aerial phenomena -- though that's unlikely to help explain it unless the conditions surrounding this occurrence help explain some whole class of previously-unexplained aerial phenomena -- but to compare it to UFOs in general is somewhat pointless since the only thing that that class shares in common is that they appear above the ground and are not explained.
Amazon came in at about 2/3 the cost of Sony, and B&N doesn't have an ereader store
They have an ereader app available for several platforms (including iPhone) and a ereader store, even though their dedicated ereader device is not yet shipping.
If you put out a game that is good enough right out of the box (or the original torrent in this case), and then issue compelling DLC they might well go ahead and purchase the DLC if that's easier than (or just as easy as) getting a torrent.
If you start to accept that, why sell the base game, as such, at all? Why not just release a fully-functional base game as a free starter, and sell DLC and services (e.g., access to premium servers) related to it? If you are going to sell something at retail as a box, then, it should really be a package of "passes" for DLC and/or services (sure, the base game can be on a CD in the box, but that shouldn't be what people are paying for.)
Yes, and Scheme do support exact rationals. And if Scheme can do do it then i think ECMAScript should do it. It is in my opinion the best way to solve the 0.1+0.2 != 0.3 problem
On this much, we agree. Particularly if constants are exact by default and conversion down the numeric tower is automatic.
Maybe, but when using inexact numbers and operations in Scheme, it is obvious to any programmers that there might be surprises.
Making it obvious where surprises can occur is better than obscuring it; having well-defined behavior that assures that applications will run consistently on compliant implementations, OTOH, is better yet. And consistency is, I would say, more important for ECMAScript than Scheme, given that how much of the use of ECMAScript centers around the ability to use it as a CPU/OS agnostic client-side scripting language for web-based client-server applications.
As someone who makes his living selling content through the Internet, I want people to think several times before building a tool like AdBlock. If the content industry can't make money from ads, we'll either go out of business or put our information behind a paywall.
(1) AdBlock already exists for Firefox; whether a version is created for Chrome mainly effects whether people who for whom lack of that functionality is a dealbreaker use Chrome instead of Firefox. Actually, ad blocking (or at least hiding) extensions already exist for Chrome, too, so the main affect of new ones is in the minute details of the user experience for users who want to block ads. For the issue you raise, the ship has sailed -- ad blockers exist and are prevalent enough that anyone who wants to block ads from their browsing experience can find a way to do so.
(2) Yes, if you can't get your users to pay enough for content for you to make a profit on it (either directly or by supporting your advertisers who in turn support you), you will go out of that business. If you (the content industry as a whole) think web advertising is the best way for you to stay in business, you may want to fight the obnoxious and intrusive advertising practices on the web that lead so many people to use ad blockers.
I understand that advertisements can be annoying and often temperamental
Then maybe you (again, the content industry) ought to work to correct that. Especially since, as you point out, the public response to that annoyance threatens your industry.
Geeks by definition (or at least what used to be the definition...) were socially inept but good at some narrow technical or artistic field. For some reason, there came a sort of "geek" identity which (maybe due some movies?) became "cool". And then suddenly people who have nothing to do with the group of people described above call themselves "geek". And that's how you get this...
By what used to be the definition when the word first entered the English language, "geek" seems to have meant "fool", so the use in the article makes sense -- its just come full circle.
No, exact or inexact is an attribute of a data value.
(Under what conditions an operation returns an exact or inexact value is part of its behavior, but far from the only important area of behavior a specification is likely to be concerned with.)
Very few programmers have read the IEE754(r) specifications and understand when and how numbers are rounded or are even aware that rounding is taking place.
I think most programmers -- whether or not they have read the IEEE 754-2008 spec -- are aware that rounding takes place with floating point numbers.
On the other hand the Scheme specification is simple to understand, and will give you very few surprises. Any integer or rational number can be represented exactly, and by sticking to "exact" functions, the results will also be exact. No need to care about how rounding is done, because there is none.
There are very few languages where rounding would be done on integers (or rationals, if the language supports them in the first place) with exact operations.
Of course, Scheme is less specific than IEEE 754 when it comes to the behavior of inexact operations, so an implementation is more likely to surprise even a diligent programmer who knows the spec for the language.
You would always use the smallest subdivision of a currency as the unit for calculations. For the US dollar you store everything as cents
Except that there are all kinds of areas where units smaller than cents are required when working with US currency. If you don't believe me, try finding a gas station whose prices aren't specified in mils. The smallest subdivision for which coins are minted -- or which normal bank transactions can be conducted in -- is not necessarily the smallest unit that needs to be stored or used in calculations.
But 754r doesn't solve that, it simply mitigates it like anybody who understands the floating point problem already does. It cannot actually solve the problem, because ALL calculations done on a computer are done in binarey - there is no way around it.
Uh, sure there is. Any calculation done on a binary digital computer, of course, has to consume inputs and produce results that can be represented in a binary format, to be sure, but that doesn't mean that they are "done in binary" in any meaningful sense.
That the conversion is made in the CPU (FPU more specifically) doesn't change the fact that a conversion must be made and the errors are carried over.
In order to support the decimal types and operations defined by IEEE 754-2008 (whether it is done in hardware, in software, or in a hybrid) a system cannot be converting into binary floating point representation, using binary floating point operations, and converting back into decimal floating point representation, and allowing conversion errors to propagate through that process, even under the hood -- it has to be producing the correct results as defined in the operations for each type, including those defined on decimal types.
This is also why decimal floating point software implementations are much, much slower than binary floating point hardware operations on systems which support the latter. If you could just convert the decimal operands to binary and use binary operations than convert the result back to the decimal representation, you would get a slowdown, but not the kind of "hundreds of times" slowdown you get when you have to implement the basic operations on the decimal representations in software.
The problem that some people have with doing this is it hides the problem, instead of accentuates it. Now even fewer programmers, especially new programmers, are aware there is a problem. They will simply think "I'm not ever converting out of decimal, so these calculations will always be correct" instead of being aware of the fact that the processor is simply doing some binary>decimal error mitigation for you, and problems can and will still crop up.
Decimalbinary conversion errors cannot, by definition, show up in a correct IEEE 754-2008 implementation when only decimal (or only binary, for that matter) values are involved in the operation.
There are, of course, sources of compounding error in floating point operations (particularly sequences of such operations) besides base conversion issues, which are well understood and which remain in IEEE 754-2008. (Some of them can be avoided in practice by having bigger floating point representations of the same base, which is another area of change in IEEE 754-2008.)
It isn't even floating point any more, it's decimal
Decimal or binary refer to bases, which are orthogonal to whether the representation is a floating point one. IEEE 754-2008 defines both binary and decimal floating point representations.
I am not saying that ECMAScript should choose the old IEEE 754 standard in favor of the new 754r. What I am saying, is that the ECMAScript standard should specify neither of them.
I can understand that so far as the internal (within the interpreter) representation, but it certainly needs to specify the behavior of numeric data types, which is most of either the 1985 or the 2008 version of IEEE 754 specifies.
That is why I used Scheme as an example of how it can be done right. By calling a datatype "inexact" in stead of float/double, it is quite obvious for most programmers that it should not be used for exact calculations. And the "exact" datatype is not limited to holding integer numbers, perfect for counting dollars and cents.
While I agree with you that Scheme's numeric tower is a good basic approach to a numeric type system your description of Scheme's numeric system as having only two types, "exact" and "inexact", is incorrect. The Scheme specification (both R5RS and R6RS) specifies a nested tower of 5 types (number, complex, real, rational, and integer). Exactness is an attribute that a numeric value -- of any of the 5 types -- can have.
Further, that doesn't address the issue of behavior, only that of representation.
As long as a programmer is not parsing/serializing binary data, all he cares about is whether calculations are exact or inexact
Actually, there is a lot more that a programmer may care about, such as how data that has to be rounded to fit into the representation used is treated, and what control they have over how that is done. That's a behavior feature that is specified by a floating point spec, and its a point of difference between the different versions of IEEE 754 (since the 2008 version has an additional rounding mode.) They also care about what values can be represented exactly, since that affects the behavior of operations and whether the results are exact or inexact.
Everyone knows that if you're going to try to enforce your ridiculous patent, you don't file suit in your own jurisdiction or the defendants jurisdication. Real patent trolls file in the Eastern District of Texas. Had they done that, they would have gotten their settlement.
Well, its worth noting that the judge before which the case was being heard up until that same judge granted Netflix's motion for a change of venue to the Northern District of California issued an order that "the Rules of Practice for Patent Cases promulgated by the United States District Court for the Eastern District of Texas shall be employed and adopted for use in this case."
If the relevant judge were acting with any sort of maturity he would tell both parties to get lost and find a venue that has some relation to either of them.
Well, I think the mature way would, actually, be to the follow the law and, if one of the parties sought a change of venue to a more appropriate place, grant it. Which, you know, is exactly what the judge did here.
But apparently, to some people, "maturity" involves unprofessional and capricious conduct.
So 754 vs 754r boils down do this: When doing arithmetic using 754, then 0.1+ 0.2 != 0.3 (as any half decent programmer should know). IBM want to fix it with a new floating point format that can do exact calculations (under certain circumstances) with decimal numbers.
Well, IBM isn't the only one (outside of the world of ECMAScript standards)--which is why IEEE754-2008 ("IEEE 754r") incorporates decimal floating point and other improvements to the old version of IEEE 754 that it has replaced as a standard.
First, it won't fix the stupid programmer bug. 754r can't guarantee exactness in every situation. For instance, (large_num+small_num)+small_num == large_num != large_num+(small_num + small_num).
The problem for non-stupid programmers is (or one of them, at any rate) that using only binary floating point prevents simple expression of calculations with simple rounding rules, when those rules are defined in terms of base-10 numbers, which is often the case in important application domains.
Second, ECMAScript is supposed to run on different architectures. It should not depend on specific number-representaions, not for integers and certainly not for floating points.
But, supporting only the old IEEE 754 standard also depends on specific number representations for floating points. It just depends on ones that are less convenient from an application perspective, though easier from an implementation perspective.
If you know someone that is using IEEE floats or doubles to represent dollars internally, reach out to them and get them help, and let them know that just counting the pennies and occasionally inserting a decimal for the humans is much, much safer!;)
Using IEEE decimal floating point is also safer, and involves less conversion and better control of rounding when you have to do operations that can't be done with pure integer math. Like, you know, anything involving percentages.
Financial calculations involve more than just tracking deposits and withdrawals of amounts given in dollars-and-cents or the equivalent.
instead of using floating point for representing decimal numbers, one can of coarse easily use fixed point... for currency computations, just store every value multiplied by 100 and use some fancy printing routine to put the decimal point at the right position.
Of course, you still have to use floating point operations (or horrible, case-by-case workarounds) if you are doing anything other than addition and subtraction, and multiplication by integer values, even if the representation you use for the inputs and results is fixed-point, and you'll have to convert the results of the floating point operations to and from your fixed-point representation. When you don't have very specific rounding rules for the operations, this isn't problematic, but the more specific the rules you have, the more cumbersome this will be, particularly if the rules are based on base-10 representation (as the often are in real world uses) and the floating point representation is base-2.
If you have use a base-10 floating point system (representation and operations) with good support for rounding the ways you need to start with, you can express the operations you want performed on the numbers more directly in your code.
I fail to see how being loosely typed means that support for higher precision numbers is any uglier than in a strongly typed language.
In fact, I think Scheme demonstrates pretty effectively that being dynamically typed (which, not loose typing, is what JavaScript is) is entirely compatible with having an extraordinarily elegant system of numeric representation which seamless scales from exact integer representation through exact rational representation through to inexact representations.
Doesn't everyone know not to use floating point numbers for financial calculations? Or at least understand the limitations or faults associated with them...
Financial calculations that involve more than addition, subtraction, and multiplication by integer values -- which there are a lot of -- require the use something other than integer math. But, yeah, most people understand the pitfalls, which is why the newer standard exists to address them.
To most efficiently perform tasks that people want computers to do, which more frequently means performing correct math with numbers that have an exact base-10 representation than, say, doing the same with numbers that have an exact base-2 representation.
10 is just an arbitrary number humans picked because they happen to have 10 fingers. There's no connection between that and computers.
Well, unless you consider that the users of computers are generally humans, and that the uses of computers are in applications defined by humans to fit human needs, which very often involves consuming base-10 input and producting base-10 output, using either operations where conversion to a base-2 approximation of the given base-10 values for internal processing and back out may produce incorrect, or at least unnecessarily imprecise, results.
Slashdot Mirror
Its not designed to make people want eBooks.
Its designed to provide an alternative existing ebook distributors to increase the share of sales revenue that the publishers of (dying) print periodicals can extract from sales of electronic editions, and to increase the advertising sales that can be realized by those same publishers. One of the big things they trumpet about it is how attractive their platform will be for advertising.
Broadening the ebook market isn't their intent.
And, no doubt, in addition to being a platform for outside advertisers, their reader will tightly integrate cross-promotional advertising (no doubt, taking into account each user's reading habits to select ads) to place teaser ads for other products to promote impulse buys.
For profit companies don't exist to serve consumers, they exist to serve their investors. Whose going to fund the coalition you propose?
IME, it works okay for novels, even on the miniature, LCD (rather than eInk) screen of the iPhone. But, yeah, a bigger screen than that, or than most current ebook readers, would be nice -- and there are lots of new e-ink readers with bigger screens that are coming out.
And epub -- which is, under the hood, basically just XHTML + a specialized adaptation of CSS + a variety of image file formats, including both bitmap (e.g., PNG) and vector (e.g., SVG) which a reader must support -- already supports illustrations and photographs, and most dead-tree newspapers don't use much color, so neither a new format nor a device with features not found in typical ebook readers -- except maybe bigger page size, but bigger paged e-ink-based readers are available -- are needed for that.
Since the whole case they make for the need for a new format and device is that eBook formats and devices like the Kindle, while good for books, aren't good for newspapers and other periodicals, because they don't precisely reproduce the print experience and layout, what is good for eBooks isn't really at issue.
HTML is open. They want "semi-open".
Which I suppose would be PDF, which also has been around for a while.
There's a middle ground that can maximize protection against trojans (of course, nothing can protect against completely unwary users), and that's using something a model where untrusted apps are (whether by running through app-specific accounts or otherwise) required to be given fairly finely grained permissions on installation before accessing resources.
While Linux distros provided somewhat more protection against users being unknowingly tricked into performing dangerous tasks by providing elegant, non-intrusive ways to provide the control users need without always running as a superuser before Windows did much in that regard, it shares with Windows a fairly all or nothing security model in many regards that is particularly susceptible to trojans.
That's because a UFO isn't an explanation -- a UFO is an "unidentified flying object". You could compare it to specific instances of unexplained aerial phenomena -- though that's unlikely to help explain it unless the conditions surrounding this occurrence help explain some whole class of previously-unexplained aerial phenomena -- but to compare it to UFOs in general is somewhat pointless since the only thing that that class shares in common is that they appear above the ground and are not explained.
They have an ereader app available for several platforms (including iPhone) and a ereader store, even though their dedicated ereader device is not yet shipping.
If you start to accept that, why sell the base game, as such, at all? Why not just release a fully-functional base game as a free starter, and sell DLC and services (e.g., access to premium servers) related to it? If you are going to sell something at retail as a box, then, it should really be a package of "passes" for DLC and/or services (sure, the base game can be on a CD in the box, but that shouldn't be what people are paying for.)
On this much, we agree. Particularly if constants are exact by default and conversion down the numeric tower is automatic.
Making it obvious where surprises can occur is better than obscuring it; having well-defined behavior that assures that applications will run consistently on compliant implementations, OTOH, is better yet. And consistency is, I would say, more important for ECMAScript than Scheme, given that how much of the use of ECMAScript centers around the ability to use it as a CPU/OS agnostic client-side scripting language for web-based client-server applications.
(1) AdBlock already exists for Firefox; whether a version is created for Chrome mainly effects whether people who for whom lack of that functionality is a dealbreaker use Chrome instead of Firefox. Actually, ad blocking (or at least hiding) extensions already exist for Chrome, too, so the main affect of new ones is in the minute details of the user experience for users who want to block ads. For the issue you raise, the ship has sailed -- ad blockers exist and are prevalent enough that anyone who wants to block ads from their browsing experience can find a way to do so.
(2) Yes, if you can't get your users to pay enough for content for you to make a profit on it (either directly or by supporting your advertisers who in turn support you), you will go out of that business. If you (the content industry as a whole) think web advertising is the best way for you to stay in business, you may want to fight the obnoxious and intrusive advertising practices on the web that lead so many people to use ad blockers.
Then maybe you (again, the content industry) ought to work to correct that. Especially since, as you point out, the public response to that annoyance threatens your industry.
By what used to be the definition when the word first entered the English language, "geek" seems to have meant "fool", so the use in the article makes sense -- its just come full circle.
No, exact or inexact is an attribute of a data value.
(Under what conditions an operation returns an exact or inexact value is part of its behavior, but far from the only important area of behavior a specification is likely to be concerned with.)
I think most programmers -- whether or not they have read the IEEE 754-2008 spec -- are aware that rounding takes place with floating point numbers.
There are very few languages where rounding would be done on integers (or rationals, if the language supports them in the first place) with exact operations.
Of course, Scheme is less specific than IEEE 754 when it comes to the behavior of inexact operations, so an implementation is more likely to surprise even a diligent programmer who knows the spec for the language.
Except that there are all kinds of areas where units smaller than cents are required when working with US currency. If you don't believe me, try finding a gas station whose prices aren't specified in mils. The smallest subdivision for which coins are minted -- or which normal bank transactions can be conducted in -- is not necessarily the smallest unit that needs to be stored or used in calculations.
Uh, sure there is. Any calculation done on a binary digital computer, of course, has to consume inputs and produce results that can be represented in a binary format, to be sure, but that doesn't mean that they are "done in binary" in any meaningful sense.
In order to support the decimal types and operations defined by IEEE 754-2008 (whether it is done in hardware, in software, or in a hybrid) a system cannot be converting into binary floating point representation, using binary floating point operations, and converting back into decimal floating point representation, and allowing conversion errors to propagate through that process, even under the hood -- it has to be producing the correct results as defined in the operations for each type, including those defined on decimal types.
This is also why decimal floating point software implementations are much, much slower than binary floating point hardware operations on systems which support the latter. If you could just convert the decimal operands to binary and use binary operations than convert the result back to the decimal representation, you would get a slowdown, but not the kind of "hundreds of times" slowdown you get when you have to implement the basic operations on the decimal representations in software.
Decimalbinary conversion errors cannot, by definition, show up in a correct IEEE 754-2008 implementation when only decimal (or only binary, for that matter) values are involved in the operation.
There are, of course, sources of compounding error in floating point operations (particularly sequences of such operations) besides base conversion issues, which are well understood and which remain in IEEE 754-2008. (Some of them can be avoided in practice by having bigger floating point representations of the same base, which is another area of change in IEEE 754-2008.)
Decimal or binary refer to bases, which are orthogonal to whether the representation is a floating point one. IEEE 754-2008 defines both binary and decimal floating point representations.
I can understand that so far as the internal (within the interpreter) representation, but it certainly needs to specify the behavior of numeric data types, which is most of either the 1985 or the 2008 version of IEEE 754 specifies.
While I agree with you that Scheme's numeric tower is a good basic approach to a numeric type system your description of Scheme's numeric system as having only two types, "exact" and "inexact", is incorrect. The Scheme specification (both R5RS and R6RS) specifies a nested tower of 5 types (number, complex, real, rational, and integer). Exactness is an attribute that a numeric value -- of any of the 5 types -- can have.
Further, that doesn't address the issue of behavior, only that of representation.
Actually, there is a lot more that a programmer may care about, such as how data that has to be rounded to fit into the representation used is treated, and what control they have over how that is done. That's a behavior feature that is specified by a floating point spec, and its a point of difference between the different versions of IEEE 754 (since the 2008 version has an additional rounding mode.) They also care about what values can be represented exactly, since that affects the behavior of operations and whether the results are exact or inexact.
The question of whether a district court has jurisdiction is different than the question of whether the district is the most appropriate venue.
Well, its worth noting that the judge before which the case was being heard up until that same judge granted Netflix's motion for a change of venue to the Northern District of California issued an order that "the Rules of Practice for Patent Cases promulgated by the United States District Court for the Eastern District of Texas shall be employed and adopted for use in this case."
Well, I think the mature way would, actually, be to the follow the law and, if one of the parties sought a change of venue to a more appropriate place, grant it. Which, you know, is exactly what the judge did here.
But apparently, to some people, "maturity" involves unprofessional and capricious conduct.
Well, IBM isn't the only one (outside of the world of ECMAScript standards)--which is why IEEE754-2008 ("IEEE 754r") incorporates decimal floating point and other improvements to the old version of IEEE 754 that it has replaced as a standard.
The problem for non-stupid programmers is (or one of them, at any rate) that using only binary floating point prevents simple expression of calculations with simple rounding rules, when those rules are defined in terms of base-10 numbers, which is often the case in important application domains.
But, supporting only the old IEEE 754 standard also depends on specific number representations for floating points. It just depends on ones that are less convenient from an application perspective, though easier from an implementation perspective.
Presumably, that's comparing execution speed in environments with hardware support of the old standard, but using software-only for the new standard.
Using IEEE decimal floating point is also safer, and involves less conversion and better control of rounding when you have to do operations that can't be done with pure integer math. Like, you know, anything involving percentages.
Financial calculations involve more than just tracking deposits and withdrawals of amounts given in dollars-and-cents or the equivalent.
Of course, you still have to use floating point operations (or horrible, case-by-case workarounds) if you are doing anything other than addition and subtraction, and multiplication by integer values, even if the representation you use for the inputs and results is fixed-point, and you'll have to convert the results of the floating point operations to and from your fixed-point representation. When you don't have very specific rounding rules for the operations, this isn't problematic, but the more specific the rules you have, the more cumbersome this will be, particularly if the rules are based on base-10 representation (as the often are in real world uses) and the floating point representation is base-2.
If you have use a base-10 floating point system (representation and operations) with good support for rounding the ways you need to start with, you can express the operations you want performed on the numbers more directly in your code.
In fact, I think Scheme demonstrates pretty effectively that being dynamically typed (which, not loose typing, is what JavaScript is) is entirely compatible with having an extraordinarily elegant system of numeric representation which seamless scales from exact integer representation through exact rational representation through to inexact representations.
Financial calculations that involve more than addition, subtraction, and multiplication by integer values -- which there are a lot of -- require the use something other than integer math. But, yeah, most people understand the pitfalls, which is why the newer standard exists to address them.
To most efficiently perform tasks that people want computers to do, which more frequently means performing correct math with numbers that have an exact base-10 representation than, say, doing the same with numbers that have an exact base-2 representation.
Well, unless you consider that the users of computers are generally humans, and that the uses of computers are in applications defined by humans to fit human needs, which very often involves consuming base-10 input and producting base-10 output, using either operations where conversion to a base-2 approximation of the given base-10 values for internal processing and back out may produce incorrect, or at least unnecessarily imprecise, results.