I'm not really a programmer, or at least I don't really consider myself one primarily. I always wanted to be...a lumberjack! Well, not really, but I never thought about being a programmer until I had already started doing a lot of programming as a scientist. Along the way I've run into a lot of languages. The things I like about Perl are probably best reflected in the reasons I don't use other languages. This isn't a knock on other languages: just a personal cost-benefit analysis and a bit of personal preference. Furthermore, once I made the commitment to Perl, I'm locked in. Switching costs can be pretty high once you choose your rut.

Perl is mostly stable: I used to like Java. I really don't have anything against it, and I haven't used it recently, but I was a partner in a company where another partner was a guy on the JavaSoft team. So, we used some Java. Then things got funky and Java became a moving target. I liked Macs, but despite that fact that JavaSoft was literally across the street from Apple, the Java runtime on Macs sucked. Perl's getting to be a little like that with the changes in various core modules, but certainly not as bad as the Java 1.0 days. Java is probably a lot more stable now, but I made the switch a long time ago.

Perl works with other things: I like Smalltalk, but unless I want to immerse myself in something that nobody else besides Ward Cunningham and 200 other people in the world know and use, I'm not going to get a lot of work done. I think Smalltalk would be more interesting if my machine was a Smalltalk environment, but it's unix, so it isn't. Unix let's all sorts of things talk to all sorts of other things.

Perl has sigils and CPAN: Python is nice. I like Python. There is a lot of good stuff there. However, it's missing sigils. Every time I try to use something in Python, I run into some problem with reserved keywords. A couple times a year I try to do everything I need to do in Perl in Python, but have a hard time finding the right modules.

Perl isn't object-oriented, and Perl has CPAN, part 2: Ruby is nicer than Python. Ruby is a wet dream, really, and I mean that as a compliment. It's as old as Perl 5. They have a nice community. They are getting more and more modules together. I even wrote a couple of Ruby articles, I think. Still, Ruby is object-oriented, and sometimes I don't need objects. There is some project size where an completely OO system costs as much as a procedural one, but I still do a lot of small things with Perl, so I don't want the extra OO baggage all the time. If I had to switch languages, I'd be all over Ruby. (Wait, that doesn't sound PC).

Perl isn't FORTRAN: FORTRAN is a pain in the ass unless you are doing formula translation, but the thing I hate is the code I've had to deal with. Once it's running it's really, really fast, and if I needed to calculate blast waves it might be the right tool, but I've found FORTRAN programs that would make the messiest Perl like neat. It's not really FORTRAN's fault: I blame the scientists. I also had to use it on VMS, which sucks the biggest donkey in the world.

Perl is about data, not computers: Do I really want to manage memory? Not really, but otherwise C is okay if I need all the power of assembly language with the ease-of-use of assembly language (stolen quote from somewhere). Sometimes I need that. Not often though. Perl is written in C, so it can't be all that bad. It's strongly typed, too.

Perl only needs the command line: I only learned C++ because I thought it would be a good thing to do. It was, I guess, but I hear a lot of horror stories about what C++ programmers actually have to do, and most of the ones I've talked to use some sort of commercial IDE. That's certainly not representative, and I certainly didn't use an IDE when I did C++, but that's what I hear C++ people talking about.

Perl gives useful output: Lisp is okay, I guess. I know Paul Graham built ViaWeb then Yahoo! Stores around it. Every time I look at it I see a bunch of mathematical masturbation without interesting results. Functional programming doesn't quite fit in with the real world, methinks. Calculate the Nth root of some polynomial all you like, and I'll be over here parsing some text. I haven't done anything serious with it though.

1. I like Perl's freedom. OOP theory states that you shouldn't violate object encapsulation. But what if I really really want to, just this once? In Perl, I can. And I can also be a disciplinned programmer and demand that everything I do be designed properly with accessors and mutators and whatnot. The point is, if I want to do a quick hack to solve some immediate problem once, I can. Other languages are authoritarian; they have a design philosophy and don't permit you to violate it. Perl lets me choose my own philosophy.

2. I like Perl's expressiveness. The malleable syntax and plethora of operators takes a long time to learn, but once you do, you can do pretty fanstastic things in a very small amount of code. Just look at a Schwartzian Transform.

3. I like Perl's context-sensitivity. Even though it looks much less like English than highly rigid languages like Java or Python, Perl behaves much more like a natural language. Words behave differently depending on what words they're next to, just like in real languages. That makes some things easy and other things hard, but it's definitely a lot more fun. Programming Perl is more like writing a foreign language than simply doing math.

4. I like Perl's people. The features I mention above tends to attract some of the best and brightest programmers around. People who want to delve into the gritty details of a language and explore its every facet, because to do some things you have to. The result is a community that filters out a lot of people who don't have true passion for the art of programming.

I like perl because it's versitile. I can learn one language and have something that works well creating reports, making web-based applications and sites, and have a very powerful scripting language (that is fairly easy to replace or work with bourne and ksh/zsh) - these 3 being my main three jobs at work. Also perl's just fun to create useless and strange looking programs with which you can amaze your friends ;). I dislike using perl for executables. I've been looking at PAR (and other such modules/methods) but have yet to have a chance to try it, so that might change.

I note you didn't meantion your reasons for liking/disliking perl and if we are to tell our reasons it's only fair that you share your's.

I generally like the community attitude, talent and expressiveness.

I dislike the bolted-on OOP, for the times when I like to use OOP.

I like that Perl is available for everything, everywhere, and it doesn't get in your way.

I like the mallability of the language, but I dislike the solution to "fix" Perl (and Perl OO) by source filters rather than language design (lots of OO modules are an example).

Edit by castaway - swapped square brackets for HTML entities

I like perl for the following reasons

1. User friendly way of coding.

2. Easiest way of learning and applying the programming ideas to get our required output.

3. I like Regular expressions features because now we are using in our applications.

3. it covers all the programming languages features.

4. This takes less time to create the code and solve the problem.

5. We can use and apply the coding already exist in the module (CPAN).

6. TIMTOWTDI Nature.

This is the Nice question which i have answered to it.

Thanks

One thing that it seems to me not to have been mentioned yet and that I like particularly in Perl is the pervasiveness of natural-languages like principles.

Of course there are also some typical Perlisms moderately to consistently deviating from said principles. But for some reason everything seems to fit quite fine as well, and indeed to me they look like being just as "natural". In fact I like the freedom and the flexibility I'm given, although I'm aware also of the potential risks in them.

All in all it's difficult to say exactly what you like in Perl, just as much as it's often difficult to describe exactly what you really like in anything or FWIW anyone you like.

I can only say that I've tried many (well, maybe a bunch of is more like it) different languages, but I could not get hooked with any of them. Instead I started using Perl because I had a few tasks to perform and I simply tried it, then I found it unvaluable to do more and more things, so that for some reason that I can hardly explain I couldn't help getting hooked with it.

Good Question
TIMTOWTDI
The above mentioned proverb u can't seen any languages. The only language perl u can see the proverb. Perl is very flexible than the other languages.

I gone through many platforms. I have never seen much more easy way like perl. Perl is very useful in all the sides in typesetting fields, programming fields, and web designing and also in networking sides.

Easily all can observe the perl coding compare with other languages. The CGI perl is very useful.

In perl, we can arise questions and get answers through monks like this we can't do in any other languages. All were helping always with creating some modules. so, i like perl very much.

Easily understandable language when compare to other language.

Regards,
Gubendran.L

• I can write code in one of many ways (there's more than one way to do it). This is good: it can save work for me, as an author.

  Unfortunately, so can everyone else. This is bad: it can create a lot of work for me as a code maintainer. I may end up having to decipher ten different idioms to maintain ten different people's code. So will each of the other ten people, if they have to read each other's code.

• On the plus side, Perl lets total newcomers churn out code quickly. On the minus side, Perl lets total newcomers churn out code quickly: and usually, in a few years, the company has to hire an expert to clean up the mess they've made. Again, the novice author may only need to understand a small subset of Perl to write code. The code maintainer, who doesn't know which features a given author may have used, needs to know all of Perl before he can be confident he can fix it. Gambling on not needing code maintenance can be costly.
• Perl has nice, English friendly syntax, for doing some things ("if" vs. "unless", for instance). Unfortunately, it has horrible syntax for others. If I want to create global variable, I use the keyword... "our"? If I want to create a local variable, I use "my". If I want to temporarily override the value of a global variable, until the current block scope ends, I use "local". Here, Perl's history has made the syntax ugly and unfriendly. By contrast, adding "unless" to the language doesn't gain all that much.
• I like that perl functions take a list as input, and return a list as output. I dislike the lack of a named paramter list: again, using an obscure @_ variable to handle the argument list is confusing. The fact that @_ modifies it's variables, and only complains if this is impossible at run time is annoying.

  I want proper named parameter lists, with variables explicitly marked as modifying their callers if that's what they are to do. Whenever I try to explain Perl functions to people, they usually pause in confusion right when the hit the @_ line -- I end up having to say it's there because "it's Perl and yes, it's ugly, but it works".

• Exception handling: it's ugly in Perl. There's no standard set of exceptions thrown by CPAN modules (too often, "there's more one way to do it" means "well, no one's agreed on a standard yet"). If I inherit a chunk of code, it's not clear what exceptions are thrown, nor what's done with them. Calling "die" to raise an exception is somewhat obscure. Expecting someone to have read the section on 'signal handling' when they want to catch a signal raised by "die" is worse.
• Perl's data structures are dynamic and flexible. This means that if I want to, I can create free form data structures that conform to any pattern I like.

  On the down side, I can do this by accident, even if I don't intend to. If I accidentally refer to something that doesn't exist, Perl creates it for me. If I intend for all elements in my list to have the same structure, Perl doesn't enforce that for me.

• Perl has packages, which were a good idea. On the down side, $::x was chosen to mean global variable x in the main package, not the current package. As a result, I have to choose between using the "our" keyword, and not having global variables stand out as special, or fully qualifying them with a package name, and then using a global search/replace to change them all. I can violate package encapsulation: by design(good), by accident(bad),or by misunderstanding (typical).
• Perl has objects, and presents the notions in a simple enough way that it's clear even to someone with a non-OO background what they do. On the other hand, it lacks a lot of typical OO features: unless you work hard at making your objects tamper proof, they're not.
• Tied objects mean I can't trust code to do what it says it does. If I include a suspicious module, I can't be sure that "$x = $x +1" does what I want it to. It also means an optimizer can't assume $x=$x+1 will increment the scalar variable $x.
• Perl's syntax is complex and variable, to allow poetry to be written, and to attempt to "do what I mean" in several cases. This makes it hard to figure out when Perl is doing something which is not "what I mean". It also means that code which tries to process Perl programs, such as Perl specific IDE, will have a hard job. I know, because I've thought about how to do it, and it's not easy.

  I'd love to see a refactoring friendly IDE that let me rename all variables within a given scope, or one that automatically updated all function calls when a function name changed within a given project. What about a search function that only applied within a given scope, so I could search for all variables used within the ugly 3,000 line loop I'm trying to refactor into something sane? It would be nice, but just parsing out where a function starts and ends is hard work. ( Look at how complicated the B:: family of modules still are, and remember that people have worked on them for years. They're still all marked experimental.)

• Documentation: I have a love/hate relationship with Perl's documentation. Perl has it, which is good. It's almost always correct, which is better. On the other hand, a lot of it is glib, riddled with jargon, and/or missing important sections. For example, the section on regular expressions assumes prior knowledge of regular expressions.

  The section on watchpoints in the perl debugger arrogantly assumes knowledge of watchpoints. It doesn't explain how to set at watchpoint that's only triggered when a specific value is reached, which I could do back in 1991, using C. under MS-DOS. This is not progress. (And no, I still don't know how to do it in Perl. If anyone does, please tell me!)

  The section on the $_ variable in perlvar still reads: "various functions" when it tries to explain the places where $_ may be used, rather than spelling out the list of functions. (Whose arm do I need to break to get this fixed, BTW? It's been like that since 1995, and everyone I talk to hates it. Some of my friends stopped trying to learn Perl, mostly because of confusion of $_, and the related sense that Perl was obscure and incomprehensible.)

• Perl should default to assuming local variables within functions, when use strict is not applied. This would make turning programs into the stricter variant much, much easier.