I've had to maintain code with large doses of lots of closures. Once you know the basic ideas, it is no harder than any other code.

I would draw a parallel to OO programming. If you sit someone down who doesn't understand OO and have them try to learn a large OO system, they'll be lost. Just working out the basic mechanics of where to find the method that gets called HERE (and having an idea of when it matters and when it doesn't) is going to constantly stump them. The fault is not, of course, necessarily with the OO code or design. It is that the programmer in question is lacking the mental toolbox that you need to understand OO code. (Of course it is also possible that the code and design are both terrible.)

Practical techniques that use closures are similar. When you understand, "Oh, he's building up a dispatch table" or "Oh, he's creating an iterator" then suddenly the technique scales and it isn't a problem. Of course, as with any technique, it is possible to create a real mess with closures. But it is also likely that clean code using closures will look like a mess to someone who lacks the right mental toolbox to deal with them.

Note that in both examples what is key is chunking, being able to understand what a block of code is doing so that you can know during maintainance whether you need to dig further there or look elsewhere.

I'd say the biggest problem with using closures is that the number of people who fully understand them and can comfortably deal with code using closures is very small -- even smaller than the number who can comfortably deal with OO code. If you spend time on #perl or certain PM threads, it seems like everyone knows this stuff, but in reality it raises the bar quite a bit. You may have a hard time finding a module maintainer or an employee who can deal with closure-heavy code. I say this after having plenty of trouble trying to hire people who can deal with what I consider basic OO code.

I'm not saying there are no good uses for closures, but they aren't something I'd use frequently.

My solution to that is simple, I just work with people that you recommend. ;-)

Things like map/grep tricks (Schwartzian transform, for example), lots of use of $_, typeglob manipulation, hash-slices, chaining lots of things with and/or constructs, using lots of closures...

To a Fortran IV programmer used to the 'if not ... goto ...' school of language design, 'if .. then ... else ...' could be viewed as a "trick".

At what point does a standard design feature of a language (Perl) cease to be a "trick" and start to be a feature; a normal , everyday use of the language?

In short, things that are fine in small doses but get hard to read very quickly.

I don't understand this. How does frequency of use affect the readability of a construct?

Do comments become less readable if I use too many of them?

Is this a serious question? A long chain of map {} grep {} sort {} stuff that shoves multiple operations on one line and uses $_ left and right is obviously harder to read than an occasional map {} here and there. I don't know if it's an official term but I sometimes call this code density.

It is a serious question. You would find 467617 easier to read and maintain to 467637?

To me, the nice thing about VHL languages is that you can encapsulate a single notion into a single line. What you call "multiple operations" I see as composite parts of a single high level operation.

When I see a Swartzian Transform, I think, "Ah! he's sorting the data". For the purposes of overview, I don't need to know how he is ordering the data, much less the mechanics of how he achives that ordering. Sorting is just a single step in the overall algorithm. Breaking that step up into several separate substeps, each with intermediate temporary storage only serves to confuse and conceal the overall algorithm.

Once I understand the overall algorithm I may need to investigate the sort to ensure that it is being done correctly and or modify it to meet new requirements. The 3 steps of the ST are well defined:

• Isolate the keys from the rest of the data items.
• Compare the keys in order of precedence.
• Retrieve the whole data items in sorted order.

  You can acheive a similar encapsulation using subroutines as exemplified by Sort::Key, but then you end up with 25+ subroutines each with a slight variations on the name. That kind of namespace explosion is my major bugbear with hierarchal libraries (and to a degree with functional languages). It requires you to memorise or look up the names, function and parameters each time you need to do something, and worse, when trying to read or maintain someone else's code.

  Better I think to have a core set of powerful, flexible polymorphic functions that can be combined in obvious way to construct the myriad variations you need. Once you understand and recognise those core constructs, you spend less time looking things up and reading what and how they work and more time understanding what the code author is (trying) to do.

  I think!

  ---

  Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

  Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

  "Science is about questioning the status quo. Questioning authority".

  The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.

You keep mentioning over-use of $_ as a problem but I have to confess, I don't remember any time I was particurally stumped by the usage of $_ in an expression. Do you have any examples of complicated expressions where using $_ makes them harder to understand?

Density is good (obfu is not, of course). What is it that mathematicians say? Something like, "One page of symbols and formula is better than 100 pages of text". Of course, a chain of a few map,grep,sort is nothing compared to J Incunabulum

...things that are fine in small doses but get hard to read very quickly. Writing things out in a less compact way is usually seen as more Java/C-like