|
in reply to YAP6: A p5 approach to p6
Aren't you in danger of just further dilluting the gene pool?
The thing that has always amazed me each time I've downloaded Parrot is that it appears to me that about 50% of the contents, and perhaps a far greater percentage of the actual effort expended, seems to be on what you might loosely term "ancilliary" developments rather than the core.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
|
Re^2: YAP6: A p5 approach to p6
by Limbic~Region (Chancellor) on Dec 25, 2007 at 14:50 UTC
|
BrowserUk,
This has concerned me in the past. I have followed parrot from afar for a number of years. The thing in my lay, and completely unqualified, perspective that parrot should have done different is target a HLL from day 1. This may not seem pertinent to your point right away, but hear me out.
A great deal of would-be contributors to the project aren't interested in C, PASM, or PIR. A high level language would have opened up the doors to many more people - even if all they did was write code that exposed bugs that a much smaller population is capable of fixing. I think it would have done much more than that though. Back in the days of Dan and Leo squabbling over optimizations and features, one argument that came up was the applicability in a real language. If there had been one with a largeish code base, it would have been much easier to take things out of the realm of theory. I could go on why I think this would have been a good thing, but what do I know (really).
Ok, so far this still doesn't seem like it is on point. One of the things I have seen over the years of non-core contribution is numerous languages targeting parrot. By and large, each language had one or two individuals and the project would lose steam
- Questions to the list would go warnocked
- They would be blocking on a bug
- They would run out of time (summer break)
- They would lose interest for whatever reason
- The internals made continuing undesireable
- etc, etc, etc
What I have been noticing lately though is that the folks who have stuck around are now being very collaborative. The pugs folks are working with the parrot folks. The tools available now make contributing much easier. Also, the folks working on language implementation are also core hackers. When something is blocking for them - they can make sure it stays visible. Perhaps I am being too optimistic or naive, but I really think that what was once a problem (tangential projects) is actually becoming a great asset.
Update: I failed to mention that I doubt YAP6 is necessary. If it can produce a mostly working perl 6 implementation in a short time frame that is at least as fast as perl 5 - great. I suspect that this is not the case. I guess what I am saying is not all non-core projects are bad - but, for me, the jury is out on YAP6.
Minor grammar corrections
| [reply] |
|
|
The thing in my lay, and completely unqualified, perspective that parrot should have done different is target a HLL from day 1.
I agree, but remember that most of the reason that we're making such progress on tangential projects right now is that we have the Parrot compiler tools featureful and stable enough to allow us to build or port languages quickly.
I failed to mention that I doubt YAP6 is necessary.
It may or may not succeed, but the people who are working on it might not work on Parrot or vice versa. Concurrent evolution and exploration might not be the most efficient use of global resources, but there's rarely a central planning agency that can convince everyone to go in the same direction.
| [reply] |
|
|
but the people who are working on it might not work on Parrot or vice versa. Concurrent evolution and exploration might not be the most efficient use of global resources, but there's rarely a central planning agency that can convince everyone to go in the same direction.
True. Opportunity cost. That said, a couple of emails from principal devs, along the lines of:
"Is there currently anything keeping you from joining our project? Is there anything you see us doing incorrectly that you might be able to help fix?".
might gain a contributor or two. Well, wouldn't do any harm, anyway.
Heh. Reminds me of the old used-car salesman pitch (paraphrasing) : "What do we need to do to get you into this shiny new (still under-development) Parrot, today?". :)
| [reply] |
|
|
|
|
| |
|
failed to mention that I doubt YAP6 is necessary. If it can produce a mostly working perl 6 implementation in a short time frame that is at least as fast as perl 5 - great. I suspect that this is not the case. I guess what I am saying is not all non-core projects are bad - but, for me, the jury is out on YAP6.
You know, that is exactly the point. Before I started thinking about YAP6, I was working to bootstrap KP6, as to release it from MP6 and make it self-hosting. But when I finally got a bootstrapped compiler, it was taking like 20 seconds to compile a simple "say 'Hello World'" line. That was when I realised that the problem was on the fact that KP6 was implementing a runtime enviroment on top of perl 5, which is by itself already a very heavy runtime, and when you stack them, the performance is absolutely unpractical.
At that point I started to take a deeper look at Parrot, that was also during YAPC::EU::2007, while I had a very good chatting with the parrot folks, and that was when I realised that Parrot has taken a very hard challenge, and that IMVHO, if I wanted something to happen faster, I would have to take a simpler challenge. And that's why YAP6 started in the first place. YAP6 is nothing but a port of the KP6 "object system" to C, as so instead of generating weird perl 5 code, KP6 could generate weird C code that would run faster. Of course generating PIR was a possibility, but (and this is completely my fault), I just couldn't get out with PIR and parrot internals requires skills that I don't have.
As the ROADMAP and the README says, YAP6 intends simply to be a runtime library for KP6 to be built upon. It is simply the KP6 object system translated to C.
| [reply] |
Re^2: YAP6: A p5 approach to p6
by ruoso (Curate) on Dec 25, 2007 at 13:52 UTC
|
Aren't you in danger of just further dilluting the gene pool?
Certainly... but I really don't see it as a bad thing. Each one of the efforts that tries to bring Perl 6 to life gets it from a different perspective, and the experiences from each of this projects are creating a more powerfull knowledge of the Language and the runtime requirements for it.
Eventually all this projects will implement the full Perl 6 at the same time, even because most of the people working in this projects knows each other and do share experiences.
And finally, the idea of having alternative runtimes is interesting. Let me bring one considerable difference from Parrot to YAP6. Parrot implements trace gc and YAP6 implements refcount gc. Trace gc may be more efficient and more safe, but is not deterministic. Some applications may need a more deterministic approach to memory use versus processing time.
| [reply] |
|
|
| [reply] |
|
|
