Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Why should any one use/learn Perl 6?

by skooma (Novice)
on Jun 04, 2018 at 13:15 UTC ( [id://1215821]=perlquestion: print w/replies, xml ) Need Help??

skooma has asked for the wisdom of the Perl Monks concerning the following question:

I am a beginner in Perl. I code most of my code using Perl 5. I recently heard about Perl 6. How good it is when compared with Perl 5? Why should I learn to code with Perl 6?

Replies are listed 'Best First'.
Re: Why should any one use/learn Perl 6?
by moritz (Cardinal) on Jun 04, 2018 at 13:44 UTC

    This is a topic that is very subjective, so take my answer with a grain of salt

    Advantages to learning Perl 6 over Perl 5:

    • Often the error messages are better
    • Many concepts are easier to learn (for example much easier OO, fewer edge cases with closures)
    • Much better support for asynchronous and parallel programming
    • Up-to-date books (around 8 books released in the last 18 months or so)

    Advantages to learning Perl 5 over Perl 6:

    • More material online
    • Broader user base
    • More stable, and usually faster by default
    • Broader module base

    Pick your poison :)

Re: Why should any one use/learn Perl 6?
by woolfy (Chaplain) on Jun 04, 2018 at 13:32 UTC
      > This forum is very good to find a lot of resources about Perl 5.

      This forum nevertheless welcomes questions regarding the whole Perl spectrum, including Perl 6 ! =)

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery

        This forum nevertheless welcomes questions regarding the whole Perl spectrum, including Perl 6 ! =)
        Yes, you're right and I agree with you, but there are unfortunately quite a few monks around here who have very negative knee-jerk reactions to Perl 6.
Re: Why should any one use/learn Perl 6?
by haj (Vicar) on Jun 07, 2018 at 15:17 UTC

    I've been following this discussion for some time... because right now I am about to learn Perl 6. I have been intending to do this for quite a while now, occasionally invigorated by problems which are cumbersome to solve in Perl 5. The main motivations were:

    • The object system: I liked the ideas set out for Perl 6's object system from the beginning. But then, it turned out that it was easier to bolt on many of the ideas onto Perl 5 with Moose than for Perl 6 to come close to maturity. Moose is awesome but somewhat syntactically challenged because it needs to feed its stuff to a Perl 5 parser, so Perl 6 still has a slight edge here.
    • The grammars: Several years ago I had a problem which could be easily formulated as a grammar, but was tedious to do with regexes. Unfortunately, the same several years ago Perl 6 was just too slow to process a 15MB file. I'd expect this to be no longer an issue as of today, but I won't re-implement my Perl 5 program (because I don't have that problem any more, for a start).
    • Parallelism: Doing this right in Perl 5 needs a lot of boilerplate which can go away with the Perl 6 builtin mechanisms.
    On Perl 6 IRC I see a lot of nifty one-liner solutions in Perl 6 for problems which I never had in the past, and probably never will have in the future. I'll simply ignore those, though they add noise to the manuals. So while I am walking through the Perl 6 intro and am typing experimental stuff into an interactive Perl 6 shell, I am also accumulating a list of things I would prefer not to see in productive code. I'll most certainly never use these myself. Here are a few of them:
    • Single quotes and minus signs in variable names.
    • Letters with diacritics in variable names. I'm getting old, my eyesight isn't the best. For my own code, I'll stick to ASCII.
    • Literals like ½ for numbers.
    • Quoting functions with three or more letters. qqw qww qqww. Seriously? The whole quoting manpage looks more than scary for me.
    • Unicode operators which I don't see on my keyboard.
    • ...and maybe more to come.
    Bottom line: I will continue to learn Perl 6, though I'm slightly annoyed by the noise of incredibly clever features which don't contribute much to solving my problems. I expect to see benefits from using Perl 6 in case of complex object setups (the syntax is easier on the eye than Moose can ever achieve), for server software (parallelism, and also the builtin exceptions), event handling (where is the Perl 6 native GUI?) and the like.

      Parallelism: Doing this right in Perl 5 needs a lot of boilerplate ...

      Fake news!

      See MCE and MCE::Shared.

      Consider the following utility script to delete records from a customer account in a global cloud services provider using their API:

      use strict; use warnings; use feature 'say'; use Data::Dumper; use MyClient; my $client = MyClient->new; my $list = $client->call('ListCustomers'); $list->parse_json_payload; say sprintf 'Start: Found %d accounts.', $list->payload->{totalCount}; my %results; for my $account ( @{ $list->payload->{items} } ) { my $id = $account->{id}; say "Deleting $id"; my $call = $client->call('DeleteCustomer', { account_id => $id }); say 'Status: ' . $call->status; $call->status == 204 ? $results{OK}++ : $results{NOT_OK}++; } say 'Results: ' . Dumper \%results; __END__

      Now, parallelized with MCE. Too much boilerplate?

      use strict; use warnings; use feature 'say'; use Data::Dumper; use MyClient; use MCE; use MCE::Shared; my $client = MyClient->new; my $list = $client->call('ListCustomers'); $list->parse_json_payload; say sprintf 'Start: Found %d accounts.', $list->payload->{totalCount}; tie my %results, 'MCE::Shared'; sub task { my $id = $_->{id}; my $output = "Deleting $id\n"; my $call = $client->call('DeleteCustomer', { account_id => $id }); say $output . 'Status: ' . $call->status; $call->status == 204 ? $results{OK}++ : $results{NOT_OK}++; } MCE->new( chunk_size => 1, max_workers => 7, user_func => \&task ); MCE->process( $list->payload->{items} ); MCE->shutdown; say 'Results: ' . Dumper \%results; __END__

      Note that in the second version, we can still just use $call->status == 204 ? $results{OK}++ : $results{NOT_OK}++; even though we have 7 workers writing to the same hash.

      (Also note that MCE provides comprehensive signal handling, so if you use an END block (not shown here) to print out your results hash (for example), you can kill the script eg with CTRL-C, and all workers will exit gracefully, while only the parent prints out the data so far.)

      You sure as hell don't need Cuckoo, errr, notPerl "6", or anything other than Perl to write clean, fast, correct, parallel code that can be used today in performance-critical environments, aka Real Life.

      Hope this helps!


      The way forward always starts with a minimal test.
        You sure as hell don't need Cuckoo, errr, notPerl "6", or anything other than Perl to write clean, fast, correct, parallel code that can be used today in performance-critical environments, aka Real Life.

        Why can't you just be positive? Always so negative!

        I hadn't heard about MCE yet. By the looks of it, it has taken the ideas I had when I implemented the forks and ThreadPool modules to the next level. Kudos to Mario Roy.

        Now to get back to your example, but then in Perl 6:

        use MyClient; my $client = MyClient.new; my $list = $client.call('ListCustomers'); $list.parse_json_payload; say "Start: Found $list.payload.totalCount() accounts"; my %results; for $list.payload.items -> $account { my $id = $account.id; say "Deleting $id"; my $call = $client->call('DeleteCustomer', account_id => $id); say 'Status: ' . $call.status; $call.status == 204 ?? %results<OK>++ !! %results<NOT_OK>++; } say "Results: %results.perl()"

        To make this run on multiple CPU's, one basically needs to do only one thing: prefix the for with a hyper;

        hyper for $list.payload.items -> $account {

        There is however one caveat: hashes in Perl 6 are not thread safe in the sense that they might lose updates when being updated from multiple threads. If you're just interested in number of successes / fails, why not make it two counters instead of elements in a hash? When updating integers from multiple threads, you should use atomic integers (otherwise you would have the same problem as with the hash elements). So the code becomes:

        use MyClient; my $client = MyClient.new; my $list = $client.call('ListCustomers'); $list.parse_json_payload; say "Start: Found $list.payload.totalCount() accounts"; my atomicint $ok; my atomicint $not-ok; hyper for $list.payload.items -> $account { my $id = $account.id; say "Deleting $id"; my $call = $client->call('DeleteCustomer', account_id => $id); say 'Status: ' . $call.status; $call.status == 204 ?? atomic-inc-fetch($ok) !! atomic-inc-fetch($ +not-ok) } say "Results: ok = $ok, not-ok = $not-ok"

        I've used the ASCII equivalent of the atomic increment operator, since PerlMonks does not display the unicode equivalent "++⚛️" inside code blocks properly.

        So I would argue three things here:

        1. Perl 6 has less boilerplate to begin with (no use statements needed)
        2. Perl 6 needs less boilerplate to parallelize (just adding "hyper" will do in many cases
        3. Some thought needs to go into updating data structures from multiple threads at the same time

        Note that the Perl 5 solution to updating shared data structures requires tieing and locking, neither of which is good for performance. The Perl 6 solution using atomic increment is lockless and uses hardware features of the CPU.

        Hope this clarifies.

        EDIT: fixed $results{} -> %results<> non-migrato, haj++

        I wasn't aware of that module (MCE). Thanks for the info!

        I still prefer to refer to Perl 6 as "Camelia" :)

      I am also accumulating a list of things I would prefer not to see in productive code. I'll most certainly never use these myself.
      Knowing what keeps people from learning Perl 6 is interesting to note, especially as I've submitted a TPF grant proposal to write a book to help people learn it. I'd like to process the points you list here, and see if we can reach a common ground.
      Single quotes and minus signs in variable names.
      Generally, I use double quotes for strings, unless there's a reason that those don't work well. Very few programmers want to care about which kind of quote to use per string, they'd rather just have a single go-to quoting character that works in almost every case. It's also very common to want to show something in your string that is not just static text, so double-quote string interpolation is often used. On the minus signs in variable names, I was unsure about this when I started with Perl 6 as well, because I was not used to it. I tried to avoid them in variables and sub names. But they're completely valid in Perl 6, and read pretty nice. They're also correctly handled in interpolated strings, which was my biggest worry. Once I realized they're not breaking anything I started using them more often than underscores, since a minus is easier to produce (no shift required) and they read nicer to me.
      Letters with diacritics in variable names.
      These I still avoid, since they're hard to produce for many people. Generally, I write my code in an English mindset, so words with diacritics aren't a common sight anyway.
      Literals like ½ for numbers. Unicode operators which I don't see on my keyboard.
      I'm gonna take these two together as they are the same issue as far as I'm concerned. Fancy Unicode characters that people don't have as a generic key on their keyboard. I actually do not avoid these. I'm using vim as my editor, which has a plugin to convert Texas ops to Unicode ops on-the-fly. I wonder if CommaIDE does the same. If it doesn't, it should. You note yourself that it's explicitly about Unicode operators you don't see on your keyboard. Would you oppose these operators still if there was a clean solution to create these operators that worked for you? Like your editor automatically converting them for you, or a certain script that you could run over your source files that would convert them automatically (which could be hooked into another process).
      Quoting functions with three or more letters. qqw qww qqww.
      I think many of these "large quoting constructs" are confusing, especially to people new to the language. I personally avoid them.
        About 3.5 years ago, I posted Quoting on Steroids, which hopefully made some sense to some. :-)
Re: Why should any one use/learn Perl 6?
by Anonymous Monk on Jun 13, 2018 at 20:03 UTC
    Perl6 seems like an elaborate practical joke. Compared to Perl5 many things are literally backwards for no apparent reason (pop @array is now @array.pop because, it's backwards! yay). Since array elements are scalars you logically use $array[n] in Perl5, but Perl6 does away with all that: @array[n] :-(

    The English-like ease and logic of Perl5 is gone, replaced by more abstract concepts expressed in bizarre constructs and... UNICODE. If these kinds of radical changes were attempted for the languages we speak the joke's hostile intent would be much more apparent (let's create illiterates). It has been clear from the beginning that Perl6 is a reaction to Perl5 by people who hate Perl5 and want something else. So haters are writing the new language and this includes Larry who refers to the ways of Perl5 as "Warts"!

    Too bad all that work didn't go towards improving Perl5 to meet and beat all the challengers it has been beaten to hell by in the past 20 years.

    http://design.perl6.org/Differences.html

      pop @array is just as legal in Perl 6 as it is in Perl 5. TIMTOWTDI, remember?

      If you have ever taught Perl 5 to a group of newbies, than you will have know that sigil variance is one of the hardest things to explain. In Perl 6 you should consider the sigils (and the twigils) as part of the name. That makes it also much easier to explain indexing on sigilless variables (yes, Perl 6 haz them)!

      Wrt "haters writing a new language": I was not aware that Perl 6 was written by Python devs :-)

      Wrt "Warts": Even a rock star programmer has code that they've written in the past that they would now do differently. Larry is no different.

      Wrt "Too bad": Looking back on what might have been, will not help us in the future. Perl 5 will not go away. Perl 6 won't go away either. They are both the result of a Perl mindset.

      Perlmonks are so... excellent. Thank you (Your Mother & liz) for exposing my ignorance gently. I didn't know we could timtowdi old syntax. How far does it go? I've done some reading but not that Perl 5 code can be dropped into Perl 6.

      > sigilless variables (yes, Perl 6 haz them)!

      Is that good? I thought barewords were bad practice. It's been pounded into our heads not to use the old global open FILE convention so now we write open my $file. I realize the implementation is problematic but the original logic of uppercase bare filehandles seems sound considering their relation to STDIN and friends. Is Perl6 going back to the future?

      > There is nothing at all stopping Perl 5 from success today except a lack of applications;

      That could change overnight. There's an absurd amount of raw power in the Perl ecosystem. What if we decided to deploy as much functionality of CPAN as possible into something like http://blogs.perl.org/users/yang_bo/2018/04/a-new-linux-distribution-with-perl-as-its-heart.html? I'm sure it would rock.

      > and general inability to compile or deploy directly to mobile.

      Why is that? Does TPF need to fund a grant? How hard is it?

      github.com/mid1221213/perldroid www.corion.net/talks/perl-on-android/perl-on-android.en.html blog.thireus.com/how-to-install-ios-perl-framework-on-iphone-ipod-touc +h-or-ipad/

      > If no one had stepped up

      Perl 5 has evolved very nicely thanks to its modular architecture.

      > the game and its rules

      This place has the best referees :-)

      Perl 5 will not go away. Perl 6 won't go away either. They are both the result of a Perl mindset.

      I guess it doesn't matter, sorry for the rant https://github.com/niner/Inline-Perl5

        ++ You have a good attitude and that was a kinder reply than I had coming. :P

        I do my best to be a Perl booster but I am much busier today than 10 years ago when I was much more active at it. I don't have any specific recommendations for apps/code today but there are a few areas Perl has fallen behind Java and Python in particular in libraries. Medical systems in particular. Perl was the first through the door and there are still some terrific pieces like UMLS::Similarity but in most other important areas, like HL7 and DICOM, Perl is lacking. It's where I work today and I would love to have a crack at fixing the situation but it's too much work, the standards are wide and generally badly designed, and there are already C/C++ and Java libs to do everything I need.

        I've done some reading but not that Perl 5 code can be dropped into Perl 6.

        Indeed, you can not. But like the Queen's English vs American English, they look very much alike. With subtle differences. -> became ., . became ~, sigils don't vary, and you must put a comma after the block in a map. But by and large, you can write Perl 5-style in Perl 6, just as you can write C-style in Perl 5. Even moreso if you use P5built-ins, which exports a growing number of functions (currently at 100 or so) that exist in Perl 5, with the same semantics as in Perl 5. Think about things like tie, opendir, pack/unpack, but also things that exist in Perl 6 but have magic attached (such as shift shifting from @_ or @ARGV by default).

        I thought barewords were bad practice.

        Indeed they are, they don't exist in Perl 6. A sigilless variable needs to be defined: it usually indicates an alias. E.g. in a for loop:

        for @foo -> \element { say element }

        Or as a direct alias to a value in a hash:

        my %hash; my \foo = %hash<FOO>; dd %h; # Hash %h = {} foo = 42; dd %h; # Hash %h = {:FOO(42)}

        So, no, those are not barewords like Perl 5 has them. Perl 5 will happily accept say BAR as valid syntax, Perl 6 does not (unless you have defined BAR in that scope).

        $ perl6 -e 'say BAR' ===SORRY!=== Error while compiling -e Undeclared name: BAR used at line 1

        And yes, all of Perl 5 CPAN is available at your fingertips if you have Inline::Perl5 installed. The only thing you need to do, is to add :from<Perl5> to your use statement, so e.g.

        use DBI:from<Perl5>; use DBD::mysql:from<Perl5>; my $dbh = DBI.connect(...); # call DBI->connect(...) under the hood

        It really can't get much simpler than that, I would say, thanks to all the hard work of Stefan Seifert

      Disagree completely, on every point; with the possible exception of semantic scalar/array/hash sigils. There is nothing at all stopping Perl 5 from success today except a lack of applications; and general inability to compile or deploy directly to mobile. Plenty of us are completely happy with Perl 5 as it stands.

      The blocking issue is the world wants applications, not programming languages. If no one had stepped up to do Catalyst, DBIC/Rose, Moose, Plack, a handful of the better ::Tiny modules, Unicode, and date handling and all the fantastic ecology those things enabled and inspired then Perl would already be completely dead as a professional greenfield language.

      Armchair project managers are worse than armchair quarterbacks. At least the armchair quarterback usually knows something about the game and its rules.

A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://1215821]
Approved by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others scrutinizing the Monastery: (3)
As of 2024-03-28 15:40 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found