Why I hate Perl
2014-02-08 18:23:00.731958+00 by Dan Lyke 3 comments
When I took my current job, I was really optimistic. I had enjoyed writing Perl for my various personal sites, I had done a bit of Perl professionally back in the .com boom, and I thought that this was a chance to explore a language that allowed tremendous productivity in a professional setting.
Now, about two years later, I want nothing to do with the language. I'm rewriting the system which generates the static HTML at Flutterby.net in C++ (and quite enjoying both the typed language and the performance gains), I'm pushing towards other back-end technologies, and I'm trying to get into the habit of using other languages for my little utility scripts, just so I don't keep falling down into the Perl well.
What can I point to as the source of this turn-around? This isn't by any means exhaustive, but, in no particular order...
Perl is notorious for "TIMTOWTDI", "there is more than one way to do it". This makes Perl a wonderfully expressive language, but it also means that there's tremendous cognitive load associated with different coding styles. Consider a multi-line string. I have seen:
$a = <<EOF;
This is a multi-line
string
EOF
and
= "This is a multi-line\nstring\n"
and
= "This is a multi-line\n"
."string\n"
and
join('', map { "\n" } (qq/This is a multi-line/, qq/string/));
Unfortunately, that last one shows up far more often than it should.
Perl has no type safety, and the type coercion rules must be approached carefully. We've all made the goof of accidentally confusing scalar and list context (Although not all of us have been interrogated by the police after making that mistake, Flutterby link here). Of course smart coders will explicitly cast scalar()
around code that they mean to be scalar, just to make the point clear, until someone doesn't and everything goes to hell.
I mentioned earlier this week about where 0.00000000000000711 became 7.11E-15 became $7.11. I'm not sure what the actual chain that led to this process looked like, but I can imagine. And, of course, the fact that there isn't strict typing means that the general edict of "currency must be in pennies" goes quickly out the door as soon as you get some guy with a CS degree on your team who hasn't thought deeply about what a divide means and not explicitly casting back to an int
, or saying "Let me just round to two digits with a /^(\d*\.\d\d)/
".
The standard solution to this sort of typelessness is to throw Moose at it. This feels really good, at first, but then the side effects kick in, and you're looking at a stack dump and thinking "how the heck did we get there?" and then the performance penalties bite you, and then you're back to "no, really, let's just put it in a hash and be done with it."
And, of course, Perl's system for references for complex data structures is basically like C pointers. Which is awesome if you're a C coder (I am), but it's hard to explain this stuff to people who learned programming in college.
Perl has no good SOAP environment. There are basically 3 different SOAP environments on CPAN. All of them are buggy in their own unique ways. You will end up sniffing the wire or otherwise hacking deep in the bowels of them to end up debugging interop problems, usually with people on the other end who are completely clueless because they're using Java and SOAP just works.
Dist::Zilla. Yeah, it's awesome. Until you can't figure out how to tell it to not include that one dependency which you can't install on the ancient production machine and which is only used in tests.
Speaking of which, Ruby has gotten really good about versionitis and packaging specific versions of libraries for a deployment environment. C and C++ are pretty damned good about this, either with static linking or with careful thought. local::lib
is not a solution nearly as often as you'd like, and having version dependent library trees scattered throughout your deployment environment plays hell on security upgrades.
SSL and the various Perl sockets environments. Hate. Hate. Hate.
Character encoding. 'nuff said. If you're gonna fuck it up that badly, gimme back my goddamned pointer to bytes in memory and let me figure it out.
Many of these issues are exacerbated by the particular environment I find myself in, but my impression is that the Perl 6 wankery is making its way more and more back into Perl 5, with more emphasis on hidden side effects and "elegant" code which would be awesome if it works, but makes it completely impossible to figure out what the code is doing by looking at it.
And then we're in debugging and we'd be better off back in gdb
and C, because there's just less abstraction to muck with.