|
Re: Why Perl
by moritz (Cardinal) on Feb 01, 2010 at 12:44 UTC
|
Perl is often used where text and strings are processed. It has much more comfortable string processing than C, built-in powerful regular expressions and many other handy features.
That makes it useful for system administrators, web programmers, biologists (DNA is often stored as a large string, after all) and many other people.
Some people who love the language also use it for many other task, because they find some of its unique features very convenient:
- context sensitivity
- In many dynamic languages, the type of operands determines the operation (in javascript "2" + 3 is "23", but 2 + "3" is 5). In Perl + is always addition, and concatenation has a different operator - the symbol determines the operation, not the type
- The Comprehensive Perl Archive Network, CPAN, is a very useful resource with tens of thousands modules
- A language designer who is a linguist rather than a computer scientist
- A very friendly and open community
- Excellent testing tools, and much interesting in Q/A topics in the community
| [reply]
[d/l]
[select] |
|
|
In Perl + is always addition, and concatenation has a different operator
Except when it isn't. Blessed types can overload operators - and then it's the type of the operand(s) that determine what's going to happen.
the symbol determines the operation, not the type
Except when it doesn't. | and & do behave differently depending on their operands - and it's more complicated than whether it's a number or a string; it'll depend on some internal flag. But more important is the context. Some operators behave wildly different in scalar and list context - but they have the same symbol(s).
| [reply]
[d/l]
[select] |
|
|
Except when it isn't. Blessed types can overload operators - and then it's the type of the operand(s) that determine what's going to happen.
That's true. Since Perl is a quite mutable language, you can always shoot yourself and other in the foot with modules.
the symbol determines the operation, not the type
Except when it doesn't.
Sure, there are unfortunate exceptions. As far as I can tell they have been removed in Perl 6.
Perl 6 - links to (nearly) everything that is Perl 6.
| [reply] |
Re: Why Perl
by marto (Cardinal) on Feb 01, 2010 at 12:46 UTC
|
The "Why learn/use Perl" question has come up here several times. I'm sure if you search you will find existing threads/debates. Some light reading to point you in the right direction:
Update: fixed typo /They/The/.
| [reply] |
Re: Why Perl
by rovf (Priest) on Feb 01, 2010 at 12:25 UTC
|
foreach my $X (all_programming_languages()) {
why $X
}
Honestly, I don't think you'll find many languages where you don't have people liking them, or disliking them. I personally enjoy doing my work in Perl, Ruby or zsh, and I dislike COBOL, BASIC and, somewhat, Java; but I'm sure you don't have to look far to find people with a completely different profile of preferences.
Just try it out for yourself. Unless you have a heavy number-crunching application, or something with very tight real-time requirements, Perl will be an option (though, for sure, not the only one).
--
Ronald Fischer <ynnor@mm.st>
| [reply]
[d/l] |
|
|
Unless you have a heavy number-crunching application, or something with very tight real-time requirements, Perl will be an option (though, for sure, not the only one).
But also remember that premature optimization is a mistake. Go ahead and write that number cruncher in Perl, and profile it. Then rewrite problem areas with XS or inline C, if somebody hasn't already done that for you and uploaded it to CPAN, and profile it. Then rewrite problem areas with inline assembly!
It sounds like a lot of work until you compare it with learning a new set of languages (yes, I'm assuming familiarity with C). On the other hand, that isn't a reason not to learn other languages or environments, especially as widely used as Python and MATLAB and R and such. But I prefer doing that when I have the presence of mind to enjoy it, not when I'm under a deadline. That's what brought me to Perl, after all.
| [reply] |
Re: Why Perl
by masak (Scribe) on Feb 01, 2010 at 12:28 UTC
|
An excellent question. I'm sure others will be able to answer more at length, or link to good articles elsewhere that do. I'll try to do it briefly and incompletely here.
Perl 5 has a relatively simple model around which it builds everything else. That means that you can start unravelling it from some end, and the more you learn, the more you'll find that the pieces "fit together".
You'll find that Perl 5 doesn't get in your way when you want to accomplish a task. Want to name a subroutine "42"? That can be arranged. Multiple inheritance? Sure. (But don't do that.) What if you want to make a subroutine that creates (anonymous) subroutines? No problem.
Like all other languages, Perl 5 has idiosyncrasies and pitfalls and dark corners, but all-in-all it compensates well for those by being really flexible. It goes a long way to please you, the programmer.
| [reply] |
Re: Why Perl
by pajout (Curate) on Feb 02, 2010 at 19:29 UTC
|
...and because just Perl has Perlmonks :>) | [reply] |
|
|
| [reply]
[d/l] |
Re: Why Perl
by jdporter (Paladin) on Feb 03, 2010 at 16:26 UTC
|
| [reply] |