At 11:42 AM 5/24/2002 +0200, Sebastian Bergmann wrote:
>Leon Brocard wrote:
> > Oh, this happens to be a FAQ. The main reason is:
> >
> > http://www.parrotcode.org/faq/
>
> I know the technical reason for a new VM, but this could've been a new
> VM for Perl 6 only. What I'd like to know is the motivation to open up
> the architecture and allow for plugable parser, compilers, bytecode
> generators / optimizers, ...
Hi Sebastian,
Follows is some unedited musing from my uncompleted book. Feel free to
argue with my opinions, it'll only help me formulate them better. :)
I always look to the emotional side of these open source efforts that
replicate effort of commercial companies. I can only term it as
"pride of ownership" which many programmers have. It's the desire and
ability to be able to point and say, "Look what we did." I think it's a
trait very
common in our world of geeks and hackers, whatever you think those are.
That could be traced to ego of intellectual people, possibly, if I cared to put
a reason behind it, but I don't. I only care that duplicated efforts fuel
competitiveness and innovation. Granted, Parrot may not be innovative NOW,
but for me it fills a niche and I just like the feel of it.
In think for many the fact that we term Parrot a register based machine
causes concern, however, I've also noticed the majority of people I have shown
Parrot immediately warmed to that one fact. Maybe thats because most
of us started our Computer Science education on CPUs like Motorola or Intel,
which also have registers. This same, fetal imprinting argument is used
by functional language proponents, claiming that the only reason other
programmers like languages like C/Perl/Java are because they didn't learn
a functional based language first. I've always disagreed with that convenient
argument. Humans are just different, lets not try to put a spin on it that
implies
that some humans learned an inferior notation which just stuck with them,
wherease others were just fortunate to have begun their life enlightened.
My take on it are humans are visual, symbolic creatures, besides being
unique. I like to think of a hammer in my hand, a chisel in the other, nails
on the table, and a measuring tape in my pocket. The reason I can grab the
tape measure so fast is that my brain remembers symbolically, where I put it.
However, if I had more tools than I could easily handle, I could still remember
what I have in my hands, what is on the table and what is in my pocket.
Stack based machines actually do that very thing, just in a smaller scale.
The Java VM wouldn't be very fun without local variables to push and pop
with. Stack based VMs are just skewed towards the usage of the stack,
just like our register VM isn't a "pure" register VM. It's just skewed towards
usage of symbolics. Both types have much in common, and both types cater
to a separate strain of the Programmer.
To add to the above:
I hate debugging stack operations. Its one of the hardest bug's to spot
in my limited experience. For this reason I'm glad that Parrot allows me
to think in registers, not stack locations. Given, everything I've said
relates to a human generating or debugging instructions. Some would
the compilers are generating the code, so it shouldn't matter about notation.
In reality it does; when is the last time you heard of a compiler gaining
100% perfection in correctly generated, optimized code? It's always ongoing
work, in which people sit and debug what their compiler just generated in
order to go back and refactor.
> VM for Perl 6 only. What I'd like to know is the motivation to open up
> the architecture and allow for plugable parser, compilers, bytecode
> generators / optimizers, ...
Perl's motto "There Is More Than One Way To Do It" is just a natural
appreciation for variety and uniqueness, not enforcing too many constraints.
When I'm in Java-land, I just don't FEEL free, I'm sorry!
If Parrot can aim at the "sweet spot" and land somewhere close
I think it is only natural for open source languages to converge on
a common platform, if that platform is good enough. For languages
like Perl, Ruby, Python and TCL Parrot would only be a win because
ALL of these languages would run faster just be being targetted
to a precompiled VM. I think the evidence is in the JVM already, and
Parrot performance already indicates 4-5x speedup of Perl operations.
By targetting more languages to Parrot we are effectively doing
what .NET has done and what Mono is doing, but from the
other end of the candle. We are keeping dynamic languages in the
front seat, while trying to provide enough hooks and optimizations
to allow languages like C# to run reasonably. Where MS programmers
want to hop between C# and VB, I want to hop between C# or Java
and Perl, which in my opinion is a much more powerful combination.
I hope this blabbering helps you with a few ideas.
-Melvin
