Ask HN: Perl 6: Do you use it, how do you like it, what do you do with it?
I'm sort-of intrigued by Perl 6, but a curiosity of mine, which I believe that I share with some other people, is how it's used in the real world, be it in little scripts or commercial software. What are your feelings and comments on Perl 6, and if you use it, how and where you use it (I'd be glad it people shared links to published projects and actual code out in the internet). Thanks in advance!
162 comments
Hi there! I used Perl5 for about 10 years. Web programming, sys admin tools, parses, so on. It's true (IMHO) that Perl5 tends to be a language "with hard to find job". So, recently I tried something new. I had some experience with Ruby/chef but I wanted something I feel more familiar in my background and I noticed a Perl6 a halve year ago, it was just around a time when first stable release appeared ( maybe 1-2 years before, but anyway ... ). Well what I can say? Perl6 is certainly proper choice for former Perl5 developers ( not only for them, but I am looking from my perspective ). Yeah there is lack of modules in comparison with CPAN but I don't treat this a big issue, all great projects started in the past with little eco system, so I guess it is only a question of nearest 5 years. Take a look at http://modules.perl6.org/ - new modules get added weekly!
Another thing - you may start a brand new code with Perl6, it is always a green field in automation / ops tasks.
Do I use a Perl6 in production? Yes I do. Recently I have updated ~ 500 servers with the help of Sparrowdo - http://sparrowdo.wordpress.com/ - a configuration management tool written on Perl6.
So for sure - Perl5 folks please look at Perl6. Other people as well :) It's neat, modern language.
Regards
Alexey
Another thing - you may start a brand new code with Perl6, it is always a green field in automation / ops tasks.
Do I use a Perl6 in production? Yes I do. Recently I have updated ~ 500 servers with the help of Sparrowdo - http://sparrowdo.wordpress.com/ - a configuration management tool written on Perl6.
So for sure - Perl5 folks please look at Perl6. Other people as well :) It's neat, modern language.
Regards
Alexey
Substantial amount of Perl6 goodness is already baked one way or another in ES6/7, Python 3.x, Scala and even the modern C# and C++14/17. Speaking of stuff like concurrency, C3 resolution, object proxies (a.k.a AUTOLOAD), introspection/reflection, promises, reasonable regex engine, etc.
As far as speed is concerned - with the modern approach to concurrent programming, it does not really make a difference which of the above languages you'd choose, as long as your architecture is right. IO::Async may in many scenarious be faster than Node, Perl devs are probably 2x the price of a JS guy...
So the question for Perl6 is really - when, if ever, is it going to have tools like npm, make, pip to simplify the maintenance of a project. Not to mention proper debugger (i.e. Perl6 debugging plugin for VSCODE).
Perl6 is a lot of syntax even for Perl5 oldies like myself, and I'll need a very long list of assurances to convince any client/manager/colleague to take this road. Because chances are I end up being the only living soul on the planet able to maintain my Perl6 code.
After all - R&D is not only about the initial writing (that'd be 15-20% of all time), but also debugging (huge part), CI (some 15-20%), and post-release support.
Unfortunately languages like Scala and ES6 are presently way more appealing with already-complete ecosystems of tools and editors. They also provide pretty much the same performance for likewise non-enterprise projects. On the contrary - in order to introduce Perl6 in an enterprise (where Perl5 is still considered an option), one would have to have a very convincing set of arguments...
As far as speed is concerned - with the modern approach to concurrent programming, it does not really make a difference which of the above languages you'd choose, as long as your architecture is right. IO::Async may in many scenarious be faster than Node, Perl devs are probably 2x the price of a JS guy...
So the question for Perl6 is really - when, if ever, is it going to have tools like npm, make, pip to simplify the maintenance of a project. Not to mention proper debugger (i.e. Perl6 debugging plugin for VSCODE).
Perl6 is a lot of syntax even for Perl5 oldies like myself, and I'll need a very long list of assurances to convince any client/manager/colleague to take this road. Because chances are I end up being the only living soul on the planet able to maintain my Perl6 code.
After all - R&D is not only about the initial writing (that'd be 15-20% of all time), but also debugging (huge part), CI (some 15-20%), and post-release support.
Unfortunately languages like Scala and ES6 are presently way more appealing with already-complete ecosystems of tools and editors. They also provide pretty much the same performance for likewise non-enterprise projects. On the contrary - in order to introduce Perl6 in an enterprise (where Perl5 is still considered an option), one would have to have a very convincing set of arguments...
I chuckled the first time I saw 'use strict'; at the top of the javascript file. Node.js seems to be morphing more and more into Perl 5 with every new release.
I still chuckle, and try to remind everyone in the room that:
1) Node did not invent concurrency, Hoare did (if a single person should ever be credited on this), others understood the concept some 20 years.
2) Node was originally based on a library by a very-controversial, still largely acclaimed Perl contributor
3) 'use strict' is indeed a Perl idea, but (to a certain extent) is the JSON format
4) The first JS repository was not npm, but JSAN, and it was started (guess) by Perl guys back in 2005 (if I remember), now long abandoned.
Basically - after teaching JS and Perl for many years (10+ Perl, 4+ JS) I can confidently say that JS has always had a thing about Perl5 while Perl5 devs knew very well how to express stuff in JS from day 1, as both languages are originally very lexical, very dynamic and lazy, etc.
In fact the languages Perl / JS / Python are quite similar by nature. So what? We don't have Python in the browser, even though transpiling would've been so straightforward.
I fail to understand how it was not so-obvious-for-everyone that devs would spare syntax for cleaner source code. Its a very broad statement, but ES*, Python and Scala - all these have very clean syntax, and are very likely here to stay (probably Go should be in this list also). In fact - universities started using Python to teach introductory classes, rather than C. Guess why - strict rules, clear syntax, easy learning curve.
The motivation for this is that DEVs get easily replaced as a resource. And that's big in terms of planning and HR. Back in the 90's, Perl5 was a definite power-horse, because no dynamic language combined different coding phenomena so well. With all due regards for all the great minds that worked on Perl6 - nowadays, there are many smart languages. And Perl needs to do more than syntax/context/name-it magic to win back confidence.
1) Node did not invent concurrency, Hoare did (if a single person should ever be credited on this), others understood the concept some 20 years.
2) Node was originally based on a library by a very-controversial, still largely acclaimed Perl contributor
3) 'use strict' is indeed a Perl idea, but (to a certain extent) is the JSON format
4) The first JS repository was not npm, but JSAN, and it was started (guess) by Perl guys back in 2005 (if I remember), now long abandoned.
Basically - after teaching JS and Perl for many years (10+ Perl, 4+ JS) I can confidently say that JS has always had a thing about Perl5 while Perl5 devs knew very well how to express stuff in JS from day 1, as both languages are originally very lexical, very dynamic and lazy, etc.
In fact the languages Perl / JS / Python are quite similar by nature. So what? We don't have Python in the browser, even though transpiling would've been so straightforward.
I fail to understand how it was not so-obvious-for-everyone that devs would spare syntax for cleaner source code. Its a very broad statement, but ES*, Python and Scala - all these have very clean syntax, and are very likely here to stay (probably Go should be in this list also). In fact - universities started using Python to teach introductory classes, rather than C. Guess why - strict rules, clear syntax, easy learning curve.
The motivation for this is that DEVs get easily replaced as a resource. And that's big in terms of planning and HR. Back in the 90's, Perl5 was a definite power-horse, because no dynamic language combined different coding phenomena so well. With all due regards for all the great minds that worked on Perl6 - nowadays, there are many smart languages. And Perl needs to do more than syntax/context/name-it magic to win back confidence.
For those wondering what library he is talking about in point 2, that is libev by Marc Lehmann.
Before moving to libuv node was using libev for events and libeio for I/O
Whenever Node comes up somewhere, I wonder what happened to the original author of it, he was called Ryan, IIRC.
Ryan Dahl.
"Update on 11/24/2016: Dan Shaw, one of the founders of Node Source and NodeUp podcast said at SFNode that Ryan Dahl is into AI and machine learning."[1]
[1]https://www.quora.com/What-happened-to-Ryan-Dahl
"Update on 11/24/2016: Dan Shaw, one of the founders of Node Source and NodeUp podcast said at SFNode that Ryan Dahl is into AI and machine learning."[1]
[1]https://www.quora.com/What-happened-to-Ryan-Dahl
He dabbled in some other open source machine learning things on Github. Seems pretty off the grid. Recently published this paper: https://arxiv.org/abs/1702.00783
[deleted]
> Speaking of stuff like concurrency
Hang on. Python 3.x is an interpreter with a GIL. So, strike one lang from your list.
> C3 resolution
Perl 6 uses C3 by default for its own default object model but it's carefully designed to also interop with languages whose MRO is NOT C3.
That strikes out another couple of langs on your list (unless you don't care about nice lang interop).
> reasonable regex engine
Perl 6 parses itself with its rules engine. Try that with a reasonable regex engine. :)
Just as significant, most "reasonable regex engines" are tuned for dealing with codepoints, not characters[1]. In 2017, that's looking increasingly unreasonable.
> I'll need a very long list of assurances to convince any client/manager/colleague to take this road.
I think it'll be another few years before the list can get long enough for your situation. Maybe we'll see you further down the road?
[1] http://www.unicode.org/glossary/#grapheme
Hang on. Python 3.x is an interpreter with a GIL. So, strike one lang from your list.
> C3 resolution
Perl 6 uses C3 by default for its own default object model but it's carefully designed to also interop with languages whose MRO is NOT C3.
That strikes out another couple of langs on your list (unless you don't care about nice lang interop).
> reasonable regex engine
Perl 6 parses itself with its rules engine. Try that with a reasonable regex engine. :)
Just as significant, most "reasonable regex engines" are tuned for dealing with codepoints, not characters[1]. In 2017, that's looking increasingly unreasonable.
> I'll need a very long list of assurances to convince any client/manager/colleague to take this road.
I think it'll be another few years before the list can get long enough for your situation. Maybe we'll see you further down the road?
[1] http://www.unicode.org/glossary/#grapheme
I fail to see how the GIL stops you from creating concurrent code. JS i spretty much the same as Python when it comes to one-thread-per-process limitation. But concurrency is not about multi-threading, it is a different approach to multiprocessing. Basically Python's Twisted, and JS's Node expose similar concepts, as do Coro, IO::Async, etc. It's about coroutines and cooperative mutiltasking, so GIL is not an obstacle.
Speaking of C3 - Python is C3 by default, and while others are not, JS guys figured mixins, which give pretty much the same expression of "horizontal-composition". Besides, all dev moves towards functional programming, and people care less about MRO's as functional paradigms replace some complex OO paradigms.
Reasonable REGEXP engine means, that every sane language out there has some level of Perl5 (or PCRE) support. That is reasonable, as long as you don't get to parse mini-langs with grammers everyday. Don't get me wrong - I'm huge fan of Perl6 BNF-like notation for grammars, but see - grammars, FSMs, regexpes, so forth... these are different names/views/uses for the same thing. Most important is to understand the tools in a toolbox, not just to be happy about how shiny a particular screwdriver is.
I'm prepared to not take offense by your last comment. Its been days and I don't see a single comment of s.o. using Perl6 for enterprise stuff.
And, please, don't give me the Booking.com example, as its a bastion of Perl devs, that was started as Perl5 one, when Perl5 was big in a very different sense that Perl6 is today.
UPDATEL Just for the record - I've been waiting/following Perl6 news for ages, shaked Larry's hand at FOSDEM when he announced it, and still fail to find a reason to move to language with no CPAN, no BOOKS, with a very complex and comprehensive syntax and (as many pointed) no big enterprise to back its adoption...
Speaking of C3 - Python is C3 by default, and while others are not, JS guys figured mixins, which give pretty much the same expression of "horizontal-composition". Besides, all dev moves towards functional programming, and people care less about MRO's as functional paradigms replace some complex OO paradigms.
Reasonable REGEXP engine means, that every sane language out there has some level of Perl5 (or PCRE) support. That is reasonable, as long as you don't get to parse mini-langs with grammers everyday. Don't get me wrong - I'm huge fan of Perl6 BNF-like notation for grammars, but see - grammars, FSMs, regexpes, so forth... these are different names/views/uses for the same thing. Most important is to understand the tools in a toolbox, not just to be happy about how shiny a particular screwdriver is.
I'm prepared to not take offense by your last comment. Its been days and I don't see a single comment of s.o. using Perl6 for enterprise stuff.
And, please, don't give me the Booking.com example, as its a bastion of Perl devs, that was started as Perl5 one, when Perl5 was big in a very different sense that Perl6 is today.
UPDATEL Just for the record - I've been waiting/following Perl6 news for ages, shaked Larry's hand at FOSDEM when he announced it, and still fail to find a reason to move to language with no CPAN, no BOOKS, with a very complex and comprehensive syntax and (as many pointed) no big enterprise to back its adoption...
I'm with you on the books. I tried to learn Perl 5 from online resources, couldn't. Once I had books in hand, no problem.
The good news for Perl 6 is that books are incoming. O'Reilly has taken on both Learning Perl 6 (by the formidable teacher brian d foy) for a summer 2017 release, and Think Perl 6 (a translation of Think Python by Laurent Rosenfeld and Allen B. Downey; unedited draft available now). Moritz Lenz is developing his manuscript of Perl 6 by Example publicly on his blog (perlgeek.de), and Ken Youens-Clark has released an e-book on doing metagenomics in Perl 6, which includes a substantial Perl 6 tutorial.
As to CPAN, with Inline::Perl5 the entire Perl 5 CPAN is available to Perl 6 -- and if you call now, we'll throw in Inline::Python for no additional cost!
The good news for Perl 6 is that books are incoming. O'Reilly has taken on both Learning Perl 6 (by the formidable teacher brian d foy) for a summer 2017 release, and Think Perl 6 (a translation of Think Python by Laurent Rosenfeld and Allen B. Downey; unedited draft available now). Moritz Lenz is developing his manuscript of Perl 6 by Example publicly on his blog (perlgeek.de), and Ken Youens-Clark has released an e-book on doing metagenomics in Perl 6, which includes a substantial Perl 6 tutorial.
As to CPAN, with Inline::Perl5 the entire Perl 5 CPAN is available to Perl 6 -- and if you call now, we'll throw in Inline::Python for no additional cost!
> I fail to see how the GIL stops you from creating concurrent code.
I misread what you wrote. My apologies.
> concurrency is ... not about multi-threading
Agreed.
(Fwiw, I think part of what threw me is that almost all proglangs can do some concurrency -- folk have been forking with Perl for nearly 30 years -- but that reminds me of the notion that most proglangs are turing equivalent.)
> all dev moves towards functional programming, and people care less about MRO's as functional paradigms replace some complex OO paradigms.
Agreed.
> Reasonable REGEXP engine means ... PCRE
OK.
> grammars, FSMs, regexpes, so forth... these are different names/views/uses for the same thing.
(Agreed in a sense analogous to forking and SIMD being different names/views/uses of concurrency/parallelism/async.)
> Most important is to understand the tools in a toolbox, not just to be happy about how shiny a particular screwdriver is.
Agreed.
> I'm prepared to not take offense by your last comment. Its been days and I don't see a single comment of s.o. using Perl6 for enterprise stuff.
Apologies for the confusion but please note that I simply agreed with you and closed with a hopeful parting:
>>> I'll need a very long list of assurances to convince any client/manager/colleague to take this road.
>> I think it'll be another few years before the list can get long enough for your situation. Maybe we'll see you further down the road?
> Booking.com ... was started as Perl5 one, when Perl5 was big in a very different sense that Perl6 is today.
Agreed.
> still fail to find a reason to move to language with no CPAN
I think "no CPAN" doesn't do justice to where things are at.
1. In "IRC::Client: Perl 6 Multi-Server IRC (or Awesome Async Interfaces with Perl 6)" the author shows this code:
2. Yesterdays blog post about the Perl Toolchain Summit[1] includes this:
> there are people looking to leverage Perl 5 and CPAN in Perl 6, which is why we also invite Perl 6 toolchain developers
I don't think it'll be helpful to get into details in this comment, but from my vantage point the Perl community is not remotely as fractured as some folk seem to think. Perl 5 and Perl 6 are two very distinct and individually great languages that have been moving towards working with each other since the 2012 Perl Reunification Summit. (It's just gonna take time to make sure it's done in such a way that the language combination is worth more than the sum of its parts.)
> no BOOKS
One just came out and two O'Reilly titles are due this year, 'Think Perl 6' due in a couple months and bdfoy's 'Learning Perl 6' driven by his kickstarter campaign which raised $40K. Others are in progress too.
> with a very complex and comprehensive syntax
Well, that's a thing.
While I had a great time with Perl in the 90s, I have long struggled a bit, and sometimes more than a bit, with Perl 5 when going beyond real basics. It seemed to me to have a very complex and comprehensive syntax overall even after I'd begun reaching up to the 3rd and 4th levels of Perl mastery.
Perl 6 seems sooooo simple in comparison!
> and (as many pointed) no big enterprise to back its adoption...
Yes.
One bit of good news is that this hasn't and won't stop the evolution and maturation of Perl 6.
Another is that the project's improvement is grounded in its test suite. This provides the interesting possibility of corporations funding development and smoking of particular tests that matter to them. (Do you know if that is happening in Perl 5 space, Python, etc.?)
[1] http://blogs.perl.org/users/book/2017/02/about-the-perl-tool...
[2] http://perl6.party/post/IRC-Client-Perl-6-Multi-Server-IRC-M...
I misread what you wrote. My apologies.
> concurrency is ... not about multi-threading
Agreed.
(Fwiw, I think part of what threw me is that almost all proglangs can do some concurrency -- folk have been forking with Perl for nearly 30 years -- but that reminds me of the notion that most proglangs are turing equivalent.)
> all dev moves towards functional programming, and people care less about MRO's as functional paradigms replace some complex OO paradigms.
Agreed.
> Reasonable REGEXP engine means ... PCRE
OK.
> grammars, FSMs, regexpes, so forth... these are different names/views/uses for the same thing.
(Agreed in a sense analogous to forking and SIMD being different names/views/uses of concurrency/parallelism/async.)
> Most important is to understand the tools in a toolbox, not just to be happy about how shiny a particular screwdriver is.
Agreed.
> I'm prepared to not take offense by your last comment. Its been days and I don't see a single comment of s.o. using Perl6 for enterprise stuff.
Apologies for the confusion but please note that I simply agreed with you and closed with a hopeful parting:
>>> I'll need a very long list of assurances to convince any client/manager/colleague to take this road.
>> I think it'll be another few years before the list can get long enough for your situation. Maybe we'll see you further down the road?
> Booking.com ... was started as Perl5 one, when Perl5 was big in a very different sense that Perl6 is today.
Agreed.
> still fail to find a reason to move to language with no CPAN
I think "no CPAN" doesn't do justice to where things are at.
1. In "IRC::Client: Perl 6 Multi-Server IRC (or Awesome Async Interfaces with Perl 6)" the author shows this code:
use IRC::Client;
use Mojo::UserAgent:from<Perl5>;
class Bash {
...
has $!ua = Mojo::UserAgent.new;
...
method !fetch-quotes {
$cache.send:
$_ for $!ua
.get($BASH_URL)
.res
.dom
.find('.qt')
.each».all_text
.lines
.join: ' ';
}
}
2. Yesterdays blog post about the Perl Toolchain Summit[1] includes this:
> there are people looking to leverage Perl 5 and CPAN in Perl 6, which is why we also invite Perl 6 toolchain developers
I don't think it'll be helpful to get into details in this comment, but from my vantage point the Perl community is not remotely as fractured as some folk seem to think. Perl 5 and Perl 6 are two very distinct and individually great languages that have been moving towards working with each other since the 2012 Perl Reunification Summit. (It's just gonna take time to make sure it's done in such a way that the language combination is worth more than the sum of its parts.)
> no BOOKS
One just came out and two O'Reilly titles are due this year, 'Think Perl 6' due in a couple months and bdfoy's 'Learning Perl 6' driven by his kickstarter campaign which raised $40K. Others are in progress too.
> with a very complex and comprehensive syntax
Well, that's a thing.
While I had a great time with Perl in the 90s, I have long struggled a bit, and sometimes more than a bit, with Perl 5 when going beyond real basics. It seemed to me to have a very complex and comprehensive syntax overall even after I'd begun reaching up to the 3rd and 4th levels of Perl mastery.
Perl 6 seems sooooo simple in comparison!
> and (as many pointed) no big enterprise to back its adoption...
Yes.
One bit of good news is that this hasn't and won't stop the evolution and maturation of Perl 6.
Another is that the project's improvement is grounded in its test suite. This provides the interesting possibility of corporations funding development and smoking of particular tests that matter to them. (Do you know if that is happening in Perl 5 space, Python, etc.?)
[1] http://blogs.perl.org/users/book/2017/02/about-the-perl-tool...
[2] http://perl6.party/post/IRC-Client-Perl-6-Multi-Server-IRC-M...
"Perl devs are probably 2x the price of a JS guy..."
Funny that here in France it is quite the contrary which leads me and others Perl dev friends accepting JS work as Perl5 and even more Perl6 work are harder and harder to find.
This is absolutely false - at least for senior guys.
Unfortunately (as I happen to be a relatively big fan of Perl5) the market for even "core" Perl developers (e.g. a core perl/module/framework developer with name recognition and solid track record) is less than half the going rate of the equivalent in Node.js for example. Perl unfortunately (as a hiring manager) seems very stratisfied too - there is a whole lot of exceptional talent, and a whole lot of horrible talent - and not a lot in the middle.
I don't know if there is really a market for "below average" Perl programmers these days like there is for JS or PHP - so entry level and other code janitor positions likely do pay more simply due to there being a lack of junior devs learning Perl these days. Those left taking those lower paying Perl jobs are likely not exactly the team of the Perl crop, much less programming crop.
That is the harsh reality of being a Perl shop these days, for better or worse. However the language is much stronger and much more modern than most on HN give it credit for. Properly written Modern Perl in 2017 is much different than the Perl you wrote as a 17 year old making $300 on his first CGI app. It may however be a case of too little too late.
Unfortunately (as I happen to be a relatively big fan of Perl5) the market for even "core" Perl developers (e.g. a core perl/module/framework developer with name recognition and solid track record) is less than half the going rate of the equivalent in Node.js for example. Perl unfortunately (as a hiring manager) seems very stratisfied too - there is a whole lot of exceptional talent, and a whole lot of horrible talent - and not a lot in the middle.
I don't know if there is really a market for "below average" Perl programmers these days like there is for JS or PHP - so entry level and other code janitor positions likely do pay more simply due to there being a lack of junior devs learning Perl these days. Those left taking those lower paying Perl jobs are likely not exactly the team of the Perl crop, much less programming crop.
That is the harsh reality of being a Perl shop these days, for better or worse. However the language is much stronger and much more modern than most on HN give it credit for. Properly written Modern Perl in 2017 is much different than the Perl you wrote as a 17 year old making $300 on his first CGI app. It may however be a case of too little too late.
I stand corrected - my statement is indeed not backed by concrete evidence, but my personal experience and is mostly related to job findings where some legacy Perl5 needs to be supported or amended.
Though, I'm more or less surprised that things are as you say in France.
Though, I'm more or less surprised that things are as you say in France.
If you want to check by yourself here is the popular french job board for web related stuff:
https://remixjobs.com
search JS or javascript: hundreds of results.
and then search Perl: 1 result.
None of the languages mentioned have the goodness of syntactic macros.
https://perl6advent.wordpress.com/2015/12/23/day-23-macros-a...
https://perl6advent.wordpress.com/2015/12/23/day-23-macros-a...
An aside but... The "modern approach to concurrent programming" totally depends on what you're doing. Async I/O isn't always the answer. Sometimes, you need to compute in parallel, and that's not necessarily mutually exclusive (e.g. Go). What language you choose does matter for both of these.
I followed the development of perl 6 for a bit. I was quite impressed for a while, as Larry Wall disolved most of the warts, corner cases, and ad-hocisms of perl 5 into a language which was cleaner and more abstract. Then he used the cognitive space thus provided to load up the langauge with as many features as he could pack in, and I gave up on it.
>I followed the development of perl 6 for a bit.
To put it mildly.
To put it mildly.
I petitioned Ars Technica 3 times to add Perl 6 to their Top 10 Vaporware list. I think, being a Perl shop at the time, they allowed personal bias to drive their ruling.
[deleted]
> as many features as he could pack in
Aiui there's some merit to the notion of The Lisp Curse[1] and he wanted to avoid it. Do you reject the notion of the curse, or think it doesn't apply to P6, or think he overdid it, or...?
Do you recall any specific features you felt went over the top?
[1] eg https://news.ycombinator.com/item?id=2450973
Aiui there's some merit to the notion of The Lisp Curse[1] and he wanted to avoid it. Do you reject the notion of the curse, or think it doesn't apply to P6, or think he overdid it, or...?
Do you recall any specific features you felt went over the top?
[1] eg https://news.ycombinator.com/item?id=2450973
There's also a bit of fear of The Forth Curse.
For those not familiar, The Forth Curse is what happens when you make a language trivially easy to extend but don't write a large enough standard library of functions or procedures for it. Then your extensible language indeed gets easily extended at every site where it's used. The problem is that it's extended slightly differently in each place to do quite common things slightly differently and in wildly incompatible ways.
For those not familiar, The Forth Curse is what happens when you make a language trivially easy to extend but don't write a large enough standard library of functions or procedures for it. Then your extensible language indeed gets easily extended at every site where it's used. The problem is that it's extended slightly differently in each place to do quite common things slightly differently and in wildly incompatible ways.
Oh, I thought that was the Prolog curse.
I write Perl 5 for a living, we have Perl 6 installed here and I occasionally use it for one-liners[1] that are much less verbose than Perl 5 or most other languages. But nothing else.
1. https://github.com/dnmfarrell/Perl6-One-Liners
1. https://github.com/dnmfarrell/Perl6-One-Liners
Cool Perl6 oneliners ..
I like it. Put it more
Biased core dev here...
I've used Perl 6 for IRC bots. The ease of writing parallel code, nice OO model, multi dispatch, and subsets make it very pleasant to do them in Perl 6. Here's a bot I wrote that listens for GitHub webhooks and reports new commits and PRs: https://github.com/perl6/geth and here's another one that's just a bunch of random features: https://github.com/zoffixznet/perl6-buggable/
I also heard people say grammars are the most note-worthy feature of Perl 6 and people basically use them to quickly hack up a nice little micro-language in which they then attack their problem. Before I came to Perl 6 I was dumb as shoe when it came to writing parsers, but I find it trivial to do with Perl 6 grammars.
Do I like it? Although I'm obviously biased, I love the language. It lets you write beautifully concise, yet still readable, code. It even lets you use much more readable syntax for regexes. Somewhat regretfully, it made it very difficult for me to learn other languages, as in them I end up writing 3x, 4x, 6x the amount of code and I keep getting reminded of Larry Wall saying Perl 6 would be the last language you'd learn. In Perl 6 I can "talk"; in other languages, I write "code".
However, while the language is fantastic, the implementation still has a lot of work to be done to polish it off. It's basically a 1.0 release. Unlike Go, Rust, or Swift, there isn't a giant corporation behind Perl 6 that can just throw money at problems until they disappear. Compared to other languages, some things are still unoptimized and are much slower. I spotted some leakage that makes it problematic for very-long-running (months) programs. About 65 new bug tickets are opened per month. The test suite is pretty sparse in some areas (which is the likely reason for many of the new bug tickets). But... three new core developers joined this January, so hopefully all that will get improved pretty fast.
Someone in the comments also mentioned the baby-sized ecosystem... Since Perl 6 lets you use C libraries without needing to compile anything, people wrote stuff like Inline::Perl5 and Inline::Python that let you import and even subclass stuff from Perl 5 and Python. And that's a bit of a double-edge sword: yes, it's trivial to use libraries from Perl 5 and Python, but it also stunts the ecosystem; no one has enough motivation to re-invent the wheel in Perl 6 when the wheels from other languages are reasonably usable.
I've used Perl 6 for IRC bots. The ease of writing parallel code, nice OO model, multi dispatch, and subsets make it very pleasant to do them in Perl 6. Here's a bot I wrote that listens for GitHub webhooks and reports new commits and PRs: https://github.com/perl6/geth and here's another one that's just a bunch of random features: https://github.com/zoffixznet/perl6-buggable/
I also heard people say grammars are the most note-worthy feature of Perl 6 and people basically use them to quickly hack up a nice little micro-language in which they then attack their problem. Before I came to Perl 6 I was dumb as shoe when it came to writing parsers, but I find it trivial to do with Perl 6 grammars.
Do I like it? Although I'm obviously biased, I love the language. It lets you write beautifully concise, yet still readable, code. It even lets you use much more readable syntax for regexes. Somewhat regretfully, it made it very difficult for me to learn other languages, as in them I end up writing 3x, 4x, 6x the amount of code and I keep getting reminded of Larry Wall saying Perl 6 would be the last language you'd learn. In Perl 6 I can "talk"; in other languages, I write "code".
However, while the language is fantastic, the implementation still has a lot of work to be done to polish it off. It's basically a 1.0 release. Unlike Go, Rust, or Swift, there isn't a giant corporation behind Perl 6 that can just throw money at problems until they disappear. Compared to other languages, some things are still unoptimized and are much slower. I spotted some leakage that makes it problematic for very-long-running (months) programs. About 65 new bug tickets are opened per month. The test suite is pretty sparse in some areas (which is the likely reason for many of the new bug tickets). But... three new core developers joined this January, so hopefully all that will get improved pretty fast.
Someone in the comments also mentioned the baby-sized ecosystem... Since Perl 6 lets you use C libraries without needing to compile anything, people wrote stuff like Inline::Perl5 and Inline::Python that let you import and even subclass stuff from Perl 5 and Python. And that's a bit of a double-edge sword: yes, it's trivial to use libraries from Perl 5 and Python, but it also stunts the ecosystem; no one has enough motivation to re-invent the wheel in Perl 6 when the wheels from other languages are reasonably usable.
Do you know what algorithm grammars use under the hood? I don't see it mentioned in documentation like this: https://docs.perl6.org/language/grammars
"Group of named regexes that form a formal grammar"
Are Perl 6 "regexes" as powerful as a context-free grammar? I guess they use the same kind of backtracking algorithm and ad hoc recursion as Perl 5? That is, does the algorithm for regexes differ from Perl 5, or only the syntax?
I think the syntax is a big improvement BTW.
"Group of named regexes that form a formal grammar"
Are Perl 6 "regexes" as powerful as a context-free grammar? I guess they use the same kind of backtracking algorithm and ad hoc recursion as Perl 5? That is, does the algorithm for regexes differ from Perl 5, or only the syntax?
I think the syntax is a big improvement BTW.
> Are Perl 6 "regexes" as powerful as a context-free grammar?
TL;DR If you can code it, you can code it using Perl 6 grammars.
Perl 6 is designed as a collection of "slangs" (short for sub-languages) that recursively embed each other. (There are about a half dozen slangs in standard Perl 6 but you can add more.)
So the full power of the "main" Perl 6 slang is available within the regex slang (and vice-versa). During execution each slang automatically tracks the interesting state of the other slangs.
So, while the compiler is free to analyze a given rule and generate a suitably optimized DFA or NFA, they are, in general, capable of turing complete power.
> I guess they use the same kind of backtracking algorithm
The main answer is No.
There are four types of "rule". Only one of these, using the `regex` declarator, backtracks in the usual regex way.
Most extant grammars contain nothing but `rule`s, `token`s, and occasionally `method`s.
The fact that the latter are just ordinary methods hints at what's going on; the "regex slang" is really just a built in recursive ascent/descent parser generator with a convenient DSL (slang) for writing grammars.
TL;DR If you can code it, you can code it using Perl 6 grammars.
Perl 6 is designed as a collection of "slangs" (short for sub-languages) that recursively embed each other. (There are about a half dozen slangs in standard Perl 6 but you can add more.)
So the full power of the "main" Perl 6 slang is available within the regex slang (and vice-versa). During execution each slang automatically tracks the interesting state of the other slangs.
So, while the compiler is free to analyze a given rule and generate a suitably optimized DFA or NFA, they are, in general, capable of turing complete power.
> I guess they use the same kind of backtracking algorithm
The main answer is No.
There are four types of "rule". Only one of these, using the `regex` declarator, backtracks in the usual regex way.
Most extant grammars contain nothing but `rule`s, `token`s, and occasionally `method`s.
The fact that the latter are just ordinary methods hints at what's going on; the "regex slang" is really just a built in recursive ascent/descent parser generator with a convenient DSL (slang) for writing grammars.
The design of regular expressions is different than any other version from any other language to improve readability along with other improvements.
In Perl 6 regexes are seen as a type of method (that is they are literally implemented as a type of method in Rakudo)
Grammars tend to look like a cross between BNF, and well Perl. https://stackoverflow.com/a/41770672/1337
Perl 6 regexes have longest term matching using |, or sequential matching like Perl 5 using ||.
Since regexes are methods, they can take arguments as well.
In Perl 6 regexes are seen as a type of method (that is they are literally implemented as a type of method in Rakudo)
Grammars tend to look like a cross between BNF, and well Perl. https://stackoverflow.com/a/41770672/1337
Perl 6 regexes have longest term matching using |, or sequential matching like Perl 5 using ||.
Since regexes are methods, they can take arguments as well.
IIRC, Perl 6 grammars are parsing expression grammars (PEGs). I don't know if these are compiled down to recursive descent or packrat parsers; my guess would be the latter (since that's typical for PEGs).
The sibling post says that they have both || and |. The || operator sounds like ordered choice from PEGs, and | sounds like a non-deterministic choice from regexes and CFGs.
So it's basically a mix of paradigms, which muddies the waters in terms of what computational complexity guarantees you can get. Pure regular expressions can be matched in linear time; CFGs in cubic time and some subsets in linear time; packrat parsing in linear time, and backtracking PEG in exponential time. Perl 5 regexes are exponential time in general.
I've used regexes extensively on big data so I don't like this mix of paradigms. I'd rather have separate dialects for each paradigm than having to guess what it's using underneath.
Backtracking causes real problems in production: https://news.ycombinator.com/item?id=12132045
I would bet money that Perl 6 uses backtracking, because it has a mix of paradigms that makes it harder to do anything smarter.
Backtracking is also bad for adversarial input, which is essentially always a concern nowadays.
So it's basically a mix of paradigms, which muddies the waters in terms of what computational complexity guarantees you can get. Pure regular expressions can be matched in linear time; CFGs in cubic time and some subsets in linear time; packrat parsing in linear time, and backtracking PEG in exponential time. Perl 5 regexes are exponential time in general.
I've used regexes extensively on big data so I don't like this mix of paradigms. I'd rather have separate dialects for each paradigm than having to guess what it's using underneath.
Backtracking causes real problems in production: https://news.ycombinator.com/item?id=12132045
I would bet money that Perl 6 uses backtracking, because it has a mix of paradigms that makes it harder to do anything smarter.
Backtracking is also bad for adversarial input, which is essentially always a concern nowadays.
Roughly (so far as I understand it), it's PEG with an escape hatch to regexps if you really must, and it doesn't backtrack by default.
Please do have a play some time and assuming that I got the above right, donate however much money you would've been willing to bet to the Perl Foundation or the Enlightened Perl Organisation as you prefer :)
Please do have a play some time and assuming that I got the above right, donate however much money you would've been willing to bet to the Perl Foundation or the Enlightened Perl Organisation as you prefer :)
Aside from perhaps protecting against adversarial input, the general philosophy of Perl has always been for programmers to not need to worry themselves about underlying implementation details. The exact algorithms (and with that the exact computational complexity bounds) might very well be implementation dependent.
Right, but the point is that you don't need to worry until you do. See the post I linked.
I'm not saying nobody wants Perl to work like that... but I am saying I wouldn't use such a tool. It's not right for the problems I need to solve.
I also think it's good if programming languages use algorithms with well-known behavior, rather than a mish-mash of heuristics. Heuristics are OK if there is nothing better known, but these problems have been studied.
I'm not saying nobody wants Perl to work like that... but I am saying I wouldn't use such a tool. It's not right for the problems I need to solve.
I also think it's good if programming languages use algorithms with well-known behavior, rather than a mish-mash of heuristics. Heuristics are OK if there is nothing better known, but these problems have been studied.
So I actually found an answer to your question re: backtracking: https://docs.perl6.org/language/faq#What%27s_the_difference_...?
Basically: Perl 6 tokens and rules imply :ratchet, which means no backtracking. You can use raw regexes if for some reason you do need backtracking, but otherwise it looks like a Perl 6 grammar is backtracking-free (and grammars in the real world hopefully use tokens/rules exclusively).
So it might actually be at least tolerable for the problems you need to solve (though it's hard for me to say without knowing the problems in the first place (: ). The main remaining question is the exact algorithm in use; I'd be very surprised if Perl 6 grammars didn't compile down to at least some variation on packrat parsers, which would mean linear complexity, but this is probably - again - implementation-dependent in the "we don't care what you do so long as it passes the Perl 6 test suite" sense. I've yet to find a definitive answer by spelunking through Rakudo's code, but it's reassuring that even Rakudo's grammar for Perl 6 itself seems to be devoid of backtracking (meaning that it's clearly possible to do without it; there are quite a few generic subs/methods in there, though, which could prove me wrong here).
Basically: Perl 6 tokens and rules imply :ratchet, which means no backtracking. You can use raw regexes if for some reason you do need backtracking, but otherwise it looks like a Perl 6 grammar is backtracking-free (and grammars in the real world hopefully use tokens/rules exclusively).
So it might actually be at least tolerable for the problems you need to solve (though it's hard for me to say without knowing the problems in the first place (: ). The main remaining question is the exact algorithm in use; I'd be very surprised if Perl 6 grammars didn't compile down to at least some variation on packrat parsers, which would mean linear complexity, but this is probably - again - implementation-dependent in the "we don't care what you do so long as it passes the Perl 6 test suite" sense. I've yet to find a definitive answer by spelunking through Rakudo's code, but it's reassuring that even Rakudo's grammar for Perl 6 itself seems to be devoid of backtracking (meaning that it's clearly possible to do without it; there are quite a few generic subs/methods in there, though, which could prove me wrong here).
Unfortunately the regex/grammar engine is one of those components lacking deep optimisation. At the moment. Thats probably a much bigger factor than anything algorithmic.
With tokens another nice thing to note is there is longest token matching and the concept of "proto" tokens and regexes. This lets you have simple decision making between similarly defined tokens without backtracking. For example the grammar I have for biological sequences can simultaneously identify and parse DNA/RNA/Protein without back tracking. Even if a file has a mixture of data I can instantiate the correct subclasses on the fly whilst parsing! https://github.com/MattOates/BioInfo/blob/master/lib/BioInfo...
With tokens another nice thing to note is there is longest token matching and the concept of "proto" tokens and regexes. This lets you have simple decision making between similarly defined tokens without backtracking. For example the grammar I have for biological sequences can simultaneously identify and parse DNA/RNA/Protein without back tracking. Even if a file has a mixture of data I can instantiate the correct subclasses on the fly whilst parsing! https://github.com/MattOates/BioInfo/blob/master/lib/BioInfo...
I reckon the optimizations will come soon (at least that's what I gathered from reading the Perl 6 documentation's "Performance" section); now that Perl 6.c is out in the wild, there's less of a moving target, so the implementations can (and apparently are) starting to focus more on squeezing out more performance.
And yeah, proto regexes are pretty sweet, and they seem to be a natural fit for what you're doing. I'm always surprised by how popular Perl seems to be in biology / life sciences, and projects like BioInfo (and BioPerl, of course) are a great reminder as to why that happens to be.
And yeah, proto regexes are pretty sweet, and they seem to be a natural fit for what you're doing. I'm always surprised by how popular Perl seems to be in biology / life sciences, and projects like BioInfo (and BioPerl, of course) are a great reminder as to why that happens to be.
Thanks. Your comment has uniquely challenged my skepticism and hesitancy around Perl 6. I mean that with sincerity.
Perl 6 looks very promising. It was an attempt to brush up Perl 5 but became its own language with a very unfortunate name (read: Perl 6 will not replace Perl 5). It has some very interesting features, including the built-in concurrency primitives and the oft-mentioned grammars.
It is still very new (from a release time perspective). I don't expect there are very many large-scale real-world usages yet. I do wish that the Perl 6 community would spend a little more time on advocacy but thankfully there are several books on the way and hopefully that will start breaking out of the echo chamber and introducing the language to the masses.
It is still very new (from a release time perspective). I don't expect there are very many large-scale real-world usages yet. I do wish that the Perl 6 community would spend a little more time on advocacy but thankfully there are several books on the way and hopefully that will start breaking out of the echo chamber and introducing the language to the masses.
I considered Perl 6 for a deep dive at the end of 2015...just as it was 'officially released'. The difficulty for me was the state of the documentation ecosystem. No dead-tree books (but for one that was written more than a decade earlier) and a lot of information ad hocked up in blogs and slides. I just felt like I could not really get a handle on it...While googling 'Perl 6' sort of worked, 'Perl 6 how do I <x>' type queries pretty much ignored the "6" and landed me on Perl 5 resources. Perl 6 still only has ~300 StackOverflow questions.
I'm still interested in it, but it just doesn't work for me as an ecosystem yet.
I'm still interested in it, but it just doesn't work for me as an ecosystem yet.
FWIW, a huge amount of work has been done to docs in the past year. There's even a dead-tree book available now (https://deeptext.media/perl6-at-a-glance/ ), with 3 more slated to release later this year.
I knew there was work in progress because I've made a similar comment in the past few months. I'm not in hurry which is perhaps in good alignment with Perl 6...A quick look at the book sample suggests it's not probably what I'd look for before starting a deep dive.
I worked on Perl 5 projects professionally for about 15 years, then switched to a new job that uses Node.js. I enjoyed coding in Perl 5, but it was hard to find and retain Perl 5 developers. Our later hires preferred to code in C#, Python and Ruby-- This was before Node.js took off. Looking at language trajectories on http://modulecounts.com/ The momentum that JavaScript has compared to Perl is amazing-- CPAN growth is relatively flat, JavaScript growth is skyrocketing. JavaScript has it's own warts, but for web projects with smaller teams, having the frontend and backend in the same language is big benefit. As much as I enjoyed the Perl language and community, I can't foresee recommending it for team web projects in the near future.
We should be careful when comparing the growth or package counts of CPAN and npm. While conceptually similar, they're still very different from one another.
A lot of the npm growth is just the JavaScript ecosystem catching up to where CPAN was ages ago.
Then there are the npm packages that add functionality that's typically included by default with Perl, so there would never really be a need for equivalent CPAN modules.
I think there is much less duplication within CPAN, while it's not unusual to find several similar npm packages that more or less do the same thing.
CPAN modules also tend to be larger and include more functionality, while it's not unusual for npm packages to include just a single function, or otherwise limited functionality. Sometimes several npm packages are needed to approximate the functionality of individual CPAN modules.
That module count graph should perhaps even be treated as worrying. Npm is clearly an outlier compared to every other package management system listed. There's not much suggesting it's inherently better than all of the other systems, either. So it's likely more negative factors, such as an excessive need for functionality, and many duplicate packages, and unreasonably small packages, and so on causing such inflated numbers.
A lot of the npm growth is just the JavaScript ecosystem catching up to where CPAN was ages ago.
Then there are the npm packages that add functionality that's typically included by default with Perl, so there would never really be a need for equivalent CPAN modules.
I think there is much less duplication within CPAN, while it's not unusual to find several similar npm packages that more or less do the same thing.
CPAN modules also tend to be larger and include more functionality, while it's not unusual for npm packages to include just a single function, or otherwise limited functionality. Sometimes several npm packages are needed to approximate the functionality of individual CPAN modules.
That module count graph should perhaps even be treated as worrying. Npm is clearly an outlier compared to every other package management system listed. There's not much suggesting it's inherently better than all of the other systems, either. So it's likely more negative factors, such as an excessive need for functionality, and many duplicate packages, and unreasonably small packages, and so on causing such inflated numbers.
Plus there's the fashion of uploading one npm dist per function, as well as a bundled dist, for projects not using tree shaking to keep their browser bundle small.
OTOH while I'm mostly a perl hacker, there's a metric fucktonne of duplication on CPAN too, so I'm not sure that comment necessarily applies (there may be more duplication on npm, but I don't have data for that).
OTOH while I'm mostly a perl hacker, there's a metric fucktonne of duplication on CPAN too, so I'm not sure that comment necessarily applies (there may be more duplication on npm, but I don't have data for that).
Furthermore, AFAIK NPM is more than a module manager for Node.js, IIRC many use it for CSS and other languages.
Things to consider:
Perl developers would never bother to upload something as trivial as left-pad to CPAN (someone did it to mock node developers but that is a different story)
and the code quality of modules in CPAN is usually higher.
and the code quality of modules in CPAN is usually higher.
How much do you attribute the growth disparity to CPAN literally already having solved most problems vs. the Node community naturally having gaps because they haven't been around as long?
I like many things about Perl 6, but I mention only the ones I used in my project. MAIN subroutine makes it very easy to create simple CLIs, multiple dispatch, gradual typing, subsets, the object system, roles, Unicode support, being multi-paradigm.
Also, Perl 6 makes it easy to write short and concise code that will also be very readable.
The project I wrote is a command line tool[1] for fetching football(soccer) data, which uses a module[2] I wrote for getting the data from http://football-data.org
[1] https://gitlab.com/CIAvash/App-Football
[2] https://gitlab.com/CIAvash/WebService-FootballData
Also, Perl 6 makes it easy to write short and concise code that will also be very readable.
The project I wrote is a command line tool[1] for fetching football(soccer) data, which uses a module[2] I wrote for getting the data from http://football-data.org
[1] https://gitlab.com/CIAvash/App-Football
[2] https://gitlab.com/CIAvash/WebService-FootballData
Everything I've seen about Perl 6, I love to death.
I just wish I had an excuse to use it. The problem is, most of the time I start a new project, I default to Python because it's what I know. I know the libraries, I know the quirks of the built-in data structures, etc. So I just go with what I know.
I really wish I had the discipline to sit down and tell myself "I'm going to write this next project in Perl 6 no matter how much time it takes to figure out how to do what I want to do".
Like, I actually just started a personal project to parse some US Census data a few days ago. I could have, and probably should have, taken the opportunity to write it in Perl 6. But I got lazy and just went with what I knew. I feel really bad about that, since from what I've seen, it sounds like a language I'll love working with just as much as Python.
I just wish I had an excuse to use it. The problem is, most of the time I start a new project, I default to Python because it's what I know. I know the libraries, I know the quirks of the built-in data structures, etc. So I just go with what I know.
I really wish I had the discipline to sit down and tell myself "I'm going to write this next project in Perl 6 no matter how much time it takes to figure out how to do what I want to do".
Like, I actually just started a personal project to parse some US Census data a few days ago. I could have, and probably should have, taken the opportunity to write it in Perl 6. But I got lazy and just went with what I knew. I feel really bad about that, since from what I've seen, it sounds like a language I'll love working with just as much as Python.
This is how I feel about Common Lisp actually (I've a sweet spot for Lisp). I have switched from programming to humanities so I don't really have much programming to do, and all the little tools and stuff I need I code them up in Emacs Lisp, and because of that I actually have no use for CL ATM, and even though I want to write some CL so bad, I write all the stuff in Elisp, I just do that.. :)
I wrote PKafka (https://github.com/mempko/PKafka) a year ago, a Perl 6 wrapper around the rdkafka library. I just started using it in a production system a week ago.
I feel that Perl 6 is an amazing language. The regex and grammars are fantastic for doing any sort of parsing. The built in support for reactive programming and gradual typing with the given/when syntax is fantastic. The type constraint and multi dispatch mechanism is also great.
However, only until the latest release 2017-01, did I feel the MoarVM is stable enough for production use.
I feel that Perl 6 is an amazing language. The regex and grammars are fantastic for doing any sort of parsing. The built in support for reactive programming and gradual typing with the given/when syntax is fantastic. The type constraint and multi dispatch mechanism is also great.
However, only until the latest release 2017-01, did I feel the MoarVM is stable enough for production use.
I've been using it locally to write a few small scripts, nothing publicly available (yet).
Traits and roles are really neat - they feel like a natural conclusion to what Ruby started building upon with respect to metaprogramming natural syntax and encouraging developer happiness over strictness.
On the whole, however, many small parts of Perl 6 feel immature. There's no core JSON/YAML module, and there's no "official" module manager yet - just panda[1] and a few others.
Overall I'd recommend tinkering with it, but I don't think it's ready (as an ecosystem) for larger development. Hopefully soon, though!
[1]: https://github.com/tadzik/panda
Traits and roles are really neat - they feel like a natural conclusion to what Ruby started building upon with respect to metaprogramming natural syntax and encouraging developer happiness over strictness.
On the whole, however, many small parts of Perl 6 feel immature. There's no core JSON/YAML module, and there's no "official" module manager yet - just panda[1] and a few others.
Overall I'd recommend tinkering with it, but I don't think it's ready (as an ecosystem) for larger development. Hopefully soon, though!
[1]: https://github.com/tadzik/panda
It sounds to me like you would like a "batteries included" version of Perl 6. (include JSON/YAML in the runtime)
No. We only include things as part of the language where the design of it is immediately obvious, and is useful for many applications. It also helps if it has been proven in other languages. So Promises(Futures) are in there, but many other things are not. You can do anything in a module, so write an external module for it instead.
Otherwise we would have the problems where the best module for the job is not in the runtime, but everyone uses the one that is in the runtime.
I have heard that Python has this problem with HTTP. Think of it like this, a module for doing X is included with the first version of a language. That means it is a module that was not written by an expert, because at that point in time there was no expert in the language. Everyone uses it though; as you don't have to install it, because it is already there.
We don't have an official module manager, because we want all of them to be equally as official as every other one. It is a good thing too; as most people in the know use zef currently, rather than panda. If we had one that was official, it would have been panda.
That's also why there is not, nor will ever be an official implementation. Any implementation that passes the test suite is just as official as every other one. (although there is only one currently)
Basically you are asking for things to be included, that are specifically not included for very good reasons. The way that this is dealt with is by using the idea of distributions like "Rakudo Star" for Perl 6, or "Strawberry Perl" for Perl 5 on windows. That is an implementation of Perl 6 along with a set of useful modules.
No. We only include things as part of the language where the design of it is immediately obvious, and is useful for many applications. It also helps if it has been proven in other languages. So Promises(Futures) are in there, but many other things are not. You can do anything in a module, so write an external module for it instead.
Otherwise we would have the problems where the best module for the job is not in the runtime, but everyone uses the one that is in the runtime.
I have heard that Python has this problem with HTTP. Think of it like this, a module for doing X is included with the first version of a language. That means it is a module that was not written by an expert, because at that point in time there was no expert in the language. Everyone uses it though; as you don't have to install it, because it is already there.
We don't have an official module manager, because we want all of them to be equally as official as every other one. It is a good thing too; as most people in the know use zef currently, rather than panda. If we had one that was official, it would have been panda.
That's also why there is not, nor will ever be an official implementation. Any implementation that passes the test suite is just as official as every other one. (although there is only one currently)
Basically you are asking for things to be included, that are specifically not included for very good reasons. The way that this is dealt with is by using the idea of distributions like "Rakudo Star" for Perl 6, or "Strawberry Perl" for Perl 5 on windows. That is an implementation of Perl 6 along with a set of useful modules.
First of all, thanks for responding. I understand the hesitation of language maintainers with respect to adding complex modules like JSON and YAML, but I do think that there are some major benefits to doing so:
* Users don't have to worry about inconsistent distributions. Following a test suite is one thing, but test suites are (almost) never comprehensive and will not catch programmer errors with respect to particular systems (e.g, LP64 and LLP64). Everything will work until it doesn't, and programmers will have to provide edge-case workarounds until individual distributions fix their implementations.
The same goes for module managers. It's good to provide an open spec and encourage multiple frontends, but it's also good to provide a uniform interface for system administrators who just want to automate module installation for an application or framework. Python's easy_install wasn't ideal, but it provided exactly that sort of common denominator.
"Batteries included" makes it sound like I want my language to come with a playground, which I think is an unfair way to characterize the expectation that Perl 6 provide feature parity with the languages it competes with (i.e., Ruby 2 and Python 3).
* Users don't have to worry about inconsistent distributions. Following a test suite is one thing, but test suites are (almost) never comprehensive and will not catch programmer errors with respect to particular systems (e.g, LP64 and LLP64). Everything will work until it doesn't, and programmers will have to provide edge-case workarounds until individual distributions fix their implementations.
The same goes for module managers. It's good to provide an open spec and encourage multiple frontends, but it's also good to provide a uniform interface for system administrators who just want to automate module installation for an application or framework. Python's easy_install wasn't ideal, but it provided exactly that sort of common denominator.
"Batteries included" makes it sound like I want my language to come with a playground, which I think is an unfair way to characterize the expectation that Perl 6 provide feature parity with the languages it competes with (i.e., Ruby 2 and Python 3).
I appreciate the explanation, but it practice it usually means everyone has to pick and choose between a collection of bitrotted old libraries. Yes, some are consistently well maintained, but it is hit or miss. It's nice being able to "import CSV" on any python script without having to wrestle with a failed installation. I think both sides have merit.
Rakudo has JSON support built in, and Rakudo Star, the example batteries-included dist, has two additional JSON modules - and ships zef for module management, replacing panda.
The ecosystem is still young, and "not ready" is a perfectly reasonable point of view, but you're using definitions of core/official that don't really apply - rakudo is the base compiler, not a complete release.
The ecosystem is still young, and "not ready" is a perfectly reasonable point of view, but you're using definitions of core/official that don't really apply - rakudo is the base compiler, not a complete release.
I've been using my distro's Rakudo/Perl 6 package, which appears to be fairly out of date. That's probably why I couldn't find a JSON module or zef. Thanks for clarifying.
they've moved on to zef for modules.
https://github.com/ugexe/zef
http://modules.zef.pm/
https://github.com/ugexe/zef
http://modules.zef.pm/
I am late to the party here, but I've recently rolled perl6 into my analytics stack project: nlytiq ( https://github.com/joelandman/nyltiq-base ). Very early stages, I am trying to build an up-to-date tool chain of very powerful tools for data munging, analytics, etc. for my own projects. Born of a frustration with the badly out of date tools in most distros.
I pulled Perl6 in after seeing some of what it was capable of last year. Generally I like tools that make hard things easier, and easy things trivial. I don't like tools that require huge amounts of boilerplate code to even start using them productively.
Perl6 is definitely in the category of making hard things easier. It is not Perl5, and doesn't pretend to be. Perl5 is immensely powerful on its own, definitely one of my go-to tools.
Perl6 brings in many of the things that I've been using in other languages for a while, with some aspect of "perl-ness" about it, which, to me, makes it more comfortable. Its ability to connect with/call anything positively blows me away. Perl5 has Platypus::FFI which can do some of this, but Perl6 is a compiled language (to an underlying VM). This has been one of my major concerns with P5 for a while (and still a concern in Python and others ... yeah, I know of PyPy, but I want a compiler built into Python 3.x).
I pulled Perl6 in after seeing some of what it was capable of last year. Generally I like tools that make hard things easier, and easy things trivial. I don't like tools that require huge amounts of boilerplate code to even start using them productively.
Perl6 is definitely in the category of making hard things easier. It is not Perl5, and doesn't pretend to be. Perl5 is immensely powerful on its own, definitely one of my go-to tools.
Perl6 brings in many of the things that I've been using in other languages for a while, with some aspect of "perl-ness" about it, which, to me, makes it more comfortable. Its ability to connect with/call anything positively blows me away. Perl5 has Platypus::FFI which can do some of this, but Perl6 is a compiled language (to an underlying VM). This has been one of my major concerns with P5 for a while (and still a concern in Python and others ... yeah, I know of PyPy, but I want a compiler built into Python 3.x).
So this doesn't help with your question but I'm sure i'm not alone on this one...
I hadn't even realized Perl 6 was out! I remember years ago it kind of being labeled as the "Duke Nukem Forever" of programming languages versions. I don't personally use it but I'm glad to see it is out (even if I found out a year late).
I hadn't even realized Perl 6 was out! I remember years ago it kind of being labeled as the "Duke Nukem Forever" of programming languages versions. I don't personally use it but I'm glad to see it is out (even if I found out a year late).
I once heard the apocalypse arrives when GNUHurd is released with perl6 & duke nukem forever running on it.
Perl 6 is my go-to language for writing command line utilities. The combination of MAIN subroutines, named regexes and full-blown grammars makes it simple to write documented, maintainable programs that can parse just about anything. Oh and Unicode support is awesome. This protobuf grammar is a good example of what Perl 6 grammars are like - https://github.com/donaldh/p6-pb/blob/master/lib/PB/Grammar.... - and worth comparing to the official protobuf language specification - https://developers.google.com/protocol-buffers/docs/referenc...
Low-level stuff on a Raspberry Pi, including native C library calls for mmap, munmap. Binding the mmap library call into Perl 6 is as simple as:
sub mmap(Pointer $addr, int32 $length, int32 $prot, int32 $flags, int32 $fd, int32 $offset) returns CArray[int32] is native {*}
https://github.com/donaldh/Perl6-RPi-GpioDirect/blob/master/...
sub mmap(Pointer $addr, int32 $length, int32 $prot, int32 $flags, int32 $fd, int32 $offset) returns CArray[int32] is native {*}
https://github.com/donaldh/Perl6-RPi-GpioDirect/blob/master/...
Here's an example of a MAIN subroutine with POD6 documentation that produces a good command line usage message
https://github.com/donaldh/swagger-to-yang/blob/master/swagg...
https://github.com/donaldh/swagger-to-yang#usage
https://github.com/donaldh/swagger-to-yang/blob/master/swagg...
https://github.com/donaldh/swagger-to-yang#usage
For a long time I thought that Perl 6 would be close to an ideal language for me. I haven't really questioned that belief, but it turns out http://www.red-lang.org is much closer.
Let's say that I'm glad that Perl 6 is there as an option.
Let's say that I'm glad that Perl 6 is there as an option.
Gosh yes I'm excited for Red Lang too.
As a perl5 programmer of 5 years, I've branched out. In terms of professionally this means mostly into Ruby but a little bit Java and the occasional JavaScript.
Perl5 is a fine language that is over-attacked, and neat stuff is still done in it. Ruby as a language is better (but more subject to hype and so more often overrated)... and I'm confident that Perl6 is full of neat stuff. I wish it the best. And I will take any of these languages over Java for most problems I've faced.
But if you stick with too much Perl for too long you run a serious risk of being typecast as a "Perl guy" familiar only with dated languages, fairly or otherwise, and can expect a hard time finding the sort of jobs you want in the future, which is a pity. (Which isn't to say you won't find jobs, just that the pool of jobs will lean towards "maintain legacy code with no chance to refactor make your time" and "build engineer".) This is why I branched out in the first place.
My next target is Elixir (and then by extension, Erlang), narrowly winning out over Scala, with Go/Rust/OCaml trailing behind a little. I reckon Scala is probably more practical, and surprisingly popular in Europe, but I like working with a "reliability" mindset more than not and therefore forecast that I'll like the tools and opportunities in Elixir better. I've barely started but my initial reaction to what I've seen is quite positive.
- But at some level, all that's just me, and you shouldn't take lessons from my experience nearly so much as it should prompt you to think about your own experience and what you want out of programming as a hobby or as your career.
Perl5 is a fine language that is over-attacked, and neat stuff is still done in it. Ruby as a language is better (but more subject to hype and so more often overrated)... and I'm confident that Perl6 is full of neat stuff. I wish it the best. And I will take any of these languages over Java for most problems I've faced.
But if you stick with too much Perl for too long you run a serious risk of being typecast as a "Perl guy" familiar only with dated languages, fairly or otherwise, and can expect a hard time finding the sort of jobs you want in the future, which is a pity. (Which isn't to say you won't find jobs, just that the pool of jobs will lean towards "maintain legacy code with no chance to refactor make your time" and "build engineer".) This is why I branched out in the first place.
My next target is Elixir (and then by extension, Erlang), narrowly winning out over Scala, with Go/Rust/OCaml trailing behind a little. I reckon Scala is probably more practical, and surprisingly popular in Europe, but I like working with a "reliability" mindset more than not and therefore forecast that I'll like the tools and opportunities in Elixir better. I've barely started but my initial reaction to what I've seen is quite positive.
- But at some level, all that's just me, and you shouldn't take lessons from my experience nearly so much as it should prompt you to think about your own experience and what you want out of programming as a hobby or as your career.
I wrote up a tutorial on Perl 6 and tried to get it more widely known there are a lot of neat features in it and it looks far better designed than most languages:
https://www.codementor.io/perl/tutorial/how-to-use-json-in-p...
However, most people have dismissed it because they think Perl 5 is dead and anything using Perl should be replaced with Python or Ruby or Go or Rust or some other language.
The hacker flavour of the language has been preserved and that's the niche it would fill for me...if I didn't have to basically do frontend web all day.
https://www.codementor.io/perl/tutorial/how-to-use-json-in-p...
However, most people have dismissed it because they think Perl 5 is dead and anything using Perl should be replaced with Python or Ruby or Go or Rust or some other language.
The hacker flavour of the language has been preserved and that's the niche it would fill for me...if I didn't have to basically do frontend web all day.
> However, most people have dismissed it because they think Perl 5 is dead and anything using Perl should be replaced with Python or Ruby or Go or Rust or some other language.
I didn't dismiss it for that reason. I wanted to like Perl 6, but dismissed it because last time I tried learning it:
* it seemed to include too much syntax
* too much lingo required to understand core concepts
* no coherently-written definitive tutorial. No Camel book for that matte.
* most examples seem to be written with maximum quirky-ness to show off the acrobatics you can do. I just want to get work done.
I didn't dismiss it for that reason. I wanted to like Perl 6, but dismissed it because last time I tried learning it:
* it seemed to include too much syntax
* too much lingo required to understand core concepts
* no coherently-written definitive tutorial. No Camel book for that matte.
* most examples seem to be written with maximum quirky-ness to show off the acrobatics you can do. I just want to get work done.
http://perl6intro.com/ is quite nice.
Yes, but as the author mentioned it is a far cry from a camel book. I've been told Larry is working on it, but I bet I can't buy it for at least two years if not three. We do have 3-4 other books coming out in the future, but I want a 600 page monster to make me truly understand it in and out.
I used perl6 to write a mini-webservice, an API-wrapper for a weather forecast API my bash script is speaking to – I of course don't want users to have to generate API keys, hence the wrapper. Programming that was straightforward, the language itself nice and powerful. But of course I did not really need a powerful language for that task.
I had issues finding the right modules to use, like which webserver to use, with which module to make http requests. But the biggest issue was that the hoster I initially wanted to use doesn't have perl6 pre-installed, and compiling it fails because the compilation itself uses too much memory. I then moved it to a bare metal server, where compiling Rakudo Star succeeded.
The whole Rakudo Star thing, that there are different VMs (that there are VMs in the first place), that there are different module manager, all that was totally confusing. But I liked the language itself a bit, it was nice testing something else.
I had issues finding the right modules to use, like which webserver to use, with which module to make http requests. But the biggest issue was that the hoster I initially wanted to use doesn't have perl6 pre-installed, and compiling it fails because the compilation itself uses too much memory. I then moved it to a bare metal server, where compiling Rakudo Star succeeded.
The whole Rakudo Star thing, that there are different VMs (that there are VMs in the first place), that there are different module manager, all that was totally confusing. But I liked the language itself a bit, it was nice testing something else.
To a large degree, the ongoing utility of Perl 6 depends upon the continued vibrancy of the CPAN community. IMHO, CPAN is anything but vibrant by today's standards.
While CPAN hosts a vast archive of nearly 35,000 modules[1], many are aging. Fewer than 800 modules are known to exist for Perl 6.[2]
[1] http://www.modulecounts.com/ [2] https://modules.perl6.org/
While CPAN hosts a vast archive of nearly 35,000 modules[1], many are aging. Fewer than 800 modules are known to exist for Perl 6.[2]
[1] http://www.modulecounts.com/ [2] https://modules.perl6.org/
> CPAN is anything but vibrant by today's standards.
This isn't all old code churn either, from some brief clicking around new CPAN distributions in January peaked in 2005 at 251, whereas January 2017 saw 187[3].
Sure, Perl has been surpassed to a large extent proportional to other languages, but what tends to get forgotten in these comparison between language popularity is that even languages that have "fallen from grace" are comparatively going just as strong as they were 10 years ago, because computing has grown in the aggregate.
Which means that while your language of choice may not be as well known to your typical programmer as it was 10 years ago, the likelyhood of finding an existing module to perform some task is about the same.
1. http://stats.cpantesters.org/trends.html#stats12
2. http://stats.cpantesters.org/newdistros/2005.html
3. http://stats.cpantesters.org/newdistros/2017.html
> Perl 6 depends upon the continued vibrancy of the CPAN community.
Why do you say that? Is this a theoretical point, a reasonable conclusion based on reading about Perl 6, or something based on trying and failing to do something with Perl 6?
> IMHO, CPAN is anything but vibrant by today's standards.
Have you encountered problems that aren't being addressed? What do you make of the river cleanup effort[1] and the new metacpan?[2]
> many [CPAN modules] are aging.
Do you agree that "aging" that's due to modules continuing to work without needing to be changed (due to careful maintenance of backward compatibility and mass testing[3]) is actually a good thing even if it looks bad?
Do you agree that the same "aging" point can reasonably be made about the module archives of Python, Haskell, Fortran and Rust? If not, what is/are the key difference(s)?
> Fewer than 800 modules are known to exist for Perl 6.
Do you agree this might be a good sign, reflecting the "lots built in" aspect of Perl 6?
Are you aware that it's possible to use ordinary Perl 6 code with modules from Python, Ruby, Lua, Perl 5, etc.?[4]
[1] http://neilb.org/2015/04/20/river-of-cpan.html
[2] https://metacpan.org/about/meta_hack
[3] http://stats.cpantesters.org/
[4] http://modules.perl6.org/#q=inline
Why do you say that? Is this a theoretical point, a reasonable conclusion based on reading about Perl 6, or something based on trying and failing to do something with Perl 6?
> IMHO, CPAN is anything but vibrant by today's standards.
Have you encountered problems that aren't being addressed? What do you make of the river cleanup effort[1] and the new metacpan?[2]
> many [CPAN modules] are aging.
Do you agree that "aging" that's due to modules continuing to work without needing to be changed (due to careful maintenance of backward compatibility and mass testing[3]) is actually a good thing even if it looks bad?
Do you agree that the same "aging" point can reasonably be made about the module archives of Python, Haskell, Fortran and Rust? If not, what is/are the key difference(s)?
> Fewer than 800 modules are known to exist for Perl 6.
Do you agree this might be a good sign, reflecting the "lots built in" aspect of Perl 6?
Are you aware that it's possible to use ordinary Perl 6 code with modules from Python, Ruby, Lua, Perl 5, etc.?[4]
[1] http://neilb.org/2015/04/20/river-of-cpan.html
[2] https://metacpan.org/about/meta_hack
[3] http://stats.cpantesters.org/
[4] http://modules.perl6.org/#q=inline
I'm no Perl user, but surely 800 is pretty good for a one year old language? How many did Perl 5 have when it was one year old? (That's a trick question: CPAN was officially launched about year after Perl 5 came out; see here http://history.perl.org/PerlTimeline.html)
It looks like Perl 6 does a good job of letting you use modules from other languages, which should help quite a bit.
Here's a link I found on Reddit showing an example of using Python's matplotlib from Perl 6.
https://gist.github.com/awwaiid/ef3f0abcfa96e34977b4
Here's a link I found on Reddit showing an example of using Python's matplotlib from Perl 6.
https://gist.github.com/awwaiid/ef3f0abcfa96e34977b4
It doesn't help that CPAN is an archaic module system with a user interface (PAUSE) straight out of 1995.
PAUSE is ugly, though I mostly use automated uploaders so I don't have to look at it.
I'm not sure what you find archaic about CPAN, the package/distribution distinction is a huge win that the rest of the world still hasn't caught on to, and the file-based nature means it scales stupidly well (npm's scaling issues simply can't happen to us).
Unless by archaic you mean "built as simply as possible, and built to last", which is basically why I love it :)
I'm not sure what you find archaic about CPAN, the package/distribution distinction is a huge win that the rest of the world still hasn't caught on to, and the file-based nature means it scales stupidly well (npm's scaling issues simply can't happen to us).
Unless by archaic you mean "built as simply as possible, and built to last", which is basically why I love it :)
I'm the rare person who never used Perl 5 but is trying to learn Perl 6. I haven't progressed beyond very simple scripts, but it's interesting. I especially am interested in the grammars, so I'll try to find a task where I'd get to explore them.
I have no plans to try and ship software written in it.
I have no plans to try and ship software written in it.
I'm in a similar boat. Many of the features make for great analysis language.
What do you mean by analysis? Text analysis? I'm curious what features drew you toward it.
Personally I think the optional typing looks interesting.
Personally I think the optional typing looks interesting.
Gradual typing, grammars for parsing, writing your own operators for common tasks, FP style for one-liners...there are more, but I'll have to add later when not drawing a blank.
I honestly haven't heard of anyone using Perl for anything new. Sure there is a lot of legacy Perl 5 being used and maintained, but Perl 6? For a new project? I've never even seen it on a short list.
ZipRecruiter, Booking.com, Duck Duck Go, and Craigslist are still building new things in Perl 5. It's out there still, you just have to hunt for it. Here's a site that lists Perl projects and companies:
http://www.builtinperl.com
By the way, do the guys who maintain www.builtinperl.com happen to be here? I submitted a new entry for it but haven't heard back for weeks. Another email has been sent but also hasn't seen any response.
I promise you there are a lot of really high profile new projects being developed in Perl 5 still. A lot of companies tend not to advertise their use of Perl because it has a bad reputation (somewhat undeservingly in my opinion) or because of a tendency for some organisations to be secretive about their infrastructure. But I've worked on some pretty major projects, in Perl, over the last 5 years.
I use perl for new code all the time. It's not a trendy language, so it won't get much coverage on HN, but the language and libraries are great IMO.
Also, perl 6 is effectively a completely different language from 'normal' perl (i.e. perl 5.x). The difference between the two is far far bigger than say python 2 -> 3.
As a perl programmer, I see no obvious benefit from switching from perl 5 -> 6, it would be the same as switching from perl to a completely different language. You're not going to be able to take your existing code and familiar libraries with you.
Also, perl 6 is effectively a completely different language from 'normal' perl (i.e. perl 5.x). The difference between the two is far far bigger than say python 2 -> 3.
As a perl programmer, I see no obvious benefit from switching from perl 5 -> 6, it would be the same as switching from perl to a completely different language. You're not going to be able to take your existing code and familiar libraries with you.
Perl6 is not, IMHO, a completely different language and I can't understand why the Perl6 community beat this drum so hard. "use <version>;" "my" variables, context awareness, $@% variable identifiers, list emphasis. At the syntactic level Perl6 is very similar to Perl5. OK, it's OO under the hood, unlike Perl5. If it's a completely different language why name it Perl6?
The OO part is actually one of the tiniest of changes. You can get basically the same thing in Perl 5 by using Moose.
It has signature, and subsignature parsing, built-in concurrency, not to mention over a dozen other features that are not in Perl 5. The main reason it is called Perl 6 is how the project began. It started out as Perl 5 minus a few warts.
As someone who well versed in both, they are very similar, and very different at the same time.
I like to categorize the differences like this:
Perl 4 is to C, as Perl 5 is to C++, as Perl 6 is to Haskell,Scheme,C#,D,Go,BNF...
That is Perl 6 brings in features from many diverse programming languages, and combines them in such a way that it feels like they have always belonged together.
It has signature, and subsignature parsing, built-in concurrency, not to mention over a dozen other features that are not in Perl 5. The main reason it is called Perl 6 is how the project began. It started out as Perl 5 minus a few warts.
As someone who well versed in both, they are very similar, and very different at the same time.
I like to categorize the differences like this:
Perl 4 is to C, as Perl 5 is to C++, as Perl 6 is to Haskell,Scheme,C#,D,Go,BNF...
That is Perl 6 brings in features from many diverse programming languages, and combines them in such a way that it feels like they have always belonged together.
Perl was my goto language for over 10 years but I lost my patience with the Perl6 for Christmas meme around 2013 by which time Ruby was a much better proposition. If the Perl5 community had finally found a way to adopt a MOP they might have had a chance of competing with Ruby and Python. I also feel Perl might have had better adoption in web development if the community had rallied round Mojolicious instead of Catalyst. Catalyst's routing via subroutine signatures is an abomination.
As someone who knows neither version, I find this surprising. Surely, even if none of your code works, switching from Perl 5 to Perl 6 is much less of a "culture shock" than switching to, say, Ruby or Python?
As someone who still occasionally has to write Perl 5 for a living, Perl 6 really is a new language. And because Perl 6 isn't as mainstream as Ruby or Python, there is a bigger culture shock when trying to find resources or figure out the "right way" to do things (I know, I know, There Is More Than One Day To Do It). There are big changes to the syntax too that make it feel like less of a successor and more of a new language inspired by an old one.
Switching from Perl5 to Perl6 isn't completely shocking, but it's not just copying code over to a new project either. Programming in Perl6 back to back with programming in Perl5 indeed feels quite a bit like switching back and forth between Perl5 and Ruby. Everything's similar enough that you have to mind the differences. It's a much different feeling than going back and forth between C and JavaScript or between Forth and Pascal where the syntaxes are so different you'd never try the other way to do something for just a couple of lines.
That's the thing - what OP said is exactly the case. Perl5 is an order of magnitude closer to ES6 than it is to Rakudo.
ES6 is a language specification and Rakudo is software. When Perl is written in uppercase it usually means the language, so what you said is true but not informative.
IIRC there's a module for parsing and running Perl 5 in 6. Am I wrong or is it not practically useful?
I think you mean Inline::Perl5: https://github.com/niner/Inline-Perl5. It doesn't parse Perl 5 and run it inside of Perl 6 though, it just runs the Perl 5 interpreter for you from a Perl 6 program and lets you marshall data between the interpreters. It's a legitimate technique.
> lets you marshall data between the interpreters.
To be clear, Inline::Perl5 (and the other inlines like Inline::Python) automatically marshal data.
And exceptions. And classes (so you can sub-class a Perl 5 or Python etc. class in Perl 6). Etc.
To be clear, Inline::Perl5 (and the other inlines like Inline::Python) automatically marshal data.
And exceptions. And classes (so you can sub-class a Perl 5 or Python etc. class in Perl 6). Etc.
There is the v5 project implementing Perl 5 targetting nqp to be compiled inline with a Perl 6 program. https://github.com/rakudo-p5/v5
The project has mostly stalled since Inline::Perl5 became so effective. v5 had the issue of being unable to easily support binary XS type modules. Which means it could never support CPAN, unlike Inline::Perl5. It was meant for people to be able to copy their high mental cost algo code into a new Perl 6 project without fuss.
The project has mostly stalled since Inline::Perl5 became so effective. v5 had the issue of being unable to easily support binary XS type modules. Which means it could never support CPAN, unlike Inline::Perl5. It was meant for people to be able to copy their high mental cost algo code into a new Perl 6 project without fuss.
Perl6 looks like a great language. What Perl6 needs is a clear branding message which in most cases has to do to a clear use-case scenario. People need to know why do they need Perl6. In late 1990s and early 2000s Perl was CGI, which was dynamic pages on the internet.
What is Perl6 now?
What is Perl6 now?
For me, Perl 6's "killer feature" is the same as Perl 5's: the ability to parse arbitrary textual data with relative ease. Perl 5's regex syntax ended up becoming probably the most common thereof (mostly by way of PCRE); I suspect Perl 6's "grammars" could do the same and serve as "the" syntax for PEGs.
All of Oh By[1][2] is built on perl.
It's a very basic (primitive ?) CGI/perl design made performant with mod-perl, etc.
I started my career building shopping carts based on what I learned from _The CGI Book_ (and the web forum that sprung from it) ... 23 years later we're building a modern startup based on the same workflow.
[1] https://0x.co
[2] https://0x.co/hnfaq.html
It's a very basic (primitive ?) CGI/perl design made performant with mod-perl, etc.
I started my career building shopping carts based on what I learned from _The CGI Book_ (and the web forum that sprung from it) ... 23 years later we're building a modern startup based on the same workflow.
[1] https://0x.co
[2] https://0x.co/hnfaq.html
I've used Perl as my primary programming language over 20 years and think that Perl 6 is a big improvement. I've been using 6 for new Perl software since 2012 (one 500 line program I run once a week and a few other 30 lines or less programs used one time) with good results---learning Perl 6 was hard for me---am looking forward to Perl 6 books. Thanks to all the people that made Perl 5 and 6 possible.
follow-up: for a non-Perl person, who is incredibly interested in getting started with Perl 6, are there any good resources (code examples, blog posts exploring language concepts unique to Perl 6) that anyone would recommend?
I'm writing a book about Perl 6 right now, targeted at folks who already know some programming language(s), but not necessarily Perl 5: https://leanpub.com/perl6
There are 9 chapters out there already, which you get you started nicely. Feedback would be very welcome!
There are 9 chapters out there already, which you get you started nicely. Feedback would be very welcome!
Thanks, I'll give it a look and probably give you feedback... a long time from now. I get to things slowly, but I do get to them :)
I believe some folks recommended the examples on Rosetta code for getting a feel about Perl idioms to me. http://rosettacode.org/wiki/Category:Perl_6
Thanks for the suggestion. Things like Rosetta Code and Learn X in Y minutes always seem to flee from my headspace when I ask these questions.
Check out the new comers section here https://perl6.org/resources/
Several books are in the process of coming out.
So far I've used it for several small tools, including some that refactored code for other, larger projects. Grammars really make that pleasant.
Are any of those open source? I'd like to see grammars used in "real" code, not just examples.
Real grammar [1], regularly used by me, at least. It may not be the best way of doing things today, it was written three or four Perl 6 compilers ago. But it works on the latest Rakudo release.
[1] https://github.com/colomon/ABC/blob/master/lib/ABC/Grammar.p...
Edited to add: I think originally based it on https://web.archive.org/web/20120201072612/http://www.norbec...
[1] https://github.com/colomon/ABC/blob/master/lib/ABC/Grammar.p...
Edited to add: I think originally based it on https://web.archive.org/web/20120201072612/http://www.norbec...
use perl5 instead because it is already there on unix systems. Use it to collect infrastructure data, scrape logs, query databases, or even for some statistics/math on the fly. If on an island I will take perl5 (and golang :-) I had hopes for perl6 but it got cumbersome in practice ...
I'll be downvoted for that but isn't Perl been replaced by Python in the last 7-8 years? I've never seen Perl used in the companies I've worked for in the past 6 years.
I think python adoption is kinda an overreaction to perl 5's warts: for example, too much punctuation switches to too little.
Python does a few things much better than perl 5. The obvious ones are the REPL and support for C bindings. However, I still find it miserable to work with.
Hopefully, perl 6 learned from python's mistakes (as well as from perl 5's mistakes).
Python does a few things much better than perl 5. The obvious ones are the REPL and support for C bindings. However, I still find it miserable to work with.
Hopefully, perl 6 learned from python's mistakes (as well as from perl 5's mistakes).
No. It's sad but I often have to teach younger JS and Python devs about Linux and Bash. And one aspect of Perl is as a better Bash.
I honestly have no idea why Python got so popular in that space. Those Python guys are always amazed when I show them a much more elegant Perl solution to their problem.
I honestly have no idea why Python got so popular in that space. Those Python guys are always amazed when I show them a much more elegant Perl solution to their problem.
I'd say that the new generation leaned towards Python, Ruby, and the like instead of Perl, and with a boom in computer geek culture, those communities just outgrew the Perl one. Also, because the languages like Python, Ruby and JS are used in startups and the like those got more coverage in conferences and books, courses etc. And now anything that doesn't have that sort of traction seems to be obsolete and/or born to die by some.
That said, frankly your comment is a bit off-topic and irrelevant--and you may get downvoted for that--because the question was not "Why use Perl 6 or not" but literally "What you do with it".
That said, frankly your comment is a bit off-topic and irrelevant--and you may get downvoted for that--because the question was not "Why use Perl 6 or not" but literally "What you do with it".
I've been a Perl user since 1994 or so, using it for an endless variety of small scripts to aid my $work and computer use in general. Since 2010 or so the vast majority of new scripts I've written have been in Perl 6, and I've ported a few of the older ones rather than try to make extensive modifications in my old Perl 6 code.
My biggest Perl 6 project (much bigger than anything I ever tried in Perl 4/5) is the ABC module [1]. This provides a grammar for parsing ABC music notation [2], a set of classes for representing ABC data, and some scripts built using it. The one I use the most is abc2ly, which translates ABC files to Lilypond format [3] for producing beautiful sheet music [4].
The other tool of mine I use routinely is TagTools [5]. There's nothing really fancy there, just a bunch of simple scripts which use Perl 6's Audio::Taglib::Simple module to work with the tags on MP3 files. But they were easy to write, come in handy for working with MP3s, and are easy to modify for odd cases.
Recently I've done a couple of scripts which rely on Inline::Python. The latest is wunderlist.pl, which I have installed in cron to update my Wunderlist to-do list every day. There is (to the best of my knowledge) no Perl6 module for working with the Wunderlist API, but there is a Python module, wunderpy2. There is a bit of boilerplate glue code there (lines 16-21 of the script) but once that's done using the Python module is almost indistinguishable from working with normal Perl 6. (Of course, if you're fluent in Python this maybe isn't such a big deal for you, but I don't know more than a tiny bit of Python, and Inline::Python lets me effectively use Python modules from the comfortable-to-me world of Perl 6.)
[1] https://github.com/colomon/ABC (Note that as I write this, the README is about 4 years out of date.]
[2] http://abcnotation.com/
[3] http://lilypond.org/
[4] For instance, http://www.harmonyware.com/tunes/They_Sailed_From_Belfast.ht...
[5] https://github.com/colomon/TagTools
[6] https://gist.github.com/colomon/89a6e7b8bf7694aa42e83058bb43...
My biggest Perl 6 project (much bigger than anything I ever tried in Perl 4/5) is the ABC module [1]. This provides a grammar for parsing ABC music notation [2], a set of classes for representing ABC data, and some scripts built using it. The one I use the most is abc2ly, which translates ABC files to Lilypond format [3] for producing beautiful sheet music [4].
The other tool of mine I use routinely is TagTools [5]. There's nothing really fancy there, just a bunch of simple scripts which use Perl 6's Audio::Taglib::Simple module to work with the tags on MP3 files. But they were easy to write, come in handy for working with MP3s, and are easy to modify for odd cases.
Recently I've done a couple of scripts which rely on Inline::Python. The latest is wunderlist.pl, which I have installed in cron to update my Wunderlist to-do list every day. There is (to the best of my knowledge) no Perl6 module for working with the Wunderlist API, but there is a Python module, wunderpy2. There is a bit of boilerplate glue code there (lines 16-21 of the script) but once that's done using the Python module is almost indistinguishable from working with normal Perl 6. (Of course, if you're fluent in Python this maybe isn't such a big deal for you, but I don't know more than a tiny bit of Python, and Inline::Python lets me effectively use Python modules from the comfortable-to-me world of Perl 6.)
[1] https://github.com/colomon/ABC (Note that as I write this, the README is about 4 years out of date.]
[2] http://abcnotation.com/
[3] http://lilypond.org/
[4] For instance, http://www.harmonyware.com/tunes/They_Sailed_From_Belfast.ht...
[5] https://github.com/colomon/TagTools
[6] https://gist.github.com/colomon/89a6e7b8bf7694aa42e83058bb43...
I think DuckDuckGo uses Perl 6 in production. Some of those devs have accounts here, so maybe they'll speak up.
Was very interested some years ago but lately I think many of the things I don't like with for example C# has snuck into the syntax.
Capital letter keywords etc.
Wish it was more like Perl 5 and more performant.
But we shall see, it might change a lot the next years as it matures.
Capital letter keywords etc.
Wish it was more like Perl 5 and more performant.
But we shall see, it might change a lot the next years as it matures.
I can't think of a single capitalized keyword.
Unless you mean capitalized built-in classes, or the infix meta operators.
Certain parts are faster than Perl 5, for example this finds the sum of a range in less than a millisecond. ( of course it cheats by calling the sum method on the Range object )
There are other places where if you write your code carefully knowing the ins and outs of the implementation, where Perl 6 is faster than you could get in Perl 5.
Then there is the fact that a lot of optimizations that are known about aren't being done, and a new JIT is in the works for MoarVM.
Unless you mean capitalized built-in classes, or the infix meta operators.
Certain parts are faster than Perl 5, for example this finds the sum of a range in less than a millisecond. ( of course it cheats by calling the sum method on the Range object )
my $sum = [+] 1..100000000000000000000000;
There are other places where if you write your code carefully knowing the ins and outs of the implementation, where Perl 6 is faster than you could get in Perl 5.
Then there is the fact that a lot of optimizations that are known about aren't being done, and a new JIT is in the works for MoarVM.
Perhaps worth another look again. I remember 'Int', '.WHAT', etc. from some presentations and that stung in my eyes a bit.
Perl 6 makes careful use of letter case to convey useful information.
If it's in ALL CAPS then it's drawing some attention to the fact that something VERY UNUSUAL is going on.
For example, `WHAT`, `HOW` etc. are special compiler macros, not at all ordinary routines. Fortunately there's little or no need to use these in typical Perl 6 programs.
Another example are the "phasers" CATCH, LEAVE, UNDO, etc. These are unusual because they are executed according to execution phases rather than the sequential order of code.
Another convention is use of initial caps. All built in object type names use initial caps. Hence `Int` for the arbitrary size integer type. (Use `int` for the native machine oriented alternative.)
This all may sound weird but I find it works well for me in practice.
If it's in ALL CAPS then it's drawing some attention to the fact that something VERY UNUSUAL is going on.
For example, `WHAT`, `HOW` etc. are special compiler macros, not at all ordinary routines. Fortunately there's little or no need to use these in typical Perl 6 programs.
Another example are the "phasers" CATCH, LEAVE, UNDO, etc. These are unusual because they are executed according to execution phases rather than the sequential order of code.
Another convention is use of initial caps. All built in object type names use initial caps. Hence `Int` for the arbitrary size integer type. (Use `int` for the native machine oriented alternative.)
This all may sound weird but I find it works well for me in practice.
I hope these things are explained well in the upcoming books. Me, a seasoned Perl 5 programmer that doesn't participate much in the Perl 6 community find these things a bit strange and visually a turnoff if you get what I mean. Also angle brackets usage no auto quoting was something I remember not liking too much.
Note that this has more to do with familiarity and syntax than the new features etc. I very much hope for a "Java killer" in the Perl family but that means performance must be a first priority.
Thanks for explaining, at least I can view examples with a little more understanding of the syntax choices going forward.
Note that this has more to do with familiarity and syntax than the new features etc. I very much hope for a "Java killer" in the Perl family but that means performance must be a first priority.
Thanks for explaining, at least I can view examples with a little more understanding of the syntax choices going forward.
I have been programming Perl 5 for many years in the finance industry. I have not seen any Perl 6. In the last year I have been using Go in conjunction with Perl to handle some of the cases where Go solves the problem better.
reading through the docs in perl 6 is really fun and I'm similarly interested in it. I think, however, that it will take some dedicated usage to get momentum going so you are stuck in a catch 22. :)
I'm actively following the project, but waiting for it to mature (speed, doc...etc) before using it.
I wrote some scripts for my little tasks.
Thats cool thing !
Perhaps you should look at this two presentations first:
https://media.ccc.de/v/31c3_-_6243_-_en_-_saal_1_-_201412292...
https://media.ccc.de/v/32c3-7130-the_perl_jam_2
https://media.ccc.de/v/31c3_-_6243_-_en_-_saal_1_-_201412292...
https://media.ccc.de/v/32c3-7130-the_perl_jam_2
Without trying to defend the merits of the language: I've watched the videos and those presentations were entertaining and nothing more. It's essentially well received trolling. The presenter knows the language so poorly that he conflated some core concepts as well as mixing up the distinction of issues in libraries versus in the language itself.
Really. There's lots of things wrong with Perl (all versions) and the same can be said about any other language. Alas these talks are among the worst put together criticisms I've seen so far.
Really. There's lots of things wrong with Perl (all versions) and the same can be said about any other language. Alas these talks are among the worst put together criticisms I've seen so far.
Those presentations were abhorrent and the conference should be embarrassed for giving such a buffoon the stage (twice!). He doesn't know the language and then lampoons it when he gets it wrong. Here are some rebuttals (one of which is mine) to the second talk https://gist.github.com/preaction/978ce941f05769b064f4. There are other rebuttals for the first one which can be found without too much difficulty.
Heard of that video. It's about Perl 6's sister language, Perl 5. And the presenter basically did this for shits and giggles. Even the module that supposedly has the exploits he talks about hasn't been recommended to use for over a decade.
I painfully watched the entire first presentation a while back, and at least a small part of the second before quitting. They both came across like "look how many times I can use the F word in an hour -- aren't I super smart and cool? -- I'm SO David Hansson".
I'll pass -- if it was just a troll (both times?), well I can't stand trolls anyway.
I didn't find it at all entertaining or funny. Mostly it just sounded sanctimonious.
I'll pass -- if it was just a troll (both times?), well I can't stand trolls anyway.
I didn't find it at all entertaining or funny. Mostly it just sounded sanctimonious.
Those talks could be summarizes as: Don't use CGI. Nobody has used it for over a decade so it's not really tested.
Which are good points, but you probably knew that anyway. The rest is just a lot of pictures from the web and some guy screaming "wtf!!" a lot.
It has very little to do with Perl5 the language. The part where he touches on that subject is based on misunderstandings on what contexts and references are.
Which are good points, but you probably knew that anyway. The rest is just a lot of pictures from the web and some guy screaming "wtf!!" a lot.
It has very little to do with Perl5 the language. The part where he touches on that subject is based on misunderstandings on what contexts and references are.
Looks like that's about Perl 5, not 6. (I am not going to watch such long videos without more info up front.)
The problems in that video are P5 centric. P6 is very different as far as how under the hood works