Contrary to the strawman arguments set up and knocked down so easily by people who believe that breaking the DarkPAN is a sin almost as bad as apparent hypocrisy on the Internet, no one wants to change Perl 5 willy-nilly. Yet many people believe that a few carefully-planned backwards-incompatible changes will allow Perl 5 to evolve into a much more powerful, much cleaner, much more understandable, and even much simpler language suitable not only for maintaining legacy projects but also for creating amazing new projects.
I intended my deconstruction of fear surrounding Perl core language changes to continue a long-standing debate. If you read Planet Perl Iron Man or Planet Perl, you've read other people arguing over the desirability of supporting the DarkPAN.
If your code is part of the DarkPAN (and it likely isn't, as you're likely a part of the Perl community if you're reading this), you may bristle at the suggestion that some people believe that retaining core language backwards compatibility to support your code is one of the worst ideas in Perl history. (If you haven't heard that suggestion, let me repeat it: the idea that the Perl community should support hidden and proprietary code of people who aren't part of the community, code that the Perl community can't see let alone test, and code that may or may not even exist is sufficiently ridiculous on its face that it mocks itself.)
Now then.
My previous post suggested that the real problem the Perl community is trying to solve is one of risk management. If it doesn't make sense to push all of the costs to manage the risk that an upgrade might change the way your DarkPAN code behaves to the Perl community (and it doesn't make sense), who bears that cost?
You do.
Don't panic, yet. It's simple to address that risk. I didn't say it's easy. I said it's simple.
Your Responsibility as a DarkPAN Maintainer
As a DarkPAN maintainer, you need to answer several questions about your code.
- Is this software worth maintaining?
- Is this software under active maintenance?
- Does this software need community support for the Perl core and any external dependencies?
- Will this software work unchanged with a newer version of Perl?
- If not, why not?
- What changes are necessary to make this software work with a newer version of Perl?
Software outside of active maintenance can stay untouched. Don't worry about it. (Of course, if you have to migrate to a new machine or a new architecture or other dependencies, it's under active maintenance at least for the sake of this argument.)
The other questions are more important. You need to be able to verify that your code will perform as you expect if you change one or more dependency.
Likely you already need to know this.
You need a comprehensive test suite which can run on any likely candidate machine. You need a test environment where you can run your software's test suite against an updated dependency -- a new CPAN distribution, for example, or a new major release of Perl. You need unambiguous results and comprehensible diagnostics.
In short, you need a sane development environment, just like any serious project worth your time already has.
(You should also have a ten minute build, but if you can verify that your software does what you expect in an hour or less and report the results to the Perl community, you're well on your way.)
If you're really good, you can even test your DarkPAN code against bleadperl or maintenance snapshots just to help p5p understand your expectations (and to understand potential changes to the language which may require you to revise your expectations, if not your code).
Anyone serious about software development should have a comprehensive and useful test suite anyway. It's simple. It's not always easy; the Perl community needs to make CPAN distribution installation and versioning easier and cleaner. That debate is happening. The solution isn't obvious yet, but a process of iteration and refinement will produce it.
Yet any DarkPAN code of such low importance that its maintainers can't produce a test suite to verify that it works isn't worth p5p's time. Forget that code. It's a dead end. Let's concentrate instead on refining a language for serious software developers to write new code worth maintaining.
Contrary to the strawman arguments set up and knocked down so easily by people who believe that breaking the DarkPAN is a sin almost as bad as apparent hypocrisy on the Internet, no one wants to change Perl 5 willy-nilly. Yet many people believe that a few carefully-planned backwards-incompatible changes will allow Perl 5 to evolve into a much more powerful, much cleaner, much more understandable, and even much simpler language suitable not only for maintaining legacy projects but also for creating amazing new projects.
Contrary to the strawman arguments set up telling people "Perl is dead if we don't break back-compatibility" or that "There are people who believe that breaking the DarkPAN is a sin," nobody wants to keep Perl 5 stale. They simply want to make sure the cost doesn't outweigh the benefits.
Nothing against careful-yplanned changes, but that has _nothing_, and absolutely nothing to do with the "Perl is dying and it's your fault" fearmongering and "fuck you" attitude flowing around at the moment.
I find this article all in all very useful and informative, not only refering to Perl code, but projects in general. But assumptions like what's worth p5p's time are IMO displaced. I'm not a part of p5p, but isn't it their choice on what they work? And I very welcome the seeming trend to making Perl more extendable with libraries. That's our future in my opinion. That's where the action is happening, where we will find (many flavors) of new syntax, some modules will make it into core, some not. Since this way allows us to extend Perl with Perl (in many cases, like Devel::Declare provides hooks for perlspace), it also opens the language design up to a much wider audience, more diversity, and maybe even a more fitted solution than something developed in C in core.
To my knowledge, no one in this debate has said "Perl is dead" since the Orwant mug incident (and I'm not certain of the real wording or its intent there).
I have said (and will continue to say) that I believe that the barrier to entry to write modern, maintainable Perl code is much too high for novices, when doing so requires enabling non-default features and installing and using several modules from the CPAN.
I've tried to address this on p5p. I've written code to start simplifying the default experience for novices. I had to work around a feature deprecated since 1994 to do so, and that patch was ultimately rejected. I don't believe the reasons were primarily technical; they were philosophical.
What's my recourse? My business depends in part on being able to teach novices to write Perl effectively and maintainably. I can give up and document core Perl 5 as it exists and try to minimize the risk there. Otherwise I can continue to try to improve Perl 5's default behavior -- and I believe that approach is not incompatible with allowing all of the existing Perl 5 code in the world to run with minimal or no changes.
I do agree that the barrier is too high. However, I don't see the problem with CPAN installations. If you want a simple class keyword in Perl, I don't see a problem with that. But I don't understand why it is such a burden to put it in a library, instead of expanding the core directly. Why not rather make the core more extendable, and include a small module to do this task in the most simple manner. Then the libraries on CPAN that are already implementing a class keyword can utilize that interface.
I just don't think it's too much too ask people to specify, for example, the version number of the default Perl environment they wish to have.
And yes I agree that the decision propably was a philosophical one. In my eye, the question is if it makes sense to a feature in the core that CPAN already played out and made available. It would make much more sense to allow developers to extend Perl from Perl. Devel::Declare is a first start, but if the perl 5 core would be extended to have an easy mechanism to do such extensions, we could have lots of modules giving novices the easy syntax you wish them to have, and they can be small enough to be bundled with the core.
Also: IMO it isn't about having the existing Perl 5 code run with minimal or no changes, it's about having it run with the minimal possible changes, while gaining an advantage that is worth the risk.
I do however feel (maybe because of a lack of understanding of the policies) that the 'use 5.x' specification should be able to activate more than just features. It should be able to activate syntactic elements (like class, method, etc.), it should be able to influence the environment (activate strict and warnings), and probably everything that can be achieved within the file-scope.
@phaylon, there's nuance to what you say. Some features belong in the core. Some are obvious extensions. It's not easy to define exactly what makes the most sense as a language feature and what's a suitable candidate for an extension.
One criterion is how often the feature gets reinvented as an extension. The growth of the Class::* namespace on the CPAN is one interesting data point. If a great percentage of large-scale projects reinvent their own object system, that's a sign that the default object system is insufficient (if flexible).
Lexical syntax modification is a good idea, but if the main driver of providing lexical syntax modification is to implement features other languages provide by default (subroutine signatures, declarative syntax for declaring classes, a method keyword), perhaps it's worth folding those features into the language itself.
I suppose the argument depends on how easily you can distinguish between a library which provides syntax features and a library which provides reusable behavior.
@chromatic: I agree that drawing the line between core features and extensions is often hard to draw. And in general I would agree that often-implemented features might belong into core. The question is, are they consistent? The Class:: packages aren't there because every project invented their own OO system, many of them fill some kind of niche that the author felt was there. So while many seem to replicate behaviour, they also have slight differences, which is the reason that people prefer one over the other.
Just as a note: I personally wouldn't care much for a "class" keyword, since I'd also want "role", "method" and many other things, so I'll have to stick with CPAN anyway. My only personal gripe with this specific example is then that it should be overridable by extensions.
I'd see no problem with having class, method & Co. keywords activated with a 'use 5.xx' line or another kind of feature bundle. But _only_ if it's more than just aesthetics. If we'd also have a way to internally discern between and create modules/classes and methods/functions, that would be great because all of the other libraries on CPAN can build on that. MooseX::Declare's class keyword could create a class with the same semantics as Perl itself. (or rather, Class::MOP::Class could, being the room in the back where the action is happening).
I'm not sure we can simply distinguish between syntax and feature, since syntax can be kind of a feature. What I'd really love is a safe way to hook Perl code into the tokenizer/lexer/parser (I'm not familiar with the perlguts, excuse my vagueness). Because then we can do _lots_ more syntax experiments on CPAN, and we can provide much more ease to the development and research into syntax. IMO we're not far from using sequences of structured Moose type sequences to find and parse special syntax. This could also be easily made extendable (MooseX::Declare, for example, already is).