IMHO, the sweet spot in point-free programmating is for short chains of write-once functions. (fun x -> ...) has some syntactic clutter including a level of parens, and if the "..." isn't very complicated there may be a net gain for readability even if there's a tiny loss of performance. According to HaskelWiki ([link:www.haskell.org] "Point-free style often times leads to code which is difficult to modify. A function written in a pointfree style may have to be radically changed to make minor changes in functionality." So you should not view pointfree programming as an investment in refactorability, and in fact the opposite may be true.

IMHO, the example you give is right at the boundary where point-free and lambda syntaxes are equivalently complex. For anything more complex, like "(n + 1) % 3 = 0", I'd say go lambda, but the point-free version as-is is readable enough.

-Max

P.S. Of course, as you get more complicated you'll want to abandon even lambda syntax for the clarity of named functions with explicit arguments and maybe type annotations.

I know that for something like APL the epithet "write once" is pretty true.

I use several programming systems from time to time and find that sometimes I avoid systems that have too many "magic symbols/magic constructs". It can make reading them more effort than it's worth. (For example many systems use $...)

Where it's up to me I use naming/constructs that I can come back and just read. This makes me more productive.

(I have reluctantly scaled back my use of languages, that though powerful are cryptic to me. One of the biggest problems is not reading your own code (which you can often make readable despite the language) but reading other people's.)

(It wasn't clear to me whether this is exactly the point of the original post.)