Some time ago, for no particular reason, I tried reconfiguring my keyboard to use the left-handed dvorak layout. It's designed for typing with one hand, and it looks like this:
`[]/pfmlj4321 ;qbyurso.65= -kcdtheaz87 'xgvwni,09
I printed that layout and posted it on my cubicle wall to help me learn. Soon enough, the seemingly random series of symbols attracted attention from my coworkers, and one of them, knowing my scripting habits, made a guess:
"Is that Perl?"
Well, the keyboard layout above isn't syntactically correct Perl, but it's not a bad question. After all, Perl has no problem with this:
use GD;$f='#ffffff';$T=table;sub p{print @_}
p"<body bgcolor=$f>";for(@ARGV){open*G,$_ or(warn("$_:
$!")&&next);$g=GD::Image->newFromGif(G)||(warn$_,
": GD error"and next);@c=map{$_!=$g->transparent
?sprintf'#'.('%.2x'x3),$g->rgb($_):$f}0..
$g->colorsTotal;p"<$T border=0 cellpadding=0
cellspacing=0>";($x,$y)=$g->getBounds;for$j(0..$y)
{p"<tr>";for($i=0;$i<$x;$i++){$s=1;$s++&&$i++while($i+1
<$x&&$g->getPixel($i+1,$j)==$g->getPixel($i,$j));p"
<td bgcolor=",$c[$g->getPixel($i,$j)],"
colspan=$s> "}}p"</$T>"}
The code above is an extreme example, done in fun. It's #16 on this perl one-liner page from The Perl Journal. (Follow the link if you want to know what it does.) But the sad truth is I've seen professionally produced perl code with about this level of clarity.
Here's a more mundane program, written in two different languages:
while (<>) { | import sys
print if /perl/i; | for line in sys.stdin.readlines():
} | if line.lower().find("perl") > -1:
| print line,
Both of these programs read a file from stdin and
print the lines that contain the word "perl", regardless of case. The
program on the left also lets you specify a filename to read on the
command line, without piping the file through stdin.
The program on the right took a little more thought and a few more keystrokes to create. I also wasn't sure how to make a string lower case in that language, so I had to create a string and ask it:
>>> dir("")
['capitalize', 'center', 'count', 'encode', 'endswith', 'expandtabs',
'find', 'index', 'isalnum', 'isalpha', 'isdigit', 'islower', 'isspace',
'istitle', 'isupper', 'join', 'ljust', 'lower', 'lstrip', 'replace',
'rfind', 'rindex', 'rjust', ' rstrip', 'split', 'splitlines',
'startswith', 'strip', 'swapcase', 'title', 'translate', 'upper']
>>> print "".lower.__doc__
S.lower() -> string
Return a copy of the string S converted to lowercase.
>>>
The program on the left required no thought whatsoever. I just typed it in and was done. While both of these programs are more concise than the equivalent program in, say, Java, the program on the left sure got the job done quicker. In fact, the language on the left is almost always quicker, because it's so much more expressive. That's why I love it!
If all I did was write new software all day, I'd probably use the language on the left for everything. But I actually don't spend that much time writing new software. Like most developers, I spend much, much more time enhancing software that's already been written. The only way I can do that is if I can read and understand the code that's already there (even if I wrote it myself just yesterday). Which leads to the million dollar question:
Which of the two programs above is easier to understand?
Anyone who's written a perl script should understand the program on the left with no problem. But anyone who's ever written a program at all should understand the program on the right. They may not know enough to write it themselves, or how to edit it. They may think it looks weird because it doesn't have curly brackets, but given a minute or two, they can figure out what it's doing.
What's the difference? Both programs describe the same process, but the one on the right describes it explicitly in words, whereas the perl program describes the process implicitly. The perl program doesn't make sense unless the reader understands what each symbol means:
<> returns the next line from stdin or a
filename specified on the command line.while (<>) { ... } loops through all the lines in the
file until EOF is found. $_. print prints the value in $_.// is the pattern matching operator, and
//i matches without regard to case.$_.The program on the right is written in python. It also has several symbols, but they're much more familliar to most programmers. The only really quirky thing about the python script is a formatting issue:
print usually appends a newline to
whatever's being printed.print's newline to a space.Python makes you do a little more work to spell out what you want, but there's fewer surprises along the way.
It's probably also useful to know that find() returns
-1 if the string is not found, but this can be inferred from context
and immediately verified from the interactive programming
environment:
>>> print "".find.__doc__ S.find(sub [,start [,end]]) -> int Return the lowest index in S where substring sub is found, such that sub is contained within s[start,end]. Optional arguments start and end are interpreted as in slice notation. Return -1 on failure.
When I have a perl question, I reach for the documentation. When I have a python question, I just ask python.
Perl is full of shortcuts, magical symbols and context-specific grammar. That's what gives it its expressive power. It's also why some people call perl a write-only language.
Of course, you can write beautiful, readable perl. As a high-level, loosely typed languages, both perl and python skip the tedious level of detail required by languages like C and Java, and let you jump right into your actual code. But the approaches differ significantly. If Java were a college textbook, python would be the newspaper, and perl would be either a post-it note or Finnegan's Wake.
Perl is all about jargon. It was created by a linguist, and designed to have the expressiveness of natural language. Some people even write poetry in it. Perl beginners can write useful programs in baby-perl just as infants get their point across through baby-talk. The perl interpreter is a fantastic listener, willing to go to great lengths to figure out what you're telling it to do.
Unfortunately, the people stuck with the job of updating your code aren't perl interpreters, and the jargon gets in the way. The more you take advantage of perl's expressive power, the more mental energy it takes to understand it later.
As a programmer, I often find myself explaining a programming concept to a nontechnical person only to see their eyes glaze over as they slip into a deep, hypnotic trance. It's not that they're incapable of understanding what I'm saying, it's that the words I'm using make them do much more work to catch up. When I drop the jargon and explain the concept in more detail, they understand. The tradeoff is efficiency. I get my point across, but it takes me a little longer.
I like perl. It's got a lot of great things going for it. I've written positively about perl in the past, and even have some open source code out there. Even so, it's probably obvious by now that I've left perl for another language.
About a year ago, I made the decision to write all of my company's software in python. That decision cost me plenty of time and energy, but I'd make that decision again today. I've looked at a lot of languages, and I've never seen anything half as good as python for expressing ideas clearly in code.
The main thing wrong with perl is that it's just not python. I honestly believe that if you want to be seriously productive as a programmer (or as a software company), you need a scripting language. The only question is: which one?
Those last three seem interesting, but I don't know enough about them to judge. PHP's great for the web, but not so great for general programming. Tcl's not meant for standalone use (but rather to be used in conjunction with C/C++, though people write standalone Tcl anyway). VBscript can't do anything useful without COM, and doesn't even have decent exception handling.
If the question is what to stake your business on, the real choice - at least today - is between perl and python. They're pretty evenly matched in terms of technology. There's not much you can do in one that you can't do in the other. The main differences are in the mentalities behind the languages, but that mentality can make a huge difference.
All other factors being pretty much equal, python's clean syntax and "no surprises" philosophy just makes more sense.