|
in reply to Re^6: Waiting for a Product, not a Compiler
in thread Moose - my new religion
I find it difficult to believe that porting 6model to multiple backends is essential to make Rakudo usable for end users in 2011 or 2012.
And none of the Rakudo core hackers spent significant amounts of time on that. Jonathan prototyped 6model in C# because he felt it was the fastest way to do it. He did spend maybe half an hour or an hour helping diakopter to port it lua.
I don't see why you continue coming back over and over again to the little extra amount we spend on investigating cross-VM compatibility; it really makes less than 5% of our hacking time, probably much less.
What any other project would do if it wanted to convince its target audience that it can produce a relevant and usable product: ask them what they need, then make it so.
And that's exactly what we did. After the first Rakudo Star release, we got huge amounts of feedback, and the first thing that nearly everybody wanted was more speed. That's a big reason for 6model -- you simply cannot make Rakudo efficient on top of an object model that requires several elements that the GC needs to consider, just to construct a very simple object with one integer attribute. And you can't make it efficient if the object model doesn't support gradual type.
That's the reason mean reason for 6model and the nom branch of Rakudo, and it does work. Every program that I've benchmarked so far is much faster on nom than on the old master branch.
So, we listened to our users, and we did what the users asked us to do.
|
Re^8: Waiting for a Product, not a Compiler
by chromatic (Archbishop) on Nov 28, 2011 at 22:06 UTC
|
So, we listened to our users, and we did what the users asked us to do.
If you truly believe that the best solution to that is to tell all of the people who trusted you to produce a usable distribution with a working subset of Perl 6 that they should wait a year and a half for a new release which will fix some of the problems and in the meantime they should either continue to use old releases (when you bother to make them) or try to run things on an unstable branch with no concrete release schedule and plenty of regressions, but you'll still insist every time it comes up that Rakudo is actually usable for real work, and why don't they try it now, this time you mean it, then we're clearly on different planets with regard to this subject, and I suspect that I've reached the limits of my ability to communicate.
I also suspect that a usable Perl 6—in terms of a product I can rely on to do real work—is years away, though I hope you prove me wrong.
| [reply] |
|
|
How do you come up with that "a year and a half"? We've had star releases every 1 to 4 months so far.
Could you please try to elaborate what we should have done differently? We asked the users, just as you said you should, and did what they wanted, exactly as you said we have should. Now it's still wrong. And you still haven't answered my questions how you would proceed without big refactors.
I understand all your criticism, but I still don't understand what we could have done instead. Skip all big refactors, and pile workaround on workaround? Invest all our resources on avoiding regressions, instead of advancing the state of the compiler and implementing the optimizations that people have asked us for?
You criticize continuously, but so far you haven't provided any feasible alternatives. If you continue to do so, you convince me that you're just ranting elaborately, and I'm wasting my time discussing with you.
| [reply] |
|
|
listen, I'm not saying you have done a bad job. I know you are doing something new which no one has done before. So its obvious there are a lot of unknown unknowns which create these rewrites and correction every now and then.
But you've got to understand realities of practical software development. When you say your next release is going to break simple programs of a user. That release doesn't qualify as a production release. Its a experimental release at the maximum. And most people when they learn about this will never bother to even adopt your release. This is precisely why Rakudo star releases aren't getting traction. Because you are saying the users, that the release contains some features, you don't quite really have documentation for it, CPAN isn't compatible, and there is no guarantee of the same features working fine in the next release.
This doesn't qualify to be a production release. Now lets look at the Perl 5 release. Once something is released, it goes out with a documentation. If something needs to be changed or removed or added there are deprecation cycles. And CPAN is always compatible.
Perl 6 production release need has to be feature complete. It will be impractical on our behalf to expect that. But it needs to adhere to most common definitions of production release. Its these experimental releases that are really messing up the perception.
| [reply] |
|
|
|
|
| |
|
|
|
I think one thing that is clear, with all these discussions. When Perl 6.0.0 releases it won't be able to replace latest then released version of Perl 5.
If Perl 6 is really that big, so that you can't really give one monolithic release which covers 6.0.0. Then I guess there must be a Perl 6 release which implements all easily implementable and usable features now. That release must not break any programs in future releases. There must be good documentation, basic libraries to write some programs and CPAN compatibility. You can carry on further development and releases hence forth as required.
For the moment a release branded as a production release will suffice. It will build trust in the community that some thing working is out in the open which can be trusted upon and used now. I believe Rakudo star was aimed towards that. But unfortunately it didn't end up meeting its goals.
Currently the feeling going around is that, we are stuck in a never ending cycle of rewrites and experimentation which never leads to a serious release. That is the perception. I know that's not true. But the world goes by perceptions.
There is nothing wrong with a minimal, production release. With documentation, libraries, with backwards and CPAN compatibility. After than you can always continue to make 6 month releases, adding more features gradually.
That way you can get a working production release product, users, growing community and at the same time gradually move towards a feature complete compiler.
| [reply] |
|
|
