Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Why hasn't Perl 6 taken off yet?
178 points by totalperspectiv on Nov 7, 2016 | hide | past | favorite | 271 comments
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?




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.


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


There's a .msi installer for Windows here http://perl6.org/downloads/


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


Perl is a hacker's language (not unlike e.g. Common Lisp). It brings maximum power to the fingertips of an individual. When you are alone, developing with Perl is a blissful joy of pure godlike power over your domain. Perl6 amplifies this feeling to eleven and beyond: there's almost nothing you couldn't do with a few lines of code.

The popularity of Perl coincides with the golden age of personal computing (and hackers culture). PCs got powerful enough that individuals could do the same things that were only available to big corporations and sometimes universities. Perl helped to harness this power, becoming the proverbial "Internet duct tape" to connect things (in the world of UNIX with emphasis on text protocols, the most powerful language for text processing won).

When lone hackers were no longer enough to satisfy the demand, the world had moved on to create _software industry_, and Perl's advantages (all power to the individual) started to be harmful. Different individuals have different preferences, and when you have to work in the team, reconciling your differences with your colleagues creates way too much friction. To facilitate teamwork, more uniform languages were deemed necessary, where understanding other people's code became a priority. Even open source software moves faster when anybody can read and participate in your code without fighting over style. This attitude was firstly exemplified with Java; now, we have Golang, which is a king of all languages optimized for team development. To facilitate this, the expression power available for individual developers had to be cut short.

As a consultant supporting my own code, I still use Perl, and if you are working alone, it's your fine bet. But as 99.9% of people work in teams, Perl6 is not the best choice for them.


"But as 99.9% of people work in teams"

That number is far too high, given the rate at which I run into single points of failure aka individuals working alone. They might be on a product team or whatever-team but they're the only software dev on the project or only dev who understands the problem space, the one and only dev who can fix that bug.

Its not entirely wrong in that 99.9% of software experiences more than one author over its useful lifetime and idioms and peculiarities of individual developers will make transition between single maintainers more exciting.

It is instructive that in general business communication if that theory were correct then English would have long been replaced by Lojban, but there hasn't been much success. Perhaps its a non-tech startup business model to increase effectiveness of a business by conducting all internal communication and documentation in Lojban. Maybe there's some kind of tech startup business model in somehow technologically encouraging support of Lojban. It could just be wrong in most scenarios.


It's definitely the case that every time I've worked with a serious Perl programmer I've learned something new about Perl and so have they.


This is a question of coding standards, which is applicable to every language. Some places had strict standards eventually for Perl <= 5 but there was a lot of legacy stuff. But Perl 6 is certainly not Perl 5 :) All languages need some standards imposed on the programmers when you're working in tight teams. Languages that give people a great deal of flexibility and power even moreso. Actually, I'd argue for a collection of local-use libraries... ;)


I agree to a certain degree, but as someone who has been doing JavaScript. It's the same there. It actually seems true for most scripting languages. It even is true for Python.

There are however code linters, formatters, etc. You use those you can do the same in Perl (6).

You need style guides, yes even in Python. In Python there is a bit more community wide agreement though.

And even in other languages you need style guides, but often they are already enforced or strongly encouraged by the IDE you use.

Anyway, when comparing with JavaScript the problem seems to be the same. Lone scripter code is barely readable by others, while in teams style guides are often created and enforced. The same appears to be true for Perl.

I am not using Perl (anymore), but I think the main reason for this argument being mostly used in the context is that Perl has been around for longer, which means you have more code written detached from the community. Also Perl has been used a lot more by people that refer to themselves primarily as sysadmins, rather than programmers.

When comparing programmer code with system administrators code JavaScript, Perl, Ruby and Python are all harder to read and more different from commonly agreed style.

So I agree that your argument is true for why Go or Javan are used and maybe to a small degree to Python, because that seems to be the strictest language, but if you compare it with JavaScript, I think they pretty much even out on weird things they allow and that is frequently done.

I think there are some other reasons for JavaScript being used more. It's not Async IO[1]. One of the reasons is web development. There is just many people who start out their career as what we nowadays consider frontend people and the step simply is smaller, even if they eventually become systems programmers, write drivers and OSs the introduction frequently was through browsers.

Another reason is performance. V8 and Spidermonkey are probably some of the most advanced interpreters out there when it comes to code optimization (other than what Facebook did to PHP). That's if you include the complexity of the language. Of course there are highly optimizing interpreters for languages that are simpler.

Tools, libraries, etc. While Perl 5 is really good there, Perl 6 is not quite there yet. Also there is no commercial company behind it, only a not too big (compared to Mozilla) foundation, which makes it harder to do PR and gain traction.

[1] think about it, libev, which was done done after libevent, and which for a while even was used by node.js, after they created libuv, mostly for better Windows support was done by a Perl guy and is widely used by the Perl community. Also they had callback, future, promise based systems and abstraction layers for quite a while.


Sooner or later if the creation you built has staying power it must be passed on to someone else. Based on what youre saying it seems perl code is a risky thing to inherit


I've got the same sentiment about Node and PHP.

Both are just an eyesore for everybody but the person who wrote it.

Heck, even the very experienced JS/Node developer who works at my place says that they sucks in teams, and I totally agree.

PHP...well, that was designed as a hack job to get a Personal Home Page to work dynamically by a lone dev kid...


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.


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.


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.


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.


Larry has talked of this[1] as Clean Golf:

> one should do token golf, not keystroke golf

> would be a nice cultural hack to start the Clean Golf meme

http://irclog.perlgeek.de/perl6/2014-03-11#i_8417918


My perspective as a Perl5 dev: Perl6 just doesn't interest me.

The two main reasons: (a) It's still not finished, but mostly (b) all I ever see is people in love with how clever they can be with the language.

I don't need to see hyper-clever ways of using built-in lazy memoised lists to generate a Fibonacci sequence in a dozen keystrokes. If I get tempted over to Perl6 (or any other language) it'll be be by examples of how easy it makes the boring, mundane tasks that I actually need a langauge for - things like reading from/writing to files; handling dates/times nicely; etc. etc.

What I like about Perl5 is its "Make the easy things easy and the hard things possible" mantra. The only mantra I hear from Perl6 is "Look how cleverly you can solve this contrived example". That's not something I care about in the slightest when I think about what language to write my next program in.


A) It's released with a frozen spec and a large test suite for compliance (https://github.com/perl6/roast), with a compiler available that supports a module ecosystem with over 700 modules (http://modules.perl6.org). What's a complete state in your mind? If not this.

B) All of the below is core language, not a use or import anywhere required. Error reporting is also handled for you without autodie and friends.

  Reading from a file:

  #Efficiently line by line for STDIN
  for lines() -> $line {
      $line.say;
  }

  #Get everything in RAM right now
  my $string = "filename".IO.slurp;

  #Lazy list will do IO as you request into the list
  my @lines = "filename".IO.lines;

  #Listing of directories if the path is a directory
  my @directories = "coolstuff".IO.dir if "coolstuff".IO.d;

  Playing with dates:

  #Get a DateTime for right now
  my $date = DateTime.now;

  #Does what it says on the tin
  say "Yippee" if $date.later(:5years).is-leap-year;


A) Complete is when the compiler(s) actually implement all of the spec, for starters.

B) Nice examples. Well done. But it's not about whether you can do the simple things. It's more about the impression of the community and where its interest and focus lies.

I'd rather use a language where the mundane day-to-day stuff is the most important consideration. My impression of Perl6, however unfair that may be, is that the day-to-day functionality is the boring necessary evil that must be in there somewhere, but the true focus is the amazing stuff you can do with a language that's simultaneously trying to be a better Perl, and a better Lisp, and a better Erlang, and a better Haskell.

In my mind, Perl6 is a huge lumbering beast that tries to do absolutely everything. I'm sure if I ever feel the need to write a lazy asynchronous parser script, it'll be the first language that leaps to mind. In the meantime, I don't have the time nor the interest to bother.


* A) Complete is when the compiler(s) actually implement all of the spec, for starters.*

The spec was frozen last Christmas, with a corresponding compiler release.


As a beginner who never used Perl5, I found my first bug (missing method https://rt.perl.org/Public/Bug/Display.html?id=128903) within 24 hours. It does seem like there are some relatively raw things left around.

That said, it seems like a really interesting language.


> #Does what it says on the tin > say "Yippee" if $date.later(:5years).is-leap-year;

Is that a Georgian or Benghali or Indian or Buddist Era Thai leap year?

Actually are we talking the Georgian calendar - or the Julian, Revised Julian, Coptic, Ethiopian, Chinese, Hebrew, Islamic, Hindu, Bahai, or Solar Hejri calendar ?


I have to admit the documentation for perl6 is absolutely excellent as the very first English prose line on the very first google result answers your very reasonable first question about a date class.

https://docs.perl6.org/type/Date

"A Date is an immutable object identifying a day in the Gregorian calendar."

I like a language that's not surprising, with easy to find answers. My experience with Perl over the decades is everything about it meets expectations to a spooky extent, which is also nice. The surprise factor for Perl is very low.

It seems to define excellence in programming language documentation. Is there anything better out there?


From https://docs.perl6.org/type/Date:

"A Date is an immutable object identifying a day in the Gregorian calendar."

(It's proleptic.)

The days used in DateTime, which is compatible with the Date class, also identify days in the Gregorian calendar.

(DateTime adopts RFC 3339[1].)

The `is-leap-year` methods for both classes refer to the Gregorian calendar year.

For a civil calendar independent date, use the `daycount` method to return a Modified Julian Day[2].

The `Dateish` role[3] abstracts from any particular civil calendar.

I'm not aware of any routines, built in or in existing Perl 6 modules, for conversion to other calendars.

[1] https://www.ietf.org/rfc/rfc3339.txt

[2] http://tycho.usno.navy.mil/mjd.html

[3] https://docs.perl6.org/type/Dateish


Perl was the poster child of scripting languages. When I started hacking on Perl 4 in the mid-1990s (before there was a Perl 5), it was a miracle language. I was throwing out multi-thousand line C programs wholesale and replacing them with 50 line Perl scripts that worked far better (daemons and Sybase reports, mostly).

Around 2000-2001, I worked on Perl 5 in a close-knit team at a dotcom startup. Even with daily interaction, it was really hard to keep coding standards straight and readability under control. The problem with Perl is that it tends to be a different language for every programmer. Its flexibility leads to arcane code that can only be easily understood by the person who wrote it.

Years later, in different roles, I've worked extensively with both Ruby and Python (I prefer Ruby). I will never, ever, ever go back to Perl for anything more than one line long. I still use Perl for 'perl -e' one-liners in the shell, mostly complex greps. That's it. If I write anything small enough that structure doesn't matter, I use /bin/sh. If I write something large enough that structure matters, I use Ruby.

Why? Because I like to be able to read my code.

Ruby is wonderfully expressive. It can do everything Perl can, and it does it in a much more readable, much more human way.


"The problem with Perl is that it tends to be a different language for every programmer."

Exactly. Larry Wall cited an analogy somewhere: if you want to know where to put walkways on a new campus, wait until pedestrians have worn trails into the grass and pave there. Perl docs repeatedly makes jokes along the lines of, "it does what you want, unless you want consistency. Bottom line, Perl was designed without predictability and consistency in mind. This makes it blazingly fast for development by one person, but the administrative overhead between multiple programmers balloons.

Because of a natural inclination to reduce the number of characters one uses, as you get comfortable with Perl you start taking more and more shortcuts. A singular moment in my long career occurred when I opened some old Perl code after leaving the language for a time. I stared for a long moment, dumbfounded. It was as if an alien had visited my computer and overwritten my code with what Wall has affectionately described as "line noise."

Also, I was awed by the feature set in Perl 6. I don't think any language outside of Lisp, C, and Smalltalk has had such profoundly new ideas. Pronouns in Perl 5 are still unique to my knowledge after 20+ years. Wall is wildly imaginative.

Perl is what made me realize, in the mid-90's, that OO is largely just a marketing term. A sufficiently powerful language provides whatever portions of OO you need a la carte.


I would wade through a mile-wide swamp of pronouns on my hands and knees if I were promised named function arguments upon reaching the other side.


I've got a dozen wildly different ideas of what you mean...


You are speaking of the 22 year old Perl 5. This HN thread is about Perl 6.

Larry Wall (primary author of record for both Perl 5 and Perl 6) noted in an article[1] that:

"Perl 6 is also a completely different language ... [that specifically addresses] readability"

Or, in greater depth:

"Perl 6 is also a completely different language that has been rethought and rebalanced on every level, with much stronger support for both functional and object-oriented programming as well as reactive and concurrent programming.

There is now pervasive concern for composability, evolvability, readability, and maintainability.

We try to "hang everything on the right peg" to allow proper separation of concerns.

While we still believe in providing multiple ways to accomplish something, we now try to encourage one of those ways as an appropriate starting default.

So we think the language scales both down and up to the level of talent of the programmer; the programmer can start out in "baby talk" without getting into too much trouble and then whenever he or she is ready to learn a new concept, the language is ready to support that and to make it easy to refactor the code as the programmer grows in sophistication.

For developers who are already sophisticated, they'll see that most of the problems endemic to the currently available dynamic languages are solved in Perl 6.

We understand lexical and dynamic scoping. We detect most typos at compile time. We don't have a global interpreter lock. We encourage Smalltalk-style trait composition over uncontrolled mixins, multiple inheritance, or monkey patching."

[1] http://www.infoworld.com/article/2882300/perl/perl-creator-l...


Great. So why should I go to Perl 6? What's the compelling use case? Ruby had a compelling use case - Rails. Rails completely reinvented how web applications could be written, and it did so in large part because it relied on the nature of the language (specifically its reliance on duck typing). That's why attempts to mimic Rails in other languages always feel a little clunky.

JavaScript, for all its blecherous losing horror, had a compelling use case - it ran in browsers. Later, Node became a compelling use case, for dealing with both performance issues and package management problems that plagued other systems (including Rails).

Python had multiple compelling use cases. It became very popular in math programming and teaching, for its clarity and consistency.

Perl's compelling use case was with Perl 4, as a general purpose glue scripting language in a Unix world. It solved tremendous problems. Perl 5 didn't have a compelling case, and it grossly exaggerated the already bad problems with complexity and inconsistency. Am I talking about Perl 5? Yes, because for 22 YEARS, we've been saddled with that crap. Two decades of waiting for Perl 6, for Perl to unfuck itself and become something useful for more than one person at a time. That's like, my entire career. Longer than most programmers in this industry have been in the industry. Longer than some of them have been alive. 22 years.

So why, why, why should I switch? What's the promise now? What problem am I having with Ruby that it can solve?


The Perl 6 project started only slightly more than a decade and a half ago.

Ruby's "DSL" ability is what allowed Rails, in Perl 6 everything is a DSL. Even strings are written a customizable DSL. You can turn on and off string features, and add new ones. It goes even deeper than that, you can swap the parser out with a new one mid-parse. One implementing Ruby for example. ( While it is possible to do this today, this isn't specced yet, as the exact way to do this is still in flux to get it to the same quality as the rest of the language ) So in a sense, all programming languages can be thought of as a subset of Perl 6. ( There would be little point in doing this for assembly though, as it will probably have to be emulated in most cases ) This feature is usually only used to slightly alter the existing parser currently.

That isn't even the best part, many features from other high level languages have already been brought together in Perl 6, in a way that makes them seem as if they have always belonged together.

If you asked a random sampling of people about which feature that they like in Perl 6, you will probably get a different one from each.


> So why, why, why should I switch? What's the promise now? What problem am I having with Ruby that it can solve?

All good questions. My personal answers boil down to "no need" (to switch), "see the rest of this thread" (to read what promise Perl 6 might have), and perhaps https://docs.perl6.org/language/rb-nutshell (to read how someone familiar with Ruby explains how to map Ruby knowledge on to Perl 6).


Since programming language is often tied to programming framework, then switching languages means sacrificing frameworks. That's a problem. Admittedly, it's a form of Lava Flow Antipattern, but it's significant. I'm giving up a useful toolset, and I'm giving up accumulated domain knowledge.

So why do it? Mainly, if the framework I'm currently using can't do things I need to do, or if it's incredibly painful to use. To the extent that someone has neither of those problems, a new language is a cure worse than the disease, whatever its benefits.

Look at it this way... imagine there's a rib joint across the street. It may not have the best bbq, but it's there. Do I walk across the street for bbq, or do I drive halfway across town to get slightly better? I'll take what's there, thank you. Now, if I'm a vegan, I'll get up and go somewhere else.


I think that says more about you than everyone else. I would walk halfway across town for slightly better bbq. Ultimately what is there to life than improving the quality of your experience. The issue is what consitutes better BBQ is completely subjective. So we might start from opposite sides of town and try and get to each others nearby BBQ ribs place. That's just human nature. With respect to "frameworks" some of this tends to be kind of centric to how you program. For the last decade most of my work isn't within any framework because its algorithmic with only a need for string IO and some parsers. Perl 6 for that is the framework.


My experience was very similar. I used to write a ton of Perl for system administration, mod_perl web apps, etc. but swore off cold-turkey in the early-to-mid 2000s when I realized that every time I opened a .pl file the first thing I did was run it through perltidy and then spend a bit of time figuring out the author's personal conventions.

My rule is pretty similar now: Perl or Bash is fine for one-liners or a script which fits in an 80x25 window and doesn't use non-scalar data structures but anything longer or which has much expectation of maintenance is written in something like Python where the culture and tooling favor readability.


Because we aim for organic growth: not too fast and not too slow. Based on stats, our userbase doubled since last year; and that's with an yet-to-be-optimized compiler that's an order of magnitude slower than competitors and by some people's standard not yet production ready.

It'll also take a bit for people who loudly push 25-year-old languages like Python and Ruby like holy grail to... die off (no, I don't want them to convert). Perl 6 is a next generation language over them and it'll take next generation of programmers to make use of the new programming paradigms.

What you're probably asking is why hasn't Perl 6 went viral like Swift, Rust, or Go? Well, we don't have a multi-million (or -billion) company backing us, so fanboys and people who are after the latest shiny things aren't flocking to us like to manure. But look around this site: those langs get as much nonsensical comments from the Python-Ruby zealots who are too scared of new languages :)

Perl 6's first production release was less than a year ago. It's a bit unrealistic to expect it to be a "poster child" of anything so fast. If you're old enough to remember, no one gave a shit about Python until at least second version.

Don't worry about popularity. Learn many languages and use what you like using.


Because I don't know much about perl, and not much more about Python, and much much less about ruby, would you kindly give a couple of examples of :

> It'll also take a bit for people who loudly push 25-year-old languages like Python and Ruby like holy grail to... die off (no, I don't want them to convert). Perl 6 is a next generation language over them and it'll take next generation of programmers to make use of the new programming paradigms.

... the kinds of paradigms or ng features that perl has that python doesn't?


I can think of grammars, junctions, autothreading.

Grammars are YACC on steroids. You can very simply say "this parsing state requires reading dot-separated things".

Junctions define multiple plausible states. In certain instances, they can look like a feature you know, but they're more generalized than any of those: sum types, switch statements with multiple cases, combined guards, sets…

Autothreading gives the ability to automatically parallelize certain constructs (for instance, when an expensive operation happens on a junction).

Perl6 also includes features found only in non-mainstream languages, like lazy lists, macros, and runtime addition of syntax.

And it has most modern concurrency primitives, unlike most languages which only have one: threads, locks, semaphores, promises, channels, event loops, supplies.

To be clear: Perl 6 is not without flaws (marketing and performance, for instance), but it is definitely innovative. It lets you write expressive code more succinctly than mainstream dynamic languages, in a way similar to how Python lets you write expressive code succinctly compared to C++.


Python is a Turing Complete language, so I'd be surprised if it trully lacked a feature and there weren't a library written by a poor soul that implemented it.

I am talking more about programming thinking than a feature set. That there's no such thing as Unicode issues or needing to use silly "u" prefixes. That 0.1 + 0.2 == 0.3 reliably that you can write accounting software worry-free and not wonder about why it fails in so many old langs. That you can use grammars to write a mini-language for your specific problem to save yourself tons of generic programming. That you can branch off into a separate processor core with a simple `start` keyword or parallelize a method call on a list of items with just a `>>` hyper prefix or seamlessly communicate a job parallelized over 30 cores with yet another core with a simmple channelled supply without worrying about data races.

These features may be present in Python, but way of thinking isn't. A new programmer starting in Perl 6 won't think of multi-threading, Unicode, floating point math as problematic areas and grammars together with full-language maleability that lets you create problem-specific langs instead of a mountain of generic classes is undreamt of by oldschoolers like me.


> That there's no such thing as Unicode issues or needing to use silly "u" prefixes. That 0.1 + 0.2 == 0.3 reliably that you can write accounting software worry-free and not wonder about why it fails in so many old langs.

It's interesting that you lead with a bunch of examples which are very old or simply wrong.

For example, in any language where you don't think about Unicode you are guaranteed to have encoding issues as soon as you have sufficiently diverse (i.e. real-world) data. If Python 2's u"" prefix offends you so – I must say, hearing a Perl programmer complain about punctuation is a somewhat novel experience – note that Python 3 was released in 2008 which changed to use Unicode by default. In every language, however, you will need to think about file encodings everywhere you read or write data until we finally hit that halcyon decade (century?) where you can assume UTF-8 with a very high level of confidence.

Similarly, Python has had decimal-accurate math since the early 2000s so the developer is free to pick whether they value absolute precision over standard IEEE floating point semantics. Perl 6 dynamically switches numeric classes so the simple syntax you show will lose precision at some point depending on the data and order of operations – that's why the documentation specifies Rat as “limited precision” and it means that anyone writing accounting (or, in many cases, scientific) software would explicitly use an arbitrary-precision data type to avoid the classic floating-point math problems:

    $ perl6 --version
    This is Rakudo version 2016.10 built on MoarVM version 2016.10
    $ perl6
    > 123456789 - 1e-5
    123456788.99999
    > 123456789 - 1e-6
    123456788.999999
    > 123456789 - 1e-7
    123456789
    > (123456789 - 1e-1) - 123456789
    -0.0999999940395355
Please note that I'm not saying Perl 6 is terrible. This is a well known trade-off which everyone has to learn about if they work in fields where this matters. Perl 6 has arbitrary-precision types built-in so anyone dealing with financial data is simply going to learn to specify that precision is not an acceptable trade-off for performance:

    > my $a = Num(12356789)
    12356789
    > $a + FatRat(0.1) - $a
    0.099999999627471
    > my $a = FatRat(12356789)
    12356789
    > $a + FatRat(0.1) - $a
    0.1
I would suggest focusing on the parts of Perl 6 which you like rather than hurling bricks at other languages. Things like start / hyper sound kind of interesting and it'd be far more interesting to hear about how those work in practice and how you manage issues like communications overhead or shared data than your personal dislikes about some other language.


> Python 3 was released in 2008 which changed to use Unicode by default.

Sure, but Python 3 only took on correct handling at the whole string level. It ignored correct handling at the character and sub-string level. Something similar applies for many programming languages. I think this was Zoffix's point.[1]

> explicitly use an arbitrary-precision data type to avoid the classic floating-point math problems:

    > 123456789 - 1e-5
    123456788.99999
Literals of the form `1e-5` are not arbitrary precision in Perl 6. They are floating point (called Num in Perl 6).Hence your above result. Similarly:

    > my $a = Num(12356789)
    12356789
    > $a + FatRat(0.1) - $a
    0.099999999627471
would work if instead you wrote:

    > my $a = 12356789
    12356789
    > $a + 0.1 - $a
    0.1
    > $a + 0.00001 - $a
    0.00001
If all inputs are 100% accurate, arbitrary precision Ints and/or FatRats then all results will be too. But the same applies even if some Rats are also involved provided the final result requires a denominator less than 18,446,744,073,709,551,615.

[1] Of the 150+ languages with Rosettacode solutions for returning the length of a string (at http://rosettacode.org/wiki/String_length) just 3 (Elixir, Perl 6, Swift) have a built in way to get the right result for what Unicode defines as "what a user thinks of as a character".


> Sure, but Python 3 only took on correct handling at the whole string level. It ignored correct handling at the character and sub-string level. Something similar applies for many programming languages. I think this was Zoffix's point

It very well could have been what Zoffix had in mind but do note that this goes back to the problem with the rant style of post.

As for the specific question of character handling which you raised, given the wide number of people who have made other choices on the question of whether a length function should count codepoints or graphemes that I'm reluctant to say using one versus the other is a question of “correct” or “incorrect” versus simply “different”. I suspect most programmers are rarely going to care and the ones who do are going to need to learn enough more about Unicode and i18n that this difference will not be a deciding factor for anyone.

(This is not to detract from the great history the Perl community has with taking seriously the benefits of having a rich Unicode API – I've routinely used this as an example to follow – but simply that Unicode is a deceptively simple-looking topic)

> Literals of the form `1e-5` are not arbitrary precision in Perl 6. They are floating point (called Num in Perl 6).

Yes. Again, my point wasn't that Perl 6 is bad but rather that it's lazy and ineffective advocacy to say something like “you can write accounting software worry-free” when you know full well that anyone doing that for real will still need to understand the differences and that most users will never care because they aren't writing financial software.


There definitely are good reasons for a length function to count both codepoints and graphemes. Which is why Perl 6 has a method for both. This is also why neither of them is called `length`. In fact if you ever attempt to call the `length` method on an object Rakudo will ask you "Did you mean 'elems', 'chars' or 'codes'"


Yes - it's a good distinction to make and when you need it, it's extremely useful. As I said, Perl deserves respect for Unicode in general and raising awareness of this issue is a key reason for that.

However, keep in mind that I was responding to a comment which simply referred to “Unicode issues or needing to use silly "u" prefixes”. This whole tangent started with a guess about what the author might have had in mind.

On this specific point, note that I wasn't saying that it wasn't good to have both but that I wouldn't call a language incorrect for working only with Unicode codepoints. That's because for most programmers this entire class of problem is someone else's problem – usually whoever wrote the text rendering engine in your browser or OS – and the people who do need to care have needed to learn most of e.g. http://unicode.org/reports/tr29/ anyway and understand which portions are relevant to whatever task and data they're working with. It's kind of cool that e.g. 'क्षि'.elems == 1, 'क्षि'.chars == 2, etc. but on the rare occasions where that would be more than trivia, I was more interested in questions like measured width in a certain font or language-specific collation or word-breaking rules.

This is all coming back to why I don't think attacking other languages is effective advocacy unless you're very knowledgeable on the details and impact for working programmers. Telling someone that a commonly used tool which works well for millions of users is incorrect is unlikely to produce the desired outcome. Showing them a cool thing which your favorite tool does better is usually going to be more effective because it gives you something concrete to talk about and it's not confrontational. Programming languages are a major commitment and very few people are going to switch because of one bullet point – that either takes market requirements (e.g. Objective C/Swift, JavaScript) or gradually building up a good reputation over time.


> I wouldn't call a language incorrect for working only with Unicode codepoints.

I didn't call Python incorrect. I'll footnote another attempt to communicate the point I was trying to make.^1

> for most programmers this entire class of problem is someone else's problem

Do you primarily mean most western devs when you say "most programmers" or are you including chinese, indian, etc.?

Do you primarily mean rendering issues when you say "this entire class of problems" or do you mean the full range of character handling issues that ordinary devs occasionally encounter such as comparing strings?

> and the people who do need to care have needed to learn most of e.g. http://unicode.org/reports/tr29/

To date, and for the near term future, sure.

But do you think it was the long term intent of Unicode that devs who merely want to grab the first three characters from a Unicode string have to first get up to speed on these incredibly complex portions of the Unicode standard if they wish to get it right?

TC made great points in his SO -- but so did the guy asking the question.

Now users have begun inserting colorized emojis and other such complexities in what might reasonably be considered contemporary run-of-the-mill text strings (eg tweets). I think this problem is going to accelerate.

Those who designed Elixir, Perl 6 and Swift have taken on Unicode, including TR29, as a core language level responsibility so that devs who merely use these programming languages don't immediately get overwhelmed when they just want to compare two strings.

> 'क्षि'.elems == 1

In Perl 6 `.elems` is always `1` for any single string of any length.

> 'क्षि'.chars == 2

By default, character boundaries are determined by the default EGC algorithm specified by Unicode. The default EGC algorithm gives the incorrect result for क्षि.

Getting the correct result (`== 1`) would require `use`ing a module that implements the appropriate tailored grapheme clustering.

> I was more interested in questions like measured width in a certain font or language-specific collation or word-breaking rules.

For now, the Perl 6 perspective on such matters is that devs should use the appropriate Perl 5 modules:

    use Some::Perl5::Module:from<Perl5>;

    ... Perl 6 code ...
Thanks for this exchange. I'm curious to see if you still feel I'm ranting. For now I'm off to an end of world party. Maybe we'll wake up to find President Evan McWho is in charge...

----

^1 A search for "grapheme" (the term used in the Unicode standard to denote what I mean by "atomic character" and what a user thinks of as a character) yields zero matches. Does Python doc use some other term to denote what a user thinks of as a character? Microsoft uses the term "text element". Swift and Perl 6 use the term "character". What term does Python use?

A search in the Python 3 docs for "character" yields several pages that total over 500 matches. I looked at a few. All corresponded to use of the word "character" to denote a codepoint (an accent, a colorizing instruction, a bidi directive, a base letter, etc.). None corresponded to what a user thinks of as a character. Do you think any uses of the term "character" will turn out to correspond to what a user thinks of as a character / text element / grapheme / whatever you and/or Python docs wish to call them?


For the sake of exhaustivity, let's point out that numeric literals in Perl6 separate rationals (Rat) and floating-point numbers (Num), which means the first Perl6 example would work as intended provided we stick with Rat:

  > 123456789 - 0.0000001
  123456788.9999999
  > (123456789 - 0.1) - 123456789
  -0.1
Rationals represent numbers of the form a÷b, with a a bigint and b a 64-bit integer. When b gets too big for that fast representation, it gets converted to a Num (ie, IEEE 754).

  > (1 / (10 ** 100)).WHAT
  (Num)
That tradeoff is reasonable, as numbers that cannot be represented this way are very likely to be non-rational math (eg, sqrt, exp, sin, pi, that kind of thing). For money, this is safe. For real numbers, well:

  > sin(0).WHAT
  (Num)
FatRat uses a bigint for b. Obviously, it still cannot accurately represent non-rational numbers such as pi.

Reference: https://docs.perl6.org/language/syntax#Number_literals https://docs.perl6.org/type/Rat


Thanks! I definitely hope my point didn't come across as “this is terrible” rather than “people for whom this is critical still need to read the docs / write tests”.


I wonder : what are those new paradigms perl6 is introducing?

I learnt ruby in early 2000', way before rails, because I was attracted to its "it's 100% OO" concept. Now, I use golang, because background jobs have progressively became a capital part of my programs, and I love how it's just about prefixing a function call with a keyword, in golang. The idea of having system programming-like perfs in web doesn't hurt either. What would you say are the groundbreaking new concepts of perl-6 ?


I wrote a short answer here: https://news.ycombinator.com/item?id=12890552

If you like go's conc stuff, then I'm sure you'll love Perl 6's async/conc/paralel. stuff: https://docs.perl6.org/language/concurrency#High-level_APIs

I wrote an IRC API with Perl 6 that I really love, since it makes it so easy for me to parallelize a plugin's work, while working with an async protocol, all the while connected to multiple servers, all with the same short script: http://perl6.party/post/IRC-Client-Perl-6-Multi-Server-IRC-M...


Thanks!

I'm going to be honest: nothing in what is described seems to me like a new idea that makes me want to try perl6. Floating point safeness is in R, dsl is in ruby, concurrence is in golang. And unicode... I'm not exactly sure what the problem is with other languages, I guess it never hit me. :)

That being said, it's cool to see all those features in the same language. I'll keep it in mind if anyone mentions all or most of those as pain points.


So, floating point safesness is in R, dsl in ruby, concurency in Go and Unicode in... ? What if you want two features at once ? Or all of them ? ;)

Examples: multi wins(Scissors $, Paper $) { +1 }; # dispatch on types

my @a = 1..5; say [+] @a; # 15

(a,b,c) Z (1,2,3) # ((a,1),(b,2),(c,3))

my $time = now; say now - $time;

class Person does Employee { }

use NativeCall; # WOW

and MORE !

So ansering: why Perl6 hasn't taken off yet ? Becouse language specification was released 11 month ago with referential implementation (just like Amaya in 1996). So give it 2 years, it will be "fully operational" ;)


> So, floating point safesness is in R, dsl in ruby, concurency in Go and Unicode in... ? What if you want two features at once ? Or all of them ? ;)

I'm pretty sure you noticed this was exactly the questions my comment was addressing ;)


Oops, but noticied now :)


It's a welcome surprise to see an unreasonable and inflammatory post end with such a good piece of advice.

Needless to say the notion that python and ruby programmers are greybeards who need to "die off" to make way for the future of software development is not a rational assessment of the state of the industry.


Of course, it's not. But as a developer who doesn't use those two languages my only point of contact with them is via those greybears who tarnish the image of the entire lot ;)


Like Larry Wall?


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.


The logo is amateurish.


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


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?


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 learnt Perl 5 a long time ago (in school) and used it for CGI based web-sites and sys-admin stuff. I always found it easier to rewrite Perl code from scratch than maintain it. Of course at the time, I was a newbie programmer, so I don't blame the language.

I don't know why I should learn Perl 6 when there are so many new languages to learn. (Just keeping up with web-tech and Javascript itself takes an enormous chunk of time away)

Can a perl 6 geek give a use case of why perl 6 would be better choice than Ruby/Python/ES6/Java/Scala/C#/F#/Rust/Swift for an application in some domain ?

A comparison on where Perl 6 is superior on different parameters such as productivity, libraries, module system, documentation tools, packaging & assembly, macro and micro performance, runtime-scaling, concurrency models, hot-deployment, software-update, etc would be great.


Also a perl 5 refugee. We use python at work, and ended up using virtual environments all over place. (Basically, python scripts can download and install a chroot with a whole python package tree in it on first run). Perl 6 supports this sort of thing instead:

use Package=1.2.3;

So you have some hope of using the system perl without dll hell.


That's actually really nice. I mean a central dependency file would still maybe be good for security updates and so on, but I wonder why multiple version support is still so uncommon among ecosystems.


To me, it's mostly the presence of all new CS inventions in core. Like you don't need any damn libraries to paralellize stuff, just use `start` block or a `supply`. If you write accounting software, you'll appreciate built-in rationals so that 0.1 + 0.2 == 0.3, unlike so many other languages. Laziness is present in many things like lazy exceptions, string generation, and sequences: say (3, 9 … ∞)[^20] does not hang and produces (3 9 15 21 27 33 39 45 51 57 63 69 75 81 87 93 99 105 111 117), despite being an infinite sequence.

You also have grammars, more readable regex language, and superb object model. On a more advanced spectrum, with grammars and slangs, you can craft your own mini-languages for a specific domain where they would fit better; there's a nice little presentation by Damian Conway where he crafts an operator for quantum mechanical math that looks and functions just like the proper mathematical symbol functions: https://www.youtube.com/watch?v=Nq2HkAYbG5o

As for the langs you mentioned: I find a lot of similarities between Rust and Perl 6, although in some areas it seems Perl 6 folks did more thinking (like the .match stuff). They are however in different domains, Rust being a systems language; but you can use Rust libraries in Perl 6 via NativeCall if you compile them for C calling convention.

Perl 6 smokes Ruby and Python with its asynch/parallel/conc. support and more advanced object model.

As far as Unicode support goes, only Swift comes close to Perl 6; try to uppercase "ß" in Ruby, for example. Even if you to claim you only write software for English-speaking customers, you still have to deal with weird customer names for example.

For parameters you mention, many people notice they have to write fewer code in Perl 6. Personally, I found when writing equivalent code as Perl 5, my Perl 6 versions were TWICE as short. And I don't mean you golf your program to anything unreadable, but rather the provided primitives are... well, modern... so I don't have to reinvent them with more basic primitives provided by older langs.

What you'll find is performance is a bit crappy right now. Perl 6's stable got released less than a year ago so there's still a ton of work left to do in bugfixing and optimizations. I think that's what a lot of folks fail to realize that Perl 6 is a brand new baby language so trying to compare its performance to Python (25 years of work) or Ruby (21 years of work) or ES6 (tons of corporate interest) is a bit unrealistic at this moment in time.

In conclusion, one can list dozens of benefits, but I think at the end of the day, it'll all come down to which language better fits your brain and if you participate in a community, which community feels more like the folks of your kind. So far, anyone who I saw try the language say they loved it. The performance can use an improvement and that's what the core devs are working on. So, I think the steam is being gathered.


Thanks for detailed response. After a quick reading, I admit Perl 6 grammars and slang look amazing. Appears to give the language a LISP-like flexibility for creating DSL's.

I discovered that Perl 6 Supply is basically the same as Streams/Sequences which is great for handling async activities and work units.

Also discovered that perl 6 has optional typing. This is terrific since it makes for better maintenance and refactoring tools possible.

I do hope the performance improves! There are so many competitive languages for the backend today that without excellent performance, memory management and scaling characteristics, it is difficult for any new language to gain traction just on features alone.


I think the biggest problem Perl6 faces now is the perception that it is unfinished. This is mostly a problem of their own making. The language was in development for 15 years! In that time people got it drilled into their head that it wasn't done yet and likely would never be.

While this perception did hurt Perl5 it seems to have also hurt itself since reading this thread and seeing the number of people saying that it is "still in progress" or "still changing". This brings me to my second point, and the one that frustrates me more.

In fact Perl6 was released as stable 1.0 on Christmas of 2015. You could be excused for not noticing it. There were a few articles in a few technical journals in the months leading up tot he release but mostly the release day went by completely unnoticed and barely remarked upon.

Perl6 is a spectacular achievement! A language designed over the course of 15 years with the extreme flexibility and malleability to last 100 years more. This could have been a news story, a big release party, lots of hype, press releases. A language in the works for 15 years, it must be great right!?

Instead, to keep with an in-joke about "released by Christmas" it was released on Christmas day by developers who had family plans to a community that was busy with their own. I doubt many people know it happened. Indeed this thread seems proof of that.

Its not everyday that a 15 year project is completed. What an opportunity for exultation, and good press, wasted.


I agree. When I first starting trying to use perl 6 (after it was fully released) and had questions, most of the replies to those questions I found were from 10 years ago, when the answer was "XYZ... but it's not finished yet". The ecosystem has 15 years of outdated documentation still floating around, and they need to organize the current documentation in a way that's helpful to new developers.


For the last year, I've seen you several times re-iterate that point that just-if and if-only the handful of volunteers who drive this project made some sort of a massive media spectacle then everyone and their brother would be using Perl 6 these days.

Sorry, but that's just wishful thinking. We don't have infinite resources or infinite number of volunteers. Maybe instead of endless critique, you could offer a helping hand. You did want to at one point: https://irclog.perlgeek.de/mojo/2016-10-09#i_13366119


And by the way, no I'm really not interested in generally helping with a language I don't use. What I object to is the Perl6 community siphoning off Perl5 oxygen and then using it to do nothing. I WAS willing to help ... in the moment that it would have helped. Its too late now, I'm not sure how Perl6 gets the spotlight again when it so perfectly eschewed it when one was waiting to shine on it.


You'll notice that that irc log is just me saying october what I'm saying now. The release was botched. Had I had any idea of the lackluster release that was to come I would have helped. This is a better log to read IMO: http://irclog.perlgeek.de/perl6/2015-12-24#i_11771099


It doesn't matter what people say when they dislike the language. Certainly not for other new languages, they still get adopted as long as they offer enough value. These days for most people Perl 6 just doesn't, expectations are too different and too high for it to meet and no PR is going to fix that.


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.


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" :-)


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 :) )


That is in the lama book (http://shop.oreilly.com/product/9780596001322.do).

> Yes, sometimes Perl looks like line noise to the uninitiated, but to the seasoned Perl programmer, it looks like checksummed line noise with a mission in life.

edit: formatting


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? :)


Practicality beats purity


you mean, like print and print() ?


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.


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.


So is Python.


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.


Well, if you wanted "Perl, only better", you went with Ruby. Python is good, but it has a different flavor.


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.


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


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?


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


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.


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


    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>


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


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


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 (former Perl5 dev) am amazed that Perl6 actually has become "production-ready", after all those years. I find it quite good, and there are many interesting new concepts.

However, some things seem to be harder. For instance, it seems that I can't use the handy =~ s/.../ string replacements anymore but have to write grammar rules. Is that true?

If the old way is still possible (without Perl5 mode) then I cannot find it in Perl6's documentation.

Apart from that -- good work!

BTW: There is only one thing which I really dislike about Perl6, and that is that "nifty logo" :-) If you want to attract professional developers you should provide a professionally looking logo.


The s/// is still there. You just use ~~ smartmatch operator instead of =~ binding operator. I did get it to pop up in the docs search results: https://docs.perl6.org/language/operators#index-entry-s%2F%2...

I personally like the method version: .subst() and .subst-mutate()


Wow, that was a quick answer. Thanks so much!


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.


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!


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


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!


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.


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


I remember those... And let's not forget Perl Poetry:

http://www.foo.be/docs/tpj/issues/vol5_1/tpj0501-0012.html


Um, https://en.wikipedia.org/wiki/International_Obfuscated_C_Cod... was there 12 years before OPC.


TIL


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


IMO:

Maturity: Perl 6 was released a little under a year ago. That's not long, and the leading implementation has not yet caught up with the standard (though work is ongoing). The ecosystem isn't quite there yet either.

Examples: People can be really bad at imagining value in the right things - they need to see it. There hasn't been a very compelling killer app yet.

Perception: People conflate Perl 6 with Perl 5. (Reasonably!) Most people remember TIMTOWTDI and remember that it was a bad thing, or at least that they prefer the Zen of Python. Most of all, they remember trying to read bad code. I don't think that Perl encourages bad code, but it sat in spaces that had lots of bad code already. (Lots of code made by people who are not programmers.) There are also codebases in Perl that are very well made, and easy to read. But we are better at remembering bad things.

Again, IMO, Perl 5's biggest problem was the surprising language. I could write something that was legal code, but had different semantic value than I thought, and the language was littered with cases like that. It was common to think that Perl was to complex for any one programmer to know.

Perl 6 isn't like this - the entire language is composed of simple components (at least, simple for their problem domains). It's also littered with good ideas that don't exist in other languages, like their regexen and grammar support. Everything else in the language is still top notch, like unicode handling and concurrency.

Basically, it is the things around the language, not the language itself. I think it is telling that people saying they don't want to use the language are saying "Perl sucks" rather than "I don't like feature X" or "This construct is confusing".

(I remember Eevee saying that "Perl 6 is truly the realization of Perl 5’s mission: to be startlingly consistent, and also just plain startling." I think that when people look at Perl 6, they'll be startled. But when they are no longer surprised, they'll just find powerful consistency.)


The story of Perl vs PHP vs Ruby vs Python is interesting. Apparently both PHP and Ruby were created because its authors found Perl too complicated 20+ years ago(!?). There is definitely a problem with that language (and I find Ruby already complex) that looks extremely cryptic for a non Perl developer. Perl is still used in place of bash scripts and in legacy apps, I just don't see people writing new software with Perl at first place. And System administrators have moved to Python which is now bundled with most distributions. Python just killed Perl.

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

Why would people move from PHP or Python back to Perl ?


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


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


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.


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


I love Perl. My favourite language.

But i hate Perl6. It feels like an obnoxious showoff who people prefer not to talk to.

It offers little that I crave for in Perl. And those bits I can do with Go already.

Perl6 is a distraction from what we should have had .. I'm still dreaming of the day Perl7 comes out with these features: (i) full Perl5 functionality (without having that klunky Inline::Perl5), and (ii) built-in concurrency.

Perl6 is late to the party. Sorry kid, nobody likes you and besides, it's time to go home.


I've had quite a bit of luck with https://github.com/niner/Inline-Perl5

Curious: can you further define 'klunky'? Thanks!


Inline::Perl5 isn't clunky if you are just using it to load modules.

    use Data::Random:from<Perl5> <:all>
Also Perl 6 has several different forms of built-in concurrency.


I think that logo is really childish and weird looking. It puts me off. And Larry Wall talking about perl gets old really fast.

In my opinion perl will slowly die because it has no social capital. A good sign of this is when you are around other programmers working on a real problem if you say "Hey let's solve this problem in perl!" it will almost always be the case that everyone can do it that way and knows exactly what perl to script (if they are of a certain age) but almost no one would even bother. Who cares about the why. It's just the fact. You get no extra points for knowing perl and for the most part if you are the guy on the team that is assigned to work on some old perl script it's probably a bad sign for you career-wise. Other languages, on the other hand, do have social capital.

Ultimately for me it's a lot like asking why everyone still uses the QWERTY keyboard when there are other keyboard layouts out there that are so much better. Perl might be better at some things, but like alternatives to the QWERTY keyboard, it's just weird to use it and the payoff isn't big enough to justify the change.


Perl has an amazing amount of social capital. It's used by tons of Fortune-500 companies. Good luck finding a single business on Wall Street that isn't using it. It's huge in the finance industry. The problem is people in the finance industry aren't allowed to talk about what they do, ever. So it doesn't get much press. It's also huge in biotech, but again, biotech doesn't get much front-page action.

Just recently, Booking.com gave over $100k to continue work in Perl. Craigslist gave over $50k for Perl. These are huge companies doing amazingly well, all depending on Perl. And they give like this every single year. Got a few minutes, check out all the companies (including tons of startups) on BuiltInPerl.com.

Perl bad for your Career? Don't tell that to the people at BusinessInsider, who ranked it the highest paying language to learn: http://www.businessinsider.com/9-tech-skills-that-pay-over-1... And they aren't alone. A recent Gartner study says "Current and prospective Perl developers should feel confident that the language will remain a solid technology investment for the foreseeable future."

The truth is Perl is the original QWERTY keyboard. But many people left it a long time ago for some really good reasons, and Perl took too long to fix those issues. Many of the reasons people left have been fixed for years or decades now. But anybody in sales will tell you it takes a lot more effort to fix a bad relationship than it takes to keep people happy. I wish the Perl community had realized that 15 years ago. Now, Perl faces the uphill battle of getting people willing to take a second look.

Fortunately, Perl has a massive community behind it. No other language can rival what the Comprehensive Perl Archive Network (CPAN) offers right now (even the ones that tried to copy it outright). Perl has amazing conferences going on around the world with huge turnouts. Yet, it has an invalid reputation that "Perl is dying." Why? Because Perl's Achilles heel is marketing.

Perl is seriously competitive in every category. It's being used all around the world by huge companies. It has an amazing community of support built around it. Perl developers are in huge demand (check out jobs.perl.org). Want a great job after school? Learn Perl!

But you'll never hear it discussed in a board room. And if you try to bring it up in a non-perl shop, you'll probably run into somebody that thinks "You get no extra points for knowing Perl." Really, the issue that people don't understand is that there are people that write scripts in Perl, and then there are people that write CODE in Perl. Both are great, both are important, but they are both very different. Many scripters don't even know, or need to know, there's a whole other level of Perl coding available. And this all comes down to marketing. Perl has failed to market itself.

So what happens now? Companies that are more interested in picking a tool that does the best job will take a look at Perl, and many will choose it. Companies that are primarily interested in hype probably won't. The Perl community isn't going anywhere. Things will progress and then 10 years from now, there will still be people posting about how in their opinion "perl will slowly die." while the other languages of today are dead and gone.


Around the new year, I looked at Perl 6 as a candidate for focus in 2016. This was around the time Perl 6 was officially released. I encountered two impediments.

1. At the time, there was not a great 'hello world' installation story for Rakudo Star.

2. There was not a good Perl 6 book published in the last ten years (that does not appear to have changed per a quick Google).

The most readable information I found was the Advent Calendars, but it's fragmented, poorly indexed, and doesn't form a coherent whole. At the time, there wasn't a good StackOverflow story (and the most recent question right now is from October 16, and the average is less than one question per day).

That said, Perl 6 is obviously a long term project and looks like an innovative language that could build mindshare with a bit of luck and the right resources (Ruby and Python didn't become popular overnight). All I'm saying is that it was not a good fit for me at the time.


Of course there isn't a current Perl 6 book, the design was only finalized last Christmas. If someone had started before that, they may have had to rewrite large sections to keep up-to-date.

Books also take time to write, and the people who would write such books have day jobs.

To be fair the rate of questions about Perl 5 back when Stack Overflow started was fairly low too.

That isn't even the best metric, on the site anyway. The best metrics are how many are answered, and how quickly before someone at least adds a comment.


There are some P6 books on the way. I think 3 within the next 3 years. Nothing is set in stone though, but that is what P5 authors have said recently at conferences.


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.


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.


"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


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


[0] http://perl6intro.com/

The start page of https://docs.perl6.org/ is not referring there is a bug indeed. It will be fixed in a day or two.


thx @gfldex, index needs to be simpler, the topic pages are great, just what I would have expected.


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.


[0] http://perl6intro.com/


Some translations:

Bulgarian: http://bg.perl6intro.com

Dutch: http://nl.perl6intro.com

French: http://fr.perl6intro.com

German: http://de.perl6intro.com

Japanese: http://ja.perl6intro.com

Portuguese: http://pt.perl6intro.com

Spanish: http://es.perl6intro.com


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.


1. Because Perl was asleep at the wheel while Python, Ruby et al got popular.

2. Perl has a bad reputation - lots of people wrote really really obtuse code in Perl and called it clever. Maintenance sometimes feels like stepping into an alt. dimension.


I would call it "bad image" instead of "bad reputation", because when you look into it, a lot of very stable and maintainable software is written in Perl. I suspect the image of Perl is mostly derived from hearsay rather than from actual experience in a real-life scenario. I know that for example xing.com and united-domains.com use Perl a lot.

I have to say, it kind of makes me a bit sad, that the image of Perl is so bad while in fact it is a great language. Almost like a genious ugly-looking child in school. I wish more people would actually try it and give it a proper chance. That is also true for other languages as well, like Haskell and Prolog.


> I would call it "bad image" instead of "bad reputation", because when you look into it, a lot of very stable and maintainable software is written in Perl.

Fair enough. I've written a lot of Perl code - some I'm still proud of! :)


Because people keep asking why it hasn't taken off rather than using it and posting here about how it was awesome.


In the 1990s I think Perl was something special. Tcl was a competitive scripting language but I think a lot of people saw it as too weird. (Imagine LISP where the basic data structure is a string)

By 2000 or so you had Python and PHP coming on really strong. PHP owned the web and I think Python owned everything else.

I had a module that did web authentication with cookies in a number of languages (PHP, Java, Cold Fusion, Perl, Classic ASP) and out of all of them I liked the OO Perl implementation the best.


Back in the 1990's, Tcl was probably the best way to do GUI development on Unix. Qt was commercial at the time, Gtk didn't exist, and everything else was saddled with baroque API's, commercial licenses, ugly asthetics, or some combination of the three.

In that context, Tcl/Tk was magical... you could put together a window with a button and an event handler inside of five lines of code. (And it would look pretty good when you were done.) If you weren't hung up on drag and drop UI building, it was arguably a better way to assemble UI components than VisualBASIC. I spent a year or two doing research UI development in Tcl and loved the tool chain.

On the other hand, Tcl got swamped with a number of forces that conspired against it in the long run. In some ways, Tk was a deficit, as good as it was... I think it tended to pigeonhole the language a bit more than was fair. Also, the changes of ownership (and motivations) between Berkeley/Osterhout, Sun, and Scriptics were muddled... particularly given the rapid ascendancy of Java and JavaScript. (Both of which did a good job of supplanting Tcl in it's non-GUI roles.)

While I don't think the string-oriented nature of the language did it any favors, I also think it illustrates one of the problems with language design. The language had some great capabilities (because it was so heavily based on strings) but I don't think many people ever truly understood the significance enough for it to really become a selling point. Tcl suffered the downside of the weird syntax, but realized none of the benefits it got from having the weird syntax. (A lot like Lisp, as you say.)


You could get those benefits but most people did not.


I know this isn't going to happen, but I think the only way to make Perl 6 the new poster child would be to rename it.

It has a lot to do with human psychology. People don't like that argument, but many things happening in IT have a lot more to do with psychology, sociology and marketing rather than any technical ("factual") reasons.

The most technical reason probably is the cost to switch, but that reason doesn't explain many things and people do switch to new things all the time.


For me the Perl 6 and Python 3 changes have similar problems: no realistic solution for massive code bases.

I worked at least 3 different places that had massive code bases in Perl 5, that saw no signs of changing the entire time. Furthermore, ecosystems develop around these things, e.g. people (unwisely or not) saving “data” as Perl 5 hashes. There are similar dependencies on the Python 2.x way of doing things.

Also, every project has its own long-term maintenance items to do. LONG before I consider screwing with the very syntax of my entire code base, I will be thinking about things like: avoiding deprecated APIs in other libraries, refactoring problematic designs, etc.

Also, project repositories frequently branch out and every merge is a pain point. There could be many people developing unrelated items in parallel. There is NO convenient place to merge in somebody’s completely new language syntax, just like there is no place for gratuitous reformatting of code or other high-impact, low-benefit scenarios.

And finally, even if a code base isn’t massive, developers have limited time. It is always more attractive to fix some bugs or add dozens of features. It is never attractive to do a complete rewrite of code for unproven gain and definite pain.


You are mistaken, the Perl6 solution is easy: you can use Perl5 code directly (import it). It's nothing like the Python2 -> 3 mess.


I'm a Linux sysadmin/devops with a heavy automation background and quite an interest in automation. I've been writing Perl (until recently that is) for over 15 years. Today I focus on Python, both in my personal and work projects.

I do it for the same reason I learned Perl originally, because I have a mortgage/rent/expenses to pay. You have folks who walk around with LISP books under their arms and learn obscura perfecta like OCaml, but I'm a lot more simple-minded: I learn what I need to learn to get my job done and also new jobs/gigs lined up. I'm not an academic, nor an advocate.

Don't get me wrong, I enjoy reading purist debates, early adopters, experts, people with interest in dynamic language theory, duking it out. At the end of the day, though, if not a single person around me writes in Perl 6, and not a single job listing shows Perl 6, then I'm probably going to wait it out until that does start to happen. And then we'll see.

So, to answer the question by the original poster: I haven't adopted Perl6 because I'm not an early adopter. Maybe if the 24 hour day suddenly became a 28 hour one ...


I suppose Perl 6 "taking off" and becoming such a "poster child of "scripting languages" nowadays is not so much about "scripting languages" but rather "application platforms" instead. Gone are the days where one would just write a bunch of scripts for a cgi-bin--you're now supposed to write a complete environment for deployment onto highly redundant, low-latency clouds--bonus if going "Serverless" and transpiles to JS.

That said, Perl 6 is becoming such an attractive platform for those who have bothered themselves to go and actually try it; being a Perl 5 hacker myself, I'm taking my time learning it in parallel to a few other languages, and its interesting to see how 2 decades of wandering has brought forth. I suppose that maybe Perl 6 will become like a Lisp (in such that learning provides for a deeper appreciation,) or maybe not (e.g. we actually make https://xkcd.com/224/ happen,) but at the end I know Perl 6 will be there as a tool I can reach for.


The syntax is even more complex and harder to learn, than the syntax of Perl 5, so it has to offer something worthy of an effort. Even worse, it has to compete with non-scripting languages, limiting its usage to pretty much just I/O bound tasks.

If you think about it the only one among new scripting languages that offers something over competition is Elixir, because of the actor model. And it's getting traction.


I was keeping an eye on perl6 for a long time, still do, still have 3+ RSS feeds that are perl6 related. But as a 'not workhorse language that is potentially worth learning' it shares space with Red http://www.red-lang.org and it interest me more at the moment.


About a decade ago many educators where looking for a language to teach programming to utter noobs because governments where scared by the year 2000 bug and asked them to produce more programmers (the latter part is a lie but it sounds nice :) many of them picked Python. Educators play a big role these days when it comes to a first language. Most folk who commented here likely went to school when teachers didn't have computers and didn't even think about teaching programming -- that was considered a hobby. So far I know only two educators who want to teach programming with Perl 6.

It takes years for a language to become used by a reasonably large group to make a difference. Given you come from Python you probably know that the first release happened in 1991. Do you know anyone who used that language before 2000? So Perl 6 didn't take off yet because less then a year since the initial release has happened.


That's very similar to saying why haven't Perl 5 folks switched to Ruby or Python or whatever. For all intents and purposes, Perl 6 is a different language with a very similar sounding name. Those folks who have used Perl 5 and built up systems around it, they are only going to switch if there is a compelling reason to.


I was tired of dealing with TIMTOADI (there is more than one way to do it), one of Perl's catch phrases. More like there's more than 50 ways to do it. It sounds wonderful and liberating, and it is, but it also means that when you just want to read some docs, the docs go through all the different ways, when you just want to get something done right now. And reading others' code, no two solutions are the same. Are there benefits, sure, yes, but sometimes you just want to know the best practice.

With Perl 6 having a learning curve, I thought I might as well use that time to instead learn Python, a language designed with the stated principle that there should be one preferred way to do things.

Unfortunately I started learning Python just as the Python 2 vs Python 3 rift was at a peak. Sigh.


From my perspective — and I went through a years-long period of writing exclusively in Perl — Perl just doesn't seem to have anything to offer me anymore. I resisted Python for a long time because Perl was so much faster, but eventually I switched because Python was much less a write-only language.

I've since switched to Go, because the way it handles static types is actually pretty awesome (for the most part … there are edge & corner cases), and I find that my software is much more reliable in Go.

For my quick-and-dirty tasks I have Lisp; for my job I have Go: does Perl 6 offer me anything I don't already have?


I have been using Perl for more than twenty years. I remember installing Perl 5 because somebody had written the network monitoring tool "SATAN" in it. I have written some nasty code with it, and some pretty clean code. Relying on CPAN, I have saved myself and others just huge amounts of time and trouble.

These days I tend to use Python for new projects, because the young coders where I work are more accustomed to that. Now, if someone where to show up fresh out of school and sure that Perl 6 was the thing, I'd be open to trying that.


The comments here are great and answer the question in various sensible ways, but I slightly wonder... could Perl make a comeback if it got its own Rails equivalent? You could argue that Laravel has done a lot for PHP (though of course PHP never went into the wilderness in the way that Perl did). Perl 6 seems to have a lot of magic in it, and I wonder if any of that could be usefully leveraged to make something very modern, very clever, and very Rails-esque that actually might get people interested in using Perl 6.

(See also Phoenix and Elixir.)


It's hard for me to describe how much Perl 6 doesn't need another web framework, but someone to actually use the ones that already exist! There is even already more than one middleware solution Crust and P6W.

https://github.com/ufobat/Bailador

https://github.com/tokuhirom/p6-Crust

https://github.com/skaji/Frinfon

https://github.com/nunorc/p6-Pekyll

https://github.com/retupmoca/P6-Web-RF

https://github.com/drforr/perl6-App-prancer

https://github.com/sergot/BreakDancer

https://gitlab.com/samcns/uzu

https://github.com/supernovus/perl6-web-app-ballet

https://github.com/zostay/P6W

Testing https://github.com/azawawi/perl6-selenium-webdriver

Even desktop style web applications with Electron https://github.com/azawawi/perl6-electron

It's all there just no one engages with any of the development because its not trending on HN every five seconds or has the eye of the tweener set of developers who blog and vlog.


Maybe the problem is there are too many. Some of us just want to pick a leading best-practices solution quickly. Which is more of an agreement with your first statement than a contradiction.

The part about trending every five seconds was gratuitous and overlooks the point that using something with broad community engagement has huge benefits, as people share their issues and solutions, and things get fixed and stay updated with the input of a large community, the power of which exceeds that of any one developer.


Plenty of things trend often on HN with very little community or support existing to date. They are still heard about frequently. The reason is the community understand how to get attention in a way that engages your average dev. It's that engagement rather than intrinsic value that is important. Programming languages essentially all do the same job. Convincing someone a wheel is rounder for your road at home is mostly about spin (and puns). I think it's safe to say the Perl community are not as good at this as they used to be say in the 90s or 00s. Another issue I think that many people overlook is ageism exists in tech. As you get older you are likely writing less code and managing projects or doing some design for others. At that point many of the tech decisions that are lower down are made by younger generations who also want something new, because the assumption at the moment is new tech is better tech. Which for the most part is sort of true.


Thanks for your rude reply.

None of these seem to be anything like Rails - they look much more geared towards the Sinatra/Flask micro-framework crowd. People didn't start flocking to Ruby because of Sinatra (not that there's anything wrong with Sinatra).


Thanks for your projection of rudeness... Makes me feel extra special given I spent about ten minutes linking all that stuff.

Baliador is meant to be a take on Dancer from Perl 5 which is somewhere between Sinatra and Rails in complexity. In the Perl 5 world the equivalent of Rails would be Catalyst. But even that isn't really as monolithically well integrated.

The point I'm making is Rails wasn't built in a day and to date Perl 6 has had quite a few people want to kickstart a Rails initiative but they always do it with new code and new ideas cloning a previous paradigm. A better plan is to embed yourself in what's there especially the core language. With grammars you could write a complete DSL as a web framework with all of the power of Perl 6. But it would take someone knowing the core language well to make something that's slick. For behind the scenes there is little reason to reimplement HTTP parsing/serving since there are a couple of modules that are tested against every release of the Rakudo compiler already.


I know it's dumb but for some reason the large amounts of Rails people moving to Elixir bother me. I don't want the language to be synonymous with web devs :/


I have been using Perl since 1996. I use it as my main language in a professional setting day to day.

I have started doing some things in Go, but the bulk of my code is Perl 5. Having lots of code written in Perl 5 that has worked for over a decade, makes a tough case to suddenly switch to Perl 6. In some sense its like switching from Python 2 to 3. You have to get all the CPAN authors to port all of their modules that your code depends on. I think there too much risk and not enough resources on the corporate side to make the switch.


Did you know you can use your Perl 5 code in Perl 6 and vice-versa?

For example, if you've installed the Perl 5 DBI from CPAN then you can use that in Perl 6 code like this:

    use DBI:from<Perl5>;

    my $dbh = DBI.connect('dbi:Pg:database=test');
    my $products = $dbh.selectall_arrayref(
        'select * from products', {Slice => {}}
    );
I'm not saying Perl 6 is ready or right for you. But Perl 6 doesn't exactly have the Python 2 / Python 3 problem. CPAN authors don't have to port anything and you don't have to port anything to be able to use existing Perl 5 code in Perl 6 (and vice-versa).


This works well: https://github.com/niner/Inline-Perl5


Perl 6 took so long to come out that it long ago became a punchline. The actual launch was the softest I've ever witnessed, and the retention of the name is misleading given the huge changes in the language.

I expect usage and awareness will grow with time, as the geniuses that do the proofs of concept that get the masses' blood flowing burn out on Clojure, Rust, and Haskell and start looking for the next big thing, and write a framework that makes people's heads spin.

Maybe that genius could be you.


The problem with perl is that perl programmers think they can replace thousands of lines of C with 50 line perl programs. Then you find errors like searching thru multicolumns of data for a string, when in fact what you wanted is to search column six only. It 'works' until someone uses that string in column 2. Etc. I switched to haskell a long time ago. It still shocks me that people especially in the chip and computer industry still depend on it so much.


I think it's because the language appears to be very complex. So much syntax, context, and novel terminology.

It appears that Perl 6 lets you be very clever and can save you some keystrokes. But I don't want to be clever, and am willing to type a few extra keystrokes if it makes things easier for me to understand the next time I look at my code.


I have tens of thousands of lines of code written to Perl 5 that I can't run under Perl 6. That's it in a nutshell.


You can use Perl 5 modules via Inline::Perl5.

And "tens of thousands" doesn't sound like a lot to begin with TBH...


I've heard that Inline::Perl5 is klunky

What's your experience?


What's "klunky"? You add :from<Perl5> to module name and off you go. The only thing that irks me is Perl 5's common notation is snake_case, but in Perl 6 kebob-case is almost universal, so by bringing in Perl 5 code you break this stylistic convention.


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.


So, you understand why Python 3 isn't leading yet, but you don't understand why Perl 6 isn't?


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.


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.


fixed with https://github.com/perl6/doc/commit/d1fe150239

The lack of feedback from actual language users did slow down Perl 6 development and esp. getting all the holes in the docs plugged.


The potential to be cryptic argument could easily be applied to Scala but that hasn't stopped it gaining popularity ( http://appliedscala.com/blog/2016/scala-popularity/ )


my a = fn { local $v= _[0] %~=->

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


You haven't looked at a non-ASCII based APL I gather? :)


Dynamic langauges cannot deal with braking changes because the cost of refactoring is too damn high.


Mainly because it isn't ready yet as it is slow and certain features are still missing like macros and concurrency. It's a cool language for sure that I'm excited about, but needs to be at least as fast as P5 (on average) before adoption.


Perl has been trumped by Python. Perl would continue to fade into the sunset through attrition.


Not only is it like a totally different language than Perl 5, the most critical problem is that it simply wasn't popular.

All it would take is buzz... and millennials. Lots of millennials.

Generally, products that are the most popular aren't always the best. Better to just accept that now, especially before you invest much time in the space :)


I feel like everybody who wanted a "better Perl" jumped ship to Ruby.


this kind of advocacy is what it takes, along with a lot more stuff, to get adoption


This is one of those things where everyone who even understands the question is going to have an opinion, and the rest will too. I've worked with Perl professionally since 1995 and still do, which doesn't necessarily mean I know what I'm talking about but FWIW here's my best guess.

I think Perl 6 has not taken off because of three things:

1. Other options.

When Perl 5 really took off in the mid-late 90's, building much of the early Web as well as all sorts of business software (we used it heavily in biotech), there weren't so many other options.

For server-side things it was (or at least seemed) faster, easier, and much much newbie-friendlier to use Perl than the other "obvious" languages, C and Java.

Now there are a lot more languages to choose from, inluding ones that share Perl's original virtues of accessibility and "hackability." While some of these newer languages were gaining ground, Perl 5 was enjoying subtle improvements while seeming more and more dated.

We have large populations of potential Perl hackers who have, for good reasons, chosen to develop their expertise in other languages. They have little interest in learning the "new Perl" because they don't have deep knowledge of nor love for the "old Perl."

That at least some of the hot new languages (Go, Swift) have corporate backing with infinitely deep pockets may also be a factor.

2. Hiring death-spiral.

It's very hard to hire for Perl programming jobs these days. We older Perl hackers often move on (or up) and the young folks look around at where the excitement and the jobs are, and they see them elsewhere.

(Perhaps counterintuitively, there are also a lot of young programmers who prefer Java: maybe not much excitement there, but never any lack of employment.)

The fact that it's hard to assemble, grow or even maintain a Perl team means that it's harder to justify developing systems in Perl from a business perspective. On the one hand you have all the advantages your senior Perl hackers can list for you, and on the other hand you have the cold hard fact that the systems they build will one day be maintained by junior devs who wish they were using something else.

It should be obvious that this is self-reinforcing, and I think there are probably thousands of little Perl shops embedded in big companies where the managers have long been dreaming of a path away from Perl, while the senior Perl hackers reluctantly start to agree with them.

This ends up as Perl 6's problem, not just Perl 5's, because the same people who would usually champion the newest version of the language are busy keeping their Perl 5.x legacy systems alive with shrinking staffs and growing pressure to get off that train.

Also, it will be hard to get your management team to back a big push into Perl 6, because they will only hear "Perl" and remember how painful it was to find Perl people the last time, and the time before that.

3. Approachability.

Perl 6 is really cool and really hackalicious but also not super easy to get started with. Where even back in Perl 4 it felt like it was newbie-friendly, the only thing newbie-friendly on perl6.org is the butterfly logo, of which I am not a fan.

Something like the Go Playground[0] would be nice and might help spread the word. As would a story about what Perl 6 is better at than anything else.

As far as I can tell, cutesy "spokesbugs" aside, Perl 6 is presented as something for the Perl crowd. And as noted above, much of the Perl crowd is too busy for it.

A lot of languages get popular because they show you how easy and fun it is to do thing X in them, and you've always hated doing X in whatever other language. I'm not sure what that X would be for Perl 6, but I have a feeling it's something about the writing itself, which might be a hard sell, but I don't really see it being sold outside the Perl community.

...

Anyway, all that said I would love to see Perl 6 get some traction. I just have no idea where it's going to do that. Maybe if a super high-profile project appears that's all done in Perl 6? Maybe if a small but influential cult of AI hackers falls in love with it? Maybe if it out-Pythons Python as the default entry-level "big data" language?

Because of the reasons listed here, for this old Perl hacker "write stuff in Perl 6" is stuck at the way-way back of the backlog, and well behind at least two other "write stuff in..." stories.

[0]: https://play.golang.org


why would I use perl when I have python?


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.


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


Where did you even get a mention of moarvm for you to get confused about?

Sounds like you're making shit up just to be difficult. The giant button on perl6.org says "Rakudo is a compiler for Perl 6 code", it leads you to a page of choices, among which is a link to a binaries where you choose your platform.

It's like complaining that you have to use `gcc` when learning the C Programming Language and being flabbergasted to find there are multiple versions of it.

Seriously, this isn't rocket surgery.


This sort of incivility is not allowed here. Please comment civilly and substantively, or not at all.

We detached this subthread from https://news.ycombinator.com/item?id=12888924 and marked it off-topic.


And yet his being told to go fuck himself downthread was left uncommented upon.


You don't really think you're facing anti-perl-6 moderation bias, do you? I assure you I'm just bereft of my laptop and stuck in an airplane with a very small phone.

Edit: ok, I've now found that comment (which you're right was worse) and banned the offending account.


Lolno. Just pointing out that that post is likely what got him riled up and thereby resulting in his mistake. I've moderated lots of stuff for years, my baseline expectation is always "moderator mistake" rather than "bias". Just the mote/beam level of this particular case seemed sufficient to be worth commenting on.

Then once I'd posted that, I downvoted zoffix myself for being unconstructive and went and tracked him down on IRC (we've known each other for years) and pointed out that even if you're right, accusing somebody of being intentionally obstructive is pretty much never constructive.


Your objection would bear more credibility if you also raised equal objection to even stronger language used in anti-Perl posts on this thread.


We try our best to be even-handed, of course. But it's impossible to see all the comments, so there's inevitably some irregularity.

Any time people notice comments breaking HN's rules that we haven't replied to, they're welcome to email us at hn@ycombinator.com.


To answer your question the moarvm is mentioned in all the release announcements and in the compilation instructions and in most of the blogs.perl.org posts that I read. For example:

"This is the third post-Christmas (production) release of Rakudo Star and implements Perl v6.c. It comes with support for the MoarVM backend..."

"Deconfusion note: if you're just a regular Perl 6 user, you likely use and only ever heard of Rakudo Star, which is a distribution that includes the Rakudo Perl 6 Compiler, some modules, and the docs. This post details a release of that compiler only, which gets released more often than Rakudo Star. So please don't think there's a new release, if Star is all you use."


[flagged]


We detached this subthread from https://news.ycombinator.com/item?id=12889429 and marked it off-topic.


I banged heads with him a few times on the Mac OS X mailing list. Perl had a very cultish following for a bit and he was adored and celebrated by them so if you crossed him you had to deal with his minions.

On the other hand, a few years later he did stick up for me when I defended my still using CGI.pm on one of the other Perl mailing list and that sure turned the tone of the thread around in a hurry.

I don't recall there ever being any sexist remarks on any of the Perl Mailing list but those incidents mentioned at that link don't surprise me. Randall has a history of doing stupid stuff.


I thought we were finally done with perl. I know I was overjoyed when I could finally get rid of this horrible language in favor of python. Perl was a mistake.


[flagged]


Comments like this aren't allowed here. We've banned this account.

We detached this subthread from https://news.ycombinator.com/item?id=12890300 and marked it off-topic.


Touched a nerve, eh? ;)


Because the industry is slowly moving away from write-only languages.


What does that mean?


Because pearl is not supported to make sense




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: