Why All the Hate?
Recently with all the renewed effort on the part of Perl programmers to be better public advocates of our language, I've noticed an uptick in counter productive and quick frankly hateful comments directed at Perl.
I'd really like to find out why. I'd also like to be reasonable and think there's actually something rational behind all this. Several ideas come to mind. For example, is all this negativity based on Perl's perception as spagetti code? Is that just rumor or have many of you out there been required to step in and take over projects with difficult codebases? Is it due to the fact that Perl 6 is still in development? Has it to do with something many of you have experienced on the job? Or maybe you've tried to get help from various Perl communities and gotten flamed?
I really have trouble understanding where this is coming from. Personally, I use Perl because I find it works with my brain and not against it. I've not found this to be the case with PHP, Python or Ruby. I have nothing against any of those languages, but it makes little sense for me to force myself to relearn and rebuild my current skillset in a different language that doesn't really offer me a compelling reason to do so. I'm deeply invested into the Perl community as a contributer to several important open source projects and that's what I enjoy about my job.
However the negativity is something I'd like to address if possible, because all this hate directed at Perl can affect me personally in terms of future employment and job options. This directly affects my family, my wife, son and dog, so I take it very seriously.
Because to be quite honest, the combined popularity of the most common scripting languages doesn't come close to countering the Java/C# juggernaut, and as someone committed to open source / free software this is an additional worry for me. Neither of those languages are particularly committed to software freedom. As far as I am concerned Sun (or Oracle now I guess) and Microsoft give some lip service to software freedom since that's a popular thing nowadays, but it's minimal and tactical in nature. Free free to argue with me if you think I'm wrong, but I just don't see a deep and fundamental commitment. Now, maybe you don't care about software freedom, but I'm old enough to remember the days when being a programmer nearly always involved proprietary tool chains and expensive certifications. If it wasn't for the threat posed by developers and advocates of free software there would be no Java Community Process, no Mono, nor would there likely be quality free version of IDEs like NetBeans, Eclipse or the various free 'Express' versions from Microsoft. There would be no free, online versions of documentation. So it really seems to be we should be working together, not against each other.
Several possible points of collaboration that suggest themselves would be standards for testing, deployment and management of applications. Also, we often depend on a core set of external libraries, such as MemcacheD, xml and xslt parsing libraries and so forth. It would be great if we worked together to improve these and to ensure that the language bindings were of consistent and high quality.
Each of our communities has different strengths and weaknesses. The Rails group are great at advocacy and Ruby has a reputation for delivering nice, clean code. Python really focuses well on education and ramping up newcomers. Perl has great testing and deployment tools, as well as CPAN. Why are sniping each other when working together would have so many benefits?
My Groups
-
POE Updated: 3 days ago
-
Perl Updated: 5 days ago
-
ProNet Vox Community Updated: Oct 29, 2009
Neighborhood
Explore friends, family, friends & family, or entire neighborhood.
Comments
The Perl module system was always difficult to install and use, especially if you did not have admin access, but now with modules and dependencies that have not been updated since 2004 it has become a minefield.
Perl developers, meanwhile, have fragmented into Rakudo, Parrot, Strawberry, and gawd knows what else, none of which is even close to production, and most of which likely never will be.
If you sense a bit of hate on from Perl developers, it's because we put a lot of effort into what was really a good language, only to see maintenance and development turn into a farce.
In general, you should use your OS package manager for installing modules. If you want latest versions - you have to live with possibility of error. Using CPAN::Reporter helps to make bugs fixed earlier.
Installing modules was made easier recently with configure_requires implemented in all parts of install process and Module::Build entering core.
Thanks for the frank and open feedback. I felt similarly about three years ago when I nearly gave up on Perl. For me, a few very interesting projects, mostly Catalyst, Moose and DBIC, got me to stick around. There are definitely things you should be doing to ease the install pain, such as using local::Lib and some other tricks which are known within the community but not promoted strongly enough. Things are getting better. I remember the first time I installed Catalyst, about 3.5 years ago, I struggled for hours. Two days ago I got it to install with one command and no fuss. So the community is taking this issue as seriously as time allows. Part of the problem is there is a lot to do and not enough skilled hands with time, so we triage the worst problems first.
One serious problem you mentioned is how some important modules seem abandoned. Partially this has to do with the lack of enough common framework built into perl, such as it's minimal object system, method signatures, etc. I've spoken on this before, that this tends to make each Perl module a bit too much of a snowflake all alone, and hard for people other than the original author to work on. I think Moose has really helped with this, as it provides a deep framework around which enough best practice context exists to smooth the learning curve. That's why I am not surprised to see Catalyst development kick up a notch now that it's on Moose. I expect the eventual port of DBIC to Moose will have a similar effect.
However part of this solution has to be that we as Perl programmers need to take a more active role in maintaining our stuff. If an important module that you need is having trouble, that you should make the effort to offer a patch. Again, I realize this can be tough and we need to do more to make it easier for newcomers to join in.
For the issue of how Perl projects often end up strongly expressive of how particular programmers think, I agree that is an issue. As I've said, since Perl out of the box lacks a lot of framework, most programmers end up plugging in the gaps with very personal solutions. I personally believe that Moose is helping us to solve this problem. As I've written elsewhere, Moose really helps plug in a lot of gaps and I believe anyone starting a new Perl project should seriously take a look. I believe over time, projects like this will help grow our ecosystem of best practices and reduce the local contextuality that beleaguers newcomers and raises the learning curve.
Also, I think that we need to do better with developing and sharing the load of code maintainence. This is something we are learning to do, and I've also written about it here. Between these two things I think over time you will see less idiomatic Perl and more concensus about the best tools and practices. Now, Perl will always to a certain degree more 'DIY' than a lot of languages. That's one of it's key differences and a reason why it attracts a certain type of mind. Not all people fit, but that's fine because there's other options. Perl is a ruthless meritocracy and we don't like to close off the new, radical idea by overly standardization. Personally, I would like to see the next version of Perl have fewer standard modules than more. Projects that are great, attract lots of developers, having regular CPAN releases, etc, are going to rise to the top. Ones that don't will just fall below the surface.