7 ms·

i'll wade in. note that i'm bigoted against perl, i'll say so clearly up front. perl is better than shell scripting at automation, this much is true. perl has

i'll wade in. note that i'm bigoted against perl, i'll say so clearly up front. perl is better than shell scripting at automation, this much is true. perl has a strong use case there. had, i'll argue. perl's idioms and structure promotes wonky, hard to read and hard to maintain code. it's true. get even the most die hard perl fan a beer or two and they'll wind up admitting it, sheepishly and quietly. but yeah, perl too easily promotes a mess. and when you have to maintain code, borrow code, etc .. readable code matters. my biggest complaints about perl usually fall into the bucket that perl fans claim are its strengths. brevity, wit, etc. those wind up confusing almost all perl developers and users, in my experience, because you have to shift gears mentally to figure out wtf a piece of code is doing, what the developer intended it to do, and thus diagnosis is a pain. too many perl users just laugh and say, "yeah, i can't figure it out either." funny until you realize they're laughing about wasting your time. my second biggest complaint falls into the reusability of perl by its design. not so modular without some surgery (minor or major, depending). the C (or ruby or python) code that people trained on perl develop is, almost always, horridly inefficient. CPAN is nice, i wish my language of choice (python) had as extensive a library so easy to use. and then you get into the mess of CPAN, which is littered with half completed, poorly documented modules. you wind up having two or three modules that do the same thing but are dependencies elsewhere or actually implement some promised functionality, etc. (cheeseshop, pip, etc yes ... but so much stuff isn't deployable like that is my point...) the perl documentation library was a big selling point about 10 or 12 years ago, not so much now. everyone else caught up is my point. python, ruby, etc are now mainstream. the "perl is everywhere" mantra used to be compelling, too. but python and ruby are just as widely available on systems and ... far more suited to long term development and maintenance than perl is. again, "better" languages for long term use and development are now mainstream. they weren't before. i tend to sum all this up for someone with "perl sucks" or "don't use perl, it promotes brain rot". and no, i wont revisit my thinking. perl had its day, but i think the sun has set and rightfully so.

pyre 14y ago
> "don't use perl, it promotes brain rot" > and no, i wont revisit my thinking. "I don't think this is the tool for the job, THEREFORE IT ROTS YOUR BRAIN! If you try to talk to me about that, I will chant, "I'M NOT LISTENING" over and over with my hands on my ears." Really?
- new299 14y ago
  I think the argument might be that it's easy (easier than many languages) to slip into writing bad Perl, which promotes brain rot, it also sounds like it's a discussion he's had many times before... and perhaps isn't too interested in having again.
  - pyre 14y ago
    > it's easy (easier than many languages) to slip into > writing bad Perl Bad programmers will write bad code no matter the language. I don't like this idea that the language can somehow force people to write better code, or that it should.
    - new299 14y ago
      > I don't like this idea that the language can somehow force people to write better code Why is this a bad idea? Do you also object to Perl Critic? Or say having a policy of using Perl Critic?
      - pyre 14y ago
        Usage of Perl Critic and claiming that Perl 'rots your brain' are miles apart. Also, I don't see anyone claiming that Python will 'rot your brain' because PEP-8 isn't enforced by the language.
    - berntb 14y ago
      You're arguing with a Karma 30 account. It took some time before the trolls woke up in this thread. (I'd love to get access to the HN logs and check IPs, to see if the trolls where sloppy with using alternative access and can be identified.)
    - buster 14y ago
      See it that way: A bad programmer that can use such a variety of difficult to read symbols in a language (which perl clearly has) will just use all of them and the result will be horrible to read and understand. Also, often times python really has one obivous way to do a specific thing. Last time i was googling for some perl code (i think it was for some array handling) i have found at least 10 equally good totally different way on perlmonks in one thread. That's not bad per se but it promotes that every one uses another line of code and the bad ones choose the lines that may have unintended side effects but work in 90% of the usecases.
new299 14y ago
Yea, I kind of agree with some of this. My coworkers are big fans of Perl Critic because it enforces a standard (and I assume one that promotes cleaner Perl). But it often seem to me that the popularity for Critic is somewhat of a language failing. I guess the argument could be main that it allows you to write hacky little scripts which could can then apply Critic too and slowly refactor into large projects. I'm not entirely sure I buy it.
- prakashk 14y ago
  the popularity for Critic is somewhat of a language failing By this argument, Javascript (JSLint), C# (StyleCop), C (lint), Python (Pychecker and Pylint) all have failings.
  - buster 14y ago
    No, whereas pylint promotes a good style, same space between function definitions, etc. this is something that is heavily missing in perl. Python also doesn't have (or actually it's almost never used) global variables and goto and all that crap that people still use in perl code. On of the first things i do when having to work on others perl code is to run Critic and first fix the myriad of warnings that come up. With Pylint it's typically just some minor stuff. With Critic it's typically some major stuff that's plainly wrong.
cygx 14y ago
Using Perl will not rot your brain any more than any other programming language - balance is key: Look at other languages and don't become a one-trick pony. If you look at the popular scripting languages (Perl, Python, PHP, Ruby, Javascript), Perl is the only one that gets freaking variable declaration right, so I'd be pretty careful when casting stones.
harbud 14y ago
I agree on several of your points. CPAN is kind of meh right now, since Python/Ruby/node.js are quickly catching up (or have passed it, even). You can quite easily find libraries existing in other languages and not in CPAN. For me it now boils down to: sunk cost (if you're already familiar with Perl, it makes sense to keep doing it in Perl) and some features that Perl currently really excels at (variable scoping, regex integration, Unicode).
buster 14y ago
Exactly my feelings. Usually when i bring this up on HN it's just a heavy downvote and i gave up with it.. I must really say that the most horrifying times in my current job over the last years have not been critical situations like server failures or the like but the countless hours i spent on debugging and "cleaning up" the perl scripts of other people. Since then i made clear that i don't touch those anymore, someone else can waste their time. Especially when you spent more on fixing some script then it would take you to rewrite it in python..

pyre 14y ago

> "don't use perl, it promotes brain rot" > and no, i wont revisit my thinking. "I don't think this is the tool for the job, THEREFORE IT ROTS YOUR BRAIN! If you try to talk to me about that, I will chant, "I'M NOT LISTENING" over and over with my hands on my ears." Really?

new299 14y ago
I think the argument might be that it's easy (easier than many languages) to slip into writing bad Perl, which promotes brain rot, it also sounds like it's a discussion he's had many times before... and perhaps isn't too interested in having again.
- pyre 14y ago
  > it's easy (easier than many languages) to slip into > writing bad Perl Bad programmers will write bad code no matter the language. I don't like this idea that the language can somehow force people to write better code, or that it should.
  - new299 14y ago
    > I don't like this idea that the language can somehow force people to write better code Why is this a bad idea? Do you also object to Perl Critic? Or say having a policy of using Perl Critic?
    - pyre 14y ago
      Usage of Perl Critic and claiming that Perl 'rots your brain' are miles apart. Also, I don't see anyone claiming that Python will 'rot your brain' because PEP-8 isn't enforced by the language.
  - berntb 14y ago
    You're arguing with a Karma 30 account. It took some time before the trolls woke up in this thread. (I'd love to get access to the HN logs and check IPs, to see if the trolls where sloppy with using alternative access and can be identified.)
  - buster 14y ago
    See it that way: A bad programmer that can use such a variety of difficult to read symbols in a language (which perl clearly has) will just use all of them and the result will be horrible to read and understand. Also, often times python really has one obivous way to do a specific thing. Last time i was googling for some perl code (i think it was for some array handling) i have found at least 10 equally good totally different way on perlmonks in one thread. That's not bad per se but it promotes that every one uses another line of code and the bad ones choose the lines that may have unintended side effects but work in 90% of the usecases.

new299 14y ago

Yea, I kind of agree with some of this. My coworkers are big fans of Perl Critic because it enforces a standard (and I assume one that promotes cleaner Perl). But it often seem to me that the popularity for Critic is somewhat of a language failing. I guess the argument could be main that it allows you to write hacky little scripts which could can then apply Critic too and slowly refactor into large projects. I'm not entirely sure I buy it.

prakashk 14y ago
the popularity for Critic is somewhat of a language failing By this argument, Javascript (JSLint), C# (StyleCop), C (lint), Python (Pychecker and Pylint) all have failings.
- buster 14y ago
  No, whereas pylint promotes a good style, same space between function definitions, etc. this is something that is heavily missing in perl. Python also doesn't have (or actually it's almost never used) global variables and goto and all that crap that people still use in perl code. On of the first things i do when having to work on others perl code is to run Critic and first fix the myriad of warnings that come up. With Pylint it's typically just some minor stuff. With Critic it's typically some major stuff that's plainly wrong.

cygx 14y ago

Using Perl will not rot your brain any more than any other programming language - balance is key: Look at other languages and don't become a one-trick pony. If you look at the popular scripting languages (Perl, Python, PHP, Ruby, Javascript), Perl is the only one that gets freaking variable declaration right, so I'd be pretty careful when casting stones.

harbud 14y ago

I agree on several of your points. CPAN is kind of meh right now, since Python/Ruby/node.js are quickly catching up (or have passed it, even). You can quite easily find libraries existing in other languages and not in CPAN. For me it now boils down to: sunk cost (if you're already familiar with Perl, it makes sense to keep doing it in Perl) and some features that Perl currently really excels at (variable scoping, regex integration, Unicode).

buster 14y ago

Exactly my feelings. Usually when i bring this up on HN it's just a heavy downvote and i gave up with it.. I must really say that the most horrifying times in my current job over the last years have not been critical situations like server failures or the like but the countless hours i spent on debugging and "cleaning up" the perl scripts of other people. Since then i made clear that i don't touch those anymore, someone else can waste their time. Especially when you spent more on fixing some script then it would take you to rewrite it in python..