No, I had six months -- the benchmark wasn't written until early January this year, at which point I had more important things to do and put it off. For too long as it turned out, since I didn't even take a serious look at it until late May.
This was never a "Python people" vs "Parrot people" bet. It was personal, between Guido and me, and I didn't factor in enough time to allow for delays, so I lost.
Nah. we put that in to not scare people. Parrot is, for all intents and purposes, completely independent from Perl 6 and has been for ages. (well before that article was written). While we're going to put in anything we need to make perl 6 run on parrot, the same can be said of anything we need to run Python and Ruby. (Which has already happened, FWIW) The only difference is that Matz and Guido haven't asked for anything yet...
Do note that if the MS patent stands, it will potentially affect Parrot, as well as the JVM, Python's VM, Perl 5's VM, PHP's VM, Ruby's VM, and ghod knows how many Scheme and Smalltalk VMs. While the large body of existing work likely means we're safe (since, lets face it, none of us are doing cutting-edge stuff--this is all engineering, not science) a patent like this gives MS, or whoever owns it, a Big Stick to weild against any VM out there, which includes all the popular interpreted languages.
Yeah, and the python and ruby folks don't do Scheme either. True, a Scheme interpreter is a solution, but for a variety of social, political, technical, and engineering reasons it's not a good solution for the problem. (Parrot isn't a great solution as a Scheme interpreter either, so it goes both ways, of course)
Yup, we're doing continuations. We've actually switched to a full continuation-passing calling scheme, as it makes a number of things rather easier.
We have, however, hidden that in most cases, so you generally don't need to fiddle with, or even care about, continuations if you don't want to. They're certainly not exposed by default at the language level so the python folks, for example, will never have to deal with them. (Nor will the perl or ruby folks if they don't want to) It's only if you're writing assembly directly, and even then it's pretty darned easy to not have to think about them.
Choosing a Scheme VM would've meant we'd have chosen a VM written for a language that nobody in the perl internals development community is fluent in, and use it to implement a language that most of the folks I know of in the Scheme community view with a (at best) barely disguised loathing. Rolling our own was the least bad of the options available.
Ah, the "Parrot sucks" troll. I'd wondered if you were going to show up. Ignoring the things that the mono project has had that Parrot hasn't, like a number of paid employees and a full specification, (Microsoft did all the hard work there. And, alas, they did it wrong in a few places) who cares that mono's got more stuff?
Why are you so insecure that the very existence of another project gets you so worked up? Kinda sad, really, that you feel the need to spoil what should be a good brag moment for Miguel and company.
This is Miguel's announcement. Put your bile away and don't spoil it.
What, you mean besides two working BASIC interpreters, a Scheme implementation, Befunge-93, Brainfuck, and a partial perl 6 implementation? (Partial because the spec's not done) Nope, nothing at all to show for the work...;-P
You seem to be missing the point with some regularity. PMCs don't have to be written in C--they will be doable in parrot code if need be. And just because 64 bit integers will be done with PMCs doesn't mean that they won't be part of the core distribution, or a recommended library.
There's nothing particularly wrong with saying "You must have the X library/module/kit to do Y". Requiring the install of the.NET library to get full.NET functionality will undoubtedly be needed. (We're certainly not going to ship the full.NET core library with Parrot any more than we're going to ship the full Java core library) If we don't ship 64 bit ints as part of the core, they'll either be in the.NET library, or in an extended data type library.
What's next, will you start complaining next that we're going to require installing Postgres to access Postgres databases? (Or will the next complaint be about the bloated size of the distribution to provide the features that match your expectations?)
The Parrot calling convention POD was pulled a while back. No, it wasn't. PDD 3 is in, and has been for a long time. There have been minor revisions, but that's it--minor revisions.
Where's Parrot's 64 bit integer type? Inside a PMC, at the recommendation of the dotGNU folks. We'll stick the 128 bit, 256 bit, and 512 bit integers in one too, if we need them.
You *do* need some form of distributable bytecode library format No, we don't, not for perl, python, and ruby support. (Who was it whining about lack of focus earlier?) Bytecode files do work just fine for it anyway, however. Nobody said they needed to be structureless.
Threading issues *must* be considered from the very start Yes, I know. If you'd have bothered to do any research, you'd have seen the direction we're going, and you'd have realized that what we've done so far has no ramifications for our chosen threading model.
The only part of history repeating itself is the naysaying from people who've not done their research. If you're going to criticize, at least get it right.
no calling conventions yet for subroutines. Alas not true. They're in place and have been for quite some time.
no conversion opcodes for various builtin types Also incorrect--we've got them and have since the very beginning. What we don't have is low-level support for specific size integer and floats, since our target languages (perl, python, ruby) don't have them. Adding them adds no overhead, though, so they're going in since it'll make base.NET and JVM compatibility simpler.
non-perl languages expected to provide additional support in the form of C code libraries for their opcodes. Once again, incorrect. No external libraries are or will be required. We're turing complete and generally have a richer set of base semantics than.NET or the JVM does. This doesn't mean that someone can't choose to require an alternate set of opcodes if they want, but the engine doesn't require it.
no way to call out to C code This one's actually true. We've not gotten to that part yet, though it's on the list.
no equivalent of Java's jar file or CLR's assemblies for parrot library distribution Incorrect, bytecode files work just fine for this. That part of the design is somewhat incomplete, though.
way too many registers: their register based VM... requires a sophisticated compiler to do proper register allocation and needlessly complicates their VM Wrong yet again, sorry. Doesn't requore a sophisticated compiler at all. At best it requires some sophisticated register allocation algorithms. Luckily for us, those algorithms are old, known territory, which is why we've got them implemented already. So what if it makes the VM slightly more complex? (And it is only slightly more complex because of it) We're not writing something for CS101 here.
no consideration of threads in their design. Once again, incorrect, if you'd bothered to read any of the design documents. Threading isn't, at the moment, implemented because other things have been more important, but it has been thought about in the design.
1.5 for 7. Not too good there. Oh, and this:
seems that Parrot is too hung up on making the VM efficient
What drugs are you on? If we piss away efficiency in the design, no amount of clever coding will ever get it back. Maybe you're willing to sacrifice a factor of two in speed for "clarity" but so are nine of your friends. (To misquote the author of make) I, on the other hand, am not.
Finally
Or perhaps they should simply concentrate on getting Perl6 to work first. They need more focus. The project tries to be all things to all people, but ends up satisfiying no one.
If you'll look, you'll notice that perl 6 isn't fully designed yet, but the bits that are have been implemented.
Just because you can't (or won't, or don't want to) see the focus doesn't mean it's not there. It is, thanks very much, and we're well on track to do what we need and do it well. The design's flexible enough to pick up things like JVM or.NET compatibility without a loss of focus or efficiency, so there's no reason not to.
Re:how well O'Reilly deals with dead parrots
on
The Python Cookbook
·
· Score: 1
Yeah, but that parrot is actually alive and well, and doing nicely thanks.:)
Perl 6, at least good parts of it, are implemented now. There's no need to wait a few years. Hit dev.perl.org for details on CVS checkout and build instructions for Parrot, the perl 6 (amongst other things) interpreter.
Things are being taken in order. Each Apocalypse corresponds to a chapter in Programming Perl 3e. We'll get to objects, never fear. They're just not next.
There's nothing wrong with going to Ruby--it's a nice language and it fills a different niche than perl does. The nice thing is that it doesn't matter if you move to Ruby. Courtesy of Parrot, you're just a parser module away from perl 6...
Working on Perl 6, both the design and the software, is our job. That's what we do, and it's full time work plus some. It'd be great if we could work on it on the side, but that's not feasable--not for us or for almost anyone else.
Things the size of perl, or python, or ruby, or linux, or apache, take an enourmous amount of work, and the bigger the project gets the more work it takes. The folks doing the majority of the design work are already supported to do it in some way: Matz is paid to work on Ruby, Guido's paid by Zope to work on Python, Linus and many of the Linux folks are paid to do the work they're doing by their employers, and many of the Apache developers are being paid to work on Apache. And for large projects, like perl 5, where the lead is a full volunteer, they couldn't do what they're doing without a huge contribution and sacrifice by family.
We're trying a slightly diffrent approach, with direct grants rather than indirect ones, relying on the community to support us rather than, say, IBM or HP. And we're not asking people who can't make ends meet to donate money, but we are asking that people and companies that use perl to throw some cash into the hat.
It's a pleasant myth that large software projects can be done for free entirely in the spare time of volunteers, but that's never been true. Either companies have paid in one form or another for the work (knowingly or unknowingly) or individuals have sacrificed a lot of their personal lives to make it happen.
Parrot's been produced. While it's not yet finished, it is functional enough to work with, and work on. See the Parrotcode website for more details, or grab a snapshot.
Yes, the parrotcode website needs a bit of an overhaul--that was in progress when the slashdot splash hit....:)
Slashdot Mirror
No, I had six months -- the benchmark wasn't written until early January this year, at which point I had more important things to do and put it off. For too long as it turned out, since I didn't even take a serious look at it until late May.
This was never a "Python people" vs "Parrot people" bet. It was personal, between Guido and me, and I didn't factor in enough time to allow for delays, so I lost.
Nah. It's life imitating satire. But, then, when doesn't it?
Nah. we put that in to not scare people. Parrot is, for all intents and purposes, completely independent from Perl 6 and has been for ages. (well before that article was written). While we're going to put in anything we need to make perl 6 run on parrot, the same can be said of anything we need to run Python and Ruby. (Which has already happened, FWIW) The only difference is that Matz and Guido haven't asked for anything yet...
Because it runs on Win2K/WinXP. 128M in a Win2K machine leaves 418 bytes of RAM and some swap free for applications...
Would be? Was. Bring him back, that's my opinion, though Hugh Grant wasn't bad either.
If they're not bringing back one of the previous actors, maybe we'll get lucky and they'll get Rowan Atkinson...
Do note that if the MS patent stands, it will potentially affect Parrot, as well as the JVM, Python's VM, Perl 5's VM, PHP's VM, Ruby's VM, and ghod knows how many Scheme and Smalltalk VMs. While the large body of existing work likely means we're safe (since, lets face it, none of us are doing cutting-edge stuff--this is all engineering, not science) a patent like this gives MS, or whoever owns it, a Big Stick to weild against any VM out there, which includes all the popular interpreted languages.
Yeah, and the python and ruby folks don't do Scheme either. True, a Scheme interpreter is a solution, but for a variety of social, political, technical, and engineering reasons it's not a good solution for the problem. (Parrot isn't a great solution as a Scheme interpreter either, so it goes both ways, of course)
Yup, we're doing continuations. We've actually switched to a full continuation-passing calling scheme, as it makes a number of things rather easier.
We have, however, hidden that in most cases, so you generally don't need to fiddle with, or even care about, continuations if you don't want to. They're certainly not exposed by default at the language level so the python folks, for example, will never have to deal with them. (Nor will the perl or ruby folks if they don't want to) It's only if you're writing assembly directly, and even then it's pretty darned easy to not have to think about them.
Choosing a Scheme VM would've meant we'd have chosen a VM written for a language that nobody in the perl internals development community is fluent in, and use it to implement a language that most of the folks I know of in the Scheme community view with a (at best) barely disguised loathing. Rolling our own was the least bad of the options available.
Why are you so insecure that the very existence of another project gets you so worked up? Kinda sad, really, that you feel the need to spoil what should be a good brag moment for Miguel and company.
This is Miguel's announcement. Put your bile away and don't spoil it.
What, you mean besides two working BASIC interpreters, a Scheme implementation, Befunge-93, Brainfuck, and a partial perl 6 implementation? (Partial because the spec's not done) Nope, nothing at all to show for the work... ;-P
No supposedly--Parrot has a working JIT now. Dowload it from parrotcode.org and try it...
You seem to be missing the point with some regularity. PMCs don't have to be written in C--they will be doable in parrot code if need be. And just because 64 bit integers will be done with PMCs doesn't mean that they won't be part of the core distribution, or a recommended library.
.NET library to get full .NET functionality will undoubtedly be needed. (We're certainly not going to ship the full .NET core library with Parrot any more than we're going to ship the full Java core library) If we don't ship 64 bit ints as part of the core, they'll either be in the .NET library, or in an extended data type library.
There's nothing particularly wrong with saying "You must have the X library/module/kit to do Y". Requiring the install of the
What's next, will you start complaining next that we're going to require installing Postgres to access Postgres databases? (Or will the next complaint be about the bloated size of the distribution to provide the features that match your expectations?)
The only part of history repeating itself is the naysaying from people who've not done their research. If you're going to criticize, at least get it right.
- no calling conventions yet for subroutines. Alas not true. They're in place and have been for quite some time.
- no conversion opcodes for various builtin types Also incorrect--we've got them and have since the very beginning. What we don't have is low-level support for specific size integer and floats, since our target languages (perl, python, ruby) don't have them. Adding them adds no overhead, though, so they're going in since it'll make base
.NET and JVM compatibility simpler.
- non-perl languages expected to provide additional support in the form of C code libraries for their opcodes. Once again, incorrect. No external libraries are or will be required. We're turing complete and generally have a richer set of base semantics than
.NET or the JVM does. This doesn't mean that someone can't choose to require an alternate set of opcodes if they want, but the engine doesn't require it.
- no way to call out to C code This one's actually true. We've not gotten to that part yet, though it's on the list.
- no equivalent of Java's jar file or CLR's assemblies for parrot library distribution Incorrect, bytecode files work just fine for this. That part of the design is somewhat incomplete, though.
- way too many registers: their register based VM
... requires a sophisticated compiler to do proper register allocation and needlessly complicates their VM Wrong yet again, sorry. Doesn't requore a sophisticated compiler at all. At best it requires some sophisticated register allocation algorithms. Luckily for us, those algorithms are old, known territory, which is why we've got them implemented already. So what if it makes the VM slightly more complex? (And it is only slightly more complex because of it) We're not writing something for CS101 here.
- no consideration of threads in their design. Once again, incorrect, if you'd bothered to read any of the design documents. Threading isn't, at the moment, implemented because other things have been more important, but it has been thought about in the design.
1.5 for 7. Not too good there. Oh, and this: What drugs are you on? If we piss away efficiency in the design, no amount of clever coding will ever get it back. Maybe you're willing to sacrifice a factor of two in speed for "clarity" but so are nine of your friends. (To misquote the author of make) I, on the other hand, am not.Finally
If you'll look, you'll notice that perl 6 isn't fully designed yet, but the bits that are have been implemented.Just because you can't (or won't, or don't want to) see the focus doesn't mean it's not there. It is, thanks very much, and we're well on track to do what we need and do it well. The design's flexible enough to pick up things like JVM or .NET compatibility without a loss of focus or efficiency, so there's no reason not to.
Yeah, but that parrot is actually alive and well, and doing nicely thanks. :)
Perl 6, at least good parts of it, are implemented now. There's no need to wait a few years. Hit dev.perl.org for details on CVS checkout and build instructions for Parrot, the perl 6 (amongst other things) interpreter.
Things are being taken in order. Each Apocalypse corresponds to a chapter in Programming Perl 3e. We'll get to objects, never fear. They're just not next.
There's nothing wrong with going to Ruby--it's a nice language and it fills a different niche than perl does. The nice thing is that it doesn't matter if you move to Ruby. Courtesy of Parrot, you're just a parser module away from perl 6...
How long? That's hard to say. For a first cut, probably a week, maybe two.
Things the size of perl, or python, or ruby, or linux, or apache, take an enourmous amount of work, and the bigger the project gets the more work it takes. The folks doing the majority of the design work are already supported to do it in some way: Matz is paid to work on Ruby, Guido's paid by Zope to work on Python, Linus and many of the Linux folks are paid to do the work they're doing by their employers, and many of the Apache developers are being paid to work on Apache. And for large projects, like perl 5, where the lead is a full volunteer, they couldn't do what they're doing without a huge contribution and sacrifice by family.
We're trying a slightly diffrent approach, with direct grants rather than indirect ones, relying on the community to support us rather than, say, IBM or HP. And we're not asking people who can't make ends meet to donate money, but we are asking that people and companies that use perl to throw some cash into the hat.
It's a pleasant myth that large software projects can be done for free entirely in the spare time of volunteers, but that's never been true. Either companies have paid in one form or another for the work (knowingly or unknowingly) or individuals have sacrificed a lot of their personal lives to make it happen.
Yes, the parrotcode website needs a bit of an overhaul--that was in progress when the slashdot splash hit.... :)
I'll give them a call this week.
Besides, .NET is a proper subset of Parrot. The reverse is not true.