One real gem from this article: "The collective test suite of the CPAN is the continuous integration test suite of the Perl 5 language itself."
All the tests written for all the Perl modules on CPAN are effectively also tests for Perl itself, because when a new Perl snapshot causes any test in any CPAN distribution to break, the Perl maintainers are automatically notified so they can fix it. That's pretty cool by itself, but it also speaks to the attitude that if a change in Perl 5 core breaks a test, by default this is a bug in Perl 5 core that must be fixed.
It's interesting that by taking this seemingly limiting attitude ("don't break working code"), you gain the ability to treat all the tests for code written in your language as tests for your language.
This is a really cool concept. And no, I don't know of any other languages that have something like this -- but I'm not convinced it's actually a good thing. Promising to never break old code means that your language can never really fix old mistakes. The only way you can evolve your syntax is by adding more, never changing or taking away ideas that turned out to not be very good. But, at the same time, not breaking old code is really nice, and something that has probably helped to keep perl relatively popular.
One solution I like a lot actually comes from a terrible language. The Stata statistics package has its own language, that is awful. But at the top of each file, you can specify the version of the language that you are writing in. If the version isn't specified, it uses the most recent interpreter; otherwise it uses the interpreter specified by the version. It allows the syntax to evolve without ever breaking backwards compatibility. Newer versions can call functions[1] written in older versions, so they still have to maintain backwards compatibility of the virtual machine. But aside from that, they could completely rework the syntax and no old code would break.
From a programmer's perspective, it's a fairly elegant solution to handle different versions.
--edited a few times for clarity
[1] Stata doesn't really have a way to make user defined functions. Instead, they're called programs, which should give you some hint as to Stata's awfulness.
They don't promise to "never" break old code. There is a big discussion about cleaning up Perl going on (and getting funded by The Perl Foundation) I believe.
It's frustrating trying to tell people that Perl is a good language because they can't see past the prevailing myths. Very few people don't elide a giggle when I tell them that Perl has the best testing culture and tool-chain out there. There is quite a lot of ignorance out there when it comes to Perl.
I see the CPAN, CPAN Testers, and Perl QA as a gold standard. There's a lot to learn from what they've been able to achieve. It's nice that more programmers are testing their code, but the nice thing about tests is running them! And the best thing about computers is that they can automate it for you which sadly doesn't happen often enough afaict.
Great article and worth a read. I hope it will inspire some people to check out these tools and reconsider Perl.
(Maybe I'm an odd duck, CL is my favorite language but I think Perl is good stuff too)
Coming from a Python background, I would love to know some more details about Perl's benefits. Are these benefits due to a good testing culture that can be learnt by other communities by sharing best practices or are there certain unique testing Perl libraries that are not found in other languages?
In my opinion Perl's culture is an exemplary one. Lots of very smart people being polite and helpful to one another. The CPAN is a tremendous tool.
What makes Perl interesting to me is the philosophy behind the language design. "Since Perl was designed (loosely speaking) by an occasional linguist, it was designed to work smoothly in the same ways that natural language works smoothly." (1)
The three mantras that I remember from my days writing Perl are: "tim-toady" (There's More Than One Way to Do It); "Easy things should be easy, while hard things should be hard;" and (borrowed from Voltaire) "don't let perfect be the enemy of the good."
Perl is messy, because language is a messy business. Perl is expressive, in part because it is messy. Perl is fun to write, and if you have the spare cycles it's worth your time to explore, purely for the mental calisthenics.
>>Easy things should be easy, while hard things should be hard
:-)
"Easy things should be easy and hard things should be possible"
Please don't link to illegal copies of books. (Besides, the fourth edition of "Programming Perl" is released.) Chromatic (the author of the linked article) has a very good and recent book about modern Perl instead, with a pdf online.
Python and Perl communities are both pretty matured in terms of their overall ecosystem.
The difference is in their niche. Perl continues to retain its niche on the CPAN end- To provide solutions to nearly every problem you are likely to face. Its also very easy to rapidly prototype with Perl, you can build things very quickly, there is tons of documentation, help and nearly all your day to day problems have been solved and answered somewhere or the other.
Unicode, CPAN, Regular Expression, Functional Programming, Text Processing, Data Processing, Large Data Munging et al continue to remain Perl's core strengths. You also have good web frameworks these days.
If you have a little time for learning great programming stuff you must take time to read Higher Order Perl by Mark Jason Dominus which is a free book.
I totally agree. Perl is one language that takes testing quite seriously. Just installing some CPAN modules and seeing the numerous tests run gives you a hard on (I mean, a hardened server)
Agreed, what I missed from Perl when I moved to coding Ruby was the excellent testing support. Now Ruby's testing has improved a lot since then, but I believe the Perl testing culture to still be superior.
Awful code written in perl is not a language problem. But by the same token, a good testing attitude from some people who write in perl is not a language feature either.
You've got it wrong dude, it's the testing infrastructure that's the key not the attitude. The infrastructure is built with perl, and has been the inspiration for other languages attempts at part of the infrastructure.
True, but we are talking about more than just "good attitudes" here. Automatic testing that happens with every commit does constitute as a language feature.
All the tests written for all the Perl modules on CPAN are effectively also tests for Perl itself, because when a new Perl snapshot causes any test in any CPAN distribution to break, the Perl maintainers are automatically notified so they can fix it. That's pretty cool by itself, but it also speaks to the attitude that if a change in Perl 5 core breaks a test, by default this is a bug in Perl 5 core that must be fixed.
It's interesting that by taking this seemingly limiting attitude ("don't break working code"), you gain the ability to treat all the tests for code written in your language as tests for your language.
Do any other languages have something like this?