2¢ alert. Also, IANAG.

The Perl renaissance started without things like Devel::Declare. I'd argue the resurgence and bloom of new tools and kits is not based on syntax, preceding tools, etc at all. It's entirely on the enthusiasm of immensely talented individuals and the amazing productivity that has been possible with Perl for a looooong time.

What you seem to be boostering for is a roadmap to turn Perl 5 into a crypto Perl 6 but without all that controversy, mess, and decade of prep-work. This sounds like an awful idea to me.

Perl 5 is alive and kicking because 1) There are some hella raw, permit me to date myself, developers doing really neat and productivity boosting stuff, 2) Perl 5 is, has been, and should remain be the kind of language, maybe the language that attracts interesting, creative, and experimental developers in numbers.

If you want to see Perl 5 continue to be a language of choice, the key is understand why those developers choose Perl. The facility and freedom of choice/style/approach that Perl gives is, at a minimum, part of that. Maybe most of it.

You're pondering ways to take Perl 5 forward. Perl 5 is moving forward. 5.10-5.14 is happening very fast. Anything involving centralized planning seems to me more likely to get in the way than help things keep moving.

Plack strikes me as a perfect example of how Perl 5 is teh shizzle now. Someone notices that ruby and python were doing some cool stuff and said, “Why don’t we have that in Perl?” And made it real in the space of… what? Didn't miyagawa whip it up in like a week? Look at the ecosystem that’s grown up around it in less than a year.

What is best for the future? COGTFO. Not to be rude but because I write Perl for productivity and for fun. These types of discussions do not serve either.

The problem with this approach is there is no one true way of doing things,

Let me remind you that the Perl philosophy encourages Timtowtdi, "there is more than one way to do it". If you want one true way, python fits your philosophy much better.

To answer your actual question: experiments in core are a really bad idea, because of the need to offer backwards compatibility. Experimenting requires the ability to throw stuff away, which you can't in core (at least not easily).

p5p has noticed that too, which is why they are happy to have syntax experiments on CPAN, not in core.

Let me remind you that the Perl philosophy encourages Timtowtdi, "there is more than one way to do it"

I think that has more to do with solving a given problem in more than one way, or using a different syntax (From the available ones) to solve a problem. What I'm speaking is more on the lines of using 10 different ways of class declarations, or switch statement declarations, each one looking different than the other. Thats a lot different than the TIMTOWDI philosophy. And is not good either.Perl may offer flexibilities to use various kinds of syntax to solve a problem. But it provides only one way to write a particular syntax.

I think that has more to do with solving a given problem in more than one way, or using a different syntax (From the available ones) to solve a problem.

Sure. But don't forget that CPAN modules cound to "avlailable ones".

What I'm speaking is more on the lines of using 10 different ways of class declarations, or switch statement declarations, each one looking different than the other. Thats a lot different than the TIMTOWDI philosophy.

I don't see the difference at all.

Perl 5 has no class keyword, so people invent their own mechanisms, upload them to CPAN, and then there's more than one way to do it.

Over time, one or two prove to be universally useful (seems to be Moose), and emerges as a quasi standard.

And is not good either.

No? I like the result. I'm pretty sure Moose is better than what would have come out if p5p had decided to build the one true object system in perl 5 core.

Perl may offer flexibilities to use various kinds of syntax to solve a problem. But it provides only one way to write a particular syntax.

Really?

say $x if $x > 0;
if $x > 0 {
   say $x;
}
[download]

That's two ways to write an if. Does it hurt Perl?

But it provides only one way to write a particular syntax.

Even if it were true, that's still besides the point. Various OO modules use different ways to write something to achieve (nearly) the same semantic (and not syntax). And that's exactly what timtowtdi is about.

Update: Your reply sounds like "timtowtdi is fine, but not in this case". And I agree that it's a good idea to supply a good default way of doing it, so that people don't feel lost, and consistency is achieved. But since it's usually not clear from the beginning what the default should be, we need many ways to do things in order to later pick a good default. Even for seemingly simple things like class declarations.

Perl 6 - links to (nearly) everything that is Perl 6.

The current feeling on p5p seems to be like this:

• If it can be implemented as a stand-alone module as easily as in core, put it on CPAN.
• If it's "big", and it can be implemented as a module in any way, and the point above doesn't apply, first implement it as a module. Only when usage has flushed out all kinks, and actually have shown a need, inclusion in the core may be consideren.
• If you have a patch, and regression tests, and you can convince p5p it's a good idea, and it doesn't slow down current code too much, and it doesn't break existing code^† and any of the points above don't apply, it may be included in the core.
• If it's a bugfix or performance improvement, it's likely to go in.

^†Actually, code gets broken all the time. p5p just tries to be very careful, weighting the benefits of a new feature to the likelyhood of code breakage, and if all possible, have a full deprecation cycle. (So, if you have a patch that breaks something in 5.12, 5.14 will have the old behaviour but with a warnings, and the new functionality will be in 5.16).

Perl now has to deal with a very old problem of programming languages:   a vast “installed base” of production code, worth millions of dollars.   It now becomes much more important that this code continues to run, as efficiently as possible but also “exactly as it now does.”   Basically, forever and forevermore.

New versions of Perl will, of course, continue to emerge, but I think that they will necessarily chart a parallel course.   And yet, we will continue to see some truly innovative developments within each track.   As an example of this, well, I think the Moose package for Perl-5 speaks for itself.   It allows the programmer to produce significantly good code, to do it with great brevity, and to do it within the context of “what has been done before.” As such, it is much more practical from an engineering point of view.

“What will replace Perl-5?”   I submit, “nothing.”   Not for a very long time.   And so, instead of railing against that thought and insisting that it must not be so, I suggest that this pattern is quite typical in our industry, and not altogether a bad thing.

“It’s not about the software.”   It’s not about the language.   It’s about what the rugged software that we build does.   It’s about our continued ability to deliver it, to maintain it, and to keep it flawlessly in-service.  (Whether we say of it, “phewww-w-w-w-w!! this stinks!” or not.)   Every single other thing is of decidedly less importance.

I guess what I’m trying to say here is:   discussions of What’s Best are good and valid and should be pursued (as should be Perl-6, which should advance the language).   But we must also keep things firmly in-context.   The things that we are discussing will not change the world ... and, I would also point out, they don’t need to.   Perl is “Very Good.”

I rather like to say... “while other languages are debating what is the best color to paint their pickup trucks, Perl just hauled another mile-long freight train past their garage.   And it’s gonna keep doing that, all day and all night.”   There aren’t too many languages out there (COBOL is one) that can actually say that.   And so, people have grown to completely rely upon what Perl can deliver.   In our world, then, the gem of theory is always going to be polished against the whetstone of practicality.   Our customers, and our employers, are in the business of freight.

I'm not really sure I understand the purpose of your post. So if I miss, sorry.

I see Perl5 continuing to evolve. I see Perl6 as something quite different, that I would love to get my hands on a full implementation of, but am not holding my breath. If it ever happens I think they would likely coexists for a very long time. I think the best way that Perl6 could support Perl5 would be to just embed the existing perl5 interpreter. It could then run all existing Perl5 code and modules and interoperate without "shelling out".

I love some of the recent additions to Perl5. Though others--smart matching; given/when--haven't really floated my boat much.

Had I the wherewithall to lead or influence the next phase of Perl5's development, I would avoid the addition of new functionality and spend a cycle or two consolidating the existing code.

I think that there is much that could be done to improve the performance of subroutine calls, memory management, 'magic' handling, and unicode processing. Improvements in these areas would have a significant impact on everything else built on top. It could, for example, have a significant impact upon the performance of heavy, sluggish layers like Moose.

I'd also like to see some of the historical artefacts addressed. Things like input & output separators etc. being global rather than per-handle. Basically a clean-up of some of the many well-known existing Perl5 problems rather than the addition of new functionality.