Your boss got a hold of a case study in which a PERL program has been developed ten times quicker than a program written in a non-scripting language. He now demands that you immediately program entirely in PERL. What do you do?
To quote Jamie Zawinski: "Sometimes a hacker has a problem, and he thinks to himself 'I know, I'll solve it with a regular expression!'. Now he has two problems."
Joking aside (I happen to LOVE regular expressions), the overall message to give any employer in this situation is that no single tool is appropriate for every job; you can't build a house with just a hammer, and you can't (usually) run any software shop writing only in PERL (or any other language for that matter).
Some specific reasons why PERL might not be the right choice for every job fall into two categories.
- There are some issues with scripting languages generally, compared to conventional (compiled) languages:
- Because of the lack of compile-time type checking, there's a whole class of errors you might encounter a run-time that would be prevented in compiled languages - careless programming mistakes like using a string where an int is expected, which might work most of the time (depending on the values and how they're coerced) but then might break in unusal (and hard to reproduce) cases. If what you're doing in your algorithms is subtle or complex at all, this is a class of errors that are worth a great deal of effort to prevent.
- Since scripting languages are interpreted, not compiled, there's a significant decrease in performance. For some things, this isn't particularly important, but for others (system or server programming, graphics, security algorithms, etc) this may be a deal breaker.
- Depending on the scripting language, it can be fairly difficult to achieve certain types of complicated data structures in any kind of reasonably peformant way, because the basic tools don't provide direct memory access in the form of pointers. This is becoming less and less of an issue as the built-in data structure libraries for most languages (including PERL) are getting more robust, but if you're doing programming that requires complex and custom data structures, it may not even be possible in a scripting language.
- There are some issues with PERL specifically that might give you pause before converting your entire organization to use it:
- It has a tendency to be extremely obfuscated. Beyond regular expressions (which I happen to find quite readable, but most do not), there's also a preponderance of *shortcuts* where you can leave out key details of the code because they're implicit. If you're a PERL whiz AND you know what the code is doing, that can make it faster to write, but it does make it slower to read & learn.
- It has many ways to do the same thing, not all of which work with each other; in other words, it's not so great on orthogonality, and things you might expect to work together don't always do so.
