Pattern Matching in Ruby 2.7 (2019)
speakerdeck.com
Pattern Matching in Ruby 2.7 (2019)
1–10 of 110 posts
Re: Pattern Matching in Ruby 2.7 (2019)
#2Is it just me or does the syntax seem very confusing? Compared to other languages with pattern matching (ex OCaml) it seems a little clunky. I'm not familiar with Ruby though, does this syntax mesh with the rest of the language though?
Re: Pattern Matching in Ruby 2.7 (2019)
#3I personally love pattern matching (one of the best features of Elixir and Erlang for my taste) and would be screaming in enjoyment if something similar would be introduced to Ruby but I'm kind of meh about the whole ordeal.
This is experimental. Even when we upgrade production systems to 2.7 I'm still going to refute usage of pattern matching in the code (and it still boggles my mind why add experimental feature to a public release of such mature language as Ruby) since there is no guarantee we won't have to rewrite everything back in 2.7.4 or 2.8
The other issue I'm having with it is that it is connected to a case statement. It might be just me, but I'd dream of having this in function header definition instead of a statement which I rarely see in code and am not too comfortable to use as well (this might be connected to the crowd I'm usually working with).
Re: Pattern Matching in Ruby 2.7 (2019)
#4Is it just me or does the syntax seem very confusing? Compared to other languages with pattern matching (ex OCaml) it seems a little clunky. I'm not familiar with Ruby though, does this syntax mesh with the rest of the language though?
It mostly does, but they talk about part of that actually, and why they had to use and extend `case` rather than introducing a new reserved word (like match).
And to your point, I think... Some of these features like pipes are really cool to see in languages like Ruby or JavaScript, but holy shit without true immutability some of this seems like a nightmare to emulate (like not being able to match on method calls if I remember correctly) in an traditional OOP runtime/vm.
Fuck my life, and this is strictly IMHO, but pipes seem totally worthless when you have to worry about the object and not the data...
Re: Pattern Matching in Ruby 2.7 (2019)
#5I hope... this is not another feature that is added to Ruby at the sake of the functional programming trend.
Rubycop’s author criticized[0] Ruby 2.7 for losing a direction/vision where Ruby should go (which sparked controversial operators that were quickly removed).
Most of them looks like, at least to me, trying to fit a functional programming features in an inherently object-oriented language to be ‘hip’. Like... the pipeline operator which had strange semantics.
I hope this isn’t one.
[0] Ruby, Where do We Go Now?: https://metaredux.com/posts/2019/12/06/ruby-where-do-we-go-n...
Re: Pattern Matching in Ruby 2.7 (2019)
#6Yes! This is fantastic! And, in typical Ruby fashion, I've learned more about pattern matching from these slides than anything else trying to explain it that I've encountered before.
I'd definitely vote in favor of the pinned expressions. One of the things I like about Ruby is how pretty much everything is an expression, and you can replace pretty much any symbol with an expression.
Re: Pattern Matching in Ruby 2.7 (2019)
#7I mean I get it - but, it doesn't feel like ruby to me. It lacks clarity. Maybe it's just me, but i'm not psyched to see this. It feels like a scope creep of some sort.
Re: Pattern Matching in Ruby 2.7 (2019)
#8I personally love pattern matching (one of the best features of Elixir and Erlang for my taste) and would be screaming in enjoyment if something similar would be introduced to Ruby but I'm kind of meh about the whole ordeal. This is experimental. Even when we upgrade production systems to 2.7 I'm still going to refute usage of pattern matching in the code (and it still boggles my mind why add experimental feature to…
> in function header definition
Hmmm, I can kind of see it, but then you'd also need function overloading, right? With this you'd just do outer/inner functions, where the outer determines the pattern match and dispatches along to the appropriate inner function.
If you want to just make sure the function only accepts arguments that match a pattern, you're basically talking a guard pattern. Maybe a `return unless foo in ` syntax would then be nice (or some other one-liner), but it's not like it'd be hard to do it using this feature, you'd just use a few more mostly empty lines.
Re: Pattern Matching in Ruby 2.7 (2019)
#9I hope... this is not another feature that is added to Ruby at the sake of the functional programming trend. Rubycop’s author criticized[0] Ruby 2.7 for losing a direction/vision where Ruby should go (which sparked controversial operators that were quickly removed). Most of them looks like, at least to me, trying to fit a functional programming features in an inherently object-oriented language to be ‘hip’. Like... t…
Hmmm. I'm definitely in favor of more functional programming features / capabilities, particularly in a language like Ruby that allows for pretty effective mixing of OOP/functional paradigms. Right tool for the job, where the job is usually "communicating with other programmers what this code should do".
I've always found Ruby to be an amazing mix of functional & OOP already, what with blocks, and that class definitions are also (actually?) functions themselves. And don't forget being able to drop parens!
I've also always felt like Ruby had mostly clear vision - arguably better than a perfectly clear one, since it leaves more room for play, exploration, and other people's contribution - even if it's not one that's able to be put into words. Every time I came across something surprising in Ruby, once I learned what was going on, it made sense in that larger whole.
Re: Pattern Matching in Ruby 2.7 (2019)
#10I hope... this is not another feature that is added to Ruby at the sake of the functional programming trend. Rubycop’s author criticized[0] Ruby 2.7 for losing a direction/vision where Ruby should go (which sparked controversial operators that were quickly removed). Most of them looks like, at least to me, trying to fit a functional programming features in an inherently object-oriented language to be ‘hip’. Like... t…
Why can't pattern matching fit in OOP? It's not really functional, despite being in most functional languages. It's just sugar for more lengthy imperative conditionals and unpacking.