Pumpkin Perl: Redux
In my last post, I proposed that we rename perl5 to Pumpkin Perl. The responses have been many and varied - some positive, some guarded, some ... unimpressed.
I'm going to try and go over them by class of comment; I'm intentionally not attributing the specific comments because they're meant to be representative of a type (I've had many more of each sort).
But this doesn't solve $other_problems
Comments of this class:
Perl doesn't need a new name and it doesn't need a new number, it needs radical reinvention.
that renaming is like 1% and everything else is 99%
I'm not really arguing that it's not a problem. I'm arguing that it's not the problem.
I don't think I disagree with these people that there are other problems that we need to solve. There are always other problems that we need to solve, and right now some of them are pretty major ones.
However, that's not what this is about. This is about getting one specific problem out of the way. To quote another less than impressed response that I think sums it up perfectly -
I'm not sold on it since a) I don't think it solves anything beyond a superficial confusion over the language names and their relationships. and er mostly a.
Yes. That's the specific thing I'm trying to solve. One problem, one change.
What I want is to have a clear and simple response to people asking us about perl 6 - a response that doesn't require rehashing the whole of the history of the perl 5/perl 6 story. By the time you've finished explaining that, whatever point you were going to make has long since been lost track of.
Instead, I'd like to be able to say say "I'm talking about Pumpkin Perl, not Perl 6" and move on.
I want an identity that we can own. Yes, we need to move the world. Yes, we need to have some serious conversations about what will constitute a long enough lever to do so. But right now, what I'm trying to focus on is giving us a stable place to stand while we do it, and this is a step towards that.
Or, to quote the people who seem to have already come to the same conclusion -
yes, it solves nothing except gets us all to stop bikeshedding
branding, used properly, is one more way to suppress misinformation.
it solves the Perl 5/6/? naming problem. people focusing on other problems w/r/t perl 5 seems a nonsequitor. sensible plan that solves a real problem. takes issue off the table. what's not to like?
But this isn't a radical enough rename
Comments of this class:
I don't think adding a noun to the existing name is distinct enough to do the kind of fresh-branding "new page" that you intend.
The problem won't be addressed because no one want to tell Larry that calling whateverfuck that language is "Perl 6" was a big mistake.
If its time for brand differentiation, then why not just "Pumpkin" ?
Well, again, I don't necessarily disagree that these are valid arguments.
However.
Firstly, I'm not personally sure that we want to entirely lose touch with being a perl. In fact, I'm pretty sure that right now I don't want that; I'm proud to use perl - specifically the pumpking's perl - and I'm proud to be a part of the perl community.
I don't want to step away from that. I just want to be able to differentiate ourselves within the perl family of languages, since there's more than one of them now. Lisp has been a language family for longer than I've been alive, and people seem to have managed to realise there can be more than one lisp. I'm very much aware that they've suffered some disadvantages as a result of that ... but everything's a tradeoff.
Plus, there's no reason that if you prefer the idea of 'Pumpkin' to the idea of 'Pumpking Perl', you couldn't refer to it as that. In fact, you could even set the 'perlname' config option when you build your VM so that it installs /usr/bin/pumpkin and /usr/bin/pumpkindoc and etc. - that's already baked in, you could do that today if you wanted to.
Secondly ... yes, I entirely sympathise with the people who want to shout "get off my lawn" (for lawn read 'name', 'major version number', or whatever as appropriate) at the perl 6 community. But just because I sympathise doesn't mean I particularly agree with you. Larry created the name perl, so he has every right to do whatever he likes with it. If he wants to call the language he's working on 'perl 6', and the community helping him work on it are happy with that, then while we're absolutely entitled to our own opinions on the subject, we're absolutely not entitled to expect anybody to care what we think. I'm confident that if we as a community decide that we want to be Pumpkin Perl, Larry (and the perl 6 community) won't stand in the way of our choice. I don't see why we should try and stand in the way of theirs.
Thirdly ... I'm looking for a non disruptive change, and one that while not entirely uncontroversial at least minimises controversy, and I believe this is it. Plus there's a whole world of people relying on the existence of /usr/bin/perl - it's even mandated by the Linux Standards Base - and it seems to me that it would be hopelessly confusing for a language called Pumpkin to install a binary called perl. Whereas a language called Pumpkin Perl installing one (and, as noted, already being capable of being configured to install a binary called pumpkin if you so desire) continues to make sense.
Fourthly, I'm looking at the art of the possible here. Even if I did think it was a great idea to unilaterally change our name rather than augment it, I don't believe I'd get consensus to do so and I don't honestly believe that at this stage I should be able to do so.
Or, to once again quote others -
I like the idea of Pumpkin Perl being the new name for the Perl 5 language. That opens up the possibility of something like Moe Perl 1.0 for a Perl5++.
"Pumpkin Perl" is probably better than other alternatives I've heard.
suddenly I'm looking at that proposal, thinking "hey, this could actually work" which hasn't happened with any other proposal up until now.
But if we're changing the name we need to do X as well
Comments of this class:
Changing the name or the version numbering scheme won't do us any good, unless we're willing to go further
I think that to make this work we need to finally come up with the Perl5 narrative
if you rebrand/reversion without changing things, everybody will laugh at you
Well ... I'd like to see us go further. I'd like to see some way that I can set my code up such that I get strict, warnings, maybe even the whole of my strictures module, right out of the box. That'd be grand.
I can see that people could call it an empty rename, but to be entirely honest I'm trying to frame this here as more a name clarification than a rename - a clarification that also manages to give us our own, independent set of version numbers. Exactly what we then do with those is a different question.
I agree that this doesn't solve the problem of a lack of a narrative, a lack of a specific statement of where we're going - but it does give us a name and an identity that we own as a community and can hang such a narrative off.
Fundamentally, I see this as very much one step, and at this point not even really a first step. Time boxed releases, the move to git, the spread of committers, and the work done to start deprecating things that we really should have convinced people to stop using/doing years ago are all important steps that we've already taken.
Perhaps more importantly, I do not want to turn this into a conversation about a rename and X, for pretty much any value of X, because the renaming itself is quite enough to be talking about at once, and because it seems to me that the things we do afterwards are ... things we do afterwards. This isn't going to go out to the wider world until version 20 at the earliest, in any case, so we'll have time to talk about things to do afterwards that are still things to do before the first release under the 'Pumpkin Perl' name.
I want to relabel the bikeshed. We can discuss what colour to paint it later.
To the quotemobile:
It's just Perl to people outside because we're not framing their perception in any other way.
having a new identity on its own is more important.
We can continue to argue about what Perl needs, but lets take care of this low-hanging fruit for the sake of momentum.
On the approach of midnight
Apparently a number of people hear "pumpkin" and immediately think of Cinderella. Ok, fair enough. But I was, honestly, a little surprised to discover that that was something they were genuinely worried about because of the perception that it would invoke 'perl turning into nothing' in other people's minds.
Then I stopped and thought about it, and realised that I love the Cinderalla metaphor.
At midnight, the carriage turns into a pumpkin.
A horse drawn carriage is an unwieldy, anachronistic, obsolete, uncomfortable piece of machinery.
A pumpkin is a quirky, tasty thing, that can be put to all sorts of fun uses, and is an inextricable part of modern culture.
That's exactly the sort of perception change I'm looking to achieve.
Roll on midnight.
Inside and outside views
Something that I've noticed here that I think is really interesting, is that people within the community, who're already substantially cognisant of all the various challenges that we face, have been the ones focusing strongly on the things that this proposal won't achieve.
On the other hand, people out towards the edges, people who use and love perl but aren't part of the core community, have been almost universally positive about it because it gives them the chance to frame conversations in a way that makes it easier for them to talk about why they like perl.
To quote a few (one perl6er, one sysadmin, and one network admin) -
I'm not primarily a fiver, so it's not my call at all. but I like pumpins, and "pumkin perl" rolls easily off the tongue. and, it's mostly an outward thing, to unconfuse outsiders.
Like the blog post about pumpkins. Seems like a good idea to this runner of networks.
I don't think any single thing will solve all the problems, but perception-wise, I think it works quite well, as someone not deep in the forest.
Given that the object of the exercise is to make it easier for us to talk to people outside of the echo chamber, I think the fact that the people who love perl who already are at least somewhat outside of our echo chamber are coming out in favour of it is a point in the favour of the proposal.
So, what next?
The final class of comment I've got, which needs, I think, only a single exemplar, is:
Who will decide? Who can decide?
Well ... we can. Effectively. Ultimately, the perl world runs, and has always run, on a mixture of JFDI and consensus - sometimes one first, sometimes the other - and I've always considered that to be a feature.
Of course, the discussion isn't over until rjbs merges a patch into master, and that won't happen unless and until there's a broad consensus from the volunteers who work on the code. I've not even started to bother them with that yet, because we don't have a patch - and I simply don't see the point in asking to merge a patch that doesn't yet exist.
On the other hand, such a consensus can far more easily be reached if there's a clear consensus among the community, among the people who actively care about this language and actively contribute to its ecosystem, that this is something we should seriously be considering.
You could, for the nonce, regard this post and the preceding one as being as much a means of testing the waters and fleshing out the arguments as anything else - but it's also very much a means of trying to get people thinking about the idea and sharing their ideas and opinions.
I'd like to think that with the above discussion I've pretty effectively covered the classes of questions people have asked about the proposal, and demonstrated that while it's no silver bullet, Pumpkin Perl is the best option that we have right now to address the specific challenges that it's trying to address - and that it doesn't make any of the other challenges we have any tougher, either.
I believe that this is an improvement. I believe that this can be done in a way that is technically non-disruptive. And I believe that while there are other possibilities that might in theory be better along some axes, in practice this is the possibility that can actually happen, and "perfect is the enemy of good" very much applies.
So, once again, I say:
Let's carve a smiley face in it and give it a go.
The question is, what do you say?
-- mst, out.
(you should tell me what you think by commenting at blogs.perl.org)