
A little thing to love about Perl 6 and COBOL - i_cannot_hack
http://blogs.perl.org/users/ovid/2015/02/a-little-thing-to-love-about-perl-6-and-cobol.html
======
ChuckMcM
I think the thing that would make perl 6 really successful would be to call it
something other than perl. Many people who have programmed perl for a long
time seem to think it is an abomination of the first order, many people who
have never programmed in perl think perl is some sort of dead language like
COBOL or PL/1\. Both groups are going to have a systemic aversion to this new
language simply based on its name. And that is unfortunate.

There are neat things in this new language and there is no reason to leave the
sea anchor of a name attached to it. Call it something fresh and new and it
can be the cool hotness that is up and coming.

~~~
fidotron
I don't think so. The real problem with Perl is it's an aesthetic train wreck.
It is possible to write beautiful Python, Ruby, Erlang, ML, Prolog, C, C++ or
even Java, but I challenge anyone to write a non-trivial Perl (5 or 6) program
that doesn't make you feel slightly ill.

Some of the semantics seem really nice, but the syntax is utterly disastrous.

~~~
tbrownaw
The only thing I don't like about Perl, is that it's a dynamic language and
therefore unsuitable for large (as in, significantly longer than will fit on
the screen at one time) programs. But "use strict;" helps with that, and
apparently more recent versions (work has 5.8.8) allow subroutines to more
easily declare a specific number of arguments.

I'm actually learning more of it right now, so I can clean up and modularize
some of my scripts. Because my other options (ksh93, Progress 4GL, and maybe
older versions of Java or C++) are even less suitable.

~~~
kbenson
If you haven't already, I highly suggest looking on metacpan.org for modules,
and searching for highly rated[1] and recent ones. Things like Path::Tiny[2],
Try::Tiny[3] and Function::Parameters[4] can make a huge difference in
productivity and readability. Task::Kensho[5] is also useful for getting a
good base set of medern modules to choose from for many tasks.

1:
[https://metacpan.org/favorite/leaderboard](https://metacpan.org/favorite/leaderboard)

2: [https://metacpan.org/release/Path-Tiny](https://metacpan.org/release/Path-
Tiny)

3: [https://metacpan.org/release/Try-Tiny](https://metacpan.org/release/Try-
Tiny)

4:
[https://metacpan.org/pod/Function::Parameters](https://metacpan.org/pod/Function::Parameters)

5:
[https://metacpan.org/pod/Task::Kensho](https://metacpan.org/pod/Task::Kensho)

~~~
tbrownaw
I'll take a look at these, thanks. :)

------
blahedo
Not to disagree with anything the OP says, but a language with somewhat more
recent currency that shares the "decimals are rationals by default" advantages
is Scheme (and Racket and so on). At least in Racket, floating point
representation is an implementation detail of the inexact-real numbers, while
the exact-rational numbers are correctly produced and computed on when you
give values in decimal form.

Scheme (et al) are probably the more direct conceptual inspiration for Perl
6's rational decimals---the Perl 6 developers were certainly aware of it (as
they were aware of pretty much all the major PL work out there :)

~~~
kbenson
Perl 6 borrowed liberally from _many_ sources. That does make it a very
complex language, but you can omit many of the more complex features until you
are more comfortable with them. There's a slide deck that touches on that
point by the same author that was posted to HN recently called "Perl 6 for
mere mortals" (a FOSDEM 2015 talk).

1:
[https://news.ycombinator.com/item?id=8953368](https://news.ycombinator.com/item?id=8953368)

------
upofadown
The problem with using floating point to represent money has nothing to do
with base 2. It is that money is generally treated as something countable. If
you divide a dollar in thirds the resulting third of a cent is not exactly
representable in base 10 either.

~~~
reikonomusha
Base-2 _is_ a problem in accounting because the written value doesn't always
actually numerically equal what's being represented internally. With decimal,
you don't have that problem, because we write in decimal.

The bigger problem however is how precision is "managed" with floats, which
leads to things like non-associativity of operations.

~~~
inglor
Yes, but the way we write decimals doesn't represent numbers very easily, for
example 10/3 can't be represented accurately with finite length decimals (but
can with rationals)

~~~
ricardobeat
Thus you'll never see anything being sold for "a third of a dollar".
Accounting and finance have specific rules for rounding these, which can then
be replicated with precision.

------
al2o3cr
Rational-as-default seems like an odd choice. It prevents catastrophic
cancellation (the ".1 + .2 - .3" from the article is an example) but at the
cost of pathological complexity for some operands. For instance, summing the
harmonic series (nth term is 1/n) means doing massive amounts of factoring to
keep intermediate results in lowest terms...

~~~
perlgeek
> For instance, summing the harmonic series (nth term is 1/n) means doing
> massive amounts of factoring to keep intermediate results in lowest terms...

There is a feature in Perl 6 that the OP didn't mention: if the denominator
doesn't fit into a 64 bit integer anymore, it falls back to floating point
arithmetic.

There's a type (FatRat,
[http://doc.perl6.org/type/FatRat](http://doc.perl6.org/type/FatRat)) that
stays precise if you really want, but the default give precise arithemtics for
"usual" numbers without pathologic slow-down for pathologic cases.

~~~
xioxox
Is this kind of mixed rational/floating point sensible? It seems to be a fuzzy
do-what-I-mean, not what-I-say kind of arithmetic. Surely weird differences in
algorithm behaviour might occur around the 64 bit integer limit. It will also
make the analysis and testing of numerical algorithm accuracy very difficult
unless you can put bounds on your input values.

~~~
leoh
I feel like this "do what I mean not what I say" is exactly what I have found
so irksome about Perl

------
Derbasti
Another language that supports this is Julia: In Julia, `/` is division, but
`//` creates a rational number. Thus, in Julia, `1//10 + 2//10 - 3//10 ==
0//1`, and `1 / (1//10 + 2//10 - 3//10) == 1//0`, where `isinf(1//0) == true`
and `0//1 == 0`.

But the best thing is that because of Julia's type system, every subsequent
operation on rationals will happen rationally as well, including (fast) linear
algebra. Obviously this excludes things like `sqrt` or `fft`.

([http://docs.julialang.org/en/release-0.3/manual/complex-
and-...](http://docs.julialang.org/en/release-0.3/manual/complex-and-rational-
numbers/#rational-numbers))

~~~
cnvogel
> Another language that supports this is Julia:

As does, for example, scheme (tests done in racket).

    
    
        > (- (+ (/ 1 10) (/ 2 10)) (/ 3 10))
        0
        > (= (- (+ (/ 1 10) (/ 2 10)) (/ 3 10)) 0)
        #t

------
arocks
I prefer Python's explicit approach to decimal types:

    
    
      $ python -c "from decimal import Decimal as D; print(D('.1')+D('.2')-D('.3'))"
      0.0
    

Or if you prefer true rational numbers:

    
    
      $ python -c "from fractions import Fraction as F; print(F('.1')+F('.2')-F('.3'))"
      0
    
      $ python -c "from fractions import Fraction as F; print(F('3.1415927'))"
      31415927/10000000

~~~
herge
What other languages call all-important features Python calls a module in the
standard library :)

~~~
draegtun
You could say the same thing about perl5 then :)

    
    
        $ perl -E "use bignum; say .1 + .2 - .3"
        0
    
        $ perl -E "use bigrat; say .1 + .2 - .3"
        0
    
        $ perl -E "use bigrat; say 3.1415927 / 1"
        31415927/10000000
    

ref:
[http://perldoc.perl.org/bignum.html](http://perldoc.perl.org/bignum.html) |
[http://perldoc.perl.org/bigrat.html](http://perldoc.perl.org/bigrat.html)

------
excitom
I like the comparison to COBOL. Another IBM language of similar vintage is RPG
(Report Generator) and it also uses packed decimals.

The control flow is:

\- Run a set of zero or more statements once at the beginning

\- Run a set of statements once per input record

\- Run a set of zero or more statements once at the end

I was always struck by the similarity to:

BEGIN { ... }

while (<>) {

    
    
      ...
    

}

END{ ... }

~~~
agumonkey
Because these are two basic building blocks of 'computation', I'd say first
order. It's map and reduce in disguise (or the other way around, doesn't
matter).

    
    
      - [record] -> [derived from record] :: map
      - Begin and End blocks are accumulator/stateful logic :: reduce
    

sed is also a little twisted version of awk, per line mapping, with pattern
spaces for accumulations.

It's first order, because it can't reuse itself on smaller pieces of data,
namely recursion (grammars, trees, etc)

------
lucianp
Interesting! I wonder what drove their decision to use rational number
representation. Is it possible to turn this feature off and use floating point
instead (for performance reasons, let's say)?

~~~
wwweston
IIRC, there's several numeric types that conform to the larger `Numeric` type
family: `Rat`, `Int`, and `Num` (which is basically a float).

`Rat` is what falls out of the expressions the OP was working with, specifying
you want `Num` is possible.

------
aidenn0
COBOL used packed decimals, not rationals; fixed precision BCD is quite
different from arbitrary precision rationals.

------
0x0
What is the "unicode tapeworm operator"? Google didn't yield much more than
this post?

~~~
jerf
It is the Unicode Pile of Poo [1] with a Combining Cedilla [2]. In Perl 6, a
language that makes Haskell look shy with its operators, you can presumably
make this into an operator. You definitely can with the pile of poo itself
[3], but I don't know if throwing a combining character in there does anything
bad since I've never done it myself.

[1]:
[http://www.fileformat.info/info/unicode/char/1f4a9/index.htm](http://www.fileformat.info/info/unicode/char/1f4a9/index.htm)

[2]:
[http://www.fileformat.info/info/unicode/char/327/index.htm](http://www.fileformat.info/info/unicode/char/327/index.htm)

[3]: [http://blog.mattoates.co.uk/2012/02/perl6-and-fun-with-
unico...](http://blog.mattoates.co.uk/2012/02/perl6-and-fun-with-unicode-
operators.html)

------
marktangotango
Someone should point his declaration "01 TOTAL PIC S9(4)V9(2)." isn't packed,
it's display.

~~~
Ovid
Damn. That's what I get for writing that late at night with a glass of wine in
my hand. Plus, I haven't done COBOL for 15 years :)

------
bane
I'm very eager for Perl 6 1.0 to come out. I'm even planning on carving out a
few weeks to learn it.

I've really poo poo'd the tardiness and vaporware aspects of P6, but I'm
starting to get excited again.

Some of the new stuff looks absolutely sublime.

~~~
brongondwana
As Larry said during the talk at Fosdem - Lord of the Rings took 14 years to
be written too, but it doesn't matter how long something took to write once
it's done. That's all in the past.

------
ScottBurson
Of course COBOL, though it has packed decimals, doesn't have general rational
numbers. Zetalisp (aka Lisp Machine Lisp) was the first language I know of
that had general rationals (ratios of two arbitrary-precision integers).

------
kevin_thibedeau
What are the consequences of using rational numbers by default? I can imagine
unexpected bloat when large arrays are in use that you expected to contain
native floats but are now a more complex object.

~~~
perlgeek
You only get compact storage if you declare the array with a type constraint
on the elements, so at that point you start to actively think about the
numeric type, and can still convert to floating point if that's what you want.

------
kganser
Crockford's Dec64 proposal has some interesting background on decimal
representation: [http://dec64.org/](http://dec64.org/)

------
visarga
Seems like it's right around the corner. So, when will we have an online
course with lessons and exercises for P6? I'd like a set of problems and some
quick presentations to work through.

About P6 - I especially like how it becomes more functional-ish and has more
consistent notation. Also, the new grammars.

It will probably see more adoption when it is preinstalled in all Linux
distros.

~~~
perlgeek
> So, when will we have an online course with lessons and exercises for P6?

If you start that project, I'll certainly support you in any way I can.

------
rvanmil
Another very popular ;) language which supports packed decimals (and decimal64
& decimal128 ) is ABAP.

    
    
        data result_float type f.
        result_float = '0.1' + '0.2' - '0.3'.
        write: / result_float.
        >> 5.5511151231257827E-17
    
        data result_packed type p length 4 decimals 4.
        result_packed = '0.1' + '0.2' - '0.3'.
        write: / result_packed.
        >> 0.0000
    
        data result_d16 type decfloat16.
        result_d16 = '0.1' + '0.2' - '0.3'.
        write: / result_d16 decimals 16.
        >> 0.0000000000000000
    
        data result_d34 type decfloat34.
        result_d34 = '0.1' + '0.2' - '0.3'.
        write: / result_d34 decimals 34.
        >> 0.0000000000000000000000000000000000

------
ape4
Perl 5 has packed decimal.

------
seesomesense
15 years and Perl 6 is still "just around the corner" Does anyone care anymore
?

Perl is largely irrelevant, killed off by the advent of better scripting
languages. The inordinate length of time that the incompatible Perl 6 has
taken has not earned it any friends either.

