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."
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 ?
Re:Personal attacks
chromatic on 2009-07-05T08:31:54
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'd like to discuss the utility of a backwards-compatible non-default syntax change which changes procedural code into declarative code, clarifies the intent of code, collapses at least three lines of boilerplate into one, improves the obvious namespacing of functions, and is forward compatible with further OO systems such as Mouse and Moose, let's put on our language designer hats and discuss it on p5p.
Don't all serious patches (with tests) deserve such consideration?
What's your point in spreading all this FUD really ?
If I've spread FUD, I'm open to correction.
Are the defaults of Perl 5 really correct for new code? Do I not start all of my new Perl 5 programs with several lines of boilerplate? Do I not have to teach novice Perl 5 programmers how to convince Perl to help, rather than hinder, them? Does Perl 5.10.1 have a release date? Is there a plan for 5.12? Is there a plan for 5.10.2?
Do you really think the Perl 5 development process as it is works, in the face of (for example) a known performance regression identified and fixed seventeen months ago in bleadperl yet still unavailable to everyone who wants a stable release? Would you say, even in jest (as I believe another pumpking did), that people deserve to suffer this performance regression because they didn't test for and discover it until after the release of Perl 5.10?
Do you believe that it's acceptable from a language design perspective that Perl 5 doesn't have subroutine signatures? That the default way to inherit from an existing class is to modify a package global variable? That by default, Perl itself refuses to warn you if you use symbolic references or call undefined symbols or make a typo in a variable name even though in almost every case these are errors of implementation?
And seriously are you really believing all this nonsense you're writing about releasing ?
Every word -- especially the words about how the average Perl 5 user cannot or will not use unreleased code. "Patch it yourself, if it's really a problem" is an unacceptable diktat.
Feel free to tell me to shut up and write more code, if you like -- but if you do so, I would very much appreciate knowing exactly how much code I have to write to express my opinion that the Perl 5 development process has problems. (I'd also love to know how much code I have to write beyond that point to have my ideas taken seriously, rather than called "FUD" and "warmongering" and "astrology".)
Re:Personal attacks
rafael on 2009-07-05T09:56:09
Lies and plain lies. I already commented on your patch on P5P. Several times. 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 which is a recent statement of intention. Concerning fixing release dates, I consider that pointless 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 be necessary to "use feature" whenever one wants to use the 5.10 novelties. Here's a reply from me to one of such mischaracterisations on P5P.
Sorry, but I can't take you seriously anymore;
what is sad, is that less experienced users do. And this causes a lot of damage to the Perl community.Re:Personal attacks
sigzero on 2009-07-05T12:17:31
gnore any opinion that's not in line with your ideology?
There is a plan for 5.12, see for example here which is a recent statement of intention.
A "statement of intention" is not a "release plan".
Concerning fixing release dates, I consider that pointless 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.
Re:Personal attacks
chromatic on 2009-07-05T16:39:18
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 the wrong default, especially in the future.
... what is sad, is that less experienced users do. May I suggest that some of them have experienced the pain I describe and would like that pain to go away?
Sorry, but I can't take you seriously anymore;
Again, how much code do I have to write for you to answer my other questions?
Re:Personal attacks
cjfields on 2009-07-06T04:53:54
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.Re:Personal attacks
tsee on 2009-07-06T07:36:04
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.
Re:Personal attacks
cjfields on 2009-07-06T12:54:06
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 (with a measure of Appeal to Ridicule).
Re:Those three aren't the only problems
chromatic on 2009-07-05T17:32:05
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 years, and then we actually staked something, well then that's a different story.
Re:On this whole century thing...
chromatic on 2009-07-05T20:28:57
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.
Re:On this whole century thing...
Alias on 2009-07-05T22:30:49
That would be great.
Care to place a wager on whether or not you'll hit them all?
Re:On this whole century thing...
cjfields on 2009-07-06T05:22:54
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 regression in 5.10 would sure be nice), nor what the plans are beyond a 'statement of intent.'
Speaking of, I have to agree with sigzero's point above; intentions (and statements thereof) are great, but concrete plans and progress are what matters in the end and are what we would like to see, not hand-waving and worries about compatibility issues with code we can only guess at.
