Now that Dave Mitchell has released Perl 5.10.1 the bikeshedding may begin again. David Golden asked What do you want Perl 5 to be? I've suggested that people define their own visions for the future of Perl 5.
I believe this is important for a few reasons:
- The Perl 5 community has never agreed collectively in any sense on one or two strategic visions for the language and its ecosystem.
- Discussions about practical concerns always flow from ideas -- often implicit -- about the vision of the language and its ecosystem.
- Everyone who has a stake in the language and its ecosystem has particular uses in mind which deserve fair hearings.
- A project without a strong sense of vision will make progress only on the whims of people dedicated enough to perform work and get it committed.
I admit some bitterness in the last point; I have little desire to participate in arguments on p5p over proposed changes. (I'm not thrilled about excoriation for a personal Git fork of Perl 5 away from p5p.)
Yet I still maintain that all of this debate and discussion and even some of the acrimony comes from conflicting ideas of what Perl 5 is and should be.
A Digression about Multiple Implementations
I won't discuss the concerns the developers have raised; that's a discussion for another context.
Yet doesn't it seem strange that Perl 5 is one of the major languages without a port to the JVM or the CLR? How about to Parrot?
Part of the problem is a lack of people knowledgeable about Perl 5 internals with both the time and interest to work on such a project. Hopefully projects such as corehackers will improve things, especially now that the 5.10.1 release has stopped consuming all of the resources of p5p.
Another part of the problem is the internals themselves, but I've mentioned that before.
The final part of the problem is perception. For all that Perl has been a great (some might say promiscuous) glue language for a couple of decades, is it only my perception that the language ecosystem has grown insular? Perhaps that's part of the external perception problem: the Perl 5 world is its own world, with its CPAN and its XS and its quirks, and it leaves the rest of the world to its own devices.
Maybe that's part of the reason Perl 5 bindings are sometimes so difficult to coax out of companies and organizations. Maybe that's why Perl 5 support in new compilers and environments and services is so slow to appear, if it ever appears.
The Vision and the Ecosystem
I wonder if we're falling afoul of a perfectionist/completionist culture, where the next stable Perl 5 release will surely be the point at which we can stop this madness of patches and changes and releases.
Yes, that's a deliberate strawman.
Tell me it's wrong, though, especially in the face of distributions which don't expect people to write modern Perl 5 with the Perl 5 installed by default. (Don't take this as a personal complaint about Red Hat; Apple has had a similar flaw for much, much longer.)
Is it possible that some people see Perl 5 as an appliance, as plumbing? It's the strange contraption under your sink that sometimes makes a knocking noise if you leave the hot water on too long and you certainly hope it doesn't break because you know it'll make a fantastic mess and you might have trouble finding someone who can fix it.
I'm not suggesting that that's true. It might not be accurate.
Yet I wonder if the disconnect between the people who want to upgrade Perl 5 on their boxes once every ten years on a Saturday afternoon between 3:50 and 4:05 pm and the people like me who want to make Perl 5 easier to learn, easier to use correctly, and more powerful in terms of abstraction and portability and optimization is pervasive throughout the community.
Answer me these questions
- Is a purpose of CPAN for experiments in language extensions?
- Do they converge into proposals for additions to Perl 5 itself? If so, how?
- Does the CPAN help or hinder the desire for stability of the once-a-decade upgraders?
- Whose needs does the CPAN meet?
- Are those needs complementary or contradictory to the goals of various groups?
- How does the rest of the CPAN ecosystem support or discourage these goals?
I have my own answers to those questions, but the conversation is more important than me dictating what I think you should think.
However, if you thought Perl
5 version numbers are a mess, you haven't seen the real horror. Consider
ratings of the
Module::Build distribution, where it's taken nine years to
reach the point where some people are satisfied that a pure-Perl 5 installation
system can replace a broken system which relies on your ability to use regular
expressions to rewrite cross-platform shell scripts (which often need to call
back into Perl 5 to emulate missing POSIX utilities) or whether people should
use a DSL wrapper around MakeMaker which relies on distribution authors to copy
and paste code which may have bugs (and in fact has had a couple, requiring
those authors to release new versions of those distributions merely to make
If the Perl 5 community gets its once-a-decade chance to upgrade a bunch of machines next year, wouldn't it be nice to sneak in one or two Better is Better moments for a change?