Idioms are constructs that are typically used for a certain task. Good examples of idioms are the constructs to iterate over an array:

    /* C idiom */
    for (i = 0; i < arr_length; i ++) {
        printf ("%d\n", arr [i]);
    }
 
    # Perl idiom
    foreach (@arr) {
        print "$_\d";
    }
[download]

Having one way of doing things (whether that's because of the way the language is designed, conventions or company policies) does have its merits. Company coding standards aren't there for the sole purpose of annoying people (although they can be annoying ;-)), Python has its share of followers, and even in the Perl community you hear too often "you shall do it this way".

That of course doesn't mean I don't like the many ways of doing things in Perl.

Abigail

In The C Programming Language there is a discussion on how to write a strcpy() function. After several iterations the code is reduced to the following:

    while (*s++ = *t++)
        ;
[download]

Although this may seem cryptic at first sight, the notational convenience is considerable, and the idiom should be mastered, because you will see it frequently in C programs.

Idioms in natural language and programming languages are just well known concise ways of saying something. Just because something is concise doesn't make it an idiom. For something to become idiomatic it must be useful enough to pass into common usage. As such it is unlikely that an idiom could be considered harmful.

I'd agree however, that Golf is best avoided in production code.

--
John.

Ironically that book is full of lots of examples of how to not write C. Try that trick strings that might overlap and you can wipe out half your data. Even if you think that it is safe, is having to worry worthwhile?

The standard library strcpy() doesn't handle the case where strings overlap either. Or at least it's behaviour is undefined.

--
John.

"...considered harmful" considered harmful.

So, your guys wouldn't understand local, $/, or list assignment greediness, but would understand anonymous arrays, arraypointer dereferencing, chained maps?

Would they also understand when not to use a ST?

5 out of 6 times (example) when the ST has been advocated here as a solution recently, I've benchmarked it versus the simple sort version, the simple version has been quicker. This isn't a case of micro-optomisations either as the sole purpose of the ST is to speed up the the process. The ST is great, but like any idiom, it needs to be understood and applied with knowledge.

While I can see your point, it does raise the question of where you want to draw the line; I've been questioned over the last week on the use of:

• (?:
• qw
• qr
• eval { }
• map { } grep { }

So, we really need to distinguish between expected and unexpected idioms. And that's going to be a hard line to draw...

--
Tommy
Too stupid to live.
Too stubborn to die.

map { MAPCLAUSE } grep { GREPLCAUSE }
[download]

Can be rewritten as:

map { GREPCLAUSE ? MAPCLAUSE : () }
[download]

For instance, if you want a list of the squares of the first five odd numbers, either of these will work.

@odds_squared = map { $_**2 } grep { $_%2 } 1..10;
@odds_squared = map { $_%2 ? $_**2 : () } 1..10;

Result: 1 9 25 49 81
[download]

-Blake

Well, language features that involve a keyword are easy to look up in the reference manual.

A combination of features used a certain way is harder to "look up" anywhere, and requires a human mentor.

On the condition that warnings and errors are properly reported, I don't see any obvious trouble for maintainers.

To clarify, let's say I see the line of code I don't understand, which is commented with "slurp in file" and I recognise a filename being used there. Now either the code "just works", or it breaks with a proper error mesage ("no such file at line 123").

In the first case I might get interested in why this works and learn something (mind you!), or just take the working for granted.

If there is a failure, I have a clear signal where to go looking: "No such file" still means that I have to trace the file and path names, rather than debugging the "slurp" line.

The bottom line: in my opinion there is a blurred line between knowing what goes on and just using "an idiom" - honestly, which Perl user is fully aware of the C-level system calls underlying Perl's open() builtin? And do we need to know?

--
Cheers, Joe

Not only that, but using read is faster!

Well, suppose it is, or something is. If the self-documenting-name function was used, then it could be changed in one place.

Which, incidentally, illustrates tye's point: the croak "$filename: $!" used in that node is a less complete error message than the diamond operator produces..

Makeshifts last the longest.

The mere existance of variable "shortcuts" such as $/ and the like enables a whole host of one-liners, especially when coupled with $_, @ARGV and <> - almost certainly at the expense of code readability.

I think care needs to be taken whereever idioms are used - especially with code that others are going to have to maintain - the same care that should be taken when writing any code to ensure that it's readily understandable.

Future maintenance is the key - if it's not clear what it does, it's not going to be easy to maintain, in my opinion.

--Foxcub

What do you mean by the word idiom? It seems that you're assigning it a meaning more akin to obfuscation. In common use, it is instead an expression, common or syntacticallly common to a language or speaker group, often difficult to understand divorced from the specific context.

I think it would be fair to say that programming *without* Perl idioms leads to far less maintainable code.

Last year I wrote and presented local Student ACM chapter on Generic/Idiomatic Programming. The core issue was of future mantainablity. I wrote it because I needed a way to show others that Generic Programming is bad.

A Generic program is one that is syntactily simple enough that with only very slight changes could run in any language.

The Generic programs were long and cumbersome and as a result obsured the task at hand. They would unravel idioms to equivalent code that would be syntactily "easy" to maintain.

I have seen 3 to 1 differences in line counts between Generic programs and good Idomatic programs. No one will say its easier to maintain programs that are that much longer.

With the right level of idomatic programing the code does its job and lets the real solution show through.

From from my experience Generic programming is favored by those who work in mulitple languages on a regular(even daily) basis and are trying to avoid idioms that do not port well. This is done to avoid coding themselves in to a cornor by anticipating a particular idiom.

Disclaimer

1. local;
2. the input record seperator, $/;
3. ARGV magic;
4. list assignment greediness.

FWIW, I think that's a useful list. It could even be seen as a succinct analysis of how the idiom works. It made me appreciate how much Perl I have learned over the past year.

I knew all of the items except for no. 3, the ARGV magic, which Aristotle pointed out to me, and which I then went off and learned about in perlop (section: "I/O Operator"). I have started using the idiom in my own production code (which is not subject to a code review, except by myself).

I do appreciate your point of view, nonetheless I think it goes too far.

Your point about coworkers really is very subjective. It doesn't say anything about how valid the idiom is *as an idiom*. But that's the whole point, I think, idioms are subjective. And as others have mentioned already, it will always be near impossible to draw a line or boundary for something subjective like this.

Yes the corporate/coding_standard reaction to this will often be to just ban it, but that doesn't make it right. Tomorrow they could be banning <> or $_ as well.

As a sidenote, I always use the diamond operator magic in commandline tools. It has significant advantages: considering the scripts are usually short, getting all I/O dealt with in a single while(<>) is really convenient, and it deals with any number of files without me having to write an extra loop over @ARGV. I also have these scripts write any actual output to STDOUT and errors or other messages strictly to STDERR, so that the user can redirect or pipe the result (or just let it print to screen) at their convenience. And because these handles are given, I don't need to deal with opening output files either. Also since the diamond operator peeks at @ARGV at the time it is invoked, I can munge any commandline parameters with Getopt::* beforehand, and it works out beautifully.

Bottom line, I can have my cake and eat it too: a lot less code, and consequently work, but maximum flexibility. Perl rocks that way.

Makeshifts last the longest.

For me what is important is what is explained. I love strumbling upon some advanced technique that I've never seen before (but please, in production code could you throw me a bone and add a comment?).

()-()
 \"/
  `                                                     

Other people reading your code and finding it difficult to read should not run screaming to you and complain about unreadable code. Instead, I think that they should ask you if the technique you used is a common idiom in Perl. If yes, they should master the idiom themselves and possibly teach others too. Mind you, bad code is bad code, but there are many short, fast and elegant Perl solutions which are not immediately obvious, but on closer inspection, are very valuable things to know.

Python, which is praised as an easy-to-read language, has a number of idioms. I'd be hard-pressed to believe that someone's first encounter with, for example, list comprehensions is going to be more successful than the Schwartzian Transform (Ok, maybe that's a little strong, but I'm sure you get my point :-).

I think that being a good programmer requires you to keep an open mind about things you don't know. Crying "I can't read this!" when a little more investigation shows that it's a very elegant solution is not my idea of keeping an open mind.

--
All that is gold does not glitter...

At my company, we have knowledge engineers and software engineers. The knowledge engineer do their job in Perl or Lisp and produce code that gets ported to C/C++ by the software engineers.

There are several reasons for this setup, but the upshot is that the knowledge engineers can do their work quickly and efficiently, while the software engineers take care of speed issues, stability and maintenance, each concentrating on what he's best at.

However, the price to pay for me is that I have to refrain from using Perl to the extreme, in the sense that I can't use idioms that are too hard to translate to other programming languages, e.g. C/C++

This might be the point to draw the line for those who ever want to get their code ported (as well as those who'll have their code ported, willingly or otherwise).

map is easy to translate, grep a little harder, but a file slurp?

Just my US$0.02...

        -gjb-

A little of topic, but...

In C/C++ you do a file slurp with a open/mmap system call, and assign the resulting pointer to a collection object of your choice(char*,vector<whatever> or string). In fact, if your c++ programmers are any good, they should be able to handle most of the perl code you can throw at them, at least the idioms, without much problem. Doing it in C on the other hand....

Closeures are doable in C++, but its ugly and I believe it can't do everything(Could be wrong on that). Regexps can be a pain if they don't use a proper regexp library. Be careful with reblessing references into other classes, or dynamically changing @ISA(I cant think of any idioms that actually do that....).

just my 0.2 kroner

goldclaw

1. A speech form or an expression of a given language that is peculiar to itself grammatically or cannot be understood from the individual meanings of its elements, as in keep tabs on.
2. The specific grammatical, syntactic, and structural character of a given language.
3. Regional speech or dialect.
4. 1. A specialized vocabulary used by a group of people; jargon: legal idiom.
   2. A style or manner of expression peculiar to a given people: “Also important is the uneasiness I've always felt at cutting myself off from my idiom, the American habits of speech and jest and reaction, all of them entirely different from the local variety” (S.J. Perelman).
5. A style of artistic expression characteristic of a particular individual, school, period, or medium: the idiom of the French impressionists; the punk rock idiom.

sense 1. seems like it could apply to code that is difficult to understand but in fact it cannot apply: the meaning and action of any piece of perl code is always able to be discerned from the individual elements (if one understands those elements thoroughly enough)- take a look at Re: camel code (SPOILERS!) for an example :) If it can be run by perl (the program) then it can be understood. I am not saying it is OK to write production code that is unclear or obfuscated, just that the word "idiomatic" is the wrong word to describe such code.

sense 2. As Abigail-II pointed out this is what is usually meant by idiom when discussing programming languages. I used to occaisionly resort to wrapping perl 1 line filters in shell code because I didn't have the perl in-place edit idiom in my tool kit. I have seen quite a bit of perl code which I have been able to say (with some accuracy) if the coder was a shell or C or "other" programmer. If you are not using Perl idioms then what language are you programming in?

senses 3-5 don't really apply to programming.

I'm not sure what the connection between idiomatic perl and cargo cult programming is supposed to be. The idiomatic perl solution would generally be a briefer and more concise version of the non-idiomatic version, which is opposite to the cargo cult method of "ritually including code which serves no real purpose". I ritually include cgi.pm in my cgi scripts (without attempting to understand cgi.pm), that is not cargo cult programming because cgi.pm serves a purpose and there are good reasons why it is better than other solutions.

Does obfuscation belong in production code? Definately not. Where is the line between obfuscation and a language idiom? I'm not entirely sure :) If in any doubt comment or re-code clearer.

--
Life is a tale told by an idiot -- full of sound and fury, signifying nothing. William Shakespeare, Macbeth

It took me embarrasingly long to figure out what you were saying. A huge ++!

Makeshifts last the longest.

Plus, I did not feel that the issue of comprehensibility by the hoi polloi had been covered. I was interested in this because I find myself regularly having to debate the Java versus Perl argument, see Perl advocacy, CGI/ModPerl vs ASP/JSP.

For career reasons, I'm learning Java by the way, and I miss the intellectual freedom of TIMTOWDI.