Why I’m Learning Perl 6

For some reason, when I started my software engineering career I got it into my head that I needed to learn as much as I could about programming languages.

I learned ruby, perl5, python, lisp, forth, ml, ocaml, scheme, haskell, r, c#, java, lua, c++, factor, idris, asm, erlang, prolog, rust, d. But that wasn't quite enough because haskell and idris kept on talking about complicated type theory stuff. So I also learned lambda calculus, type theory, set theory, domain theory, topology, category theory, information theory, sub-structural logic.

What I'm trying to say is that I'm not afraid of learning new things. Even if they seem hard or esoteric.

When I heard that perl6 was ready, I took a look. I like the idea of a lot of what is present in the language (hey look, a grammar engine, that's neat). But ultimately, I decided that it was too much stuff that I would have to learn. Maybe that's just a perception problem on my part, but I have to think that they have some sort of problem if someone like me feels overwhelmed by all of the things that you have to grok in order to understand the language.

At this point the word is so far removed from the meaning in this thread you might as well say a haberdasher supports threads.

I agree here. If Perl 6 however gets anything close to Perl 5's Mojolicious it would be more than enough to switch to it. I haven't used Perl in many years, but it's by far the best web framework I've ever used. It's really thought out well, made all the right design decisions from the beginning and just really great code itself.

But such gems tend to be unique, also in completely different fields. And it probably wouldn't have been possible if the original developer hadn't been involved and gained experience through Catalyst, which is roughly Perl's take on Ruby on Rails.

If it got a bit more press in its early days, outside of the Perl community I think the world of web development could look very different today.

As I said I am not a Perl developer anymore (and don't focus on the web part anymore either), and I am sure there is a bit of nostalgia in those lines, but even though there are great frameworks in other languages, no doubt, there is impressive projects, I still didn't get something that allowed such a kind of rapid development and transitioning prototype applications into production services in such a seamless manner.

I think it's also a great example of Perl being very readable despite all the ugly scripts you find out there - of course also because a big bunch of it being written by non perl developers who just needed to get a script going. Just like with JavaScript and PHP.

It's funny though how the presence of a well done web application framework nowadays is considered the killer application in a pretty consistent way. I've seen that in various languages that weren't really made for web application programming as well. There is obvious reason, as it's the agreed upon API for most applications, however I wonder if this might not bring stagnation and kind of a cycle that only allows a certain way of thinking and developing to succeed, as standards and programming languages/frameworks co-evolve.

Because it not a helpful comment. It's wrong in a lot of ways and misleading in others.

Like dragonwriter said, having coroutines in your language or a fiber library is not close to the same thing as the language having a scheduler that maps those fibers onto native threads for you. Some of the languages mentioned can't even execute multiple threads on multiple cores in parallel.

This is incorrect. Coroutines and fibers are not m:n threads. There are important implementation and usability distinctions. Besides, there are a lot of additional usability issues with bolted-on concurrency vs language-level concurrency.