Matt S Trout (mst)

I like the idea a lot, but the name makes only sense to native speakers with a specific cultural and linguistic background. I wish you had chosen a name that was less awkward to spell and write. "pumkin perl" sounds a lot like "pam pam pam" or similar noises that my baby child makes when trying to speak ;-)

If we're going to do it, then let's do it already. I'm willing to say that as soon as this is released, I will push for a migration to it at $work.

Anyone else willing to take that pledge?

I'm glad you've taken the time to reframe the debate here and bring it back to solving one specific problem rather than "well, if we do x then we have to do y, z etc as well". Fixing a problem of perception is important. It's low hanging fruit, to be sure and why not just get it out of the way so that people can stop worrying about it and focus on other, harder to solve problems?

I wouldn't have sat down and come up with Pumpkin Perl as a name, but I can get behind it as a solution to this particular problem. Besides, alliteration can't be a bad thing. :)

I too will say that pumpkin is not my favorite name, but since I am for building a shed and could honestly care less about the color, then I say build it. I will support the name.

Does it fix the problem? Does it change Perl 5's lane far enough that Perl 5 and 6 no longer have to worry about disrupting each other? In my script, how do I get pumpkin perl? `use Pumpkin;`? `use 5.20;`? `use 7;`? `use 1;`?

I'm not asking this as rhetorical or loggerhead question, this is important for the implementation (IMO). If its still in the 5 version number we still have the same problem.

The name may only make sense on certain platforms.

Pumkin perl is the modern version of perl.
The old version (system perl?) available on some OS's (eg redhat) is not compatible.

On Windows there is Strawberry perl (and ActiveState of course) but will we have Strawberry Pumkin perl for this platform? Rename it to be Orange perl?

If we want to have a new perl 5 and promote it as such then we should add into core some of the things that people say that perl is missing, eg OOP, (Moo or Moose etc), then add others and we can properly say that Pumkin perl is the modern version of perl with all these extra features that do not have to be fetched from CPAN.

But by the time we agree what these features should be, perl 6 may be complete :)

Matt, you forgot to include the people who actively think this is a bad idea. Most of whom probably won't talk to you directly or comment via this blog.

Don't mistake the handful of vocal supporters for broad community consensus.

I have the same problem with the name Pumpkin Perl as 27escape, i.e. there are already a number of Perl5 distributions with batteries included with that naming scheme so it will be taken as that instead of as a new Perl.

On the other hand outsiders would immediately recognize a Perl as being a different kind of Perl than the Perl5 they associate the name Perl with today due to the C->C++ relationship. My own preferred name would be Perl** to avoid the oo assumptions.

Anyway, as long as it breaks the Perl 5 deadlock I'll support any name.

27escape: your concern about RH and other stubborn OS's not picking up a new version may argue for my suggestion of dropping "Perl" and just keeping "Pumpkin". And if its positioned as a new language (albeit inheriting much from its lineage), in fact set the 1st release as Pumpkin 1.0. OS vendors may not pick it up immediately, but if its a "shiny, new" language, it may be easier to bundle vs. "Perl 5.8.8 is good enough, if it ain't broke don't fix it".

I'd also suggest that dropping the Perl part and calling it "A New Dynamic Language" allows Perl 6 to proceed wo/ any further whining from the Perl 5 peanut gallery.

I have some thoughts, but they're not really "well, if we do x then we have to do y, z etc as well", more "there are many things y which are hard to get away with doing without doing x".

And by that I mean, if we only change the name on the box, but not any of its contents, then we'll be kicking ourselves later, because some of the changes we could be doing are most opportune to change when you change the name on the box.

We could still possibly steal the name 'perl 6', but its unlikely

One thought I had which I know is crackbrained and will never happen, would be to request from the Perl 6 team to have them standardise on a new name, and let us take the name "perl 6" as a future release of what is now Perl 5.

Sure, there will be initial confusions, but they're the sort of confusion that will go away and become only historical.

Then we can truely start to respond to peoples questions about Perl 6 with "I'm using Perl 6 now" and pointing to the Perl 6 download link on CPAN.

And by the time we get to using Perl 6.20.0 people will have possibly largely forgotten about the problem, and they'll have to have a smarter, more informed argument than "but where's perl 6!!!hurhur duke nukem hurr hurr", which will will likely never go away by simply naming a successor of Perl5 "Pumpkin"

But this suggestion is mostly an academic one, not a serious one, as I'm not in the mood or in position to request the people behind the Perl 6 project at present to relinquish this name, because it will likely be interpreted as a sort of "fuck you", and I don't want to do that to them, its more a suggestion of "hey guys, if you want to help us out, this could be of use".

But that aside: lets pretend its a fork

I think the adoption of a new name will be most effective if we do it like how one would expect to see a "complete fork" occur: Allow the present Perl 5 to continue on for some time with its own releases, and have the new line from Pumpkin 1.0 have

• A separate binary
• A separate name
• Seperate install paths.
• Seperate Library dirs.

( And after all, Saying "We started a fork of Perl5" has more sensationalist victory points in its favour for rabid media dogs than "We're renaming Perl5 as Pumpkin Perl" ;) )

This will allow us to do something that we've not really been able to do presently: Have downstream Linux OS's easily maintain 2 separate versions of this language in the same %ENV, without needing to do magic changing PERL5LIB/PUMPKINLIB and friends just to run a different program.

Instead, Downstream will be encouraged to just work with it as if it were any other "new" language, and it should be able to be installed easily in parallel with perl5.

And doing this has fringe benefits we can utilize if we want to, either now or later. e.g. breaking backcompat in slightly more drastic ways.

And if we choose to, we could maintain a Perl5 release series in parallel with a Pumpkin 1 series, Perl5 focusing on keeping backcompat / while adding non-invasive features, and adding more invasive and backwards incompatible features to Pumpkin.

Consumers would no longer need to be told "Well, if you want to run X you need a newer perl", or the inverse, "If you want all your consumers to be happy, you better not use features only available since Y" . Either X is available for their perl, or it is not. If X is available only on pumpkin, then its the same usage scenario if X is only available on Java.

We could also have a split cpan, maybe something funky like "metapumpkin.org" that contains anything already on CPAN that "just works" already on Pumpkin, which for the most part would only likely exclude

1. code that is silly and uses system('perl') instead of system($^X)
2. has #!/usr/bin/env perl instead of #!/usr/bin/env pumpkin
3. has hardcoded library paths.

And a and c are mostly grievous code smells anyway, but I'm probably missing out some =).

Additionally, The benefit of doing this masquerading as a fork, is that if our ideas turn out to be a load of wank, we can scrap pumpkin and go back to good ol' Perl5, and the public audience can be told "Well, there was a fork of Perl5, but Perl5 proved to be better than the fork, so... if you think you can do a better job, go right ahead" .

=)

p.s. Oh, and Orange Acme will be all over that orange pumpkin shit. london.pm.org is already themed and ready to go.

p.p.s. Onions and Pumpkins together make fucking great soup.

Pumpkin Perl? Wow, that is a rename all right. That is all I can agree with.

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

That would make an awesome option to perlbrew, er I mean *pumpkinbrew*!

I don't see the Strawberry Perl thing as being an issue. It becomes Strawberry Perl based on Pumpkin Perl - there is no Perl 6 variant of Strawberry. If such a thing comes into being, it'll get its own name.

I like this as a straightforward way of dealing with a problem I get at times, where a client or contact is thinking of going for Python or Ruby, but won't consider Perl, because "Perl 5 is obsolete and Perl 6 isn't ready". You know and I know that's not how it is, but not everyone who isn't close to the situation knows. This deals with this one problem well.

Just my tup'n'orth ;)

Just a question: does the rename mean to be retrospectively, including Perl 5.0 (1994), Perl 5.6 (2000) and other ancient versions, Perl is still associated with? I'd prefer to take the chance of branding to get rid of this connection of Perl with badly written script from a decade ago. As "Pumkin Perl" is being introduced now, it should mainly refer to the current version of Perl 5, which is Perl 5.16. To be less strict I'd also be happy with Perl 5.14 because the difference to Perl 5.16 is minimal and becacue 5.14 is included in Ubuntu 12.04 LTS, so it will be the most recent version available in many systems for the next years.

So "Pumkin Perl" should be Perl>=5.14 (with "should" in the sense of RFC 2119). This notion does not cost anything but helps to assume modern features such as "say", "//", and "given".

Oh and I forgot to mention the most important aspect of connecting the name "Pumkin Perl" with Perl 5.14 or above: "use strict" is enabled by default.

Ok, I just proved myself about the difficulty for non-native speakers. Is pumpkin somehow related to pumping, by the way?

I proposed some common sense things that a "new" Perl could implement right away. Further for almost all of those things, old code could be run by turning those features off, ie no strict;. Its near the bottom of this post: https://blogs.perl.org/users/joel_berger/2013/02/on-the-version-number-succeeding-perl-5.html

mst: yes, I read your arguments. In a perfect world, I'd agree w/ your intentions. But I've been listening to this Perl 5 v Perl 6 mess for maybe 8 years now ? As you observed in another reply, Perl 6 ain't changing names anytime soon. So maybe its time for radical change on the Perl 5 side (even tho its really not) and just jump the naming barrier altogether.

I'd also suggest that Perl 5.18 (or 5.20) will be sufficiently different from Perl 5.6 (where many outside the echo chamber seem to think things stopped) or even 5.8 (where Red Hat seems to think things stopped), that selling it as a new language may not be totally disingenuous. Mixing in a few popular new features might be nice, but not really needed.

Thit is truly genius! Pumkin perl will immediately sweep off all ancient perl burden that still comes from google pages. People will search and find new, modern perl examples and find out, that pp is fast and usable. Also we can drop a lot of things, that p5 is suffering of. Fuck back compatibility, move from cpan to github. Clean up from old modules that does not work for years. Shine!

TL;DR: I don't like the idea of Pumpkin Perl.

I've spent hours today writing and rewriting thoughts on this. I'm very fond of Perl, and wanted to express my opinions without denigrating the opinions and hard work of others. Most sentences below should be prefaced with "In my humble opinion ...".

I agreed with many things in Matt's articles today, but I'm sorry, I don't like the idea of Pumpkin Perl. I think it will replace one confusion over language names with a different confusion over language names, and harm the perception of Perl beyond the perl community. And it will essentially distract us from addressing bigger issues.

The biggest problem facing Perl is the lack of a single clear vision for where Perl is going, and a strategy for getting there. And there's no-one (wanting) to provide these things. And the lack of this prompts some people to pitch their vision and strategy (which is where I think Moe is coming from). I briefly hoped that one of the outputs of the perl reunification summit was going to be such a vision, but if it was I didn't see it.

I'd prefer a single unified vision, as I think the greatest success for Perl lies that way. But if there isn't, then there should be two different languages, one of them not called perl.

Perl 6 is really the research department of Perl, and as such shouldn't have a version. Calling it "Perl 6" hasn't helped anyone, and it really hasn't helped perception outside the community.

I'd like a vision where perl 5 is stable and perl 6, 7, 8 become a lean pragmatic modern language. Language support for OO, Unicode, exception handling, constants, concurrency, strict and warnings on by default, etc. CPAN is stuffed with dozens of alternate implementations of features missing from the language, and perl 5i, Modern::Perl, and, and, and. You can easily end up pulling in multiple implementations of the same idea.

It's late. I'm going to go to bed with a Scala book.

Yeah, break compability, remove everything we are suffering of.

Here's one more idea to consider: Name the next version "Perli". It would be Perli 1.0.0. You can pronounce it "Perl eye", "Pearly", or "Perl improved" if you like.

Benefits:

• the name indicates obvious connection with Perl
• the name only adds one additional letter and syllable. :)
• name is different enough that users won't be surprised that you're breaking compatibility with Perl 5.x.
• name is different, so `/usr/bin/perli` won't conflict with `/usr/bin/perl`.
• name wouldn't cause confusion with distributions named, for example, "Strawberry Perl" (in fact, might be the impetus for a "Strawberri Perli")
• Does not step on the toes of Perl 6.
• Enables jokes involving the "Perli Exclusion Principle".

Just an idea to sink your pearli whites into. ;)

Ooh, some other fun little benefits of using "Perli" which come to mind:

• "Pearly" sounds nice.
• (silly) "Here is the Perlian way to do that ..." :)
• The name change should be technically non-disruptive, since it's still a one-word name and its `-v` output would be analagous to Perl 5's: "This is perli 1, version 0, subversion 0 (v1.0.0)".

Thanks for the reply, Matt.

Can you please tell me, would Pumpkin Perl manifest itself as something like `/usr/bin/pumpkin`, whereas Perl 5 would stay `/usr/bin/perl`?

I do really like the name Pumpkin Perl, btw. Creative, connects with Perl history, and is related to one of my favorite pies, and holidays. :) Great choice.

I thought perl emphasis collaborative maintainance over the single hero. I hear "matz ruby" and I'm displeased, but it might be okay because matz is in control of the language despite a lot of competitors who change and enhance the language around.

My proposal was "p5p perl" to emphasis the community over ricardo.
What did he do in the last years other than waving arms and giving
talks? helping in decision making certainly not.
p5p did the work.
A future pumpkin might be more technical, but still naming the
release after him? This is the wrong message.

Personally I do believe that design by committee (p5p) did not work,
but design by a non-technical community pumpking did not work either.
You could call it "stagnation" or you call it "stability".
But not "pumpking perl", please.

No renaming at all.
Forks have to choose a different name for the implementation anyway
(not the language). That's how it works.
And there's no need to be afraid of the forks yet. Worse is better. Normally.

Perl 5 should still be called "Perl". Instead, Perl 6 should get a new name. Let the newcomer sound like a silly pumpkin, not the established language.

Renaming Perl 5 would cause confusion over the fact that all the existing Perl 5 code out there couldn't be called Perl code anymore, it would have to be called Pumpkin Perl code.

Even though the existing Perl has not changed, we're required to call it something different? No, that's not how names are supposed to work. New names are for new things.

Perl 6 is the new thing, *it* should get a new name.

I like the reasoning, I like the idea, and I like the name.

Most people will probably still just say "perl".

But what is the trademark status?

(As for Perl 6, we've already got "Rakudo Perl" and other Perl 6 dialects, so there's no need to have "Rakudo Blackfriar Perl" or something as Will appears to suggest.)

I'm glad that the name "Onion Perl" hasn't been suggested, since that might imply that there is Only One Perl. There isn't, and in the future, we might even have another sibling in the so far fairly small Perl family of languages.

It looks like most of the comments like the idea but dislike the name, mostly because its meaning isn't obvious. To give everyone a worse choice to rally against, thereby consolidating mst's choice, I hereby propose the name Acoustic Perl (analogous to acoustic guitar).