7 ms·

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:

by epoch1970 11y ago

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!

mrxenu 11y ago
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.
- epoch1970 11y ago
  I'd like to use Perl 6, but after 15 years of waiting there still isn't an implementation ready for production use. Rakudo and MoarVM clearly aren't what we, as potential Perl 6 developers and users, want. They look far too similar to the many other similar Perl 6 failures we've seen. 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? Even if they do remain viable, we don't want to have to deal with separate VMs, regardless of whether they're specific to Perl 6 or not. We don't want to deal with the bugs and compatibility issues that invariably pop up when dealing with separate compilers and VMs. Like I said, we want the Perl 5, Ruby, Python, Lua, and Tcl type of experience. We want there to be one consistent implementation that's widely used and trusted. We want something proven and familiar. Unfortunately, we aren't getting that with Rakudo and MoarVM, nor from the many other unsuccessful attempts in the past.
  - sigzero 11y ago
    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.
  - mj41 11y ago
    Yes "we" want. And "we" don't understand what is e.g. this about https://en.wikipedia.org/wiki/List_of_Python_software#Python_implementations https://en.wikipedia.org/wiki/List_of_Python_software#Python...
    - epoch1970 11y ago
      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.
      - mj41 11y ago
        ... instead of splintering and delaying the adoption of the language like the many failed partial Perl 6 implementations did. I'm historian of Perl 6, a bit :-). http://www.slideshare.net/michaljurosz1/perl-family-15-years-of-perl-6-and-perl-5 http://www.slideshare.net/michaljurosz1/perl-family-15-years... Open source, volunteers, real life, ecosystem, not easy to implement so feature rich language, ... this wasn't planned.
justinator 11y ago
> 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! [0] https://github.com/niner/Inline-Perl5 https://github.com/niner/Inline-Perl5 [1] https://github.com/niner/Inline-Python/ https://github.com/niner/Inline-Python/ [2] https://metacpan.org/pod/Inline::Perl6 https://metacpan.org/pod/Inline::Perl6
- cygx 11y ago
  > or written in Perl 6 itself using half-baked Perl 6 to 5 converters Oh, I don't think that ever happened. That might be a reference to viv, which was used to implement STD (cf http://perl6.org/compilers/std-viv http://perl6.org/compilers/std-viv ). There was also the initial idea that Perl 6 could run Perl 5, but this is proving impossible. Personally, if Rakudo ever starts outperforming Perl5 for practical workloads, I believe that idea might eventually be revisited.

mrxenu 11y ago

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.

epoch1970 11y ago
I'd like to use Perl 6, but after 15 years of waiting there still isn't an implementation ready for production use. Rakudo and MoarVM clearly aren't what we, as potential Perl 6 developers and users, want. They look far too similar to the many other similar Perl 6 failures we've seen. 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? Even if they do remain viable, we don't want to have to deal with separate VMs, regardless of whether they're specific to Perl 6 or not. We don't want to deal with the bugs and compatibility issues that invariably pop up when dealing with separate compilers and VMs. Like I said, we want the Perl 5, Ruby, Python, Lua, and Tcl type of experience. We want there to be one consistent implementation that's widely used and trusted. We want something proven and familiar. Unfortunately, we aren't getting that with Rakudo and MoarVM, nor from the many other unsuccessful attempts in the past.
- sigzero 11y ago
  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.
- mj41 11y ago
  Yes "we" want. And "we" don't understand what is e.g. this about https://en.wikipedia.org/wiki/List_of_Python_software#Python_implementations https://en.wikipedia.org/wiki/List_of_Python_software#Python...
  - epoch1970 11y ago
    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.
    - mj41 11y ago
      ... instead of splintering and delaying the adoption of the language like the many failed partial Perl 6 implementations did. I'm historian of Perl 6, a bit :-). http://www.slideshare.net/michaljurosz1/perl-family-15-years-of-perl-6-and-perl-5 http://www.slideshare.net/michaljurosz1/perl-family-15-years... Open source, volunteers, real life, ecosystem, not easy to implement so feature rich language, ... this wasn't planned.

justinator 11y ago

> 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! [0] https://github.com/niner/Inline-Perl5 https://github.com/niner/Inline-Perl5 [1] https://github.com/niner/Inline-Python/ https://github.com/niner/Inline-Python/ [2] https://metacpan.org/pod/Inline::Perl6 https://metacpan.org/pod/Inline::Perl6

cygx 11y ago
> or written in Perl 6 itself using half-baked Perl 6 to 5 converters Oh, I don't think that ever happened. That might be a reference to viv, which was used to implement STD (cf http://perl6.org/compilers/std-viv http://perl6.org/compilers/std-viv ). There was also the initial idea that Perl 6 could run Perl 5, but this is proving impossible. Personally, if Rakudo ever starts outperforming Perl5 for practical workloads, I believe that idea might eventually be revisited.