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

21–30 of 110 posts

Re: Pattern Matching in Ruby 2.7 (2019)

#21

Post by roryrjb »

DarkWiiPlayer wrote: post #19
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…

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.

Re: Pattern Matching in Ruby 2.7 (2019)

#22

Post by chucke »

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.

Re: Pattern Matching in Ruby 2.7 (2019)

#23

Post by stanislavb »

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 guess the answer is - Google. As it used Python and the word was out. Also, Python had been released a few years earlier and so was adopted by universities.

Re: Pattern Matching in Ruby 2.7 (2019)

#25

Post by brigandish »

DarkWiiPlayer wrote: post #19
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…

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…

I wouldn't say I'm a C programmer at all though I did manage to struggle through producing a very simple C-extension for Ruby once. Recently, I had to debug one that wouldn't install. Could I find well written, up to date documents?

No. I found bits and pieces scattered in blog posts and gists, and wildly different ways of making extensions.

It was incredibly vexing and I would've happily used Python - or anything else - at that moment. The number of times I find hardcoded paths in Ruby extensions is mind boggling. I guess "it works on my computer" is okay for some but to me it seems amateurish. I don't blame the library authors as much as the core team for this because the documentation and examples are so bad. Not a good look for a mature language.

I'm looking at learning Crystal and Elixir because they'll (hopefully in Crystal's case) fix a lot of the glaring-but-never-fixed problems in the Ruby ecosystem for me.

Ironically enough I've spent my afternoon fighting with a Ruby C-extension that won't install!

Re: Pattern Matching in Ruby 2.7 (2019)

#26

Post by pjmlp »

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…

> functional programming features

What features?

Smalltalk-80 already had lambdas and LINQ, they were just called blocks and collection methods instead.

Pattern matching in OOP languages was a path pursued by BETA, Simula's successor by the same authors, where even classes are instances of patterns as concept.

Re: Pattern Matching in Ruby 2.7 (2019)

#27

Post by pjmlp »

zelly wrote: post #11
RangerScience wrote: post #9

Earlier quoted context omitted.

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

Ruby blocks are another example of something that looks like a functional programming feature but is actually not. As in Java 8 and C++11, which also added lambdas, it doesn't have much in common with FP lambdas. These are essentially syntax sugar for an ad-hoc function that's too small to factor our and give a name. FP lambdas are the most elementary unit of computation. You're supposed to be doing absolutely everyt…

From CS point of view, I miss the point you are trying to make.

No mainstream FP language is doing pure lambda calculus.

Re: Pattern Matching in Ruby 2.7 (2019)

#28

Post by pjmlp »

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.

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

Re: Pattern Matching in Ruby 2.7 (2019)

#29

Post by zmmmmm »

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…

That's why I actually do a lot of my data science work with Groovy. I just find Python awkward, frustrating and way underpowered as a language (both in terms of language itself but, of course performance as soon as you need to implement anything and not just glue other things together). Groovy + JVM accessible numerical libraries (Smile, ND4J etc) actually make a pretty good combination, even if you do not have access to the state of the art stuff that is going on in R / Python.

Re: Pattern Matching in Ruby 2.7 (2019)

#30

Post by coldtea »

zmmmmm wrote: post #29
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…

That's why I actually do a lot of my data science work with Groovy. I just find Python awkward, frustrating and way underpowered as a language (both in terms of language itself but, of course performance as soon as you need to implement anything and not just glue other things together). Groovy + JVM accessible numerical libraries (Smile, ND4J etc) actually make a pretty good combination, even if you do not have acces…

>I just find Python awkward, frustrating and way underpowered as a language (both in terms of language itself but, of course performance as soon as you need to implement anything and not just glue other things together).

Compared to Groovy and Java?

Post reply on HN