In a corehackers discussion yesterday, David Golden suggested that collecting, reconciling, and unifying a vision for Perl 5 may lead to improvements in development processes, scheduling, and prioritization.
I know of no better description than James Shore's summary of Vision from The Art of Agile Development:
Every project needs a single vision....
Distance between visionaries and the product manager increases error and waste.
Some projects have multiple visionaries. They need to combine their ideas into a unified vision.
A vision for your project helps you identify success. It expresses what you believe to be important. It allows you to measure your completion of your success conditions. Vision defines what you're building, why you're building it, and when you've finished.
I've worked on several projects without vision. They've all failed to produce anything useful.
Vision in Practice
Vision affects every technical and philosophical decision made about the project. Which features are important? Which features can wait? Does one group of users deserve prioritization over another? Are there long term implications of decisions? What kind of organization works best?
Community-driven software projects with strong leadership often have strong visions. For example, David Wheeler's PostgreSQL Development: Lessons for Perl? expresses one element of the PostgreSQL core team's vision:
[The] PostgreSQL project can be explicit about what versions of PostgreSQL it maintains (in terms of regular releases with bug fixes and security patches) and can quickly deliver new releases of those versions. Because so little changes in maintenance branches other than demonstrable bug fixes, there is little concern over breaking people's installations.
PostgreSQL makes a priority of keeping old installations running. This leads to development practices:
[Every] time a major new version of PostgreSQL ships, a maintenance branch is forked for it; and thereafter only bug fixes and security issues are committed to it. Nothing else.
I write this not to contrast with any other project's vision or development practices; I write this only to demonstrate a strong connection between a well-defined vision and well-enforced development practices.
Vision for Perl 5
David also suggested that a discussion of motivations and goals may help the Perl 5 community converge on a shared vision. Here's my vision for Perl 5.
I would like Perl 5 to:
- Increase in usability and consistency, especially with regard to metaprogramming
- Change its default behavior to improve learnability for novices and to encourage writing maintainable, elegant code
- Become easier to modify and extend
- Allow further optimizations available in other dynamic languages (JIT, better garbage collection, automatic parallelization, serializable bytecode)
- Absorb widely-used and well-designed features tested from the CPAN, perl5i, and corehackers
You could summarize this into a simple phrase: "I want Perl 5 to become a better language for new development."
Now the fun begins: what's your vision for Perl 5 development? Feel free to post a comment here. (Be aware that I will unapprove any comment criticizing another vision; visions are positive statements of what you personally value. Express what you value instead.)
I want a full language specification for Perl 5.
At the point where we have a specification that matches the current released Perl, we can then start the process of deciding what features to add for the specification for future releases.
If the specification is a public document, it's much easier to see what the current state of the language is, as well as the future plans. Being public, this would make it much easier to have open discussions of what is desired for the future of the language.
Also, at the point there is a public specification defining the behavior and features available at a specific version, it's easier to track what changes between versions, and exactly what language features are enabled/disabled/changed when specifying compliance with a specific version.
As it is now, much of what I've witnessed in the recent arguments over the future of Perl 5 can be attributed towards the competing needs of language design vs. language implementation. If divorced, I think each as a smaller chunk would become a much more workable problem, but stil be able to provide valuable feedback for each other.
I would point towards Perl 6 for an example of this, but I'm sure there are other successful languages that embody this that are already widely in use and successful that would better serve as examples, only I'm not familiar enough to know of them. Also, Perl 6 as a role model is probably viewed as a cancerous meme by some of the Perl 5 community at this point, so it may actually be counter-productive.
I find I have a lot to say on this topic, and on much of the other posts here. Damn, I guess I finally have to start a blog now.
My vision is that perl5 keeps freedom, peace and backwards compatibility.
And got a pragma to
use everywhere [strict => qw/vars subs/],[warnings]; # but
use nowhere [warnings => 'void'];
This could totally different in reality, but I hope this pseudo makes the intension clear.
Well said kbenson.
Yes a Perl5 spec is definitely a good idea and then perhaps followed by a Perl5 implementation of this spec on Parrot?
/I3az/
Yes, that would be an eventual goal in my vision, possible other implementations.
Creating an implementation for parrot would greatly simplify the Perl 6 p6->p5 interoperability they have defined in their spec which is supposed to allow blocks of p5 and p6 code to coexist with each other in the same file and be interpreted correctly. That's a win for both.
I think that many of those discussions boil down to the fact that there is no Way to test new features from the Next version of Perl. In Python you can always check what the Next Version of Python will Change/deprecate. Extremely useful. Of course you'll Need to Know now what Perl 5.12 will bring. I'd suggest to take à Look at Python and their Upgrade Policy, IMHO à very sensible approach. (all typos copyrighted by my iPhone)