
Why Would Anyone Use Perl 6? - hankache
http://blogs.perl.org/users/zoffix_znet/2016/01/why-in-the-world-would-anyone-use-perl-6.html
======
MichaelBurge
Perl tends to be a practical language: Perl programmers are too busy working
on their product to rebuke scathing criticisms from angry bloggers and the
peanut gallery. But that angry blogger? He'll get a mob together and start
protesting outside your house if he catches you using the wrong Javascript
library.

I say don't worry about the criticism and popular opinion: The specific
language you use is pretty far down the list of problems that a given software
might have. You'll build up some useful libraries in your niche and eventually
other people will see that the most time-effective way to solve a problem in
that niche is to use Perl 6 to get access your libraries.

Every other language I use derives from its specific purpose: Ruby because
vendors like PayPal or AWS publish Ruby gems(and because of Rails); Haskell
for writing parsers, interpreters, and compilers(ADTs and parsing monads); C
if I'm trying to understand some code and need it to be portable or
operationally simple; Perl 5 if it's a quick prototype script. Just the other
week I needed a Bayesian variant of Prolog and would've used Perl 6 if it had
a library for it.

~~~
muraiki
I think I'm just surprised and saddened that HN heaps so much hatred on P6. I
mean, we're a community of hackers: do we really need to ask "why another
programming language"?

The hatred P6 receives here reminds me a lot of the hatred Go used to receive,
where every article posted devolved into a discussion regarding the lack of
generics. I bought into the "Go is a regression" meme for a long time until I
started using it to solve real problems at work, and now I love it.

I hope that we programmers can learn to rejoice in each other's creations
rather than to heap scorn and criticism on anything not from our particular
tribe. It reminds me of people who insist that you can only like a single
video game console... heaven forbid you use more than one, or one with
inferior graphics (but with more fun games!), etc.

~~~
lmm
> I mean, we're a community of hackers: do we really need to ask "why another
> programming language"?

If not us, then who? There is plenty of space for a language that delivers
real innovation, or even one that puts real polish on old ideas. But when a
language does neither, we absolutely should be asking what it's for. A
community that prides itself on being pragmatic and delivering business value
should know the costs of language proliferation.

~~~
muraiki
Gradual typing, reactive programming, PEG grammars and language extension via
those grammars... the list goes on. Innovation and polish abounds, yet we have
comments like yours, which are completely uninformed. I thought HN was better
than this, but perhaps there's no escaping eternal september.

~~~
wtetzner
Also "correct" unicode support, treating grapheme clusters as characters.

------
muraiki
I could give a list of features as to how Perl 6 will make my life as a
developer better, but a list of features is not enough to justify adopting a
whole new language with a small ecosystem. To adopt a language, it really has
to improve your productivity. For instance, I think we've seen this with Go's
adoption by people from dynamic languages, as it offered type safety, speed,
and concurrency in a package that was generally more readily acceptable to
them than Java/C#/Scala/etc.

jnthn has a great series of blog posts illustrating how many of Perl 6's
features come together to make developing a library very easy. To me, this is
a great example of "how does Perl 6 help a business": by allowing rapid
development of a complex asynchronous application, which is a use case many of
us face. He illustrates this by writing a STOMP client for RabbitMQ, going
from toy to a serious library: [https://6guts.wordpress.com/2016/01/04/not-
guts-but-6-part-1...](https://6guts.wordpress.com/2016/01/04/not-guts-
but-6-part-1/)

I look at this workflow and think, "Wow, I wish I could do things that
easily." But now I can, because Perl 6 is out. :)

~~~
hahainternet
I too have been admiring Jnthn's latest posts. The reactive programming
displayed is really quite lovely. God it actually makes me want to develop an
asynchronous client! The only other language that makes me feel that way is
Go.

------
harryf
From 3 minutes playing, junctions are cool...

    
    
        #!/usr/bin/env perl6
    
        if 3|4|5 == 5|6 {
            print "Junction found\n"
        } else {
            print "No junction\n"
        }
    

...or using arrays this seems to be the way to do it...

    
    
        #!/usr/bin/env perl6
        my @first = <3 4 5>;
        my @second = <5 6>;
    
        if any(@first) == any(@second) {
            print "Junction found\n"
        } else {
            print "No junction\n"
        }

~~~
hbex5
That both indicates to me why Perl 6 is cool, and also why it's a bit mad.
Junctions, in the core language? Really? Wouldn't they be best placed just
being a library?

~~~
Ovid
Junctions are insanely useful once you get used to them and I use them
frequently. Basically, any time you have a list and you're worried the
properties of _any_ , _all_ , or _none_ of the list members (hmm, just about
all lists), then junctions are often a very clean way of expressing the issue.

    
    
        if all(@ages) >= 18 {
            # let 'em in the club
        }
    

Or:

    
    
        if any(@ages) < 18 {
            # don't let 'em in the club
        }
    

Or:

    
    
        if none(@ages) < 18 {
            # don't let 'em in the club
        }
    

So I use logic like the above quite a bit, however, there are plenty of areas
where the above can be _better_ if it's deeply integrated into the language.
In this case, as already mentioned, it's auto-threading where appropriate.
That's not an easy feature to get right if it's not baked into the language,
but it's a huge win if done right.

Perl 6 also has gradual typing baked in. Other languages have gradual typing
as a library, but that often fails dramatically
([http://blog.circleci.com/why-were-no-longer-using-core-
typed...](http://blog.circleci.com/why-were-no-longer-using-core-typed/)). In
Perl 6, because it's built-in, not only are the failures described something
Perl 6 can avoid, but there are also plenty of type checks Perl 6 can avoid
_at run time_ with integrated gradual typing (imagine that benefit in hot
loops).

You could even combine that with native junction auto-threading and presumably
have super-fast comparisons where the needs for checking types is eliminated
at run time because it's already been done at compile time. If you do that
with libraries, it's awfully tricky to get right, if not impossible.

------
aikah
> Why in the world would anyone use Perl 6? Well... it's the little things.

The issue is, why would anyone want to move from Ruby/Python/Js to Perl in
2016...

Obviously most Perl users understand the benefits of Perl 6.

~~~
signa11
> The issue is, why would anyone want to move from Ruby/Python/Js to Perl in
> 2016...

actually not quite. given the plethora of libraries/frameworks etc. for
perl-5, why would _perl-5_ programmers move to perl-6 ?

~~~
brudgers
My intuition is that current users of Perl 5 probably fall largely into two
camps: using it because it looks like the best tool for the job or using it
because it is the language of their soul.

People in the first group would switch if Perl6 looks like a better tool.
Short of revelation the second group won't. Hardcore Perl programmers have had
a long time to think about Perl 6 and come to their conclusions. It's not a
community where evangelism is likely to make a difference these days. I don't
think the Perl community is like the Python community for cultural reasons
that stem from their histories.

~~~
gaius
Perl 5's killer app is CPAN. It will be a looooong time before Perl 6 can
compete.

~~~
kbenson
You seem to be under the impression that Perl 6 can't use Perl 5 CPAN modules.

[https://github.com/niner/Inline-Perl5](https://github.com/niner/Inline-Perl5)

~~~
gaius
What advantage does running Perl 5 code in the Perl 6 runtime give you? Is it
enough to warrant switching?

~~~
kbenson
Depending on how you look at it, the advantage is either all of the Perl 5
ecosystem plus whatever Perl 6 brings to the table, or the lack of a
disadvantage through not having a large module ecosystem, depending on how
charitable you want to be.

Not to mention, you also have Inline::Python[1], and conceivably any other
runtimes they want to embed. I think it would be interesting to see what you
get by taking the best of class in each ecosystem and using them. It may or
may not scale well due to data marshalling, but it's definitely something new
(at least the ease of it is) and, IMO, worth looking into.

1: [https://github.com/niner/Inline-Python/](https://github.com/niner/Inline-
Python/)

------
edem
So what are the answers to these questions?

\- Version 6.c? Why not 6.0?

\- What's with the whole "language" and "compiler" distinctions no one cares
about?

\- Why is the first stable release of the compiler not optimized to the max?

\- Is there a need for a new Perl? What is it good for?

\- What is its business case?

\- Why in the world would anyone use Perl 6?!

If I want to transform my 100.000 line program to a smaller one I won't grab
Perl 6 to transform it to 50.000 but I will grab Clojure for example to
transform it to an 5.000 one. Is that the only argument for using Perl 6?

~~~
steveklabnik
I'm a guy with a Camel tattoo who found Ruby and never went back to Perl, but
have followed Perl 6 out of nostalgia. Here's the answers as I understand
them:

    
    
      - Version 6.c? Why not 6.0?
    

This is first, a reflection of the playfulness of Perl, and second, a
statement about language design. The first release, an alpha, was 6.a. The
second, a beta, was 6.b. The third, the actual 'final' release, was 6....c?
Since it was being released on Christmas, and 'c' fits, it was decided that
releases of Perl 6 would be named after holidays, and they went back and found
them for A and B too.

As for the statement about language design, I'll add that onto the next one,
as it makes more sense in that context.

    
    
      - What's with the whole "language" and "compiler" distinctions no one cares about?
    

"Perl 6" is a _language_, not an _implementation_. There's a language spec,
and any implementation of this spec is a Perl 6. This is a distinction that a
lot of projects make, but is a lot fuzzier, because they don't have specs.
Consider Ruby: yes, JRuby is also a Ruby, but since there's no language spec,
people still assume MRI when you say "Ruby". Perl people don't want you to
assume Rakudo when discussing the language itself.

This is why there's no minor version of "Perl 6". Language specifications
change a lot less frequently than compilers.

    
    
      - Why is the first stable release of the compiler not optimized to the max?
    

Like most projects, as long as performance is Good Enough, it's good to get
people start using it, and then work on performance after. Especially for a
language where performance isn't a main goal, like Perl. As long as you
haven't painted yourself into a corner with language decisions, performance
improvement is refinement work.

    
    
      - Is there a need for a new Perl? What is it good for?
    

I don't know if there's a _need_, but Perl 6 sure improves on a ton of things
about Perl 5. It's the stuff that makes Perl Perl, but turned up to 22, not
just 11.

The last two are questions I can't really answer.

------
blisterpeanuts
Thanks for the interesting discussion on Perl6; will have to try some of these
cool new syntactical features.

I haven't had much need of Perl recently; trying to force myself to switch to
Python (a jarring psychological experience) not because I hate Perl but
because Python seems to be where a lot of the demand is these days.

But I learned something else of great importance from this article: cowsay

I'd never heard of cowsay before but it's an amazing tool! I installed it on
my SuSE workstation (sudo zypper install cowsay) and on my Mac (brew install
cowsay) and it just makes me happy! My favorite command is:

ls|cowsay

------
smacktoward
The universe of people writing Perl 6 code at the moment is very small.
Responding to every critique of the language with "hey, it works for ME!" is a
great way to ensure it never gets any bigger.

~~~
hahainternet
Please point out a critique of the language in this thread.

------
rurban
If I want speed on massive concurrent cores I would choose pony. If I want
safety, I would choose pony. If I want to keep my old libs and scripts I would
choose cperl. But perl6 is a nice language still, a dinosaur like Common LISP.

~~~
fuck_dang
Except that huge corporations use both Perl and Common Lisp on a daily basis.
Craigslist, Google, etc.

So you have some old perl scripts laying around, but they work well enough and
some guy takes care of them, updating them when they need. He knows perl and
that's his job, so whatever. One day, the architecture changes and the scripts
need to go parallel. That's a problem because the perl guy doesn't know Pony
(a promising language with a community even smaller than perl6...) and really
needs to get these scripts running again.

So he uses Perl6 along with the inline module, and things are working again.
Over time, he hacks up a better system in vanilla Perl6, and deploys that too.
He had such a great time using Perl6 that he even hacks up a few more tools he
could use, etc etc, next thing you know he's a Perl6 developer.

I write ruby because it is modeled similarly to how I think about problems,
but if I was a perl guy, I could see the appeal to Perl6, but saying that it's
a dinosaur is both wrong and irrelevant to the FUD surrounding Perl6 right
now. At this point, it's about adoption.

------
draw_down
It's great that you like Perl 6. You can just come out and say that, you know.

------
xenadu02
Most languages/platforms adopted regular expressions from Perl. I rather
suspect most will eventually adopt Perl 6 grammars and that may be its lasting
impact.

------
forgotmyalias
I don't get why anyone has any hopes for Perl6. It took 16(!) years to
implement features other languages already have. And CPAN is the dark, sad pit
of forgotten and abandoned packages. Is there really a significant chance that
people will switch to Perl6 from any other not-perl alternative or embrace it
as a first language.

~~~
obsurveyor
It's kind of sad to hear that about CPAN, it used to be pointed at as the only
bastion of package organization.

~~~
jandrese
CPAN still works fine. Some of it is due to Perl not changing fundamentally in
a long time so some old package from 2005 is still likely to work today. Most
breakage I've found comes from external dependencies, packages that load data
from websites tends to decay very quickly if not maintained for example.

That said, it is still good practice to try to avoid dependencies on packages
that are not maintained, or you might find yourself the de-facto maintainer of
the package. This is true across all languages.

Perhaps one of the most enduring legacies of Perl is that no language that
comes after it can be considered complete until it has its own CPAN like
package management system. That and the regular expression engine of course.

------
TeeWEE
A language should be minimal, easy to learn. On top of it you can build
libraries. It should NOT be build into the language... To bad thats the
direction Perl went from the start. It was usefull for text formatting, if you
know all the quirks... But as a language to build big systems... I would never
chose it.

~~~
awwaiid
LISP fan? :)

The trick of course is that then your libraries effectively define your
language. There are various sweet-spots of native-language features, standard-
lib features, and external libraries. I think it is a matter of taste and
trade-offs.

------
Grue3
> perhaps writing if 5 < x and x < 100 instead of the much clearer if 5 < $x <
> 100

Why not "if 5 < x < 100"? Sigils look awful.

~~~
hahainternet
> Why not "if 5 < x < 100"? Sigils look awful.

Because sigils tell you things. What if 'x' in your example is a list? Are you
now checking the length of the list rather than the value? Sounds like room
for a security bug to me.

~~~
lmm
> Because sigils tell you things. What if 'x' in your example is a list? Are
> you now checking the length of the list rather than the value? Sounds like
> room for a security bug to me.

Only if your language is really awful. A good language shouldn't even let you
run "5 < x" when x is a list, but even a mediocre one would surely at least
make that error out at runtime rather than giving a nonsense answer.

~~~
hahainternet
> Only if your language is really awful. A good language shouldn't even let
> you run "5 < x" when x is a list, but even a mediocre one would surely at
> least make that error out at runtime rather than giving a nonsense answer.

It depends what you consider "Nonsense". Python for example has no reliable
way to differentiate between a string and a list. Strings are iterable, but
lists can't be compared with the < syntax for example.

My point is simply that $x very clearly says (in Perl 6) "A single value
called x" wheras @x is "A list of values called x". In python, "x" is
indeterminate even at runtime.

Oh, and you can declare barewords with \x for example, if you really want to,
it is Perl after all.

~~~
DonHopkins
What version of Python can't differentiate between a string and a list, or
compare lists?

    
    
        Python 2.7.10 (default, Jun 10 2015, 19:42:47)
        [GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin
        Type "help", "copyright", "credits" or "license" for more information.
        >>> type([1])
        <type 'list'>
        >>> type('1')
        <type 'str'>
        >>> type(1) == type('1')
        False
        >>> [1] < [2]
        True
        >>> [2] < [1]
        False
        >>>
    

I consider it "Nonsense" to abuse overloaded context sensitive strings of
punctuation with arbitrary rules of precedence and associativity, instead of
English words correctly spelled out of letters that people can look up
alphabetically in a reference manual and google for tutorials to find out what
they mean.

~~~
hahainternet
Sorry I should have made things more clear. I am talking about in things like
function signatures.

Doing something like isinstance(x, str) is discouraged and considered non-
pythonic, and recently hasattr() has also been talked about. However, both
strings and lists can be iterated, so assuming that this will fail is
incorrect:

    
    
        x = "Hello"
        for y in x:
            print("{} is {}".format(y, type(y)))
    
    

I asked on IRC and ultimately the only answer I got was that the most pythonic
way to do things was to name functions whatever_str and whatever_list.

edit: I also should have said above "lists can't be compared with strings
using <". I was trying to point out Python did things potentially correctly
there, but I see now it's ambiguous.

~~~
DonHopkins
If it's so important to decorate variables with unique punctuation to visually
distinguish between two particular kinds of many possible types, then why
don't you also decorate function calls according to whether they return lists
or scalars?

How should you decorate functions that return different types depending on
what context they're used in?
[http://perlmaven.com/wantarray](http://perlmaven.com/wantarray)

If it's so important to visually distinguish the names of scalars and arrays,
then shouldn't you also be able to distinguish a string from an int, like
BASIC's a$ -vs- i%?

So why just distinguish lists and scalars? Why not go all the way to Hungarian
Punctuation and use Unicode and Emoji characters to uniquely decorate
variables for every other possible built-in and user defined type?
[https://en.wikipedia.org/wiki/Hungarian_notation#Relation_to...](https://en.wikipedia.org/wiki/Hungarian_notation#Relation_to_sigils)

~~~
hahainternet
You might be a little confused, I'm pretty sure that wantarray and the concept
of functions caring about context is entirely gone in Perl 6. Now you are
expected to return objects which 'do the right thing'.

However, if you really want to do some of the other things you've listed they
are possible to do. Perl 6's syntax can be augmented by the programs being
executed.

I'm honestly interested though, was I ultimately wrong above? Is there a smart
way to define a function in python that can take both a single item and a list
of items? In Perl 6 I'd just define a multi sub where the list form applies
the single item sub for each item in the list.

~~~
DonHopkins
It might be gone from Perl 6, but the idea of dividing all possible types into
two different classes, and then using punctuation to distinguish variables
holding those two classes, is from Perl 5, just like the idea of functions
caring about the context of their return value.

If Perl 6 is an entirely new language, then why is it riddled with so many bad
ideas from another language that only coincidentally shares the first 4
alphabetic characters of its name?

Why the artificial scalar/array dichotomy? What is it that is so important
about being able to distinguish variables holding scalar-like values and
array-like values by punctuation, but it doesn't matter that you can't
distinguish variables holding strings and integers by their punctuation?

And how can you be consistent about types that act like both scalars and
arrays, like strings? Or user defined types that might behave like scalars or
arrays but are represented by objects? Are those treated as arrays? Or are
they references, treated as scalars?

Scalar -vs- array is a false dichotomy that's deeply and unnecessarily
embedded in the very syntax of the language.

~~~
hahainternet
I'm not entirely sure you've illustrated that it's a bad idea. I believe that
I illustrated that a simple pattern is not easily doable in Python but is in
Perl 6. You'll have to show that this is a bad pattern or the implementation
is bad or something at least to prove your point.

There's more to sigils than just scalars and arrays too, as you can see here:
[http://doc.perl6.org/language/variables#Sigils](http://doc.perl6.org/language/variables#Sigils)

The difference in your examples are that scalars describe more the 'shape' of
the variable than its type. Given that a _lot_ of programming is dealing with
lists or 'dictionaries' this is a fairly minimal intrusion into the code that
very much improves succinctness, correctness and the ability to easily read
what some code is doing.

Oh, and strings don't act like arrays in Perl 6 AFAIK. Because they could be
split on characters, or codepoints, or bytes, you must be explicit:

    
    
        > for "Hello".comb -> $c { say "Character $c" }
        Character H
        Character e
        Character l
        Character l
        Character o
    
    

(Or to be perly)

    
    
        > .say for "Hello".comb

~~~
DonHopkins
What's wrong with using "isinstance(lst, str)" when necessary?

The few cases when you need to make that distinction aren't worth infecting
the rest of the code with punctuation marks. Using letters to explicitly spell
out self-documenting words in the few function names that need to make that
distinction is much less intrusive, more flexible, unambiguous and capable of
precisely distinguishing many more nuances, than using a small set of
punctuation characters throughout all of your code to mitigate rare problems
with just a few cases.

Of course it can be taken to an extreme, but it's much easier to guess or
google for the meaning of an Objective C selector than for a bunch of Perl
punctuation.

[http://stackoverflow.com/questions/15152171/what-is-the-
long...](http://stackoverflow.com/questions/15152171/what-is-the-longest-
method-name-you-have-seen-in-ios-cocoa-touch)

~~~
hahainternet
> What's wrong with using "isinstance(lst, str)" when necessary?

In order for it to be like the Perl6 implementation I would have to check
against every type of iterable AFAIK. For example, a generator would be
perfectly acceptable, but is there a unique function I could check with
hasattr?

Clearly you feel that sigils are intrusive in Perl 6, but having written a
bunch I find it quite enjoyable, and they're pretty easy to find in the
documentation too. Ultimately, you can use variables without sigils, but with
caveats:
[http://doc.perl6.org/language/variables#Sigilless_variables](http://doc.perl6.org/language/variables#Sigilless_variables)

~~~
lmm
> In order for it to be like the Perl6 implementation I would have to check
> against every type of iterable AFAIK. For example, a generator would be
> perfectly acceptable, but is there a unique function I could check with
> hasattr?

Define what it is you want - which function you want to use - and then check
that (e.g. if you want to iterate over it check for __iter__; if you want to
want to test membership check for __contains__). In one part of the code a
generator might be acceptable; in another it might not. Which is the point
really - array vs scalar seems like a simple, sensible, widely usable
distinction on first glance, but it turns out the meaning you actually want is
very context-dependent, and a global distinction is a lot less useful than it
appears.

~~~
hahainternet
If I check __iter__ I consume strings too which is what I'm trying to avoid.
Both of you have taken the perspective that this distinction is irrelevant but
neither of you have a good answer to this case:

    
    
        > multi sub hi($a) { say "Hello there $a" }
        > multi sub hi(@a) { hi($_) for @a }
    
        > hi("lmm")
        Hello there lmm
        > hi(<lmm DonHopkins>)
        Hello there lmm
        Hello there DonHopkins
    

__Surely __this is not so exceptional a use case?

~~~
lmm
That sounds like a really perverse use case to me. Why would you want one
function to have two completely different behaviours depending on what it was
called with? If you want two different behaviours, write two different
functions.

~~~
hahainternet
I resisted replying to Don as I didn't think he presented any actual argument.
The "Write two functions" crew haven't thought this through though.

Ultimately, the scenario I came across this in was an atomic transaction
decorated function. The data being provided to this function flows through a
good 3 or 4 functions beforehand. I also require _single, _list and
_listoflists behaviour. This would bloat a 4 function stack into something
like 20 different functions. There are also issues with transaction
decorators.

It just seems crazy to me that Python can't manage this (to me trivial) use
case.

~~~
lmm
> I also require _single, _list and _listoflists behaviour.

So it sounds like your needs don't align exactly with perl's sigils anyway
(and why should they? For different business requirements you'd categorize
differently).

> This would bloat a 4 function stack into something like 20 different
> functions.

Not with good language/design. Separate your concerns. Let the difference in
behaviour live somewhere more appropriate - either on an object that contains
the data (OO style) or in a callback you pass into the function (functional
style).

> There are also issues with transaction decorators.

Decorators have problems yes, that's why I prefer to have a type system handle
that kind of thing.

~~~
hahainternet
> So it sounds like your needs don't align exactly with perl's sigils anyway
> (and why should they? For different business requirements you'd categorize
> differently).

Indeed but I can write constraints in my function signature to permit this.
Hell I can even define something as SpecialList[SpecialKey] if I truly wanted.
Perl has a type system.

> Not with good language/design. Separate your concerns. Let the difference in
> behaviour live somewhere more appropriate - either on an object that
> contains the data (OO style) or in a callback you pass into the function
> (functional style).

Doing this in Python is an exercise in horror, frustration and hatred. Doing
it in Perl is the work of a few seconds. That is my point.

~~~
lmm
> Indeed but I can write constraints in my function signature to permit this.
> Hell I can even define something as SpecialList[SpecialKey] if I truly
> wanted. Perl has a type system.

Interesting. Is this a new thing?

> Doing this in Python is an exercise in horror, frustration and hatred. Doing
> it in Perl is the work of a few seconds. That is my point.

Then what's the perl example without using sigils? Does that not translate
directly into python?

~~~
raiph
> Interesting. Is this a new thing?

What is the single "thing" you're referring to and what is "new" relative to?

I interpret hahainternet's comment to refer to at least three new things in
Perl 6 relative to Perl 5: Perl 6 has a carefully developed type system, roles
support parametric polymorphism, and both static and dynamic type constraints
on parameters are supported.

\-----

You earlier wrote "If you want two different behaviours, write two different
functions". But hahainternet _had_ written two different functions. This
suggests you hadn't then yet taken on board what multidispatch is (a
fundamental innovation -- from the 80s iirc -- related to declaring and
calling functions).

Then you responded to hahainternet's "This would bloat a 4 function stack into
something like 20 different functions." with "Let the difference in behaviour
live somewhere more appropriate ... on an object that contains the data (OO
style) ..." without realizing that that's _less_ appropriate, not more:

"In the presence of multiple dispatch, the traditional idea of methods as
being defined in classes and contained in objects becomes less appealing"
(from
[https://en.wikipedia.org/wiki/Multiple_dispatch](https://en.wikipedia.org/wiki/Multiple_dispatch)).

A similar argument applies to callbacks.

All in all I'm guessing you haven't yet seen the light about multidispatch and
a read of
[https://en.wikipedia.org/wiki/Multiple_dispatch#Perl_6](https://en.wikipedia.org/wiki/Multiple_dispatch#Perl_6)
might help clear some things up.

~~~
lmm
> What is the single "thing" you're referring to and what is "new" relative
> to?

The type system and perl 5. That would have been a much more constructive
response to "why perl 6?" (if it's as good as you say) than this article.

> You earlier wrote "If you want two different behaviours, write two different
> functions". But hahainternet had written two different functions. This
> suggests you hadn't then yet taken on board what multidispatch is (a
> fundamental innovation -- from the 80s iirc -- related to declaring and
> calling functions).

No need to be rude. Rather than argue over whether the cases of a multimethod
are different functions or the same function, let me just clarify that if you
want two different behaviours then it is clearer to give them different names.

> "In the presence of multiple dispatch, the traditional idea of methods as
> being defined in classes and contained in objects becomes less appealing"
> (from
> [https://en.wikipedia.org/wiki/Multiple_dispatch](https://en.wikipedia.org/wiki/Multiple_dispatch)).

That article is decidedly non-neutral. I'm well aware of multiple dispatch. I
find it very bad for code maintainability, and often a sign of poor domain
modeling. The interaction between two objects is an unnatural and opaque place
for behaviour to live; usually the behaviour belongs to one or the other or on
its own, or if their relationship is that complex it should probably be
promoted to a first-class entity.

~~~
raiph
>> What is the single "thing" you're referring to and what is "new" relative
to?

> The type system and perl 5.

Gotchya. Perl 6 is not a Perl 5 update. There are reasons it shares the name
Perl, which usually become obvious if you know both langs, but for non-users
it's best to think of Perl 6 as a completely new language.

> That would have been a much more constructive response to "why perl 6?"

I think the OP article was a mostly good humored response to the reality that
a lot of responses to Perl 6 are absurd. Like individuals sincerely asserting
that it should not be taken seriously by anyone for any commercial purpose --
because of perceived problems with the logo chosen by the language design
team!

> (if it's as good as you say)

Uhoh. Did I say Perl 6 is good? I think, right now, it's a lot of fun if
you're in to all sorts of PLs. But let me restore balance in the force. The
language isn't equational and its type system isn't Hindley Milner. Compiled
code is very slow and consumes a lot of RAM and fully fixing that is going to
take many years worth of engineering. The doc needs tons more work. There are
only a handful of modules. It's a new and unproven language. Balance restored?

> No need to be rude.

My apologies. I didn't mean to be rude.

(I looked over your other responses in this thread prior to posting my comment
and none suggested to me that you were claiming familiarity with multidispatch
and several suggested to me that you did not really have a feel for how they
work out when properly used in Perl 6.)

> Rather than argue over whether the cases of a multimethod are different
> functions or the same function, let me just clarify that if you want two
> different behaviours then it is clearer to give them different names.

Gotchya.

Nit: multidispatch in Perl 6 works for any function and (almost) any operator
(operators are actually just functions), not just methods.

The Perl 6 view is that multi functions/ops/methods have both a "short" name
and a "long" name. The short name is the bit that goes before the parameters.
The long name includes the signature. It's a different perspective on naming
and I find it works well for me.

> I find it very bad for code maintainability, and often a sign of poor domain
> modeling. The interaction between two objects is an unnatural and opaque
> place for behaviour to live; usually the behaviour belongs to one or the
> other or on its own, or if their relationship is that complex it should
> probably be promoted to a first-class entity.

I hear you've encountered use of multiple dispatch that you don't like, and
that it's often signaled poor design, and that you think that the code
placement for a multimethod is fundamentally unnatural.

But I don't hear that you've encountered multiple dispatch for functions
and/or operators rather than methods; or that you've seen the scenarios in
which it is a good fit for coding (I presume you don't think there's literally
no sweetspot use-case); or that you've had a chance to work with a language
like Perl 6 in which multimethod placement is as you suggest. So it sounds
like you have only encountered limited and perhaps poorly designed and/or used
multiple dispatch and that's colored your perspective.

Anyhoo, thanks for the exchange, and I hope you get another chance to use Perl
6 for something it's good at and see that, whatever else may be true, it is a
lot of fun. :)

