On 12/14/2010 4:43 AM, Natxo Asenjo wrote:
>> Python enforces you to be more consistent, which is not a bad thing if
>> you want to understand better what you are doing in the very beginning.
>> Later on Perl, Ruby, C#, Java, C/C++ might be a good alternatives, as
>> they probably are much stronger in a lot of fields for more complex tasks.
>
> use strict;
> use warnings;
>
> if you write Perl and do not use that, you will have problems, yes.
>
>> But remember each tool has its own use case. You don't need a hammer
>> when you have screws. It's the same with programming languages. And
>> Python and Perl are often used as the "Swiss Army Knife". Useful for a
>> lot of ad-hoc and not too heavy routine tasks, but you won't rely on it
>> when going hunting in the wilderness.
>
> well, Perl helps me daily on the wilderness of my job. I do not
> understand the analogy, but it probably is my fault ;-)
Perl is easy to write, starts up relatively quickly, and has a lot of
available modules for specific operations. Since it interpreted as
plain text, you can include a file with the full syntax available for
configuration instead of having to writing your own parser with
yet-another-syntax for config files. But, it is somewhat hard to scale
and maintain because people write in different styles and things that
start small tend to have a lot of global variables that are hard to
remember as the code grows. And perl is not great for GUI programs.
I'd consider backuppc (which contains a nearly complete rsync
implementation) and RT (a trouble-ticket system) to be ambitious
projects for perl.
For larger scale things, look at java. Examples might be OpenNMS,
Hudson, OpenGrok, or Alfresco. These are long-running servers where the
startup time is not a problem and in Hudson's case the cross-platform
compatibility is a big plus because a master program can schedule and
distribute jobs across many different types of machines.
--
Les Mikesell
lesmikesell at gmail.com