I hate to repeat a comment of mine, but for the sake of emphasizing just how different Perl 6 is, here's a version of Fibonacci in Perl 6:
subset NonNegativeInt of Int where * >= 0;
proto fib (|) is cached returns NonNegativeInt {*}
multi fib (0) { 0 }
multi fib (1) { 1 }
multi fib (NonNegativeInt $n) { fib($n - 1) + fib($n - 2) }
say fib(100)
I expect most would either use plain 'ol imperative code if that's what they're used to (from Perl 5), or do it with the sequence construction operator (triple dot):
my @fib := 0, 1, *+* ... *;
From what I've seen so far, Perl 6 code is still similar to Perl code. Presentation snippets tend to focus on specific new features and should not be taken as representative samples of real-life code.
My intention wasn't to make people say "wow, I know Perl 5 but now I'll never figure out Perl 6," but rather to illustrate some new features in the context of a familiar example. :) In fact, the above-mentioned presentation introduces P6 features by gradually expanding upon P5 code, showing that you can gradually grow into the language.
Another one of Johnathon's excellent presentations goes into depth about the kinds of optimizations being made in MoarVM: http://jnthn.net/papers/2014-yapceu-performance.pdf
If you're familiar with another OO dynamic language like Perl 5, Python, or Ruby, you can probably get up to speed more quickly in P6 than Haskell, and you can gradually introduce more advanced P6 ideas as your ability grows.
But yeah, I'd still recommend you learn Haskell... and Erlang, and Lisp... and...
You wouldn't.
That is to say: You might learn Haskell if you want do write 100% functional code, and Perl 6 if you want to write imperative/procedural/OO code with functional idioms mixed in here and there (in places where that facilitates a more elegant approach).
I.e. the two languages are not really competing in the same category.
Even though Perl 6 has first-class code objects, closure semantics, basic pattern-matching, lazy lists, immutable data types, and so on, a lot of the syntax and default behaviors are geared towards stateful programming styles, which - combined with the lack of static typing - means that strictly sticking to functional programming in Perl 6 will be awkward and you'd be better off using a dedicated functional language if that's what you want.
If you think that you need a revolution to get to a desirable state, Haskell is for you. If you prefer not to have to re-wire your brain, give Perl 6 a shot.
Or, of course, do both :-)
I've been a professional Perl developer for a long time, and I've followed Perl 6 since the first announcements. There is some impressive and really interesting work going on there, but from my perspective it seems to be a new language rather than a new version of Perl. I fully support the development of Perl 6, but I really wish the name would change to something that doesn't involve Perl.
It seems like the usage of the name "Perl" has actually done a fair amount of damage to the Perl 5 language, and the Perl community. Non-Perl programmers don't understand what is happening. To them, Perl 6 is just the next version of Perl, and the long wait for Perl 6 is a sign of problems within the Perl community. To many of them when Perl 6 comes out it will be the obvious choice to use for new projects, since the name implies it is the new version, even though the reality is that Perl 5 will likely be the correct choice for a large number of new projects for many years to come.
Perl has become a punching bag by the uninformed who speak about it as a dying, irrelevant, read-only language. Perl 6 carrying the Perl name has helped reinforce those views, allowing them to incorrectly speak of the lack of new versions, the future versions breaking backwards compatibility, and many of the changes being a strong admission that something was very wrong with Perl 5. When Perl 6 is released there will be a lot of confusion and the common belief will become that Perl 5 is even more irrelevant.
So, why not stop using the name "Perl" and call it something different? Wouldn't it be better for everyone if Perl 6 was regarded as a new and separate language?
It's both, really. If you use it (and after a while of getting used it), it just feels like perl.
> I fully support the development of Perl 6, but I really wish the name would change to something that doesn't involve Perl.
Well, in retrospect, it might have been a good idea to name it something else entirely. But that's too late now, and nobody has been able to come up with a good new name anyway. And the "Perl" brand is still very strong, so we are loath to give it up.
Finally, Perl 5 has many unsolved problems that will hinder its evolution in the upcoming decades. Once Perl 6 has become as fast and mature as Perl 5 is now, we want to provide the future that's closed to Perl 5.
The weakness of Parrot VM was it's ambition - to be an efficient VM for all dynamic languages. This may have seemed possible in the past but recent work (i.e. v8, luajit2, etc) has invalidated that; it's much better (and much easier) to build a VM for a specific target than for all possible targets, as there are simply fewer points where you need abstraction. (For instance, NaN is false in javascript boolean context, but not in Perl6). More importantly, MoarVM has been designed and developed by a small set of developers applying all the lessons learned from parrot, while parrot was in many ways an experiment by committee.
Mostly that MoarVM developers could learn from all of Parrot's successes and mistakes, while not carrying any of the historical baggage. That means cleaner design, less memory footprint, faster execution.
> and why were we stuck at Parrot for so long before giving it up?
Rakudo works on Parrot. Why drop support for it?
Once you frame the question that way, the answer becomes obvious: because there hasn't been big changes to the code generation yet that would make continued parrot support painful. Once we reach that point, the situation will be reconsidered.
Getting the right trade-offs there was no easy task.
Another challenge was how to make the type system and built-in types so that stuff works intuitively for a Perl programmer, and still has sane rules in the type system.
Finally a thing that's surprisingly tricky is precompilation. You need to serialize types and objects, and then another compilation unit comes, and needs to modify something, so it claims ownership over a piece of serialized data or code. There are way too many nasty corner cases in that area.
Or in other words what is still left to do that is not just routine work, but actually might not be possible (or not possible in the timeframe)?
Or in even more informal language, what's the holdup? :)
In general, I think there's huge latent demand for a relatively fast, "next-gen" scripting language, as even Python is showing its age in terms of the programming styles it doesn't support, and has no plans to.
Will it really be released by the end of this year? Obviously the history of this project induces a healthy bit of skepticism. My two cents would be that the dev team should just release it next week and fix the inevitable warts gradually.
On a related note, should I, as someone who does not know Perl, bother learning Perl 6 yet? Or is it likely to change a lot before release?
Barring that, there are three major technical things we want to tackle before the release: native, shaped arrays (compact storage of arrays/matrices of machine-sized types), the Great List Refactoring (GLR; mostly about speeding up list iteration and making things more consistent), and some Unicode-related tasks.
Any of those might prove more difficult than expected. I personally see the biggest risk in the list refactoring, because lists are rather central to the language as a whole.
I think that the initial port of Rakudo to JVM was done by jnthn single-handedly. I don't know how PyPy compares with JVM though.
At any rate I think that an implementation of 6model (the basis for Perl6 objects) on PyPy would likely be too slow to really make it worth the effort. ( If you really want to try I'm sure there are People who would help you )
There are currently 3 backends for the Rakudo implementation of Perl6: Parrot, JVM, and Moar.
The fastest one currently is the one designed to meet the needs of Rakudo: MoarVM. (in many benchmarks) It of course makes sense that a VM designed for Perl6 would work better for Perl6.
Some of things it does:
* type specialization. It looks at repeated executions of a piece of code, and if the type of a variable or parameter is stable, it assumes it'll be always that way, and specializes the code for that (for example, always picks a method from the same class). And of course it inserts a guard clause to ensure that if the type should change, it takes the slow (but correct) path
* inlining
* container removal. In Perl 6, things generally become mutable by being inside a container (think pointer), and if the specializer finds cases where that's not needed, it generates better code for them
* reachability analysis and elimination of allocations are being worked on, iirc.
http://design.perl6.org/S12.html#Multiple_constraints
It concludes with:
> As a first approximation for 6.0.0, subsets of enums are static, and other subsets are dynamic. We may refine this in subsequent versions of Perl.
http://use.perl.org/use.perl.org/articled5d3.html?sid=00/07/...
Just for reference my company's software is all built with Perl 5 and runs great. Most of the execution time is within the database calls so there is no impact from using Perl over a marginally faster runtime like Python or Java.
I'm not trying to be argumentative, but the last realistic comparisons I did had Perl running quite a bit faster. For example comparing ack to grin, which are very similar projects in Perl and Python respectively...at the time, admittedly several years ago, ack was an order of magnitude faster than grin. I also wrote a few log parsers in both Perl and Python (at a time when I was working in a Python shop, so they preferred everything be done in Python). The Perl parsers were much faster than the Python variant, for exactly the same work (again, an order of magnitude difference). Perhaps this is just an example of Perl's domain of expertise...processing text is a big part of its origin story, and has always been a big part of what people use it for. Or, perhaps Python has made remarkable performance improvements in those intervening years. I haven't worked with Python in that time, so haven't followed development. Perl 5 has gotten faster in that time, too, though, so I'd be surprised if Python is dramatically faster for the same real world tasks.
What is fast is string handling and log mangling. Perl was created for that; everything else is bolted on.
perl6 has much more features than perl5, it's a completely different world. I wouldn't call that bloat.
I think there's a good chance that Perl6 will not only become 'relevant in the large', once again, but also, once again, be a driving force in the overall improvement of our industry.
It never made any sense to me that some people would rather see Perl stagnate and die and complain from the peanut gallery than they would help it move forward.
That's not entirely fair. Some of us doubters spent a lot of time, energy, and resources trying to help it move forward before deciding it wasn't worth it.
The problem I described is when people actually prefer to kill a project through stagnation than to help it move forward - often by active resistance to any real change. Living projects periodically change. Even goals like improving speed often require redesigns and replacements of old components. When the process of change and renewal is shut down or nobody contributes to it, everyone starts wandering off and the project dies.
I'm not a developer of Perl. I'm sure all your input was appreciated by someone. It's a personal decision whether you want to keep putting in that effort, or switch to other tools. I just don't see any sense in attacking Perl 6 any more.
Meanwhile, Perl 5 will have its 22.0 release this May.
We are upvoting non-news? It'll be a great announcement if they ship it, but it's just hype now. Also, consider all they are announcing is a version for developers.
"Larry has announced that the Perl 6 Developers will attempt to make a development release of Version 1.0 of Perl 6.0 in time for his 61st Birthday this year and a Version 1.0 release by Christmas 2015."
Do people no longer write code? Because if they do, some of them might might choose to use Perl 6 for that, and that's all the success a programming language can hope for.
I see no reason why Perl 6 can't find its niche among people who prefer the Perlish over the Pythonic way to approach problems, but want a modern, consistent, cruft-free language (which Perl 5 is not).
I'm not against Perl or its evolution, but I don't see the point to learn this today when you have so many better scripting language alternatives with established community and rich libraries available.