I love Hal and he was one of the first people I met in the Ruby community. I still don’t like the in proposal :). I’ll ignore him for another 10 years.
Jest aside, this is a nice writeup of the whole discussion around in in Ruby. Still, I think there is one thing missing: Ruby is a very stable language, syntax-wise. If you go 10-15 years back and see the concepts and syntax Java has gained (the “stable” language) over the concepts and syntax Ruby has gained, you will see how conservative Ruby is at that side. I was surprised that .? wasn’t denied on the grounds of introducing new syntax. This isn’t quite the case for libraries (the big encoding introduction was an issue), but if you learned Ruby 1.8 deep, you can implement many modern approaches to Ruby in that language, too.
 Fun fact: did you know that Ruby wasn’t considered a “duck-typing” language before Ruby 1.8?
 Just for the sake of comparison:
Java since 2001 introduced: Generics, Annotations, Autoboxing, Enumerations, varargs, for-each loops, static imports, lambda expressions, default methods (all with different syntax). These are only the big changes. Smaller syntax extensions like Coin ignored.
Ruby since 2001 introduced:
1.8.0: only small new syntax, most notably class Foo::Bar; end.
class Foo::Bar; end
1.9.1: Symbol hashes. String literals have an encoding, new constant and variable scoping that (mostly) can be considered a soundness fix
2.x.x: Keyword arguments, Strings are unicode by default. .? and (previously experimental) Refinements
Ruby also got refinements and prepend off the top of my head (pretty major, if seldom used).
The thing I like about this proposal is that it’s not a new keyword, and it’s actually quite a natural extension of ruby’s optimizing for developer happiness principle. I could see a lot of people adopting this feature.
Edit: whoops, I see you did mention symbol hash syntax! Removed from my list…
Edit2: wait, you’re editing your list! Hah, the timeline is getting crazy ;)
Ruby also got refinements and prepend off the top of my head (pretty major, if seldom used). Hash with symbol syntax, if that counts.
Oh, yes, forgot these two. Though, for refinements: they are pretty recent, actually a Ruby 2.2 feature (they were experimental before).
Still, in contrast to the Java introductions, that seems rather small. It’s mostly around the edges.
This isn’t criticism of Java, too. Java just follows a different discipline there.
Oh. “prepend” isn’t Syntax. And you were able to build the result of prepend code before.
It doesn’t feel so funny if you consider the ‘in’ operator to be awk-inspired. It could blend in with the rest of the awk that’s in ruby.
include? is backwards from mathematical usage – we ask whether a member is in a set (“epsilon”-like notation), not whether a set contains a memeber.
Actually, it’s fairly common to have both “x ∈ X” and “X ∋ x” depending on how you want to structure your English sentence (remember that mathematics is read out loud, in natural language, so the mathematical formulae are just shorthand for natural language).
x ∈ X
X ∋ x
Am I the only one who does not like operators so much? They introduce so much complexity, it is almost unbearable.
Also, design decisions based on notions of convenience and sugar belong to the weakest arguments one can make about code. I am sure most would agree that “convenience food” is among the worst kinds of foods, and sweeter is not equivalent to better. Alright, but enough of real-world analogies, I think there is a strong point to be made in favor of functions and methods
Functions (and methods) look the same in their definition and their application. This means that one can easily look up a function, either over an IDE or git grep. Mapping an in operator to a include? method requires learning that association by heart (and they will differ from language to language, Python’s __contains__ is the same). I once read a retrospective on C’s success, and the author gave some credit for the fact that C’s function definitions looked a lot like function calls and indeed pre-ANSI C function declarations are even closer resembling the function calls.
The author fails at properly refuting counterarguments (that being said, I very much like that these arguments are faithfully mentioned). I personally find if x.in? my_set to be an appropriate alternative to an in operator, and I cannot follow the # very ugly comment.
if x.in? my_set
# very ugly
The otherwise brilliant diagrams library of haskell is a great example how operators can make code impenetrable for inspection by a reader unfamiliar with the operator-idiom.