32 ms·

> 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

by raiph 10y ago

> 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 http://www.unicode.org/glossary/#grapheme

larodi 10y ago
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...
- eritain 10y ago
  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!
- raiph 10y ago
  > 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.?) [1] http://blogs.perl.org/users/book/2017/02/about-the-perl-toolchain-summit.html http://blogs.perl.org/users/book/2017/02/about-the-perl-tool... [2] http://perl6.party/post/IRC-Client-Perl-6-Multi-Server-IRC-Module http://perl6.party/post/IRC-Client-Perl-6-Multi-Server-IRC-M...

by raiph 10y ago

larodi 10y ago

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...

eritain 10y ago
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!
raiph 10y ago
> 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.?) [1] http://blogs.perl.org/users/book/2017/02/about-the-perl-toolchain-summit.html http://blogs.perl.org/users/book/2017/02/about-the-perl-tool... [2] http://perl6.party/post/IRC-Client-Perl-6-Multi-Server-IRC-Module http://perl6.party/post/IRC-Client-Perl-6-Multi-Server-IRC-M...