Names and Numbers, Brand and Identity

I've just put a post up on my shadowcat blog talking about where the 'perl 7' meme came from, why it's a terrible idea, and suggesting what we should do instead.

tl;dr - Pumpkin Perl!

This post exists to provide somewhere for people to comment that isn't Hacker News or reddit; I've cross linked it from the end of the blog post itself so hopefully people who want to discuss the idea will find their way here.

(if you haven't seen, there's already been a followup responding to the comments made here and elsewhere and a third post breaking down the what, the why and the how of the proposal)

25 Comments

Perl doesn't need a new name and it doesn't need a new number, it needs radical reinvention.

I'm with Stevan.

That said, "Pumpkin Perl" is probably better than other alternatives I've heard.

The problem, as I see it, is that to the outside world it will just sound like all the various implementation flavors of Python and Ruby. It becomes our "CPython", just with a more alliterative name.

At the end of the day, it's still just Perl to people outside the community. Until Perl 5 or Perl 6 offer something radically new, the brand impressions won't change.

Perl 6 is the language that's still not done.

Perl 5 is the dead end behind Perl 6.

Being thus decked out, she got up into her coach; but her godmother, above all things, commanded her not to stay past midnight, telling her, at the same time, that if she stayed one moment longer, the coach would be a pumpkin again, her horses mice, her coachman a rat, her footmen lizards, and that her clothes would become just as they were before.

Perl 6 has been "the future of Perl" for almost 13 years. Perl itself is just over 25 years.

I'm not sure names are the problem.

This sounds to me a lot like an actual name for the thing that Nicholas suggested (http://nntp.perl.org/group/perl.perl5.porters/198242).

I like the idea of having several distributions, which are basically Perl + some set of modules or other. Pumpking Perl would be the one that's close to what pure Perl5 core is now (contains the modules needed to get CPAN going and not a lot else).

That reminds me about figuring out why one can't "just drop a CPAN tarball in a dir in your core checkout and have it build along with everything else", which would be a start on easy to build distributions of that sort.. (So much to do, so little time..)

I have no idea what this means. ISTM that Perl 6 is the radical reinvention in progress. It's just taking a while.

Such a racket is being made over all this scheming, I just *had* to post this:

http://racket-lang.org/new-name.html

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++.

And what about Perl 6? I'd love to see it called Camelia Perl (6? 1?).

So, there would then be 3 Perls:

* Perl 5.x : stays backward compatible with Perl 5
* Pumpkin Perl
* Perl 6

Is that correct?

If so, would Pumpkin Perl start seeing backward-incompatible changes which won't make it into the Perl 5.x line?

To clarify my earlier comment, I think any alternate identity for Perl 5 that still has the word "Perl" in it won't change external impressions in the short run. I think it will still be perceived as the version before Perl 6. In the long run, the question will be whether and how "New Perl" is able to evolve and whether that can create new perceptions distinct from the old.

ok so change the name of the language, but what executable do you run? pperl? perlp? Again I think what we have is Perl/perl, and all in all, it works. I think we should get to keep it.

I really reject that getting the version number 7 puts a damper on the Perl 6 effort (and if they really think that it does, they should realize we have been living with that for years). History can say "Perl forked between version 5 and 6. Perl 5 became Perl 7 and so on. Perl 6 left the nest, kept it version number and became a distinct language of it own with version numbers of its own."

No one has yet answered my blog post of several days ago. Does P5P/Perl6devs/Larry believe the two to be distinct? When Perl 6 is released will Perl 5 still be a first-class citizen? If so we need control of our own version number, the version number that is compatible with all current perl scripts. To me this isn't very difficult logic.

It's just Perl to people outside because we're not framing their perception in any other way.

MST's idea, which has been presented before, (probably once per year) is a good one. It only requires some solid marketing copy and artwork. We can continue to argue about what Perl needs, but lets take care of this low-hanging fruit for the sake of momentum.

Perception is everything.

MST awesome as always. Check.
Diffusing the situation. Check.
New name for Perl 5, Pumpking Perl. Check.
Color: orange. Check.
New things to throw at mst at end of his talks: pumpkins (the stuffed toy types). Check.
Name for Perl 6 (already available: Rakudo Star, Perlito, Niezca, and more, pick your fav). Check.
Cooperation between development teams of Perl 5 and Perl 6. Check.
Wisdom. In progress.
Back to work. Check.

Pumpkin Perl won't solve the problems Stevan want to fix.

But more importantly, Pumpkin Perl won't be an obstacle to the solution he's prototypinh *and* it will give Perl 5 the growing space it needs until Moe or whatever revision of the internal make it to a production release. Make it clear to the world that Perl (5.16) has made a lot of progress since the 5.8 days and there are good things coming up.

Furthermore, I think it will defuse some of the mixed feelings between the Perl 5 and 6 communities, again by giving Perl 5 growing space until it's Christmas.

C.

>I like the idea of having several distributions, which are basically Perl + some set of modules or other.

But this is just what Linux is!

See the dread DistroWatch 'Page Hit Rankings' down the right-hand-side for a plethora of named versions.

So we need a name with bite: Arsenic, Cyanide, ...

I've been asked before in job interviews by CTOs and assorted people about my plans to learn Perl 6. In one case because they believed Perl 5 to be completely obsolete and expected Perl 6 to be ready soon, and to be magnitudes of order faster than Perl 5.

As such, the confusion about Perl 5 and Perl 6 makes me actively worried about my future job security.

As such i am very glad to see prominent and important people in the perl community stand up and speak out for a way forward, with paths and options that can actually feasibly become reality.

I'm all for Pumpkin Perl.

It's the best name I've come by, out of all other suggestions during the last few days.

+1 for Pumpkin Perl!

If its time for brand differentiation, then why not just "Pumpkin" ? w/ the Perl 5 part parenthetically referenced in pumpkin -V.


Given the state of tech journalism today (techcrunch and their ilk), I've no doubt it would create quite a stir...the fun, awesome new dynamic language de jure, "Pumpkin" ! And add in some "Big data cloud mobile social graph visualization" something or other in the byline...


I think seeing "#!/usr/bin/pumpkin" at the top of my scripts might help soften the often derogatory comments from my pythonophilic coworkers...

Saw a comment somewhere (unfortunately forgot where and by whom) that - I think - got it right:

Changing the name or the version numbering scheme won't do us any good, unless we're willing to go further. It might in fact hurt us, if people have a look at the renamed language and think: oh, bothing new, only marketing fake - folks must be quite desperate...

I think we need to declare a fairly recent Perl version to be a long term support release (>= 5 years; only security and bug fixes and purely internal improvements) to keep those people and companys happy that have an established code base and are reluctant to make extensive changes.

And then we need to have a different version that includes as many incompatible changes as necessary to create a language that's up to todays demands by default.

E.g.: without having people (especially newcomers) learn about and write ridiculous boilerplate code like Tom C.'s Unicode Cookbook Standard Preamble; with "use feature "unicode_strings" etc. enabled by default; including all changes necessary to enable the in-core MOP and the in-core MOP and something like Moo built on top of it; ...

There needs to be some more discussion about which already existing features should be made default or be enabled by default and what extra features still need to and can be implemented (or removed) if we free ourselves from the burden of keeping backwards compatibility: Let's re-read http://web.archive.org/web/20040207072905/http://www.yetanother.org/damian/Perl5+i/ ? What else? Disable some of the more arcane "magic" be default to improve execution speed (yes, to some extent that's a marketing driven suggestion, but marketing is what mst's post is about, isn't it?).
Replacing XS by FFI might be too much, because there´s a bunch of functionality we absolutely need (XML::LibXML etc.) and also rewriting that might be too much to do in a finite time frame...

Btw.: /me actually thinks that "Raptor Perl" - cf. https://github.com/kraih/perl-raptor - could be nice: old but powerful (though "dangerous to use" could come to mind, too).
There´s even orange in the image ;-)

What currently exists as Perl 5 needs an identity. A real identity that people can both understand and promote. "A member of the Perl family" is not an identity.

Changing the name is not just about changing our comparison to Perl 6. It is about signaling to people both outside and inside the echo chamber that we are willing to move forward. That we want to move forward.

pumpkin presents the best option I've seen for an answer to that. It doesn't solve every problem, but it solves enough. It gives us the room to grow into whatever we want to be.

Someone looking for a new language is going to try "Pumpkin Perl"? I doubt it.

Leave a comment

About Matt S Trout (mst)

user-pic mst