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

31–40 of 110 posts

Re: Pattern Matching in Ruby 2.7 (2019)

#31

Post by coldtea »

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…

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

Those are just external libraries written in C/fortran/etc. Not monkeypatching.

Re: Pattern Matching in Ruby 2.7 (2019)

#33

Post by pwm »

gdy wrote: post #20
nnq wrote: post #18

Earlier quoted context omitted.

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

Sure. Math based abstractions are non-leaky. This is one of the main thing FP people rave about. Eg. map works without bias on all functors regardless whether the concrete thing is a list or a tree or an IO action, etc...

Re: Pattern Matching in Ruby 2.7 (2019)

#34

Post by rkachowski »

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…

Kind of tangential but I really appreciate seeing this cross inspiration of Elixir and Ruby. Ruby taking inspiration from the pattern matching and pin operator of Elixir, and Elixir taking the initial direction from Ruby. I look forward to the future developments of both.

Re: Pattern Matching in Ruby 2.7 (2019)

#35

Post by emj »

meesterdude wrote: post #7

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.

Lacking clarity is a good word for it, it was my feeling as well, but I've not used Ruby extensively. My feeling trying to hack existing Ruby code was always that Ruby favoured the arcane abit too much. This is from a perspective of me not bothering to learn Ruby at all. I remember thinking the same about C and Python before I bothered learning them.

I guess that feeling is always present when you try languages that are new, or our ignorance of pattern matching/Ruby?

Re: Pattern Matching in Ruby 2.7 (2019)

#37

Post by jhanschoo »

stanislavb wrote: post #23
skrebbel wrote: post #15

Earlier quoted context omitted.

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.

From my perspective, it was the was the ipython notebook (now jupyter) that was the killer app leading to Python being adopted for data science.

Re: Pattern Matching in Ruby 2.7 (2019)

#38

Post by zmmmmm »

coldtea wrote: post #30
zmmmmm wrote: post #29

Earlier quoted context omitted.

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?

Groovy absolutely. Java is .... Java.

Re: Pattern Matching in Ruby 2.7 (2019)

#39

Post by foldr »

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…

IIRC the main distinguishing feature of ruby blocks from regular anonymous functions is that you can break out of a containing scope from within them.

Re: Pattern Matching in Ruby 2.7 (2019)

#40

Post by agumonkey »

coldtea wrote: post #31
nnq wrote: post #18

Earlier quoted context omitted.

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

> 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. Those are just external libraries written in C/fortran/etc. Not monkeypatching.

I never looked at the source but it seems that there's an object layer with a lot of meta-programming to turn the oo syntax into more pleasant ergonomics.

I don't applaud ruby dark voodoo tricks, but I think it's the same spirit.

Post reply on HN