It's a shame it got a reputation as being uncool as it's a very capable language and nice eco system.
I also think the criticism about unreadability is way overblow, it's what you make of it really.
It's a shame it got a reputation as being uncool as it's a very capable language and nice eco system.
I also think the criticism about unreadability is way overblow, it's what you make of it really.
The Perl community, tired of waiting for a workable Perl 6 implementation, has lavished some fine attention to Perl 5 and it's in incredible shape, but the target community, also tired of waiting for Perl 6, has largely moved on.
It's going to be tough to bring people back into the fold. Everybody wanted Perl 6, and it barely works now. The features in 6 are amazing (might even be enough to get folks to come back), but the implementations are all over the place. Perl 6 needs a couple of killer apps. The CFG work might have made handling XML stupid simple, but XML is quickly falling out of relevancy.
The transition from Perl 5 to Perl 6 might go down as one of the great language mismanagements in history. For goodness sake, it's been in design for almost 14 years! And there are really just now workable implementations coming out, but all are still incomplete, lack features, robustness and speed.
I'm also guilty of this, having been excited about Perl 6 a decade ago, but taking a wait and see approach that lasts to this day, until development settles down. I don't want to commit lots of work that will be made obsolete the next time Larry decides to change an operator's semantics.
Is it finally time to sit down and learn Perl 6?
That said, there really haven't been too many major changes to the language itself (as opposed to the implementation) in the last couple of years. I have several modules I wrote 3+ years ago, and keeping them up to date with the language has only required trivial changes in that time. You could certainly start learning the language today using the Parrot implementation with the knowledge that something better will be along very shortly.
You're just trolling and clearly haven't got a clue.
Object system with MOP, subtyping, pattern-matching, new human readable “regexpes“, grammars etc.
And for the first time in humankind it chars in string are counted by not bytes, not 2-bytes, not codepoints, not another shit, but Unicode graphemes! 2013!
I use Perl to "get shit done" (GSD) it's not sexy, it's not my main job, hell, it's barely reusable. But using Perl has been the difference between failure/late delivery and success/early delivery/under-budget more times than I can even remember.
As late as the end of last year I has hacking Perl 5 code as a side project to GSD and took a project that went from not-existing because the scope was unfeasible for the next 3 calendar years to existing and producing measurable results 3 weeks later. That work got me a promotion and then a new better job making more money (and not doing Perl work) and overall joy and happiness because I was the guy that GSD (and Perl made that happen).
You are probably thinking of Ruby. Wait, Haskell. Hold up, Erlang. Sorry, Node.js.
What is the point in spending time on any thing new?
>>given it's undeniably unambiguously spectacularly awful track record,
How many inventions throughout history fall into these category? Airplanes, Rockets?
>>and the fact that there are so many other wonderful and better languages available to spend your time learning.
So this will be one of them.
>>There's nothing in Perl 6 that makes it any more powerful (and definitely not any more easy to learn and use and maintain) than any other language.
Seriously?
Have you even read the specification? If Perl 6 sees the light of the day in say an year, it will be the equivalent of what current day 10 languages together would achieve in 10 years from now.
>>There are no jobs programming Perl 6, and there never will be.
Which is true for any new language ever.
For what it's worth, I'm pretty sure Rakudo JVM passes more tests today than any p6 implementation did at the start of the year. It's just not quite as capable or user-friendly as Rakudo Parrot yet.
It's not quite as dramatic as it sounds:
Yes, Perl6 was announced in 2000, but the actual implementation effort (both Parrot and Pugs) started in 2005.
Guess what got started a year later (2006) and isn't finished yet as well? Rust.
Is it finally time to sit down and learn Perl 6?
Learn it? Certainly. Use it in production? Not yet. The Parrot backend was used to nail down the object system. Supposedly, the mostly-working JVM backend will be used to nail down threading semantics.
Concurrently, they are developing their own VM to get rid of the semantic mismatch between the language runtime and backend VM.
But if we believe in the Osborne effect, then already from 2000 the announcement of Perl 6 started to eat momentum from Perl 5.
I was fully expecting to sit down at a machine and type "perl6" instead of "perl" to invoke early versions of the language. I was even willing to deal with semantics changes in the language for a while till that settled down.
But 5 years is a long time to wait before implementation even started and 13 years is even worse and still not really be able to sit down at a terminal and "perl6 -v".
Wait, that's not entirely true
Betty:~ lelf$ perl6 -v
This is perl6 version 2013.06-200-gee08521 built on parrot 5.5.0 revision RELEASE_5_5_0Parrot started in 2001, and there was at least one P6 implementation in the works shortly after:
https://github.com/parrot/parrot/commit/9bb281bf85088000ee40...
The Parrot backend was used to nail down the object system.
That's not how I remember things. Jonathan may have implemented the current object system on Parrot, but then he prototyped one on the CLR and one on the JVM (or vice versa), then wrote one for Rakudo based on that.
Concurrently, they are developing their own VM to get rid of the semantic mismatch between the language runtime and backend VM.
That's a very charitable interpretation of what they're doing.
The idea for Perl 6 was the same: Clean up the language, add new features at the expense of compatibility, and create a v5 → v6 transition tool. During the evolution of Perl 6, this original goal became less important. Nowadays, Perl 5 and Perl 6 are seen as two sister languages in the same family, which take inspiration from each other, but are independent. There won't be mass migrations to v6 once it “arrives” (it already did in the form of Rakudo Star). There are, however, efforts to run v5 and v6 code in the same VM.
Readability was never an issue. We follow a few common guidelines and with Perl::Tidy we get consistently formatted code.
So in principle Perl is perfect for us, the only drawback is that there is less and less library support for Perl. Most services like for example Stripe have libraries for Python, Ruby but don't bother with Perl (and I don't blame them). Third party libraries from CPAN are usually not that robust and well maintained.
But in general the Perl backend is the most robust part in our codebase and I would not trade it for any other language.
I think it would change your mind about a number of things!
If you have an experienced team and new programmers willing and eager to learn Perl, lady Luck can go for a fuck.
use Modern::Perl;
use Moose;
it's quite different thing. Perl6 may become cool, but it's a different story.(Moose is full-grown object system, with meta object protocol, nice syntax and implemented completely as a library).
Perl got a bad rep for two reasons. First, writers of boutique languages wanted a reason to feel good about themselves. Second, certain segments of the Perl community (I won't name names) insisted on writing obfuscated, baffling code that read like line noise from a modem.
The Perl community counteracted this, but there were still enough of these people out there to give it a bad rap.
In the meantime, if you're a Perl programmer who can write functional, efficient, clean and readable code, there's no shortage of stimulating work.
I just took a quick look at the manual. The class definitions look seriously verbose. I guess with some coding templates or macros, it wouldn't be too bad, though.
http://search.cpan.org/~ether/MooseX-Method-Signatures-0.44/...
http://search.cpan.org/~flora/MooseX-Declare-0.35/lib/MooseX...
[Edit: I might add -- the OO system is mature and largely inspired by Common Lisp. It is better than the "competition" among the scripting languages (says the ones with heavier background in those environments than me).]
But you didn't expect a serious answer.
You've written five(!) troll comments in this discussion -- as of now, total comments are 28. The last four trolls in 12 minutes.
In short: You're a complete drag on HN signal-to-noise and give pathetic waste-of-air language war trolls a bad name.
(All complex language environments have duct tape and baggage. And... ah, why feed the stinking trolls?)