Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Re^13: The current state of Perl 6

by Your Mother (Canon)
on Apr 21, 2010 at 05:18 UTC ( #835948=note: print w/ replies, xml ) Need Help??


in reply to Re^12: The current state of Perl 6
in thread The current state of Perl6

Books have editions due to the enormous limitations of physical publishing. Software publishing has no such limitations. Also, I haven't read a (non-technical) book published in the last 15 years that didn't have at least one typo. They will forever. Mainstream stuff has got worse every year. Sometimes editions are redacted—to their detriment. So, the analogy is out of place on several levels.

I don't think it's that anyone is hearing what they don't like as much as hearing things that don't make much sense or amount to, "But why can't I have a pony?" So what if Perl 6 never "ships?" I'll be disappointed but I'll still have Perl jobs for as long as I care to work with software. The world will turn. Perl isn't going away and the fewer Perl hackers there are the more the remaining ones will be sure of work at high salaries.

The following is for anyone who has been complaining about the perceived or regional decline of Perl in this thread–

Man up. If anything about the situation is distressing to you, do something about it besides kvetching. Want Perl 6 faster? Participate in its development. Bitching and moaning is only wasting time for those of us patient; it's painful watching chromatic have to defend his hard work. He could be off contributing more of it instead. Want Perl to clearly advance? Evangelize, write tutorials, answer questions on forums, fix CPAN stuff. Want more Perl 5 jobs? Start your own business or if it's really so important, move|emigrate to where there are Perl jobs. If all you wanna do is rain on Perl 5|6, go do it on a Java|Python forum or someplace where the audience at large might be interested.

Sometimes when some of us discuss how great we think Perl is or how much we enjoy working with it or how much money we're making it feels like that's not what Anonymous Monk wants to hear.


Comment on Re^13: The current state of Perl 6
Re^14: The current state of Perl 6
by Anonymous Monk on Apr 21, 2010 at 06:18 UTC
    The original question was about the "Freezing the Spec" and not accusing chromatic of something bad. Chromatic is a great guy!

    But how many projects have you worked on where the spec evolves towards infinity without a stop? What happens to such projects? Isn't it wise to avoid a second system affect which Perl 6 seems to be experiencing.

    You can't make systems without making mistakes, and if you avoid making mistakes you will never build a big system!
      This seems to deserve a serious answer.
      The original question was about the "Freezing the Spec" and not accusing chromatic of something bad. Chromatic is a great guy!
      I agree about chromatic. As for Freezing the Spec...
      But how many projects have you worked on where the spec evolves towards infinity without a stop? What happens to such projects? Isn't it wise to avoid a second system affect which Perl 6 seems to be experiencing.
      I've been on many different kinds of projects with many kinds of development cycles. I've never seen a spec evolve toward infinity without stop. I have seen specs that were frozen too soon, which is why Perl has always used "slushes" rather than "freezes". The phrase "evolve toward infinity without stop" implies that such a process must be divergent, but you can also evolve toward infinity without stop while also asymptotically approaching a stable value. There are many graphs in analytical geometry, and the typical development curve has many S-curves with stable plateaus where we release intermediate versions. Perl 5 has followed this course, so it's "evolving toward infinity without stop" too. The question is really one of convergence vs divergence, something we think we understand with Perl 6.

      As for second system syndrome, that usually bites you when you are working under a deadline. We don't do deadlines; we do convergence.

      You can't make systems without making mistakes, and if you avoid making mistakes you will never build a big system!
      If you actually look at most of the recent design decisions for Perl 6, you'll discover that most of them are actually to correct earlier mistakes that make it harder to implement. If any new powerful features sneak into the spec, it's generally a result of simplification, not complexification. So in analyzing the current design process, please consider convergence vs divergence, as we do. We want this as much or more than you do, or we wouldn't be working on it so hard.
      But how many projects have you worked on where the spec evolves towards infinity without a stop? What happens to such projects?
      That sounds like $WORK. Being an agile company in a highly volatile market means our specs change every day, following consumer demand. Code that was written a year ago, is thrown away today because it's no longer relevant.

      Oh, and we have a yearly revenue that needs 10 digits before the decimal period, when expressed in US dollars.

        A company using agile dev methods making tens of billions of US dollars a year? [citation required] Not to be a jerk but because I'm very curious to know the answer if it's true.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (10)
As of 2014-12-21 17:44 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (106 votes), past polls