Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pattern Matching in Ruby 2.7 (2019)

speakerdeck.com

Post reply on HN
Print view View original

41–50 of 110 posts

Re: Pattern Matching in Ruby 2.7 (2019)

#41

Post by agumonkey »

zelly wrote: post #10
pcr910303 wrote: post #5

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

Because part of the OOP mindset is to never dig into an object and only interact with a flat interface. From the few that I remember from OO articles in the 00s.

Now technically yes all FP idioms are just simple operations below that can be used. And they are.. python, js have destructuring which is a first stage pattern matching.

Re: Pattern Matching in Ruby 2.7 (2019)

#42

Post by barrkel »

xlii wrote: post #3

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…

The === operator is used by case statements, and can be used to implement pattern matching if you write objects which match in the way you want. It's how regexes match strings and ranges match numbers, etc.

What it doesn't have is destructuring combined with pattern matching, though it does have some destructuring assignments.

Re: Pattern Matching in Ruby 2.7 (2019)

#43

Post by IfOnlyYouKnew »

nnq wrote: post #12

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

Agreed... I can write typical data-wrangling code at close to the speed of typing in ruby. In Python it takes forever, and I notice how every fibre of my soul tries to avoid even looking at it, much less enjoying and wanting to learn.

But it didn't turn out that way. And since people using Python don't strike me as particularly stupid or anything, there must be something about that language I'm still missing, or it wouldn't have succeeded as it did.

I do insist, however, that the documentation is overseen by sadists. Half the time the first 10 hits are to the C interface. The others sometimes link circularly between two "see: x" declarations, etc.

Re: Pattern Matching in Ruby 2.7 (2019)

#44

Post by pansa »

skrebbel wrote: post #15
nnq wrote: post #12

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

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 Rail…

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

Re: Pattern Matching in Ruby 2.7 (2019)

#45

Post by zozbot234 »

agumonkey wrote: post #41
zelly wrote: post #10

Earlier quoted context omitted.

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.

Because part of the OOP mindset is to never dig into an object and only interact with a flat interface. From the few that I remember from OO articles in the 00s. Now technically yes all FP idioms are just simple operations below that can be used. And they are.. python, js have destructuring which is a first stage pattern matching.

Destructuring ("digging into" a type) makes little sense with open records and sums, which OOP introduced into common use. The "closed" ('final', 'sealed' etc.) case where destructuring makes sense was disregarded for some time because it was thought that extensibility was always the appropriate choice.

Today, "open" extensibility mechanisms are considered a bit problematic because it's never really clear what invariants they should preserve, so maintaining correctness is an issue. A "closed" interface makes it essier to specify related invariants.

Re: Pattern Matching in Ruby 2.7 (2019)

#46

Post by workthrowaway »

nnq wrote: post #18
lmm wrote: post #17

Earlier quoted context omitted.

I shudder to think what datascience code would look like if a language with a culture of monkeypatching/metaclassing had won. Clear code is nice, but not when the price is sweeping all of the details too deeply under the carpet.

> sweeping all of the details too deeply under the carpet Ever worked with numpy, scipy, pandas etc. in Python? It's ALL about what you call "sweeping the details under the carpet", or what is generally called abstraction. When abstraction is well "swept under the rug", eg. "you can use it without understanding it much" it's called non-leaky abstraction, and is the best kind of abstraction. Sure, there's languages li…

imo, python won because the community does not condone monkey-patching and dark magic tricks. it's totally possible, yes, but it is frown up. i just realized how important language communities are, actually!

i, unlike GP, do not get a smile on my face when i read ruby code full of implicit tricks. even when i understand some of them, it is still annoying.

why don't people just write clear, explicit, maintainable code instead of trying to be clever. i am sure method_missing could be implemented in python using various tricks but nobody, afaik, is doing that.

Re: Pattern Matching in Ruby 2.7 (2019)

#47

Post by lizmat »

roryrjb wrote: post #21
DarkWiiPlayer wrote: post #19

Earlier quoted context omitted.

I don't really know much about python, but how is the C API? Because as nice as Ruby may be as a language, I wouldn't want to touch the C API with a laser pointer. Maybe python just has a nicer API, leading to more people writing fast C libs for it instead of Ruby; and ultimately many people will just use the language with the fastest libraries for their domain (specially the kind of people that have some influence o…

This is a big use case for me. I really want to use Perl but I favour Python because the CPython API vs XS, it's a no brainer. I haven't really looked into the Ruby C API but if it's sane I would use it as well.

Perhaps Raku is an alternative for you with its Perl roots and its NativeCall support: https://docs.raku.org/language/nativecall Also see this recent blog post for interfacing with C++ and Fortran from Raku: https://andrewshitov.com/2020/01/08/calling-cpp-and-fortran-...

Re: Pattern Matching in Ruby 2.7 (2019)

#48

Post by pansa »

chucke wrote: post #22
xlii wrote: post #3

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…

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.

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

Re: Pattern Matching in Ruby 2.7 (2019)

#49

Post by namelosw »

nnq wrote: post #12

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

And also, a decade before the Ruby community was the most inspiring community. One can really learn a lot from others, every day. It was like a hacker sanctuary while most programmers are still debating Java vs C++/C#.

Now the community is scattered into different communities - JavaScript, Go, Python, Rust, Scala, Elixir, etc. Those communities are still quite good, but none of them is as great as the previous Ruby community, or at least, gives me the same feeling IMHO.

Post reply on HN