Every once in a while I read a flame war because of a thread like this, and It's becomming hard to follow.

In general, there is one rule of thumb - if you like it, you're probably going to use it.

At the bottom line, my opinion is that the forte is with the programmer's ability to understand the language, and use it well. If Perl's freedom gets to you, making you write sloppy code, maybe you should switch to Java. If you think C is too tedious for getting a job done, Perl sounds like the way to go. There are countless arguments such as these two, and all are legitimate.

My two cents is that you should just try the language, and see what it does to you. Perl is very nice in that it keeps many surprises hidden for you, and you grow into it. I prefer it for nearly any task and scenario. But this is because I find that it is the least limiting and time consuming for my style, and what I've had to do so far.

I don't think you'll have an easier time making up your mind about it by asking.

Update: . o O ( Why is the root node being downvoted? I think it's a perfectly legimate question. It's just that we get it often. If that's the reason, maybe you should point kiat to the Super Search page, or even to actual nodes. )

Thanks, nothingmuch!

I've been pretty much puzzled why I get downvoted for genuinely wanting to seek views on something that I'm interested in or for asking questions that appear silly to some but are stumbling blocks to me.

If everybody knows perl equally, this site will become redundant. So when I get downvoted for asking a question on perl, I wonder why.

I think it would be really illuminating to the author of a node if people who downvote it can let on why they judge the node as deserving a --. I mean if you bother to downvote, you certainly can afford the energy to critique, can't you?

On that note, I thank you once again for sharing your views and for bringing the subject of downvoting up :)

You really can't figure out why people would downvote your node? You basically said that you think perl is unpopular for web development and slow. No, not in so many words, but that is the implication, and of course a statement like that is going to annoy some people on a site for perl users.

If you honestly just wanted to know what people think perl is best at, why start with a bunch of negative (and untrue) comments? Why not say how much you are enjoying using perl and start from there instead?

As for Perl's strengths, I don't think any other language comes close to the beauty of its regex engine. Other scripting languages do have regex facilities, but to the extent that they force regex operations into an OO framework (as Java and Python do), they kill the simplicity and, I would say, a fair bit of the power that Perl offers for doing a wide range of text-stream filtering tasks with very little coding effort (and very good runtime performance).

Add the integration of Unicode into Perl's regexes, along with the far-reaching Encode module for moving data into and out of other character sets, and you have a world-class God-send for people who deal with non-ASCII text data.

Then of course, there is CPAN. Nothing tops that.

As a more speculative notion, I haven't looked for or watched anything matching PerlMonks for the other languages -- I know (or assume) such sites are out there somewhere for Java, Python, etc. But I wonder whether they match the volume and effectiveness of our own Monastery. My (totally uninformed) opinion is this: when you get to be good with Perl, you get your work done so quickly, and the tool is so intriguing and multi-faceted, that (a) you have lots of time left over to help other people use the language, and (b) you have a strange compulsion to try it out on everyone else's problems -- it's such a great hammer that everything looks like some sort of nail...

Some people say Perl excels as a text processing language; with its wide range of string, regex and formatting functions, I agree. But I use Perl mostly for scientific and number crunching. Writing such code is fast and easy with modules like the Perl Data Language. Although I used to program in domain-specific Fortran, Perl is far more pleasant and flexible.

Basically, a project where perl is a good idea is if a possible 10% loss of processor efficiency is worth a 100% gain in developer efficiency.

(87% of all statistics are made up on the spot... 43% of people know that.)

------------
:Wq
Not an editor command: Wq
[download]

In the arena of CGI, it seems PHP has now become more popular than perl for newbies and even veteran coders.

If people are looking for speed, they tend to use C or Java for their applications.

Does perl have a distinct advantage in any particular programming task?

I program in Perl5 because it's fun. It's like exploring a partially enchanted, partially cursed mediaeval castle, filled with treasure, dragons, elves and cunning traps and surrounded by an enormous forest populated by a wide range of inhabitants. (Unlike perl6 which more looks like a 18th century French palace, with a well-kept, but boring park surrounding it. Java is an apartment building with no greens surrounding it.)

Abigail

Hear! Hear!

Magical and marvelous, Perl something I expect to find tucked away in a corner of Jack Vance's Library At the End of the World (in 'The Dying Earth' and other stories), with lots of forgotten and only partially understood spells just glowing in the dim light.

I have been keeping up in a fashion with the Perl6-ery, and it sounds like a 'best practices' rebuild. Functional, but kinda of soul-less. It will have its own quirks, being Perl, but I am going to miss my '->'....

A couple of years back at a PerlCon someone likened Perl to an old Hippie -- kind of odd and funky, tie-dyed and whimsical, but a hell of a lot of fun to be around. Perl was written as the People's Programming language. Java is an attempt by the Computer Sciences departments to recover the programming mystique and bottle it back up in the Ivory Tower. Perl and Java are "Power to the People" versus "The Religious Hierophonts".

----
I Go Back to Sleep, Now.

OGB

Java is an attempt by the Computer Sciences departments to recover the programming mystique and bottle it back up in the Ivory Tower.

If that were true, it would probably have offered a lot more OO features in version 1 than are even in the current version of the language. The only thing it arguably got right over C++ from a CS point of view was disallowing multiple inheirtance (which also means it's not there when you really do need it, except in a really hackish way).

Java's design is more like C++, but much simplier. You'll see plenty of comparisons between it and C++ that show development time is sharply reduced using Java. They're probably right, but then again, I don't think there are many people who will argue that C++ is a simple langauge to begin with. So I'm not impressed with such a comparison.

I think that if Java really was designed as a CS Ivory Tower language, it might be a lot better. There have been a lot of cool ideas developed since C++ was invented that Java doesn't include (though some are poping up in Perl6).

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated

It's not meant to be patronizing! When you know a little Perl and a little PHP, you will find it hard to see the difference. But when you know a lot of Perl and a lot of PHP, you'll definitely find yourself in situations where, if you've chosen the PHP route, you'll be thinking, "This would be so easy in Perl".

So, I guess it all depends what your long term goals are. If you don't see yourself doing more than simple DB powered web pages, you have no reason to learn Perl.

But, even if you'll never use Perl, if you understand what it can do, it will help you in your PHP. It seems that people who love Perl are people who love to learn (I, for example, am trying to get my head around Lisp the same way that a language student would try to understand latin - useless for everyday life, but essential for for changing your outlook paradigm :).

Right tool, right job. Keep that in mind.

.02

cLive ;-)

I rather like the quote that PHP is "Perl with training wheels".

<pedant>The correct quote is PHP - it's "training wheels without the bike". merlyn posted it at Re: Not Inciting a Holy War although as he put it in quotes I'm not sure whether this means he's quoting what was already a popular meme at the time. I don't know who the original author is in that case. In any event it seems like I've been seeing it pop up for years here and there.</pedant>

I use Perl for practically anything (but still keeping in mind the "Right tool for the job"), and I'm having a lot of fun in the process.

Arjen

Other monks have already said everything I would say about why one should use Perl, but there's one thing I haven't seen much of a response to. You mention PHP "seem[ing]" like it is "now ... more popular than perl." My only response to that is, "Who cares?!?" I know I sure don't. Popularity only matters insomuch that there is a healthy community around a language. Perl still has a healthy community -- even in the "arena of CGI." (I put quotes around this because most PHP is probably not actually using CGI, and most sane Perl web apps shouldn't either.) This all leads me to my hyper-obvious conclusion: popularity sucks. Use what works.

--- Begin gratuitious .sig
$"=q//;$_=q/print"@{push@a,for(42+$_)gonqw;72 59 76 58 63 55 56 66 69
22 77 58 9 15 4 57 69 67 -32;;\@a}"/;s$(g)(?=on)$ f$;s;(?<=fo)(n);r ;
;s,  f (?!s#(44|60|47|59|62|51|49|58|54|58|47|64|44|62|45) #$x{$1}#ge
;map{$_+42}qw/t i n l w g c s k r i/)(?=or),c,x;s!(co)(?=r)!ch!x;eval
[download]

What do you mean by "sane Perl apps shouldn't use CGI"?
Only use modperl, or are you getting at something else?

What do you mean by "sane Perl apps shouldn't use CGI"?

Well, I guess "sane" might not have been the best choice of words. By that definition, I am not even sane myself. Of course, not many people would argue with me about that, so perhaps the word still makes sense. ;)

Maybe I should have said, "for any Perl web apps where performance matters, sanity dictates the use of mod_perl instead of plain CGI. But for web apps where performance doesn't matter, CGI might be ok."

Perl can do CGIs, even though PHP is simpler.

Perl can do OOP, even though Python and Ruby are cleaner.

Perl can do text processing, even though sed/awk/yacc/grep are more specific to the task.

Perl can process XML, even though XSLT is (arguably) superior.

But none of these languages can do all these things reasonably well. This is what people sometimes miss when they say "Use the best tool for the job!" (and why I tend to avoid that phrase). If your task is simple, then you can get away with using a very specific tool for your task. In anything bigger, you're going to need to do a wide range of tasks. While you can break your complex task into several simple ones, you still need some way to glue together each part. For the purposes of getting real work done, you often need to pick just one tool, because trying to put many domain-specific tools together isn't worth the effort. You're often better off picking a tool which can do it all reasonably well rather than twenty tools that do very specific tasks.

There's a reason why Perl is called the Swiss Army Chainsaw.

Update: Speeling mistake. Thanks tilly.

Another argument against "do the right tool for the right job" (I know that you're not so likely to hear arguments against that here... but hear me out) is this: If you have one tool that works reasonably well for every job (maybe not the best tool for each individual job, in a vacuum), then you can invest yourself in really learning that tool inside out and very well. I may do things with perl that would be better done with sed or with a c program or who knows what... but they take less overall time in perl because I do so much else in perl every day. It's practiced and trained, I can rattle it off like nobody's business.

This is also why (if anyone pays attentsion to such things) I talk a lot, in my posts, about the line between perl scripting and shell scripting, perl "one-liners" and so on. Because, by the same token, I am needs-be using shell all the time, and perl one-liners interface incredibly well with shell scripting. I'm getting off topic here, but ever find yourselves doing stuff like:

something | perl -pe ... | sort | perl -pe ... | wc
[download]

or some crazy pipeline that flows in and out of perl one-liners and through other things that perl could do? Hell, perl can sort. Perl can count the number of lines read... why am I using shell for this? It's because if you're alread *thinking* in one language, use that language, even if it is *not* the best tool. The mind-set shift between the tool you're already using and the "best tool" is not worth the advantage that the better tool gives you.

Anyway... what that's all about is the fact that perl, by being so versatile, is a *reasonable* tool for pretty much any job... and that's often more useful than the very best tools for each of ten different jobs.

------------
:Wq
Not an editor command: Wq
[download]

This sounds like a copy+paste from a textbook. Have you actually done any work with XSLT? Have you actually written dynamic webpages in PHP or written OO code in Python or Ruby? How much text processing have you done with awk/sed/etc?

Of all the things you mention, the one I have no experience with is Python. Of all the other claims, the only one I can confirm is that Ruby OO is cleaner. I strongly disagree on all other points.

XSLT is a gigantic pain to work with, for a large variety of reasons from the mundane to the esoteric. Given the choice and an XPath capable XML module, I'd use Perl over XSLT every time without fail.

For text processing… well I don't know how you can write what you did, because Perl was invented because these tools were too limited to begin with. Note that I'm not sure what yacc is doing in that list, because it has a very different focus than the other tools (they're all about processing text in the furthest possible sense, I guess). I've written tons of trivial and non-trivial sed scripts, and while my awk exposure has been limited, I have written a handful of non-trivial scripts, enough that I think I have a feel for the language. None of these tools is very useful for anything more than pretty simple tasks.

As far as PHP is concerned, it really should be likened to the Template Toolkit rather than the whole of Perl. Give me Perl, any day of the week.

Just about the only thing that I can think of where Perl is a bad choice is raw, unadulterated number crunching. PDL helps, but really that's the domain of C. For any kind of data munging task — not just pure text processing, but really anything that involves combining or extracting data somehow, whether that be XML, database work, or whatever you can dream of —, no competitor comes close to Perl.

Makeshifts last the longest.

Just about the only thing that I can think of where Perl is a bad choice is raw, unadulterated number crunching. PDL helps, but really that's the domain of C.

Only if you really, really like explicit for-loops, memory-management, and POSIX threading. If you don't, PDL is vastly superior.

Have you actually done any work with XSLT?

Nope, but see this Kuro5hin.org article on XSLT, which is the reason I don't bother at all.

Have you actually written dynamic webpages in PHP . . .

Yes, I keep knocking my head against it's limitations.

. . . or written OO code in Python or Ruby?

Yes. They're both cleaner than Perl OO.

How much text processing have you done with awk/sed/etc?

Hardly bother to use them, since Perl does what I want.

Note that I was very careful with the wording of each of those statements. PHP is simpler than Perl. Python/Ruby OO is cleaner. Sed/awk/grep/etc. are more specific to text processing. And XSLT is arguably superior (though I wouldn't make that argument myself, clearly somebody thinks it's better (even if they're PHBs) or it wouldn't exist). These are very specific statements of overall "goodness".

What I didn't say was that they were all absolutely superior. Particularly in PHP's case. It is simplier, and that's preciely why I don't like it.

Update: Speeling mistake. Thanks tilly.

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated

Someone above mentioned CPAN. To add to that can I use the words FREE and OPEN. Enough said.

Forget all the stuff about "strictly typed languages" etc. We are dealing with "information". The information can come in many different forms, and mean different things depending on it's form. In other languages you are stuck on the "form of the information", but in Perl you just take the information and do what you want with it. Want to treat it as text? fine, as a number? fine, as a bit stream fine. Now Perl lets you do all this without having to worry about memory management, buffer overflows, and all the other drawbacks and pitfalls of "the other languages.

Java?....yuck, I see all those class files needed just to run a little app, and I delete it.

Perl just intregrates well with the way humans see information, it's the future, regardless of what the big companies say. As systems become faster, and RAM size increases, more and more people will use Perl instead of C, because it does the same thing and is easier.

For speed, use assembly, like in all the new video animation techniques. So I think using Perl as a pre- and post-processor for feeding data to assembly subroutines is the "ultimate".

From my observations of programmers I've been acquainted with, the ones that don't like Perl are the denser ones. They don't have the brainpower or willpower to pick it up, so they say "it's junk", and move on to languages like PhP.

Forget all the stuff about "strictly typed languages" etc

Perl is strongly typed. It just have "types" in the way most programmers are used to. '$' denotes a scalar type, '@' an array type, and so on. It is very strong (there's no way to transform an array into a scalar, for instance) and behaves in a way that most programmers would expect it to (what would an array transformed into a scalar look like, anyway?).

For the record, when speaking of type systems:

• Strong != Strict
• Weak != Dynamic

These are really seperate concepts, and I wish completely different terms were used to describe them.

The LHS is generally done at compile time, while the RHS is generally done at runtime. Strong vs. Weak deals with weather your language lets you transform one type into another. In C and Java, you can transform an int into a float through a simple cast, so they're reltively weakly typed. They also require you to explicitly define the type, so they're strictly-typed languages. Which is an annoying combination, because type errors and warnings are just as likely to be real problems as they are to be mere annoyances.

See also: Strong Typing and Perl by MJD. Very enlightening presentation. It demonstrates that if you're going to have a type system, don't do it half-heartedly like C and Java do. Not only that, but a truely strong type system (such as in ML) can have a lot of benefits without the problems normally associated with them.

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated

Perl is very well suited to textual analysis, finding patterns and such stuff, and you can create data structures as complex as you like in a picosecond. Try Java for that and you'll see the difference.

Perl is also an expressive programming language, meaning that there is more than just machine efficiency in what you write. You can choose to explore a problem from many different points of view, quickly; a little functional here, a little object-oriented there, twenty lines of procedural glue, it all goes. No other language I know offers the same grade of expressiveness, and this is why I personally love the language.

If you take PHP, for instance, it's ok as long as you want to create web pages, but if in the matter you have to solve some programming tasks, it's often more a nuisance than a helpful tool. Perl is (nearly) always a nice environment to work in.

Warning: Personal rant follows:
What I don't like in Perl (in Perl 5, at least) is the way the language handles object-orientation; Java/C++ have a much better and cleaner syntax, and most other languages are following it (I have seen that PHP 5 will be almost word-by-word Java-alike). I see things are bound to change with Perl 6, and I hope I'll love that as much as I like the rest of the language....

As stated above, Perl's strength's lie in its ability to be able to perform well in most realms (web, network, databases, XML) without necessarily being the absolute best tool in any particular area

The reason? To my mind it's CPAN. The culture around Perl has encouraged the building of a treasure trove of exceedingly useful modules. In most languages, if you have to deliver a solution, you need to start coding from scratch or scouring the web for libraries/modules/utilities that someone may have written already. CPAN can set you well on your way in many instances.

If people are looking for speed, they tend to use C or Java for their applications.

Now let me get into poetic stream-of-conciousness Perl-lust mode...

For me, it's R.A.D., pseudo-functional constructions, and screwing with people's heads including my own. Infinitely extensible, quick, and deadly. The metaphysical swiss army chainsaw -- an epiphany of future epiphanies.

It's R.A.D., a twisted hybrid of OO, functional, and imperative paradigms, and ability to mix and to match and borrow. It's extensible and funky funky and funky.

What is Perl? IMHO, it's the most powerful language on the planet in terms of developer efficiency -- and nearly as capable as C. It's a fusion of academic languages with practical real world ability. What isn't Perl? Well, C... but wait!

with Inline, XS, and so on...it merges nicely with C. Perl and C together form a wickedly powerful combination.

Yes, Perl takes skill to wield well (and there is no gun control, so often it get into the hands of newbies who abuse it and dredge it through the muck of anti-design and 'executable line noise'), but when properly weilded it is one tool that is always there and will always do the job brilliantly.

It is a hammer for nails...and screws. Ever heard that "when all you have is a hammer, everything is a nail?" -- Perl tends to make everything BECOME a nail, it could make Elephant Walking become a nail. Really, it could. And let's not forget it's usage as glue (or wood), for when nails don't apply!

I have yet to find this in any other language, nor have I come to love any language as much as Perl. Perl isn't perfect, but it's the closest to Nirvana in coding as I can get. And hey, I've written all of 5 CGI scripts in my life -- I do not consider that programming. CGI isn't Perl. Perl isn't CGI. It's sooooooo much more. And it's not just 'scripting' either (though you can do that). It's a real full blown language with a lot of powerful constructs.

No offense but your statements suggest that you are not familiar with the programming world.

Take a look at Running CPAN without Being root and you can learn how to install the modules locally. (In fact usually you can just copy the modules into your source-code directory and copy that over to the server.)

Hi Tilly,

Are you saying that since a module is simply a file containing related functions that I can access those functions by putting the file alonside the script that uses the functions rather than by installing it in the normal way.

I guess that if I can do that then there are no limits to what I can do on a shared server. I will experiment.

Thanks for the input.

Best wishes

Sid

Perl also seems to be, as brought to my attention by the Sams Learn Perl in 24 Hours, an excellent scripting language for prototyping a job that will eventally be compiled in something like C, especially with it's syntax being close to that of C's.

If you're truely "thinking" in Perl, you'll find that a lot of your code won't map easily into a C equivilent. And if you're not thinking in Perl, you're probably not taking full advantage of the language. There are those who write Perl, and those who write in interpreted C.

Now, that's fine if you're fully intending to prototype in Perl and then move to C (you just avoid using Perl idioms), but if you're humming along in Perl and suddenly the boss comes in and wants it redone in C, you might have a problem.

IMHO, you shouldn't make a C translation an option until you have proven that you need the speed benefit. If Perl isn't a good fit for your task, use another language, but don't automatically go into C.

/me does his part to keep the world safe from buffer overflows

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated

I am all to familair with the sceanrio of "humming along in Perl" and suddenly it is required to be rewritten in another language :). I haven't done much converting from Perl to C simply because the fact that Perl is much quicker and easier for me to work with, it is practical, as the name implies :). I didn't want to lead someone wrong with a bunch of my personal opinions, and I had made the connection between the basics of Perl being similar to the basics of C, with the exception of having to declare variable types in C :).