Parrot: maximizing the audience
Markus Laire
> Hi there,
>
> As a recent parroter, what striked me most while reading perl6-internals, is
> that it's very perl-centric. Ok, I agree that:
> ...
> * the name "perl6-internals" is really too restrictive (but this point has
> already been discussed last week).
> ...
Would it be possible to rename "perl6-internals" now to something
better like "parrot-internals"?
There probably are some big problems in renaming an active list, but
this could give us more non-perl developers interested in parrot.
--
Markus Laire 'malaire' <markus...@nic.fi>
Sean O'Rourke
> On 3 Sep 2002 at 22:17, Jerome Quelin wrote:
>
> > Hi there,
> >
> > As a recent parroter, what striked me most while reading perl6-internals, is
> > that it's very perl-centric. Ok, I agree that:
> > ...
> > * the name "perl6-internals" is really too restrictive (but this point has
> > already been discussed last week).
> > ...
>
> Would it be possible to rename "perl6-internals" now to something
> better like "parrot-internals"?
I think aliases can take care of this, though I'm not the sysadmin.
Maybe it makes people feel better to send mail to "parrot-internals"
instead of "perl6-internals", but I don't see how giving the list a
different name will have any real effect beyond breaking my procmail
setup.
/s
Brent Dax
# > Would it be possible to rename "perl6-internals" now to something
# > better like "parrot-internals"?
#
# I think aliases can take care of this, though I'm not the
# sysadmin. Maybe it makes people feel better to send mail to
# "parrot-internals" instead of "perl6-internals", but I don't
# see how giving the list a different name will have any real
# effect beyond breaking my procmail setup.
And there's still that pesky @perl.org at the end. So if we do this, I
suggest we take the full jump:
inte...@parrotcode.org
d...@parrotcode.org
whatever-you-th...@parrotcode.org
--Brent Dax <bren...@cpan.org>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
"In other words, it's the 'Blow up this Entire Planet and Possibly One
or Two Others We Noticed on our Way Out Here' operator."
--Damian Conway
Aaron Sherman
FWIW: I think you will eventually find that there are several different
audiences here. There are the folks who are working on parrot and/or
imcc. There are the folks who are working on actual Perl 6 internals
(e.g. P6C). There are also others working on other language font-ends.
I've been thinking about tackling a [bourne [again]?|korn] shell
front-end to allow large shell programs (not mentioning names *cough*
Big Brother *cough*) to be slowly replaced from the inside out.
Bryan C. Warnock
them.
Separating Parrot isn't as trivial as s/erl/arrot/g, and probably won't
be done *completely*.
We're not going to fool anyone that this isn't a Pet Perl Project, and
while other communities are eyeing us, it's not clear that the amount of
work to obliterate that line is going to be worth the cost.
If there are going to be changes made, they'll most likely be made
incrementally, which, of course, means that by the time the last changes
are made, there will be even more to rip out and redo.
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
Dan Sugalski
>IANADan, but he's aware of these issues, and is/has been thinking about
>them.
Heh. Well, I am. Lucky me. :)
This is something I've been thinking about since we formally
announced we were going semi-language-neutral.
>Separating Parrot isn't as trivial as s/erl/arrot/g, and probably won't
>be done *completely*.
Nope. What's more likely is that Parrot will accumulate bits from
other languages--rather than losing Perl we'll gain Ruby and Python.
Maybe others too.
>We're not going to fool anyone that this isn't a Pet Perl Project, and
>while other communities are eyeing us, it's not clear that the amount of
>work to obliterate that line is going to be worth the cost.
Once there's sufficient reason, and I'm pretty easy on this, we'll
switch to a more neutral look. Or if there turns out to be a good
time, we can switch then too.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Richard Soderberg
> > * the name "perl6-internals" is really too restrictive (but this point has
> > already been discussed last week).
> Would it be possible to rename "perl6-internals" now to something
> better like "parrot-internals"?
+1.
> There probably are some big problems in renaming an active list, but
> this could give us more non-perl developers interested in parrot.
smo...@perl.org was renamed at one point, due to conflict related to the
name. The old addresses for it still work, but it's renamed as far as the
outside world's concerned.
R.
H.Merijn Brand
Most (90%) of the smoke report still flow in through smokers...@perl.org
only very few use daily-bui...@perl.org
/maybe/ I should change my sig :P
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: smo...@perl.org
http://archives.develooper.com/daily...@perl.org/ per...@perl.org
send smoke reports to: smokers...@perl.org, QA: http://qa.perl.org
John Porter
> ... I don't see how giving the list a
> different name will have any real effect ...
?
It will have a huge psychological effect, at least outside our tight
little club. But if that's only as far as you can see...
--
John Douglas Porter
John Porter
> IANADan, but he's aware of these issues, and is/has been thinking about
> them.
Fine. But what does Larry think?
> We're not going to fool anyone that this isn't a Pet Perl Project, and
> while other communities are eyeing us, it's not clear that the amount of
> work to obliterate that line is going to be worth the cost.
Hm. We can make it possible, or we can make it impossible.
Which way, which way....
--
John Douglas Porter
John Porter
> What's more likely is that Parrot will accumulate bits from
> other languages--rather than losing Perl we'll gain Ruby and Python.
> Maybe others too.
But that doesn't address the real issue, which is --
Are we really serious about enabling other languages to target this
machine? Or do we want them always to be, at best, second-class
citizens?
> Once there's sufficient reason, and I'm pretty easy on this, we'll
> switch to a more neutral look.
Some folks seem to think that sufficient reason exists now.
> Or if there turns out to be a good time, we can switch then too.
How could any time later than now be a better time than now?
--
John Douglas Porter
Dan Sugalski
Really? At the moment, how many people outside the tight little club
actually care about the name of the mailing list? And how many more
would really care if we changed the name?
Dan Sugalski
>Bryan C. Warnock wrote:
>> IANADan, but he's aware of these issues, and is/has been thinking about
>> them.
>
>Fine. But what does Larry think?
Hadn't particularly asked him. Does it really matter?
Roderick A. Anderson
> Nope. What's more likely is that Parrot will accumulate bits from
> other languages--rather than losing Perl we'll gain Ruby and Python.
> Maybe others too.
Parrot: There's more than one language to do it.
Sorry but I couldn't resist,
Rod
--
"Open Source Software - Sometimes you get more than you paid for..."
Dan Sugalski
>Dan Sugalski wrote:
> > Once there's sufficient reason, and I'm pretty easy on this, we'll
>> switch to a more neutral look.
>
>Some folks seem to think that sufficient reason exists now.
That's fine. You don't have to convince some folks. You have to convince me.
Nicholas Clark
> At 7:34 AM -0400 9/4/02, John Porter wrote:
> >Sean O'Rourke wrote:
> >> ... I don't see how giving the list a
> >> different name will have any real effect ...
> >
> >?
> >
> >It will have a huge psychological effect, at least outside our tight
> >little club. But if that's only as far as you can see...
>
> Really? At the moment, how many people outside the tight little club
> actually care about the name of the mailing list? And how many more
> would really care if we changed the name?
I'd much prefer someone to implement something that allows python programs
to run on parrot. Not that I've ever used python, let alone hacked its
innards. My reasons are:
1: I'd like some other existing mainstream language to be working
2: The impression I get is that python would be the easiest. (in that it
I believe that it has external bytecode of a well-known format)
3: It ought to be easier than either (full) perl5 or (not yet fully written)
perl6
However, I confess I'm not sufficiently concerned about this to actually
try it. (There are too many things I still want to do with the perl5, it
seems)
Nicholas Clark
Angel Faus
> At 7:40 AM -0400 9/4/02, John Porter wrote:
> >
> >Some folks seem to think that sufficient reason exists now.
>
> That's fine. You don't have to convince some folks. You have to
> convince me.
Being ultra-pragmatic, the name change:
- costs nothing
- might make some folks happier
So it's a win-win, isn't it? Even if, of course, it doesn't really
matter at all.
Although symbols do matter sometimes, specially in politics, which is
just what we are talking about.
-angel
Garrett Goebel
>
> At the moment, how many people outside the tight little club
> actually care about the name of the mailing list? And how
> many more would really care if we changed the name?
Answer: You can hardly require a realistic answer to that question because
you won't know until you do.
Jeez, you'd think this was a contentious issue ;)
Who cares? Why not add a parrot-i...@parrot.org alias instead of taking
perl6-internals away? What is lost with an alias gained? A rose by any other
name is still a rose.
If Ask is willing, why not have him put it on the TODO list?
Reducing the number of times people are forced to see the word "Parrot" tied
together with "Perl" would be conducive to weakening that "tight little
club" mentality. Anyone disagree with that? It seems like a no brainer.
Even if it is just a language neutral symbol. Hell, if you really want
parrot to be dynamic language neutral, then Dan and Jeff ought to be wooing
Python and Ruby internals gurus for the job of Parrot heir apparent.
Anything less than that is empty words and promises.
It is pretty evident that in the current state of affairs all other
languages are second class citizens. But it would be nice to see the door to
the club house opened a little wider.
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com gar...@scriptpro.com
Andrew Kuchling
I follow the perl6-internals list through checking the archive, and
noticed Jerome's posting. I wrote the parrot-gen.py script that he
pointed to. Here are my comments on this issue.
(Note that I do not speak for the python-dev gang as a whole, but
AFAIK I'm the only current or former python-dev'er who's looked at
Parrot in any detail.)
First, the mailing list name is a complete non-issue; I don't care.
Having it be @perl.org doesn't matter, either.
First reason I don't work on it very much:
1. Frankly, it's not much fun. I can spend my free time writing
Python code, an environment I like, or I can work in the unfamiliar
and uncomfortable Parrot build environment and source code, grepping
through it looking for examples to help me figure out what's going on.
Guess which option wins most often?
I initially wrote parrot-gen.py because I wanted to play a bit with
Parrot and see what it took to generate Parrot bytecode from Python.
Parsing Python code is trivial with the Compiler/ package in 2.2, so
it was just a matter of code generation. Every so often, I'll update
my copy of the Parrot CVS tree and try to update the script to match
it. I also have incomplete PythonString.pmc and PythonFloat.pmc files
lying around someplace, and got halfway through updating the code to
use imcc instead of assemble.pl, but the task isn't enough fun to make
me bother finishing those off.
Some larger reasons:
2. No clear benefit to using Parrot.
What new possibilities does Parrot provide for Python? Stacklessness?
Better GC? A new I/O layer? Language interop? None of these is more
than mildly interesting to me, and none is a killer application.
Personally, I'm skeptical of the claims of cross-language interop
because I don't think a library written in Perl will provide an Python
interface that looks at all idiomatic, and vice versa. You could
write a Python wrapper to make a Perl library look more natural, but
now 1) we're all writing wrapper code that will introduce more bugs,
2) as a user chasing a problem, I now have to debug the interface
between the library and the wrapper code, 3) as a user, now I'll have
to read Perl/Ruby/Scheme/whatever code in the underlying library. The
way things are now, at least I only need to know 2 languages, Python
and C.
A big benefit for Python might be if someone writes a Parrot to
{machine code,.NET} compiler, but there are existing alternatives such
as Pyrex and no one has written such a Parrot compiler yet, so that's
not too convincing.
If every other language was using Parrot, there would be some pressure
to join them, but given the lukewarm response by other language
communities, that's not a factor at the moment.
3. Lack of any real languages on Parrot
I'm slightly worried that Parrot is already succumbing to the lure of
premature optimization -- counting the number of opcodes executed per
second, trying to save a C pointer dereference here or there -- before
the Parrot VM has been shown to be useful as a language target. No
one is running real programs in Perl or Python or Scheme or anything
on the VM (right?), so any optimizations at this point are just
guesses, and may not actually be relevant to real programs. This
makes me wonder if the Parrot implementation will just retrace the
same path as the Perl5 implementation.
I'd rather see a full implementation of a single real language that
people actually use (Scheme, Python, whatever) on top of an
unoptimized Parrot VM, instead of the existing situation of a bunch of
half-implemented or toy languages on top of an optimized VM. That
would be a more convincing proof that Parrot can actually handle a
real language, and gives other languages something to test
interoperability with.
--amk (www.amk.ca)
Then the shadows began to gather; first little furtive ones under the table,
and then bolder ones in the dark panelled corners.
-- H.P. Lovecraft, "The Strange High House in the Mist"
Steve Fink
Most of the active developers seem to be working on parrot for its
merits as a VM. Perl6, for me at least, mostly provides evidence that
this isn't just an exercise in intellectual masturbation, as Simon
would say -- there will be at least one real language that targets it.
But even if it's tied to Perl less than one might expect, I don't
disagree that it still smells strongly of Perl. Which isn't
surprising, given its origins. The reason why it came into existence
was Perl6; the early developers thus came from the Perl community, or
at least the Perl-using community, and so implemented the supporting
build system etc. with Perl; and the design of many things,
particularly the more incidental things such as specific PMCs, was
done from a Perl-centric perspective. Dan's designs tend to be more
language-independent than others', probably because he has language
independence as a stated goal while the rest of us rabble tend to only
worry about getting specific concrete examples to work, and those
examples are most often based on Perl.
But let's remember again what the point of Parrot is, other than
providing a way of running Perl6 code. To me, it all comes back to
decoupling a VM from a language's compiler, which provides the
following benefits:
- The two to be worked on independently, allowing more freedom to
improve each without worrying about backwards-compatibility or
incompatible development philosophies.
- It's easier to find experts in just one of the two components,
rather than requiring an expert in both VMs and the target language.
- Optimization is easier, since performance problems can be easily
isolated in either the VM or the compiler.
- Multiple languages can target the same VM, so more people are
motivated to improve the VM (and thus hopefully improving all
languages). But that's what we're talking about.
These advantages exist equally for languages other than Perl, but all
languages but Perl6 have one thing in common: they already have a
perfectly functional runtime execution engine of some sort. Not only
that, but they have an established group of experts for that runtime
engine. And those are very good reasons not to switch. That means that
Parrot has to offer some pretty convincing practical benefits, not
just theoretical ones. And any perceived obstructions, real or
otherwise, are going to make switching much less likely.
If I imagine that I am a Python developer digging into Parrot for the
first time, this is what I'd see: first, development is done on a list
named perl6-internals. Hmm... I wonder how Perl-centric it is? That
address is going to make it a lot harder to convince myself that
Parrot isn't fundamentally bound to Perl. (The @perl.org doesn't
bother me; if I have that much of a kneejerk reaction to the word
Perl, I'm not going to touch Parrot until you drag me to it, kicking
and screaming.)
Second, the build system is written in Perl. Okay, that will be a
nuisance, but I don't expect to work on that anyway. As long as it
does its job, I'm happy, and if it doesn't then I'm not going to waste
any time trying to fix it -- my time is better spent elsewhere, far
away from Parrot.
Third, the whole thing just seems too immature to be a realistic
target yet. These PMC things sound fine, but my language requires a
somewhat different set of operations and I can't find any working
examples of arbitrary method invocation. It runs a tinderbox, but some
machines have still been failing for a long time. The currently
existing PMCs have strange gaps and tangles where a low-level one
calls a higher-level one (and that higher-level one often has Perl in
its name!). The documentation seems to be written for someone else who
already understands more of Parrot than I do. Et cetera.
In summary, I think we should try to remove the obstructions, partly
because it's the right thing to do and partly in hopes that we'll be
able to get more eyes and hands working on Parrot. But the main focus
should be continue to make Parrot as robust, fast, and flexible a
target as possible, because in the end that's the only thing that will
persuade people to switch. And I'm guessing that the best way to that
goal is to use Perl6 as the driver, at least until something else
shows up, because that's the only way to derive realistic requirements
for what needs to be accomplished.
Melvin Smith
>[Please CC: me on any responses.]
>
>1. Frankly, it's not much fun. I can spend my free time writing
>Python code, an environment I like, or I can work in the unfamiliar
>and uncomfortable Parrot build environment and source code, grepping
>through it looking for examples to help me figure out what's going on.
>Guess which option wins most often?
This is no surprise. Parrot documentation will be lacking until
things settle down.
>Some larger reasons:
>
>2. No clear benefit to using Parrot.
>
>What new possibilities does Parrot provide for Python? Stacklessness?
>Better GC? A new I/O layer? Language interop? None of these is more
>than mildly interesting to me, and none is a killer application.
Faster execution times would be on the top of my list.
I'm speaking for Perl, not Python, but last time I checked, neither
language was spectacular in this category.
>Personally, I'm skeptical of the claims of cross-language interop
>because I don't think a library written in Perl will provide an Python
>interface that looks at all idiomatic, and vice versa. You could
I agree with you.
>A big benefit for Python might be if someone writes a Parrot to
>{machine code,.NET} compiler, but there are existing alternatives such
>as Pyrex and no one has written such a Parrot compiler yet, so that's
>not too convincing.
It may not happen either if the JIT is fast enough.
>If every other language was using Parrot, there would be some pressure
>to join them, but given the lukewarm response by other language
>communities, that's not a factor at the moment.
Its too early to have any response, Parrot is still alpha software.
>3. Lack of any real languages on Parrot
>
>I'm slightly worried that Parrot is already succumbing to the lure of
>premature optimization -- counting the number of opcodes executed per
>second, trying to save a C pointer dereference here or there -- before
>the Parrot VM has been shown to be useful as a language target. No
This is just responsible programming. We benchmark to track
progress and we need no excuse to over-optimize..; we ARE
building a virtual CPU you know. :)
>one is running real programs in Perl or Python or Scheme or anything
>on the VM (right?), so any optimizations at this point are just
>guesses, and may not actually be relevant to real programs. This
All opcodes that are used by real programs are relevant. We aren't
dealing with unknown technology here; most of the components
of a VM are proven and supported by academic research and most of
us are pretty smart people so I don't think this is a wasted exercise.
>makes me wonder if the Parrot implementation will just retrace the
>same path as the Perl5 implementation.
I don't call Perl5 a failure. Maybe the implementation is hairy, but it
works well and is THE scripting language of choice for system-admins,
DBAs and countless other professionals.
>I'd rather see a full implementation of a single real language that
>people actually use (Scheme, Python, whatever) on top of an
Eek, Scheme would do little for Parrot's acceptance in the
commercial world, and we all know its the commercial world
that provides most of the fuel to the fire. Seeing a "real" Perl, Python,
Java or C# running on Parrot would be my preference.
>unoptimized Parrot VM, instead of the existing situation of a bunch of
>half-implemented or toy languages on top of an optimized VM. That
>would be a more convincing proof that Parrot can actually handle a
>real language, and gives other languages something to test
>interoperability with.
Its really unfair to size Parrot up in this way. I hope the state of things
hasn't scared you off, we need good people, but it won't stop me
from giving my trickle of support in hopes of creating exactly what
you just mentioned. You, being a Python hacker and open-source
contributor, of all people, should know how slow this game moves.
Thanks for the honest comments,
-Melvin
Bryan C. Warnock
> I'm actually somewhat surprised at how little Parrot is tied to Perl.
I've no clue whether I agree or not. OT1H, given its origins from the
bosom of Perl, Parrot is surprisingly independent. OTOH, compare where
Parrot is to where it *might* have been had it started as a completely
independent project.
When I went back to resolve once-and-for-all the Perl or Parrot Design
Document debate earlier, I felt that to truly make Parrot independent,
not only would I have to change the name throughout PDD 0, but I would
have to revisit and revalidate - from a language-neutral position - all
of the original decisions. Some points would need to be removed.
Others added.
Should POD remain the documentation standard? It made sense at the
time, because this was just Perl. Would a language-neutral group reach
the same conclusion? Or would we be supplying our documentation in
*ML/text/*roff? Would Perl be the configuration/utility language of
choice, vice Bourne, C, autoconf, ...? Even something as trivial as
version numbers may or may not apply. Parrot was just one small part of
Perl that we were reinventing. Now it's one big part of itself.
It will be hard to "untaint" the early Parrot work without seeming to
continue to be Perl-specific. In fact, *because* of how Parrot (the
project) was developed, we'd probably need to *overcompensate* the shift
away, just to make the field seem level to other languages.
Of all the areas of Perl overlap, however, the one that is *most*
critical to Parrot's independence is both the one most people have
labeled as unimportant, and will be the one that will be most difficult
to maintain and deal with on a daily basis, and that's the mailing list.
It's great that we've got a bunch of toy languages that we provide, but
we're not providing Perl 6 as a toy. Its development *must* move out of
the parrot tree, and that means that we've got to draw a rigid line
between the two. Trying to have Perl 6 internals (in terms of Parrot)
and Parrot internals discussed on the same list will lead to a blurring
of that line, with all the standard ramifications of making assumptions
in code, etc, etc. (Not to mention driving the developers crazy who
have to weed out mail on the project they're not interested in.)
So since Parrot's history is on perl6-internals, Perl 6 internals work
should spin off onto parrot-externals. Problem solved. They're
separated. :-)
Two other human X factors to consider:
First, with Perl 6 being developed onto a moving target, there are
undoubtedly going to be Perl 6 bugs/features/patches/additions that are
going to cross the line into the Parrot cage. It happens in concurrent
development. It's going to take effort to keep the two apart.
Second, while Parrot remains mainly supported by Perl 6 developers, it's
going to be a burden on the bulk of that community to force themselves
into those two different mindsets. I'm simply amazed that Nicholas
Clark is able to play in both the Perl 5 and Parrot arenas, but they
have very little overlap in the areas being addressed. It makes little
sense to spawn a new list if 90% of the messages are cc:d to the other
one.
So that's what I feel is the difficult decision to make: the situation
as it currently stands is *easiest* on the known developer base, but
creates a barrier of entry for non-Perl implementers. However, we can
make things easier for others to get more of a community buy-in, at the
expense of effort by the Perl folks, but there's no guarantee that those
people will come.
Ask Bjoern Hansen
In the works is a new mail setup where we easily can have lists at
other domains and still have them available via nntp etc. At that
point I can create a dev at parrotcode.org list or something like
that. (or when the perl6 people want to work on the internals of perl6
:-) )
- ask
--
ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
John Porter
Except:
> ... the best way to that
> goal is to use Perl6 as the driver, at least until something else
> shows up, because that's the only way to derive realistic requirements
> for what needs to be accomplished.
The incorrectness of that is directly proportional to the immaturity
of the language specification. And it goes without saying (heh) that
there are plenty of languages with more solid specs than Perl6.
--
John Douglas Porter
John Porter
> John Porter wrote:
> > But what does Larry think?
>
> Hadn't particularly asked him. Does it really matter?
Not if you say it doesn't.
--
John Douglas Porter
John Porter
> John Porter wrote:
>
> That's fine. You don't have to convince some folks. You have to convince me.
Actually, uh, I was kinda hoping that some folks would convince you. :-)
Anyway, whenever someone (and it seems like I'm the only one who does)
tries to invoke the Perl Gods around here, you're always quick to brandish
your +5 Mace of Iconoclasty. You're quick to assert that this ain't your
father's Olds, but you're not quite ready to allow that it might not be
an Olds at all.
jm2c. ty,tyvm.
--
John Douglas Porter
John Porter
> make things easier for others to get more of a community buy-in, at the
> expense of effort by the Perl folks, but there's no guarantee that those
> people will come.
--
John Douglas Porter
John Porter
Dan Sugalski
>Dan Sugalski wrote:
>> John Porter wrote:
>> > Some folks seem to think that sufficient reason exists now.
>>
>> That's fine. You don't have to convince some folks. You have to convince me.
>
>Actually, uh, I was kinda hoping that some folks would convince you. :-)
I'm apparently reasonably difficult to convince. :)
>Anyway, whenever someone (and it seems like I'm the only one who does)
>tries to invoke the Perl Gods around here, you're always quick to brandish
>your +5 Mace of Iconoclasty.
Well, it's got a nice grip, and the balance is good. The larger ones
are overkill most of the time anyway.
>You're quick to assert that this ain't your
>father's Olds, but you're not quite ready to allow that it might not be
>an Olds at all.
IYHO, of course. Which turns out to be wrong here, but that's OK.
Joe Mason
Sorry for the duplication, Dan.
On Wed, Sep 04, 2002 at 07:42:24AM -0400, Dan Sugalski wrote:
> At 7:34 AM -0400 9/4/02, John Porter wrote:
> >Sean O'Rourke wrote:
> >> ... I don't see how giving the list a
> >> different name will have any real effect ...
> >
> >?
> >
> >It will have a huge psychological effect, at least outside our tight
> >little club. But if that's only as far as you can see...
>
> Really? At the moment, how many people outside the tight little club
> actually care about the name of the mailing list? And how many more
> would really care if we changed the name?
Hi. I like Python, and I find Ruby interesting. I refuse to learn
Perl, because it is Confusing.
I'm interested in Parrot mainly because I'd like to be able to take
advantage of modules written for other languages without having to
duplicate all the work. I'd like to take a Python or a Ruby and fiddle
with it to try out different ways of doing things without having to
alter
all the standard libraries.
I have no problem with it being called perl6-internals. Certainly
doesn't stop me from being interested. I suppose I'd be happier if it
were changed to a language-neutral name, but only if you *mean* it - I'd
be really annoyed if some token effort was made to distance it from
Perl, but it ended up being Perl-centric anyway. And if a name change
turns out to be any trouble at all, it's not worth it.
I mean, even though my main interest is in a cross-language VM, I still
refer to it as "the Perl 6 VM" when describing it to others, not "a VM
optimized for dynamic languages".
Joe
Andrew Kuchling
>This is no surprise. Parrot documentation will be lacking until
>things settle down.
Actually it's not so much the documentation. I didn't complain about
0.0.7 and 0.0.8 requiring changes to parrot-gen.py, because that's
simply to be expected at this point. More documentation would be
nice, of course, but it's not the major stumbling block.
>Faster execution times would be on the top of my list.
>I'm speaking for Perl, not Python, but last time I checked, neither
>language was spectacular in this category.
<shrug> I can't remember the last time I found a Python program too
slow for my purposes; Moore's Law is doing a fine job there. Better
performance is not that exciting to me.
>Eek, Scheme would do little for Parrot's acceptance in the
>commercial world, and we all know its the commercial world
>that provides most of the fuel to the fire. Seeing a "real" Perl, Python,
>Java or C# running on Parrot would be my preference.
Getting something -- anything -- running is what I'm suggesting;
commercial acceptance is irrelevant for that purpose.
I suggested Scheme because the syntax is easy to parse, the language
is already specified in detail, and getting continuations working
would exercise a complex part of Parrot's design. Perl6 can be ruled
out because its design isn't finished yet; I assume Perl5 is
difficult, and it will require extra work in implementing regexes,
which aren't needed for most other languages. Like Perl5,
implementing Ruby would also entail implementing regexes. Python
might not be too difficult if imcc is used and the necessary PMCs get
written, but I'm not moving very quickly on that. I hadn't thought of
C#/Java, but they're not really Parrot's target languages, being
static as opposed to dynamic.
With one full language implementation, you can take real programs off
the net and benchmark them, or take real libraries (a rule engine in
Scheme, say) and try calling them from proto-Perl code to see how well
cross-language works in practice. It provides an actual target to
poke at.
--amk (www.amk.ca)
Destiny? Isn't that just a fancy name for blind chance?
-- Peri, in "Mindwarp"
Steve Fink
That's the "showing up" part. We've got smart people right now who
care about getting Perl6 up and running on Parrot. Or at least, a
person who's straining to become plural. :-) We have a handful of
other languages that are more proof-of-concept or for other reasons
are happy to just do as much as possible with the amount of Parrot
that exists already. These are undeniably great things, but won't
drive development.
More languages would be better (perhaps Scheme will push on the Sub
PMC and its three-headed relatives?), but at this very moment we only
have one.
Speaking of Sub/Coroutine/Continuation, right now we *really* need
someone who pretends to understand this stuff to take a look at
Jonathan Sillito's patches and do something with them. Or give him
commit privs, or something.
mrjol...@mindspring.com
>Speaking of Sub/Coroutine/Continuation, right now we *really* need
>someone who pretends to understand this stuff to take a look at
>Jonathan Sillito's patches and do something with them. Or give him
>commit privs, or something.
Hey those are my three headed babies you
are talking about! :)
Sorry, I've been preoccupied and I must have
missed Jonathan's patch. I will have a look.
-Melvin