In my experience, the Ruby culture doesn't prize cleverness over consistency. Instead, it leaves responsibility up to the developer. You can do convoluted things like 7, 8, and 15, but you don't have to (and few people do). Really, any language lets you write ugly code, and good developers will strive for clarity.
As an example, you can use Perl-style magic variables in Ruby ($!, $_). But in three years writing Ruby code professionally, I think I've only seen one of these ever used, and only rarely.
IMO metaprogramming is a bigger potential problem than Symbol#to_proc or perlisms. You can override the + operator globally with Ruby, or do any other number of stupid things. But metaprogramming also offers a ton of power (similar to Lisp macros?).
This is purely my personal experience, mind, but I have observed that Ruby users tend to be younger and webbier and employed mainly to code, and Python users tend to be older and employed to do other things, of which coding is a subset. This explains the cultural differences; Python users have been burnt before by unmaintainable codebases and are determined not to make the same mistake twice. Also, as Python users (again, in my experience) tend not to be primarily programmers, they aren't impressed by clever coding tricks.
Very true, however Ruby is still very much growing in popularity and growing as a language. Therefore, if you employ a "little-known trick" and somehow it becomes popular, it is no longer little-known and it becomes a "standard idiom."
This is not automatic, but I suggest the possibility is much greater with Ruby than with certain other languages for various reasons, and therefore it is at least worth considering a new idiom in Ruby rather than rejecting it outright.
One of the ways you can make your favourite idiom popular is to blog about it, of course. Or perhaps to write something really popular and use your idiom in it, such as returning() {...} or perhaps Symbol#to_proc.
But #16 is a good one — I like one liners but after reading I looked through the code base in one of my projects and sure enough, explicit true/false was spelled out in methods returning booleans...
I agree with you that many of these shortcuts are obnoxiously read-only, but that was probably the worst example you could have picked. That notation is nicer than Python's standard ", ".join(["foo", "bar", "baz"])
I love Ruby for it's expressiveness even more so than Python. But the author's code examples tend to make me hesitate for the reasons that bad Perl code makes my eyes fall out.
But the author's code examples tend to make me hesitate for the reasons that bad Perl code makes my eyes fall out.
It's nice to read the article for that reason. Hopefully people will realize that you can write horrifyingly bad code in any language. I'm looking forward to the Python edition ;)
Maybe we can start approaching language design rationally when people start realizing that all languages suck big time. Even Ruby. Even Lisp.
By "worst example", I meant that I thought it was a poor example of your point, because the notation you quoted is okay. A lot of the other ones were worse code (and better examples of your point).
It's a common operation. You should see how many people have to code it/get it wrong in topcoder. So it overloads * -- how often are you going to multiply a string?
We have different opinions on what's important in a language. I want something that's as fast to write as prose, so that my mind can focus on other things in the problem domain. This may mean that my code is rather unreadable to people used to coding in specific idioms. But functionality is commented at a higher level, so then what are they doing reading individual statements from my code anyway?
This means that, sometimes, I find myself in opposition to the python community for its goals of readability and regularity, but it's a powerful language chalk full of good ideas and one of the most important tribes on the net, so I still use it.
Because multiplication has a tenuous relationship with Array#join, because Array#join shares none of the "other" mathematical properties of multiplication, because :* is overloaded in other, conflicting ways for other object types, and because the resulting code is needlessly terse and no easier to read as a result of this hack.
A culture that prizes cleverness over consistency is an evolutionary dead-end, this transcends the merits of the technology.