Ok, first of all, this is one of the dumbest "news" stories I've seen here in a while. It's really lame.
Secondly, he had to write python for this stupidity? From any bash shell:
while (true); do cat
I think I actually lost intelligence by reading and spending 30 seconds thinking about how dumb this whole thing is.
I agree that it's possible to write maintainable perl, but from my vantage point, perl is not really designed for this.
To me it's more of a hack n` slash language. Code while you think. All those shortcuts and lack of boilerplate code and ability to just say "take this data, compare it with this, and do whatever" in a few lines is to me perl's strength. The fact that the resultant code is hard to read is the weakness. If you are not going to do that, and write code in a more rigid, designed manner to avoid this, why use perl in the first place?
The argument that it's not the tools it's the developer stands, however I do think some tools are more oriented towards maintainability (java, c++) and others towards rapid development (perl). You get ugly code in every language, but perl almost directly encourages it. The CPAN tool is _the_ definition of perl. Works, but oh my god is this code or cyphertext!
I think I see the problem here. It's a perception problem. You've decided that you want Perl to be a "hack n slash" language, so you view it in that way, and only in that way. I think you're seriously shortchanging Perl and pigeonholing it to something that doesn't match reality.
"Why use Perl" if you're not going to write sloppy code? Because there's a huge number of things that Perl can do really well. For example, using Mojolicious, it can be a great tool for designing web applications. Using CPAN, it can do any number of things. Using Moose, it has Object Oriented capabilities that rival any other language available. It's fast, it's flexible, and it processes text better than anything else.
Also, I'd really like to see some evidence of your "perl almost directly encourages [ugly code]". No offense, but I think that's a bunch of crap. It perpetuates a stereotype that isn't based on fact, but prejudice. Take 10-20 minutes and do a little research on Perl. Not Perl as you think it is (based on outdated assumptions and incorrect information), but as it really is. Look at the Modern Perl movement, the push to get past the misinformation about ancient Perl, and the awesome new world of Perl.
It's a much different world than you seem to see. And, for the record, having written C++ and Java professionally in the past, I'd much rather maintain Perl code than either of those.
Yes you can write maintainable code in perl if you make a specific effort to do so, but to me that defeats the point. It's primarily a hack and slash language that lets you crank out code while you think. To me writing maintainable perl is like writing a quick one-off script in c++ or java. Yes you can do it, but why bother. Use the tool that is suited for the task.
Have you actually written Perl?
I mean, no offense, but that's just silly. Maintainable code requires a specific effort in Perl? But it doesn't in other languages? Can you provide anything to back that up? I can add use strict; use warnings to my perl and still have less boilerplate code than an equivalent Java (or C++, or even Python) program.
Writing maintainable code, in any language requires some effort. Period. Perl makes it no more difficult than any other language, and offers more assistance than most (see warnings/strict/perlcritic/etc).
As for it defeating the purpose. . . well, I'd ask for evidence, but I'm really not convinced you understand Perl to an extent that you could provide a decent answer. Maybe I'll ask the two co-workers who are maintaining a 6 year old, 60k line perl application at work, see what they think. See if they think Perl is "suited for the task". Last time I talked to them, they seemed to be thoroughly enjoying it, though.
Agreed. Cookwise is a *great* book. And for those looking for a little more "geek cred" for her, Shirly Corriher has guested on half a dozen episodes of Good Eats, particularly earlier ones. Fans of Good Eats will appreciate her book, as will anyone who wants a better understanding about cooking.
(1) Never draw what you can copy. (2) Never copy what you can trace. (3) Never trace what you can cut out and paste down.