
Pattern Matching in Ruby 2.7 (2019) - brudgers
https://speakerdeck.com/k_tsj/pattern-matching-new-feature-in-ruby-2-dot-7
======
xlii
I 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).

~~~
chucke
Refinements was also at some point marked as "experimental", and jruby
maintainers have at some point declared not wanting to support it. It's 2020,
refinements are still here, and jruby supports them, even with all its
imperfections.

I'm wondering: how would you showcase an experimental feature to the
community? Cuz if you're saying "3rd party library", there were already 3/ 4
different pattern matching libraries.

~~~
pansa
> how would you showcase an experimental feature to the community?

How do other languages do it? Python has the PEP process for discussing design
on paper, but I don’t know how they handle experimental implementations.

~~~
akuchling
Standard library packages can be declared "provisional":
[https://www.python.org/dev/peps/pep-0411/](https://www.python.org/dev/peps/pep-0411/)

The PEP says "A provisional package is one which has been deliberately
excluded from the standard library's backwards compatibility guarantees."

But there's no equivalent for language features, AFAIR.

------
pcr910303
I 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...](https://metaredux.com/posts/2019/12/06/ruby-where-do-we-
go-now.html)

~~~
zelly
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.

~~~
pjmlp
Indeed, Objective Caml is a multi-paradigm language with pattern matching.

~~~
totalperspectiv
And Scala. The poster child of oop + functional

------
RangerScience
Yes! 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.

------
meesterdude
I 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.

~~~
onli
The ^ operator is maybe a bit confusing, and that Hashes need to use symbol
keys to work here is just another example that symbols are a mess. But did you
see the JSON-matching example in the slides? That made it totally clear to me
how this is supposed to work and what the advantage of having this would be.
Very powerful, very useful, and the code in that scenario is much clearer.

------
sawyerjhood
Is 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?

~~~
rubyn00bie
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...

~~~
pmontra
In a language like Ruby and most imperative mutable ones pipelines could be a
nice syntactic sugar for constructs like this

    
    
      a = f1()
      a = f2(a)
      a = f3(a, b)
      a = f4(a, c)
    

It becomes (let me use Unix pipes)

    
    
      a = f1()
        | f2()
        | f3(b)
        | f4(c)
    

OO idiomatically handles that by making each method return an object with the
status and at least the next method to be called

    
    
      a = f1().f2().f3(b).f4(c)
    

However unless the class of that object is something standard and already
available like (example) Ruby's Enum, it's a pain to code it (and understand
it later on) and people go for the shortcut of writing the code at the
beginning of my reply.

------
nnq
...semi off-topic, but man, _how I wish Ruby had won the hearts of data-
science and machine-learning practitioners instead of Python or R!_ It looks
like such a wonderful and extensible and programmer friendly language compared
to all the others in the "multi-purpose dynamic 'scripting' languages class".
Every time I read Ruby code it almost puts a smile on my face, it seems such a
joy to write and think in, _so sad it didn 't break out of its niche much :(_

~~~
skrebbel
Same! I never used Rails much but did learn Ruby and used it a lot for the
kind of stuff people tend to use Python for nowadays. Data crunching,
prototyping, sciency stuff.. It's excellent for that.

I mean, Ruby is so much more elegant and consistent than Python, I'll never
understand how Python became the more widely appreciated language of the two,
especially with the effective head start that Ruby had through Rails'
popularity.

~~~
pansa
> I’ll never understand how Python became the more widely appreciated language

IMO syntax is a major factor. Python looks like pseudocode, while Ruby looks
like Perl.

~~~
SeekingMeaning
Genuinely curious, what makes Python look more like pseudocode? The use of
colons?

Regardless, I’ve always thought that Ruby is more like pseudocode because with
Ruby, I’m able to worry less about syntax and more about what I’m trying to
do. Maybe it’s just me?

~~~
pansa
> Genuinely curious, what makes Python look more like pseudocode? The use of
> colons?

I used to think it was significant indentation, but if you look at the
pseudocode on e.g. Wikipedia, there is no significant preference for either
whitespace or begin/end.

Therefore, it’s probably things like `if value in my_map` vs `if
my_map.contains(value)` and `[x * 2 for x in my_list]` vs `my_list.map(x -> x
* 2)`.

~~~
nnq
\- `if value in my_map` is a one off special case - ugly, nasty, hard to
figure out how to extend it (what if I invented my_map to have special logic
for `in` ...I need to search the docs for a magic method called for that
operator ...if I even know for what keywords to search, ugh)

\- `if my_map.contains(value)` is nice and consistent, easy to search for the
code of the .contains method and figure out what it does

\- `[x * 2 for x in my_list]` another ugly special case syntax, instead of
general purpose higher order functions, even in Python while a `.map` method
could've been easily added to dictionaries too, we had to wait years
(decades?) for dictionary comprehensions to land in the language, and it's
another damn special syntax one has to remember. ugh! - a sane solution not
involving higher order functions usage would've been to make everything in the
language an expression and have `for ...` expressions return lists or
dictionaries or sets, still better than the fugly "list comprehension", I
really can't comprehend why people like them

\- `my_list.map(x -> x * 2)` nice, clean, and general. If I work with a
weirder list like thingy and want to see the logic of mapping, I can easily
jump to the definition of it's `.map` method

Most pseudocode is _ugly_ and _ambiguous_ and _actually hard to read without
special context from the text around it_ because you're never sure what
something _actually_ means, can't easily "jump to its implementation code and
read it". Same like natural language, hard to non-ambiguously understand and
_ugly as hell_ in technical context where math and diagrams work 1000x times
better.

I can't understand _why people who are trained in math, physics and /or other
sciences would ever choose something just because it "looks more like
pseudocode"..._ To me _pseudocode_ rhymes with... _pseudoscience!_ It's never
what you want when you can choose something better.

------
3pt14159
I'm 80% in favour of this change. JSON parsing is tedious and this looks like
it will help pretty cleanly on something that rubyists do quite frequently. I
could also see myself using this pretty frequently elsewhere.

That said, I do see some minor drawbacks:

1\. I personally find the case statement in ruby confusing. It uses === which
I find hard to use without stopping and thinking.

2\. I don't understand why the bitwise or operator is being used for the
pattern matcher or. Was it not possible to just use `or` itself?

3\. Deconstruct keys reads a bit weird. Easy enough to understand and
remember, but I can imagine being new to ruby or programming and finding the
pattern matching pretty hard to follow.

------
louis8799
Do we have something similar in python, if not I am going to make one.

~~~
L3viathan
There is this: [https://github.com/grantjenks/python-pattern-
matching](https://github.com/grantjenks/python-pattern-matching)

~~~
Stormwalker
This project is just someone wrote a proposal or something. Here is actually
implemented pattern matching as a library
[https://github.com/santinic/pampy](https://github.com/santinic/pampy)

------
floki999
I used both Python and Ruby extensively for a while, love both, but Ruby was
just nicer to code in. The problem for me was the much smaller ecosystem,
especially for anything numerical/data related. Numpy was, pre Pandas days,
the killer library for the type of work I do.

------
rkachowski
Is pattern matching implemented sequentially in order of declaration in other
languages? My naive brain took the pattern resolution to be based on some kind
of map of types and values to implementation.

~~~
verttii
It is, from top to bottom.

------
vmchale
ML is changing the world.

~~~
Scarbutt
Wrong thread?

