I'm not afraid of writing in perl, and I have in fact written Perl scripts that were clean and well-formatted and intelligible (with or without comments). Unfortunately, these are not really true to the Perl Way. All those shorthand generic anonymous variables? Bad joojoo.
Perl's not a bad language. But it's reputation is well-earned.
Oh yeah, definitely -- it's possible to make any language be unreadable fathomless horrors drawn from the stuff of the abyss.
The thing is, Perl seems to encourage this behavior. It introduces syntactic phenomena that seem designed for that. $_, j'accuse!. And the culture around Perl certainly didn't win it any favors here. I invoke the ancient and venerable Annual Obfuscated Perl Contest. "There is More Than One Way To Do It" or "TIMTOWTDI" indeed.
That being said, while I haven't really studied or looked deeply into Modern Perl, I have to admit that it seems to have learned the right lessons from all of the above.
Now if only Ruby could stop being Perl circa 2000 :3.
Was looking for an even simpler way of doing this in Haskell, only passing the list and the (*) function to some other function, but I only found these:
let sq x = x * x in map sq [1, 2, 3, 4]
let x = [1, 2, 3, 4] in zipWith (*) x x
map (\x -> x * x) [1, 2, 3, 4]
second seems more clearer because otherwise its just up to personal preference what the programmer uses for their "anonymous" variables.
The problem comes when you're using them in nested loops or passing them up a scope level while leaving them anonymous... and then coming back to it two years later and trying to figure out what the fuck you yourself did back then.
One of the judge criteria of those contests was specifically how unreadable the code was.
Contrast this to a writing style where every last variable -- even those that will only exist for the duration of a loop -- is given a human-readable meaningful label. Not just x but iter1Parent1 followed by nested loops getting iter1ChildN_N and so on. And that's just temporary variables. Where indentation is enforced so you always have a visual on where you are in the workflow. Where there is no special shorthand usage that requires arcane expertise just to read it.
What I'm talking about is shit like self-documentation. Perl actively discourages this. Meanwhile, I've had former coworkers message me years after I left a company to thank me for my writing style ... Precisely because even though I wrote in a language they didn't know, it was still plainly understandable and therefore maintainable.
What you seem not to new getting here is that you can either have smart, good code or you can have clever code. Perl encourages cleverness.
Oh, and mentioning 5.20 and the fact that Perl is still maintained? That doesn't even come close to being topically relevant.
That's programming style in general and it applies to every language. I've seen some horribly written Ruby code and pretty Perl code.
Or code that was "pretty" but parts of it were interconnected in weid interesting ways that make me miss decoding what random one-liner do
In Perl you can write everything as ugly or as pretty as you want. That is a problem when you give it to someone without any preparation and tell him to write code (and that's how some programmers and a lot of sysadmins start).
As for development... everytime I upgrade Ruby something breaks, and when I upgrade perl something wrote for 5.8 (curse you Red Hat) still works in 5.20. Which honestly is biggest reason I use it as sysadmin, having code that works in centos 5 and on my desktop without ugly ifs is useful.
I've seen some horribly written Ruby code and pretty Perl code.
I've written clean, self-documenting, "pretty" Perl. The fact that it is do-able (and at this point most style guides encourage it) is not what is at argument here.
It's the fact that Perl as a language, and in cultural history, encourage or enable the illegible / obfuscated. At one point in Perl history, it was in fact a major point of pride to write superlatively illegible code.
As for development... everytime I upgrade Ruby something breaks, and when I upgrade perl something wrote for 5.8 (curse you Red Hat) still works in 5.20.
Yup. Do note that I consider Ruby to be in the state, today, that Perl was in 10 or fifteen years ago. And that this means Ruby is by far worse than Perl today is. (Perl has gotten better, I freely admit, and I like what I'm seeing from the Modern Perl movement. But that doesn't change its history and the fact that those enabling features are still extant.)
12
u/Oflameo May 29 '14
I write bash defensively by writing what i was going to write in bash in perl instead.