I’ve noticed that many recent discussions about changes to Perl 5 core development spiral off into circular discussions about deprecation cycles, definitions of compatibility, source code branch strategies, timeboxing, volunteer motivation, and so on. Consensus has been slow to converge and conflict is in the air.
I think the problem is that people have different goals for Perl 5. Some of these goals mesh well, but others conflict. Some of the remedies support many goals, some only one or two. And some remedies work against some goals. Placing some goals above others has big implications for changes to the development process and for priorities for new development.
I’ve started brainstorming some of the goals that I’ve heard or read or imagine might be out there. Maybe if we can find some common ground around some goals, getting to common ground about methods won’t be quite so difficult.
Read these over and tell me what you think, here or on a blog or site of your own. Do you agree with some? All? None? ** If you had to pick just one or two, what would it be? How would you know if they happened?** What would it look like? What would be different?
What do you want Perl 5 to be?
- I want Perl 5 to be more innovative
- I want Perl 5 to be less dependent on the heroic efforts of a shrinking pool of maintainers
- I want Perl 5 to be rock solid for enterprise use
- I want Perl 5 to be a better language for new development
- I want Perl 5 to be popular
- I want Perl 5 to be less buggy
- I want Perl 5 to be portable to all the platforms I use
- I want Perl 5 to be more maintainable
- I want Perl 5 to be easier to teach
- I want Perl 5 to be more like Perl 6
- I want Perl 5 to be more useful to those who contribute most to it
- I want Perl 5 to be better at solving particular types of problems
- I want Perl 5 to be more fun
My own view is a mix of several of these, and I’ll try to articulate that further in a future post.