Re: perl's forte

Perl can do CGIs, even though PHP is simpler.

Perl can do OOP, even though Python and Ruby are cleaner.

Perl can do text processing, even though sed/awk/yacc/grep are more specific to the task.

Perl can process XML, even though XSLT is (arguably) superior.

But none of these languages can do all these things reasonably well. This is what people sometimes miss when they say "Use the best tool for the job!" (and why I tend to avoid that phrase). If your task is simple, then you can get away with using a very specific tool for your task. In anything bigger, you're going to need to do a wide range of tasks. While you can break your complex task into several simple ones, you still need some way to glue together each part. For the purposes of getting real work done, you often need to pick just one tool, because trying to put many domain-specific tools together isn't worth the effort. You're often better off picking a tool which can do it all reasonably well rather than twenty tools that do very specific tasks.

There's a reason why Perl is called the Swiss Army Chainsaw.

Update: Speeling mistake. Thanks tilly.

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated

Comment on Re: perl's forte Download Code

Replies are listed 'Best First'.
Re: Re: perl's forte by etcshadow (Priest) on Mar 19, 2004 at 17:35 UTC
Another argument against "do the right tool for the right job" (I know that you're not so likely to hear arguments against that here... but hear me out) is this: If you have one tool that works reasonably well for every job (maybe not the best tool for each individual job, in a vacuum), then you can invest yourself in really learning that tool inside out and very well. I may do things with perl that would be better done with sed or with a c program or who knows what... but they take less overall time in perl because I do so much else in perl every day. It's practiced and trained, I can rattle it off like nobody's business. This is also why (if anyone pays attentsion to such things) I talk a lot, in my posts, about the line between perl scripting and shell scripting, perl "one-liners" and so on. Because, by the same token, I am needs-be using shell all the time, and perl one-liners interface incredibly well with shell scripting. I'm getting off topic here, but ever find yourselves doing stuff like: `something \| perl -pe ... \| sort \| perl -pe ... \| wc` [download] or some crazy pipeline that flows in and out of perl one-liners and through other things that perl could do? Hell, perl can sort. Perl can count the number of lines read... why am I using shell for this? It's because if you're alread thinking in one language, use that language, even if it is not the best tool. The mind-set shift between the tool you're already using and the "best tool" is not worth the advantage that the better tool gives you. Anyway... what that's all about is the fact that perl, by being so versatile, is a reasonable tool for pretty much any job... and that's often more useful than the very best tools for each of ten different jobs. `------------ :Wq Not an editor command: Wq` [download]	[reply] [d/l] [select]
Re^2: perl's forte by Aristotle (Chancellor) on Mar 20, 2004 at 07:41 UTC
This sounds like a copy+paste from a textbook. Have you actually done any work with XSLT? Have you actually written dynamic webpages in PHP or written OO code in Python or Ruby? How much text processing have you done with awk/sed/etc? Of all the things you mention, the one I have no experience with is Python. Of all the other claims, the only one I can confirm is that Ruby OO is cleaner. I strongly disagree on all other points. XSLT is a gigantic pain to work with, for a large variety of reasons from the mundane to the esoteric. Given the choice and an XPath capable XML module, I'd use Perl over XSLT every time without fail. For text processing… well I don't know how you can write what you did, because Perl was invented because these tools were too limited to begin with. Note that I'm not sure what yacc is doing in that list, because it has a very different focus than the other tools (they're all about processing text in the furthest possible sense, I guess). I've written tons of trivial and non-trivial sed scripts, and while my awk exposure has been limited, I have written a handful of non-trivial scripts, enough that I think I have a feel for the language. None of these tools is very useful for anything more than pretty simple tasks. As far as PHP is concerned, it really should be likened to the Template Toolkit rather than the whole of Perl. Give me Perl, any day of the week. Just about the only thing that I can think of where Perl is a bad choice is raw, unadulterated number crunching. PDL helps, but really that's the domain of C. For any kind of data munging task — not just pure text processing, but really anything that involves combining or extracting data somehow, whether that be XML, database work, or whatever you can dream of —, no competitor comes close to Perl. Makeshifts last the longest.	[reply]
Re^3: perl's forte by etj (Priest) on Jun 23, 2022 at 15:52 UTC
Just about the only thing that I can think of where Perl is a bad choice is raw, unadulterated number crunching. PDL helps, but really that's the domain of C. Only if you really, really like explicit for-loops, memory-management, and POSIX threading. If you don't, PDL is vastly superior.	[reply]
Re: Re^2: perl's forte by hardburn (Abbot) on Mar 21, 2004 at 02:55 UTC
Have you actually done any work with XSLT? Nope, but see this Kuro5hin.org article on XSLT, which is the reason I don't bother at all. Have you actually written dynamic webpages in PHP . . . Yes, I keep knocking my head against it's limitations. . . . or written OO code in Python or Ruby? Yes. They're both cleaner than Perl OO. How much text processing have you done with awk/sed/etc? Hardly bother to use them, since Perl does what I want. Note that I was very careful with the wording of each of those statements. PHP is simpler than Perl. Python/Ruby OO is cleaner. Sed/awk/grep/etc. are more specific to text processing. And XSLT is arguably superior (though I wouldn't make that argument myself, clearly somebody thinks it's better (even if they're PHBs) or it wouldn't exist). These are very specific statements of overall "goodness". What I didn't say was that they were all absolutely superior. Particularly in PHP's case. It is simplier, and that's preciely why I don't like it. Update: Speeling mistake. Thanks tilly. ---- `: () { :\|:& };:` Note: All code is untested, unless otherwise stated	[reply] [d/l]