Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re^7: Perl 6: Managing breakages across Rakudo versions

by moritz (Cardinal)
on Jul 17, 2012 at 11:59 UTC ( #982211=note: print w/ replies, xml ) Need Help??


in reply to Re^6: Perl 6: Managing breakages across Rakudo versions
in thread Perl 6: Managing breakages across Rakudo Star versions

This doesn't fit in to what is the general definition of a support policy/stability policy.

So, who said we are going to have a support policy/stability policy, and that it doesn't meet the general definition of these terms? Once again, we were asking for feedback on how to manage changes. I think you're reading things that weren't written.

If you are a user or a potential use of Rakudo, actual, non-bikeshedding feedback on that topic is very much appreciated.


Comment on Re^7: Perl 6: Managing breakages across Rakudo versions
Re^8: Perl 6: Managing breakages across Rakudo versions
by Anonymous Monk on Jul 17, 2012 at 13:51 UTC

    I will give you a frank feedback on what I think should be the way forward for managing things in Rakudo

    1. No more major rewrites, as they break a lot of code and a lot of catching up is required in the months that follow.

    2. Implementation for at least one backend complete, which is backwards compatible, has basic libraries and usable documentation.

    3. Path towards making Perl 5 and CPAN compatible defined, and planned to achieve over a period of time.

      I agree.

      I speak only for myself here as someone who gets paid to write Perl code.

      Just give me a Perl6 implementation i can depend on. I need to start writing scripts and modules and ditribute them on CPAN. And i need some reasonable guarantees that i don't have to do major rewrites every few months just to keep my code working.

      Rakudo doesn't have to be "feature complete" or be "highly optimized". To attract developers (who may write Perl code for a living), it needs to be stable enough that it's worth the (company) time to start writing code for it that it more complex than "Hello World" and more useful than self-test scripts.

      Stop breaking things because you "need to optimize". Frankly, unless Perl6 gets at least one stable, extensible Interpreter (e.g. not major rewrites every time you feel like it), there won't be a big community writing actual, useful code for it that starts to attract even more developers. Ergo it wont run any code that needs an optimized interpreter...

      Really, give me something i can show to my boss as a reasonable good choice to implement software with that will run for years, maybe a decade.

      "I know what i'm doing! Look, what could possibly go wrong? All i have to pull this lever like so, and then press this button here like ArghhhhhaaAaAAAaaagraaaAAaa!!!"

        I agree! Except that I really am in no rush. I want to see a production release as soon as possible, but I don't want to see these pre-production releases dressed in the trappings of production releases (e.g. "stability policies" and other service level agreements) because that actually harms the reputation of Perl. I agree with Anonymous Monk: until such time as Perl 6 is really production ready, break anything and everything necessary to get it there. The more you break now, the less you'll break later. Presumably.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (8)
As of 2014-10-21 08:11 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (98 votes), past polls