3 ms·

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

by 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.

by ysavir 3y ago

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.