Slashdot Mirror

I'm not very familiar with Parrot

I think you are right, but Parrot is not in the same game with Java and .NET., yet.

Even /. has gotten over (most of) its .NET trolling and is starting to look at the platform in a practical, even positive light. There are coding projects well into production, some are finished, and surely there are some in maintenance stages. By the time Longhorn rolls out, the .NET runtime will probably be on the majority of active Windows systems. Mono may be an even bigger contender in the near future.

Meanwhile, programmers are waiting, many patiently, for Parrot which is just at 0.1.0. As an equivalent, Parrot isn't really in the race yet. Everyone would love to seriously consider it, but it's not a contender (in the same way .NET and JVM are) to technically consider yet. I hear things like mod_parrot are still in need of work, though there are related projects coming about.

Hopefully Parrot will become adopted over projects like Mono, not just in concept and ideology but in a practical platform. I think Python support may be critical, even more so than Perl6. Let's hope Parrot's maturity doesn't need to wait for Perl6.

Recent developement summaries on Parrot and other Perl-related things. Is there a timeline for Parrot? I haven't seen it.

Your question is answered in the Parrot FAQ. Sun's JVM isn't free software, there's no other JVM out there that compiles on as many platforms as Perl 5, and all JVMs as well as the CLR use a stack architecture, whereas Parrot uses a register architecture which appears to be much more suitable for Perl (ie faster).

If you look at the Parrot FAQ, they explain exactly why they chose to write their own VM instead of using JVM or CLR. To quote:

Why your own virtual machine? Why not compile to JVM/.NET?

Those VMs are designed for statically typed languages. That's fine, since Java, C#, and lots of other languages are statically typed. Perl isn't. For a variety of reasons, it means that Perl would run more slowly there than on an interpreter geared towards dynamic languages.

The .NET VM didn't even exist when we started development, or at least we didn't know about it when we were working on the design. We do now, though it's still not suitable.

FWIW, it looks as though Parrot will give very good performance as VMs go. Python for Parrot (at least the parts that work already) is faster than the existing implimentation of Python, and there's every reason to think that the same will be true of Perl, Ruby, and whatever other languages they impliment.

License compatibility.

Parrot has an odd license -- it currently uses the same license as Perl 5, which is the disjunction of the GNU GPL and the Artistic License, which can be written (Artistic|GPL) for short. Thus, Parrot's license is compatible with the GNU GPL, which means you can combine Parrot with GPL'ed code.

Code accepted into the core interpreter must fall under the same terms as parrot. Library code (for example the ICU library we're using for Unicode) we link into the interpreter can be covered by other licenses so long as their terms don't prohibit this.

Platform compatibility.

Parrot has to work on most of Perl 5's platforms, as well as a few of its own. Perl 5 runs on eighty platforms; Parrot must run on Unix, Windows, Mac OS (X and Classic), VMS, Crays, Windows CE, and Palm OS, just to name a few. Among its processor architectures will be x86, SPARC, Alpha, IA-64, ARM, and 68x00 (Palms and old Macs). If something doesn't work on all of these, we can't use it in Parrot.

Speed, size, and flexibility.

Not only does Parrot have to run on all those platforms, but it must also run efficiently. Parrot's core size is currently between 250K and 700K, depending on compiler. That's pushing it on the handheld platforms like a horse in the ass of a chinese schoolgirl. Any library used by Parrot must be fast enough to have a fairly small performance impact, small enough to have little impact on core size, and flexible enough to handle the varying demands of Perl, Python, Tcl, Ruby, Scheme, and whatever else some clever or twisted hacker throws at Parrot.

These tests are very hard to pass; currently we're expecting we'll probably have to write everything but the Unicode stuff."

Well there goes that idea.

Parrot Code FAQ

Consequently, Perl 5 code should run faster under Perl 6.

Why should I program in Parrot Assembly language?
[...]
You get all the pleasure of programming in assembly language without any of the requisite system crashes.

What language is Parrot written in?

C.

For the love of God, man, why?!?!?!?

Because it's the best we've got.

That's sad.

So true. Regardless, C's available pretty much everywhere.

DLFP: What do you think of the Parrot project (http://www.parrotcode.org/), which aim is to develop a common virtual machine for interpreted languages, such as Perl 6, Python, Ruby and Tcl ? [Jean-michel Fayard]

Guido: I wish them well, but I don't think they will succeed. They are vastly underestimating the effort that goes into a virtual machine for any specific programming language. Even languages as similar as Ruby and Python have fundamentally different runtime abstractions, and the difference between Python and Perl is much greater still. (For example, the concepts of strings and numbers are entirely different in these two languages: in Python, numbers and strings are different immutable types, while in Perl they are the same type and are mutable.) I expect Parrot will do a great job of running Perl 6, but a relatively poor job of running other languages. Of course, I'd be happy if I were wrong (except for the brief moment of receiving a pie in the face at OSCON 2004), but I don't expect that to happen.

Why should I program in Parrot Assembly language?
[...]
You get all the pleasure of programming in assembly language without any of the requisite system crashes.

What language is Parrot written in?

C.

For the love of God, man, why?!?!?!?

Because it's the best we've got.

That's sad.

So true. Regardless, C's available pretty much everywhere.

DLFP: What do you think of the Parrot project (http://www.parrotcode.org/), which aim is to develop a common virtual machine for interpreted languages, such as Perl 6, Python, Ruby and Tcl ? [Jean-michel Fayard]

Guido: I wish them well, but I don't think they will succeed. They are vastly underestimating the effort that goes into a virtual machine for any specific programming language. Even languages as similar as Ruby and Python have fundamentally different runtime abstractions, and the difference between Python and Perl is much greater still. (For example, the concepts of strings and numbers are entirely different in these two languages: in Python, numbers and strings are different immutable types, while in Perl they are the same type and are mutable.) I expect Parrot will do a great job of running Perl 6, but a relatively poor job of running other languages. Of course, I'd be happy if I were wrong (except for the brief moment of receiving a pie in the face at OSCON 2004), but I don't expect that to happen.

Ever heard of Parrot?

When you can have Parrot instead?

Seriously? With a common runtime for many languages such as Perl, Python, Ruby, etc, I don't see why anyone would need to use Java any longer.

I've heard about ports of Python to the Perl's new bytecode called Parrot. Ruby to Parrot is called Cardinal .

I don't know if it's a reason to wake up, though.

I think 2004 is going to be a bumper year for open source (and Linux, in particular) thanks to the advances made in 2003. Linux is finally a term that is recognized by many businesses, and the concept of 'open source' is invading even the most stoic of companies. More developers than ever are joining the ranks (although many only because they're out of work, unfortunately), and there are lots of cool projects.

Mike Home, who works on Wine, posted a great summary of planned open source developments in 2004, mentioning Wine's continuing development (0.9 should be out in 2004), and planned leaps in KDE and GNOME. GNOME will finally get a full and stable version of Epiphany, too.

Development continues on Perl 6 and the Parrot virtual machine, and I am particularly interested in the development of Dashboard, a GNOME 'just in time' information manager project created by Nat Friedman, of Ximian fame.

Alan Cox should have his MBE this year, er, MBA, rather ;-) And perhaps he'll stop using Welsh only on his diary. And as discussed over at KernelTrap, Reiser4 may also be merged into 2.6, although this is not certain, and may be merged into 2.7 first for further testing.

So, what do YOU see happening in open source in 2004? Fill us in on what you plan to do, and why 2004 is going to be a bumper year for open source, Linux, and all. What technologies are going to spring up this time around?

I'm actually a little sad this story hasn't made it to the front page yet. Incredibly interesting!

I think emulation (and, on a different plane, virtualization) has a massive part to play in computer science over the next couple of decades, and if emulating old computer games is how we can get people to study the topic, so be it!

After all, writing an emulator is writing a virtual machine.. and there are a few of those around.. the JVM, Parrot, and the .NET CLR.

I'm waiting for Parrot to mature. It's a register-oriented bytecode interpreter, designed for Perl 6, but with other languages in the wings. When it gets Perl's libraries, Ruby's syntax, real threads, and great speed, I think it will do well.

One of my favorites is the joke of Python and Perl merging into a project called Parrot, which inspired this.

The folks at Parrot might be your best bet.

Nope, Kaffe is the open source one that isn't based on Sun code. I suspect that there are a few clean-room embedded VMs out there too, but I can't prove it.

Perhaps more relevant to the Linux users here is the huge growth in Java on Linux due to the commercial (but generally free) JVM implementations from BEA, IBM and Sun. This is what places Java-on-Linux head and shoulders above Mono.

I agree, however, that there are valid alternatives to both, and people with a desire to do something creative rather than just cloning stuff might like to help out with Parrot, the Perl 6 VM, also targeting a bunch of other languages.

Nope, Kaffe is the open source one that isn't based on Sun code. I suspect that there are a few clean-room embedded VMs out there too, but I can't prove it.

Perhaps more relevant to the Linux users here is the huge growth in Java on Linux due to the commercial (but generally free) JVM implementations from BEA, IBM and Sun. This is what places Java-on-Linux head and shoulders above Mono.

I agree, however, that there are valid alternatives to both, and people with a desire to do something creative rather than just cloning stuff might like to help out with Parrot, the Perl 6 VM, also targeting a bunch of other languages.

Of course, if you just go read the Apocalypses and Exegeses on perl.com and the FAQ on parrotcode.org, you get all of this for free.

In reality it's the other way around though. There's a large chunk of Perl 6 design yet to be completed, but the Parrot engine itself has come along quite nicely. There are a number of smaller languages running on Parrot right now.

There has also been a wager made recently between the Parrot folks and the Python camp (concerning pies) that there will be a Python running on Parrot by next year that will run faster than the exiting Python VM. A wager that the Parrot camp is not willing to lose.

Everyone here is really quick to be critical because they can think of one buzzword here or there and make wild claims about why something is worthless. But in the end, the Parrot group have produced actual working code, and all the detractors have produced is empty words.

Try it out yourself: parrotcode.org

Why they aren't using .NET is a FAQ. The current (CVS) parrot not only runs assembled bytecode, but also will parse, optimize (to a certain degree) and execute Parrot assembly directly.

Why they aren't using .NET is a FAQ. The current (CVS) parrot not only runs assembled bytecode, but also will parse, optimize (to a certain degree) and execute Parrot assembly directly.

Try here or here.

Just trust that there are many talented people working on Perl 6.

Just to give one current, more or less viable Parrot application that I know of, the virtual machine been embedded as mod_parrot , which can in principle allow you to run Parrot bytecode in Apache. Why would anyone want to write web applications in what amounts to assembly code? Well of course, most people wouldn't, but as Perl6 matures this could become a viable competitor to mod_perl ...and mod_python , mod_tcl , mod_scheme , etc.

More to the point, the development of Parrot has forced a cleanup of the Perl API. The current situation where the reference implementation is the only implementation has never been theoretically clean -- other languages, like Python, C, and Java, have long had multiple implementations, and this has consistently been a healthy thing for the evolution of the language. Abstracting out the virtual machine layer will allow Perl6 to have a pluggable runtime layer (e.g. replace runtime compilation & execution of bytecode into, say, dynamic execution of precompiled bytecode (as Python does), or direct compilation from source to executable machine code (as C does). More recently & concretely, abstracting out the VM layer has been the motivation for Ponie -- an effort to re-implement Perl5 to run on Parrot, and in the process give Perl that abstracted alternate implementation that most other languages have. This will be a very healthy thing, both for Perl5 and for Perl6.

If there has been a dropoff in contributions, it isn't due to Parrot work. Dan Sugalski et al have done excellent work here, and I think most people in the community recognize this. If there has been a dropoff, the much more mundane explanation is probably just the taking economy: a whole lot of people just don't have the spare cash to give these days.

For my bit of the Parrot project I'm tackling BASIC. The version of BASIC that now runs under Parrot will run many QBASIC programs -- I uploaded a colorful chess program yesterday that required almost no "porting". And of course, Parrot runs under a wide variety of platforms.

My goal is to have it eventually run all QBASIC programs, less stuff that *can't* be done outside of MS-DOS.

This was a very interesting article. I natively speak Perl, C, and C++, know enough about PHP to get by, and still remember some Commodore 64 BASIC (10 ? CHR$(147)). I am also, as I believe I've said before, not afraid to learn things like Java, Python, Ruby, maybe even Visual Basic again (God forbid) should they prove exceedingly relevant to my case - in fact, I quite look forward to knowing (hopefully) all of them and then some. But never Pascal. (Just kidding.)

I've really found that the thing I hate most about programming in general is that no single language is the right one to use for any of my programs! I am very interested in any effort I ever come across to do functional merging of disparate environments. In addition to a couple of workarounds I've invented in the past for shoehorning Perl into PHP, I like reading about things like SWIG, the open CLR, and even COM (the concept more than the implementation), and a smile always comes to my face when I think about the Inline library written for Perl.

Now, the thing I really pine for is all of this interlanguage binding stuff being easy, fairly portable, more synactically simple, and less hacky. I know that these exist, but not quite completely together. If I write a program in Perl with use Inline C, I can never be sure that anyone else has all the development tools necessary to compile all the C on the fly. Writing a program in Visual Basic with a nice mouse-drawn GUI and an external component is really easy - but it's Visual Basic. Writing a component wrapper for Perl is fairly straightforward with SWIG, but some well-thought-out language features would make it easier. And COM... I'm going to have to try wrapping my head around that book again someday... I'm sure the ATL makes it all very simple, but can I use ATL from MinGW? From C? From Perl? And don't try to tell me that I need to learn yet another flavor of XML to make all of this work.

That's mis tus centavos.

(Note: I disclaim perfection. Don't hit me too hard; I admit I haven't done enough of my homework to claim this post isn't full of holes. Once I've looked this whole matter through, if ever, and if I still haven't come up with anything good, I may just have to take a deep breath, lay down a syntax, figure out how to use a lexer generator and a compiler compiler, and throw together some ghastly but very easy-to-use homogeneous aggregator system. Either that, or I wait for Parrot to interoperate with Mono...)

and it is doubtful that Perl will ever be re-implemented ever again. It's obvious you don't read Slashdot, or even keep up with the latest programming news. Perl is under heavy reimplementation right now. Indeed, Larry Wall publishes a new tome of information about the rearchitecture every few months. The Parrot team are working on a VM for the language, upon which other languages like Ruby are even planned to be re-implemented. Get with the times :-)

I don't trust either Sun or Microsoft to refrain from jerking me around for a few $$$, standards or not.
Give me a FAST Parrot VM with GTK for Lin/Win/Mac and I'll never touch C++ again.

Best reason not to move to Java: click.

Programmers determine coding practices, structure, etc. You can find obfuscated java code, obfuscated python, obfuscated perl, or obfuscated php. It all depends on the _programmer_, not the programming language. It's like blaming car accidents on the type of car a person drives.

Structured code is a good thing though, and so is efficiency.

Most PHP Projects are put on a shared server, so using shared memory will generally anger the host. For enterprise level, maybe for a simple simple form I'd go with PHP, everything else I would go with something more hardcore, and yes, even Java. Java is a good language, but it's bad to be trapped to a single company for your language.

Mod_Perl on Apache does shared memory, along with several other improvements. With strict coding practices in a company, and someone going over the code(should be done with _every_ language and _every_ project) the code is easy to read, easy to re-use, and easy to modify. Yes, even Perl. High level enough to do things quickly and easily, and powerful enough to do it very quickly, using shared memory, etc.. Don't underestimate the power of mod_perl, it's easy to get a dynamic database page with mod_perl to load faster than static content.

And with mod_perl, and good practices(again, necessary even in Java) it will scale easily to multiple servers, legacy systems, etc...

Of course, we're waiting on Parrot. Yeah, kinda Perl 6, but yeah, it will compile Java. And yeah, cross platform, unlike Java (Java on BSD is a PITA, _and_ reminds me of Win 3.1 on my 33mhz system back in the day).

So again, the problem is the programmer, not the language. Although you are correct that PHP is not an application server. But look at Parrot and look at Perl, things can grow into even better things.

Parrot also has a BF (Brain****) interpreter.

I am a Perl fanatic. I love Perl. But what is going on with Perl 6? The guys working on the Parrot VM for Perl 6 are doing such an amazing job, but I'm pretty dismayed about the language development on Perl 6 itself.

Perl 6 was meant to be a total rewrite. Nothing was meant to be sacred, cruft could disappear, and we'd be left with a mean language, true to its roots, and working on a hot new VM.

Instead we get stuff like this:

sub *print (*@list)

Talk about confusing! * signifies a glob, but in the above example the first * signifies a sort of 'package wildcard' meaning that the subroutine is global! The second *, however, is a glob, as in Perl 5. WTF? Perl 6 looks almost as inconsistent as PHP already, and it's only in draft!

Each page of this Apocalypse presented me with a new piece of cruft to look horrified about. Slurpy arrays!? Oh my god. Wall even goes on about 'psychological reasons' for syntax! 'Default values' and 'Rules' are things that are easily done with existing code.. it's not even as if they result in particularly crufty code in Perl 5.

I'm still looking forward to Perl 6, but it really does seem as if Parrot is where the true action is. Perl 6 really does look as if it is being designed by committee.

Jako, a C-like language developed for testing Parrot

Cola, likewise, but more Java-like

BASIC

Forth

...and an extremely rudimentary Perl 6 compiler...

What do we think?

Perl 5 runs on eighty platforms; Parrot must run on Unix, Windows, Mac OS (X and Classic), VMS, Crays, Windows CE, and Palm OS, just to name a few. Among its processor architectures will be x86, SPARC, Alpha, IA-64, ARM, and 68x00 (Palms and old Macs). If something doesn't work on all of these, we can't use it in Parrot.

I'd like to it compared to other bytecode interpreters like the JVM and .NET's CLR. How similar/different are they?
One big difference is that it's register-oriented rather than stack oriented. It has some fixed number of registers (32 IIRC), each of which can hold a Perl scalar value, i.e. a string, number, or reference. The register design apparently makes it faster than stack-based designs.

The thing I'm really looking forward to is that it promises to be a well designed, well implemented, portable, free-as-in-speech approach to software distribution. This is in contrast to Java, for instance, which has lots of really horrible proprietary implementations and only an incomplete free-as-in-speech implementation (gcj).

That should read Kaffe and Parrot, got my Java developments confused...

Well, someone else already meantioned it, Parrot is Perl's way of doing a VM and looks really nice. So there already is a VM... beside other languages which use VMs already.

But I also think that too much competition in this field wouldn't be that good either. Don't get me wrong, competition is always good, but too much isn't since those competiting VMs targeted at the same market would stiffle its own distribution, IMHO, since it COULD happen that none gets a really broad distribution.

And a widespread VM is a good one, at least for the programmer, because he can assume the most widespread VM to be avaible to most to users, that is they already have it and don't need to install it first so that you're able to install your software. And requiring the user to install as few files as possible is a Good Thing(tm) :-)

And this is the reason why I think CLI will succeed, despite me not liking MS: it will be widespread, users won't have to install it since it already comes with your Windows. And others can use either MS's FreeBSD implementation or Mono. Would Parrot or another VM be included in Windows this one would succeed. It already was the reason for Javas success so far: the reason you already had it in you Netscape and former IE (AFAIK) made it very easy to use for end users. Had MS distributed an up-to-date JVM in XP, Java would have left no room for CLI, I guess.

Having others VM would be nice but with many people focussing on one VM the avaibility of good tools is better for that VM, thus enabling programmers to more easily write good programs.

On the other side there should always be an alternativ, just because there is no one true way of doing things and every application has a different need and thus you could choose the VM that fits your need more closely :-)

Parrot the VM for Perl6 is being developed w/ multiple languages in mind.

Although the Java community is still larger than even this combined pool [of Perl, Python, and Ruby]

Surely spoken by someone outside the Perl community. I might say that more people are paid to write in Java, but I wouldn't call that a community.

I do agree with you about the potential of Parrot, though. By the time it's released (I think current estimates say about a year), it'll already have functional support for a number of languages, including Python and Ruby, and probably Java and C#. This one's gonna be big, folks.

Parrot is the way to go. It's open source, virtual machine. Supports some languages already, but the VM is still under development and needs some help. Come on, even Java will compile to it in the future. =)

Language/VM/OS is a useful abstraction. So far, we have lots of Languages and lots of OS's, but relatively few VM's. For example, if one could compile Java to run on the JVM and Parrot, well - I'm not quite sure what you'd do.

And that's my point.

Here's the URL for the main site:

http://www.parrotcode.org/

Parrot isn't the VM for Perl6. Parrot is a "new language from the creators of Perl and Python." Duh. There's even an O'Reilly book on it.

Seriously though. They barely mentioned Parrot and Parrot is coming along very nicely I think. Even with a Java to Parrot Bytecode program, Brainfuck, Jako, Befunge-93, cola, forth, miniperl, ook, (non-final) perl6 interpreters/compilers, as well as python, ruby and scheme interpreters/compilers coming. Of course it's not finished, so not all of the languages are either, but hey, it's getting there, and damn fast. There's even a Parrot Assembly Lange.

Parrot is definately not Perl6. It's much more. It's like java, but open source, and independent of Languages. They're hoping to have it compile on as many platforms as perl does now, unlike Java which is Windows, Mac, Linux, and some PDAs, end of story.

So everyone check it out and throw some patches in too! Of course, the only support I've given so far is moral support. :/

No supposedly--Parrot has a working JIT now. Dowload it from parrotcode.org and try it...

If you want you can code directly in PASM (Parrot Assembler) or help write some of the tools that parse real languages and emit PASM. It's not a particularly small assembler like 6502 (but it can be if you really want!) but still has that small-system feel.

I got my Assembler fix this past spring with Parrot BASIC (link is PDF).

If you want you can code directly in PASM (Parrot Assembler) or help write some of the tools that parse real languages and emit PASM. It's not a particularly small assembler like 6502 (but it can be if you really want!) but still has that small-system feel.

I got my Assembler fix this past spring with Parrot BASIC (link is PDF).

Well, parrot (the VM on which Perl 6 will run) has a JIT, that means that all your scripts can be JITed for a significant speed gain.

Check it
out

For more information about Parrot, go to dev.perl.org/perl6, or join the perl6-internals mailing list.

Stephen

For those of you who were like me and have no clue what this story is talking about:

Parrot Code
Parrot FAQ
Parrot

For those of you who were like me and have no clue what this story is talking about:

Parrot Code
Parrot FAQ
Parrot

Yes, the parrotcode website needs a bit of an overhaul--that was in progress when the slashdot splash hit.... :)

Essentially this is the new virtual machine Perl 6 will be targeting (what Perl 6 will be compiled into before it is run.) But Perl will not be the only language that will run on this. People are working on making Python, PHP and even Java run on this same machine. It's about working together people.

Oh, I know it's much more fun to say "nah ne nah nah, my language is better than yours". But the Perl people want to work in an interoperable world where we can all code stuff in whatever language we want and it'll all work together. And this is their effort.

Now if you want to slam this down and winge, then it's up to you and I'm sure I'll waste my time reading your comments. However, if you want to actually do something about this kind of thing, you know where the donate button is.