Perl 5, Perl 6, Perl 7, Perl 2013, whatever
It seems people outside our community sees Perl as an stalled language because we have not released a new mayor version for so many years. We have to do something to show them they are wrong, right?
Well, no, maybe the problem is ours, unable to see what we don't want to see: They are right. Perl 5 is stalled.
Stevan Little has already described the situation quite well on Perl is not dead, it is a dead end. The funny thing is that it is mostly the same view that started Perl 6 more than a decade ago. It still holds.
From my point of view the mayor problems with Perl 5 are as follows:
- Its internals are a mess: complex, with lots of code rot caused by mis-implemented features, undocumented, etc.
- Backward compatibility: it is very difficult to evolve something when you have committed to almost 100% backward compatibility.
- Under-designed features: just look back at all the features added since Perl 5 came out, most of them are broken in some way or incomplete. Smart-matching, threads, ithreads, attributes, lvalued subs, prototypes, tie, overloading, unicode support, etc.
- Lack of some features people coming from other languages take as granted: threads, exceptions with specific handling syntax (try, catch,etc), function prototypes, etc.
But these are the technical problems, the easily solvable ones!
The real, real, real problem is that perl5-porters doesn't work. Don't get me wrong here, I really appreciate the work all the individual porters do. It is just that as a collective they are not able to evolve the language.
As I see it, Perl 5 needs a leader* (and that may be one person or a small committee). Somebody who says what Perl must be, with a long term vision, able to assume risks and take decisions and that is respected by the big Perl 5 community.
Then the leader may need resources, people able to do what he says.
Until that happens, Perl 5 will keep being as is, maybe with minor improvements or additions but nothing really deserving the Perl 7 name. People outside our community will only laugh if we try to sell then what we have now as the new Perl 7. Our credibility is already low enough, so, please, don't do it!
In the mean time, there is Perl 6. Yes, they did pretty bad on the past, being too ambitious and trying to work in too many fronts at the same time, unable to provide us with Perl 6 on time. But now, when nobody is still expecting it, it seems to me they are going to reach the point of producing something useful and beautiful. If I had the time to get into some project for fun, believe me, it would be Rakudo/Perl 6.
* Yes, perl5-porters have the pumpkin, but I don't see any of them had assumed the leader role, they act more as tutors or peace-keepers. Note that I don't intend that as a critic to them, because this is probably what was expected.
yaph
I'm glad to hear you find these technical problems easy to solve! So far, they have not been solved. When will we see your patches? I can assure you we do apply patches that fix problems and add well-designed features.
Ricardo, sorry if I didn't make it clear, but that sentence was mostly a joke. Well, just lets blame my limited English skills for that.
In any case, now that you are here, and seeing all the people worried about the future of Perl 5. It would be nice to have some reflexions on the matter from you as the current pumpkin. How do you see Perl 5 evolving on the future? What are the realistic expectation we should have?
That list isn't really a technical list. It's a list of the things that p5p doesn't violate from its implied social contract with users. Perl 6 didn't start for technical reasons. It started to break that contract. A big part of that discussion was the toxicity of p5p and the personalities who controlled it at the time.
Patches aren't always the solution, and the "patches welcome" sentiment is really "fuck you—go off and fix it alone before you talk to me."
I'm not advocating any particular technical or feature position. I gave up on p5p. Do what you like, and I'll just help people deal with the result.
It's this sort of useless, energy-draining, and laughable discussion that makes the people capable of real technical innovation want to give up on perl, perl5-porters, the interwebs, and life in general. Just say no and let's all go back to writing useful code. We've lost our share of brain this way in the past years. Let's not lose the rest.
I'm sorry to have misunderstood you. It's unfortunate that there has been a lot of bluster that does come off like, "There are a lot of easy solutions if people would just stop arguing and fix things." In general, what I have seen is that this is not true, and that no one is forthcoming with the solutions that they claim are easy — so I hope you can understand why I was frustrated when I read you as seeming to say that we had easy solutions!
I think that the chief problem may be the lack of contributors working on those areas that are often complained about: speed issues, flexibility of the language, and some other things. The next problem, or perhaps quite tied up in the first, is the technical difficulty of becoming a new contributors. On one hand, the code is quite complex. Not only is it necessarily complex, but it is also old, and has not always been kept as consistent throughout as one might like. It makes it technically difficult to contribute.
There are also non-technical hurdles, in that perlbug is a pain to use, the core is not as well documented as it could be, and it can be difficult to get code review.
As to the notion that the mailing list is hostile to new contribution, I think that this is largely untrue. It is unfortunate that there is sometimes a storm of unhelpful nit-picking, but I don't think that useful contributions are often shouted down, at least in recent years. I have tried to help prevent this from being a problem.
So, if the question is, "Where are we going next?" I'll say what I said in my 2012 talks on the subject: we're going wherever the patches take us. I have not seen the percentage in declaring a roadmap, because I am not going to be the one implementing features. I would like to try to improve the culture of the core development to allow people who want to contribute to do so easily, and I hope that those future contributors will help us produce a better language. Recently, for example, someone came forward with work on adding (!) core subroutine signatures. This work looks quite promising, and I hope to see it landed early in the version 19 series.
Apart from that, certainly there are features that I'd like to see: fatal implicit closes, exception objects, a core MOP, possibly some form of autoboxing. I'd love to have an improved method for character/byte disambiguation, but it seems difficult to add without breaking existing abstractions. In the end, though, I am not the one who is going to be making these changes, so it would be foolish for me to put them forward as the clear roadmap.
I really do welcome patches, because they're the thing that can actually drive the Perl 5 implementation forward, as opposed to talk about patches, which seems to come quite cheap.
Ricardo, thank you for your detailed and thoughtful answer.