Cool. I am glad there has been enough support and supporters over the years to push it to the finish. Compiled native executables, concurrency, async code blocks, and much more. I look forward to learning as soon as I get a chance. Hoping that companies adopt as well.
That refers to precompilation to MoarVM bytecode. You can do that manually right now, but eventually, a precompilation cache will be managed by Rakudo.
I'm really interested in this. Perl6 is so jam packed with interesting novel features, that it serves as an amazing testbed for future languages. I always feel that Ruby was a language that came out of Perl; a subset of it's features, carefully selected and implemented with the knowledge of what did not go too well with Perl.
So, like probably many people, I was very hyped about Perl 6 in the early 2000s, followed the mailing lists and so forth, but became disappointed and stopped caring when it became painfully clear that there had been no net progress for a decade.
So please excuse my skepticism, because I'm still fascinated by Perl 6's ideas and potential. But is this another "Rakudo Star" where they just take whatever current mess they have and label it "release", or is Perl 6 really finally ready now?
Just to clarify, what happens at Christmas is the first proper language release (as specified by the test suite) that will be accompanied by a conforming compiler release, ie the main focus is still semantics, not 'production readiness'.
That said, Rakudo of today is more usable than Rakudo of days gone by, though there are still issues (my personal pet peeve: parsing speed; hopefully, automatic precompilation will land in the not-too-distant future, which, would mitigate the problem).
Thanks for the clarification. So what does it mean to release "a language"? Is there a specification in addition to the test suite? Is the specification frozen from that point on? Or will it change, but only in backwards compatible ways?
The test suite is the actual specification; for the language release, it will be cleaned up of things that aren't yet ironed out.
The design documents at http://design.perl6.org/ are companion documents to the test suite, but where the two are in conflict, the test suite is authoritative.
As for changes: backward incompatible changes will result in a new language version.
I keep wondering the same, especially when perl.org mentions nothing about Perl 6. It would be really nice if they showed some sort of sign there about Perl 6. Instead all we get is Perl 5.
I have to work with a legacy Perl codebase most weeks and I've been ignoring Perl 6 because upgrading our interpreter version is difficult for a bunch of reasons to boring to go into.
I'd been naively holding out a hope that Perl 6 would improve things so I clicked on the Perl 6 for Perl 5 programmers link from perl6.org.
They added code block interpolation to strings:
#!/usr/bin/env perl6
my $number = 3;
say( "{ $number * 4 }" ); # prints 12
Really? printf is cool and useful for it's own domain. But there is a reason that languages provide interpolation. And the simplest possible example above is not one of those reasons.
I'm not going to bother convincing you that printf is not the highest form of string interpolation. Seems like you've got your bases covered pretty well.
I never said printf is the highest form, nor did i imply it. If you think i did imply that, and you consider it to be ridiculous, then it would behoove you to ask if i did mean to imply that or not; instead of assuming that your interpretation of my words is fact and i am being ridiculous.
I consider printf an acceptable form of string interpolation, nothing more.
As simple as writing a Perl6 signature for your C function. A proper solution for deploying your own libraries has yet to arrive (you can look up library names at runtime and compile code via the module manager, but imo it's still rather ad-hoc).
They still have no idea how a fast dynamic language should be designed. To their advantage python does neither. Ruby does know, but doesn't get along with to well. Only PHP got their act together with 7.0.
I don't think so - it's still 'slower than similar languages with similar features', so not sure what difference it makes that there aren't many languages to compare against, if when we do compare it's still slower.
I'd be interested to see what features there are that make the system slower in general, even when they aren't being used. I did a lot of work in my PhD on making odd features not affect the performance of Ruby code when they aren't being used.
> I'd be interested to see what features there are that
> make the system slower in general, even when they
> aren't being used. I did a lot of work in my PhD on
> making odd features not affect the performance of
> Ruby code when they aren't being used.
I suspect you would be warmly welcomed, and meet many interesting people, in the Perl6 IRC channel, especially if you lead to a link to your PhD.
And the thing is, these features are being used all the time, because the core language is built out of them. If you want to see how a language which is not built on these things runs (on the same vm implementation, I might add), I suggest you try nqp :-).
Don't forget about the grammar engine - the parsing speed is only in the hundreds as measured in lines of code/s, which is a concern for script startup.
I've come up with rather 'creative' workarounds[1] until a more proper solution arrives...
Not directly, sadly. I can make an educated guess though, since Perl 5 has since adopted many of the features thought up for Perl 6. Particularly try looking at its OO features, in regards to roles, parametrized roles, reflection and automated attribute/constructor creation. I can't say with confidence, but i suspect the number of languages having all those features is very low, if existent, and the number of languages with some of these features is also low.
Do note that you will have to look closely and follow references to make sure you have a full picture of understanding, since at first glance many of them seem simple, but turn out to offer considerable depth.
I'm not sure if Perl 5 has adopted these features, but these features have been implemented in Perl 5 via modules [0], which is excellent - but sadly, this is vastly different than being in core, or even having the modules in core. I don't even think you can set default attributes in Perl 5 methods. You still have to pass around the object, shift it off - a whole lot of boilerplate.
Something as simple as that has been proposed, but it's not been in production for Perl 5. (without Moose and friends, of course)
Really, there hasn't been a terrible amount of new features in Perl 5 - and certainly not a new model for OO. Moose is great! And the constant release of CPAN modules is also wonderful, but the core of Perl 5 is full of dragons, which makes backporting features from Perl 6 hard to do in core - and perhaps a good argument can be made against doing that. Example: Moose is a very successful project, but thee given/when statement in the core of Perl was a failure.
There's also the perl6 specific benchmark https://github.com/japhb/perl6-bench but I have no idea where they post their results to. It used to be a gist or IRC.
Note that to fully take advantage of it, the optimization layer above it that does type specialization also needs work (eg some optimizations were lost during the 'Great List Refactor', a semantic change that was set as one of the blockers for the 6.0 release).
So much good stuff. I really like the kernel+distribution idea and thinking about lexer/parser and "just adding stuff to that" like the example of adding Ruby ?! syntax.
When will a traditional interpreter written in C and running just about everywhere be available for Perl 6?
All of the successful scripting languages have one: Perl 5 and earlier, Python, Ruby, Tcl, Lua, PHP, and even UNIX shell scripts.
Yet when it comes to Perl 6, we just don't see that.
The Perl 6 community has spun its wheels time and time and time again with half-baked interpreters written in an obscure language like Haskell, or written in Perl 6 itself using half-baked Perl 6 to 5 converters, or targeting the .NET CLR or JVM, or targeting very obscure and limited VMs like Parrot or MoarVM.
It's no wonder that Perl 6 hasn't really gone anywhere after 15 years. They've done everything but the one thing they should be doing if they want success: implementing a traditional interpreter using C that runs just about everywhere!
I don't quite get your point. MoarVM was created specifically for Perl 6, it is written in C and just works. JVM support in Rakudo is just added bonus and you are free to ignore it (like most users do).
For 99% users "Perl 6" will mean just "Rakudo + MoarVM" which seems to be exactly what you're asking for.
Note that MoarVM is nothing like Parrot. Parrot was a failed project which intended to bring universal VM for all dynamic languages. Obviously, too wide project scope resulted in broken and unmaintainable implementation.
MoarVM is made just for Perl 6 and intends to avoid repeating its predecessor's mistakes.
> Rakudo and MoarVM clearly aren't what we, as potential Perl 6 developers and users, want.
Why not? A core implementation with its own VM (MRI+YARV for Ruby from 1.9 on, for instance) seems to be pretty common for languages.
> Like I said, we want the Perl 5, Ruby, Python, Lua, and Tcl type of experience.
But that's exactly what Rakudo + MoarVM offers. For the Ruby comparison, Rakudo is analogous to MRI, MoarVM is analogous to YARV.
> We want there to be one consistent implementation that's widely used and trusted.
And why can't Rakudo be that implementation?
> We want something proven and familiar.
Well, clearly, it won't be proven till its been around for a while in production use, and won't be familiar till you've used it for a while. But I don't see any reason that Rakudo (which is used for some things exposed to the public now) can't be the thing that ends up "proven and familiar"?
> Unfortunately, we aren't getting that with Rakudo and MoarVM
Maybe you should do a little research? Rakudo is backed by the Perl foundation. It's not going away and neither is the MoarVM.
Rakudo + MoarVM is going to be "it" going forward I would think. I guess we'll wait and see. That doesn't mean that other compilers won't come along because that is one of the benefits of Perl 6. All the languages you mention have different versions out there. The only one that doesn't is Perl 5 and that's because only Perl can parse Perl. That's going away with Perl 6 and that's good. Rakudo+MoarVM is great. It still leaves the door open for genius to shine.
Rakudo + MoarVM is exactly what potential Perl 6 developers want. Everything else is just gravy.
I have no idea if Perl 6 will "take off". I hope it gains traction. Watching Larry Wall got me interested enough to install it and start learning it anyway.
How are we to trust that Rakudo won't go the way of Pugs, or that MoarVM won't go the way of Parrot, leaving us in a lurch?
Some people will tell you to trust them. I, on the other hand, base my expectations on the history of the project and the actions of the people involved. I don't believe you can turn 15 years of disappointment and underperforming into something usable based on an arbitrary deadline enforced by yet another marketing announcement.
There obviously is some marketing involved, but in principle, this is less about Rakudo, and more about Larry freezing the 6.0 language version.
One can hope that development focus will then switch from semantics to things like stability, deployment and performance, ie the things you strongly advocated for years ago.
I guess we'll see if it's going to happen that way...
While it may be technically true that "Perl 6.0 released!" is an accurate headline if you define "Perl 6.0" as "the test suite for the 6.0 language version", I suspect that almost everyone reading that headline will expect to see a stable language implementation.
Given the reception to the past year's worth of discussion around "Get ready to party", it seems irresponsible to me to continue with these semantic distinctions, as they're lost on the intended audience.
That's a perfect example of a much better approach, exactly like I was talking about earlier.
There's CPython, the main Python interpreter. It's quite traditional in architecture, and is written in a very portable subset of C.
It's the Python implementation that pretty much all Python developers and users happily and successfully use.
Then there are the experimental or niche Python implementations. They augment very specific and isolated use cases, instead of splintering and delaying the adoption of the language like the many failed partial Perl 6 implementations did.
It should be evident that the Python approach is better than the Perl approach. We've been able to use Python 3 in production for many years now, while Perl 6 still isn't usable.
I would almost think that what you like in Python is now available for Perl 6 (plus loads more!):
You've got MoarVM, which is just like CPython
But if you want a different backend - great! Don't have to wait for MoarVM - the folks at MoarVM didn't wait for Parrot to solve their problems (or they'd still be waiting). For example, use JVM, just like Jython.
This is a stark difference to the situation of Perl 5, where there is only one interpreter, and there's little, if any chance of another. There's no Perl 5 language specification (as there is in Perl 6), except the Perl 5 interpreter. Only Perl 5 can parse Perl 5.
Perl 6 got so many things right, it's phenomenal.
Getting things right takes time, and it only happened because so many things went wrong.
It doesn't matter how many things Perl 6 got right when they got the most important thing completely wrong: the availability of a usable and reliable implementation!
> with half-baked interpreters written in an obscure language like Haskell
Because the author thought it to be fun. You know, hackers and all.
> or written in Perl 6 itself using half-baked Perl 6 to 5 converters
Oh, I don't think that ever happened.
You may be thinking of NQP? Which is still a Thing, and it's what Perl 6 is written in, which is amazing.
There was also the initial idea that Perl 6 could run Perl 5, but this is proving impossible. This is done now using the Inline::* modules, which will use say, the Perl 5 interpreter. [0]
So, there's one for Perl5 to allow for compatibility with Perl 5 modules, but also for Python[1], and most likely for x language. That's awesome!
Of course, the inverse is true, too. You can call up Perl 6, from Perl 5![2]
> or targeting the .NET CLR or JVM, or targeting very
> obscure and limited VMs like Parrot or MoarVM.
Targeting .NET or JVM is also a good idea! Many languages do it. The general idea of Parrot shares a lot of interesting ideas with .NET - I almost want to say Parrot precedes .NET. The April Fools joke certainly did. If it didn't, Parrot was certainly inspired by .NET - or it was just an idea that was in the air at the time. Good idea!
