Ask HN: Why hasn't Perl 6 taken off yet?

178 points by totalperspectiv ↗ HN
I am new ish to perl, coming from Python, and absolutely love the language and the community! I've been poking around perl 6 and it seems even cooler! It has everything I want: gradual typing, multiple paradigms, an up and coming package manager, and a nifty logo.

So, why isn't it the poster child of the scripting languages yet?

280 comments

[ 6.0 ms ] story [ 267 ms ] thread
cuz the language is cryptic as fuck, using every symbol there is; code is like

    my a = fn { local $v= _[0] %~=->
possibly a time investment trade off, focusing on another C-style lang is not as big as a time investment, and translates better to C and C-lang derivites
Your example is problematic because it's not even perl code. Perl 6 code is actually pretty nifty

  for 'dict.txt'.IO.words -> $word {
        say "$word probably rhymes with Perl"
            if $word ~~ /[ea?|u|i] rl $/;
  
        say "$word is a palindrome"
            if $word eq $word.flip;
    }
I'm not convinced that your example is more readable than a typical program in perl5 without all the magic. To read this code you have to know that appending '.IO.words' to a string will magically cause the file name referenced in the string to be read and then split into words. I would find it much more readable to just say: open the file, loop over the lines, split them into words. Maybe it's one of those conventions I'd get used to over time but right now it just leaves me scratching my head. What if dict.txt doesn't exist? What if it's there but unreadable? What if it's there but a directory? Where is the error checking? Is this going to crash or throw an exception if an error occurs? How does it determine what a word is? I can't even find it in the IO documentation (https://docs.perl6.org/type/IO). So yeah, it's nifty, sort of. It seems more like a snippet to show how nifty itself is rather than something useful.
…Just curious, have you ever used any of Perl(5), Python, or Ruby before?

If I had to guess, ‘foo.IO.words’ probably turns ‘foo’ into an IO object of some sort and then reads words. (Whether it reads the whole file into a string and splits that into words, or if it just reads the next word generator/iterator-style is not especially relevant.) An error throws an exception, like it would in Python or Ruby ‘open('dict.txt')’.

Also I kinda doubt that ‘loop over lines and split them into words’ is more readable than ‘.words’ which presumably does exactly what it says on the tin.

A word is probably defined by either \b or UAX #29. (And since IIRC one of the goals of Perl6 is good support for Unicode, \b hopefully uses the word boundary algorithm in that appendix.)

If you come from only a Perl 5 background this is the issue. None of that is obvious. It is to someone who's seen OO languages that are a bit functional with good exception handling. In Perl 5 you would probably add to the top of the file:

  use warnings;
  use autodie;
To get similar functionality as the implicit Perl 6 IO error system.
Well, Perl 6 throws defined exceptions by default for most stuff like this, and would be very explicit as to why it couldn't open a file. Tests are part of the IO stuff too, to see if it exists beforehand if you like, or check permissions. Also, if you like you can do all the steps of using a normal file open and iterate over each line and split the words yourself if you want to. Your choice. ;)
https://docs.perl6.org/type/Str#(Cool)_method_IO leads you to: https://docs.perl6.org/type/IO$COLON$COLONPath leads you to: https://docs.perl6.org/type/IO$COLON$COLONPath#(Cool)_method...

It's a bit of a trap, I agree and we should fix it. Having all exceptions listed is on the list and will add another few hundred man hours to the nearly 5000 we invested in the docs so far.

If you really want to be verbose you can always write `open('foo.txt', :r).Str.split(/\W/)`. If you learn a new language there will be buildins that are well tested and may be more efficient then your solution (it isn't right now for your example. Rakudo does it exactly your way). It can be worth your time to learn what the standard library provides you with -- in any language that is.

You haven't looked at a non-ASCII based APL I gather? :)
my a = fn { local $v= _[0] %~=->

What is that? It certainly isn't Perl (5 or 6).

Because it waited too long and now everyone who needs scripts just uses Python/Ruby/Lua instead. I highly doubt Perl 6 will take off in any meaningful sense. Not to disparage the language, it's just the social dynamics of the software world and tastes have shifted. Perl is, rightfully or wrongfully, considered a legacy language of the 90s and it would take a serious re-branding and evangelization effort to change that perception. That being said, I know some folks who pull in pretty good bank maintaining Perl apps but they are definitely not writing Perl 6 on the day to day

The logo is cute, I will say.

I'll say that I love scripting languages and those languages are already dead...they just don't know it yet. Of course they're good for scripts, but I think we'll find them drop off a cliff like Perl5 in a few years. They're just too darn slow (coming from a python guy).If Perl6 can get to near Java speeds (assuming you use the gradual typing and help out the compiler), then dynamic languages may be saved. If not, it's all Swift/Rust/C#/JS from here.
Shortly after release I got interested, looked into it enough to discover that speed was a concern for the future and that the current implementation was super slow. I wandered away.
Well if you are wandering that way again it's a bit faster a year later. About 10x across the board would be a good estimate. That's still super slow for some things.
This is my own personal opinion, but I despise Perl. The language requires a ton of memorization of small, tedious rules that are arbitrary, and there are many disparate ways of writing the same thing. I remember giving up on Perl when I discovered that || and or were both "or" operators but had different precedences.

Again, this is my own personal opinion. I know many people have made some great software based on Perl, but it's the only language I won't touch with a 10 foot pole, and I've spent a couple of years programming in PHP and a year in COBOL.

>> I remember giving up on Perl when I discovered that || and or were both "or" operators but had different precedences.

|| has a higher precedence than or in Ruby as well.

Yeah that was one of my favorite features.
Am I totally misunderstanding you, or are actually saying "||" having higher precedence than "or" is one of your favorite features? Ruby features or Perl features? How does that tangibly effect your day to day life? What is your second favorite feature?
Am I the only one who just completely ignores `and` and `or` in Ruby in favor of `&&` and `||`? The boolean keywords do look nicer than the operators, but given that there are some contexts where you can only use the operators, I just don't bother using the keywords at all
No:

    > rubocop -D foo.rb 
    Inspecting 1 file
    C
    
    Offenses:
    
    foo.rb:1:3: C: Style/AndOr: Use || instead of or.
    a or b
      ^^
    
    1 file inspected, 1 offense detected
perl's rules are very very consistent and logical. (especially compared to PHP, and much more logical than e.g. javascript) They don't always look nice when applied to contemporary problems, but for me it grew in the language feeling, when I could understand what perl does in particular case without looking into it's documentation.

But ruby was a quite a happy move for me back then in 2006, language was underperforming, features were lacking, nowhere anything like CPAN, but I could express logic much closer to how I think about problems, without additional layer of "thought translation".

The real WTF, in any language, is relying on precedence, rather than just using parens.

I've seen some expensive boo-boos due to operator precedence mistakes (e.g. - in C)

That said, there are a lot of special variables that can be tedious to figure out (e.g. - $" vs $;), if somebody uses the less frequently used ones, rather than the long-form names.

    man perlvar
was always pretty easy to search & explained the real purpose of whatever goofy line noise people would use
Yep. That's where I found $" and the other one, whatever it was :-)

I can remember $_, $? and $!, but that's about it. And I like Perl.

The only ones like that which exist in Perl 6 are $_ @_ %_ $! $/

The rest were either just abandoned or given names such as $GROUP or $PROGRAM-NAME

$/ isn't the same as it was in Perl 5 instead it is for storing the result of successful matches. ( you can also assign to it )

$0, $1, $2 is short for $/[0], $/[1], $/[2] $<abc> is short for $/{'abc'} which can be spelled as $/<abc>

>> operator precedence mistakes (e.g. - in C)

Many years ago, I had a bookmark in my C manual (Harbinson Steele) for the operator precedence page.

After a while I removed that bookmark. I decided that if I needed to look at that list, I should use parentheses. :-)

I could just drop my K&R C manual down on the spine, and it would always open up to the operator precedence page. No bookmark was necessary because I always had to open it to that page so often.
That's an important page - for reading other people's misguided cleverness.
I was trying to help with an algorithm used in some of our Perl code recently, writing some tests I'd used \A and \Z in a regex. My Perl co-worker told me it should be \z, I asked why and he said:

> who knows :|

> It Just Is.

> remember, perl is a memory competition

There is a LOT to remember about how Perl works.

Uh..?

1. PCRE copies the Perl regex syntax almost completely (except some much newer cases than \A and \Z). See e.g. http://www.rexegg.com/regex-quickstart.html for \A, \Z, \z

2. If you check http://perldoc.perl.org/perlre.html then:

   \a          alarm (bell)
   \A          Match only at beginning of string, as PCRE.
   \z \Z       Same as PCRE. (But \z is not in Regexps for Python/JS.)
Edit: You might want to note that the regexps are redone quite extensively in Perl 6 and to a large part replaced with grammar for those use cases.
To be fair it wasn't _just_ that particular thing, that's just the part I remember. There were other things that every time I have to go back to the docs for.

It _is_ a memory competition though. In the various languages I've learned, Perl feels like it has the most to remember about how things work or interact (ymmv of course, I'm speaking of my experience here).

I have to agree with that, it could maybe take an extra work week in the beginning, to get beyond baby language. (But it wasn't as bad as C++ was for me. :-) )

Expressive is the good side of this. But you really need to have coding standards in place.

On this subject, to upgrade to Perl 6 will be a bit scary, like driving a much faster car. :-)

The problem there of course (migrating to Perl 6) is also finding matching packages for the _huge_ list we presently use. I can also only imagine the fallout from various issues like places we may have accidentally used the outcome of a dualvar accidentally, or other interesting side-effects of Perl 5.

6 Looks just fine as a language, but it really does feel like a completely new language which means it's less a migration and more a re-write. Which then leads to the question: if we're going to re-write, should it still be Perl?

Come on, don't exaggerate -- dualvar has to be explicitly imported and used. (I've never seen it in the wild, I have no clue what Perl::Critic says? Edit: pbp has nothing to say about them?)

And I'm not touching the "Perl 6" naming discussion.

There is inlining for using Perl 5 libraries in Perl 6, which smoothen the road. But it is a hard start to motivate projects in a new language, which is incrementally better. I would be happy to try.

Dualvars come up naturally. Treat a number as a string (try using Data::Dumper on some scalars) and suddenly your json ends up coming out like: {"something": "12"} rather than {"something": 12}

Just because both slots are filled with the same "value" in perl, doesn't mean it's _not_ a dualvar. It's just a side-effect of the way scalars in Perl work.

Of course. But I get your our point -- this is a corner that might bite you.

It don't happen to me often, but I sprinkle "+ 0" and so on, without thinking about it.

How many times have you actually written a regular expression that matches a bell, versus how many times have you had to explain to people that \a matches a bell while \A matches the beginning of the string (which we know is at least once)?
The discussion was \z contra \Z. I always clear out the new lines and use \Z, so I never bothered.

The ASCII table used to be the alpha and the omega. :-)

That is, it was not so much of unnecessary extra detail when the char codes was inserted into Reg exps. The newfangled Regexps and grammars of Perl 6 cleaned out a lot of lint.

You could probably make an argument for starting to remove, not only add, [more] features when you declare a perl version in a script.

(And personally, I only ever used \n, \r, \t and similar. Everything else is as Cthulhu meant it to be, octal. Regular expressions' problem always was readability, I never used more features than I need and /x is my friend. That said, the "modern" Perl 5 regular expressions are like grammars, really cool.)

(comment deleted)
> I remember giving up on Perl when I discovered that || and or were both "or" operators but had different precedences.

This one is useful. Remember that Perl was created for being a more powerful kind of shell.

Those operators have their precedence set so that you'll use || as a logical operation inside a command, and "or" for control flow between commands. The same is true for && and "and".

For me the essence of it is this:

Perl says "there's more than one way to do it"

Python, by contrast, says "There should be one-- and preferably only one --obvious way to do it."

The practical outcome of the Perl philosophy is that Perl code can be extremely varied to get the same thing done and therefore much harder for different programmers to understand and maintain. Python programmers are more likely to quickly understand the intent of a chunk of code regardless who the author is.

Perl at its worst can also be pretty arcane and I've heard it described as "executable line noise". That doesn't make for maintainability.

This was the best thing about my move from Perl 5ish to Python. My colleagues were a mixed bag. Some knew Perl really well and wrote tight and efficient code. The rather baroque syntax and density of the language made it nigh unreadable but it worked well and they could be relied upon to maintain and refactor it. Most of my co-workers didn't know it that well and wrote crappy code using really horrible conventions that made the project a nightmare to maintain (e.g. a 5000 line script with a 3000 line function called "run", lack of local variables because no one properly understood scoping etc.). It was all I could do to keep my parts of the code clean.

I moved to Python for a later project (a custom CI system) and while there were people of varying skill working on it, the code looked the same because of the "only one way to do it" philosophy. Similar formatting, same idioms, readable code etc. This alone justified moving to Python for me. I could fix a problem in about a tenth of the time I needed to fix a similar bug in the perl codebase.

A huge part of this is due to the bad coding practices and relative inexperience of the programmers on the perl project. However, my feeling is that, perl is forgiving when it comes to style. It allows a skilled used to create really beautiful programs but pays the price by allowing terrible programs by bad programmers to run sufficiently well. We compared it to English. Very flexible, very forgiving when it comes to grammar and syntax if your intention is just to convey meaning.

Aside: what stops chumps from making 3000 line Python "run" functions?

(as far as I know, Python doesn't give you an error message when your function gets up to 66 lines, or whatever, long)

Nothing at all.

But, in my experience, because of the limitations on how flexible the language is, a 3000 line python function which is edited by multiple people is usually more readable than a 3000 line perl one.

Semantic whitespace makes it increasingly unwieldy to write huge python functions - you need to see where you're unindenting to, you can't just match parent.
Code review or linters. There's a few linters out there, and they're widely known in the community with loads of documentation/examples. I believe there's Perl::Critic, but I've never seen it used on the few Perl projects I've worked on.

(As an aside, you can make it more horrible because you don't even need a "run" function - just stuff it into the *.py file and it'll get executed :) )

Whatever reason it is, people don't do that often. They also don't write those often in Ruby, Java, C, and many other languages.

Maybe a better question is: what makes 3000 lines single-function code so prevalent in Perl?

There's something to say about Perl 5 making function arguments difficult. But I don't think it ends there, because other languages attract the same kind of code.

Luck of the draw. I have not seen the huge Perl funcs, only a few times in C (literally thousands of lines). But that's just the crowd I happen to have worked with.

YMMV, as they say.

I guess another way of seeing that would be "fewer chumps use Python" :-)
I think this is one case where humility goes wrong. The Perl philosophy is to enable the end user ( the programmer ) to find his own way to solve problems. This has some advantages, like being able to pick up programming on one's own time. If you are self-taught, more often than not you will stumble upon some non-obvious way to do something. Perl enables you to get some task done. This gives you that positive feedback early on to encourage you to keep going.

This attitude is not very good in corporate environments where all code produced must be uniform so that new people can come and go and the software keeps churning out money.

Contrast this to Python which is a much more enterprise-y language, which is the reason for its success.

> Python, by contrast, says "There should be one-- and preferably only one --obvious way to do it."

you mean, like string interpolation? :)

I don't know if there are any wide polls available about this, but from my experience:

- Most perl developers moved on long ago. My last 3 bosses were all "perl" people who switched to Ruby as their primary language around 2010.

- No strong argument that perl 6 is "best-in-class" for any particular type of problem. This is often what brings interest in new languages (Go, Elixir, and Rust for example, all have this).

Unicode handling? Perl 6 seems to be the only language I've seen that truly grapples with the complexity of Unicode -- at least when it comes to combining characters and normal forms. Seems other languages generally just assume that one code point is one "character".
So how many large "Unicode handling" applications have you seen recently?

For most people the Unicode handling isn't the main problem they're solving, and most languages are more or less good enough now.

It's more than that.

Yes, every other language has flaws on Unicode handling. But those flaws persist exactly because they are not important.

It's been I long time I don't write a "Unicode handling" application, yet the only environment where I ever got problems with it on the last decade was .Net. And it was a very small problem, worked around in less time than I've lost on this HN page.

Swift supposedly also gets deep into the weeds with Unicode.
I love perl 5 and have been using perl since 1997. I haven't touched perl 6 yet simply because the whole mess is still too confusing. It's not obvious what I should download and the frequent release announcements just confuse the issue further. If I want perl6 why am I downloading rakudo star? What the heck is a moar vm and why do I care? Why is the download page telling me it supports "Christmas Perl 6 (6.c language version)?" What is 6.c? Are there multiple versions of perl 6 that I have to worry about? Why does every release announcement say something like this:

"Please note: This announcement is not for the Rakudo Star distribution[^2] --- it’s announcing a new release of the compiler only. For the latest Rakudo Star release, see <http://rakudo.org/downloads/star/>."

Perl 5 is much more straightforward. Their download link sends me to a page where I click my platform and then there's a link to "download latest stable version." Why can't I just download the latest stable version of perl6?

I know I can spend a couple of hours learning more about it but perl 5 more than meets my needs and I'm comfortable with it.

Reading up on it now, Perl 6 is a specification and Rakudo is an implementation. If you want to write Perl 6-compliant code, you can use Rakudo. "There are others...", but it seems silly to me...

As an outsider, my 2c is "abandon 'perl 6', too much baggage for reuptake, and go with Rakudo, which is a more modern name". People smarter than me decided on this rakudo/perl 6 nomenclature split, but it just feels like an own-goal to me.

https://en.wikipedia.org/wiki/Rakudo_Perl_6

I agree that the packaging of Perl 6 needs to be improved, particularly for Windows. It's easy in Linux and Mac.

Languages are a specification and implementation. Perl's been implemented in Rakudo, which runs on MoarVM and the JVM. It's handy being able to run on multiple VMs so that you can take advantage of their strengths, and in particular, places that deploy the JVM for Java will be simpler to integrate with, and apparently you can do stuff across with Java libraries even, though I haven't played with that at all myself.

http://rakudo.org/how-to-get-rakudo/#Installing-Rakudo-Star-... that's how I get it. Rakudo::Star is just a bundle of Rakudo with a bunch of commonly used modules which can be handy to have already installed.

Right now you get your choice of MoarVM or JVM to use as the tie into your OS, and MoarVM gets selected by default. It's started showing up in Linux distributions now too.

I already spent the hours, so here's a short summary: * Perl 6 is a specification in the form of a test suite. By metonymy, the language it specifies and any implementation that passes the test suite are also called Perl 6. * Perl 6.c is the first stable release of the spec. Later versions will advance through the alphabet: 6.d, 6.e, etc. (6.a and 6.b were release candidates.) * 'Christmas' is the human-friendly name of 6.c. 6.d will be named 'Diwali', and further versions are expected to carry on with names of holidays and celebrations. * Rakudo is the flagship implementation of Perl 6.c. It has monthly releases. For the next few years, I would not expect a feature to be released in a Perl 6 spec until it has been implemented and tested in Rakudo. * Rakudo Star is a distribution that bundles Rakudo and a library. It has monthly releases close on the heels of Rakudo. * MoarVM is one of the runtimes that Rakudo can use. It is custom-built for Rakudo, is developed in the Rakudo project, and is installed whenever you install Rakudo. Rakudo can also run on the Java Virtual Machine. A port to the V8 Javascript engine is underway. * Not Quite Perl 6, or NQP, is a language you probably don't need to know, but which you might hear about. It is approximately a subset of Perl 6 -- the features that are useful for writing compilers and not too tricky to implement. Where Rakudo is not written in Perl 6, it is written in NQP. This way, most bug fixes, optimizations, and new features can be implemented only once, not once for each runtime, and porting Rakudo to a new runtime mostly consists of porting NQP and then bootstrapping.

But yeah, I'm still a lot more comfortable in Perl 5 too.

I'm a (very happy) Perl (5) dev and although I've attended lots of Perl 6 cool presentations, I haven't took the time to learn it yet. My reasons are related to the fact that there are not that many commercial opportunities with it just yet. That is a thing which I expect to change in a relatively short time. I've already seen a few job posts looking for Perl 6 developers, which, given the language is declared 'production ready' for less than a year is a pretty amazing stuff.

Also, there aren't hat many libraries in its ecosystem yet, a thing which can be a plus for devs who want to create a name for themselves in the open source world by implementing/translating libraries with a large user base potential.

ask the parrot.
yes? I haven't published the post-mortem on purpose. It would not look good, and has too many references to still existing problems. sorry
The thing to remember with these questions is that popularity is largely a matter of social dynamics—not the language's intrinsic qualities. I mean, sure, qualities matter to a point, but that point is pretty low: it just has to work well enough. Past that, it's mostly a matter of spreading through social networks, perhaps helped on by marketing.

So when you look at a language and ask why it isn't popular, the answer is probably not that it's bad or that it has terrible features or that it's missing things every other language has.

Instead, the relevant answer is some combination of timing, marketing and luck—and Perl 6 definitely flubbed the first two!

It's been, what, two decades since Perl 5 first came out? In that time, trends have changed, people's preferences have shifted (and ossified) and even the role of a scripting language is different. And Perl 6 is not making any of that up on marketing, niftly logo notwithstanding: the Perl brand has been pretty well tarnished over the past years which makes these the absolutely wrong coattails to try sliding in what is supposed to be a brand new language.

None of this, by the way, shows that Perl 6 is a bad language. That's a different discussion entirely—a discussion in which popularity plays a small role at best.

But it is to say that I'm not all that surprised Perl 6 hasn't gotten anywhere.

I agree. Until version 5, Perl has always been considered (rightly or wrongly) a "write only" language awful to maintain and good for awk-like processing or the cgi-bin, and nothing has come out that has changed that perception.

They should drop the name Perl altogether and go for Rakudo IMHO

> They should drop the name Perl altogether and go for Rakudo IMHO

That would be a great idea. Inside the Perl community, everybody is already invested in Perl 5, and Perl 6 is just too different. Outside the Perl community, nobody would want to be found dead with anything called Perl. If Perl 6 is sufficiently better and sufficiently different, releasing under a new name would make a lot of sense.

"a "write only" language"

A cousin of that problem is it doesn't matter how many years ago "Modern Perl" was written, today MySQL still doesn't support transactions.

Not a non-sequitur, in that to this day you'll still run into people swearing mysql doesn't support transactions because last time they looked into it in '94 it WAS true, mysql didn't add transaction support until the late 90s IIRC. Likewise its a law that all Perl discussions ignore everything that's happened in Perl development in the last 20 years. If no one has written code like that since '96 it just doesn't matter to the discussion.

I actually started drifting away from Perl not that long after it became object oriented, it kind of felt like a bad fit, it lost its "perlness". I assumed that even if it had evolved it would be further along the same path so I wasn't interested.

But more importantly, NOBODY I know and rate has come to me and told me "You know what? Perl has moved on, it's actually become a wicked language, you should give it a shot". Whereas that has happened to other languages that I had given up on (ActionScript, JS, PHP) and I had no problem going back to them.

As for MySQL, seriously? Are there people who think that in 2016? I find it hard to believe. One thing is a programming language, but for a RDBMS it's just a matter of time before all the feature developer wants get added. With MySQL it's just a matter of "so what's version is it now, have they added them yet?"

From my point of view, you seem to have a perfectly correct assessment of it.

Yet, as a previous Perl 5 programmer that abandoned it when better languages got powerful enough... How can Perl ever fix it's image in my head, so I'd take a deeper look at it and evaluate this new language?

I don't know the answer here. But there are a few things I know. What normally makes me look at languages is a combination of:

- Competent people recommending it. (This one is keeping open to learning Perl, but it's still not recommended enough for me to stop and learn it.)

- Unique new features. (Stuff that are in no other language. I don't see many for Perl)

- Community and ecosystems. (Those will drag me into a language, instead of leading, but they do make me look. Again, Perl has nothing here.)

So, Perl 6 has a bit of one of those, and it may be unable to ever get anything more. If for not other reason, because of bad standing image that won't attract many competent people for recommending it. I'm not convinced it will ever get anywhere, whatever is the actual language quality.

Those "competent people" need to see a value in the language, but they don't, that's why they don't recommend it enough.
Yep. It's entirely possible that Perl 6 is an amazing language that will make me incredibly productive, yet I'll never think it's convincing enough to learn because I'll look over other people thinking like me, and won't see they trying.

It's also perfectly possible that it does not add much value and I shouldn't mind learning it.

And there's a lot of effort required to discover what of those is true.

It took 15 years for a "production ready" Perl 6 interpreter to be finished, at which point Python, Ruby, Lua, and even Node.js had more than enough traction to not leave much room for Perl 6 in the market.

Six years ago I got into a flamewar on Hacker News about Perl 6 not being done yet and had to clarify to an angry Perl hacker that by "not being done", I meant, "as of 2010 we only have an incomplete implementation of a draft specification of the language".

> It took 15 years for a "production ready" Perl 6 interpreter to be finished

More like it took 14 years for the first attempt (Parrot) to be abandoned, and about a year for the second attempt (MoarVM) to be somewhat usable, but still not really production ready.

To the OP it's quite simple - Perl 6 isn't done yet, it's still in development.

Any idea how long ECMAScript 6 has been in development? Well, it used to be called ECMAScript 4 and it was started in 1999, a whole year before Perl 6.

People use this as a negative all the time, or as "the reason" it hasn't picked up, but the rules of software dev are simple: ship fast, ship efficient, ship cheap -- pick two. It's FLOSS, so one choice is already made: ship cheap. Glad that Perl 6 went with efficiency over getting to market quickly.

Spend some time with the language and then go find me anything that comes close to covering the same number of programming paradigms, let alone the coverage of the standard library, then tell me that it missed its shipping target.

tl;dr -- 15 years after it started and it still manages to be more featureful than anything else out there.

Perl 6 was too little, too late. It was hyped for a long time and delayed for a long time. During that time, everybody who was impatient and not forced to use Perl ended up moving to the new hotness languages like Python and Ruby.

Ruby is probably the main reason Perl lost so much market share, since it took a lot of the underlying philosophies from Perl and turned it into a beautiful, easy-to-read language.

So is Python.
Well, if you wanted "Perl, only better", you went with Ruby. Python is good, but it has a different flavor.
You read this part:

> turned it into a beautiful, easy-to-read language.

and got annoyed (presumably?) that Python wasn't mentioned, but you completely ignored:

> it took a lot of the underlying philosophies from Perl

Ruby is a lot closer to Perl than Python is, which is what the draw would be for people migrating away from Perl.

Thanks, this is precisely what I intended.
I started using Perl in the early 90s and Ruby in 2005. I keep reading that Ruby was inspired by Perl and even Matz says that, so it's true. However the Perlish sugar on Ruby is so thin that I'm not really sure I see it. The regexp syntax? Yes, it's the most distinctive feature of Perl to me together with the while(<>) loop, but that's very minor. The influence of Smalltalk is much more marked but in general Ruby is its own language with its own flavor, much easier to read and write than any other language I used.

I kept writing quick throw away text processing scripts in Perl until a few years ago, when I started to forget how to write the basic constructs due to lack of use. I'm writing them in Ruby now but I think that Perl was better suited to the task. At least I can read the Ruby ones years later.

But am I giving a try to Perl 6? No, I don't even know how it looks like. What problem would be solving for me? Who else is using it and for what? Can I go to a customer and say let's use Perl 6 for this project, don't worry you'll find many other developers to carry on development if I won't be available anymore? Not yet.

I was a Perl dev in the 90s, have since used PHP, Ruby, node and Python and I must agree that there is something "perl like" in Ruby. I don't know what it is, maybe it's the feeling of naturalness when writing, maybe the fact that "there is more than one way of doing it", but despite the languages between quite different Ruby is the closest to Perl that I know. Except that I can actually read it quite well even months after I have written something.
Because pearl is not supported to make sense
Actually other languages user got some awesome web frameworks: PHP got Laravel and Symfony, Ruby got Rails and Python got Django and Flask. On other hand Perl community kept waiting for v6 for long time and in due course users shifted to other languages due to reasons mentioned above.
"why isn't it (Perl6) the poster child of the scripting languages yet?"

In the Perl6 community there is no equivalent of "The Python Tutorial" [0] or the "Python X.Y.Z documentation". From Python 1.X onwards, if you wanted to learn Python from scratch, this is where you started. Where is this in Perl6 version that assumes you start from scratch without having to learn the baggage of PerlN? [3]

[0] If I'm wrong loot at this: https://docs.python.org/3/tutorial/index.html and point me to the Perl6 equiv.

[1] https://docs.python.org/3/

[2] where N < 5.X

(comment deleted)
Well, there is this:

https://docs.perl6.org/language/rb-nutshell

An overview of the differences between Ruby and Perl6, which doesn't seem to assume Perl5 knowledge, but beyond that the docs are a bit lacking on the tutorial front. (and personally they seem a bit lacking on the polish side of things too. They seem like they could benefit from a some better organization.)

Personally, I don't want to see the Ruby examples or think about them or compare them, I'd prefer just the idiomatic Perl 6.C tutorial (weird name, isn't it?) to see what it brings as an advantage.
I'm not disagreeing that there should be a "Perl6 from scratch" type tutorial instead of "Hey, programmer coming from X language"-type tutorial.
I'm utterly confused by your use of footnotes. You seem to have used two footnotes in your text (with the second one bizarrely being "3"), and then put three citations at the bottom, only one having a corresponding number in the text
Speculation:

1) The field is pretty crowded. There's a lot of languages competing for attention. It takes time to learn. Which ones should I spend time on?

2) Momentum. Scripty siblings Python & Ruby & JS & even PHP have active communities with a lot going for them.

3) Baggage. Some of the conventional wisdom about Perl 5 is pretty iffy, but it's well established conventional wisdom, dammit! In fact, you'll almost certainly see it recapitulated in this thread. Most arguments to the contrary seem to be slow to make a real dent in what Everybody Knows™ about Perl. The fact that Perl 6 is a different language will probably be equally slow. People will repeat the comforting mantra that Ruby is the new Perl. Order will be reinforced.

4) Blub-ish paradoxes. Perl 6 is doing some weird and different stuff. Is it hyper-useful weird and different stuff? Will I know until I learn to use it?

5) Not a big win in terms of market value yet.

Social momentum is also a thing; which mostly expands on point 5, but also points 1 and 2.

IF you are going to find Perl installed on some system, it's more likely to be Perl 5 than anything newer.

You are very likely to find SOME version of Python, or Python compatible thing on most Linux distributions. Anything really old you're safe targeting Python 2.6 compat, maybe 2.7 compat. Anything relatively recent you will probably find a 'decent' version of Python 3.

> even PHP have active communities

And this is surprising?

Ruby.

(mentioned elsewhere, but let's distill it down)

Perl idioms translate to Ruby quite well, but with better object syntax, and a more unified runtime library to deal with code blocks or other higher order function type usages.
That said, Perl 5 can be quite a bit faster (to run) than Ruby. But Ruby is speeding up, and is generally easier to read.
Perl 5 is better than Perl 6, so why would I change?
You'll have to elaborate, just saying "this is better" is useless.
Perl 5 is a more expressive and logically consistent language than Perl 6. If I want something Perlish, I'm using Perl 5 no matter what.
This is completely wrong. Perl 6 is a much more expressive and logically consistent language than Perl 5.

On the other hand Perl 5 is faster for normal usage, and has mature library support, while perl6 has to catchup a lot. Perl 5 is only slower with their not-existing/silly object systems (Moose), there Perl 6 is much better.

Many perl5 devs just don't want to learn a new language yet.

I'll agree with the rest, but not about Moose. It is not Perl 6, but is still probably better than most other scripting language OO systems.
Not for performance which is what I think rurban was getting at.
Performance and syntax. features are almost OK, despite the type system.

Syntax: It explicitly deviates from perl6 and could have looked much cleaner.

The short answer boils down to, "It might be dangerous, you go first." Moving to a brand new language (which is what Perl 6 is, despite its long incubation and its vestigal name) has real costs - the libraries you have come to depend on aren't there, new libraries to replace them aren't all written yet, some might never be, the ones that exist aren't as feature-complete and battle-tested. For a new language to get adoption, someone needs to go in there and start doing those things, and deliver a value proposition. If a language wants to get followers, at least in the beginning it's better to have one "does it better than anyone else" area than to be a jack of all trades, too.
>> the libraries you have come to depend on aren't there

See e.g. Inline::Perl5 and Inline::Python (don't know how mature that is).

>> For a new language to get adoption

I'm not really that knowledgeable right now, but how many weeks have Perl 6 (the language, not the libraries) had an implementation ready for production? :-)

Edit: Thanks, Ulti. Close to 50 weeks. Good work of the implementors. :-)

Since Christmas 2015 was the "production" release of the language specification. Hence the 6.C version number, the C stands for Christmas. Rakudo around about now implements that feature set in a stable way. The last year has mostly been optimisation work in the runtime and VM. The whole thing is about as stable and production worth as Swift. That is to say features do still change, but not the ones already specced as 6.C
Perl 6 is the poster child for "second system effect".

The python community have just about managed to achieve a backwards-incompatible change, which was fairly minor and developed in a reasonable timeframe to address certain specific issues.

The Perl community were made extravagant promises 15 years ago. People started holding their breath for 6. By now, everyone has given up and the delay has asphyxiated the community. Not to mention that the Perl niche is much more crowded and still has a working, complete Perl5 in it.

I think the Perl community had a lot to do with Perl falling off in popularity. The standard reply to questions posted the "Beginners Perl" mailing list was "RTFM dumbass".

The "Learning Perl" book sucked hugely. CPAN is pretty cool but too many modules have poor documentation and almost no example code.

Web app frameworks got convoluted and didn't make things easier and tended to lock you into doing things their way.

Despite that, I still liked perl because it did let me do things my way. I waited and waited for Perl 6, and then quit caring.

This year I finally rewrote a perl/cgi web app in Javascript. What little server side I code I needed I used Perl 5 but there was very little.

"The "Learning Perl" book sucked hugely."

Wow. It's always interesting to see how people can have such different takes on things. Perhaps it was the time in my programming career that I read it, but I remember being impressed with some of the programming practices it instilled. Never used Perl a whole lot, but the way Schwartz presented programming, not just Perl, I found very useful.

Definitely. The Perl books (Learning, Programming, and Cookbook) were all, for me, excellent.

c.l.p.m. on the other hand, was a hatefest dominated by people who seemed to resent the peasants daring to touch "their" precious programming language.

That's exactly what I ran into. I needed to learn how to write cgi scripts and I didn't know much about coding at all. Almost nothing.

I suppose we came in hordes and stormed their gates but all they really had to do was provide us with a space and that didn't happen.

Ironically, they did the same thing with the Raspberry Pi foundation reached out to them. No one responded.

I even went back to the "Perl Beginner's" mailing list and told them about the RPi Foundation and that Perl was being reviewed for the languages they would support with their Edu projects. No one responded.

At that point I don't think Larry Wall was involved much with Perl 5. And I know a few years before that he was frustrated with with lack of a cohesive path for Perl 6, and that not long ago he talked about how the Perl 6 Community had to reach out to educators and get involved with programs for kids.

The Python community did respond To the RPi Foundation when they reached out, and in a big way too. That's paid off big for them and the Foundation. Kids are growing up with Python now and will know it well and use it.

This evolution of languages has been interesting to observe.

> I think the Perl community had a lot to do with Perl falling off in popularity. The standard reply to questions posted the "Beginners Perl" mailing list was "RTFM dumbass".

Perl is the only language where devs see unreadability as a badge of coolness, indeed there was even an Obfuscated Perl Contest: https://en.wikipedia.org/wiki/Obfuscated_Perl_Contest

(There are golfing competitions in other languages, for example js1k, but the focus there is download size, the fact the code is obfuscated is a side effect rather than the point)

You're confusing Perl 5 and Perl 6. The two are different languages with vastly different communities.
There is very much a relation to the two and why Perl 6 has not garnered the enthusiastic community Perl 4 and 5 had 10-15 years ago.

When I was still active on their mailing list there was a lot of excitement around Perl 6. By the time I left most others had already been long gone. They'd gotten smacked too many times.

None of that is Larry Wall's fault. He's been herding cats since he started these projects. I think Larry is great.

This was not my experience with Perl, at all. Perl was the first really welcoming programming community I found on the web. Not the only one, I'm sure, but it stood out in remarkable ways.

Perl Monks was super helpful to beginners and intermediate Perl programmers; unmatched then or now, I think; maybe the Go community is a modern parellel, as it has a very beginner-friendly culture, IME. IRC was always great (though I must concede it is somewhat cranky these day...not unhelpful, but not always as gentle about helping as it once was). I don't know which "Beginners Perl" mailing list you're referring to, but the ones I used to follow when I was learning (a couple of decades ago) were very helpful.

I'm sure there are cranky old Perlmongers in this world. And, it's been so long since I was paying close attention to beginner resources that I may have missed a shift in tone in that time. But, Perl, to me, was a great learning language.

And, I liked Learning Perl, though I think the Camel is a better book, and if you're not a true programming beginner, Programming Perl is the better book to read. Learning Perl teaches Perl and programming at the same time, and may not be the best way to learn either; though, again, I thought it was quite good, and was very empowering for me.

"Learning Perl teaches Perl and programming at the same time, and may not be the best way to learn either;"

That's a great point. I've never thought of it like that but that is no doubt the reason why I strained with "Learning Perl".

Thanks for pointing that out!

That mailing list acquired moderators who'd smack people for doing that a few years back.

We've taken something of a chainsaw to the 'RTFM dumbass' side of the community over the past half-decade or so - you can even discuss perl on irc.perl.org #perl these days.

I'm really glad to hear this. It's probably been just a year or two more than that since I signed off on those I subscribed to.

That makes me want to join again!

I just started playing with Perl6 a couple weeks ago, and I am completely loving it now. It's the strangest process to get used to. I haven't had this much fun programming in a long time. Some frustration every one in a while until I can wrap my head around some new concept, but that's to me what this language is all about. SO much conceptual stuff in it. Very, very rich.

I've been converting some old stuff to it to learn it, and it crazy how much more compact things can become. Working with grammars has been amazing. And I'm just now getting hit over the head with how flexible class roles with parameters can be to consolidate methods that do similar, but slightly different things.

I haven't even started into the concurrency bits yet... something about "promises" and "supplies". But I'm actually looking forward to it at this point. And that's really a surprising thing to me ;)

Anyway, my 2 cents on it at least. I'm not sure it matters if Perl is ever a poster child for anything. I think it kinda just doesn't matter.

> I've been converting some old stuff to it to learn it, and it crazy how much more compact things can become

Oh gosh that sounds scary. A lack of compactness was never Perl's problem, quite the opposite in fact.

No one talking about Perl 6 compactness means golfed code! Just naturally translating over say a Java program with the OO design intact will be hugely compact. In a way that means the code is written at a succinct conceptual and declarative level. Perl 6 is incredibly declarative, you say what you want, not how to get there. The core features cover nearly all of what you want out of the box too.
Yeah, I didn't mean compact as in, oh let's see how few letters we can use. I meant compact in the way you can organize even VERY complex stuff, especially using their concept of grammars. You can write whole languages and protocols pretty neatly with those.

Or like type. I've been loving their type system. You can use Perl as a heavily typed and enforced language, or not at all. And it's really easy to make up your own types, which you can also easily use for handling arbitrary constraints you might need.

  subset Even of Int where * mod 2 == 0;
  (1..1000).map: { when .is-prime { .say }
                   when Even      { say 'EVEN Num' }
                   default        { say 'no'}
                 }
Like there I just made up an new type called "Even", and used it when printing out stuff about numbers between 1 and 1000. But the really cool thing is you can use the exact sort of stuff for all kinds of variable types and even structures. It's just amazingly weird and open wonderful. I admit I've really fallen for it. ;)
There is an operator to check if one number is divisible by another.

    subset Even of Int where * %% 2;
You also don't have to write the where clause as a lambda.

    subset Even of Int Where $_ %% 2;
woot! :) still learning stuff ;) - though I'll use the first.
I used to love Perl 5 in my free time for personal projects around 2009-2010, frameworks like Dancer or Mojolicious were getting traction and it was a lot of fun; but when I wanted to change my career and move away from what I was doing at the time (PHP mostly), I finally decided to go with Python and that meant no time for Perl (and no Perl 6).

Basically at that point there were less Perl jobs and the language had (has?) bad reputation on being too easy to write hard to maintain code that I thought the language wasn't worth the peer pressure when Python or Ruby were nice languages too with open and welcoming communities behind them.

Perl 6 seems to add to that bad reputation unfortunately, adding extra complexity.

This is just an anecdote, but reading the comments seems like other people had a similar experience.

Perl 6 adds features, and hides complexity.

You are right that Perl 6 is more complex, but you will never see the majority of it until you decide you want to dig deeper.

If you write equivalent idiomatic code in both versions of Perl, the Perl 6 code will likely be less complex, shorter, more declarative, and easier to read.

The reason why developers don't migrate from other languages is plainly because Perl 6 doesn't offer enough unique things that people actually care about to migrate.

The reason why existing Perl 5 developers don't migrate is because they don't need and/or want to. The benefit would mostly be derived from writing new code, but most Perl 5 code in the wild are legacy systems and complex admin shell scripts. Those are exactly the kind of thing that you don't want to rewrite in the latest-and-greatest; the potential to introduce subtle bugs by upgrading is more important than the benefit of being able to use new constructs in those parts that you need to improve. And the vast majority of new code is also admin shell scripts written by experienced greybeards, who really don't like their cheese moved, and so will stick to what they're used to for as long as they can.

> The reason why existing Perl 5 developers don't migrate is because they don't need and/or want to.

Exactly. I continue to use Perl (5) for text munging, data cleaning, and gluing together programs written in other languages. It was designed for these tasks, I still need to do them, and nothing has come along since that is substantially better. When I need to do other things, I use other languages, and so far I haven't seen that Perl 6 has a "killer app."

> Why hasn't Perl 6 taken off yet?

i think the story it similar to Visual Basic 6 and VB .NET: the change between perl 5 and perl 6 is really big, perl 6 is a new language - not just a change of version, people who are comfortable with perl 5 have little incentive to learn it all again (or they have switched to python)