In English, it's much more efficient and common to say "can't" rather than "cannot" or "can not". Sure, it's redundant: you could have always used the longer form. But by permitting the contraction of "can't", you reward the more experienced English speaker with the savings of a bit of time and effort.

Similarly, foreach $_ (...) { ... } is semantically identical to foreach (...) {...} which is semantically identical to for (...) {...}. Sure, the latter are redundant in a pure sense, but they perform the "contraction" for the experienced Perl speaker.

So, it's best to learn the common "contractions". It saves time and typing for the expert, although it might slightly confuse a beginner. In fact, not using the contraction will likely confuse or call unduly attention for an expert, much like someone saying "can not" is when speaking English. An expert will wonder why the speaker didn't use "can't", because it sounds odd.

When I program in other languages, I miss Perl's contractions. Having only one (or two) ways to say something leaves me without a convenient short way to do something. I'm glad I have the opportunity to write mostly in Perl.

An expert will wonder why the speaker didn't use "can't", because it sounds odd.

Was the choice of example conscious? Because it is wonderful. It both describes the barrier to those new to the language, and the utility to those who know the "cant".

Right on. There's an amazing amount of natural language principles in Perl, including contractions and pronouns. I really enjoy reading Larry Wall's writing about Perl and the linguistic concepts he incorporated into the language, he has a great essay on his site about it: Natural Language Principles in Perl.

I definitely know that I miss Perlish idioms in other languages, and I'm certain that I'm not the only one. Other languages are learning though, Java recently added a foreach loop in Java 1.5. :)

Randal,
Your request for an example such as "will not" vs. "wont" prompted the following thoughts...

What about use warnings, carp, cluck, croak, and confess? This spans the reporting with more severe results starting with simple warning and ending with Die and backtrace (confess.)

You might relate these to should, shall, shant, will not, and wont.


SciDude
The first dog barks... all other dogs bark at the first dog.

Paul Graham once made the point that just having each line be simple isn't everything. There is no doubt that any given line of BASIC is much simplier than almost any given line of LISP. However, on the average, the BASIC program will be much, much longer to solve the same problem. He argues that the complexity of a program is:

effort per line * number of lines
[download]

So if we assume that the LISP program has an average line complexity of 10, and the BASIC program is at 1, then it seems to be that BASIC is a simplier language. But if the BASIC program is 100 time longer, than it's really a win for LISP.

He made a rather complelling argument that a paper on some advanced mathmatical topic may be so full of specific mathmatical language that it often takes the uninitiated hours to read a single paragraph. However, without that notation, the paper would be a hundred times longer than it is.

On another point, I tend to write my code so that portions that are likely to change are easy to change. For example, lets assume that you have an AoA that needs to go into an HTML::Template loop. Here is my idiomatic solution:

$tmpl->param(
    loop => [ map {{
        foo => $_->[0], 
        bar => $_->[1], 
        baz => $_->[2], 
    }} @AoA ]
);
[download]

The part likely to change here is the parameters being sent into the loop. As such, it's easy to change those. But look at the rest of the statement. To fully understand it, you have to realize that the first curly brace creates a block for the map statement, and the second curly creates a hashref. Plus, you need to know how to handle references in general, a concept that many new Perl programmers struggle with for a while (though IMHO, it's a critical step in learning Perl).

Really, it all comes down to how much Perl you know. It is only unreadable if you don't know the construct used.

map {{ PAIRS }} ...dwims the direction you said but not why you thought. If the contents of the two braces look like pairs or like statements this is used to decide whether the you just meant to introduce a block (for use with next/last/redo) or a hash. This is why map +{ }, ... is important because it looks more like a hash ref and does not involve dwimmery to decide that it is a hash. map {; ... } ... is the other dwim-free mode for running statements and returning lists (possibly of pairs).

As Larry says, Perl is optimized for ease of use, not ease of learning.

Using statement modifiers is not obfuscation just because someone who has no idea of Perl will have a harder time understanding it. You shouldn't have to cater to the lowest common denominator.

Brevity is a corollary of laziness, and makes code easier to read. If you pick your shortcuts wisely, you will reduce the amount of red tape and thus make it easier for a reader to discern what the code is truly concerned with.

Obfuscation begins when the code uses roundabout ways of expressing its function, instead of straightforwardly stating what it is doing, so that the reader has a harder time telling the intent of a piece of code.

Good code says exactly what it is doing, as briefly as possible, using the constructs that most closely match the way a human thinks of the algorithm.

That said, there is a fundamental tradeoff that I mentioned in Re (tilly) 2: To sub or not to sub, that is the question?:

Suppose that working with heavily factored and organized code is 5 times harder per page of code. Suppose that it does the work of 20 pages of unfactored and unorganized code. If you assume that the issue of tracking down the same bugs in unfactored code is similar to the issue of changes made for one reason affecting things all over the place, then that is a gain in productivity of a factor of 4. However whenever picking up that code I can guarantee you that you will feel that factor of 5 issue.

As a general rule of thumb, the more experienced the programmer that you're writing for, the more that you can expect of them. Pile things on beginners too fast, and they hit mental overload then balk. The same holds true for experts as well, but the expert has more generous limits.

UPDATE: Fixed broken link. Thanks, hardburn.

My simplistic thought-or-mantra on this is:

Not using shortening Perl idioms makes code easier to read for non-Perl people,
though using shortening perlish idioms introduces good Perl habits to all people...

Cheers, Sören

Yes, normal perl code can sometimes become unreadable for those who don't use perl regularly. But isn't it the same with other programming languages?

APL is infamously hard to read for outsiders, even more than perl. Lisp or Scheme code is reported to be difficult to read for those who're not used to it.

Even some bash code like

# bash functions for manipulating the path

shopt -s extglob

# addpath appends a directory to the path unless it is already there
# eg: addpath ~/bin
addpath(){
local a p=":$PATH:"; for a;
do case "$p" in (*:"${a%/}"?(/):*);; (*) p="$p$a:";; esac;
done; p="${p#:}"; PATH="${p%:}";
}

# delpath deletes a dir from the path
delpath(){
local a p=":$PATH:"; for a;
do a="${a%/}"; p=${p/:"${a}"?(\/):/:};
done; p="${p#:}"; PATH="${p%:}";
}

#END
[download]

Shell code of all varieties is difficult to read. With each OS having different flavors of all the same basic tools it can be really difficult to suss out (without reading reams of manual pages) what something does with all the various options. I hate shell code. Ack. Ptooey. Or .... I hate having to read other people's shell code written for their version of *NIX.

Shell code of all varieties is difficult to read.

Spoken like a man who has never supported SQR or read IRS instructions.

Shell syntax has its quirks, sure. It certainly isn't as powerful as perl or as "clean" as Java or as readable as Applescript. However, for when it was written it was quite an advance. Also, it beats the heck out of DCL on VMS, which is where I first learned to really program, so maybe I look on shell programming with more fondness than others do.

YMMV

--
tbone1, YAPS (Yet Another Perl Schlub)
And remember, if he succeeds, so what.
- Chick McGee

The Frontier between legibility and obfuscation is thin and light as a paper sheet, moving to the slightest whisper.

Perly English has its quirks

As any other (almost) etnic language. Here, you'll find from raw to very polished materials, from eridite masterpieces to slang swearwords...

for $element (@array) {
  print "$element\n";
}
[download]

print "$_\n" for @array;
[download]

It's a combination of having to mentally reverse it, and the use of $_ that makes it less legible. I always use a named variable instead of $_ when I can. It's better documentation.

I agree the example here isn't the greatest. For instance I would almost definately write that line as:

print join("\n",@array),"\n";
[download]

So a better example IMO would be something like:

$count{$_}++ foreach @element;
[download]

Which I would translate as a one liner to "increment the count for each element".

I also think its worth mentioning the 'with' use of for:

print $_*$_+2*$_+1 for $some->('complex')->{'lookup'}->[equation];
[download]

which IMO translates to "print n²+2n+1 with n equaling some complex lookup equation."



---
demerphq


First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi

As tilly suggests, it depends on your reader. If you're writing complex code that inexperienced programmers could never hope to understand, use complex Perl idioms.

Programmers tend to create simpler interfaces around complex code to perform common tasks. Complexity occurs in most systems: hiding it away makes systems accessible to more people, trading off power for accessibility.

If you like patterns, I find Christopher Alexander's intimacy gradient roughly analogous to this. Your code base has complex, private areas that few people need to interact with and simpler, public areas that interact with many more people. Your programming style can vary according to who the code is for.

It's all about context. I tend to write a function in a fashion such that similar code looks similar. For example, if a function starts with a bunch of checks and one doesn't "look right" with a single line ... if (...);, then I use if/unless (...) { ... } for all of them.

Another important piece of context is the importance of the piece of code. If the line is important, then I might choose if/unless (...) { ... } to make more visually impressive.

Contractions and shortcuts can add clarity, but they can be over done.

Just as with natural language, double negatives, complicated compound clauses, and large distances between the referred and the referrent -- or, as this interruption demonstrates, mid-sentence diversions, within long rambling sentences that try to do too much and thus don't do it well, compared to simpler structure -- can all serve to make a the reader of code or of prose work harder, and possibly make mistakes.

print "foo!" unless /\S/; # too many negatives 

if (grep {is_important{$_}} map {mangle{$_}} $obj->method; # too compl
+icated, too much span

{
 #begin brace1
  {
   #begin brace2
    {
     #begin brace3
     ...
     #begin brace-n

       # too much nesting!

# and so forth
[download]

Legibility is also affected by consistency. I'm doing some debugging on a code base that freely exchanges for ( i;i<@;i++ ) { }, for ( @ ) { }, blank for @, while ( i-- < @ ) { }, and foreaches. None of it is obfuscated but it's jarring to have the different cants (to build on shenme's contraction connection) thrown back and forth one after another. A single unusual style would be easier to get the mindset of and follow for debugging than all the common idioms in a soup.

My feeling in a nutshell, if code dosn't look ugly its 100% easier to understand.