[danso]

> When I first started learning Ruby, I was excited to discover that Ruby has the keywords and and or as boolean operators. I quickly got into the habit of writing all of my boolean statements with these, instead of the more conventional && and ||, because my code became so much readable

     pry(main)> a = true && false
     
     pry(main)> a = true and false

Hmm...I dunno, I don't think the latter is necessarily easier to read than the former. The use of the symbols helps, for me at least, to delineate between value/variables and operators. Those symbols aren't pretty but their ugliness can serve a purpose.

I don't mind using them in SQL, but only because SQL is case-insensitive and I can stick to the style of making all syntax uppercase.

[lmm]

I dislike using symbols, I think because they draw a mostly-arbitrary line between operators and method calls. As a scala/python fan I like to blur that line, and write code that reads as close to English as possible, so I'd write expressions like

    (user isActive) and (user.expiry before now)

and I think that really is more readable than '&&', in a way that your example obscures because you're still using '>' and 'false'.

[tikhonj]

In a well-designed, flexible language (which includes Scala), operators are not a special case. In fact, in Scala, they are just methods, so there's no arbitrary line between the two!

I personally like the Haskell/OCaml approach of having operators just be normal functions that happen to be parsed in infix position. It's simple, elegant, uniform and flexible.

Either way, the core idea is that operators should be nothing special.

[kyllo]

And Lisp takes this idea one step further by having operators just be normal functions that are in the prefix position like normal functions. This, combined with the explicit parentheses to denote evaluation, mean that operator precedence is not even an issue in Lisp.

[lmm]

Yes, that's exactly my point. You wouldn't use symbols for the names of normal functions (at least I hope you wouldn't).

[tinco]

This article isn't about replacing symbols with words, ruby isn't about replacing symbols with words either, and there is no place in the article where the author states that

    a = true and false

is prettier than

    a = true && false

And if you would actually have read the article and paid close attention you would have learned that the two lines you just said are not functionally equivalent.

No ruby programmer would ever have a line that says

    a = true and false

It just makes no sense.

Maybe a very experienced ninja ruby programmer would, but that programmer would know exactly what he was doing.

The beauty in ruby and in the 'and' keyword is that a ruby programmer intuitively knows when to use which. This article just clears up why exactly they work like you expect them to work.

edit: maybe a weird programmer would do something like this

  @message = "We failed :(" and false

at the end of a function that has conditionals with return statements in them.

[tikhonj]

If by "no place" you mean "first paragraph", you're right:

> I quickly got into the habit of writing all of my boolean statements with these, instead of the more conventional && and ||, because my code became so much readable.

And I definitely agree with danso and disagree with the blog on this issue: the operators gives more structure to the code and makes it much easier to parse at a glance. With the 'and' version, I have to actually read the code to figure out what its doing; with the '&&' version, I can get the basic idea just from the code's "shape" (for lack of a better word).

I think being able to quickly grasp the idea at a glance is far more important than having code look like English.

[EvilTerran]

there is no place in the article where the author states that a = true and false is prettier than a = true && false

Something like this, you mean?

I was excited to discover that Ruby has the keywords and and or as boolean operators. I quickly got into the habit of writing all of my boolean statements with these, instead of the more conventional && and ||, because my code became so much readable

If you would actually have read the article (or even just the comment you replied to) and paid close attention you would have learned that it said precisely that.

[danso]

Wow, I must have missed the point. Because I could've sworn the OP was talking about how he thought that 'and' and 'or' could be stand-in's for && and ||, but he found out that they aren't quite equivalent. Because if they were equivalent, he would substitute words for symbols because, as I quoted, "[his] code became so much readable."

I'm not evaluating what he discovered at the end of the post. I'm evaluating his original intent for using 'and' and 'or' in the first place, which was readability. I'm simply stating my opinion on that comparison.

And yes, "a = true and false" doesn't make sense. I just copy-pasted his sample code as a quick example. I didn't expect people to take it literally, as if I were showing off a best practice.

[tinco]

Hmm you're absolutely right. I guess I'm projecting, I just read that as using `and` and `or` in places that seemed logical to him, but the paragraph is quite clear in that he just replaced all instances of the symbols with the words.

Since that is the case, I fully agree with you and shouldn't have been so snarky. I apologize :(

[danso]

Well, it's a Friday afternoon :) You were right I didn't read to the very end (I kind of guessed what the OP was going to conclude)...I was mostly interested in seeing of other people thought 'and' and 'or' were good Ruby idioms to use (ignoring the precedence confusion).