4 ms·

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 thi

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?

tenderlove 3y ago
I didn't know it was controversial either! D:
- ecshafer 3y ago
  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.
  - tenderlove 3y ago
    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
JohnBooty 3y ago
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%5Eactiverecord%5C%2F%2F+method_missing&type=code https://github.com/search?q=repo%3Arails%2Frails+path%3A%2F%...
- stevebmark 3y ago
  I guess you haven't read Eloquent Ruby!
  - throwanem 3y ago
    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.
    - freedomben 3y ago
      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.
      - throwanem 3y ago
        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.
        stevebmark 3y ago
        Now you have your recent advocacy, which is common in the Ruby community. Embrace magic, embrace indirection.
        3y ago
zverok 3y ago
(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_rubocopdisable_syntax_rubocop/ https://www.reddit.com/r/ruby/comments/16slc10/announcing_ru...
- ezekg 3y ago
  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.
- stevebmark 3y ago
  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.
- KingLancelot 3y ago
  [dead]
ysavir 3y ago
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.
- karmakaze 3y ago
  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.
- freedomben 3y ago
  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.
  - ysavir 3y ago
    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.

tenderlove 3y ago

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

ecshafer 3y ago
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.
- tenderlove 3y ago
  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

JohnBooty 3y ago

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%5Eactiverecord%5C%2F%2F+method_missing&type=code https://github.com/search?q=repo%3Arails%2Frails+path%3A%2F%...

stevebmark 3y ago
I guess you haven't read Eloquent Ruby!
- throwanem 3y ago
  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.
  - freedomben 3y ago
    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.
    - throwanem 3y ago
      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.
      - stevebmark 3y ago
        Now you have your recent advocacy, which is common in the Ruby community. Embrace magic, embrace indirection.
      - 3y ago

zverok 3y ago

(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_rubocopdisable_syntax_rubocop/ https://www.reddit.com/r/ruby/comments/16slc10/announcing_ru...

ezekg 3y ago
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.
stevebmark 3y ago
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.
KingLancelot 3y ago
[dead]

ysavir 3y ago

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.

karmakaze 3y ago
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.
freedomben 3y ago
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.
- ysavir 3y ago
  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.