Slashdot Mirror

The reason I suggest this is that it would appear that the main purpose of the Harmony project is to create a vibrant, inclusive community. In that case, the open source world, Harmony, and Parrot, plus users of java, perl, python, ruby and tcl (for starters) can all benefit by combining two disparate groups of all-star programmers working in potentially complementary areas.

If any parts of the Harmony project can use parts being developed for Parrot, much time would be saved and the quality of both projects could increase. In addition, it would likely be easier for the Harmony project to meet its stated goals of collaboration and sharing of runtime components, etc. to do so with parrot. The Parrot FAQ also talks a bit about VM development, including working with a JVM, it sure sounds like there is some overlap with Harmony.

Perhaps the Parrot people don't need any help (I doubt they would say so though) and maybe the Harmony VM people can't stand the idea of not building from ground zero, or using only the Apache license and nothing else. If any of these three maybes are true then it is a sad story.

Also, I may be out of line but it sounds like parrot will enable sharing of code from different languages at runtime. If so that will just magnify what Harmony is trying to do in terms of bringing people together.

So humbly I would like to say that the ideas of creating a specification and reference implementation, and promoting collaboration and sharing of modular code sounds wonderful, and focusing on these and not wasting time reinventing the wheel could be a great move for Harmony, and contribute to refocusing the brainpower of the free software world, in the spirit of the Harmony and Parrot projects.

My guess is that Harmony has some really smart people and they are also well aware of the Parrot effort. Maybe some are already involved for all I know. Any comments one way or the other?

I find it interesting that someone hasn't developed a "trully free" alternative language/platform that rivals Java and .NET.

There is, and the by the accounts of most people who have used it its better than either one parrot. For example it the code itself takes advantage of the large number of registers on modern CPUs as well as L1 and L2 cacheing issues to make sure code runs much faster than .Net or JVM code. It supports types of record structure reads that aren't available on PCs (only on VMS or MVS) as well as I/O operations that are more Cish for PC, Mac...

The early test languages are Perl 6 and an alternate Python. Also they have: Ruby, Objective-C, TCL and Scheme. Eventually they hope to have the mono languages in particualr Java, C#....

You mean like this?

> Mono... I do belive that CLIs are the way to go.

I couldn't agree more. If it can't be done from a command line interface, it isn't worth doing! w00t! ...or did you mean CIL: Common Intermediate Language?, a CLR, Common Language Runtime.

Ok, I have to admit: CIL is a brilliant concept too.
If only Parrot wasn't pushing up the daisies.
HELLO POLLY PARROT!!!

Yes. The Hurd-on-L4 bases all its communication on a capability system. Programs running on it may or may not explicitly make use of it (it's all wrapped for the POSIX interface, so they obviously don't see it), but they will use it underneath anyway.

That is really great to hear. Now I have no doubts that Debian GNU/Hurd will be my future system of choice. Today I use Debian GNU/Linux and my main problems are drivers running in the kernel space causing security and stability issues and the lack of real capability system. I'm glad that there is going to be a perfect system for my needs hopefully in not too distant future.

A good thing about this is of course that things like chroot are very easily implemented (there are many more good things, as I'm sure you know), but there is one problem: Any program which uses it is not portable to other systems. That means most programs will not want to use it. Which is a pity, of course, as it is a great system.

I'm sure I will use it even for the price of nonportability because I have already hit the wall of user-based privilege control system's limitations too many times, which is quite frustrating as no one else seems to see any problem with them. I suppose that there will be some convenient way similar to chroot and ulimit to run programs with restricted privileges even if they are themselves not aware and dependent on capabilities. Also I hope that it will be possible to use capabilities where available from managed environments like Parrot or maybe even directly in places like Apache configuration to give specific and limited rights to individual scripts. The possibilities are very promising.

This is an interesting news, and I have some mixed feelings. I hate it, I love it, and I don't care. I hate is as a Perl hacker. I love it as a Parrot enthusiast. And I don't care as a cellphone purist. To be more specific, as a Perl hacker I hate it because I am jealous. As a Parrot enthusiast I love it because what's good for my Python-using friends is also good for Perl in the long run. As a cellphone purist, I don't care because I have just bought a new Nokia 2300 which is already too bloated for my purist taste. All in all, this is an interesting news, even if not surprising. I look forward to read about having Parrot VM available on cell phones one day, so we could finally have an efficient register-based VM suitable for optimal execution of programs written in moderen dynamic languages and be free from the JVM mistakes legacy. This in an important goal.

I'm waiting for a Parrot chip.
Now that would be exciting.

More about Parrot here.

It's pretty interesting stuff. As I understand it, they're making a virtual machine that is better suited to running code from weakly-typed languages than, say, the JVM would be. I'd really like to see what comes out of the Python-Parrot combo, with or without the pies thrown.

I totally agree with your comments about the need for a standard library. But, as you observe yourself, such things can be developed by the community: CPAN for Perl...

On that front, it will be interesting to see what will happen in Parrot successfully manages its dream of uniting (amongst others) Perl, Python and Ruby - allowing a module from one language to be used in another. Surely that confluence of communities could build a very formidable library indeed...

Jedidiah.

Write a compiler for parrot.

Lots of people are doing that right now, and you could learn a lot from the included compilers for different languages, all in varying stages of completion.

Has anyone created tools for language development projects targeting Parrot? I had been thinking of writing Parrot code that can convert grammars to interpreters/compilers until I read this article and its replies. Now I'm hoping someone is already working on it.

Write a compiler for parrot.

Lots of people are doing that right now, and you could learn a lot from the included compilers for different languages, all in varying stages of completion.

Maybe you should have a look at Parrot? The CVS includes a lot of working and non-working language-implementations which you could have a look at..

I also recommend you to have a look at Lua which is a minimalistic yet beautiful language..

PERL 6, however, seems to be dead. I've been following its progress for a couple years now and it is going almost nowhere.

The decision to move to a bytecode interpreter looks like a huge mistake. Most people are fine without the bytecode interpreter

and it has split off dev resources from the issues that would help your everyday user -- "syntactic sugar".

OO support is also lousy in the current PERL.

The feature request framework was also lacking.

Everything went up to Larry Wall, who decided things basically as God.

I saw at least one simple and powerul thing dismissed out of hand -- a built in loop counter.

The stated goal of PERL6 was improving XS, but this doesn't require a bytecode interpreter either.

Of course, this is all running off volunteer labor so I shouldn't complain too much!

PERL 6, however, seems to be dead. I've been following its progress for a couple years now and it is going almost nowhere.

The decision to move to a bytecode interpreter looks like a huge mistake. Most people are fine without the bytecode interpreter

and it has split off dev resources from the issues that would help your everyday user -- "syntactic sugar".

OO support is also lousy in the current PERL.

The feature request framework was also lacking.

Everything went up to Larry Wall, who decided things basically as God.

I saw at least one simple and powerul thing dismissed out of hand -- a built in loop counter.

The stated goal of PERL6 was improving XS, but this doesn't require a bytecode interpreter either.

Of course, this is all running off volunteer labor so I shouldn't complain too much!

Not P-Code, GCC should compile to Parrot bytecode. Then you just boot into the Parrot VM.

Be a little patient ...

http://www.parrotcode.org

This isn't directly related to BC++, but it's in line with my other post slightly above. It's related to looking for alternatives, in the current age of Java, .NET and Mono.

For the last 8 hours after my other post on this thread, I've been searching the net for information regarding C#, CIL, Mono, comparisons to Java (with usability in mind, not zealotism), etc. And one thing is for sure: .NET and CIL is good technology - I hate to admit it, but MS has something good there. It is not a surprise, as it comes a LOT from the same person that designed TorboPascal, Delphi and now C#. I recommend those interested to read an interview here and pay attention to the ideas he puts forth. It offers a lot of insight into a few things that are wrong with Java, and that most people will probably have felt.

Also, one interesting RAD project is here. .

I've also tryed to learn as much as I could from the state of Mono, its legal status... and I felt important to share that my view has changed slightly, it MIGHT become a player, and it might offer a cross-platform alternative to .NET. I also recommend the GoMono FAQ . There's a lot FUD regarding possible patent threats from Microsoft over Mono, but I believe that to be mostly out of misinformation and lack of knowledge at how it works. The idea of a common VM isn't new, Parrot for instance is just another one.

I'd be most interested in whatever other people might have to say about Java vs .NET/Mono, that comes from careful study and consideration not just hype. Approaches like CIL and Parrot make a lot of sense... where do you see them going?

I wouldn't be too sure (read the first comment , LOL !!) .

If Microsoft enforces a patent on Mono, I'm sure Novell will pay the license fee though. A RAND license from Microsoft might involve a per-copy royalty or a distribution restriction agreement for the source - effectively killing off Open Source part of Mono. But Novell would still be able to consider Mono a revenue stream (so the paying customers might still be not left out in the cold).

The sad part of this is that all the public code of Mono will also become useless for everyone concerned (except for academic purposes , but there are much better research VMs). This is the concern expressed by the various Gnome devels recently ...

Does Parrot use References Counting (limited by virtual memory)? or
Does Parrot use Mark-Sweep Collection or Copying Collection (limited by physical memory)?

Unlike Perl 5 today, Parrot will not use reference counting. This is one of important difficulties which the Ponie project has to overcome. Please let me quote the most relevant parts of Parrot documentation.

Parrot FAQ:

You're not using reference counting. Why not?

Reference counting has three big issues.

1. Code complexity
2. Every single place where an object is referenced, and every single place where a reference is dropped, must properly alter the refcount of the objects being manipulated. One mistake and an object (and everything it references, directly or indirectly) lives forever or dies prematurely. Since a lot of code references objects, that's a lot of places to scatter reference counting code. While some of it can be automated, that's a lot of discipline that has to be maintained.
3. It's enough of a problem to track down garbage collection systems as it is, and when your garbage collection system is scattered across your entire source base, and possibly across all your extensions, it's a massive annoyance. More sophisticated garbage collection systems, on the other hand, involve much less code. It is, granted, trickier code, but it's a small chunk of code, contained in one spot. Once you get that one chunk correct, you don't have to bother with the garbage collector any more.
4. Cost
5. For reference counting to work right, you need to twiddle reference counts every time an object is referenced, or unreferenced. This generally includes even short-lived objects that will exist only briefly before dying. The cost of a reference counting scheme is directly linked to the number of times code references, or unreferences, objects. A tracing system of one sort or another (and there are many) has an average-case cost that's based on the number of live objects.
6. There are a number of hidden costs in a reference-counting scheme. Since the code to manipulate the reference counts must be scattered throughout the interpreter, the interpreter code is less dense than it would be without reference counts. That means that more of the processor's cache is dedicated to reference count code, code that is ultimately just interpreter bookkeeping, and not dedicated to running your program. The data is also less dense, as there has to be a reference count embedded in it. Once again, that means more cache used for each object during normal running, and lower cache density.
7. A tracing collector, on the other hand, has much denser code, since all it's doing is running through active objects in a tight loop. If done right, the entire tracing system will fit nicely in a processor's L1 cache, which is about as tight as you can get. The data being accessed is also done in a linear fashion, at least in part, which lends itself well to processor's prefetch mechanisms where they exist. The garbage collection data can also be put in a separate area and designed in a way that's much tighter and more cache-dense.
8. Having said that, the worst-case performance for a tracing garbage collecting system is worse than that of a reference counting system. Luckily the pathological cases are quite rare, and there are a number of fairly good techniques to deal with those. Refcounting schemes are also more deterministic than tracing systems, which can be an advantage in some cases. Making a tracing collector deterministic can be somewhat expensive.
9. Self-referential structures live forever
10. Or nearly forever. Since the only time an object is destroyed is when its refcount drops to zero, data in a self-referential structure

Does Parrot use References Counting (limited by virtual memory)? or
Does Parrot use Mark-Sweep Collection or Copying Collection (limited by physical memory)?

Unlike Perl 5 today, Parrot will not use reference counting. This is one of important difficulties which the Ponie project has to overcome. Please let me quote the most relevant parts of Parrot documentation.

Parrot FAQ:

You're not using reference counting. Why not?

Reference counting has three big issues.

1. Code complexity
2. Every single place where an object is referenced, and every single place where a reference is dropped, must properly alter the refcount of the objects being manipulated. One mistake and an object (and everything it references, directly or indirectly) lives forever or dies prematurely. Since a lot of code references objects, that's a lot of places to scatter reference counting code. While some of it can be automated, that's a lot of discipline that has to be maintained.
3. It's enough of a problem to track down garbage collection systems as it is, and when your garbage collection system is scattered across your entire source base, and possibly across all your extensions, it's a massive annoyance. More sophisticated garbage collection systems, on the other hand, involve much less code. It is, granted, trickier code, but it's a small chunk of code, contained in one spot. Once you get that one chunk correct, you don't have to bother with the garbage collector any more.
4. Cost
5. For reference counting to work right, you need to twiddle reference counts every time an object is referenced, or unreferenced. This generally includes even short-lived objects that will exist only briefly before dying. The cost of a reference counting scheme is directly linked to the number of times code references, or unreferences, objects. A tracing system of one sort or another (and there are many) has an average-case cost that's based on the number of live objects.
6. There are a number of hidden costs in a reference-counting scheme. Since the code to manipulate the reference counts must be scattered throughout the interpreter, the interpreter code is less dense than it would be without reference counts. That means that more of the processor's cache is dedicated to reference count code, code that is ultimately just interpreter bookkeeping, and not dedicated to running your program. The data is also less dense, as there has to be a reference count embedded in it. Once again, that means more cache used for each object during normal running, and lower cache density.
7. A tracing collector, on the other hand, has much denser code, since all it's doing is running through active objects in a tight loop. If done right, the entire tracing system will fit nicely in a processor's L1 cache, which is about as tight as you can get. The data being accessed is also done in a linear fashion, at least in part, which lends itself well to processor's prefetch mechanisms where they exist. The garbage collection data can also be put in a separate area and designed in a way that's much tighter and more cache-dense.
8. Having said that, the worst-case performance for a tracing garbage collecting system is worse than that of a reference counting system. Luckily the pathological cases are quite rare, and there are a number of fairly good techniques to deal with those. Refcounting schemes are also more deterministic than tracing systems, which can be an advantage in some cases. Making a tracing collector deterministic can be somewhat expensive.
9. Self-referential structures live forever
10. Or nearly forever. Since the only time an object is destroyed is when its refcount drops to zero, data in a self-referential structure

Parrot already has SDL bindings, and it should be relatively easy to add in anything that has a C API, thanks to NCI.

As for maturing, well, I'd consider parrot to be of at least beta quality; it isn't stabilized yet, and many things are still subject to change, but on the other hand, it promises to be at least on par with (and in some cases substantially faster than) php, perl, ruby, and python as far as VM performance goes.

However, Perl 6 I'd consider to be alpha quality; more of its design is in flux, and although there is a proof-of-concept compiler for most of it, the real one has yet to be written. Although you may or may not see Parrot get mature in the next year, I doubt you'll see Perl 6 by that time as well--although I wouldn't mind being proven wrong here. :)

Modern games will always try to max out your CPU/GPU. That doesn't mean scripting languages don't have a place in games, but critical portions of them, or their libraries (like a 3D rendering engine, heh) will probably stay written in C/C++. However, there are already games written in scripting languages, and some of them are quite fun.

Parrot!!!

Forth is up. Is Python ready?

PHP real soon now?

...and the Perl 6 interpreter (parrot) is essentially complete...

Actually, parrot is a virtual machine meant to run interpreted languages. That's one of the cool things about it -- ruby and python could both be written to run on it, and then a parrot-to-machine-code compiler could be written, and I could finally compile ruby. Yay!

Compiler != interpreter

So, care to back up your statements?

You can't win with either java or mono(c#).. Maybe its time ffor python/perl/php/ruby.....

Well, with IronPython mono is Python. Alternatively, you can always use Jython and have Python being Java. The real benefit here is this: There's no need for constant updates to the pyGTK and pyGNOME libraries every time GTK of GNOME changes if you're using IronPython, because IronPython automatically gets the latest GTK# stack through mono - your bindings are always automatically up to date.

Of course, you can always go with Parrot if you want the completely new and different open source implementation of the concept. Parrot will run both Perl and Python happily, not sure about PHP and Ruby, but I imagine someting is in the works, and while it is a lot less complete than the others, it promises to do a lot more, and potentially do it notably faster than either Java or Mono/.NET

Plenty of options, and they all make some sense. Time to let OpenSource Darwinian practices see who survives in the long run - there are more baskets for these eggs, so there's no reason to panic.

Jedidiah

I think the Python work would be interesting. I'm a long-time Perl coder and Python looks interesting. But IMHO, PHP would be a waste of time. Part of the reason CPAN is so huge is that perl5 is coming up to its 10th anniversary. The perl5 language has remained very stable over that time. But PHP5 has just been released and from what I've heard it's another major change to the language. But if it's got namespaces and/or sane package management like everyone's been begging for, then PEAR might start to really pick up. I guess we'll see in another 10 years. Either PEAR will be huge success, or programmers will reminisce "Remember PHP? I think someone's coded up a Parrot compiler for that old language " :)

Not an RFC, but another great joke gone to implementation

Performance is much more a matter of structure (exponential complexity) than language (poor linear complexity). As to level, "high level" languages limit you to their implementation of a few concepts. Depending on where the heavy lifting is, Perl could easily outperform optimized C.

Speaking about Perl and Assembly, it is important to mention that there are modern object-oriented assembly languages with asynchronous I/O, events, threads, multiple inheritance, garbage collection, built-in Unicode support, etc. See: Parrot Assembly, and IMCC:

"IMC stands for Intermediate Code; IMCC stands for Intermediate Code Compiler. You will also see the term PIR which is for Parrot Intermediate Representation and means the same as IMC, but for some each Parrot developer has his favorite term. PIR was the original term, where IMC seems to be the vernacular. It is an intermediate language that compiles either directly to Parrot Byte code, or translates to Parrot Assembly language. It is the preferred target language for compilers for the Parrot Virtual Machine. PIR is halfway between a High Level Language (HLL) and Parrot Assembly (PASM)."

"PASM is an assembly language, raw and low-level. PASM does exactly what you say, and each PASM instruction represents a single VM opcode. Assembly language can be tough to debug, simply due to the amount of instructions that a high-level compiler generates for a given construct. Assembly language typically has no concept of basic blocks, namespaces, variable tracking, etc. You must track your register usage and take care of saving/restoring values in cases where you run out of registers. This is called spilling.

"IMC is medium level and a bit more friendly to write or debug. IMCC also has a builtin register allocator and spiller. IMC has the concept of a "subroutine" unit, complete with local variables and high-level sub call syntax. IMCC also allows unlimited symbolic registers. It will take care of assigning the appropriate register to your variables and will usually find the most efficient mapping so as to use as few registers as possible for a given piece of code. If you use more registers than are currently available, IMCC will generate instructions to save/restore (spill) the registers for you. This is a significant piece of every compiler.

"While it is possible to write more efficient code by hand directly in PASM, it is rare. IMC is still very close to PASM as far as granularity. It is also common for IMCC to generate instructions that use less registers than handwritten PASM. This is good for cache performance."

For a good introduction to Parrot, read Parrot: Some Assembly Required by Simon Cozens. There is a great article (also on ONLamp.com) Building a Parrot Compiler by Dan Sugalski (I have no idea why it wasn't posted on the Slashdot front page).

(By the way, for those who read off-line, here is a printable version of the linked Why Learning Assembly Language Is Still a Good Idea article in one piece.)

Performance is much more a matter of structure (exponential complexity) than language (poor linear complexity). As to level, "high level" languages limit you to their implementation of a few concepts. Depending on where the heavy lifting is, Perl could easily outperform optimized C.

Speaking about Perl and Assembly, it is important to mention that there are modern object-oriented assembly languages with asynchronous I/O, events, threads, multiple inheritance, garbage collection, built-in Unicode support, etc. See: Parrot Assembly, and IMCC:

"IMC stands for Intermediate Code; IMCC stands for Intermediate Code Compiler. You will also see the term PIR which is for Parrot Intermediate Representation and means the same as IMC, but for some each Parrot developer has his favorite term. PIR was the original term, where IMC seems to be the vernacular. It is an intermediate language that compiles either directly to Parrot Byte code, or translates to Parrot Assembly language. It is the preferred target language for compilers for the Parrot Virtual Machine. PIR is halfway between a High Level Language (HLL) and Parrot Assembly (PASM)."

"PASM is an assembly language, raw and low-level. PASM does exactly what you say, and each PASM instruction represents a single VM opcode. Assembly language can be tough to debug, simply due to the amount of instructions that a high-level compiler generates for a given construct. Assembly language typically has no concept of basic blocks, namespaces, variable tracking, etc. You must track your register usage and take care of saving/restoring values in cases where you run out of registers. This is called spilling.

"IMC is medium level and a bit more friendly to write or debug. IMCC also has a builtin register allocator and spiller. IMC has the concept of a "subroutine" unit, complete with local variables and high-level sub call syntax. IMCC also allows unlimited symbolic registers. It will take care of assigning the appropriate register to your variables and will usually find the most efficient mapping so as to use as few registers as possible for a given piece of code. If you use more registers than are currently available, IMCC will generate instructions to save/restore (spill) the registers for you. This is a significant piece of every compiler.

"While it is possible to write more efficient code by hand directly in PASM, it is rare. IMC is still very close to PASM as far as granularity. It is also common for IMCC to generate instructions that use less registers than handwritten PASM. This is good for cache performance."

For a good introduction to Parrot, read Parrot: Some Assembly Required by Simon Cozens. There is a great article (also on ONLamp.com) Building a Parrot Compiler by Dan Sugalski (I have no idea why it wasn't posted on the Slashdot front page).

(By the way, for those who read off-line, here is a printable version of the linked Why Learning Assembly Language Is Still a Good Idea article in one piece.)

You might want to look at the parrot project.
http://www.parrotcode.org/

Um, no, actually. It started off as a joke at the time, but since then Parrot has actually turned into a a real project which will run Perl 6 and, eventually, Python and other interpreted languages. (The Perl folks are in much more of a hurry to ditch their spaghetti Perl 5 VM, so that's priority #1. :-P) But there's some strong rumblings in the Python community about the Python port in progress, there are quite a few references to JVM bytecode translation and a Scheme port, and I've seen unsubstantiated rumors of Ruby and PHP ports. True, the core Python community isn't planning a switch yet, but if someday down the road the standard Parrot distribution comes with a Python frontend, people might start flocking to it for the one-stop convenience.

Programmers will be able to extend he syntax of programming languages,

Again, nothing new.

And also here.

Well... You are technically correct. I am only wondering whether talking about "syntax" in the context of Lisp isn't a little exaggeration. The true power of Lisp seems to be the apparent lack of syntax as we usually understand it and writing parsed trees by hand, to make writing bad code impossible.

and programs will be stored as XML documents so that programmers can represent and process data and meta-data uniformly.

There is no way in hell that would ever happen. Ever.

I agree. What people forget is that you can not win against entropy. By redefining problem in a different way you are not necessarily solving it.

Very true. Let us not forget the Conservation of Cruft Principle.

Does anyone even remember now KISS principal?

I don't think we've met.

> >Programmers will be able to extend the syntax of programming languages,
>Again, nothing new.

And also here.

>>It's a very insightful and thought-provoking read. Is this going to be the next generation of extensible programming?
>No.

I agree. What people forget is that you can not win against entropy. By redefining problem in a different way you are not necessarily solving it. Does anyone even remember now KISS principal?

An interesting article written by a professor at the University of Toronto argues that next-generation programming systems will combine compilers, linkers, debuggers, and that other tools will be plugin frameworks, rather than monolithic applications.

This is not the next generation of programming systems but rather the present one for pretty much everyone except for those using Microsoft tools.

Programmers will be able to extend the syntax of programming languages,

Again, nothing new.

and programs will be stored as XML documents so that programmers can represent and process data and meta-data uniformly.

There is no way in hell that would ever happen. Ever.

It's a very insightful and thought-provoking read. Is this going to be the next generation of extensible programming?

No.

Now, I will read the entire article, but somehow, I am not holding my breath...

Everyone is right here. There is no one language which is best for everyone. Perl 5, Perl 6, Ruby, Python, Lisp, Scheme... They are all going to target Parrot so we will be able to choose our favourite language and still work together instantiating our objects and even inheriting from each other's classes crossing the cross-language boundaries.

Wow! What a wonderful and innovative idea, totally unlike anything anyone has done before!

JVM is not exactly language-independent. It is not very well suited for dynamically typed languages such as Perl 5, Perl 6, Ruby, Python and in fact even for languages like Lisp and Scheme. Thought, with few exceptions like immutable strings or some uninheritable base classes, JVM is quite a nice environment for statically typed languages with simple single-inheritance object models like Java.

The Microsoft .Net on the other hand is not very platform-independent and I don't think it ever will be, while still supporting mostly statically typed languages. Besides, it didn't even exist at the beginning of Parrot project...

In any case, none of them runs Perl 5, Perl 6, Ruby, Python, Lisp and Scheme which I was talking about. So yes, Parrot is in fact totally unlike anything anyone has done before. Very true.

As long as you only want to write in slow interpreted languages, it's not a bad idea. Personally when I use Lisp I compile it to native code, and it runs FAST. When I use ML I compile it to native code, and it runs FAST. When I use Perl... I spend several minutes twiddling my thumbs. No thanks.

There is no such a thing as slow language. The only way in which a language per se can be slow is the parsing time. Of course Perl 6 having unprecedentedly rich (and even self-modifying) syntax will always be much harder to parse than Lisp which is basically a manually written parsed tree. However, you will always be able to compile it once and store Parrot bytecode or native binary. Even without compiling it to a native binary, there is JIT engine which can run critical parts of the bytecode as single assembly instructions on harware registers if you give enough hints to the compiler. See the files in parrot/jit directory in the CVS. It is really worth reading.

Please let us all keep in mind that only three years ago Parrot was merely an April Fool's joke (and quite brilliant at that). See the original Perl and Python Announce Joint Development press release on use Perl, the interview with Larry Wall and Guido van Rossum on Perl.com and the O'Reilly book announcement: Programming Parrot in a Nutshell by Guido van Rossum and Larry Wall. Does anyone remember the Perl + Python = Parrot Slashdot story? I am sure that back then absolutely no one was expecting that it might all come true some day. That's amazing how much has happened during those last few years.

ruby? Python? Kid's toys.

Common Lisp. Enough Said. Okay maybe Scheme, if you're a bit of a masochist...

Everyone is right here. There is no one language which is best for everyone. Perl 5, Perl 6, Ruby, Python, Lisp, Scheme... They are all going to target Parrot so we will be able to choose our favourite language and still work together instantiating our objects and even inheriting from each other's classes crossing the cross-language boundaries. A very impressive work has already been done in the 0.1.0 "Leaping Kakapo" version of Parrot. See: Parrot FAQ and the languages directory in the CVS.

ruby? Python? Kid's toys.

Common Lisp. Enough Said. Okay maybe Scheme, if you're a bit of a masochist...

Everyone is right here. There is no one language which is best for everyone. Perl 5, Perl 6, Ruby, Python, Lisp, Scheme... They are all going to target Parrot so we will be able to choose our favourite language and still work together instantiating our objects and even inheriting from each other's classes crossing the cross-language boundaries. A very impressive work has already been done in the 0.1.0 "Leaping Kakapo" version of Parrot. See: Parrot FAQ and the languages directory in the CVS.

In the name of the entire Slashdot community, I would like to thank Larry Wall for the absolutely amazing work he is doing. Thanks Larry! There are many people working very hard to make our dream come true and give us the most innovative and cutting-edge programming language in existance, which Perl 6 is soon going to be. It would not be possible without all of the Perl 6 and Parrot contributors. Please let us also not forget about brave people who still actively maintain Perl 5 and will keep doing it even after Perl 6 is ready. The Ponie project shows us that Perl 5 is not going away. The work of all of those people is invaluable. And this is all to give us free software development platform of the 21st century, while uniting Perl, Python, Ruby, Tcl, Scheme, Ook, Forth, Befunge, BASIC and many other languages thanks to Parrot, finally allowing them all to seamlessly work together and ending the flame wars between them. Thank you!

I have submitted a story but it was rejected, so please let me resubmit it as a first post instead.

The long awaited Apocalypse 12 by Larry Wall has been just announced by chromatic on perl6-language mailing list. It is one of the most important documents explaining the Perl 6 language design. (All of the previous design decisions are available as Apocalypses by Larry Wall, Exegeses by Damian Conway and Synopses by Luke Palmer, Damian Conway and Allison Randal.) Apocalypse 12 talks about Object Oriented aspects of Perl 6, i.e. about Objects, Classes, Roles (also known as Traits), Multiple Dispatch and also covers some non-OO decisions:

"The official, unofficial slogan of Perl 6 is "Second System Syndrome Done Right!". After you read this Apocalypse you will at least be certain that we got the "Second System" part down pat. But we've also put in a little bit of work on the "Done Right" part, which we hope you'll recognize. The management of complexity is complex, but only if you think about it. The goal of Perl 6 is to discourage you from thinking about it unnecessarily." --- Larry Wall.

(Lameness filter didn't allow me to post the table of contents. Reason: Please use less whitespace.)

You can access the entire document as a print friendly version. The standard version of Apocalypse 12 is divided into 20 parts. Enjoy.

If you are new to Perl 6 and Parrot, then Perl 6 Essentials by Allison Randal, Dan Sugalski and Leopold Tötsch might be a great introduction. The second edition should be published soon.

Python threads fail on FreeBSD

Python threads fail inside Apache

The VMU to which you refer is Parrot

to be the backend for Python and Perl and perhaps Ruby & TCL

Hardware support for languages is currently implemented in the x86 architecture to map the C language into one op instructions during assembly.

If you are interested in virtualization then you might be interested in Inferno. Which, when you read it, you'll see it is done the way it should be.

Parrot appears to be alive and well here. Version 0.1.0 was released on Feb 29th.

Currently at v0.1.0, awaiting Something Big in Perl 6, it would seem.

Yeah but an even cooler joke would be throwing something up that everyone thinks is an April Fool's joke, and then doing it for real. A meta-April Fool's joke, if you will.

You mean like Parrot?

Quoting from the Parrot FAQ:

The name "Parrot" relates to Simon Cozens's April Fool's Joke where Larry Wall and Guido van Rossum announced the merger of the Perl and Python languages.

Except now it's real, it's the already-implemented runtime engine for Perl 6, and the ability to run a variety of dynamic languages like Perl, Python, Ruby, PHP, etc is explicitly part of the design.

Heh... :-)

Yeah but an even cooler joke would be throwing something up that everyone thinks is an April Fool's joke, and then doing it for real. A meta-April Fool's joke, if you will.

You mean like Parrot?

Quoting from the Parrot FAQ:

The name "Parrot" relates to Simon Cozens's April Fool's Joke where Larry Wall and Guido van Rossum announced the merger of the Perl and Python languages.

Except now it's real, it's the already-implemented runtime engine for Perl 6, and the ability to run a variety of dynamic languages like Perl, Python, Ruby, PHP, etc is explicitly part of the design.

Heh... :-)

Do you mean Parrot?

Sun wants control. I say let them have control over their crappy language. May they keep it all to themselves, while we go on using something else. Something better. No, not .NET. That is more of the same. The OSS community has proved they are able to create better languages and development environments than Microsoft or Sun. We should instead make our own community driven language neutral VM, for example Parrot, establish our own standard high-level language, for example Python.

Who needs a half-assed effort, riddled with vendor lock-in?

At the moment I'm hoping Parrot succeeds and that every weakly typed language gets rewritten to run in it. Then instead of .NET's current strategy of mixing languages which all sucked, we can mix languages which don't suck.

Java's not a platform-friendly language, and as such will generally suck for writing platform-friendly apps. If you want your desktop to be a Java desktop, then fine, but if you're writing for other platforms I recommend writing the core of your application in C or C++ and the rest in Perl, Python, Scheme or one of the other languages that admits to platform specifics.

This will, of course, get much easier when all of those high-level langauges can talk to eachother through Parrot as a back-end. You'll be able to take advantage of Ruby's OO model, but accomodate a third-party library from CPAN in Perl and tie it all to a UI layer that your last project wrote in Python with no ugly transitions through object brokers or external executables. UNIX-like systems have benefited from this homogeneity for decades because of the fact that tools all have a common vision of the system, but libraries have as yet not been able to standardize on ways to communicate across calling conventions, interpreted vs compiled modes of execution and data / object models. With Parrot in that gap I see a bright future for desktop development in high-level languages (as well as many other areas).

Yes, high level languages improve productivity, and yes Java is has that attribute, but you should select a language that is the right tool for the job, and when writing desktop apps, Java is the wrong tool for most jobs.

how many times have you hacked something together in perl that ended up being relied on for some pretty important stuff, only to find 6 months down the track that there's some condition (db connects fine, but fails halfway through script execution as an example) you didn't consider and the whole thing just collapses in a heap - a nasty to recover heap cause you didn't write much logging code either.

The proper answer to this loaded and overly complex question is of course: "Countless." I did not need a "fault tolerant" shell, though, but real asynchronous I/O with good exception handling subsystem and events. That is why I look forward to Perl 6 and Parrot.

This would REALLY be useful when you're connecting to services external to yourself - network glitches cause more problems with my code than ANYTHING else, and it's a pain in the arse to write code to deal with it gracefully. i'd really really like to see a universal "try this for 5 minutes" wrapper, which, if it still failed, you'd only have one exit condition to worry about. hey, what the hell, maybe i'll spend a few days and write one myself.

Good luck then.