Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re^13: Waiting for a Product, not a Compiler

by moritz (Cardinal)
on Nov 29, 2011 at 09:49 UTC ( #940567=note: print w/ replies, xml ) Need Help??


in reply to Re^12: Waiting for a Product, not a Compiler
in thread Moose - my new religion

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.


Comment on Re^13: Waiting for a Product, not a Compiler
Re^14: Waiting for a Product, not a Compiler
by wfsp (Abbot) on Nov 29, 2011 at 10:23 UTC
    Please move along.
    I don't think anyone needs any encouragement. Pity.
Re^14: Waiting for a Product, not a Compiler
by Anonymous Monk on Nov 29, 2011 at 11:10 UTC

    Why?

    Seriously, are your trying to say you can either release Perl 6.0.0 as whole or you just can't?

      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.

Re^14: Waiting for a Product, not a Compiler
by Herkum (Parson) on Nov 30, 2011 at 21:00 UTC

    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.

      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.

      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.

        While I can understand wanting to figure out how to implement certain features but are they really necessary to go forward? You mention concurrency, most of my programs are never going to need it so I don't see any advantage in holding up the WHOLE project to figure out that problem. Some features are great to have, but are not necessary to getting a core API started. Have a plan for integration in later.

        I can also understand wanting to avoid design debt, I mean XS is a horrible hack that I have never figured out. But I think having a great design, which may never be possible, should not stand in the way of a good design which could be used in the near future.

        I think this is more of a case of analysis paralysis, that a commitment to a current implementation would incur problems in the future. However, you will never get to the future if you don't commit to something. This leads to the problem, if the development team cannot commit to a design how can they expect other people to commit to it either.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://940567]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (11)
As of 2014-07-14 10:22 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    When choosing user names for websites, I prefer to use:








    Results (257 votes), past polls