It is a really nice language based off of all the tutorials and presentations I've watched. It just needs some better performance before I'll really start using it and I think there are many in the community that are in the same boat. It's a pity, because it's a chicken or the egg kind of problem. I would try to help, but when it comes to computer science I am a consumer and not a producer (I have my own large projects in my domain :)).
I'm also very impressed in how the language is turning out. It's a pleasure to write and read. I know most people really don't like Unicode operators, but I find them to be very useful. They're short and concise, and allow those writing mathematical equations to stick to their regular symbols. And for those that don't know how to do Unicode on their OS/editor, there's ASCII equivalents.
Performance-wise, it seems to be fast enough for all my personal projects, and it's getting faster every release. Is there a certain piece of code that you want to have running within a certain amount of time? That would allow you (and Perl 6 devs) to have a goal to look at, and work towards.
As a general scripting language, P6 looks nice as a lot of features such as concurrency that are aren't super straightforward (Ex: python) seem to be dead simple in P6.
In fact some things that you would do in PDL have already been added, they just currently aren't as fast as they could be.
(1,2,3; 4,5,6; 7,8,9) »**» 2
(1,4,9; 16,25,36; 49,64,81)
We often have efforts to make one VM that can support everything and they have usually failed in the past. I wonder why it failed this time?
* Parrot was intended as the runtime for Perl 6.
* Perl 6 was not ready to indicate what it needed when development started on Parrot
* Scope/Goal of Parrot was extended to other scripting languages
* Parrot started to become more and more unsuitable as the VM for Perl 6 once Perl 6 figured out what it needed
* Parrot failed to attract other clients for its VM
* The Great List Refactor in Perl 6 the year before its official release, forced a decision on whether to also refactor for the Parrot backend or not (on top of the refactoring needed for the JVM and MoarVM backend)
* The decision was no: but really, the GLR was the straw that broke the camel's back, so to say. Particularly, NFG support and async/event driven support were deemed to be impossible to implement with the state Parrot was in at the time.
* With no more clients for its VM, developers left the Parrot project
I can’t figure that out. On
It seems it maybe still moves?
2) The name's origin is really the sketch see: https://web.archive.org/web/20040203055250/http://www.oreill... and https://en.wikipedia.org/wiki/Parrot_virtual_machine#cite_re... "The name Parrot came from an April Fool's joke which announced a hypothetical language, named Parrot, that would unify Python and Perl."
The last release was from more than two years ago.
If it isn't dead yet, it certainly is feeling its age.
If someone were willing, they are more than welcome to start a fresh Parrot port of Rakudo.
Since then, Rakudo Perl 6 has become more than 100x as fast, at least for this test. And more than 250x as fast using a concurrent version of the test (which was as simple as putting a `.race` in the code).
This makes it still slower than the Perl 5 version, which uses XS (all parsing logic written in C). But the gap is closing with another round of optimizations to be merged later this week after an extensive refactor that took about 2 months. Of which you will most certainly see a report on https://6guts.wordpress.com , the blog of Jonathan Worthington.
PS: You might read this and be reasonably surprised that Rakudo Perl 6 is not, after all this, very fast yet. I have a - not entirely serious - explanation for that:
All problems in computer science can be solved with a layer of indirection.
Many layers of indirection make programs slow.
Perl 6 solves many computer science problems for you ;-)
In the future, we'll continue to solve those problems, just faster.
My guess would be that the strings had to be copied more often in the C/C++ code.
So it may be that the rate at which it gets faster has gotten faster.