13 ms·

To my mind, the blockers for Perl 6 adoption in order of importance have been: 1. The name, saddling it with the legacy of Perl. (I say this as someone who rea

To my mind, the blockers for Perl 6 adoption in order of importance have been: 1. The name, saddling it with the legacy of Perl. (I say this as someone who really liked working with Perl back in the waning years of the old millennium, and believes that Perl was visionary in pointing the way to the state of modern programming... but also that it had some limitations that have only become more glaring over the years.) 2. The coyness around whether it's "done" or not. Right now today, as someone who has paid attention to Perl 6 and even written some toy code with it, I do not understand its release status at all. That's absurd. 3. The insistence on branding sub-components of it and exposing that branding. Yes, it has a VM. Yes, it has a compiler. But why do people talk about ParrotVM and Rakudo as if they're different things? Java has a compiler and a VM, they're called "javac" and "jvm." This wifty "no, Perl 6 is the standard, the software you're running is Rakudo and Parrot" distinction is totally irrelevant to anyone actually wanting to write code, and weirdly confusing. 4. In a distant, distant last place: any actual functional stuff about the language.

CogitoCogito 7y ago
> but also that it had some limitations that have only become more glaring over the years. I don't have any real experience with Perl, so could you maybe expand a little? I'm curious about what you think the limitations are.
- mkozlows 7y ago
  I mentioned it in another comment, but a really obvious one is that functions in Perl don't have parameters. Every function just takes in a list, and can do whatever it wants with that list. This page gives a good overview of the situation: https://perl101.org/subroutines.html https://perl101.org/subroutines.html There's a kind of elegant flexibility to that, but it also makes it really hard to program reliably in the large, to build useful tooling, or even to glance at a function and know what you should pass it. Beyond that, classic Perl was full of things that make it quick to write small programs (as CGI scripts were at the time) without a lot of boilerplate, but which don't scale up. (Perl 6 is very different, and has an almost comically flexible/powerful function signature system (https://docs.perl6.org/type/Signature https://docs.perl6.org/type/Signature). Whether or not you like Perl 6's stuff, it's nothing at all like Perl 5's.)
  - bmn__ 7y ago
    > functions in Perl don't have parameters Sorry, you are misinformed. That hasn't been true for a long time, see http://p3rl.org/Kavorka::Manual::Signatures http://p3rl.org/Kavorka::Manual::Signatures Other languages would kill for this kind of beyond-complete maximum overkill feature set. > This page gives a good overview of the situation: https://perl101.org/subroutines.html https://perl101.org/subroutines.html No, it doesn't. That page is not wrong, but incomplete and teaches the wrong stuff, wouldn't recommend. Instead see http://perl-tutorial.org/ http://perl-tutorial.org/ for recommended tutorials.
    - rubinelli 7y ago
      From the Perl 5.30 documentation: > WARNING: Subroutine signatures are experimental. The feature may be modified or removed in future versions of Perl. https://metacpan.org/pod/perlsub https://metacpan.org/pod/perlsub
      - mmcclimon 7y ago
        It's true that they're experimental, but it's extremely unlikely they'll be removed. The only reason they weren't stable in the most recent version of perl is because of some interactions with subroutine attributes (specifically, :lvalue) which needed some tweaking. We use them everywhere at Fastmail and they're great. Which is to say: a lot of the reason they're still experimental is because Perl's commitment to backward compatibility. Other languages might have said "oh well," but Perl 5 said "oh, an unintended consequence that might break real uses in the wild; we should wait another year."
    - iosonofuturista 7y ago
      So, the first tutorial on the list that you recommend has this page for functions[0]. It's more or less the same as GP's link. YOU are the one misinforming, it would seem. Granted, I don't work with perl (5, never tried 6) for about 15 years, but most criticism of it seems to align with my experiences back then. [0] http://mvp.kablamo.org/basics/functions/ http://mvp.kablamo.org/basics/functions/ Edit: The second [1] also recomends the @_ method, and the third [2] the shift method. Did you even read your own links? [1] https://perlmaven.com/subroutines-and-functions-in-perl https://perlmaven.com/subroutines-and-functions-in-perl [2] https://learnxinyminutes.com/docs/perl/ https://learnxinyminutes.com/docs/perl/ (search for subroutines)
- empath75 7y ago
  My experience is that Perl scripts other people wrote are impossible to understand. It made me never want to touch it again. I was handed several unmaintained ten year old Perl scripts to update and in every case I just rewrote it in python just because Perl gave me a migraine looking at it.
  - alabamenhu 7y ago
    That's a problem with the people who wrote the script, though, not the language itself. Consider the difference between a minified JS script or one produced with emscripten and the code pre-minification. One is unintelligible guaranteed, the other … maybe haha. Unfortunately, what tended to happen is people would write one liners, and slowly expand the one liners into more complex one liners, and then integrate them into larger scripts without refactoring. Regex can triple that problem (thankfully Perl 6 allows you to write some of the most intelligible — seriously! — regex out there).
    - kjs3 7y ago
      That's a problem with the people who wrote the script, though, not the language itself. That's like the folks who say "the problem with C (buffer overflow, UB, etc.) isn't C, it's the people who write C". Which leads to at some point contemplative folks deciding either "this is happening so often, maybe it is the language" or "the majority of people writing this language are incompetent". While I've heard plenty of people in the C community espouse the latter view, having written C since K&R days, I think most people acknowledge it's a problematic language. But I don't have empirical evidence of a ratio. I wrote a ton of Perl <=5 back in the day. I'm pretty sure I know why I thought it was a good idea at the time. I know where I fall on the above. I know why I, and virtually everyone I know professionally, don't solve problems in Perl any more. But hey...maybe I'm just incompetent.
      - empath75 7y ago
        About the ten millionth time that someone had a security breach from exposing s3 buckets aws decided to look into if maybe something in their UX was bad instead of blaming the user every time. ‘User error’ is rarely a sufficient explanation for why something negative happens, particular when those users are professionals using a professional product. At some point one needs look at whether there is something in the product that causes those errors to happen or that doesn’t do enough to prevent them.
- deleted 7y ago
  [deleted]
- hnick 7y ago
  I use Perl in my day job and enjoy it a lot, but the biggest showstopper for me is that its greatest strength is its greatest weakness. "There's more than one way to do it", it's amazing at getting things working, it excels at writing "glue" programs to shim between bigger and slower moving parts, especially if they're throwaway hacks. However all that flexibility means that it's not possible to run static analysis with full confidence. Yes, tools exist - but it's been proven impossible for them to catch all cases, and this uncertainty carries real risks for critical business processes. When you have a code base encompassing a set of core modules, with hundreds of auxiliary programs using them across the business, then any attempt to update perl or its modules grinds to a halt. It's impossible to even enumerate which programs will be impacted by the change with confidence, let alone the effects of such a change. For details see "Perl Cannot Be Parsed: A Formal Proof" (https://www.perlmonks.org/?node_id=663393 https://www.perlmonks.org/?node_id=663393). You can mitigate the impact with coding style guides and code reviews but once the damage is done it's very difficult to untangle an existing code base that loads modules at run-time and makes full use of Perl's flexible nature in other ways.
dragontamer 7y ago
> But why do people talk about ParrotVM and Rakudo as if they're different things? Java has a compiler and a VM, they're called "javac" and "jvm." Bad example: Java actually has many VMs available for it: Oracle, OpenJDK, Zing, and IBM come to mind. (EDIT: And "Dalvik", for all the Android fans). I'm unsure if Java has multiple compilers, but its quite possible. Python has CPython 2.0, CPython 3.0, and Jython at least. Probably a few others. When Perl 5 was huge, there were multiple VMs and interpreters: IronPerl comes to mind as a Windows implementation back in the day that had different quirks than the canonical Perl interpreter.
- ailideex 7y ago
  > Bad example: Java actually has many VMs available for it: Oracle, OpenJDK, Zing, and IBM come to mind. I'm unsure if Java has multiple compilers, but its quite possible. It does have multiple compilers for java, at least javac and ecj (eclipse compiler for java) http://blog.deepakazad.com/2010/05/ecj-eclipse-java-compiler.html http://blog.deepakazad.com/2010/05/ecj-eclipse-java-compiler... And if you consider groovy and scala and kotlin it has many more compilers.
  - spathi_fwiffo 7y ago
    ... and it also has Brand Names in abundance, even internally to java's core. JustInTime, HotSpot, Swing, Beans, etc.
- hestefisk 7y ago
  IronPerl was a .Net implementation of Perl so one could compile to IL. Afair, adoption was sparse.
- skykooler 7y ago
  > Python has CPython 2.0, CPython 3.0, and Jython at least. Probably a few others. ...and IronPython, Cython, PyPy, PythonNet, MicroPython, probably plenty more I'm forgetting.
  - d0mine 7y ago
earthboundkid 7y ago
I would move 4 up to 2. Every time I read an article about how cool Perl 6, I see the clever bits of syntax and think "WTF? I might enjoy playing with that for fun, but no way in hell would I use that for work."
- jrumbut 7y ago
  I think this is what I admire about Perl 6, though also it is why it wasn't released as the successor to Perl 5 10 years ago. It has some genuinely ambitious features, some things that (as someone who barely dabbles in new languages) that I haven't seen before, or combinations I hadn't seen. Something novel instead of the umpteenth iteration of "x with a better type system" or "x without that pesky type system".
  - earthboundkid 7y ago
    Yes, God bless them for making old Perl thirty years ago and popularizing the hash map as a core data type, and God bless them for making new Perl and whatever it brings. But I don't actually want to use either old or new Perl. :-)
- rootusrootus 7y ago
  The language geek part of me loves Perl. The business part of me would never let it be used for production code. Too much business risk to tolerate.
  - inimino 7y ago
    Counterpoint: this is why almost all business code lacks quality. (To be clear: not because people aren't writing Perl, but because we tend to reflexively reject any technology that people are passionate about because "risk". But the risk of writing trash code that nobody ever could be passionate about is less visible. Also: I'm not saying there's an easy solution to this problem.)
  - petre 7y ago
    Would you let JavaScript be used in production code? Because it is used and it's a mess.
kbenson 7y ago
> The insistence on branding sub-components of it and exposing that branding. Yes, it has a VM. Yes, it has a compiler. But why do people talk about ParrotVM and Rakudo as if they're different things? Java has a compiler and a VM, they're called "javac" and "jvm." This wifty "no, Perl 6 is the standard, the software you're running is Rakudo and Parrot" distinction is totally irrelevant to anyone actually wanting to write code, and weirdly confusing. The reason the implementation is named (Rakudo), is because there's a spec, and originally there were a few people making implementations. There was good effort from individuals on C and C# versions that were more monolithic, and Rakudo was where most the community work went since it was designed in a way to be more cross platform (it's mostly implemented in the minimal NQP languages, which is "not-quite perl". It's a much easier thing to port to a VM, and then you get like 90% of the language features already designed and working). The reason the VM is noted is because it changed a couple of times. Bringing the VM name into it lets people know that if it's different, maybe it will have fixed their main performance complaints. To my knowledge, they haven't used parrot in a decade or so, and there's actually some bad blood between the VM and Perl 6/Rakudo (which had different teams, another reason to brand with both. So, Perl 6 is the standard. There have been multiple implementations to varying degrees of completeness, including but not limited to Rakudo, Pugs, and Niecza. Those implementations have generally targeted one or more VM targets, including Parrot, MoarVM, Java, .Net and custom VMs. It may or may not have hurt adoption seeing this terminology, but it was there for a reason, because it denoted very large important aspects of what was going on behind the scenes, and in some cases doing otherwise could have worked against some relationships that were going on between projects.
- jannotti 7y ago
  You can tell that the parent post understands all that, right?
  - hitekker 7y ago
    As per usual, the GP sees the matter from a purely technical perspective, which occludes the larger business insight that the top-level comment provides.
hitekker 7y ago
3 is a common anti-pattern among software systems without clear leadership. Absent a steady, guiding hand, developers behind a component of a system are forced to set their own direction. Unfortunately, that direction stems from their motivation which is easily tainted by group ego. Maybe the developers feel like they're not getting the attention they deserve, maybe they have a big idea they want to solve and their tool is tangentially related. Or maybe they know exactly what to do, and the "other" people in the system do not. Whatever the rationalization is, it's enough to transmute their original purpose into a larger mission that everyone in their little silo agrees with, and that gradually diverges them from the rest of the system. "We're necessary and therefore we're important... more important than the system we were built for!" Eventually, a new name springs forth to signal their existence or even assert their dominance over the system to which they belong. The kind of thinking that plagued ParrotVM: https://news.ycombinator.com/item?id=7358646 https://news.ycombinator.com/item?id=7358646
laumars 7y ago
> 3. The insistence on branding sub-components of it and exposing that branding. Yes, it has a VM. Yes, it has a compiler. But why do people talk about ParrotVM and Rakudo as if they're different things? Java has a compiler and a VM, they're called "javac" and "jvm." This wifty "no, Perl 6 is the standard, the software you're running is Rakudo and Parrot" distinction is totally irrelevant to anyone actually wanting to write code, and weirdly confusing. I'm surprised by this comment because this is how pretty much every language works. C++ has specs and different compilers with different names and has done for decades. As does C, Python, Perl 5, Javascript, PHP, Lua, LISP, LOGO, BASIC, Pascal, SQL and your own example of Java has different compilers/interpreters/VMs. Often even in languages where the "spec" is defined by a reference implementation, you still find people building their own compilers or VMs for different platforms or use cases. It's really quite common to separate the language name (and specification version) from the compiler and runtime branding. In fact that used to be the norm back when target platforms differed wildly.
dragonwriter 7y ago
> The coyness around whether it's "done" or not. There's no coyness; the language spec and implementations are both actively developed, and it's a spec-first design, so Rakudo is sometimes incomplete with regard to the most-recent spec, but Rakudo is and for some time been a “production-ready, stable” implementation of Perl 6. The language has been consistently described as stable since the “Christmas” release, Perl 6.c, on 25 December 2015, though it took a bit longer before Rakudo had a production-ready 6.c implementation; the current (and currently supported in Rakudo) spec is 6.d, released last year. > Yes, it has a VM. Several, in fact. (More if you count defunct historical ones like Parrot.) > But why do people talk about ParrotVM and Rakudo as if they're different things? Because they are: ParrotVM is a (AFAIK) essentially dead multilanguage VM that Rakudo used to support; Rakudo currently has a MoarVM backend, and a JVM backend, and IIRC there is a non-production-ready JS backend that is available separately.
condercet 7y ago
This is a good list. The default user experience for Perl 6 needs to be dramatically improved. Developer ergonomics matter! Yes, when you run 'python' you get cpython, and Java is probably hotspot vm or openjdk or something (but Java is not a good example of developer ergonomics). Rust is one of the best examples here -- adoption is being driven by the ease-of-use of the entire toolchain, including the package manager and things as small as human readable compiler errors.
- mempko 7y ago
  perl6 has a REPL just like python if you just type perl6. There is a package manager called zef. It has some of the best and most human-readable compiler errors I have ever seen in a compiler. It has one of the simplest FFI to C I have seen to interface with the rest of the world. If there is anything perl6 got wrong, it wasn't ergonomics.
  - condercet 7y ago
    Yes, perl6 does a lot of things right. It's a great language and ecosystem that deserves more adoption. But all the things the parent comment listed, particularly branding, are in my mind part of developer ergonomics. And there is room for improvement. They wouldn't be talking about renaming the language if this wasn't the case.
    - mempko 7y ago
      Yup, definitely agree a rename is in order. I tell people, "You must try perl 6" and they go "Oh, I tried that long time ago in the 90s". They just don't here the "6" after the perl.
devit 7y ago
Feels like the big blocker is that it seems to only be useful if you insist on a language that is Perl-like but also modern, but most Perl programmers probably moved to other languages already and don't care about whether their language is Perl-like, and the remaining ones are probably mostly maintaining Perl 5 codebases that they don't want to rewrite. Ignoring the Perl angle, it's a language with a small ecosystem that doesn't seem to provide any groundbreaking advantage compared to existing languages, so no reason to adopt it. In general, to become popular a new language needs to provide one of those: 1. A new groundbreaking and useful paradigm that cannot be added to existing popular language ecosystems without a total compatibility break (e.g. Rust) 2. Compatibility with an existing ecosystem and significant improvements (e.g. Kotlin) 3. Being the best among languages required by a platform or program (e.g. Swift, also JavaScript when introduced) 4. Have one of the best ecosystems for a specific niche (e.g. Ruby when Rails got popular)
- mkozlows 7y ago
  The thing is, there are a LOT of new things in Perl 6. Its approach to regexes (with grammars) feels genuinely revolutionary, and it's got a lot of other neat things about it. I don't think it'd be instantly super-popular if it were a standalone, non-Perl-affiliated language, but I think it'd at least be talked about like Elixir or F# or Elm.
  - cies 7y ago
    I agree here. Language design needs some artistic freedom, and P6 is clearly exploring new areas in that regard. I always felt Perl <6 was the papa of Ruby: optimizing for (a) programmer's happiness. Perl showed the way in so many ways, combined with the object model of SmallTalk we got Ruby. Maybe P6 also has a some new ideas in that find their use in future languages. But we will only know after P6 gets used and loved and exposed to real world scenarios, what those "most valuable/copyable innovations" are...
  - goatinaboat 7y ago
    Its approach to regexes (with grammars) feels genuinely revolutionary Is that really a thing that couldn’t just be added to PCRE and be available in any language with bindings? F# has the advantage of easy interoperability with the vast .NET ecosystem.
cestith 7y ago
SBCL is not Common Lisp. ChickenScheme is not Scheme, nor is guile Scheme. GCC is not C. V8 is not JavaScript. Neither is SpiderMonkey. clang is also not C. tcc is not C. Visual C++ is not C or C++. Delphi is not Object Pascal. Pypy is not Python, nor is Jython, nor is Stackless Python, nor is IronPython. JRuby is not Ruby. yasm and fasm are not x86 assembly or x86_64 assembly or ARM assembly. I'm seeing a pattern of things that are named tools which are not the exact name of the language they compile or run.
- cogman10 7y ago
  Here's the difference. If I said "what's an implementation of Common lisp?" You'd say SBCL. If I Said "What's an implementation of C" you'd say GCC. If I said "What's an implementation of Javascript?" You'd say V8, Spidermonkey, etc. When I ask "What's an implementation of Perl6" The answer is "Nothing implements perl 6, isn't that wonderful!" It used to take forever diving around to find something that could run some subset of perl 6, usually with the disclaimer of "This isn't really perl 6, but rather a language that seems like perl 6" And you'd get the same thing from the mailing lists/etc.
  - dragonwriter 7y ago
    > When I ask "What's an implementation of Perl6" The answer is Rakudo (compiler) and Rakudo Star (full distribution). Both of which have been production-ready since shortly after the Perl 6.c spec release in December 2015. Your rant would be understandable back before there was a stable spec, especially long before when the in-process language description and the various implementations were sometimes far apart. But it's been years since it had even a remote resemblance to reality.
    - mkozlows 7y ago
      When a project has been going on for decades, things that have only changed in the last few years are not going to be immediately and obviously understood by people. The legacy of confusion and weirdness around the Perl 6 project is a legit problem, even/especially if it's no longer true and now Perl 6 is like a normal language.
simcop2387 7y ago
> 3. The insistence on branding sub-components of it and exposing that branding. Yes, it has a VM. Yes, it has a compiler. But why do people talk about ParrotVM and Rakudo as if they're different things? Java has a compiler and a VM, they're called "javac" and "jvm." This wifty "no, Perl 6 is the standard, the software you're running is Rakudo and Parrot" distinction is totally irrelevant to anyone actually wanting to write code, and weirdly confusing. Pedantically, and this also helps serve your point, Parrot isn't used by any modern Perl 6 implementation, it's effectively dead (if not totally). MoarVM is the less ambitious (not trying to support every dynamic language like Parrot was) and more mature VM that is in use now. And the requisite, ParrotVM is just pining for the fjords joke goes here. It has ceased to be, gone to meet it's maker, it is an Ex-Parrot. EDIT: For reference, Parrot VM really was named because of that sketch. It started as an April Fools joke and kinda stuck. https://web.archive.org/web/20100718195724/http://www.perl.com/pub/a/2001/04/01/parrot.htm https://web.archive.org/web/20100718195724/http://www.perl.c...
- evancox100 7y ago
  # copy stdin to stdout, except for lines starting with # while left_angle_right_angle: if dollar_underscore[0] =eq= "#": continue_next; } print dollar_underscore; } Hilarious...
  - merlincorey 7y ago
    The opening block with `:` and ending block with `}` literally killed me.
    - rbp 7y ago
      figuratively
      - jdironman 7y ago
        Characterally.
GordonS 7y ago
As a relative old-timer, I agree with your 1st point - when I think of Perl, I think of cryptic, ridiculously terse syntax. OTOH, "Perl" has existed forever... it would be kind of a shame to lose the name.
- Grinnz 7y ago
  It is not lost, Perl 5 is still developed.
- awinder 7y ago
  its okay, I’m fairly certain that there exists Perl 5 code that will outlast our very species
collyw 7y ago
I started my first programming job using Perl in 2003. There was talk about Perl 6 being ready soon. It sounded really cool like many people I was quite excited about it. Sadly the screwing around and refusing to give a real release date really messed things up ("It will be ready by Christmas, we just aren't saying which year"). I moved on to Python - which has been a good move career wise, but its a shame as I enjoyed using Perl and Perl 6 does have a lot of interesting ideas. Like you say, I have no idea about the release status either.
- daotoad 7y ago
  Let me clear that up for you, if you are still in doubt. Perl5 had a period of slow releases in the 2000s, this changed in 2010 with the release of version 5.12. Since then, Perl 5 has been on a yearly release cycle. The current release is version 5.30.0. When it became clear Perl6 wasn't coming any time soon, some people left Perl. Others knuckled down and wrote some great code that made Perl5 into a much better language. With many core feature additions and deprecations, new CPAN modules, and tooling to support consistent work by teams, the Perl5 language is more expressive and better than ever. Perl6 took forever, had major internal conflicts, but managed to survive and ship a specification in December 2015, version 6.c (6.a was an alpha version, and 6.b a beta). The Rakudo Perl6 compiler gets monthly releases, but most people install the Rakudo Star distribution, which bundles some extra modules and just makes life a bit easier. Rakudo Star began shipping "A usable Perl 6 compiler" in 2010. Regular releases tracked changes in the compiler. The Perl6.c spec was announced in December 2015, and the first Rakudo to implement it was released at the same time. Rakudo Star, lagged a bit and released in January 2016. Here's the Perl6 release announcement: https://perl6advent.wordpress.com/2015/12/25/christmas-is-here/ https://perl6advent.wordpress.com/2015/12/25/christmas-is-he... The Perl 6.d spec was released in November 2018, and the Rakudo 2018.11 version defaults to supporting it. Here's a link the Perl6 FAQ with more info on the Perl6 versioning and releases. https://docs.perl6.org/language/faq https://docs.perl6.org/language/faq If you liked Perl5 then, come back and give modern perl5 a try. Perl6 is an amazingly expressive and fun language to write with.
  - petre 7y ago

CogitoCogito 7y ago

> but also that it had some limitations that have only become more glaring over the years. I don't have any real experience with Perl, so could you maybe expand a little? I'm curious about what you think the limitations are.

mkozlows 7y ago
I mentioned it in another comment, but a really obvious one is that functions in Perl don't have parameters. Every function just takes in a list, and can do whatever it wants with that list. This page gives a good overview of the situation: https://perl101.org/subroutines.html https://perl101.org/subroutines.html There's a kind of elegant flexibility to that, but it also makes it really hard to program reliably in the large, to build useful tooling, or even to glance at a function and know what you should pass it. Beyond that, classic Perl was full of things that make it quick to write small programs (as CGI scripts were at the time) without a lot of boilerplate, but which don't scale up. (Perl 6 is very different, and has an almost comically flexible/powerful function signature system (https://docs.perl6.org/type/Signature https://docs.perl6.org/type/Signature). Whether or not you like Perl 6's stuff, it's nothing at all like Perl 5's.)
- bmn__ 7y ago
  > functions in Perl don't have parameters Sorry, you are misinformed. That hasn't been true for a long time, see http://p3rl.org/Kavorka::Manual::Signatures http://p3rl.org/Kavorka::Manual::Signatures Other languages would kill for this kind of beyond-complete maximum overkill feature set. > This page gives a good overview of the situation: https://perl101.org/subroutines.html https://perl101.org/subroutines.html No, it doesn't. That page is not wrong, but incomplete and teaches the wrong stuff, wouldn't recommend. Instead see http://perl-tutorial.org/ http://perl-tutorial.org/ for recommended tutorials.
  - rubinelli 7y ago
    From the Perl 5.30 documentation: > WARNING: Subroutine signatures are experimental. The feature may be modified or removed in future versions of Perl. https://metacpan.org/pod/perlsub https://metacpan.org/pod/perlsub
    - mmcclimon 7y ago
      It's true that they're experimental, but it's extremely unlikely they'll be removed. The only reason they weren't stable in the most recent version of perl is because of some interactions with subroutine attributes (specifically, :lvalue) which needed some tweaking. We use them everywhere at Fastmail and they're great. Which is to say: a lot of the reason they're still experimental is because Perl's commitment to backward compatibility. Other languages might have said "oh well," but Perl 5 said "oh, an unintended consequence that might break real uses in the wild; we should wait another year."
  - iosonofuturista 7y ago
    So, the first tutorial on the list that you recommend has this page for functions[0]. It's more or less the same as GP's link. YOU are the one misinforming, it would seem. Granted, I don't work with perl (5, never tried 6) for about 15 years, but most criticism of it seems to align with my experiences back then. [0] http://mvp.kablamo.org/basics/functions/ http://mvp.kablamo.org/basics/functions/ Edit: The second [1] also recomends the @_ method, and the third [2] the shift method. Did you even read your own links? [1] https://perlmaven.com/subroutines-and-functions-in-perl https://perlmaven.com/subroutines-and-functions-in-perl [2] https://learnxinyminutes.com/docs/perl/ https://learnxinyminutes.com/docs/perl/ (search for subroutines)
empath75 7y ago
My experience is that Perl scripts other people wrote are impossible to understand. It made me never want to touch it again. I was handed several unmaintained ten year old Perl scripts to update and in every case I just rewrote it in python just because Perl gave me a migraine looking at it.
- alabamenhu 7y ago
  That's a problem with the people who wrote the script, though, not the language itself. Consider the difference between a minified JS script or one produced with emscripten and the code pre-minification. One is unintelligible guaranteed, the other … maybe haha. Unfortunately, what tended to happen is people would write one liners, and slowly expand the one liners into more complex one liners, and then integrate them into larger scripts without refactoring. Regex can triple that problem (thankfully Perl 6 allows you to write some of the most intelligible — seriously! — regex out there).
  - kjs3 7y ago
    That's a problem with the people who wrote the script, though, not the language itself. That's like the folks who say "the problem with C (buffer overflow, UB, etc.) isn't C, it's the people who write C". Which leads to at some point contemplative folks deciding either "this is happening so often, maybe it is the language" or "the majority of people writing this language are incompetent". While I've heard plenty of people in the C community espouse the latter view, having written C since K&R days, I think most people acknowledge it's a problematic language. But I don't have empirical evidence of a ratio. I wrote a ton of Perl <=5 back in the day. I'm pretty sure I know why I thought it was a good idea at the time. I know where I fall on the above. I know why I, and virtually everyone I know professionally, don't solve problems in Perl any more. But hey...maybe I'm just incompetent.
    - empath75 7y ago
      About the ten millionth time that someone had a security breach from exposing s3 buckets aws decided to look into if maybe something in their UX was bad instead of blaming the user every time. ‘User error’ is rarely a sufficient explanation for why something negative happens, particular when those users are professionals using a professional product. At some point one needs look at whether there is something in the product that causes those errors to happen or that doesn’t do enough to prevent them.
deleted 7y ago
[deleted]
hnick 7y ago
I use Perl in my day job and enjoy it a lot, but the biggest showstopper for me is that its greatest strength is its greatest weakness. "There's more than one way to do it", it's amazing at getting things working, it excels at writing "glue" programs to shim between bigger and slower moving parts, especially if they're throwaway hacks. However all that flexibility means that it's not possible to run static analysis with full confidence. Yes, tools exist - but it's been proven impossible for them to catch all cases, and this uncertainty carries real risks for critical business processes. When you have a code base encompassing a set of core modules, with hundreds of auxiliary programs using them across the business, then any attempt to update perl or its modules grinds to a halt. It's impossible to even enumerate which programs will be impacted by the change with confidence, let alone the effects of such a change. For details see "Perl Cannot Be Parsed: A Formal Proof" (https://www.perlmonks.org/?node_id=663393 https://www.perlmonks.org/?node_id=663393). You can mitigate the impact with coding style guides and code reviews but once the damage is done it's very difficult to untangle an existing code base that loads modules at run-time and makes full use of Perl's flexible nature in other ways.

dragontamer 7y ago

> But why do people talk about ParrotVM and Rakudo as if they're different things? Java has a compiler and a VM, they're called "javac" and "jvm." Bad example: Java actually has many VMs available for it: Oracle, OpenJDK, Zing, and IBM come to mind. (EDIT: And "Dalvik", for all the Android fans). I'm unsure if Java has multiple compilers, but its quite possible. Python has CPython 2.0, CPython 3.0, and Jython at least. Probably a few others. When Perl 5 was huge, there were multiple VMs and interpreters: IronPerl comes to mind as a Windows implementation back in the day that had different quirks than the canonical Perl interpreter.

ailideex 7y ago
> Bad example: Java actually has many VMs available for it: Oracle, OpenJDK, Zing, and IBM come to mind. I'm unsure if Java has multiple compilers, but its quite possible. It does have multiple compilers for java, at least javac and ecj (eclipse compiler for java) http://blog.deepakazad.com/2010/05/ecj-eclipse-java-compiler.html http://blog.deepakazad.com/2010/05/ecj-eclipse-java-compiler... And if you consider groovy and scala and kotlin it has many more compilers.
- spathi_fwiffo 7y ago
  ... and it also has Brand Names in abundance, even internally to java's core. JustInTime, HotSpot, Swing, Beans, etc.
hestefisk 7y ago
IronPerl was a .Net implementation of Perl so one could compile to IL. Afair, adoption was sparse.
skykooler 7y ago
> Python has CPython 2.0, CPython 3.0, and Jython at least. Probably a few others. ...and IronPython, Cython, PyPy, PythonNet, MicroPython, probably plenty more I'm forgetting.
- d0mine 7y ago

earthboundkid 7y ago

I would move 4 up to 2. Every time I read an article about how cool Perl 6, I see the clever bits of syntax and think "WTF? I might enjoy playing with that for fun, but no way in hell would I use that for work."

jrumbut 7y ago
I think this is what I admire about Perl 6, though also it is why it wasn't released as the successor to Perl 5 10 years ago. It has some genuinely ambitious features, some things that (as someone who barely dabbles in new languages) that I haven't seen before, or combinations I hadn't seen. Something novel instead of the umpteenth iteration of "x with a better type system" or "x without that pesky type system".
- earthboundkid 7y ago
  Yes, God bless them for making old Perl thirty years ago and popularizing the hash map as a core data type, and God bless them for making new Perl and whatever it brings. But I don't actually want to use either old or new Perl. :-)
rootusrootus 7y ago
The language geek part of me loves Perl. The business part of me would never let it be used for production code. Too much business risk to tolerate.
- inimino 7y ago
  Counterpoint: this is why almost all business code lacks quality. (To be clear: not because people aren't writing Perl, but because we tend to reflexively reject any technology that people are passionate about because "risk". But the risk of writing trash code that nobody ever could be passionate about is less visible. Also: I'm not saying there's an easy solution to this problem.)
- petre 7y ago
  Would you let JavaScript be used in production code? Because it is used and it's a mess.

kbenson 7y ago

> The insistence on branding sub-components of it and exposing that branding. Yes, it has a VM. Yes, it has a compiler. But why do people talk about ParrotVM and Rakudo as if they're different things? Java has a compiler and a VM, they're called "javac" and "jvm." This wifty "no, Perl 6 is the standard, the software you're running is Rakudo and Parrot" distinction is totally irrelevant to anyone actually wanting to write code, and weirdly confusing. The reason the implementation is named (Rakudo), is because there's a spec, and originally there were a few people making implementations. There was good effort from individuals on C and C# versions that were more monolithic, and Rakudo was where most the community work went since it was designed in a way to be more cross platform (it's mostly implemented in the minimal NQP languages, which is "not-quite perl". It's a much easier thing to port to a VM, and then you get like 90% of the language features already designed and working). The reason the VM is noted is because it changed a couple of times. Bringing the VM name into it lets people know that if it's different, maybe it will have fixed their main performance complaints. To my knowledge, they haven't used parrot in a decade or so, and there's actually some bad blood between the VM and Perl 6/Rakudo (which had different teams, another reason to brand with both. So, Perl 6 is the standard. There have been multiple implementations to varying degrees of completeness, including but not limited to Rakudo, Pugs, and Niecza. Those implementations have generally targeted one or more VM targets, including Parrot, MoarVM, Java, .Net and custom VMs. It may or may not have hurt adoption seeing this terminology, but it was there for a reason, because it denoted very large important aspects of what was going on behind the scenes, and in some cases doing otherwise could have worked against some relationships that were going on between projects.

jannotti 7y ago
You can tell that the parent post understands all that, right?
- hitekker 7y ago
  As per usual, the GP sees the matter from a purely technical perspective, which occludes the larger business insight that the top-level comment provides.

hitekker 7y ago

3 is a common anti-pattern among software systems without clear leadership. Absent a steady, guiding hand, developers behind a component of a system are forced to set their own direction. Unfortunately, that direction stems from their motivation which is easily tainted by group ego. Maybe the developers feel like they're not getting the attention they deserve, maybe they have a big idea they want to solve and their tool is tangentially related. Or maybe they know exactly what to do, and the "other" people in the system do not. Whatever the rationalization is, it's enough to transmute their original purpose into a larger mission that everyone in their little silo agrees with, and that gradually diverges them from the rest of the system. "We're necessary and therefore we're important... more important than the system we were built for!" Eventually, a new name springs forth to signal their existence or even assert their dominance over the system to which they belong. The kind of thinking that plagued ParrotVM: https://news.ycombinator.com/item?id=7358646 https://news.ycombinator.com/item?id=7358646

laumars 7y ago

> 3. The insistence on branding sub-components of it and exposing that branding. Yes, it has a VM. Yes, it has a compiler. But why do people talk about ParrotVM and Rakudo as if they're different things? Java has a compiler and a VM, they're called "javac" and "jvm." This wifty "no, Perl 6 is the standard, the software you're running is Rakudo and Parrot" distinction is totally irrelevant to anyone actually wanting to write code, and weirdly confusing. I'm surprised by this comment because this is how pretty much every language works. C++ has specs and different compilers with different names and has done for decades. As does C, Python, Perl 5, Javascript, PHP, Lua, LISP, LOGO, BASIC, Pascal, SQL and your own example of Java has different compilers/interpreters/VMs. Often even in languages where the "spec" is defined by a reference implementation, you still find people building their own compilers or VMs for different platforms or use cases. It's really quite common to separate the language name (and specification version) from the compiler and runtime branding. In fact that used to be the norm back when target platforms differed wildly.

dragonwriter 7y ago

> The coyness around whether it's "done" or not. There's no coyness; the language spec and implementations are both actively developed, and it's a spec-first design, so Rakudo is sometimes incomplete with regard to the most-recent spec, but Rakudo is and for some time been a “production-ready, stable” implementation of Perl 6. The language has been consistently described as stable since the “Christmas” release, Perl 6.c, on 25 December 2015, though it took a bit longer before Rakudo had a production-ready 6.c implementation; the current (and currently supported in Rakudo) spec is 6.d, released last year. > Yes, it has a VM. Several, in fact. (More if you count defunct historical ones like Parrot.) > But why do people talk about ParrotVM and Rakudo as if they're different things? Because they are: ParrotVM is a (AFAIK) essentially dead multilanguage VM that Rakudo used to support; Rakudo currently has a MoarVM backend, and a JVM backend, and IIRC there is a non-production-ready JS backend that is available separately.

condercet 7y ago

This is a good list. The default user experience for Perl 6 needs to be dramatically improved. Developer ergonomics matter! Yes, when you run 'python' you get cpython, and Java is probably hotspot vm or openjdk or something (but Java is not a good example of developer ergonomics). Rust is one of the best examples here -- adoption is being driven by the ease-of-use of the entire toolchain, including the package manager and things as small as human readable compiler errors.

mempko 7y ago
perl6 has a REPL just like python if you just type perl6. There is a package manager called zef. It has some of the best and most human-readable compiler errors I have ever seen in a compiler. It has one of the simplest FFI to C I have seen to interface with the rest of the world. If there is anything perl6 got wrong, it wasn't ergonomics.
- condercet 7y ago
  Yes, perl6 does a lot of things right. It's a great language and ecosystem that deserves more adoption. But all the things the parent comment listed, particularly branding, are in my mind part of developer ergonomics. And there is room for improvement. They wouldn't be talking about renaming the language if this wasn't the case.
  - mempko 7y ago
    Yup, definitely agree a rename is in order. I tell people, "You must try perl 6" and they go "Oh, I tried that long time ago in the 90s". They just don't here the "6" after the perl.

devit 7y ago

Feels like the big blocker is that it seems to only be useful if you insist on a language that is Perl-like but also modern, but most Perl programmers probably moved to other languages already and don't care about whether their language is Perl-like, and the remaining ones are probably mostly maintaining Perl 5 codebases that they don't want to rewrite. Ignoring the Perl angle, it's a language with a small ecosystem that doesn't seem to provide any groundbreaking advantage compared to existing languages, so no reason to adopt it. In general, to become popular a new language needs to provide one of those: 1. A new groundbreaking and useful paradigm that cannot be added to existing popular language ecosystems without a total compatibility break (e.g. Rust) 2. Compatibility with an existing ecosystem and significant improvements (e.g. Kotlin) 3. Being the best among languages required by a platform or program (e.g. Swift, also JavaScript when introduced) 4. Have one of the best ecosystems for a specific niche (e.g. Ruby when Rails got popular)

mkozlows 7y ago
The thing is, there are a LOT of new things in Perl 6. Its approach to regexes (with grammars) feels genuinely revolutionary, and it's got a lot of other neat things about it. I don't think it'd be instantly super-popular if it were a standalone, non-Perl-affiliated language, but I think it'd at least be talked about like Elixir or F# or Elm.
- cies 7y ago
  I agree here. Language design needs some artistic freedom, and P6 is clearly exploring new areas in that regard. I always felt Perl <6 was the papa of Ruby: optimizing for (a) programmer's happiness. Perl showed the way in so many ways, combined with the object model of SmallTalk we got Ruby. Maybe P6 also has a some new ideas in that find their use in future languages. But we will only know after P6 gets used and loved and exposed to real world scenarios, what those "most valuable/copyable innovations" are...
- goatinaboat 7y ago
  Its approach to regexes (with grammars) feels genuinely revolutionary Is that really a thing that couldn’t just be added to PCRE and be available in any language with bindings? F# has the advantage of easy interoperability with the vast .NET ecosystem.

cestith 7y ago

SBCL is not Common Lisp. ChickenScheme is not Scheme, nor is guile Scheme. GCC is not C. V8 is not JavaScript. Neither is SpiderMonkey. clang is also not C. tcc is not C. Visual C++ is not C or C++. Delphi is not Object Pascal. Pypy is not Python, nor is Jython, nor is Stackless Python, nor is IronPython. JRuby is not Ruby. yasm and fasm are not x86 assembly or x86_64 assembly or ARM assembly. I'm seeing a pattern of things that are named tools which are not the exact name of the language they compile or run.

cogman10 7y ago
Here's the difference. If I said "what's an implementation of Common lisp?" You'd say SBCL. If I Said "What's an implementation of C" you'd say GCC. If I said "What's an implementation of Javascript?" You'd say V8, Spidermonkey, etc. When I ask "What's an implementation of Perl6" The answer is "Nothing implements perl 6, isn't that wonderful!" It used to take forever diving around to find something that could run some subset of perl 6, usually with the disclaimer of "This isn't really perl 6, but rather a language that seems like perl 6" And you'd get the same thing from the mailing lists/etc.
- dragonwriter 7y ago
  > When I ask "What's an implementation of Perl6" The answer is Rakudo (compiler) and Rakudo Star (full distribution). Both of which have been production-ready since shortly after the Perl 6.c spec release in December 2015. Your rant would be understandable back before there was a stable spec, especially long before when the in-process language description and the various implementations were sometimes far apart. But it's been years since it had even a remote resemblance to reality.
  - mkozlows 7y ago
    When a project has been going on for decades, things that have only changed in the last few years are not going to be immediately and obviously understood by people. The legacy of confusion and weirdness around the Perl 6 project is a legit problem, even/especially if it's no longer true and now Perl 6 is like a normal language.

simcop2387 7y ago

> 3. The insistence on branding sub-components of it and exposing that branding. Yes, it has a VM. Yes, it has a compiler. But why do people talk about ParrotVM and Rakudo as if they're different things? Java has a compiler and a VM, they're called "javac" and "jvm." This wifty "no, Perl 6 is the standard, the software you're running is Rakudo and Parrot" distinction is totally irrelevant to anyone actually wanting to write code, and weirdly confusing. Pedantically, and this also helps serve your point, Parrot isn't used by any modern Perl 6 implementation, it's effectively dead (if not totally). MoarVM is the less ambitious (not trying to support every dynamic language like Parrot was) and more mature VM that is in use now. And the requisite, ParrotVM is just pining for the fjords joke goes here. It has ceased to be, gone to meet it's maker, it is an Ex-Parrot. EDIT: For reference, Parrot VM really was named because of that sketch. It started as an April Fools joke and kinda stuck. https://web.archive.org/web/20100718195724/http://www.perl.com/pub/a/2001/04/01/parrot.htm https://web.archive.org/web/20100718195724/http://www.perl.c...

evancox100 7y ago
# copy stdin to stdout, except for lines starting with # while left_angle_right_angle: if dollar_underscore[0] =eq= "#": continue_next; } print dollar_underscore; } Hilarious...
- merlincorey 7y ago
  The opening block with `:` and ending block with `}` literally killed me.
  - rbp 7y ago
    figuratively
    - jdironman 7y ago
      Characterally.

GordonS 7y ago

As a relative old-timer, I agree with your 1st point - when I think of Perl, I think of cryptic, ridiculously terse syntax. OTOH, "Perl" has existed forever... it would be kind of a shame to lose the name.

Grinnz 7y ago
It is not lost, Perl 5 is still developed.
awinder 7y ago
its okay, I’m fairly certain that there exists Perl 5 code that will outlast our very species

collyw 7y ago

I started my first programming job using Perl in 2003. There was talk about Perl 6 being ready soon. It sounded really cool like many people I was quite excited about it. Sadly the screwing around and refusing to give a real release date really messed things up ("It will be ready by Christmas, we just aren't saying which year"). I moved on to Python - which has been a good move career wise, but its a shame as I enjoyed using Perl and Perl 6 does have a lot of interesting ideas. Like you say, I have no idea about the release status either.

daotoad 7y ago
Let me clear that up for you, if you are still in doubt. Perl5 had a period of slow releases in the 2000s, this changed in 2010 with the release of version 5.12. Since then, Perl 5 has been on a yearly release cycle. The current release is version 5.30.0. When it became clear Perl6 wasn't coming any time soon, some people left Perl. Others knuckled down and wrote some great code that made Perl5 into a much better language. With many core feature additions and deprecations, new CPAN modules, and tooling to support consistent work by teams, the Perl5 language is more expressive and better than ever. Perl6 took forever, had major internal conflicts, but managed to survive and ship a specification in December 2015, version 6.c (6.a was an alpha version, and 6.b a beta). The Rakudo Perl6 compiler gets monthly releases, but most people install the Rakudo Star distribution, which bundles some extra modules and just makes life a bit easier. Rakudo Star began shipping "A usable Perl 6 compiler" in 2010. Regular releases tracked changes in the compiler. The Perl6.c spec was announced in December 2015, and the first Rakudo to implement it was released at the same time. Rakudo Star, lagged a bit and released in January 2016. Here's the Perl6 release announcement: https://perl6advent.wordpress.com/2015/12/25/christmas-is-here/ https://perl6advent.wordpress.com/2015/12/25/christmas-is-he... The Perl 6.d spec was released in November 2018, and the Rakudo 2018.11 version defaults to supporting it. Here's a link the Perl6 FAQ with more info on the Perl6 versioning and releases. https://docs.perl6.org/language/faq https://docs.perl6.org/language/faq If you liked Perl5 then, come back and give modern perl5 a try. Perl6 is an amazingly expressive and fun language to write with.
- petre 7y ago