Andrei's list of barriers to D adoption

[Walter Bright via Digitalmars-d]

On 6/6/2016 11:36 AM, Observer wrote:
> It's more complicated than that.  Part of what you need is to
> be able to declare a variable as (say) having two significant
> fractional digits, and have the rounding rules be implicitly
> applied when saving to that variable, producing an exact
> representation of the rounded result in storage.  And part of
> the reason for that is that if you compare "3.499" to "3.501"
> (as the originally computed numbers) when only 2 sig figs
> should be in play, they must compare equal.  This is very much
> unlike what happens with binary floating point, where exact
> comparisons are rarely possible due to low-order bit differences.
> In commercial decimal-arithmetic applications (think "money"),
> the low-order bits are supposed to be discarded for almost all
> values that actually represent an amount of currency.  For
> reliability of the application, this has to be built into the
> data type, not dependent on programmer vigilance.  That is,
> just like certain other language features, a decimal type
> without implicit truncation would be thought of as "doesn't
> scale well".

What I've done, though I know that I won't convince any users of BigDecimal, is 
use longs and have them represent pennies instead of dollars. Then they're all 
exact to two places.