4 ms·

Perl 6 started around when perl 5.8 was released. Then Perl 5 went stagnant while most of the core language developers were working on Perl 6. After a few yea

Perl 6 started around when perl 5.8 was released. Then Perl 5 went stagnant while most of the core language developers were working on Perl 6. After a few years where there were competing implementations of perl 6, and still some wild ideas being tested, folks that still were using Perl 5 watched the rest of the languages develop, and the growing buglist against perl 5, and starting poaching ideas from Perl 6, ruby, python, and improving the Perl 5 runtime. Eventually, The Perl 5 camp committed to regular releases, and continued renewed development in the engine, and it is still pretty good. But the damage has been done @ this point -- a lot of the community has wandered off to other 'cool' languages and frameworks. The confusion will continue, especially since it's become clear Perl 6 is quite the departure from Perl 5, and there is a LOT of code in the wild using Perl 5. I've seen some talk of the Perl 5 folks asking Larry Wall to rename Perl 6, but he's declined to do so. With perl6's grammar support, some folks are working on importing the perl5 grammar into perl6[0]. Fortunately, there's a very rich testing environment(in the form of CPAN) to ensure this effort will be stable. [0] https://github.com/rakudo-p5/v5/ https://github.com/rakudo-p5/v5/

kbenson 11y ago
The alternative to v5 is Inline::Perl5[1], which instead of defining a mode that understands Perl 5 syntax and maps it to the underlying Perl 6 runtime, actually embeds a Perl 5 interpreter and handles all the back and forth automatically. The benefit of this approach is that XS modules still work (you can use Per 5's DBI in Perl 6 using Perl 6 syntax). 1: https://github.com/niner/Inline-Perl5 https://github.com/niner/Inline-Perl5
inopinatus 11y ago
> a lot of the community has wandered off to other 'cool' languages and frameworks I am just one such. Half my career was writing Perl. But these days, most of my work is in Ruby and as a longtime fan of Erlang (but never having had the opportunity to use it in production), I'm taking a long look at Elixir+Phoenix. This tutorial wasn't enough to entice me back to Perl, and I'm wondering if there is anything at all that could. In general we choose a language for their applicability to the problem domain. The focus on text manipulation in Perl 4, and then extension of this with an object framework in Perl 5, made it a shoo-in in the 90s and early C21 when we all needed form parsing, HTML template stuffing, and email mangling tools. In these days of dynamic DOM manipulation and event-driven microservices, it doesn't seem so relevant; whilst Node and Go and Elixir look entirely on point. If you go look at the Perl 6 FAQ, there's a section, "Why should I learn Perl 6?". It lists a grab-bag of language features, rather than a set of problems that Perl 6's new design can solve. As a result it feels much like a solution in search of a problem. That wasn't even ever true of JavaScript, even though JS took years to come of age. If I was designing a language today, and I am not, but if I were, I would look at how dominant Java seems to be in the big data community and try knocking it off that perch with appropriate language primitives, constructs and libraries. It seems to me this is the modern problem domain homologous to the bulk text mangling for which Perl originally became famous.
- tragomaskhalos 11y ago
  Having somehow avoided much Perl for most of my working life, I've recently done quite a bit of it (Perl 5 this is), and I have found it, syntactically, a painful experience when compared to Ruby and Python. The one thing I have loved compared to those two though is the performance. If Perl 6 retains that performance edge it may gather mindshare, but otoh my impression of Perlists that I work with is that they are quite content with Perl 5's warts, so I am not convinced that 6 will have much of an impact.
  - kbenson 11y ago
    If I have one piece of advice for people coming from other languages into Perl 5, it's to not be fooled by some similar looking syntax into thinking it should be used like C or any other C-like language. I find assumptions in that vein are often what leads people to painful assumptions about the language. If I had time for a second piece of advice, it would to be sure you understand context in Perl 5[1]. Everything is based around context, and to not be aware of how it factors in to the current expression often leads to befuddlement (at best) or anger. On the flip side, context is often where Perl shines. I recommend Chromatic's excellent Modern Perl: The Book[1] if you feel any of this might apply to you. Finally, Perl can be a very Lispy language. Avoiding those parts (map, grep, etc) is sort of like consciously avoiding every even gear when driving a car. Possible, but much more painful than using it as designed. Edit: Oh, you probably want that reference I implied up above. 1: http://modernperlbooks.com/books/modern_perl_2014/ http://modernperlbooks.com/books/modern_perl_2014/ covers context in multiple sections.
- muraiki 11y ago
  For event-driven microservices, I think Perl 6 is actually a great choice. I have experience writing some small things in Go and Node.js, but Perl 6 offers much more powerful high-level features for handling async, concurrency, and parallelism. Promise combinators are built into the language to provide composable concurrency. But unlike using something like Q in Node.js, you can truly perform tasks across promises in parallel (and with static typing to boot!) Perl 6 has channels for when you want Go style semantics, but you also have Supplies for when you want their dual: instead of pushing events through channels you pull them reactively. This allows you to write highly declarative code; see https://gist.github.com/muraiki/222814d5928f648be3c1 https://gist.github.com/muraiki/222814d5928f648be3c1 I think that P6 will also be awesome for data munging. Here's a pipeline that processes text from a file with 4 parallel workers. my $lines = open('foo.json', :r).lines.hyper(batch => 20, degree => 4) my $filter = $lines.grep: -> $line { $line ~~ /someregex/ }; my $json = $filter.map: &from-json; my $foos = $json.grep: *<some_property> == 'foo'; say $foos.list[8]; Since the operations are done in scalar context, they essentially operate lazily, pulling one value through the chain at a time. The pipeline is only activated once coerced to list context at the end, and only enough values as are required to find the 9th match are processed. I've used Elixir before. It has some great features and having the power of BEAM and OTP is quite awesome. But sometimes the actor model is not what you want. I think that Perl 6 will be not just a great glue language, but also a powerful language for writing multi-paradigm applications that meet the demands of modern systems.
raiph 11y ago
> But the damage has been done @ this point -- a lot of the community has wandered off Do you think the Perl community should have tried to slow down or reverse the exodus?
raiph 11y ago
> With perl6's grammar support, some folks are working on importing the perl5 grammar into perl6[0]. If someone just wants to run Perl 5 code, especially from CPAN, Inline::Perl5 is the answer, not v5.

kbenson 11y ago

The alternative to v5 is Inline::Perl5[1], which instead of defining a mode that understands Perl 5 syntax and maps it to the underlying Perl 6 runtime, actually embeds a Perl 5 interpreter and handles all the back and forth automatically. The benefit of this approach is that XS modules still work (you can use Per 5's DBI in Perl 6 using Perl 6 syntax). 1: https://github.com/niner/Inline-Perl5 https://github.com/niner/Inline-Perl5

inopinatus 11y ago

> a lot of the community has wandered off to other 'cool' languages and frameworks I am just one such. Half my career was writing Perl. But these days, most of my work is in Ruby and as a longtime fan of Erlang (but never having had the opportunity to use it in production), I'm taking a long look at Elixir+Phoenix. This tutorial wasn't enough to entice me back to Perl, and I'm wondering if there is anything at all that could. In general we choose a language for their applicability to the problem domain. The focus on text manipulation in Perl 4, and then extension of this with an object framework in Perl 5, made it a shoo-in in the 90s and early C21 when we all needed form parsing, HTML template stuffing, and email mangling tools. In these days of dynamic DOM manipulation and event-driven microservices, it doesn't seem so relevant; whilst Node and Go and Elixir look entirely on point. If you go look at the Perl 6 FAQ, there's a section, "Why should I learn Perl 6?". It lists a grab-bag of language features, rather than a set of problems that Perl 6's new design can solve. As a result it feels much like a solution in search of a problem. That wasn't even ever true of JavaScript, even though JS took years to come of age. If I was designing a language today, and I am not, but if I were, I would look at how dominant Java seems to be in the big data community and try knocking it off that perch with appropriate language primitives, constructs and libraries. It seems to me this is the modern problem domain homologous to the bulk text mangling for which Perl originally became famous.

tragomaskhalos 11y ago
Having somehow avoided much Perl for most of my working life, I've recently done quite a bit of it (Perl 5 this is), and I have found it, syntactically, a painful experience when compared to Ruby and Python. The one thing I have loved compared to those two though is the performance. If Perl 6 retains that performance edge it may gather mindshare, but otoh my impression of Perlists that I work with is that they are quite content with Perl 5's warts, so I am not convinced that 6 will have much of an impact.
- kbenson 11y ago
  If I have one piece of advice for people coming from other languages into Perl 5, it's to not be fooled by some similar looking syntax into thinking it should be used like C or any other C-like language. I find assumptions in that vein are often what leads people to painful assumptions about the language. If I had time for a second piece of advice, it would to be sure you understand context in Perl 5[1]. Everything is based around context, and to not be aware of how it factors in to the current expression often leads to befuddlement (at best) or anger. On the flip side, context is often where Perl shines. I recommend Chromatic's excellent Modern Perl: The Book[1] if you feel any of this might apply to you. Finally, Perl can be a very Lispy language. Avoiding those parts (map, grep, etc) is sort of like consciously avoiding every even gear when driving a car. Possible, but much more painful than using it as designed. Edit: Oh, you probably want that reference I implied up above. 1: http://modernperlbooks.com/books/modern_perl_2014/ http://modernperlbooks.com/books/modern_perl_2014/ covers context in multiple sections.
muraiki 11y ago
For event-driven microservices, I think Perl 6 is actually a great choice. I have experience writing some small things in Go and Node.js, but Perl 6 offers much more powerful high-level features for handling async, concurrency, and parallelism. Promise combinators are built into the language to provide composable concurrency. But unlike using something like Q in Node.js, you can truly perform tasks across promises in parallel (and with static typing to boot!) Perl 6 has channels for when you want Go style semantics, but you also have Supplies for when you want their dual: instead of pushing events through channels you pull them reactively. This allows you to write highly declarative code; see https://gist.github.com/muraiki/222814d5928f648be3c1 https://gist.github.com/muraiki/222814d5928f648be3c1 I think that P6 will also be awesome for data munging. Here's a pipeline that processes text from a file with 4 parallel workers. my $lines = open('foo.json', :r).lines.hyper(batch => 20, degree => 4) my $filter = $lines.grep: -> $line { $line ~~ /someregex/ }; my $json = $filter.map: &from-json; my $foos = $json.grep: *<some_property> == 'foo'; say $foos.list[8]; Since the operations are done in scalar context, they essentially operate lazily, pulling one value through the chain at a time. The pipeline is only activated once coerced to list context at the end, and only enough values as are required to find the 9th match are processed. I've used Elixir before. It has some great features and having the power of BEAM and OTP is quite awesome. But sometimes the actor model is not what you want. I think that Perl 6 will be not just a great glue language, but also a powerful language for writing multi-paradigm applications that meet the demands of modern systems.

raiph 11y ago

> But the damage has been done @ this point -- a lot of the community has wandered off Do you think the Perl community should have tried to slow down or reverse the exodus?

raiph 11y ago

> With perl6's grammar support, some folks are working on importing the perl5 grammar into perl6[0]. If someone just wants to run Perl 5 code, especially from CPAN, Inline::Perl5 is the answer, not v5.