Perl is a very supple language, but it has its quirks. For instance, it isn't at all obvious that scalar keys %$some_hash returns the number of hash elements in constant time. (We had quite a thread on that one, complete with BrowserUK benchmarking). Nor is it obvious that die; (without any parameters) rethrows an exception. Somebody thought that $#some_array was an intuitive way of specifying the last index of an array, but it wasn't me. Nor do I think scalar @some_array is a particularly obvious way of saying "I want the size of the array". I could come up with quite a list of these oddities.

So perhaps the starting point is to say, "yes, there are parts that are difficult" and then maybe ask them to explain further. Once someone names specifics it is much easier to say "yeah, but that's bad practice and no longer recommended to new programmers". Or if they are talking about something that is hard but powerful, like regexes, one could say: "yes, that is hard, but it allows so much power in just a few keystrokes". And if they are in fact talking about some of the more arcane syntax, well, just agree, but point out that those are just one small part of a language. Every language has its awkwardness. Why, for example, in Java do I have to declare a whole class using boilerplate code just to have a closure?

The other part of their response "Perl only exists as long as Bio data is in text files" completely misses the point as to why Perl is the tool of choice. It isn't the file format that makes bio data text like - it is the gene sequences themselves. As long as RNA and DNA comes in chains, you will need regexes and as long as Perl is the regex processor of choice, it will have a use.

Good comment... Though you do dance around an obvious weakness of Perl. There's no GUI--nor are there visual tools for perl of any sort. And let's face it, a lot of programmers of the C# and Java ilk, tend to build guis first, and then plug into those and think they've done something amazingly sophisticated--not realizing at all that these tools they use, really aren't a reflection upon the underlying programming language at all.

Why did Perl enjoy such a spike in productivity ten years ago? Because of the web. It is inherently visual, but it required text manipulation. Where are the quick strides now being made in that arena? Perl's doing some stuff, but it simply doesn't stand out as much... because a lot of tools have made simpler languages a whole lot more easy to do the easy stuff quickly.

That and many people are inherently VISUAL. Perl leaves behind a large portion of the human being by neglecting graphics and visualization the way it does. Heck, there are computer architecture trends that are exploiting the graphics card as the next great source for computer power.

sorry it's an old worn-out soapbox, but honestly, I think that without some visual tools, I can't help but think that we'll always be the red-headed stepchild of the computer world... cuz the people who make the decisions in my places of employment don't understand much beyond powerpoint slides and the occasional (if I force them) excel spreadsheet. Heck, They freak out when I suggest we do all our documentation on a wiki, rather than using something like Microsoft word... sigh... My kid just made a powerpoint presentation for school for homework. She should've done it in Perl. Heheh... Gah.

I agree with this particular soap-box. The role of technology has changed profoundly in the last 25 years. Not only are human beings visual, but the entire process of marketing technology has gone visual, starting perhaps when Steve Jobs realized that you could sell computers the same way you could sell stereo sets and piano - as cool furniture.

Or consider the buzz two or three years ago about mash-ups. To someone who understands the algorithms they were little more than glorified report writers that drew data from REST and JSON feeds rather than databases. However, the visual excitement of seeing boring data found one place on the web dressed up in snazzy graphics and geolocation software made people think that suddenly programming had turned into sport anyone could play. The selling point on the IPod-touch and IPhone are great visuals and high usability - not technical wizardry. No matter how much wizardry there actually is, that is not what is selling it. I could go on. We are no more in the days of software=technology than we are in the days of autos=mechanics.

There will always be hard core engineers and artists who will immediately connect to Perl (or so I hope). However, without an avenue into the world of the visual I think Perl is likely to increasingly become a niche product relegated to scientific research and backend systems administration. That's an important niche that will guarantee jobs, but it is important to remember that it is at the bottom of the financial food chain. Sysadmin and research are cost centers, not revenue and market builders.

I see symptoms of that already. If you look at CPAN, the vast majority of modules are for programmers by programmers. There are very few modules written for the end user, non-technical web-site owner or non-programmer.

I see a vicious cycle here and GUI/distribution/mod_perl are at the heart of it. If I don't have good visual tools, I can't even think of writing a package for the end user. If most cheap webhosting companies charge extra to use Perl, I can't write to the low end web-site owner market either. If there is no push-button always-works distribution system (the modern standard), even the best package will be left with a limited audience.

The absence of end-user software and distribution systems reinforces the idea that we are still in a programmer-to-programmer world. That fantasy makes things like make-less builds, skinnable GUIs with modern event loop processing or a binary distribution depo seem like something nice to have or even silly. If they are nice to have or silly, why build them? They remain absent and hence the cycle begins again.

Freight locomotives do not have a GUI.

Nevertheless:   Not a single railroad on this planet could possibly exist without one.

And... in (for example) the case of “the Web,” where, exactly, does the software begin and then cease to be “graphic?” Is Perlmonks “graphic?”   Amazon.com?   eBay?   Perl programs all!   Are they “graphic,” or not?   Here we have passed beyond the realm of creating “gooey programs” on single-user desktop and hand-held computers.   We might have stumbled into the warehouse, where “10,000 outgoing packages must be loaded on that truck by 4:45 PM, or there will be no money to pay anyone to come to work in the morning.”   Perl is there.   What is the true significance of a “graphical IDE in this setting?”   (Beyond what is provided, for example, by Eclipse?)

I clearly do not mean to be provocative here, but in a most friendly way I suggest that I really don’t think that your argument is sustained...   There is both a place and a value for both types of languages & tools.   It would be impractical to write a GUI program without a good GUI-oriented SDK, but there is a vast world of useful computing beyond that realm.

So you're saying the following is unclear, even to someone who knows but the very basics?

if (!@clients) {
   ...
}

for (0..$#clients) {
   ...
}

if (!keys(%tasks)) {
   ...
}
[download]

I would say those are rather readable, even without the "..." populated. They should be crystal clear with the "..." populated. Whether the parts are meaningful in isolation is not very interesting.

For instance, it isn't at all obvious that scalar keys %$some_hash returns the number of hash elements in constant time.

That's got nothing to do with readability. You wouldn't say hash.num_keys is unreadable, yet we know nothing of the efficiency of num_keys.

Perhaps a small seemingly off topic diversion might make my point clearer. Consider the beginning of Louis Carroll's "The Jabberwocky":

Twas brillig, and the slithy toves
  Did gyre and gimble in the wabe:
All mimsy were the borogoves,
  And the mome raths outgrabe.

Even though almost none of the words will ever be found in the dictionary, my guess is that you know that "brillig" is an adjective, "toves" are some sort of animal or animate being, and "outgrabe" is a verb. You know all this because as a skilled English speaker your brain can use the structure of the sentence and the morphology of a word to guess its approximate meaning.

In the same way, an experienced programmer who has never read Perl before in their life might well guess that at the meaning of $#foo when he or she sees for (0..$#foo). He or she knows that "for" clauses generally have starting and ending boundary conditions. 0 looks like a starting condition. ".." is a common symbol for a series in both mathematics and English. By process of elimination $#foo is likely to be the final boundary condition.

However the ability to guess at the meaning is not quite the same thing as $#foo having inherent meaning on its own. Were one to encounter my $x=$#foo one would be lacking the structural hints and $#foo would be opaque in meaning if you didn't have prior knowledge. The # suggests it might have something to do with numbers, but there is nothing that says what number it refers to: first index, last index, count, or something else entirely? You'd have to look it up.

That same programming background can also trip people up if they assume too much. !@somearray only makes sense once you've got the notion of context determining data type. For someone coming from a computer language where that doesn't exist as a concept !@somearray just looks like nonsense or an always false statement. Negating an array makes no sense at all to someone coming from a VB background. For someone coming from C/C++ or Java, it would likely be interpreted as always false. @somearray is an array rather than a reference so presumably it "exists", i.e. already has an address reserved. If it has an address, how can it be "not" even if the array itself is completely empty? Zero-length is not the same as non-existent or null. Even if you argue that every piece of that chain of logic is completely wrong in Perl or even in C, you are only driving the point home further: for !@somearray to make sense you first have to think in a Perlish way. If you don't you are left confused trying to shoehorn it (unsuccessfully) into the concepts of other languages.

On the other hand, once you do understand Perl, the language holds together well and has good mnemonics. The "#" in $# is a good mnemonic for that "number thing" associated with an array, but it only helps once you already know the meaning and just need a little memory jog.

Seems to me that most are talking about features that are foreign to them. They assume something must be hard to read if they don't know what it means. For example, someone who just knows assembler might not understand Java (for loops? objects?), but that doesn't mean Java is generally hard to read.

The primary culprit is regular expressions and the related ops. They don't realise that the full page of code it would take for them to do the same without that regular expression would be just as unreadable as the regular expression.

One place where I would agree with them is the overuse of global variables.

People love to feel right, and geeks in particular like to feel intelligent. Unfortunately, one popular way of feeling intelligent is to take a complex system which you don't understand, and paint it with a broad brush describing how inferior it is. Many people, on seeing or working with Perl code, become bewildered and frustrated. This occurs in every language. But somehow, for Perl, a strong meme has developed that blames the language rather than ignorance of it. This makes it easy for people to feel intelligent despite their earlier feelings of bewilderment, by simply blaming the language. It's worth noting that pretty much everyone but the most enlightened of humans engages in this behavior to some extent, with whatever our favorite whipping-boy language happens to be (e.g. Visual Basic, COBOL, APL).

In my view, it's important to try to rise above the bickering and not become upset. After all, they're making snarky comments to feel superior, so by becoming defensive you show weakness, making them think you've got something that needs defending, and reinforces their snarkiness. Perl does not need defending. You can just say "haters gonna hate" and let it be. Chances are they will doggedly defend their opinion no matter what you bring to the argument, because to concede their point is to reveal their own ignorance.

However, on the off chance they are actually willing to learn something, or can accept that the facts as they understand them are inaccurate, it does help to have correct information on hand:

• Readability, organization, ease of articulation are things that are both based on experience and taste. It's hard to argue these other than by saying that Perl is flexible enough to adapt to whatever style you personally find beautiful (unless you're allergic to sigils). One telling fact is that Ruby should receive roughly the same treatment, but doesn't. I think Ruby is quite beautiful, but it can be made opaque and terse just like Perl. Even so, people love to hate Perl more, so it's not just a matter of syntax.
• On the matter of Perl being kept alive only by bio data in text files, just ask for data. It's hard to measure things like how popular a language is, and every measure has some flaw, but just about any site you can find that attempts to measure this will rank Perl in the top 10, and consider it a mainstream language. For example, tiobe, langpop, or even GitHub's Top Languages. It would be hard to imagine that all those Perl jobs and projects are supported by the bio information market.

So even if you show them a piece of very clean Perl code, some people just notice the presence of sigils, and refuse to even try to understand what the code does.

Many years ago, I learned to respond to all such provocations with a gentle, monkish smile and a disarming word.   (Go ahead, be an actor ... just make something up.   Then fake an incoming phone-call of exceptional urgency and, upon your return, make a beeline for a different table.)

People will sometimes say things “just to get a rise out of you,” and when the drops of blood finally dry upon the walls, what has been accomplished?   Zilch.   So, just don’t bother taking the bait.

Every programming language ever made by man (and, probably, every other possible contrivance, as well...) has features about which one might say, “oh, if I had it to do all over again, I <would | wouldn’t> ...”   But, you don’t.   It’s done.   Zillions of copies of it are now in-production all over the planet and, believe it or not, they’re working.

P.S.:   If you remain convinced that you have discovered some Universal Truth that no one else in our profession has yet discovered, go ahead and Create Another Language.™   (Note that the moniker, “Silver Bullet,” is already taken, but there are still plenty of both bland and sexy-sounding names left to choose from.)   It is usually a good idea to have prepared the book and the initial worldwide lecture tour well in advance.   A certification program wouldn’t hurt, either.   The world always needs Another Silver Bullet.   Always room for one more.

;-)

They were so opinionated that Perl only exists as long as Bio data is in text files, if that changes then no more Perl...

topics such as PDL, BioPerl, Text::Table, DBI,...

#for databases
use DBI;
use DBD::<something>;

#for web-based extraction/scraping
use LWP::<whatever>;
[download]

So take a deep breath.... and another. Just don't hyperventilate and really lose your wits. 8-)

I recently spent several months in a very-SAS shop (see my recent Meditation on the automated recovery of program understanding), and I was quite amazed at what they were able to make SAS do.   I also noticed how SAS Institute had in-effect woven a procedural programming language right into their heretofore “PROC and DATA-step oriented” system.   It quickly occurred to me that they were using a lot of quasi-SAS code to do what a little bit of Perl code could do, and that the resulting (Perl) code might be a good bit easier to maintain (take vastly fewer resources, etc).   My position was heard and understood, and, technically speaking, was not denied.   The decision was made to stick with the Devil that they already knew, and I did not press the point further.

Nor did the point need to be pressed.   Their objective was to get $work done, and, in their own peculiar, sassy way, they did so.   Thankfully, I did not hear much “Perl bashing,” because most of the people I was talking to had worked somewhat with Perl in their distant past.   Also, I noticed that several of them were surprised at what Perl could do now, versus the last time that they had encountered it.   So, those seeds I planted might yet bear some fruit.

I've found the thing that freaked me (and most people) out the most about perl are things that once you know how they're used, they have power that no other language can really compare to...

1. $_ and other hidden variables. These hidden functional variables that just get set at seemingly random times, is freaky. another command that has "implied variables" is "sort" which I always end up looking up, if I have to do anything more complex than use the <=> operator.

2. Sigils and Barewords... they just feel like a bother to most people, who want to know if a variable is an int or a string... it takes a while to understand that context gives type. Whenever I switch between C and Perl I end up dropping sigils by accident, only to find barewords really freak out Perl. Then again, I find pointer notation in C++ is really annoying--especially the precedence required for casting, though in variable declaration the * placement appears all over the place. Perl makes that stuff much easier.

3. Random arbitrary keyword variables like exporter, ISA and all the qw(), and some modules/namespace dereferences is a real pain, but this is mostly because I first learned perl before they were really prevalent... and now that I'm trying to use strict, I find the complaints about my use of globals to be annoying. :) Objects is another one of those things that juggling terms is kinda tough.

4. Pod format... sigh... I know I should learn it... but honestly...

Ironically the regex was what really drew me to Perl, because I learned them in a Unix class before Perl was really known to anyone at my university. And I fell in love with regex captures, from the beginning. THat feature alone has made me a loyalist for life. :) --Ray

I was actually taken aback by the statement on the validity of Perl as long as Bio data is in text files that I missed the string processing and the very nature of representing DNA and protein letters in string, that was a good point ELISHEVA

Perl friendliness can be a weak spot that outsiders take to accuse the code as being unreadable and clumsy, I was able to learn and get started on Perl quickly, but not until I joined the Monastery did I shape up my coding and stopped shaking, and of course, I am yet a novice and yet picking things up to stability, the point is, friendliness allows those wanting to learn the language to quickly pick it up but doesn't guarantee that they can write the cleanest of code out there...

raybies have a good point with all the requirement for the Visual component to gear up, but, well, Perl can be part of a production that depends on visual orientation, in my line of work, there's this CLCBio suit of programs specific to sequence analysis, some of these programs are Perl modules and the entire thing is wrapped up in a very sophisticated GUI interface. STATPerl is another one, the author has made All analysis and graphs in perl, only the user interface is developed by VB6 and I have seen some Tk/OpenGL marriages, but of course, thinking of building a GUI and then plugging code into it may not be a joy-ride in Perl as compared to Java Applets for example.

Regular expressions can go nightmarish, when they do that YAPE comes into mind, compared with other languages that do regexes, Perl stands out because of its inherent text processing capabilities, so having an engine to parse patterns just completes the entire toolset. If someone did not invest the right amount of time on learning Regular Expressions in an incremental progression they won't accuse themselves for the cause of their inability to understand and employ regexes which, in part, is not fair, they are cryptic but that's their nature and that's their coolness..

I oft refrained from wading into bickering arguments and always entertained the opposite opinion by forgiveness, for those who do not know can be forgiven since they do not know but once they know and go overboard on their attemtps of attrition, you tend to lose your cool, the emotions for Perl are always mixed, there are those who just love to hate the language as bellaire says, check the Urbandictionary's Perl entry. While our love for the language should not blind us from identifying weaknesses we still do not seem to have the habit of picking on other languages, which is really supreme on our side and this is one of the reasons that this community is so vibrant and so focused.

Perl looks natural as a language more than SAS for example, it has fewer constraints when it comes to typifying variables, a number or a string are efficiently dealt with, the memory management is automatic, the TIMTOWTDI rules over Python's deterministic approach and many other qualities that shall make this langauge last longer than perceived

Other source of confusion that causes some to predict the demise of the language is the Perl6 counterpart (so to speak), many think it is a replacement to Perl and they go the extra mile of saying this and that about the counted days before Perl becomes obsolete, that shakes the confidence in those contemplating spending the time and efforts learning Perl or acquiring Perl into their stash and serves an empowerment deal to those who wrongly choose to hate Perl.

In conclusion, my plattering should've been titled "What's it with those who hate Perl", and I should've tried to look into their genetics for clues... :P

I'll simply use this quote :

There are only two kinds of languages: the ones people complain about and the ones nobody uses.
Bjarne Stroustrup

But my guess is that the moment you become a proper Perl programmer you start to achieve your objectives with lesser (and perhaps more efficient) code and perhaps code that looks less readable to the non-monks.

In my experience quite the opposite is true. The more experienced someone is the more readable their code becomes. Experienced programmers in any language know how to use the language's features to make the code self-documenting. They remove clutter by encapsulating logic in functions and methods. They chose variable names and method names wisely. They take advantage of the languages scoping rules and cluster data close to the methods that use them.

Sometimes experienced programmers do use some of the less common features of a language, but their experience ensures that they are used to improve overall readability. Of course, you will have to look that funky syntax up in the reference manual, but this is no different than reading a good columnist in the New York Times or ploughing through a Faulkner novel. You'll go to the dictionary from time to time reading those, but once you know the words, you have the feeling that "yeah - that word says it best". A good writer in both English and code chooses words carefully.

The programming equivalent of "big words" that you have to look up in the dictionary exist in every language. I've written some pretty complex code using Java generics. I doubt your average Java programmer could read it without some thought. Heck, if I've been away from it, I need to crack open the docs and relearn things just to dig into my own code. Php has a bizillion functions and the naming of those functions sometimes seems just a little haphazard. If you code using some of the more unusual ones, your reader is going to be spending time in the docs even though it is "only" Php.

I've recently been going through a number of the exercises at ProjectEuler. I did find it amusing that some questions turn out to be a one-liner in Perl.

On the other hand, I imagine many people, Perlers or otherwise, would require some hep with

my $sum = reduce {$a + $b } map { .... } grep { ...... } @some_array
[download]

Yes, it can be broken into an explicit block, spread of several lines. Besides being more verbose and slower, the block focuses on what happens element by element, while the dense version thinks in terms of the data set.

As Occam said: Entia non sunt multiplicanda praeter necessitatem.

I realize that you can write bad code in any language. However, less readable code may not necessarily qualify as bad code.

The author in the article below says 'Perl is renowned for being a language where you can express complicated commands in a very small amount of space.'

http://www.builderau.com.au/program/perl/soa/Special-shortcuts-in-Perl/0,339028313,339272650,00.htm

May be good Perl programmers do not sacrifice readability for brevity. However, it would appear that Perl allows 'brevity' like no other language. I mean no offence when I say all this. All I am trying to say that when an average programmer is learning a new language, he/she may find the brevity a bit hard.

This does not happen so much with other languages.

Certainly it does! See The DailyWTF for copious examples.

Everyone writes more or less the same way.

I can find examples of good Java and bad Java as well as good Python and bad Python. (COBOL's probably an outlier.)

A good, advanced Perl programmer isn't writing code that's hard to understand for beginners to the language and programming novices. They write advanced solutions to advanced problems. It's those solutions and the problems they address which are difficult for beginners to understand. That is the case for any language.

A one line conditional statement isn't hard for me (a beginner to both programming AND Perl) to recognized because I've learned and seen examples of them in use. Other than being cool names, I had no idea what implode or explode were supposed to do in PHP (two of the very first functions you learn in the language). One step further, imagine going into a Python forum and asking "Hey, what does '>>>>' mean? I keep seeing it in my book?" I'd be laughed out yet that's a question I had when first researching what programming language I wanted to learn.

These are small particulars that you have to look past and instead ask: "What is this language's approach to solving problems and is it similar to the way I think or want to work."



"...the adversities born of well-placed thoughts should be considered mercies rather than misfortunes." — Don Quixote