|
in reply to Re^11: Waiting for a Product, not a Compiler
in thread Moose - my new religion
In short.
You need one minimal feature complete, completely backwards compatible, documentation ready, CPAN compatible product. After that in future releases you need to gradually grow it.
Is it clear now.
|
Re^13: Waiting for a Product, not a Compiler
by chromatic (Archbishop) on Nov 29, 2011 at 18:55 UTC
|
I'm comfortable without complete backwards compatibility. I expect the spec to continue to change in places. In an ideal world, that's the risk you take in using a Perl 6 implementation today: Larry reserves the right to change his mind on what 6.0.0 will be until he officially blesses what 6.0.0 will be.
I can deal with that.
What I don't consider "ready" or "usable" is a project which makes a big splash about how it's going to produce something "not complete, but ready for early adopters to begin using" which will be "refined and improved and released regularly", then slips its release for several months, makes a couple of releases, slips from monthly or so releases to "every three months", then undergoes yet another rewrite of core components, makes a half-hearted release of an abandoned line of code because "it's really about time we did another release", then slips more releases because that "just a minor refactoring, really!" is taking a long time and (unlike what the word "refactoring" means) produces quite a few regressions.
My business had a product we intended to release to actual clients about the time of Rakudo Star. We were all set to get things going around April last year. Then Rakudo Star slipped to July, and it was obvious that Rakudo Star wasn't of the quality we could use. (You might remember I did some measurement and performance work in Parrot around that time. Performance wasn't everything we'd hoped for, but we were counting on regular releases and about a 5% or 10% improvement every release—which we were able to produce—to be viable for early adopters just starting to explore the system.) I kept the project around until late December and then January of this year, when it became obvious that the nom rewrite (again, if you cause regressions when you refactor, you're not refactoring) would take far longer than claimed. (If you want to predict what other people will do, pay more attention to their history than their estimates.)
I was ready to scuttle the project then, but one of my business partners talked me into wait and see mode. (I appreciate the bitter irony that said partner wasn't even keen on starting the project, as I am the only one among us who was, but the opportunity cost of watching and waiting was minimal.)
That project's not going to happen in 2012. I've cut our losses. I don't know what of the existing product will be salvageable if Rakudo can get its act together. I don't know what will work if another implementation becomes viable.
Now then, someone go on and tell me yet again that "Perl 6 is usable right now!" because I was ready to ship a product with it almost a year and a half ago, and it's still not ready for that.
| [reply] |
Re^13: Waiting for a Product, not a Compiler
by moritz (Cardinal) on Nov 29, 2011 at 09:49 UTC
|
Yes. Thank you. And you won't get that, because the Perl 6 specs doesn't have such a core <update>yet, and won't get it very soon</update>. Please move along.
| [reply] |
|
|
How can you expect people to treat this seriously if you don't have a core? The project has been around 12 years, I mean Perl 1 to about Perl 5 was done in a shorter amount of time and supports more platforms than you can shake a stick at!
If you having fun doing it, that is certainly a good reason for you to continue with it. However, I find it hard for people to consider it serious if you cannot commit to a core set of features by now.
| [reply] |
|
|
We do commit to a set of features, not just to all the details of how they are implemented. For example it was clear from the start we'd have multi sub dispatch, but the exact semantics for figuring out which candidate to call has changed in the past, for very good reasons.
We also have a core of syntax and semantics that has changed very seldomly in the recent years, but we don't commit to backwards compatibility yet.
There are two main reasons for that. The first is that some areas of the language are yet largely unexplored, for example concurrency. While the Perl 6 design team had concurrency in the back of their heads when desiging the language (which is why much more stuff is done lexically, instead of in global variables as in p5), there is little concrete spec on how concurrency works yet, and it might affect some core features in small, backwards incompatible ways.
The second is that each commitment to backwards compatibility is a possible design debt. Perl 5 has way too much design debt already, and we don't want to repeat its mistake. So we rather commit later than sooner to backwards compatibility.
At some point in time we'll have to reconsider that choice, but I don't feel we're quite there yet.
| [reply] |
|
|
|
|
That's partly due to Larry's wish for the re-write to be community driven rather than dictated by himself. There are a lot of conflicting points of view to discuss and aggregate and ideas keep changing. If anything so far the extended development period has achieved little but prove the general programming populace are unable to achieve a consensus with each other as to what they want 6 to be.
| [reply] |
|
|
Please move along.
I don't think anyone needs any encouragement. Pity.
| [reply] |
|
|
| [reply] |
|
|
From my point of view, committing to any kind of "core" library now would throw Perl6 into the same (perceived) pit of backward compatibility friction that gets ascribed to Perl5. Perl5 has a working deprecation cycle now to solve that problem, but Perl5 is not within the dynamic zone of "let's try every crazy idea that we hear of".
Personally, I think Perl6 would do good to explicitly state its stance on parallelism and concurrency, so that libraries will get implemented relying either on sane userspace threads, coroutines or OS threads. Even better would be explicit language support for both, coroutines and (Userspace) threads. But then, I have both in Perl5 already, so I might just be biased here.
| [reply] |
|
|
