> "don't use perl, it promotes brain rot"
> and no, i wont revisit my thinking.
Really?
like another commenter said it's a discussion i've had before and haven't heard compelling arguments in favor of perl, so no i'm not interested in revisiting it.
that said it IS context dependent. i wont fire you for writing perl one-offs to maintain some systems or process some files. but i would argue against you for wanting to ship perl for the reasons i stated, with my main thesis being that your decision would jeopardize the project's future (assuming it had some future). i've heard the arguments before, like "you can write clean and maintainable perl" (which has analogues with "high performance java" and "long-term maintainable PHP"). the counterpoint is "sure, one can. but people rarely do. other tools promote those features more readily. pick one of them."
first, that some languages promote decent coding practices, while some actively encourage bad ones, either through crappy idioms, bad docs and a lousy community, or a lack of immediate penalties.
second, that where you spend much of your time coding has a significant effect on how you think about problem solving, consequences, etc. the practice of programming builds behaviors, modes of thinking, and values.
finally, if it isn't clear, i consider perl's features to be substandard to long term coding. the values it places on hacked up gimmicks (under the guise of "more than one way to do things" and "see! it's a one liner!") is a large part of this.
therefore "brain rot" in this case isn't equivalent to years of meth use, but rather a failure to appreciate crap designs, a failure to perform sound engineering when you write code, and a failure to think about the future of your code. i've seen the products of people who write code professionally, with them having learned through years of coding perl, and it is not pretty. lots of them.
keep calling me closed minded on the topic, i wont disagree. but the end result is that when someone tells me that perl is their language of choice and i'm hiring for a person to write code, it's a deep hole they have to get out of right away or i won't hire them, nor will many of the people i work with.
> the values it places on hacked up gimmicks (under the
> guise of "more than one way to do things" and "see!
> it's a one liner!") is a large part of this.
> when someone tells me that perl is their language of choice
> [...] i won't hire them
A good example is http://www.nntp.perl.org/group/perl.beginners/2009/01/msg106... that i just found googling for perl one liners. The OP want's to know what this line does, the first answer is "you can make it even shorter!". Somewhat explains what i try to say ;)
Surely there is a lot of clean perl code out there but from my experience at customers (i'm consultant) what happens in-house in some development departments looks very very very different. Then again i've seen a lot broken, half-tested and unmaintained CPAN modules as well.
And it's not restricted to Perl: http://news.ycombinator.com/item?id=4906370
> Then again i've seen a lot broken, half-tested and unmaintained CPAN modules as well.
You also get this in PyPi, Gems, NPM, etc. Just more proof that Sturgeon's Law exists.
If you catch me using a butcher knife to get the cork out of a wine bottle, feel free to call me a fool. That shouldn't reflect badly on the makers of knives or corkscrews or wine bottles.
i've seen the products of people who write code professionally, with them having learned through years of coding perl, and it is not pretty. lots of them.
I've read a lot of code from people who've never learned a whit about programming. The lesson I take from that experience is that some languages make it easy for people who aren't interested in programming to get things done without having to learn much about programming or design or maintenance or coding standards.
That said, warnings and strictures should have been the language's default behavior for programs, not one-liners.
> it's easy (easier than many languages) to slip into
> writing bad Perl
Why is this a bad idea? Do you also object to Perl Critic? Or say having a policy of using Perl Critic?
Also, I don't see anyone claiming that Python will 'rot your brain' because PEP-8 isn't enforced by the language.
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.)
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.
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).
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.
By this argument, Javascript (JSLint), C# (StyleCop), C (lint), Python (Pychecker and Pylint) all have failings.
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.