The fact that there is no type checking, the sometimes cryptic syntax, and the unusual object oriented features seems to be hindering our development.
What does "our development" refer to here? Your personal development as capable and flexible programmers? The actual development cycle of applications? Something else? What are some particular symptoms, events, or hassles that make it seem like perl is a hindrence?
If you haven't coded in other languages (or if you've been doing perl so long that you've forgotten what it's like), then I would ask you to consider whether things that seem to be a hindrence could just be misconceptions. For example:
How big a problem is it that there is no type checking? When I look at C and C++ (where there are no sigils), I find people having a lot more trouble with designing, writing and maintaining code (and I have more trouble reading their code) just because of the way variables are bound instrinsically to specific arrangements of memory storage (and a variable name gives no explicit clue as to the nature of its storage, unless the programmer is using a compulsive coding style that flags types in the variable names, but often this makes the code even harder to read). Last time I checked, it is still possible to compile and run C or C++ code that will crash nastily, because programmers can (and do) still coerce pointer types, or they just don't anticipate the variety of data people will throw at it. Meanwhile, in Perl you need to know the difference between a hash, an array, and a scalar, and for scalars, you need to recognize when it's a reference. That's all, and it's easy.
How bad is it that Perl's OO features are optional, and require some extra syntax to set up, involving a few strange bits of syntax? (I'll confess, the first time I saw "bless" in a perl script, I felt is was a joke of questionable taste.) Frankly, I don't believe that every piece of code needs to be An Instance of A Class or Object. Lot's of software requirements just don't lend themselves easily to that sort of abstraction, or at least can function quite well without it, thank you. My impression is that the mandatory OO framework of C++ and Java doesn't mean that less code is required to implement OO, or that the code is sure to be a better implementation -- rather, it just means that the extra baggage required for OO has to be part of every program. (Python suffers somewhat less from this problem, because it has managed to boil down the OO syntax to a bare minimum -- but then, some people have other complaints about how Python code is supposed to be written.)
halley's initial reply presents the most important truths about language selection -- the things that Really Matter. If those issues don't apply to the applications you're working on, and you still think Perl isn't the best choice, why not go ahead and try some other choice, just on your own, and see if that's a better way, all things considered?
In reply to Re: When to use perl
by graff
in thread When to use perl
by bobdeath
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |