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

11–20 of 110 posts

Re: Pattern Matching in Ruby 2.7 (2019)

#11

Post by zelly »

RangerScience wrote: post #9
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…

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 everything with lambdas even addition, theoretically (head in the clouds academic BS), and the other syntax (like `do` in Haskell) is sugar for lambdas.

So basically Ruby is far from FP. It sticks to OOP, which has actually been proven to work.

Re: Pattern Matching in Ruby 2.7 (2019)

#12

Post by 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 :(

Re: Pattern Matching in Ruby 2.7 (2019)

#13

Post by pmontra »

sawyerjhood wrote: post #2

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?

It kind of meshes with but I agree it's clunky. I'd like to have full pattern matching like we have in Elixir or at least in method definition. But that's going to turn Ruby into something different. I'm not sure it's worth it.

Re: Pattern Matching in Ruby 2.7 (2019)

#14

Post by pmontra »

rubyn00bie wrote: post #4
sawyerjhood wrote: post #2

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?

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…

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.

Re: Pattern Matching in Ruby 2.7 (2019)

#15

Post by skrebbel »

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 Rails' popularity.

Re: Pattern Matching in Ruby 2.7 (2019)

#16

Post by bjoli »

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…

As someone who sometimes steps out of the comfort of writing scheme, I agree with you. I spent a lot more time writing python than I did ruby, but with ruby I can just jump right in and things work like I expect them to. With python there is always small semantic things that moves the whole experience into slightly uncomfortable territory.

But whatever floats people's boats. If I had to do numeric computation I would chose python as well, but personally I would become a grumpy fart that would complain way too much

Re: Pattern Matching in Ruby 2.7 (2019)

#17

Post by lmm »

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

Re: Pattern Matching in Ruby 2.7 (2019)

#18

Post by nnq »

lmm wrote: post #17
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 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 like Go that are all about NOT sweeping things under the rug. But that's a different niche.

Re: Pattern Matching in Ruby 2.7 (2019)

#19

Post by DarkWiiPlayer »

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 on their community).

Again, no idea if this is the case, but comparing the C APIs of Ruby and Lua, it's a huge difference.

Re: Pattern Matching in Ruby 2.7 (2019)

#20

Post by gdy »

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…

"it's called non-leaky abstraction"

Is there such thing?

Post reply on HN