Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/

Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Saturday July 04, 2009
04:42 PM

Why "Shut Up and Write Code!" is Unhelpful and Wrong

[ #39228 ]

The Perl community needs to discuss the DarkPAN and the present and future of the language and its ecosystem in much more productive ways than accusations, hyperbole, and strawmen. This includes the people who want to destroy the DarkPAN as well as the people who believe that its stability must be preserved.

I write provocatively and deliberately. I'm writing a manifesto, after all. Yet I believe I never devolve to name-calling, strawmen arguments, nor misquoting people. (If I do, please tell me and I'll correct it.)

My motives are simple: I want regular releases of Perl 5. I want the default behavior of Perl 5.12 to encourage modern Perl programming practices. I want missing features added to the language, even in small steps at first if necessary. I want Perl 5 to be a better language for creating interesting new programs than for maintaining clunky old programs.

Here are some selected quotes from Rafaël Garcia-Suarez's The DarkPAN matters:

DarkPAN is just a slang word to express the fact that Perl 5 is now currently used all over the world in production and sometimes critical systems... asking this question, even rhetorically, makes you sound as if you didn't knew that Perl is actually used in production.

When I use the word "DarkPAN", I mean precisely this: code which p5p cannot see, cannot search, does not know the features of, and which may or may not exist. See also "We can't change this misfeature in the core, because it may break the DarkPAN!" -- funny how that sentence always ends there, rather than including "But of course, we may not, and we'll never know, because it's the DarkPAN."

I tend to think that the regular contributors of perl5-porters are a lot more likely to have informed opinions about the Perl 5 core development than people who don't even read it.

Pick on me instead then. If you don't like my opinions, feel free to revert all of my patches over the past eight years.

[Who's] trying to be realistic by attempting to release software with some quality expectations, notably by making the upgrade process seamless and introducing as little bugs as possible?

Yet those quality expectations did not work in the case of Perl 5.10, with well-known defects continuing to spread as more and more people upgrade to Perl 5.10. The existing process does not work. Call it "realistic" if you like, but it did not work for 5.10. (Note also that one of the blockers to 5.10.1 is RT #22977 -- see also RT #50528 -- a bug almost six years old that's been present in eleven stable releases of Perl 5.)

First, we should not consider breaking it. Breakage happens, but our goal is to avoid it. Secondly, breakage is detected after upgrades, usually (or it would have been avoided).

The original point referred to deliberate, backwards-incompatible changes. Note, however, that a regular release policy could revert accidental breakages on a known, fixed schedule. The current Perl 5 release policy does not address this at all, which is part of my objection.

We just don't like to introduce incompatible changes just for the sake of being incompatible.

The only people suggesting making incompatible changes for the sake of incompatibility are people setting up a strawman argument against people like me who write tests, write testing modules, write documentation, write manuals, explore bugs, give talks, teach new users how to write Perl effectively, and occasionally write patches for new features who say "You know, some of the existing features are wrong, and they'd be better off this way."

In other words, this is an attempt to diffuse the real issue. The question is not and has never been "Should existing code randomly stop working?" Instead the question is "Can the defaults change in such a way that existing code will still work with perhaps a one-time, one-line change?" (It may not even require that much change.)

[Code] changes don't happen because someone yells about it on a blog. They happen because someone actually writes code.

I wrote code. Rejected. ("What's the point of a class keywords? You can always use package and @ISA anyway! If you need something more, just use any of several dozen Class::* modules on the CPAN!") Jonathan Leto put together a potential Perl 5.10.1 release that needed only a pull from the appropriate perldelta and a pumpking to release it. Rejected. ("Perl 5.10.1 is just around the corner, really, this time we mean it! Small releases are silly and expensive because of stat calls! A regular release cycle is like believing in astrology!")

But we're not in the land of toy projects here. We can't bless any change (or revert it two releases afterwards) just because it looks shiny at the time. This is not the parrot you're looking for. People do use Perl 5 for serious things, and we must ensure that a certain level of quality is preserved.

I can predict the day and date of Parrot releases into the next century. The number of contributors to Parrot grows over time, as does the frequency of commits. Parrot right now supports features that the Perl 5 VM will never support, and that feature list will only increase over time.

Dismiss all of that because Parrot is neither as widely-used nor as old as Perl 5 if you like, or even because you think I'm a jerk and you hate everything I care about, but there's one overriding metric for software project management: can people use the software? (The corollary is that unreleased software effectively does not exist.)

Quibble about the length of our deprecation policy. Complain that we haven't implemented your pet feature in a way that you like. Beg us to move a milestone forward. Berate us for not fixing a bug you don't report. That's fine.

Yet I believe almost every Parrot committer will agree that our defined support and deprecation policies and our regular release cycle have rescued the project from the very real threats of irrelevance, quality problems, and uselessness.

"Shut up and write some code!" is just a polite (relatively) way of saying "Do it our way or not at all, and above all, do not question the process or its results -- unless you're a core hacker."

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • You seem to be pissed off because I rejected a badly-written patch of yours about a pointless new keyword, and now you're going at war. What's your point in spreading all this FUD really ? Bring Perl 5 to an end ? Make me quit P5P ?

    And seriously are you really believing all this nonsense you're writing about releasing ?

    • Thank you for finally responding directly to me.

      You seem to be pissed off...

      I'm not angry. I'm sad.

      ... because I rejected a badly-written patch of yours about a pointless new keyword....

      Even after all of the complaints about people who talk more than they code, I don't expect standing ovations for producing code, but I would appreciate at least an acknowledgement that I did something about it.

      This is the first time (to my knowledge) you've made any comment about the implementation of the patch. If you

      • Lies and plain lies. I already commented on your patch on P5P. Several [mpe.mpg.de] times [mpe.mpg.de]. But you probably choose to ignore any opinion that's not in line with your ideology?

        There is a plan for 5.12, see for example here [mpe.mpg.de] which is a recent statement of intention. Concerning fixing release dates, I consider that pointless [blogspot.com] and I don't understand why you think release dates matter.

        Also, I don't like at all the way you systemically mischaracterise 5.10 by spreading FUD -- yes, I'm using the word again -- about how it would

        • gnore any opinion that's not in line with your ideology?

          There is a plan for 5.12, see for example here [mpe.mpg.de] which is a recent statement of intention.

          A "statement of intention" is not a "release plan".

          Concerning fixing release dates, I consider that pointless [blogspot.com] and I don't understand why you think release dates matter.

          Can you honestly say that the overly long release date have helped Perl? I think not but I would like to hear why you think it hasn't.

          Sorry, but I can't take you seriously anymore

          That is really sad. You are now dismissing him so that anything he says, whether good or bad, you don't have to worry about. I am glad we as Perlers are easily dismissive. That sure helps the dialog.

        • But you probably choose to ignore any opinion that's not in line with your ideology?

          I chose the word implementation deliberately, Rafael. I'm a careful writer. You're a careful reader.

          I don't like at all the way you systemically mischaracterise 5.10 by spreading FUD...

          The quote in the linked message was an analogy. To my recollection, I have never suggested that all new features in Perl 5 require use feature, only that some new features do. As I have written many times, my concern is that this is th

        • Raphael, I've been a long-time reader of both your blogs and chromatic's. You seem to basically characterize anyone who agrees with chromatic as 'less experienced'. That's a bit insulting. You can count me as one of your former readers now. And that makes me more sad than angry.
          • Being less experienced in technical and open source project management issues than Rafael is a very broad statement and certainly not an insult. I consider myself part of that group yet I've been around longer than most.

            • It's one thing to present it like it's a fact (I'm in the same group as you, actually more so). However, it's quite another to use it as a defense of one's tenuous arguments, and as a way of disregarding the opposing view. To me, painting everyone who agrees with chromatic as such falls into the latter, and indicates the person making the argument is unwilling to listen and unreasonable to deal with.

  • > Yet I believe I never devolve to name-calling, strawmen arguments, nor misquoting people. (If I do, please tell me and I'll correct it.)

    Personally, I'd say you have a tendency towards hyperbole. I've found when putting forward arguments the responses counter a far more extreme version of what I've actually said.

    That may have a more correct name than hyperbole...

    As for the DarkPAN argument, that seems at risk of being a kind of software development form of Loki's Wager [wikipedia.org] (with a measure of Appeal to Ridic [wikipedia.org]

    • That may have a more correct name than hyperbole...

      Discussions on the Internet tend to veer quickly away from the excluded middle.

  • > I can predict the day and date of Parrot releases into the next century.

    BTW, there's your hyperbole.

    I really would leave that point alone. One can predict all sorts of things, but who's to say they'll be true. Your prediction, should you actually do it, requires that you'd found a way to guarantee the accuracy of releases, to the day, after you are deceased.

    Also, there's nothing at stake. Now of course, if you were to specify a series of exact release days and dates stretching out for the next several

    • Also, there's nothing at stake.

      It's software. There's very little at stake anyway.

      Of course there are conditions to the prediction: Parrot must be a maintained project in 100 years and the current release strategy must remain (at least for the twice-a-year supported releases).

      Would you feel more comfortable if I predicted the dates of the next twenty four releases? We've hit our target dates within 24 hours for the last thirty or so releases; that's an easy prediction to make.

      • That would be great.

        Care to place a wager on whether or not you'll hit them all?

        • That would be great.

          Care to place a wager on whether or not you'll hit them all?

          That's not the point, at least in my perspective. With Parrot and Rakudo there is a consistent plan in place that indicates when the next release is made, pretty much to the day. I believe there has been one slip in Rakudo's release schedule of a few days (announced ahead of time).

          In stark contrast, the same thing cannot be said about perl 5.10.1, 5.12, etc. At this point I couldn't state with any certainty what the intended release data for any of those are to within a year (that fix for the performance