Is "this kind of code" worth it? It certainly is aesthetically pleasing and somewhat terse compared to a parenthesis jungle. But that does outweigh the fact non-experts don't know exactly what the statement is doing?
To anyone who learns the idiom, this code is fine, and perfectly readable. I don't even know Ruby yet, and it took me less than a minute to become fully comfortable with this kind of code. This isn't a huge barrier to "non-experts".
It's always easy to claim something is okay when you "don't even know [language] yet", isn't it? ;)
All joking aside, the problem with this is not that "non-experts" don't understand what the code does at all. It's that they don't understand all that it does. If you never read anything that warns you about the difference between "and/or" and "&&/||" (or if you skim over it), it can bite you really bad.
Of course it took under a minute, you were reading a nice blog post on the topic. The problem is not every instance of 'and' will include that information. And so I worry that if I drop 'and' into some minor glue script I write - it becomes less self documenting to my coworkers. It's a minor point, but it can become a slippery slope (see: perl)
This entire argument is moot. No one cares how obscure a language looks to someone who is not familiar with it. Do you regularly sit down and decide, “I am going to use a language I don't know to accomplish something essential and immediate?” And even if the answer is yes, then do you still not know the language at the end of that exercise?
This is a very simple, easily understandable and easily readable feature of Ruby. It's not obscure, complex, or even that unusual. Precedence is something every competent programmer needs to understand, and it should be part of every programmer's research to learn a new language. After all, this is a conversation about the existence of "and" & "or", not their abuse.
I used to be competent, but now I guess I avoid writing stuff that relies on any knowledge of operator precedence.
I try to learn what I can of such precedence in the language of the day, since I will have to maintain other people's "code" (cypher?), but I try to write obvious "programs" (who is in this play, what are the acts?).
I've been at this over 2 decades, and it's much easier to read something that uses a few parentheses, a well named intermediate variable or two, or even a few functions, than it is to read bunch of multiple operators on the same line gobble-de-gook. Watching somebody else generate a hundred thousand dollars of wasted product in a manufacturing preparation process a few years back, due to such a run-on if-statement being fouled up, was also a good confirmation of this bias. I'm sure my current job in finance offers similar opportunities for expensive blunders.
If by "non-experts" you mean "people who have hardly any familiarity with the language at all," then yes, I'm OK with people who don't know the language not understanding code written in that language.
I agree that we should not write code only for experts, but that doesn't mean we should take the absolute opposite approach and refuse to use case statements or blocks because somebody might read our code without bothering to learn the basics of the language.
The use case I'm thinking of is when I'm using my scripting language of choice to write some glue code and I want other people in the organization to be able to grok it easily. Perhaps Python is really the better choice for those tasks, but so often these days my choice of scripting language for task X depends on the state of libraries I plan on using. And ruby does have better libraries from many tasks.
I agree that if you're writing a medium to large technology stack, you should take it as an assumption only proficient users of the language will hack on it.
Finally, I disagree with your assertion that only people with "hardly any familiarity with the language at all" would not know the order of operation difference between && and 'and'. I think the popularity of this story on this site speaks to that.
"But that does outweigh the fact non-experts don't know exactly what the statement is doing?"
That thinking can cover a whole lot of code, and raises the question of what defines an expert?
Use the whole language; people become experts by experiencing new things.
The guidelines should be, can you yourself still read and understand it a month later, and do you find that a particular idiom tends to make bugs easier or harder to find.
Depends on what you call "this kind of code". Operators like "and" and "or" facilitate some very useful and expressive idioms, so having that kind syntactic constructs is rather useful.
However, I think it's a big mistake to make those constructs use "and" and "or", because it overloads the semantics normally associated with those keywords. Yes, it's true that it's precisely the same logic under the hood, but you have to fight the "oh, boy, that's so neat!" reflex and think about all that could go wrong.
There's a similar gotcha in Python, where instead of ternary operator (a ? b : c) you use a combination of "and" and "or" (a and b or c). The gotcha is that it backfires if "b" evaluates to false.
All in all, it's probably not "worth it" to have nasty surprises like that, but that could be avoided by using different keywords, not "and" and "or".
I just want to briefly mention that I am only on the third chapter of the Poignant Guide, hardly what you'd call an expert, and I already understand completely what is going on in the top comment's example. I know why. But maybe that's because it acts pretty much like Python with anonymous functions in this case.
And no, I haven't read the original post yet. I was doing a skim-the-comments-before-reading run,
