FAQ 1.11 When shouldn"t I program in Perl?

This is an excerpt from the latest version perlfaq1.pod, which
comes with the standard Perl distribution. These postings aim to
reduce the number of repeated questions as well as allow the community
to review and update the answers. The latest version of the complete
perlfaq is at http://faq.perl.org .

------------------------------------------------------------ --------

1.11: When shouldn't I program in Perl?

When your manager forbids it--but do consider replacing them :-).

Actually, one good reason is when you already have an existing
application written in another language that's all done (and done well),
or you have an application language specifically designed for a certain
task (e.g. prolog, make).

For various reasons, Perl is probably not well-suited for real-time
embedded systems, low-level operating systems development work like
device drivers or context-switching code, complex multi-threaded
shared-memory applications, or extremely large applications. You'll
notice that perl is not itself written in Perl.

Perl remains fundamentally a dynamically typed language, not a
statically typed one. You certainly won't be chastised if you don't
trust nuclear-plant or brain-surgery monitoring code to it. And Larry
will sleep easier, too--Wall Street programs not withstanding. :-)



------------------------------------------------------------ --------

The perlfaq-workers, a group of volunteers, maintain the perlfaq. They
are not necessarily experts in every domain where Perl might show up,
so please include as much information as possible and relevant in any
corrections. The perlfaq-workers also don't have access to every
operating system or platform, so please include relevant details for
corrections to examples that do not work on particular platforms.
Working code is greatly appreciated.

If you'd like to help maintain the perlfaq, see the details in
perlfaq.pod.