Slashdot Mirror
Parrot 0.1.1 'Poicephalus' Released
Pan T. Hose writes "The long awaited release of Parrot 0.1.1 "Poicephalus" has been finally announced on perl.perl6.internals newsgroup and perl6-internals mailing list simultaneously by Leopold Toetsch followed by an announcement on use Perl by Will Coleda and now also on Slashdot." (Read on for a list of changes since the last release, as well as a number of useful links.)
Pan T. Hose continues "The most important changes since the previous version 0.1.0 (code-named 'Leaping Kakapo' and
released in February) are:
- Python support: Parrot runs 4/7 of the pie-thon test suite
- Better OS support: more platforms, compilers, OS functions
- Improved PIR syntax for method calls and <op>= assignment
- Dynamic loading reworked including a "make install" target
- MMD - multi method dispatch for binary vtable methods
- Library improvement and cleanup
- BigInt, Complex, *Array, Slice, Enumerate, None PMC classes
- IA64 and hppa JIT support
- Tons of fixes, improvements, new tests, and documentation updates
I am especially interested in python support. I love python but it is some times a tad bit slow. I've seen lots of interesting initiatives to really improve performance (the starkiller python to C++ "compiler" for example), and am now very curious to see how good this one will perform. Besides, it would be quite funny to have perl and python united :-)
Why a new VM? Jython showed it is possible to "recycle" the java VM. Can anybody explain why this is better?
10 ?"Hello World" life was simple then
...that would compile Ruby programs into intermediate compiler code so they could be run on Parrot.
He's done a few releases and appears to be making good progress here.
The Army reading list
The Virtual Virtual Machine is, if I understand correctly, a virtual machine to build virtual machines.
-- Did you try Tao3D? http://tao3d.sourceforge.net
Parrot is a very interesting project indeed, and it looks as if it is now starting to seriously pick up steam. What we're looking at here is VM that works, and is optimised for Perl, Python, Ruby, Forth and all those other lovely scripting languages.
.NET and Java vs. C# people seemed to have missed Parrot creeping up from behind. Potentially Parrot can pull together Perl, Python and Ruby - imagine CPAN that works with all of those languages at once, but pulls in all the interesting Python and Ruby libraries too.
.NET via Mono or Java via JVM shoudl start considering Perl/Python/Ruby via Parrot as a very serious choice for doing the high level application programming.
Given all the current debate raging over JVM vs.
In general scripting languages have been looked down upon, but realistically the gap between scripting languages (and what you even mean by "scripting language") has been drastically narrowed to the point where it is increasingly less relevant. The only serious remaining issue is speed - and that's something Parrot can help fix, putting Perl, Python and Ruby code on a similar footing as Java and C# code running on their VMs. You'll take a small hit for using a higher level language, but it won't be as drastic as it is now.
Maybe all that GNOME discussion about
Jedidiah.
Craft Beer Programming T-shirts
Yes. You should be able to use libraries freely no matter what language they were written in, so python users get to use CPAN, perl users get access to RAA, and so on... it's all bytecode in the end. :)
;-) (Evals might be able to give a language as a parameter if I understood it right).
Potentially, you might even be able to switch and mix languages mid-file too, though that probably is not useful all that often.
Spine World
With so many open source language implementations around these days, developing a VM that any of them can take advantage of is a fantastic idea.
One focussed effort on providing efficient JIT compilation will improve performance, and similarly this one layer to address portability could do more to break down OS barriers than java managed.
I'm excited about Parrot just for that, but if there is any possibility that different languages will be able to make use of libraries written in others, then that would be the icing on the cake. I can't tell if it should be possible, but if I could make use of someone else's library written in their favourite languge, from my favourite languge (by virtue of them both running on Parrot), software would be a whole lot more fun.
Really.
Parrot's runtime sounds a whole lot like what Mathematica does internally: dynamically typed language which compiles JIT into a bytecode for a register-windowing VM.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
This is really a performance issue, not a type safety issue. If type safety is particularly important, then type checks can be done at run time. However, doing these type checks at run time has a run time performance cost. Doing these same checks at compile time means that compiled code will run that much faster since no type checks are being performed at run time.
Certain types of programs really benefit from compile time type checking - specifically, those where inputs are known at compile time, or are known to be of certain types, or are known to be safe (i.e., inputs are not coming at your program across the wire from a potentiall hostile source - think any web app that takes free form input from users).
It could be argued that in the modern GUI/networked era, many apps are going to be doing lots of run time checking anyway because they are exposed to data inputs from potentially hostile users on a WAN - i.e., the internet, and they are at the mercy of user GUI inputs (bizarre mouse clicks and drags, bogus text or numeric field entries, etc.). That being the case, being able to do type inference and compile time type checks doesn't buy one much in terms of saftey or performance for any such app, since you'll be doing lots of run time type checks on user input data anyway.
IMHO, the idea of compile time type inference and type checking is born of a model of computing that is becoming obsolete. It was how most computation was done just a few decades ago - the programmer controlled the input closely, and so could guarantee inputs of certain types in certain ranges, etc. We have now moved into an era where the most interesting inputs are essentially unknowable at compile time - these are user inputs, whether GUI, keyboard, or network in origin. Just as importantly, user choice destroys the notion of a fixed algorithm executing in a predicable fasion. We simply can't know what direction our programs will take once we allow the user sufficient choice in shaping the programs execution. This being the case, and increasingly so as we go forward, I think that compile time type checking is a backward looking paradigm for programming languages.
See Peter Wegner's home page for some related ideas on new ways of thinking about what it is that a program really does in the modern interactive GUI/network era.
There is nothing inappropriate in poicephalus as e.g. poicephalus gulielmi is just a Latin name of Red-fronted Parrot, well known for every bird lover, just like agapornis pullarius is a Latin name of Red-headed Lovebird, another proposed code-name for this release. You are probably thinking about phallus for some reason but instead of looking for Freudian connotations you might want to read more about parrots.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
Sterling Hughes and Thies Arntzen are working on getting PHP to parrot with their project Pint. They want some stuff in PHP and parrot would fit perfectly, but havin access to modules from perl or pythong is a nice extra bonus.
b4n
A few comments: .NET did exist when Parrot was announced, and more .NET into an ECMA .NET is designed for compiled languages as much
.NET provides a lot of
.NET can execute dynamic Python code as fast or
importantly the work to turn
standard had started way before this.
as the x86 is designed for compiled languages
(in fact the x86 is strongly typed and knows about
two types: ints and floats, nothing else).
So anyways, for those who can see further than
the end of their noses,
sugar for strongly typed OO languages, but it
requires a strong effort to be as naive to think
that dynamic languages are not supported.
In any case, IronPython has demostrated that
faster than the Python interpreter itself.
So those two stated reasons for Parrot are rubbish.
On the other hand, its perfectly fine to say
`We wanted to do something different' or `we
wanted to do our own thing'. Nothing wrong with
that.
Miguel.
You rock. If i hadn't already commented I would have modded you straight to the top! :)
.net will be microsoft's destruction? If open source oses can run .net then why pay for windows? Microsoft has controlled the market because they have controlled the implementation of the most popular API - win32. Sure, they will try and control their new API, .net by things like windows forms that are tightly coupled with win32 - but how long till there is a viable opensource alternative? So i'm guessing microsoft's drawcard is palladium. Digital media is their leverage.
The answer, as far as i understand it, is YES! It's going to be bloody brilliant to be able to use the CPAN libraries from any language.
But it makes me wonder if
I guess we'll see how it pans out.