User: Password:
|
|
Subscribe / Log in / New account

Chromatic: Goodnight, Parrot

Chromatic: Goodnight, Parrot

Posted Feb 11, 2013 18:23 UTC (Mon) by raiph (guest, #89283)
In reply to: Chromatic: Goodnight, Parrot by rahulsundaram
Parent article: Chromatic: Goodnight, Parrot

I like and follow Perl 6.

Rakudo is the leading Perl 6 compiler. Imo, at least in the short term (2013), where Rakudo goes, Perl 6 goes.

1. Getting to Rakudo on JVM
===========================

* First, I recommend folk consider reading the outstanding blog post rahulsundaram linked.
* http://pmichaud.com/2012/pres/yapcna-perflt/slides/slide3... is a slide from a fun 5 minute lightning talk (video at http://pmthium.com/2012/09/a-rakudo-performance/). This slide shows the ratios of the four languages used to implement the Rakudo compiler: Perl 6, NQP (a mini Perl 6), C, and PIR (Parrot Intermediate Representation) code. The sliver of PIR is a few weeks from being driven to zero.
* Once the NQP port to JVM is done the Rakudo Perl 6 compiler can be ported (jnthn clearly expects the whole Rakudo to be ported by yapcna, Austin TX, June 3-5.).

2. What Rakudo on the JVM means for Rakudo
==========================================

* As http://perl6.org/compilers/features shows, Rakudo is deficient on Unicode and related items, native types, and threads. (It's arguably ahead of Perl 5 on all three of these, but it's deficient relative to the Perl 6 spec.) Rakudo devs claim these had been held up by problems related to Parrot and that the JVM will provide a suitable backend to get these functionality pieces nailed down. Note that JVM functionality that enabled completion of the Perl 6 spec and Rakudo implementation, not speed, was the primary reason for porting to the JVM.
* Larry Wall recently said that speed is the #1 blocker of mass adoption of Perl 6. Although Rakudo has recently closed the speed gap in most regards compared to Niecza (another Perl 6 compiler that targets .NET) it's still dog slow in many ways. However, there are reasons to believe Rakudo on the JVM may be faster, perhaps an order or two magnitude faster, than Parrot. (chromatic seems to dispute this.) Imo, if Rakudo substantially speeds up it will be a game changer.

3. What a fast, complete Rakudo will mean for Perl 6
====================================================

Larry recently said he hopes to publish a Perl 6 equivalent of "Programming Perl" (the bible for Perl 5) around the end of this year. In mid 2009 I predicted Perl 6 would reach a generally robust state around the end of 2014. I think I was about right and folk will begin adopting Perl 6 in earnest during late 2014 or early 2015.


(Log in to post comments)

Goodbye, duct tape

Posted Feb 12, 2013 0:10 UTC (Tue) by man_ls (guest, #15091) [Link]

So, what are the implications of depending on two different proprietary virtual machines for Perl6? I guess that the JVM could be said to be Free software if one counts the OpenJDK, but then you have to explicitly target the OpenJDK -- and trust that Oracle keeps it open, or target another JVM and expect that Oracle does not sue it for some bogus reason.

There are many other languages that run exclusively on the JVM, but they are mostly esoteric -- the most popular of those seems to be Scala.

There are other issues like memory usage and startup time. Perl5 used to be the duct tape of the internet; requiring a JVM for Perl6 will make it unfit for that particular purpose (which for me is filled nicely by Python 2 anyway).

Goodbye, duct tape

Posted Feb 12, 2013 1:18 UTC (Tue) by raiph (guest, #89283) [Link]

> So, what are the implications of depending on two different proprietary virtual machines for Perl6?

Huh? Perl 6 has never depended and will never depend on anything proprietary.

Just because you can install non-free device drivers on a Linux system does not mean Linux is now suddenly dependent on that non-free software. It just means the Linux developers have not gone out of their way to stop people doing what they want to do.

If folk want to run Perl 6 on the JVM maybe to compare it with current options (Parrot, mono, Javascript) they will soon be able to. And that's a good thing.

> There are other issues like memory usage and startup time.

Indeed. The 2013 focus on speed and memory is needed. But, as even the originally very skeptical dskoll specifically recognized in this thread with a "wow" after he acually tried it again, Rakudo is improving on about the pace the devs suggested it would around 2 years ago.

Having it both ways

Posted Feb 12, 2013 11:32 UTC (Tue) by man_ls (guest, #15091) [Link]

I am missing something. In my simplistic reading, there are two leading Perl6 compilers; one (niecza) targets the CLR and thus the .NET runtime, which is proprietary (although there is a Free software reimplementation called Mono, the spec is still proprietary and patented by Microsoft). The other (rakudo) targets Parrot which apparently is an evolutionary dead-end and has lots of performance and encoding problems; the way out of these problems is Rakudo on the JVM, which is again proprietary or depends on a lawsuit-happy company (Oracle in this case). I see no mention of a JavaScript backend on the front page of either compiler.

Given that there isn't a single official runtime, I see a maze with just dead ends and proprietary options. It is like the situation with Linux a few years ago when graphics drivers were either unusable or proprietary; the community worked on it and now we have very good free drivers for popular boards. Is the Perl6 community similarly worried, or happy with the situation?

Having it both ways

Posted Feb 12, 2013 12:03 UTC (Tue) by epa (subscriber, #39769) [Link]

Oracle's JVM may be proprietary software (depending on what you download), but there are plenty of free virtual machines to run the language. It's not an open standard in the sense of being collaboratively developed by a standards body, but nor are lots of good and free things (X is an open standard; Wayland is not). More or less the same remarks apply to .NET.

Having it both ways

Posted Feb 12, 2013 13:50 UTC (Tue) by raiph (guest, #89283) [Link]

> I am missing something. In my simplistic reading, there are two leading Perl6 compilers; one (niecza) targets the CLR ... other (rakudo) targets Parrot ... [and soon] JVM ... I see no mention of a JavaScript backend

Indeed you are missing something. While you didn't see a mention of a JavaScript backend, it's plausible pmurias will have it done before jnthn completes the JVM port. And what about swarley's Go port?

Goodbye, duct tape

Posted Feb 12, 2013 2:31 UTC (Tue) by wahern (subscriber, #37304) [Link]

I think you're unintentionally conflating the JVM with the JDK.

A nice JVM is http://jamvm.sourceforge.net/. It's not the gargantuan, unportable mess that other JVMs are, which typically aim for speed first and sanity later.

Something like JamVM should also be quick to start up, too. But I completely agree that common JVMs suck for general scripting tasks. Solaris, I believe, tries to optimize this by sharing JVM instances. But "scripts" which require the JVM are still dog-slow.

Goodbye, duct tape

Posted Feb 12, 2013 2:33 UTC (Tue) by wahern (subscriber, #37304) [Link]

It begs the question, though, whether Perl6 on the JVM will require the JDK.

Goodbye, duct tape

Posted Feb 12, 2013 11:37 UTC (Tue) by man_ls (guest, #15091) [Link]

That is a very good point; it may address the speed and memory issues. It is not a very active project though; last release was in January 2010. But my argument as to "proprietariness" remains similar: the official JVM is proprietary and heavily patented by lawsuit-happy Oracle, which has sued other implementors (Google). If I had to take the decision to port to the JVM I would not take it lightly.

Goodbye, duct tape

Posted Feb 12, 2013 14:00 UTC (Tue) by raiph (guest, #89283) [Link]

Porting to the JVM is a pragmatic short term call not a strategic long term one.

As jnthn recently said:

"The way Perl 6 progresses in terms of its language design is thanks to people using the bits of it that are implemented so far and providing feedback. While a great deal of the language spec is now very stable, that has come after a great deal of feedback. We’ve some areas where we’ve not been able to build and try out certain things on Parrot, a big one being concurrency. Parrot lacked any kind of threads for years, and what it has now is not a great basis for building much on, sadly. That still leaves aside async operations, which should be considered in with all of this. Meanwhile, the JVM can offer well tested, widely used, battle-hardened building blocks for looking into these things, which will allow us to focus on the Perl 6 aspects of things without having to worry (much) about hitting VM bugs."

Once the JVM port is done I've no doubt that ports to other backends will start landing, and I've no doubt most will be non-proprietary.

Goodbye, duct tape

Posted Feb 13, 2013 19:34 UTC (Wed) by wahern (subscriber, #37304) [Link]

I believe the reason it hasn't had a recent release is because it's feature complete and stable. It's not stagnant, just a well executed project.

However, it implements an older spec of the JVM, v2 instead of "Java SE 7 Edition" (i.e. v3). But if you just want a nice, portable JVM, it's a good target, or at least a good place to start.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds