[prev in list] [next in list] [prev in thread] [next in thread] 

List:       perl6-language
Subject:    Re: Language design
From:       Darren Duncan <darren () darrenduncan ! net>
Date:       2015-06-22 20:36:36
Message-ID: 558871D4.70203 () darrenduncan ! net
[Download RAW message or body]

On 2015-06-16 2:15 PM, The Sidhekin wrote:
> On Tue, Jun 16, 2015 at 10:52 PM, Michael Zedeler <michael@zedeler.dk> wrote:
>     ...and unpredictable performance is a cost you're willing to pay?
>
>    I don't write performance-critical applications, but even if I did, why would
> I prefer getting the wrong answer faster?

I agree with Sidhekin and similar mentalities.

On the range between safety/correctness and speed, a good programming language / 
tool should always default to the most safe/correct option when the user doesn't 
specify where on the range they want, and leave it to the power users to 
explicitly make the trade-off when they know what they're doing.

In this case, people who explicitly want floats because of performance rather 
than exact rationals do indeed count as power users.

Normal people are more interested in not being surprised by the answers they get 
to what should be common-sense questions, such as when adding 10.3 to 14.2.

I should also point out that finance / anything to do with money is an extremely 
common use case that cares very much about math being exact, its not just 
esoteric science applications.

This all being said, I draw the line where implementing is much more complicated 
to serve esoteric cases.  So for example while exact precision rationals 
absolutely should be default / part of core, something like symbolic values eg 
exact representations of irrational numbers, are perfectly valid to, and 
probably shouldn't, be part of core.  Exact rationals are not particularly 
complicated.  Its perfectly reasonable to expect in the core that if someone 
does math that is known to deal with irrationals in general, that loss of 
precision then is acceptable.

-- Darren Duncan

[prev in list] [next in list] [prev in thread] [next in thread]