Saturday 4 July 2009

The DarkPAN matters

There is currently some FUD going about in some parts of the Perl community about why we should break Perl 5 backwards compatibility. A short blog entry, schmarkpan, is a good example of the trend: loud, noisy, but clueless and devoid of any content.

The author writes, DarkPAN was discussed quite a bit at YAPC::NA. But really, what is it? How is it defined? Well, 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: websites with high availibility, financial systems, operating system build processes, and so on. That would also include the so-called GreyPAN, all Perl OSS applications that are not on CPAN. So, asking this question, even rhetorically, makes you sound as if you didn't knew that Perl is actually used in production.

He continues, Who are these people that have a vested interested in Perl and yet do not participate? For a start, I would like to point out that Mr Perez himself is someone with apparently some interest in Perl, but who does not participate in Perl 5 at the slightest. I might be biased, but 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.

I think attempting to appease a faceless entity with no defined boundaries has fail written all over it. It is fear mongering. Who's the fear monger here? And 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? It's a well-known political technique to accuse the opposite party of being guilty of one's own defects. But it doesn't make you right.

If we break it, they can choose not to upgrade. Several fallacies in one single sentence. 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). Third, this not only applies to Perl 5, but also to every open source project widely used (in the Perl world, DBI or LWP come to mind -- upgrading them is not a trivial operation either.) This is a matter of common sense.

Then, suddenly and without warning, the discussion shifts from breaking backwards compatibility to simply breaking Perl: What about bug fixes?, I hear you say. That is the joy of open source. There are lots of unemployed hackers out there that would be willing to backport those fixes for you. Oh heavens forbid! Actually paying open source hackers to write code! The sky is falling! Wishful thinking at its finest. Mr Perez might have found a tuit tree in the middle of a magic garden, but I have never seen "lots of unemployed hackers" who are at the same time fluent in the Perl internals, and lots of generous donators that fight over the privilege of paying them to work on Perl. Actually, there is one, currently: Dave Mitchell, who is paid to get 5.10.1 released. Yes, paid: the sky is falling.

Perl does not belong to DarkPAN. It belongs to us who participate in its wellbeing. In other words, "fuck the users". 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.

But have you, Mr Perez, even skimmed through a perldelta manpage, to look at the list of incompatible changes? Because there's actually a lot of them, in spite of what you seem to believe. I had code that broke because strict is stricter in 5.10 (as mentioned in the manual that you didn't bother to read.) ghc broke because we removed the magical variable $*. It's not like we fear incompatible change. We just don't like to introduce incompatible changes just for the sake of being incompatible.

I say we make the decisions best for our language of choice. But code changes don't happen because someone yells about it on a blog. They happen because someone actually writes code. If you really want to see something changed in Perl 5, write a patch and come discussing it on P5P. Although you might not have an idea about what you might want to see changed in Perl 5, since your empty, uninformed and slightly inconsistent rant fails to identify any precise problem.

5 comments:

NPEREZ said...

I am flattered really that you even bothered to read my rant. I'll reply here instead of as a retort post. I only have a few things I'd like to discuss.

What is DarkPan? How is it defined? You can write off the question as rhetorical posturing, but I am sincere. You don't define it any better. Yes, I am well aware of production system use code. And perhaps I should have included a bit more context, but what makes this code so fragile? Is it massive amounts of XS? Is it that it only works with strictures turned off?

As for questioning my credentials, I do subscribe to p5p, through the corehackers project I have committed a documentation patch (and will likely do more, considering there are a bunch of -D flags mentioned other places but not INSTALL), I also spent a little time with rjbs' effort for testing smartmatch. Yes, I am indeed new. I do not have the experience to hack directly on the core just yet, but I am building that by writing a toy language in C to just get my feet wet.

In discussing breakage, you say that is a goal to avoid breakage. And that is fine. You even quoted my "If" at the beginning of that statement which hardly puts me into the breakage for breakage sake category. You go on to say that breakage is only detected after upgrades, and that is a big problem. It should be detected after running through a vigorous test suite in some sort of development environment.

Anyhow, as for the rest of the attack on my competence, and knowledge on this topic, I'll skip over it. I obviously hit a nerve, which was kind of the point.

What I will say is that I am hardly alone in wanting shiny things. Yes, there is a responsibility to stability, but it seems kind of retarded to consider stability over improvements. 5.10.0 has all of these wonderful enhancements that are turned off by default. Why? It seems broken to ask for features in your code when you are explicitly using the binary in which they are provided. Or what about strictures and warnings on by default? Or what about any of the other tools on Schwerns perl5i list or chromatics Modern::Perl list?

These are the things I am talking about. These are the changes I would like to see.

Again, thanks for reading and replying.

Rafael Garcia-Suarez said...

Your concerns are pointless. By hearing you one would think that all 5.10 improvements are off by default. But you're only speaking about the 3 lowercase keywords pulled in by a "use 5.10.0". You don't even consider that the defined-or, the smart match, the new regular expression verbs, the UNITCHECK blocks (and keyword!), the C3 MRO, the stacked filetest operators, etc. -- I'm only quoting the beginning of the perldelta -- are turned on by default, and actually are not turnable off.

On the topic of the test suite, did you try to build perl already? It does come with a vigorous test suite. But expecting a 100% coverage straight from the start for something as complex as perl is kind of naive.

You are inventing imaginary problems and then fighting them.

Isaac Lin said...

It seems inappropriate to lump all code not in CPAN into one amorphous, second-class category. With an open development community, it doesn't seem right that only way to have your requirements considered is to distribute your software through a single distribution channel. Is CPAN now to be Perl's version of the iPhone App store?

Unknown said...

Hello Webmaster,

I am webmaster of several leading Job and Employment websites; I've found your website information and advice to be a very good fit for our visitors so could you please give us the best price for a site wide link on your esteemed website for a period of half and 1 Year? We will make payments Via PayPal so if interested, please mention your PayPal id.


If we are happy with your price, then we will send you the Link details that you can place on your website and we will make the payments to the PayPal id provided by you.


Regards,
Peter Freeman

Unknown said...

I would like to know why there couldn't be an inverse to deprecation. where after like 3 versions a backwards incompat change, like adding keywords, becomes default on. wouldn't 3 years be long enough warning? esp if you allowed something like no feature x; are people really saying adding say breaks my code?