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...
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.
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
"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]
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
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?
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...
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!
> 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:
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: ' ';
}
}
Are you not willing to count this sort of use of CPAN's Perl 5 Mojo::UserAgent as part of Perl 6's virtual CPAN as it were?
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.?)
"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.
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.
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.
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.
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...