Is Parrot 1.0 too late?
Nikolay Ananiev
That's a lot of time and many things have changed since then. From my point
of view one of the biggest strengths of Parrot is that it's a target for
many (and why not all?)
dynamic languages and as I know there's no other VM like it. Well... since
now.
Check this article: http://blogs.zdnet.com/microsoft/?p=404
Microsoft announces a dynamic layer for CLR, so they will be able to
support dynamic languages on their VM.
And JVM 1.6 already has this, plus it's opensource and has
support for the mainstream platforms.
So, is one of parrot's biggest strengths gone? Are we too late?
Why would the developers use Parrot instead of JVM/CLR/Mono?
Allison Randal
>
> So, is one of parrot's biggest strengths gone? Are we too late?
> Why would the developers use Parrot instead of JVM/CLR/Mono?
We're certainly pleased that we kicked off a revolution in virtual
machines, and that others are beginning to catch on to the fact that
they'll have to support dynamic languages to compete. But, it would be a
little silly to throw in the towel just when others are beginning to
follow your lead. (And I do mean beginning. They're making great
strides, but I still hear strange comments like "We support all features
of dynamic languages. Of course some features, like multiple
inheritance, may be slow, but we don't encourage the use of those
features." from the JVM team.)
The plan to run Perl, Python, PHP, Ruby, etc. is not the only innovative
feature of Parrot. To list a few:
- PGE provides parsing tools that are light years ahead of what's in
common use today (what's commonly used today hasn't seen much in the way
of technological advances in the past 20 years).
- TGE is a powerful tool for manipulating trees of data, like the output
of a parse, or an abstract syntax tree (think of it as XSLT on steroids).
- Those parsing and transformation tools are valuable both for writing
compilers and for data processing tasks (handling database output,
screen scraping, combination and modification of Atom streams in an
AJAXian way, etc.), giving a big boost in ease of use for both areas.
- Parrot is a register-based virtual machine instead of stack-based like
.NET, Mono, JVM. Register-based machines require fewer instructions to
complete the same operations (no need to push and pop the stack),
eliminating some unnecessary overhead. JIT-ed code is also
register-based (since the actual machine under the virtual machine is
register-based), so the register-based bytecode makes that
transformation simpler.
- Parrot moves beyond the fragile stack-based control flow common to
virtual machines today, to a continuation-based control flow. (I can
recommend a few good books and articles if you're curious.)
While the other VMs are catching up to supporting the features of
dynamic languages from 10-40 years ago, we plan to open the way for a
whole new breed of dynamic languages. Will others follow our example? I
won't complain if they do. "Imitation is the sincerest form of flattery."
Allison
Chromatic
> Why would the developers use Parrot instead of JVM/CLR/Mono?
Parrot is open source today, not *mumble* down the road like the JVM will be.
Parrot supports more dynamic features than only "find method by name at
runtime".
Parrot doesn't have (obvious) patent issues.
I have commit access.
Okay, that last one isn't a serious reason either way,
-- c
Joshua Juran
> On Tuesday 24 April 2007 15:31, Nikolay Ananiev wrote:
>
>> Why would the developers use Parrot instead of JVM/CLR/Mono?
>
> Parrot is open source today, not *mumble* down the road like the
> JVM will be.
Parrot is also widely portable, much like perl is. This one's
especially important to me, as I still work with Mac OS 9.
> Parrot supports more dynamic features than only "find method by
> name at
> runtime".
Unix user shells have had that for decades. It's called 'execvp()'. :-)
Josh
Nikolay Ananiev
ready for the mainstream and won't be ready in the next two years (maybe?).
That's a lot of time for commercial projects like CLR and JVM and
the competition between MS and Sun is quite serious, so I expect
the dynamic features in their VMs to progress very fast. I'm also afraid
they have the resources to create compiler tools comparable to PGE and TGE
(you know that MS can always steal).
I think in 2-3 years CLR and JVM will be a serious competition to Parrot
and I just hope people won't say "uh, another VM for dynamic languages"
about Parrot 1.0.
Maybe we have to search harder for new ways to advertise Parrot to other
communities and get new developers and supporters to the project.
Currently, Parrot looks too Perlish and is mainly supported by the Perl
community.
I think that has to change.
"Allison Randal" <all...@perl.org> wrote in message
news:462EEE7F...@perl.org...
Nicholas Clark
> Parrot is also widely portable, much like perl is. This one's
> especially important to me, as I still work with Mac OS 9.
Parrot builds on Mac OS 9? Cool
It's not listed in PLATFORMS, so I wasn't sure.
Nicholas Clark
Joshua Juran
No -- I haven't even attempted it yet. I'm still developing the Unix
emulation layer, Lamp (Lamp Ain't Mac POSIX) on which it will run,
including the kernel and prerequisite userland utilities -- one of
which is perl.
Just this weekend I ported Lamp to 68K, and after a little assembly
hacking and refactoring yylex() into small enough chunks, perl made
the trip as well.
Once I get perl further along (as right now it's only miniperl -- I
haven't written dlopen() yet) and add some missing features to the
shell, I'll take on building parrot. Chances are, if it works on
CygWin, I can make it run in traditional Mac OS -- on both
architectures.
Josh
Nicholas Clark
> Maybe we have to search harder for new ways to advertise Parrot to other
> communities and get new developers and supporters to the project.
> Currently, Parrot looks too Perlish and is mainly supported by the Perl
> community.
> I think that has to change.
Do you have any ideas on how to achieve this?
I guess that the most obvious current thing that ties Parrot to the Perl
community is that Parrot requires a copy of Perl to bootstrap, and all the
build tools are written in Perl 5.
I know that Perl 5's build system attempts to get a minimal Perl 5 binary
bootstrapped as early as possible, and then does the rest of the build using
Perl 5 programs running on it. I've just tried out Ruby, Python and Lua.
Akin to Perl, Ruby builds a miniruby, and then uses that to build the
extensions. Python doesn't build a minipython, but does use the Python binary
as part of the extension build process. Lua is the odd one out - it doesn't
ship with a Configure script, just a Makefile, and doesn't appear to build
anything outside the main source directory.
So Parrot is the odd one out here, for relying on an external language for
its extended build process. I'm not sure if this is significant.
Nicholas Clark
Herbert Snorrason
> So Parrot is the odd one out here, for relying on an external
> language for
> its extended build process. I'm not sure if this is significant.
Isn't Parrot more comparable to JVM and CLI in this regard, in that
it's a theoretically language-independent VM, while the examples you
mention are very specifically tied to one single language? So it
wouldn't be unexpected that it's the odd out?
- A nitpicking lurker.
Allison Randal
>
> I guess that the most obvious current thing that ties Parrot to the Perl
> community is that Parrot requires a copy of Perl to bootstrap, and all the
> build tools are written in Perl 5.
This is slated to change before the 1.0 release.
Allison
Nicholas Clark
Not entirely
Perl 5 is really Perl 5/Perl 5, Java is Java/Java, in the sense of C#/.NET
The distribution provides both a language and a virtual machine, although
that virtual machine is not really accessible apart from via the language of
the same name. Java toolchains are written in Java, although I admit that I
don't know how early Java is used during the building of a Java VM from
source. But I don't see a fundamental reason not to write more of the Parrot
build system toolchain in a language that runs atop the Parrot VM, rather
than the Perl 5 VM, over the long term.
(In the shorter term, the Perl 5 code works, and change for the sake of
change itself is make-work, and a distraction from progressing other areas,
such as implementing PDDs, and exterminating bugs)
Nicholas Clark
Allison Randal
> Yes I know about Parrot's great features, but Parrot is still not
> ready for the mainstream and won't be ready in the next two years (maybe?).
> That's a lot of time for commercial projects like CLR and JVM and
> the competition between MS and Sun is quite serious, so I expect
> the dynamic features in their VMs to progress very fast. I'm also afraid
> they have the resources to create compiler tools comparable to PGE and TGE
> (you know that MS can always steal).
That's a possibility, but what are you afraid of? This is how open
source software works. We develop in the open to promote the greater
advance of all technology. We don't hoard our advances in the fear that
others will use them (that's what proprietary companies do).
One of the greatest advantages of the open source model is the fact that
Parrot isn't tied to a particular company's profit strategy. This gives
us a much greater flexibility to take bold risks on new technology. I
expect that this will keep Parrot consistently ahead of the CLR and the
JVM. They have more resources to throw at it, but they also have strong
motivations not to radically change their architecture.
But, there's really no way to be certain how the game will play out
until we play the game. If poker players all threw in their cards as
soon as they were dealt, it would make for a pretty boring game.
> Maybe we have to search harder for new ways to advertise Parrot to other
> communities and get new developers and supporters to the project.
On that I completely agree, but as a simple matter of practicality, not
some desperate bid for market dominance. If you want to recruit new C
developers, you go where C developers hang out. (chromatic and I are
speaking at a Linux conference this weekend.)
> Currently, Parrot looks too Perlish
On that I completely disagree. Parrot looks very Perlish because it's
highly dynamic and intended to be easy to use (which happen to also be
goals of Perl). This is an advantage.
> and is mainly supported by the Perl
> community.
That's not really an advantage or disadvantage, it's an accident of
history. And, probably also a sympathy of vision.
Allison
Jonathan Worthington
Configure system and build tools into something that compiles down to
PBC (and then just ship something very basic that can run a PBC). I
don't think PIR is the thing to translate them to though - Configure and
the build tools are fairly big things. You don't want to be doing that
in an intermediate language. Well, I sure don't anyway, and I'm sure I'm
not alone in feeling this way.
One option would be a HLL that maps very closely down to the features of
Parrot, but really is a high level language. I say maps down closely
because then you don't have to worry about matching the semantics of
some existing language, making it somewhat simpler to Get Done.
Another option is for any of the HLLs in languages/ to get to the stage
where we can port Configure to them. OK, well, not BF. ;-) But then you
have the advantage of it being a language that some people already know.
Of course, we may run into the fun of "we should do it in X because it's
my favorite language" kinda things, if we have multiple Parrot-targeting
HLLs in shape by then. Though the simple answer to that is to make a
decision and tell people to put up with it. :-)
IMHO, etc.
Jonathan
Jonathan Worthington
> I guess that doing so will involve re-writing a lot of the current
> Configure system and build tools into something that compiles down to
> PBC (and then just ship something very basic that can run a PBC).
ANSI C or something. Long day...
Jonathan
Nicholas Clark
I like this approach. It feels viable.
Nicholas Clark
Jerry Gay
whatever it will be called) will be c89 at it's core, with the minimum
of platform-specific extensions (only where neccessary.)
one thing we must do is get away from using perl 5's configure
information. this is something we can do now--we just need somebody
with knowledge of perl 5's configure system and somebody with
knowledge of parrot's configure system to get together and Just Do It.
any volunteers? i'd be happy to be the parrot coder. i know enough
about parrot's configure system to be dangerous; i know nothing of
perl's configure system, however.
~jerry
Joshua Isom
build on a PDP-10, although I haven't tried it yet in an emulator. Of
course, some tweaking may be necessary, but that would only increase
portability!
Joshua Isom
obvious dependency on having a make that can read a generic makefile,
and a c compiler that can compile to the running architecture
successfully(cross compiling would come later). We can limit what goes
into parrot, which pmc's, etc, and try to get a miniparrot that's works
with a fairly default makefile for bootstrapping. Type make, then
whatever configure script, then make again to build a full parrot? It
would help our external dependancies go down to what's an expected
dependency, make, and cc.
The main things to consider is how much we'd need inside miniparrot.
Nicholas Clark
> I think that would be more work than truly necessary. We have an
> obvious dependency on having a make that can read a generic makefile,
No.
It is possible to bootstrap without any make-like utility.
The lowest common denominator way of doing it is to take the sources to the
ANSI C microparrot, linearise the dependencies on a machine with a running
parrot, and write out a C program that uses system() to execute commands in
order in the source directory to build that microparrot.
A slightly more sophisticated version would check whether the target exists
first, and skip until a target does not.
However, having a make like utility is easier. Lua seems to go for that
approach.
Nicholas Clark
Joshua Juran
> Aiming to be as ANSI C compatible as possible will help to make it
> build on a PDP-10, although I haven't tried it yet in an emulator.
> Of course, some tweaking may be necessary, but that would only
> increase portability!
Oh, and I forgot to mention: With Parrot, you have the Perl
community's legendary sense of humor.
Hey, at least Mac OS 9 uses ASCII... *ducks*
Josh
John Siracusa
I think the role Parrot aims to fill is remains unfilled, although it is
being approached from both sides. Check out this LLVM presentation, for
example:
http://llvm.org/pubs/2007-03-12-BossaLLVMIntro.html
Look towards the ends of the slides:
http://llvm.org/pubs/2007-03-12-BossaLLVMIntro.pdf
An excerpt:
Call for help!
OSS community needs to unite work on various scripting languages
Common module to represent/type infer an arbitrary dynamic language
Who will provide this? pypy? parrot? llvm itself someday ("hlvm")?
HLVM is actually in progress:
Judging by how fast LLVM has progressed since Apple's been backing it
(almost two years now) LLVM/HLVM may be something to watch (or work with...)
-John
Chromatic
> Judging by how fast LLVM has progressed since Apple's been backing it
> (almost two years now) LLVM/HLVM may be something to watch (or work
> with...)
A couple of Parrot committers have a pretty good contact with an LLVM
hacker....
-- c
Andy Bach
a
Andy Bach
Systems Mangler
Internet: andy...@wiwb.uscourts.gov
VOICE: (608) 261-5738 FAX 264-5932
"So it goes ...."
Kurt Vonnegut, Jr. (November 11, 1922 ? April 11, 2007)
Mike Mattie
Allison Randal <all...@perl.org> wrote:
> Nikolay Ananiev wrote:
>
> > Maybe we have to search harder for new ways to advertise Parrot to
> > other communities and get new developers and supporters to the
> > project.
>
> On that I completely agree, but as a simple matter of practicality,
> not some desperate bid for market dominance. If you want to recruit
> new C developers, you go where C developers hang out. (chromatic and
> I are speaking at a Linux conference this weekend.)
>
> > Currently, Parrot looks too Perlish
>
> On that I completely disagree. Parrot looks very Perlish because it's
> highly dynamic and intended to be easy to use (which happen to also
> be goals of Perl). This is an advantage.
I also disagree here quite strongly. I trust the perl community above
all other communities because it is unique in one respect. "There is more
than one way to do it".
The world is simply to complex to be crammed into a single paradigm
without having horrible blow-outs of *artificial* complexity all over
the place.
I like to use OO for some parts of a problem, more functional approaches
in others, and to bundle it all into a usable program there is only
one language: perl. With parrot I will be able to use multiple languages
with paradigm freedom. That is important to me as no superlative can convey.
Despite the generally higher intelligence of programmers, or maybe
because of it ... programmers are sucked into paradigm zealotry
to a degree that could be classified as cultish in human
behavior. Another explanation is that a paradigm is an investment,
once a developer "pays" for a paradigm they are reluctant to adopt
another.
Either way you cut the paradigm thing the only community in programming
that does not immediately trigger a full recall of Orwell's 1984 is the
perl community. Lisp does too, but by allowing you to create paradigms
with macros :)
so parrot is double-plus good. Truly adopting paradigm freedom requires
an intellectual transformation and commitement, no more training wheels,
no accepted practice to offer as an excuse for how things are written.
That and you have to use your own judgement case-by-case.
That will not come from places like Microsoft :)
Look at C#, java , they don't need to send mind-police , it's built
into the compiler.
This may sound elitish, but it is really not. It is easier , alot
easier to just apply the same old cookie cutters (patterns ?) to
every problem. Sometimes it makes good sense. But for the people
who are always feeling boxed-in by language paradigms I think
perl/parrot is where they will call home.
With perl 6 especially the quirky evolutionary flavor of perl 5
is replaced with a very clean language design. The only thing
left to turn people off will be the availability of choice.
In summary until microsoft/sun anoints Bruce Lee as their official
hero , with posters in every hall nothing like parrot will ever
come from those places. It's really hard to sell "having no way as
the way" as a industry band-wagon.
> > and is mainly supported by the Perl
> > community.
>
> That's not really an advantage or disadvantage, it's an accident of
> history. And, probably also a sympathy of vision.
There is sympathy with that vision here.
> Allison
James E Keenan
Since November I've been working on maintaining those of Parrot's
configuration and build tools written in Perl 5. Lately I've been
trying to recruit others to help in that process. The discussion in
this thread suggests that at some future point some or all of the Perl
scripts/modules I've been working on will be replaced with ... something
else.
This, of course, makes me wonder what I'm doing now and, more
importantly, makes me wonder what to say to other people with Perl 5
skills who want to help with the Parrot project.
This is not simply an ego thing on my part. I've written very little of
the Perl 5 tools and taken on maintenance of a bit more, but one thing I
realize is how much of Parrot's source code is written in Perl 5. How
much of that must eventually be replaced?
And who is going to maintain it? In my experience Perl 5 programmers
are relatively abundant while C programmers (these days) are rarer. How
many people might actually learn the yet-to-be-designed HLL that would
presumably replace a lot of the Perl 5 we currently use?
So, can someone draw a roadmap of:
-- *which parts* of Parrot's configuration and build tools *need* to be
replaced with something else;
-- *why* that replacement is necessary;
-- *when* in the design process that replacement must take place; and
-- *how* that replacement will be maintained going forward from there?
If this is already discussed in some of the design documents, I would
appreciate a link. Thank you very much.
kid51
Joshua Isom
Everything using perl5, since parrot will ultimately help to get rid of
perl5, until a perl5 port comes along. You could theoretically use
perl6, but that would presently hurt portability(since pugs uses ghc).
> -- *why* that replacement is necessary;
>
There won't be a perl5 to depend on. Currently, building perl5
requires perl5, which can be difficult with porting. Plus parrot's
config is greatly dependent on perl's config instead of having it's own
config.
> -- *when* in the design process that replacement must take place; and
>
I've never heard of a timetable for this one. I know it's been a goal
for a long time now. I've often thought about the various ways to
cleanly bootstrap parrot with as few external dependencies as possible,
and to make those dependencies as generic as possible. But I have so
little time available so have never got to the point of actually coding
to see how to do a clean bootstrap, so no reliance on an installed perl
or parrot.
> -- *how* that replacement will be maintained going forward from there?
>
With the right abstraction in the right points, a proper directory
layout, and good documentation, it'll be good. Plus, starting from
scratch is always a good thing, sometimes...
> If this is already discussed in some of the design documents, I would
> appreciate a link. Thank you very much.
>
> kid51
>
>
I think the first step would be to decide how to bootstrap a miniparrot
easily, either via a generic makefile and a predefined config.h, or a c
program to probe and build whatever. Actually implementing that step
wouldn't need to be immediate. Then to figure out what the bare
minimum of parrot would be needed, most likely be writing a
Configure.pir set of code(and if we abstract enough, other programs
like perl6 and ruby would use it for whatever configuration they need,
such as for building dynoplibs and dynpmcs). Then we'd just need to
build a parrot that can support just that, which wouldn't require any
jit, or cgp cores, or have to deal with threading. Plus that so called
miniparrot could also be used some for an embedded parrot.
After knowing what's needed to configure for parrot, the next step is
probably the build tools. We know we our aim is to replace perl5 in
the long run, and that perl5 won't be available eventually(how many
systems contain perl4?).
Other than "parrot will eventually use miniparrot to configure and
built itself" I don't believe there's been a lot of discussion of just
how to go about it. All I've had time to do is ponder how to do it
cleanly.
Allison Randal
>
> Since November I've been working on maintaining those of Parrot's
> configuration and build tools written in Perl 5. Lately I've been
> trying to recruit others to help in that process. The discussion in
> this thread suggests that at some future point some or all of the Perl
> scripts/modules I've been working on will be replaced with ... something
> else.
This has been the plan all along. Unfortunately it's not documented in
detail anywhere, but it has appeared in multiple mailing list
discussions over the years.
<http://www.nntp.perl.org/group/perl.perl6.internals/2007/02/msg36493.html>
<http://www.nntp.perl.org/group/perl.perl6.internals/2007/02/msg36593.html>
We can't depend on Perl 5 because we're replacing it.
> This, of course, makes me wonder what I'm doing now and, more
> importantly, makes me wonder what to say to other people with Perl 5
> skills who want to help with the Parrot project.
Agile development in action. We can't know the full set of requirements
for the build system until we have a working build system. And we can't
delay all development waiting for the perfect build system. So we work
in stages of refinement. Your work here is enormously helpful.
> This is not simply an ego thing on my part. I've written very little of
> the Perl 5 tools and taken on maintenance of a bit more, but one thing I
> realize is how much of Parrot's source code is written in Perl 5. How
> much of that must eventually be replaced?
How much needs to be replaced depends on the strategy we take. One
possibility is to take some of the core pieces, make any minor
modifications needed to run on Parrot's implementation of Perl 5, ship
them as compiled bytecode, and run them on miniparrot. There are
advantages and disadvantages to a bootstrapping strategy like this, it
will work for some parts of the build system but not for others.
Some parts of the build system can be run on the maintainer side rather
than the user side. So, the release manager and developers can have a
dependency on Perl 5, while the end users get pre-generated C files and
so avoid the dependency. (Similar to the current strategy for IMCC where
individual users of Parrot don't need lex and yacc.)
Some parts may be written in PIR (again, only those parts that are late
enough to have a working miniparrot).
> And who is going to maintain it? In my experience Perl 5 programmers
> are relatively abundant while C programmers (these days) are rarer. How
> many people might actually learn the yet-to-be-designed HLL that would
> presumably replace a lot of the Perl 5 we currently use?
Agreed, we don't want to write an entire build system in C. It's a
horrible language for the kinds of dynamic effects we need in the build
system. Some parts will be in C, but just enough to get miniparrot started.
> So, can someone draw a roadmap of:
>
> -- *which parts* of Parrot's configuration and build tools *need* to be
> replaced with something else;
>
> -- *why* that replacement is necessary;
>
> -- *when* in the design process that replacement must take place; and
>
> -- *how* that replacement will be maintained going forward from there?
The biggest thing we need to start this roadmap is documentation on the
current configuration and build system. The current requirements and
process for building Parrot are the starting point for all future
refinements to the build system. You're in a better position to draft
that than anyone else in the project right now. Interested?
Allison
Whorf
>virtual machines today, to a continuation-based control flow. (I can
>recommend a few good books and articles if you're curious.)
Nikolay Ananiev
"Nicholas Clark" <ni...@ccl4.org> wrote in message
news:20070425150...@plum.flirble.org...
> On Wed, Apr 25, 2007 at 11:48:07AM +0300, Nikolay Ananiev wrote:
>
>> Maybe we have to search harder for new ways to advertise Parrot to other
>> communities and get new developers and supporters to the project.
>> Currently, Parrot looks too Perlish and is mainly supported by the Perl
>> community.
>> I think that has to change.
>
> Do you have any ideas on how to achieve this?
No.
If I knew how to tie a large group of people to a specific project
I would've been a very rich guy. :-)
But I hope that by discussing these topics, some ideas or suggestions
may come up.
Nikolay Ananiev
> Nikolay Ananiev wrote:
>> Yes I know about Parrot's great features, but Parrot is still not
>> ready for the mainstream and won't be ready in the next two years
>> (maybe?).
>> That's a lot of time for commercial projects like CLR and JVM and
>> the competition between MS and Sun is quite serious, so I expect
>> the dynamic features in their VMs to progress very fast. I'm also afraid
>> they have the resources to create compiler tools comparable to PGE and
>> TGE
>> (you know that MS can always steal).
>
> That's a possibility, but what are you afraid of?
I'm afraid these companies have the opportunity to take the niche
that Parrot aims at, before we get there.
> This is how open source software works. We develop in the open to promote
> the greater advance of all technology. We don't hoard our advances in the
> fear that others will use them (that's what proprietary companies do).
>
I just want Parrot to "make it" an be successful as a project. I think
this will happen if we manage to make it popular among other
communities, before JVM or CLR become popular as platforms
for dynamic languages.
> One of the greatest advantages of the open source model is the fact that
> Parrot isn't tied to a particular company's profit strategy. This gives us
> a much greater flexibility to take bold risks on new technology. I expect
> that this will keep Parrot consistently ahead of the CLR and the JVM. They
> have more resources to throw at it, but they also have strong motivations
> not to radically change their architecture.
New technology doesn't make a popular project. And a big
project like Parrot needs a popularity to survive.
>
> But, there's really no way to be certain how the game will play out until
> we play the game. If poker players all threw in their cards as soon as
> they were dealt, it would make for a pretty boring game.
>
But we have to be prepared for the game before it starts.
>> Maybe we have to search harder for new ways to advertise Parrot to other
>> communities and get new developers and supporters to the project.
>
> On that I completely agree, but as a simple matter of practicality, not
> some desperate bid for market dominance. If you want to recruit new C
> developers, you go where C developers hang out. (chromatic and I are
> speaking at a Linux conference this weekend.)
>
>> Currently, Parrot looks too Perlish
>
> On that I completely disagree. Parrot looks very Perlish because it's
> highly dynamic and intended to be easy to use (which happen to also be
> goals of Perl). This is an advantage.
By "too Perlish" I mean that not many developers outside the
Perl community have heard of Parrot. If you go to the PHP
community and ask them about this project, they'll tell you
they don't care. And the ones that know something will tell you
"Why to use Parrot? We have Zend 2.0".
Anyway, I expect Zend will never officially support Parrot,
because they are working too closely with Sun.
Maybe the big question here is:
What do you think Parrot needs to get to 1.0?
Does it need the masses from the Perl and other communities?
Is it ready for this?
or it needs just a few more highly motivated developers?
Bob Rogers
Date: Tue, 24 Apr 2007 23:00:31 -0700
Nikolay Ananiev wrote:
> So, is one of parrot's biggest strengths gone? Are we too late?
> Why would the developers use Parrot instead of JVM/CLR/Mono?
We're certainly pleased that we kicked off a revolution in virtual
machines, and that others are beginning to catch on to the fact that
they'll have to support dynamic languages to compete. But, it would be a
little silly to throw in the towel just when others are beginning to
follow your lead. (And I do mean beginning. They're making great
strides, but I still hear strange comments like "We support all features
of dynamic languages. Of course some features, like multiple
inheritance, may be slow, but we don't encourage the use of those
features." from the JVM team.)
Sorry for being slow to pick up on this, but this last bit makes it
sound like a pure marketing tactic. It's as if they are thinking,
"Let's add dynamic language support, so we can say that we can do that
too, but let's not bother to make it good, so it doesn't threaten our
flagship technologies." After all, multiple inheritance is pretty old
hat, and isn't even "dynamic" per se.
If that is the case, there is a risk that the big vendors may be able
to convince the pointy-haired bosses that they do indeed support dynamic
languages, when for practical purposes they don't. It reminds me of a
marketing shift at Franz Inc, the only remaining independent Common Lisp
vendor, I think it was about eight or ten years ago. At the time,
everyone was claiming to support "object-oriented programming" in some
form or other, so Franz started using the phrase "dynamic object-
oriented programming" in order to differentiate themselves. We may one
day find ourselves in the absurd position of having to explain that
Parrot is different because it supports "dynamic dynamic languages."
From: "Nikolay Ananiev" <ana...@thegdb.com>
Date: Sat, 28 Apr 2007 11:18:08 +0300
"Allison Randal" <all...@perl.org> wrote . . .
> That's a possibility, but what are you afraid of?
I'm afraid these companies have the opportunity to take the niche
that Parrot aims at, before we get there.
Parrot aims to be a *free* multilanguage VM, which sets it apart right
there -- even if I'm wrong and the big vendors really do want to support
dynamic languages fully (and can pull it off).
-- Bob Rogers
http://rgrjr.dyndns.org/
Joshua Hoblitt
> Allison Randal wrote:
> >Nicholas Clark wrote:
> >>
> >>I guess that the most obvious current thing that ties Parrot to the Perl
> >>community is that Parrot requires a copy of Perl to bootstrap, and
> >>all the
> >>build tools are written in Perl 5.
> >This is slated to change before the 1.0 release.
> I guess that doing so will involve re-writing a lot of the current
> Configure system and build tools into something that compiles down to
> PBC (and then just ship something very basic that can run a PBC). I
> don't think PIR is the thing to translate them to though - Configure and
> the build tools are fairly big things. You don't want to be doing that
> in an intermediate language. Well, I sure don't anyway, and I'm sure I'm
> not alone in feeling this way.
I believe that the intent, or at least my intent, was for the Perl5 cod
to be compiled down to PBC that was shipped with the distribution to be
executed via miniparrot. Of course, configuring miniparrot without
"Configure" is an unsolved problem.
-J
--
Allison Randal
Here's a few things you (and others) can do:
- give a talk about Parrot at your local linux/ruby/python/php/perl/etc
user group (recruiting new developers, and raising general awareness),
show working code
- contribute a patch (accelerating our path to the 1.0 release)
- document a feature (making it easier for new users/developers to get
involved)
This list isn't really the right place to talk about the "business" side
of the project, but we have good connections with significant companies
who who have an eye on Parrot. They can't do anything until we ship a
production (or at least beta) release, though. 1.0 is our top priority
right now, as soon as possible.
Allison
Allison Randal
I've had quite a few requests for this. Here's a good start:
- "Continuations and advanced flow control" by Jonathan Bartlett,
<http://www-128.ibm.com/developerworks/linux/library/l-advflow.html>
- "Compiling with Continuations" by Andrew W. Appel, Cambridge
University Press
- "A Dynamic Continuation-Passing Style for Dynamic Delimited
Continuations" by Dariusz Biernacki, Olivier Danvy, Kevin Millikin,
<http://lambda-the-ultimate.org/node/1966>
- "Representing Control, A Study of the CPS Transformation Mathematical
Structures" by Olivier Danvy and Andrzej Filinski, Computer Science
2(4):361-391
- "A Correspondence between Continuation Passing Style and Static Single
Assignment Form" by Richard A. Kelsey, ACM SIGPLAN Notices 30 (3): 13-22.
- "The Scheme Programming Language" 3rd ed. by Kent Dybvig (chapter 3,
particularly section 3.4), The MIT Press. Also
<http://www.scheme.com/tspl3/further.html#./further:h4>
Allison
Nikolay Ananiev
"Allison Randal" <all...@perl.org> wrote in message
news:4634E53F...@perl.org...
Nikolay Ananiev
http://blogs.msdn.com/hugunin/archive/2007/04/30/a-dynamic-language-runtime-dlr.aspx
"Allison Randal" <all...@perl.org> wrote in message
news:4634E53F...@perl.org...