You Used Perl to Write WHAT?!

Esther Schindler writes "Developers spend a lot of time telling managers, 'Let me use the tool that's appropriate for the job' (cue the '...everything looks like a nail' meme here). But rarely do we enumerate when a language is the right one for a particular job, and when it's a very, very wrong choice. James Turner, writing for CIO.com, identifies five tasks for which perl is ideally suited, and four that... well, really, shouldn't you choose something else? This is the first article in a series that will examine what each language is good at, and for which tasks it's just plain dumb. Another article is coming RSN about JavaScript, and yet another for PHP... with more promised, should these first articles do well."

Comments

1 Page Version

[The_DoubleU]

http://www.cio.com/article/print/175450

Re:Ray Tracing

[SanityInAnarchy]

Larry Wall doesn't exactly follow his own advice, there... But I digress.

I'm not really sure a raytracer was such a horrible idea.

When looking at a potential application, if it seems to be characterized by a lot of tight loops over intensive calculations, you should probably be looking elsewhere.

If you can isolate those tight loops, there's a good chance you can do just that part in C. High-performance should be possible.

It's the real-time response that would be difficult. I wouldn't have a problem writing a 3D raytracer (intended for a renderfarm, say) in Perl, but I might not want to do a 3D game.

The article also recommends both using Perl as a replacement for shell scripts, and, well, not using it as a replacement for shell scripts. The logic given is that you shouldn't call out to the shell, and use the native functions -- but that would suggest that you're using it as even more of a replacement for shell scripts. Ah, well, at least I don't actually disagree with the article, although occasionally, it just makes more sense to, say, call the 'find' command than re-implement it in Perl.

Then it gets into really WTF territory:

However, I would argue that more modern Web scripting languages, such as PHP and Ruby on Rails, offer more out-of-the-box Web support and a cleaner integration into the webpage experience. You should especially avoid using perl for traditional CGI-style form processing; this code tends to be hard to read and maintain because the HTML ends up inlined inside the perl code.

Wait, you're recommending PHP, a language invented out of the need to inline server-side code in HTML, and then you complain about Perl having HTML inlined in it?

I mean, yes, it's a bad pattern, but frankly, PHP is "more modern" in the sense that Vista is "more modern", and Perl has plenty of out-of-the-box Web support. I might still use something like Rails, or stranger things like Seaside, but never PHP.

Also: You recommend Perl for database manipulation. Rails was invented out of the idea that most web apps are really just trying to put a database on the web. And PHP has been notorious for SQL injections, if undeservedly.

Still, you have hit on the one unambiguous point: Unless you're participating in an Obfuscated Perl Contest, don't write ugly, unreadable code, in any language.

Re:Bollocks

[VGPowerlord]

it isn't supposed to be used in CGI. Eh. Right.

I can think of a combination of three factors to support this assertion:

1. CGI.pm is a memory hog, so you really need some sort of acceleration.
   
2. mod_perl breaks if you look at it funny.
   
3. Any other way of speeding it up locks you into using that particular method, as you end up rewriting your scripts to use it. See: FastCGI or SpeedyCGI.

For all the things PHP does wrong, these are things that it has done right.

Not following...

[SatanicPuppy]

So it's a virtue to be programming in a half a dozen different languages? Or to force an accomplished programmer to switch to a different language for no good reason? Sure, he should be able to pick it up, but there is a learning curve, and lingering inefficiency issues that will last for a while.

I recently had a throwdown regarding this because one of my coworkers was working on a project, and I flat refused to help him in his chosen language. That language? VB6.

Now I used to program in that...thing...and when .Net came out, I purged it from my memory banks. I am not going back, not for anything. Does that make me weak, to refuse to dive back into an obsolete language in order to generate a new application?

It's one thing to be flexible and open to new ideas, and dedicated to improving your skillset, but it's entirely different to be running around programming in random different languages for no compelling reason. One of the negatives in TFA was that if you used perl to sub for a shell script, you'd take an efficiency hit...This after he said you should never use it at all where efficiency was an issue because it's interpreted! The reason to use perl instead of a shell script is because perl will work in any shell...If you need performance you shouldn't be using it anyway.

In short, using a different tool for every job is only useful if it's not more efficient in the long run to do the job with the tool at hand. If I need to tighten a bolt, I could go to the hardware store and get a socket set that will fit that bolt, or I could use the crescent wrench that's sitting 5 feet away. The sockets would do the job a hell of a lot faster...But it would take longer to get them than it would to just use the wrench.

Real World Counter Example

[localman]

Sure, Perl is pretty much on everyone's shit list these days. But as the Director of Development for Zappos.com from 2000 through 2006, I have to take exception with his claim that perl is unacceptable for high-performance applications. Of course it depends what type of high performance applications you're talking about, but for high performance web applications it's actually quite good.

Specifically, the Zappos site, built with Perl, was rated the fastest retail website in the world for broadband customers for much of 2006. It beat out Amazon, Dell, Best Buy, etc, etc, you name it. It was also the most consistent speed and the fewest errors. Search Internet Retailer for the more numbers. It always places in the top 5.

Also, the claim that one might mix HTML in scripts is a sign that this guy hasn't actually used Perl in the past decade. Everyone switched to powerful templating systems sometime in 98. There are several very nice web development frameworks for Perl these days. Just like almost any other language.

The rest of his criticisms are more valid. I wouldn't try writing graphic intensive applications, or anything with heavy math processing in Perl. And the most common complaint, that it doesn't prevent you from writing messy code, is certainly true. Of course, just because your code looks neat doesn't mean it's good code either :)

Cheers.