At first, I appreciated the cleverness of the technique, but then I saw red - perhaps I should have posted to the thread. I could imagine a work situation where somebody presented the one line file slurper at a code walkthrough; he would be told in no uncertain to change it as it needs to be understandable by any future person reading the code.
It requires a knowledge of localisation, input record separator, the magicality of @ARGV, and list assignment greediness. OK, no problem for most of us here at the Monastery, but could present a problem for coworkers.
I would put it more strongly than this, advocating such an idiom is dangerous, as it leads to cargo cult programming. Tightly packed idioms do have one application, and that is Golf. However, the Golf mentality can be harmful in the workplace, although it is impressive to colleagues to be able to achieve apparent miracles from the command line - there's no code that needs to be released through change management ;-).
I recall the 1970s days of home computers when everything had to fit into 8K. Although it was not called Golf, the practice of shoe-horning algorithms into the smallest number of source code bytes was widespread. There were also practices of stripping comments, and recoding in machine code - just to save a few bytes.
With Perl 6, the syntax is changing greatly, and most of the Golf will cease to work. This is the time to get rid of it. There will still be some applications for code that runs using the fewest machine cycles or sortest time - prize to the best benchmark. Anyone for Parrot Golf?
However, not all idioms are bad. My essential criterion is whether the idiom is readily understandable. An example of what I consider a good idiom is the Schwartzian Transform, which is beautiful.
In reply to Idioms considered harmful by rinceWind
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |