While it depends greatly on the task at hand, some reasons I
have not used ksh or bash for development are (in no particular
order):
- If you have a situation requiring lots of operations where
the shell would fork a simple program (e.g. date, rm, ln) and
where perl would do it directly, the fork overhead may be very
high.
- Perl code can be easier to maintain. Some shell-only
programmers may disagree, but I tend to forget why I did
certian "tricks" in shell scripts. But I can generally figure
out my old perl scripts.
- Perl has better support for functions.
- CPAN
- Perl expressions are generally easier to follow than calls to
expr/sed/grep.
- It is probably easier to find new good Perl programmers to add
to a team than to find new good ksh programmers.
I am in the process of converting most of my non-trivial
shell scripts to perl. I recently tried to explain two large
scripts, one perl one shell, to a group of inexperienced
programmers. They could follow the perl, but not the shell,
and the shell was much simpler code, honestly. The issue in
that case was that the shell required verboseness and tricks
that were not necessary in perl.
HTH, --traveler
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.
|