Pumpkin Perl Breakdown
Enough broad strokes.
You can find the initial outline and rationale for my proposal here, and my response to the comments and suggestions I got following it here.
And now, here's a breakdown of the what, the why and the how, so that we can make a proper start at turning this from an idea into a concrete reality.
All comments are, as always, very much welcome.
mst
Hello,
First, thanks for all the efforts, and the open communication on this. I've a few questions just to think about this change:
1) Will $new_name have any compatibility issue with PAUSE, CPAN, cpantesters, perldoc.org and metacpan ? If so, maybe that front of work need to be evaluated or/and planed.
This question extends to lot of tools many of us like to use, for example perlbrew, cpanm, etc.
2) Will perl > 5.18 continue existing, if next year, blead performs this changeset ?
I think the obvious response is "no", but being opensource, and having so many people and business depending on perl "as it is" now, maybe it's inevitable to see a efforts split, or people supporting perl5 after this change.
I think the "calendar" for final users, should be more "clear" than when this change may meet blead. More like a calendar or roadmap, of "what" and "when" is going to be supported (or not supported). And I'm not talking only about "the interpreter", but more about all the ecosystem.
3) This depends a bit directly on the answer to the question 1 and 2. Will $new_name use the same infrastructure and live under the perl foundation umbrella?
There is many things implied... from DNS domains, infrastructure maintenance and support, mailing lists, irc channels, downstream packagers, etc, etc...
Sorry if my questions has been already responded, I'm living out of my country and using intermittent and slow internet connections in my personal time, so I'm not as plugged to the community as I used to be.
Best regards.
Iñigo
I don't have much to add, except +1.
I think one item is missing in the "Why" section which should be explicitly included:
"If you currently use Perl 5, but also think that Perl 6 is Perl's future: ..."
If you believe that perl5 requires a new implementation to take us forwards:
You should support this proposal because by providing the current implementation with its own name, we allow alternative implementations to also have their own name and identity without linguistic complications, leading to a fair technical playing field within which they can prove themselves.
mst, as someone who believes a new implementation is the way forward (and thinks the Moe experiment might be useful here), I think the above looks like what would happen if a strawman and a non sequitur made a baby. Nobody asked for permission to make JRuby or Rubinius or Jython or Jim Tcl. If Moe were a functioning compiler that allowed something related to Perl5 to run on the JVM, we could all call it Moe even if Perl5 was still just Perl v5.xx.
In a way, renaming Perl5's current implementation seems like it might steal the thunder from any near-term re-implementation...but of course I jest. There is no near-term reimplementation.
Perhaps you didn't really mean "allow alternative[s]". Maybe you meant "encourage". At any rate, I would appreciate it if you would elucidate on your point for the reading comprehension-impaired.
I like your reasoning.
+1 to the proposal.
Instead of "real users", I should have written "The people you want to convince." I'm not sure that even a thousand people who know and care enough about the state of Perl to discuss the version number of a 5.18 or a 5.20 are the people you most want to reach with this effort.
What is the real problem they want to solve? Does this suggestion address that problem?
To some degree they don't know they have a problem. We're trying to read their minds and guess what their problem *is*, if they were able to recognize and articulate it.
Here's my guess: they want to get stuff done, and Perl might be a way to do that. So that leads to: they need find good documentation about Perl, they need to find the right tools for the job, and they need to get the Perl interpreter to accept the code that they've written based on the documentation they've found.
Coming out of that are various problems such as: there's lots of old documentation that doesn't follow modern best-practices, there is confusion as to whether Perl5 or Perl6 is the "right" tool and how these two differ, and the disinformation that Perl is dying and is going to be replaced soon anyway by a whole new version/language.
Does the proposed solution of a renaming/rebranding solve these problems? Not entirely, but it's a really good start. I can't see any solution *not* including a renaming of some sort.
Surely there must be an easier way to validate that guess then spending the next year trying one proposed solution or another, then figuring out how to measure if it worked. (Seems like measuring efficacy will be difficult if the guess turns out to have been wrong.)
Hi Matt
OK, I read your extremely-well-argued what, why, how - and I agree: Pumpkin Perl it is.
gotmynick/inigo, (1) as I said, no technical changes up front, (2) so far as currently existing code sees it, it'll look exactly like perl 5.20 was always going to look - this is a change for humans, not for programs, (3) it'll still be the same codebase, developed by the same people, under the same umbrella; Shadowcat has registered a few domain names in case we need them but initially they'll just be redirects, I'd imagine (and we'll happily donate them to TPF once the proposal's accepted if people think that's a good idea)
John, now you point it out it was a mistake to omit that; the people I'm aware of in that category all basically said "... so as such we're going to keep working on perl6 and not express an opinion", which I think is why it didn't occur to me to do so.
I think the answer is pretty easy though:
If you currently use perl5, but believe perl6 is the future of the perl family of languages:
You should support this proposal because it kills dead the various distracting "but perl6 should X" proposals that keep being made, and because it gives perl5 a better chance to keep getting on with doing what it's doing in the meantime.
arrestee, after all the trouble we've had with the namespacing collision of perl5 and perl6, it seemed pretty obvious to me that it'd be nice to have that a priori avoided for any new languages/implementations.
Since clearly it wasn't obvious, let my try a rephrase: I'm not so much saying it's -necessary- to allow new implementations, more that it means there's one less problem for them to potentially need to worry about later.
Does that make a bit more sense? If so, any suggestions on how I could rephrase my original words so that it would have been obvious to you as well as to me? :)
chromatic, the people I want to convince -are- the users. I'm trying to create an identity that we, as a community, feel like we own, and feel like we can use with reduced changes of people getting confused as to what we're talking about, to give us a solid place to stand from which to evangelise our language of choice.
This isn't directly about convincing the rest of the world, it's about giving us a platform to stand on while we do so.
When I was in social work training I was introduced to the concept of partializing problems, i.e., trying to help someone experiencing multiple, interacting problems cope with them by breaking them down into components which were more solvable on their own.
mst, I appreciate what you're doing as an attempt to partialize Perl's problems -- even though most of the evidence of those problems which has been presented so far is anecdotal and subjective.
Thank you very much.
Jim Keenan+1 for trying something like this.
I'll help on websites where I can.
mst, all day long I could not figure out where to stand to see things your way. Then I happened upon Dave Golden's blog post where he says:
If we go all the way, and rebrand from "Perl 5" to "Pumpkin Perl 1", then we open the door to a future "Pumpkin Perl 2" that breaks backward compatibility with a major version bump.
Oh. I get it. I was so stuck on my idea that the time to get a new name was when there was a major break of backcompat that I never really saw that scenario. With the, you know, version numbers and such... Sorry 'bout that.
But I still don't love the idea. Golden's post goes on to say:
IF we think there will ever be a future Perl 5-like language/interpreter that is a significant departure from what we have today (that isn't Perl 6), then we really need a way to signify that with some sort of major bump or change in either version or nomenclature.
Right, there's my plan: change of nomenclature when there's a significant departure from the status quo. It's what strikes me as 1) good style, and 2) less risky. But it does mean doing nothing in the short-to-medium term to stem Perl's slide in popularity, and doing nothing can be risky too.
So just go for it, man. Lots of people will love it, and the rest will get over it. Might even work.
To be clear: I think the rename is a great idea. It's a first step, and that's awesome.
With that in mind, for this to be successful we as a community have to go all in. Doing a rename like this in a half-assed fashion will fizzle out, and end up as wasted effort in a year. We need to give it an extreme amount of energy so it gets over the tipping point and takes on a life of it's own.
This means more than making a pretty logo, changing the version string, and saying "yay perl". It means making noise. Lots of noise. No half-assed "ironman" blogging thing that generates little interest. It means well designed, good looking documents and materials that have a consistent message, feel, and style.
It means a full-on rebrand with corresponding marketing blitz. It needs a Benevolent Dictator who knows branding and gets things done.
If you know what you are getting into, then I'm with you 100%. So yes, I am volunteering to put the effort in - if others are with me.
There are so many reasons to support this idea.
One of those I really like is that people will be able to use search engines and find something up to date when typing "pumpkin perl": there's so many outdated stone-age perl-related material that we won't be able to get rid of that without a change like this.
So, for this and many other reasons, it's +1.
And willing to help where I can, of course.
I liked everything about mst's original Pumpkin post with one small exception -- the specific qualifier Pumpkin.
In most ways it's outstandingly good. But it didn't leave me 100% satisfied.
I've just seen someone's suggestion of Modern Perl, and I have to say I like it a lot. I checked whois, and shadowcat owns modernperl.com...
I like it.
The name "Pumpkin" isn't necessarily my favorite, but I'm pretty sure that's just pure personal opinion; I can't think of any real objections to it, nor can I think of a better suggestion. There's certainly nothing wrong with it.
I do still like the idea of year-based versioning, ideally along with the name change. If you're going to do releases based on a scheduled time-table, it makes sense to match your versions to it. However, that's something that can be considered in the future.
I'm feeling good about this change.
From http://irclog.perlgeek.de/perl6/2014-09-05#i_9305941 (freenode/#perl6) a few minutes ago (edited to correct spellings):