In CIO, James Turner writes "You Used Perl to Write WHAT?!", which has the tag line "Every programming language has its strengths...and its weaknesses. We[sic] identify five tasks for which perl is ideally suited, and four that...well, really, shouldn't you choose something else?". He misses the point though, especially for the audience who reads CIO.
He lists five uses for Perl:
- Pattern matching
- In-place editing
- A replacement for shell scripts
- As a database manipulation tool
- As a cross platform language
Those aren't uses though. They are just features, and they aren't especially interesting features. Most languages can handle that stuff. Pattern matching? Sure, that was sexy back in 1991, but everyone does that now. No CIO sits down with his staff and says "Hey, let's do something with pattern matching! Any ideas?", just like a home contractor doesn't think "I'm going to do something with hammers, but what should it be?"
James says in the first paragraph "And while perl[sic] is certainly a versatile tool, it isn't the right tool for every job." Um, not kidding sherlock. No language is the right tool for every job. However, evaluating languages starts with knowing what the task is, and the important things aren't the basic language features. James, however, doesn't bother with the real problems; he just wants to deal with fads and hype. He prefers the convenient misinformation to the educated decision.
CIOs are interested in how much it is going to cost, which resources it demands, how long it takes, how it fits into existing internal technology, and if it can be done in a way that meets the organizations' needs. Programming languages solve none of these problems. Whenever I leave
Programming Perl in a room by itself with a computer (I even spring for the fancy Macs), I always notice that Perl never writes a line of code. I tried it once with
The Ruby Way, and it didn't write any code either. Maybe the janitors erased everything those languages wrote on the white board, but neither language admitted to doing any work when I asked them what they accomplished. In fact, they ignored me.
People solve problems, not computer languages. Languages are just means of expressing ideas, and most ideas can be expressed equally well in many languages. I happen to really like expressing myself in Perl and working with other Perl people, but that has nothing to do with technology or the right tool. I could solve the same problems in Ruby or Python. They are just languages. This isn't some video game where you have to collect the exactly right magic amulets to kill the boss creature.
Here's when you use a particular language:
- You have an experienced team using that language already
- The other bits of the problem, such as web servers and databases, integrate with the language
- Most of the problem is already done for you in libraries or modules
- When it's going to save money and time compared to your current solution
Here's when you don't use a particular language:
- No one in the organization knows anything about it
- You first heard about the language in a magazine
- Someone is trying to sell you something
- You have to buy new or special hardware to use it
- The person trying to convince you can't give you three good reasons not to use what they think you should use
Can you use Perl to get the job done? I think that is almost always "Yes". I've seen a lot of efficient, scalable, high traffic systems written in Perl with millions of dollars running through them. Should you use Perl? I don't know. You're the only one who can answer that and don't let anyone else tell you otherwise, even if they do write a magazine article.
Write good code.
stu42j on 2008-01-25T19:36:57
The section on When Not to Use Perl reminds me of my favorite Larry Wall quote: "The trick is to use Perl's strengths rather than its weaknesses."
Other than the first one, his arguments boil down to:
2) Don't call external shell function when internal libraries are faster.
3) Don't mix code with HTML.
4) Don't write obfuscated code.
Well, Duh! Sounds like good advice in any language.
Re:Write good code.
phaylon on 2008-01-25T19:57:59
Well, he hasn't even _touched_ real requirements for big projects. And why would he? If it comes to libraries, stability, deployment, toolchains, etc. there's not much difference between the languages, and CPAN is and always was a big win for Perl.
He absolutely disqualified himself with this part:
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.
(Highlights are mine)
So, we shouldn't use Perl for the web because it doesn't do it. But we should use Ruby for it because it doesn't do it but has a framework, which Perl has many of, just like Ruby.
Millions?
Alias on 2008-01-27T06:46:48
For the record, our Perl app at work does a billion (australian) dollars a year.
And we're only in a small country, so I can only assume there's places doing billions of dollars a year, not millions.
Re:Millions?
brian_d_foy on 2008-01-27T13:50:38
Ah, I should have put a time scale on it. I was thinking on the scale of a day. One application I saw had the metric that every hour of down time was a lose of a couple million dollars.
File::Copy?
sciurius on 2008-01-27T17:42:43
2) Don't call external shell function when internal libraries are faster.
Apparently, he hasn't heard Abigail's talk on File::Copy.
Re:File::Copy?
stu42j on 2008-01-28T16:23:43
I haven't either. I just read the slides but missed the point. Can you summarize?
Re:File::Copy?
stu42j on 2008-01-28T16:44:12
Never mind, I found a video: http://videos.grango.org/2007/2007-yapcna-lt-abigail-filecopy.mpg
Re:File::Copy?
runrig on 2008-01-28T17:40:37
"Don't call external shell function when internal libraries are faster." Apparently, he hasn't heard Abigail's talk on File::Copy.
In the case of copying files on Unix, the external shell function is faster. And more flexible. I usually only use File::Copy when I need to copy to/from filehandles.
Re:File::Copy?
runrig on 2008-01-28T22:13:26
Apparently you (nor I until now) had read the article either. He actually has an example of using perl to copy files using a system call versus using File::Copy, and favors the File::Copy version (though in the system() version, he also uses system('ls') to get a list of the files). (Nit: the two versions don't do the same thing...the File::Copy version filters by extension).
Re:File::Copy?
sciurius on 2008-01-28T22:26:14
It's the preference to File::Copy that triggered my reaction. File::Copy is very limited, at the edge of being harmful. That is what Abigail points out in his talk.
Re:File::Copy?
runrig on 2008-01-28T22:41:25
Sorry, for some reason I was temporarily completely missing your point...got it now :-)
