3 ms·
I'm mostly ambivalent towards Perl — but I'm not afraid of programming in it, and there are a few financially lucrative Perl jobs which are such because of Perl
by WesolyKubeczek 6y ago
I'm mostly ambivalent towards Perl — but I'm not afraid of programming in it, and there are a few financially lucrative Perl jobs which are such because of Perl programmers shortage. Usually you need to keep running (and develop new features, too!) a moloch of code that was born two decades ago.
It's not fun and not hell compared to other jobs. If it does keep running, it's not that bad. To put a perspective on it, I've seen Python codebases so overengineered, brittle, and hard to read, that I couldn't help but think that the authors chose the hard way quite deliberately, and that they viscerally hated their colleagues. This doesn't make Python the language bad.
But how Perl handles Unicode and it's plethora of internal flags on strings that make them bags of octets, maybe-invalid UTF-8, valid UTF-8, and other such nonsense — is driving me nuts! Because it's documented right there in `perlunicode`, some people take those flags to introduce some kind of their own type system. Mostly it's DBI, which will send corrupt data to your database if a string value had the wrong flags. There may be others, but DBD::mysql is something I've been burned by.
Now, sometimes you get the string after soaking it in a chain of third-party module calls, and you can't be sure if it's all octets, or it's UTF-8. `eq` returns true on two strings, but on the application-database boundary you get two distinct behaviors.
I know that people have been furious about the bytes/unicode split in Python 3, but trust me, it's the better than Perl's nightmare.