in reply to Right tool for the job?

Often enough, the right tool is the one you know because you know it. It doesn't much matter whether you use a slide rule or a TI-89 Titanium to solve an arithmetic problem so long as you get the right answer.

Of course, there are problems where the tool does matter (which you are well aware of as evidenced by your assertion that you wouldn't use Perl to write an OS kernel.) But they usually aren't that hard to recognize. In the event that they are, and you use Perl but you get slaughtered on performance, all is not necessarily lost anyway. You might have a good prototype.

The things you listed that you've used Perl for seem to me to be fine uses of Perl, though. Perl is great because it's like a Swiss Army Power Tool. It not only saves you time and effort with the software you write but, it saves you the time and effort of learning those 3000 languages.

If it was Prolog you knew instead of Perl, what would you do in vim? Wait for someone to write prologdo? Ever seen QT bindings for awk? Think you could create an Excel report from data in an MS SQL-Server DB using csh?

I'm sure you get the point.

If you really feel the need to learn another language, by all means, go do it! The broad base of development experience is certainly a good thing. Not so much because it helps to know a bunch of languages, but because you tend to learn different ways of looking at problems. But don't be too concerned about relying on what you know. Depth of development experience can be a good thing too. The more things you use Perl for and the better you get with it, the easier it will be for you to recognize its limitations and know when it really is the wrong tool.¹

[1] Which, of course, is almost never. ;-)

-sauoq
"My two cents aren't worth a dime.";

Replies are listed 'Best First'.
Re^2: Right tool for the job?
by davidrw (Prior) on Sep 25, 2005 at 00:37 UTC
    Often enough, the right tool is the one you know because you know it.
    Unfortunately, there's often other considerations ... think about maintenance -- if for example you're asked to add feature X to a client's IIS/ASP web site, you probably don't want to choose perl (and TT or whatever) (or mysql/postgres vs their existing SQLServer) even though it might be very easy and fast to write, because they won't have any ability to maintain it and it will take a decent amount of installation/configuration to put those tools in place to begin with. (and yes, you spend the whole time cursing vbscript, but it's about the client & solution, not being able to always use the most fun language)

    Ever seen QT bindings for awk? Think you could create an Excel report from data in an MS SQL-Server DB using csh?
    Those are dangerous questions w/this audience -- someone is liable to go do it for fun ;)
[reply]
      Unfortunately, there's often other considerations ...

      Well, yes... which is why I went on to say: "Of course, there are problems where the tool does matter (which you are well aware of as evidenced by your assertion that you wouldn't use Perl to write an OS kernel.) But they usually aren't that hard to recognize."

      I didn't mean to imply that performance was the only other consideration, by the way. Or even that the only considerations are technical. More often than not it comes down to politics and culture.

      -sauoq
"My two cents aren't worth a dime.";
[reply]

In Section Meditations