perl6 and Parrot 0.5.2 Released

mAriuZ writes "Bob Rogers just released Parrot 0.5.2. This monthly release includes a couple of interesting new features. First, we've bundled Patrick Michaud's Rakudo (thats the implementation of Perl 6 on Parrot) such that you can type make perl6 on Unixy platforms and make perl6.exe on Windows and get a working standalone Perl 6 binary. This is experimental and we hope to iron out some installation and deployment issues by next months release, but it was important to demonstrate our progress. The second new feature is a toolkit for starting your own compiler. Max Mohun built a prototype several months ago, and we've added a stripped-down version for now that builds the skeleton of a compiler for you using the Parrot Compiler Tools. I mentioned the LOLCODE compiler in What the Perl 6 and Parrot Hackers Did on Their Christmas Vacation; this is how Simon and Company were able to get LOLCODE up and running so quickly."

Comments

Perl 5 to Perl 6

[cynicsreport]

In the time it took to develop Perl 6, other programming languages have been conceived, implemented, used and abandoned.
While I am relieved that Perl 6 is finally showing signs of life, I have concerns:
1. Can Perl 6 take the place of Perl 5?
Perl 5 is integral to Unix/Linux systems; it is pretty much taken for granted. To switch to Perl 6 seems like a monumental task. It seems more likely that those wishing to use Perl 6 will have it installed along with Perl 5 (not instead of).
2. Did it take too long?
Perl 6 received a fair amount of hype when the project began. With no realistic timetable publicly announced, it seems that people forgot or gave up on it. In fact, in that time Python has become very popular; I wonder if it has taken some of the 'market share' that would have otherwise gone to Perl 6.
3. Is it any good?
Perl 6 was supposed to be the "community's" rewrite of Perl 5. The word 'community', when it comes to programming language design, is a bit concerning.... It almost sounds like a euphemism for 'committee'. And that makes me shudder. I once heard the expression "A camel is a horse designed by committee." And I can think of a few programming languages that go along with that saying (No offense to camels).

Either way, I will download it. I will use it. I will see if it's any good. And, despite all of the issues, I am glad it's finally here!

Re:Perl 5 to Perl 6

[synthesizerpatel]

1. No. Nobody will care about Perl 6, plus, it's not integral to Linux/Unix. The reason Unix is popular is that you have options. Perl works if you like it, but you don't have to use it or be aware of it.

2. It took far too long. They had books out about Perl6 after the announcement, consisting of reprints of whitepapers and proposals.. Years later, still no perl 6 for real.

3. Nobody will care how awesome Perl 6 is. The audience of Perl 6/5 doesn't care about single binding vs multiple binding objects -- they won't even get out of bed to have an argument about strongly typed languages vs. weakly typed languages. They just like easy programming -- the metric of Perl 6's success is how much it caters to lazy people. If you want glue, use perl, if you want cement you use something stronger.

(I was a Perl guy for 15 years, used to love it, now Perl and Ruby both look like line noise that's been encrypted -- compared to my new girlfriend, Python.)

Re:Perl 5 to Perl 6

[ajs]

Nobody will care how awesome Perl 6 is. The audience of Perl 6/5 doesn't care about single binding vs multiple binding objects -- they won't even get out of bed to have an argument about strongly typed languages vs. weakly typed languages. They just like easy programming -- the metric of Perl 6's success is how much it caters to lazy people. If you want glue, use perl, if you want cement you use something stronger. I care how awesome Perl 6 is. I care about all of the language design points you raise. I am a current Perl 5 user and will be a Perl 6 user. I'm a minority, and I know it.

However, it's also true that Perl 6 has been designed to cater to both crowds, and that's one of the myriad reasons it took so long.

while =STDIN {
  say;
}

Is just as short and sweet as it always was in Perl 5, but if you want to get under that hood, you can.

(I was a Perl guy for 15 years, used to love it, now Perl and Ruby both look like line noise that's been encrypted -- compared to my new girlfriend, Python.) Frankly, I think Python is a great little language. It filled the gap between Perl and Java very, very nicely (though Groovy also does that now). Perl 6 won't replace Python, but I think it will become the way people write medium-to-large systems in certain niches, replacing some C++, Java, Python and Perl applications. PHP is probably safe where it is as a rapid Web prototyping system. Ruby will likely evaporate (being largely absorbed into the feature-set of Perl 6) but there's a large Rails community that will take some time to convert even if Rails is directly portable, and it probably will be at some point.

Perl 5 is a toy language (it's arguable that CPAN is Perl 5's most valuable feature, and that without it, Perl would not have a community today). It's a great little toy, and powerful in its own right, but it's a toy. Line noise? Eh, perhaps, but I started as a C programmer, and thus was trained early in how to write code in an unmaintainable syntax in a maintainable way. The largest problem is that Perl is far easier to be effective in than C, and that breeds long-standing unmaintainable code on its own. That problem is, unfortunately, the curse of all easy languages to use (PHP and Python suffer equally there, though Python has been somewhat stricter on not allowing the bad code to become community code). Perl 6, on the other hand is not a toy, and I'll use it for very different reasons.

About Parrot ..

[systems]

Does Parrot work like the .Net framework in the sense that libraries say writen in Perl can be used in Python or Tcl! (note that Tcl is a completly different paradigm than Perl or Python)

I do know that for .Net to achieve this it forces languages to implement certain set of features, and that the libraries to be shareable to be written using a subset of the CLI or CLR. Are there any Parrot plans for something similar, the idea of a single Libarary archive for all the free languages out there sounds amazing. Groovy is doing something exactly this with Java.
Anyway, I read the faq and this seems unlikely to be planned for, but maybe someone else knows better!

Re:About Parrot ..

[Jugalator]

Yes.. but.. (from what I understand) unlike .net and java, you will be able to compile binary versions of your applications for distribution Well, Parrot is actually much like the .NET VM. One reason Parrot was invented according to their own FAQ was because at the time, the .NET VM hadn't been released. Indeed, the .NET CLR now supports dynamically typed languages by making use of the Dynamic Language Runtime, like IronPython and IronRuby already use.

Compare the Parrot PIR and PASM intermediate languages to the .NET IL language. Basically, Parrot does a similar thing as the .NET Dynamic Language Runtime running on top of the Common Language Runtime (and yes, Parrot will support multiple languages like .NET too).

At the time when Parrot was started, there was basically only Java widespread for dynamic language support, but the Java VM did not support dynamic languages well.

So I'm not sure this is the revolution you're looking for. Here you have some example usages: http://www.parrotcode.org/examples/ There's nothing special about natively run code here in the sense you seem to be talking about. The point of the Parrot project is rather about uniting many languages behind a single bytecode that their interpreter can "compile" to a form that can be run by it, much like the concept of .NET. One can also check this out: Is it too late for Parrot VM? which pretty much repeat what I said.

Re:BFD?

[DAldredge]

This isn't reddit - some of use have jobs and use Perl to make those jobs easier. We can't afford the language of the month fads that pervade that other site.

Not "Community". More like Larry's Magnum Opus.

[Anonymous Coward]

The supposed "community" rewrite started with a bunch of actual community requests, which Larry Wall then waded through increasingly slowly, pretty much taking the little bits he liked, then proceeded to add on a huge set of requirements that he cared about personally (and to be fair, probably the core Perl devs too). Things like extending regex into a full grammar that could parse Perl and be used to extend the language. And linguistic and abstract gumbo like how regular control flow (returning for a fucntion) was some specialization of the exception mechanism.

Dont get me wrong, I loved reading the Apocalypses. I thought, "wow, Larry really has a deep vision of where he wants things to go". I thought is was pretty neat and hoped to play with it. But in my mind I was thinking that Perl 6 would keep to the general strengths of Perl, in that it was FAST to get done what you wanted.

That was YEARS ago. I'm abstractly interested but have no desire to use Perl anymore. The "community" rewrite was sprinkled with requests that addressed what people were actually trying to do (certainly NOT trying to parse Perl, NOT taking 6 years, and NOT trying to get a VM running), they were a hodgepodge but every submission was pretty much focused on a narrow problem and in themselves would be achievable in less than 6 years. Instead it's become Larry's Odyssey. I also no longer harbor any expectation that Perl 6 will be FAST (to learn incrementally, to develop a quick solution, or to execute). Great if it does, I just don't believe or care.

I wish Perl 6 had been the 'shortsighted' approval of perhaps a quarter or a third of the RFCs, rolled out within a year or two. Maybe Perl 7 could have continued this stupid trajectory it's on to irrelevance. More importantly, the volunteer development and donations would be much higher because people would actually CARE about the progress and the features.

This wasn't what it should have been. It is like this because Perl 6 was overrun by Larry's priorities instead of the community's.

Re:Not "Community". More like Larry's Magnum Opus.

[mr_mischief]

If you're looking for incremental improvements, you might take a look at Perl 5. In 2001 there was 5.6.1 and now there's 5.8.10 with many improvements.

Want a few examples of improvements? The regex parser recently went from mostly recursive to mostly iterative. it also has many new features and has other efficiency gains. Unicode handling exists and continues to get better. Several things take less memory than previously. Lexically-scoped pragmas can now be implemented in pure Perl without resorting to C. A simpler and clearer way to handle static lexical variables has been introduced. Perl's default variable can now be lexically scoped. Many new language features have been introduced. Perl has a switch statement in the core now. There's a new defined-or operator. The user-defined sorting subs can now be recursive if you need them to be. Compress::Zlib, Archive::Tar, and Archive::Extract are among some exciting new core modules.

Most of what I just mentioned were changes between 5.8.8 and 5.10.0, so there's quite a bit more between 5.6.1 and the current Perl landscape. There were also a lot of changes to Perl 5 back in the 2001 to 2002 time frame, and have been all along since.

Some changes between 5.6.1 and 5.8.0 included changing to a stable algorithm for sort(), changing the default IO layer from the system stdio to the PerlIO system for more predictable cross-platform behavior, safe signal handling, the UTF8 encoding being changed from lexically scoped with the program to being associated with a file handle, and a much better threading model.

Important changes during the 5.8.x series include extra randomness in the order of hash keys, Config.pm being shrunk by about 90%, better handling of UTF-16 encoding, the elimination of some temporary lists during certain operations, and smarter malloc() handling.

Perl 5 isn't exactly sitting still, and it hasn't been. Perl 6 is, IMHO, not so much a simple upgrade of Perl as a new language in the family of Perl-like languages. Perl 6 will be to Perl 5 much what Perl 5 was to Perl 4. People will notice some syntax changes, but many people will program in it like they were using the previous version with a tweaked syntax. Others will take advantage of all the new features. Eventually most Perl programmers will find a portion of the language that suits their tasks most readily and will become most comfortable with that. Perl 5 isn't going away for a long time, so people who really can't stand the idea of a new Perl will be able to do a lot of Perl 5 work.

Yeah, there are other languages that will wax and wane. Ruby looks interesting, and a lot of people seem to like it. I have a general distaste for personally using languages with so much significant whitespace as Python, but lots of people really like it and there's really good software being written in it. I can't fault a language or its designer for my having other preferences. JavaScript is pretty handy, and it's getting better tools and implementations all the time and a new standard soonish. I've picked up HaXe recently, and it's an interesting alternative to ActionScript and JavaScript. I am considering learning D. Java's really popular. Yet many people still program in Perl, C++, C, Ada, Pascal derivatives, Basic, Fortran, and even COBOL. People said Basic was dead, but Visual Basic is still around.

Like Perl, though, what we call Basic these days doesn't much resemble Basic from 20 years ago. Visual Basic doesn't even look like older versions of itself, let alone QuickBasic or the even older and even more severely limited GWBasic or Dartmouth Basic. If Perl 6 is a few years separated and a bit different, it doesn't mean it's not Perl or that it was a waste to create it. The only way it would be a waste is if nobody used it.

Re:BFD?

[Wiseman1024]

Python's lambda is limited to a single expression, which sucks, but you can always do def _(...) just before use. As for closures, Python implements closures properly (properly = as described in SICP, the environment model of evaluation), but immutable objects such as numbers or strings are, well, immutable, and the = operation played on a bare symbol always defines it in the current scope. However, an improvement on this regard is coming on Python 3000.

Python's parsing of vertical whitespace is not ambiguous. Lambda doesn't support statements because Guido doesn't want to. I would easily allow something like:

higher_order_function(lol, lambda x, y: ...code goes here... ...more statements...
, next_arg, etc)

Or, if Python didn't have statements (which are the real flaw IMO), you would just do something like:

higher_order_function(lol, lambda x, y: progn(
        whatever,
        whatever), next_arg, etc)

Define progn as lambda *a: a[-1].

Holy cow!

[try_anything]

perhaps it's appropriate to judge the design of Python in terms of how it supports important features on which to build larger and more elegant abstractions.

Closures and lambdas can be faked using objects and named functions. It's admittedly awkward, but at least it's intelligible. The code can be read and understood without being a Python language junky. (Is there even such a thing as a Python language junky?)

Compare that to Perl5 OO. Perl5 OO is dog food, yet Perl 5 library authors consistently use it to define their library interfaces. All those libraries may toss the OO and rely on hashes of closures behind the scenes -- I haven't checked -- but library programmers evidently find it advisable not to share their elegant abstractions with users. Instead, they use objects, which (in Perl5) are wonky, bizarre, and understood by practically no one who isn't a Perl language guru. The fact that library authors define their interfaces in terms of constructs that few people understand seems like an admission that Perl has its own problems creating elegant abstractions.

plenty of people seem to think that Python is a language that scales up for experts

Actually, the idea is that you can know enough about Python to work competently with Python code and still have enough brainspace left over to be an expert in something besides programming. Try THAT with Perl.... I mean, try that sometime when you're not ten times as smart as I am :-(

Re:To all the detractors

[adamkennedy]

People have been arguing for who knows how long about syntax. At some point the argument has to end and someone has to implement that syntax. It's not an easy thing to bring either of these points to conclusion.

Actually, this is kinda wrong. Both have been happening simultaneously.

The entire point of Pugs was to have a reference implementation of the syntax.

And the mere existence of that implementation has meant that the language folks have gotten insight into how they designs work when you actually implement them.

As a result, in several places the syntax has been modified to make implementation easier, or make parsing faster, etc.

Re:Merry Christmas!

[Anonymous Coward]

I'm very happy to see something productive out of the Parrot community. They've promised some great things, and we've been waiting a long time to use their offerings. Some people in the community (see article below) have started to doubt the Parrot project's usefulness, but maybe this cool Perl6 development will make them re-think their stance.

Will Parrot ever truly deliver? (http://pinderkent.blogsavy.com/archives/124)

Earlier today I was reading an article about Parrot. Parrot is, as stated on the projects Web site, a virtual machine designed to efficiently compile and execute bytecode for dynamic languages. Parrot currently hosts a variety of language implementations in various stages of completion, including Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6, APL, and a .NET bytecode translator.

So Parrot does sound like an interesting piece of technology. Its understandable how a common runtime for scripting languages could prove beneficial. But will it ever be a platform suitable for serious, production usage? I have my doubts.

Parrot has been under active development for quite some time now. The initial 0.0.1 release was made on September 10, 2001. During 2007, weve seen a release every month or so. So a lot of effort has been put into Parrot over the past six years. It has surpassed one of the major stumbling blocks with many Open Source projects, in that it has managed to build at least some development momentum. Unfortunately for its supporters, Parrot has never really seemed to catch on. I think there are a number of reasons for this.

Stability is probably the first problem. I dont mean stability in terms of the runtime crashing, or anything of that sort. Im talking about concept stability. There has always seemed to be a relatively large amount of change between releases. While this is good, in that there are improvements being made and new ideas being implemented, this causes problems for users who want to build reliably upon Parrot. Individuals and businesses often do not, or cannot, invest the time and effort to track a continually-moving target like Parrot.

The language implementations for Parrot, while many in number, have been of limited use. Looking at the status messages of some of the most promising and practical language implementations shows why this might be the case. Such messages include:

• Incomplete - but all examples and test cases are working. (Amber for Parrot)
• Most of the samples work. (BASIC/compiler)
• Has been broken for a long time. (BASIC/interpreter)
• Parser is pretty complete. Generates PIR for basic Ruby programs (Cardinal, Ruby CVS Head 1.9 implementation)
• Functioning, all samples working, lacks IO routines (Cola)
• Working for some simple forms. Due to some broken features, most of the bootstrapping code has been commented out. (Common Lisp)
• Functioning for handcrafted test cases. Loading frozen state is currently broken. Far from complete. (Parrot m4)
• This project has been abandoned. Any takers? (Pint, an experimental PHP implementation)
• Passes nearly 25% of tcls (lightly converted) test suite, using a Test::More like harness. (Tcl)

So while there are many interesting language implementation projects for smaller or more obscure languages that have reached further stages of completion, the ones that were most likely to be of practical use seem to be lacking. Now, this is understandable. Maintaining a suitably complete Ruby, Python, Perl or Tcl implementati