Hacker News Reader

Comment by stevebmark | Hacker News Reader

Pattern matching is an objectively good language feature. I wasn't aware the Ruby community sees it as controversial. Why does the Ruby ecosystem do so many things backwards compared to modern software engineering? Pattern matching bad, method_missing good?

View on HN

(Author here)

Well, unfortunately a lot of new stuff becomes controversial on the pure ground of "no new language changes! it is good enough for me!"

TBH, I thought about a post series like this for a long time, but the last trigger was an announce of a special Rubocop addon to "disable useless syntax sugar"[1], and pattern matching was one of the "useless sugars" in the list. So I felt I need to cover it, too. And in the end of the day, I think it is an interesting excercise to analyse it in the same way as other, less significant and more controversial, features (the most intresting stuff would be in the second part, though).

1: https://www.reddit.com/r/ruby/comments/16slc10/announcing_ru...

I wasn't aware of that new cop. Anecdotally, find Rubocop (and Flog and Reek) to be backwards tools. To me, they pattern match (ha) as the same core problems with the Ruby ecosystem. Ignore best practices that other language ecosystems have evolved, and embrace what other languages agree are bad practice.

I'm glad I missed that r/ruby thread. I wouldn't have been very nice. I honestly can't tell if it's a troll or not. I love all of those features of Ruby, and use them daily.

Ruby is generally an object-oriented language, at least in practice if not by design, and pattern matching goes against the object-oriented grain (in my opinion, at least-would love to hear others).

The object oriented approach isn't to try and extract conclusions on a data structure so that we may utilize it correctly, but instead to use an object with a interface we can interact with regardless of the organization of the data. Neither approach is a right or wrong way to program, but culturally Ruby leans towards the object oriented mentality.

I think you're onto what might be biggest internal struggle that I've noticed since starting in Ruby in 2011: The tension between object oriented and functional. In many ways the two are not in conflict, but occasionaly they do clash, and that's where things get messy. As someone who loves the functional approach, it saddens me when object-oriented ways get in the way of a great functional feature or pattern, but at the end of the day Ruby is thoroughly an object oriented system. IMHO it should err on the side of object oriented. For people that really want functional, it's probably better to look at a language like Elixir that is inspired greatly by Ruby but functional from the start.

If it helps at all, keep in mind that many people who think they're doing object-oriented ruby are actually doing functional programming. Take a look at the Service Object pattern--A globally accessible reference with a singular method class (`.call`) that takes arguments and returns a singular value, and without you ever interacting with an instance of the class, etc etc. This is just a function in disguise! Every true service object could be reimplemented as a proc without the rest of the codebase knowing anything changed.

Writing Object Oriented code is hard. If you don't have a solid understanding of SOLID, at best you end up reinventing functional programming, at worst you end up with a big plate of spaghetti code. That's why most ruby codebases are a huge mess. It's still my preferred approach, but it's certainly not for everyone, and it's certainly easy to muck up. Thankfully Ruby is flexible and allows both--people just need to be honest about what they're actually doing, and not present any implementation of Ruby as object oriented.

The way 'syntax' is implemented in much of Ruby isn't processed by a separate parser, but rather is interpreted during execution of the source to create the objects/classes or modify them to do what is desired by the language feature. Thinking of things this way, it becomes more clear that it's not using the OOP features to get things done but rather mangling them to make pretty DSLs. I would object to too much of that too--except that in this case, I really like pattern matching.

    Pattern matching bad, method_missing good?

`method_missing` hasn't been considered good practice in a very long time. i mean, most people never thought it was great, but it's a non-issue IME

there are only a few usages of it remaining in activerecord. i thought they were all gone, honestly. (keep in mind about 1/2 of these are tests)

https://github.com/search?q=repo%3Arails%2Frails+path%3A%2F%...

I guess you haven't read Eloquent Ruby!

The book from twelve years ago?

I carry no brief for Ruby, and method_missing (and its extensive abuse in early Rails) is a major reason why. If you can find no more recent advocacy for that pattern than this, maybe it's time I took another look at the language in earnest.

I actually love method_missing. I don't think it should be used for the vast majority of use cases, and most ruby devs shouldn't even know it exists, but the power to reach deeply into things and tap sources is one of the things that makes Ruby amazing IMHO.

Oh, I'm not averse to reflection in general! It can be very elegant and still easily understandable when well used, ideally at compile time. No, it's just that this particular example was once egregiously overused, with an excess of cleverness aforethought that made debugging anything far more difficult than it really had any need to be.

It's not even that I can't see how the Rails implementors got there; on the one hand it was very early in the development of the modern web concept and nobody really knew what worked and what didn't yet, and on the other, a more modern pattern would have probably been very slow anyway in those days. Still, the experience left a bad taste that I've found hard to shake.

Ruby is really good as a language these days, and has only gotten more performant.

Rubocop has gotten wide adoption and has standardized a lot of good practices. By default it's awfully strict.

I worked full-time with Ruby for 9 years across several companies and I solemnly swear that I never saw a single person use method_missing or consider it as anything other than a mostly terrible idea.

Never saw it used once, or even considered once, in actual application code.

Generally that was the case with any of those "sharp knives" or "potential footgun" language features. Monkey patching is another good example. Used to be extremely common and even recommended, but now it is extremely frowned-upon and used only with extreme care/desperation in application code.

The "problem" with Ruby is that it has become kind of a monoculture around Rails. Rare to see it used for anything but Rails these days. People who want a fun casual language are using Python because Python has that booming ML-adjacent ecosystem and a strong foothold in academia/science.

Now you have your recent advocacy, which is common in the Ruby community. Embrace magic, embrace indirection.

I didn't know it was controversial either! D:

I also work at the small mom and pop e-commerce site, and i havent seen it being considered controversial anywhere. And once people see its benefits i think theve been picking it up. Just this week we had a PR that it serioisly reduced the code by 30%

Awesome talk at rails world btw.

Thank you!

Ya, I really enjoy pattern matching. I think new language features just take a long time to percolate through the community. I remember when `->` was controversial, but that's the only way I write lambdas today. :D

Reply on news.ycombinator.com