6 ms·

Python is a Turing Complete language, so I'd be surprised if it trully lacked a feature and there weren't a library written by a poor soul that implemented it.

Python is a Turing Complete language, so I'd be surprised if it trully lacked a feature and there weren't a library written by a poor soul that implemented it. I am talking more about programming thinking than a feature set. That there's no such thing as Unicode issues or needing to use silly "u" prefixes. That 0.1 + 0.2 == 0.3 reliably that you can write accounting software worry-free and not wonder about why it fails in so many old langs. That you can use grammars to write a mini-language for your specific problem to save yourself tons of generic programming. That you can branch off into a separate processor core with a simple `start` keyword or parallelize a method call on a list of items with just a `>>` hyper prefix or seamlessly communicate a job parallelized over 30 cores with yet another core with a simmple channelled supply without worrying about data races. These features may be present in Python, but way of thinking isn't. A new programmer starting in Perl 6 won't think of multi-threading, Unicode, floating point math as problematic areas and grammars together with full-language maleability that lets you create problem-specific langs instead of a mountain of generic classes is undreamt of by oldschoolers like me.

acdha 10y ago
> That there's no such thing as Unicode issues or needing to use silly "u" prefixes. That 0.1 + 0.2 == 0.3 reliably that you can write accounting software worry-free and not wonder about why it fails in so many old langs. It's interesting that you lead with a bunch of examples which are very old or simply wrong. For example, in any language where you don't think about Unicode you are guaranteed to have encoding issues as soon as you have sufficiently diverse (i.e. real-world) data. If Python 2's u"" prefix offends you so – I must say, hearing a Perl programmer complain about punctuation is a somewhat novel experience – note that Python 3 was released in 2008 which changed to use Unicode by default. In every language, however, you will need to think about file encodings everywhere you read or write data until we finally hit that halcyon decade (century?) where you can assume UTF-8 with a very high level of confidence. Similarly, Python has had decimal-accurate math since the early 2000s so the developer is free to pick whether they value absolute precision over standard IEEE floating point semantics. Perl 6 dynamically switches numeric classes so the simple syntax you show will lose precision at some point depending on the data and order of operations – that's why the documentation specifies Rat as “limited precision” and it means that anyone writing accounting (or, in many cases, scientific) software would explicitly use an arbitrary-precision data type to avoid the classic floating-point math problems: $ perl6 --version This is Rakudo version 2016.10 built on MoarVM version 2016.10 $ perl6 > 123456789 - 1e-5 123456788.99999 > 123456789 - 1e-6 123456788.999999 > 123456789 - 1e-7 123456789 > (123456789 - 1e-1) - 123456789 -0.0999999940395355 Please note that I'm not saying Perl 6 is terrible. This is a well known trade-off which everyone has to learn about if they work in fields where this matters. Perl 6 has arbitrary-precision types built-in so anyone dealing with financial data is simply going to learn to specify that precision is not an acceptable trade-off for performance: > my $a = Num(12356789) 12356789 > $a + FatRat(0.1) - $a 0.099999999627471 > my $a = FatRat(12356789) 12356789 > $a + FatRat(0.1) - $a 0.1 I would suggest focusing on the parts of Perl 6 which you like rather than hurling bricks at other languages. Things like start / hyper sound kind of interesting and it'd be far more interesting to hear about how those work in practice and how you manage issues like communications overhead or shared data than your personal dislikes about some other language.
- espadrine 10y ago
  For the sake of exhaustivity, let's point out that numeric literals in Perl6 separate rationals (Rat) and floating-point numbers (Num), which means the first Perl6 example would work as intended provided we stick with Rat: > 123456789 - 0.0000001 123456788.9999999 > (123456789 - 0.1) - 123456789 -0.1 Rationals represent numbers of the form a÷b, with a a bigint and b a 64-bit integer. When b gets too big for that fast representation, it gets converted to a Num (ie, IEEE 754). > (1 / (10 ** 100)).WHAT (Num) That tradeoff is reasonable, as numbers that cannot be represented this way are very likely to be non-rational math (eg, sqrt, exp, sin, pi, that kind of thing). For money, this is safe. For real numbers, well: > sin(0).WHAT (Num) FatRat uses a bigint for b. Obviously, it still cannot accurately represent non-rational numbers such as pi. Reference: https://docs.perl6.org/language/syntax#Number_literals https://docs.perl6.org/language/syntax#Number_literals https://docs.perl6.org/type/Rat https://docs.perl6.org/type/Rat
  - acdha 10y ago
    Thanks! I definitely hope my point didn't come across as “this is terrible” rather than “people for whom this is critical still need to read the docs / write tests”.
- raiph 10y ago
  > Python 3 was released in 2008 which changed to use Unicode by default. Sure, but Python 3 only took on correct handling at the whole string level. It ignored correct handling at the character and sub-string level. Something similar applies for many programming languages. I think this was Zoffix's point.[1] > explicitly use an arbitrary-precision data type to avoid the classic floating-point math problems: > 123456789 - 1e-5 123456788.99999 Literals of the form `1e-5` are not arbitrary precision in Perl 6. They are floating point (called Num in Perl 6).Hence your above result. Similarly: > my $a = Num(12356789) 12356789 > $a + FatRat(0.1) - $a 0.099999999627471 would work if instead you wrote: > my $a = 12356789 12356789 > $a + 0.1 - $a 0.1 > $a + 0.00001 - $a 0.00001 If all inputs are 100% accurate, arbitrary precision Ints and/or FatRats then all results will be too. But the same applies even if some Rats are also involved provided the final result requires a denominator less than 18,446,744,073,709,551,615. [1] Of the 150+ languages with Rosettacode solutions for returning the length of a string (at http://rosettacode.org/wiki/String_length http://rosettacode.org/wiki/String_length) just 3 (Elixir, Perl 6, Swift) have a built in way to get the right result for what Unicode defines as "what a user thinks of as a character".

acdha 10y ago

> That there's no such thing as Unicode issues or needing to use silly "u" prefixes. That 0.1 + 0.2 == 0.3 reliably that you can write accounting software worry-free and not wonder about why it fails in so many old langs. It's interesting that you lead with a bunch of examples which are very old or simply wrong. For example, in any language where you don't think about Unicode you are guaranteed to have encoding issues as soon as you have sufficiently diverse (i.e. real-world) data. If Python 2's u"" prefix offends you so – I must say, hearing a Perl programmer complain about punctuation is a somewhat novel experience – note that Python 3 was released in 2008 which changed to use Unicode by default. In every language, however, you will need to think about file encodings everywhere you read or write data until we finally hit that halcyon decade (century?) where you can assume UTF-8 with a very high level of confidence. Similarly, Python has had decimal-accurate math since the early 2000s so the developer is free to pick whether they value absolute precision over standard IEEE floating point semantics. Perl 6 dynamically switches numeric classes so the simple syntax you show will lose precision at some point depending on the data and order of operations – that's why the documentation specifies Rat as “limited precision” and it means that anyone writing accounting (or, in many cases, scientific) software would explicitly use an arbitrary-precision data type to avoid the classic floating-point math problems: $ perl6 --version This is Rakudo version 2016.10 built on MoarVM version 2016.10 $ perl6 > 123456789 - 1e-5 123456788.99999 > 123456789 - 1e-6 123456788.999999 > 123456789 - 1e-7 123456789 > (123456789 - 1e-1) - 123456789 -0.0999999940395355 Please note that I'm not saying Perl 6 is terrible. This is a well known trade-off which everyone has to learn about if they work in fields where this matters. Perl 6 has arbitrary-precision types built-in so anyone dealing with financial data is simply going to learn to specify that precision is not an acceptable trade-off for performance: > my $a = Num(12356789) 12356789 > $a + FatRat(0.1) - $a 0.099999999627471 > my $a = FatRat(12356789) 12356789 > $a + FatRat(0.1) - $a 0.1 I would suggest focusing on the parts of Perl 6 which you like rather than hurling bricks at other languages. Things like start / hyper sound kind of interesting and it'd be far more interesting to hear about how those work in practice and how you manage issues like communications overhead or shared data than your personal dislikes about some other language.

espadrine 10y ago
For the sake of exhaustivity, let's point out that numeric literals in Perl6 separate rationals (Rat) and floating-point numbers (Num), which means the first Perl6 example would work as intended provided we stick with Rat: > 123456789 - 0.0000001 123456788.9999999 > (123456789 - 0.1) - 123456789 -0.1 Rationals represent numbers of the form a÷b, with a a bigint and b a 64-bit integer. When b gets too big for that fast representation, it gets converted to a Num (ie, IEEE 754). > (1 / (10 ** 100)).WHAT (Num) That tradeoff is reasonable, as numbers that cannot be represented this way are very likely to be non-rational math (eg, sqrt, exp, sin, pi, that kind of thing). For money, this is safe. For real numbers, well: > sin(0).WHAT (Num) FatRat uses a bigint for b. Obviously, it still cannot accurately represent non-rational numbers such as pi. Reference: https://docs.perl6.org/language/syntax#Number_literals https://docs.perl6.org/language/syntax#Number_literals https://docs.perl6.org/type/Rat https://docs.perl6.org/type/Rat
- acdha 10y ago
  Thanks! I definitely hope my point didn't come across as “this is terrible” rather than “people for whom this is critical still need to read the docs / write tests”.
raiph 10y ago
> Python 3 was released in 2008 which changed to use Unicode by default. Sure, but Python 3 only took on correct handling at the whole string level. It ignored correct handling at the character and sub-string level. Something similar applies for many programming languages. I think this was Zoffix's point.[1] > explicitly use an arbitrary-precision data type to avoid the classic floating-point math problems: > 123456789 - 1e-5 123456788.99999 Literals of the form `1e-5` are not arbitrary precision in Perl 6. They are floating point (called Num in Perl 6).Hence your above result. Similarly: > my $a = Num(12356789) 12356789 > $a + FatRat(0.1) - $a 0.099999999627471 would work if instead you wrote: > my $a = 12356789 12356789 > $a + 0.1 - $a 0.1 > $a + 0.00001 - $a 0.00001 If all inputs are 100% accurate, arbitrary precision Ints and/or FatRats then all results will be too. But the same applies even if some Rats are also involved provided the final result requires a denominator less than 18,446,744,073,709,551,615. [1] Of the 150+ languages with Rosettacode solutions for returning the length of a string (at http://rosettacode.org/wiki/String_length http://rosettacode.org/wiki/String_length) just 3 (Elixir, Perl 6, Swift) have a built in way to get the right result for what Unicode defines as "what a user thinks of as a character".