sidhe.org · Domains · Slashdot Mirror

About the "CLR sucks" referrence... by DrYak · 2006-09-07 00:12 · Score: 1 · on IronPython 1.0 is Born

First, thanks to Anonymous Coward for us lazy readers.

Then about the "CLR sucks" reference :

My initial motivation for the project was to understand all of the reports that I read on the web claiming that the Common Language Runtime (CLR) was a terrible platform for Python and other dynamic languages. I was surprised to read these reports because I knew that the JVM was an acceptable platform for these languages.

This was essentially people complaining that the first implementations for .NET didn't have all the features needed to compile Python and Perl straight into .NET bytecode. Some information about this can be found at Dan's blog (formely working on Parrot).
Perl and Python can do some weird kind of operations that aren't supported by C#. And because it was mainly built with C# in mind, the CLR machine lacks them (the "open to other language" is mainly PR stuff : Microsoft is basically not against the CLR being used to run other languages, but don't expect to find everything you need for it). The JVM happen to be a little bit more friendly (even if it was never advertised as such back then and was only initially intended to be used for Java).

What the people, who complained about CLR, wanted was to have scripts compiled into NET bytecode and then directly run inside the .NET interpreter, and just mix freel python/perl/java/C# at compile time.

IronPython is a solution around those limitation, and basically is something like rewritting a python interpreter in C#.
So you get your Python script ran inside a python interpreter which it self is compiled into bytecode that runs inside the NET interpreter. (But that's only the global over-simplified idea. Thanks to some optimizations, it doesn't run as slow as one may except, and also python script and C# classes can communicate).
One could mix python and C# if one includes the IronPython interpreter at compile time.
IronPython implements those part that are missing in the CLR engine. And some other parts were improved for the 2.0 version of the .NET framework.

The opposite approach is the one behind Parrot. It is designed as language-neutral from the ground up. Althrough it began it's life as "The software we're writing to run Perl 6", very early the project was going to be designed to run Python, and Ruby was considerated too. Wikipedia has some info about current status and projects collaborating to incorporate other languages.
Unlike IronPython the point is to compile Python scripts (and whatever else language) to Parrot bytecode, and then dirrectly run them from the parrot engine, mixed freely (and sharing data and classes) with whatever else language was thrown in the mix (1 single language binding to use whatever tool-kit. No more separated SDL#, PyGames, Perl::SDL, etc...) and easy communications with C libraries. An interpreter is only needed in the final compiled product if one needs to be able to support uncompiled scripts.
(Also, in addition to a large array of languages, the parrot aims to support a crazy large array of targets)

IronPython is somewhat reminiscent of the FSF saying that the GNU software could never be ported to DOS because of it limitations, and DJ Delorie writing DJGPP to get around those limitation and give a POSIX compatibility layer on MS-DOS.

Re:Parrot by Anonymous Coward · 2006-09-06 13:00 · Score: 0 · on IronPython 1.0 is Born

Yes, the CLR with its JIT can perform slightly better than pythons unoptimized C runtime. Big deal.

This post generated by hate (apparently) and if you're not a mono guy yet, they all think like you over there :-o

What happened to the Pie-Thon challenge ? by Anonymous Coward · 2004-07-31 01:34 · Score: 0 · on Complete OSCON Coverage

If I remember correctly Dan Sugalski was all set to EAT PIE in OSCON 2004. Did Guido Van Rossum hit him face on ?.

Parrot may not be fast enough yet, but it's the future of FreeSoftware VMs . (not a knock off .NET clone).

Perhaps he should have waited... by clintp · 2004-05-18 14:13 · Score: 3, Funny · on Super-Fast Python Implementation for .NET and Mono

Maybe he could have gotten in on the Great Parrot/Python Pie-a-Thon. Perhaps an opportunity to plaster both Guido and Dan with a cream pie...

Re:Parrot/Perl6 by sICE · 2004-03-11 19:05 · Score: 2, Informative · on Mono Poises to Take Over the Linux Desktop

I'm not very familiar with Parrot

If you want more informations about parrot and perl6, you might want to have a look at the mailling lists (parrot|perl), you can also access them via nntp at nntp.perl.org, or subscribe here. You'd perhaps perfer to browse the summaries of Piers Cawley.

For more documentation, consider the parrot's wiki, Dan Sugalski's blog, or even browse the source.

For the languages supported -- some are already functionnal, some not -- here's what i have in the last tarball i took: BASIC, Befunge-93, befunge, bf, cola, conversion, forth, imcc, jako, m4, miniperl, ook, parrot_compiler, perl6, plot, python, regex, ruby, scheme, tcl, urm.

Who said parrot didn't had fun?

Re:Why no ActivePerl? by JudasBlue · 2004-01-09 07:28 · Score: 1 · on Performance Benchmarks of Nine Languages

"In the article it rather sounds like they just assumed Python performance would be an indicator of performance for interpreted languages generally, but is there anything to back this up?"

No, there isn't. I will say upfront that I am heavily baised for Python, and do everything I can in it, but when it comes to raw speed, the last numbers I saw show that Perl is about twice as fast. Those benches are for python 2.1 tho, which is quite a ways out of date.

Since then, python in 2.3 has gotten about 30% faster and apparently the devs think that it can take Parrot.

However, I don't code in Python for raw speed, I code in it for productivity and maintainablity, and there it saves me a tremendous amount of time over most everything else, but your milage may vary. For the kind of stuff I do, I swig out to native C once in a blue moon, but mostly the speed thing isn't an issue for me.

Parrot vs Python by cpeterso · 2003-09-14 14:49 · Score: 5, Interesting · on Can Recent MS Patents Affect Mono and DotGNU?

Dan, the author of the Parrot VM, has a bet with Pythong's Guido van Rossum. Dan bet Guido that Parrot can execute pure Python bytecode faster than the Python interpreter can. The battle will be decided at OSCON 2004 in Portland, OR. He sounds pretty confident:

"Boys and girls, let's get this straight. I'm only going to say this once. Parrot is an order of magnitude faster than perl 5 doing equivalent things. Without enabling any extraordinary measures. You know how Python's performance rates against Perl 5. Do the math."

Dan's blog entry about the bet: http://www.sidhe.org/~dan/blog/archives/000139.htm l

Re:Scheme by makapuf · 2003-07-09 02:06 · Score: 2, Interesting · on Ponie: Perl On New Internal Engine

this blog seems to be very interesting about how and why continuations, coroutines, closures, and the usual suspects (microthreads, ..) will be implemented in Parrot, by one of the main contributor of Parrot (he wrote the book about perl6)

So ... RTFB

Re:Language is irrelevant by Lazarus+Short · 2003-05-13 15:05 · Score: 2, Interesting · on What I Hate About Your Programming Language

Soon we'll have Python.NET, Perl.NET, Ruby.NET, PHP.NET, etc, etc.

Actually, that's unlikely.

This blog entry by Dan Sugalski gives an expanation:

First things first--both the JVM and .NET are perfectly capable of being target machines. They're fully turing complete, so it's not an issue of capability. But, like the Infocom Z machine, which is also turing complete, the issue is one of speed.

Perl 5 has two big features that make using the JVM or .NET problematic--closures and polymorphic scalars. Perl 6 adds a third (which Ruby shares) in continuations, and a fourth (which Ruby doesn't) of co-routines. (Though arguably once you've got continuations, everything else is just a special case) Python has similar issues, though I'm not the guy to be making statements about Python, generally.