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

Ruby 2.7

ruby-lang.org

Post reply on HN
Print view View original

11–20 of 68 posts

Re: Ruby 2.7

#11

Post by chrisseaton »

jolux wrote: post #9
chrisseaton wrote: post #8

Earlier quoted context omitted.

The idea of Maybe is that you usually don't check for None. The idea is that you use it sort of like a collection in most cases, allowing the None to propagate up as the result of collection operations on other Nones. The issue can be that you get a None at the end and it isn't clear where it came from originally, and how it reached you. Adding stack trace information to each intermediate None, when in debug mode, ca…

>The idea is that you use it sort of like a collection in most cases Sort of like a monad, even! Honestly if you're running into problems like that though you should probably be using Either instead of Maybe like GP suggested. In my opinion, most of the benefit is still derived from strong static type checking, because otherwise you basically have to trust that callers respect your contract with these types. Perhaps…

> Sort of like a monad, even!

Yes that's it - they're monads! Either is also a monad, and you can store error information in the other side if you want, but a good thing about Maybe is it could transparently store the error information, and produce it when debugging, rather than baking it into the normal runtime semantics.

> you basically have to trust that callers respect your contract with these types

This is table-stakes for a dynamic language like Ruby, though. Yes people can do anything, but usually they follow the rules they're given.

Re: Ruby 2.7

#12

Post by sergiotapia »

Pattern matching is awesome in Elixir, it's great to see functional language traits stain the Ruby language more. It's all the better for it.

Re: Ruby 2.7

#13

Post by tyingq »

Does the pattern matching do something that Ruby's map() can't do?

Coming from Perl, map() there can return fewer elements than the source list, so pattern matching works already. A short skim of Ruby's map seems to imply it always returns something with the same number of elements.

Edit: I was confused about what this feature did. So this subthread is still interesting, but mostly unrelated.

Re: Ruby 2.7

#14

Post by rubyfan »

tyingq wrote: post #13

Does the pattern matching do something that Ruby's map() can't do? Coming from Perl, map() there can return fewer elements than the source list, so pattern matching works already. A short skim of Ruby's map seems to imply it always returns something with the same number of elements. Edit: I was confused about what this feature did. So this subthread is still interesting, but mostly unrelated.

Yeah afaik something is always returned from the block (even if it’s nil). Occasionally I recall my self doing something where the block might return nil and then I’d call `compact` to get rid of extra nil stuff. It works when you want a modified version of the enumerable but don’t want nil stuff. If you just want to match a subset then I think `select` is probably what you want.

Further, the pattern matching feature is significantly different than `map` imo.

Re: Ruby 2.7

#15

Post by knrz »

rubyfan wrote: post #14
tyingq wrote: post #13

Does the pattern matching do something that Ruby's map() can't do? Coming from Perl, map() there can return fewer elements than the source list, so pattern matching works already. A short skim of Ruby's map seems to imply it always returns something with the same number of elements. Edit: I was confused about what this feature did. So this subthread is still interesting, but mostly unrelated.

Yeah afaik something is always returned from the block (even if it’s nil). Occasionally I recall my self doing something where the block might return nil and then I’d call `compact` to get rid of extra nil stuff. It works when you want a modified version of the enumerable but don’t want nil stuff. If you just want to match a subset then I think `select` is probably what you want. Further, the pattern matching feature…

In JavaScript, Elixir, and Ruby I use flatMap for this purpose. You can return an empty array on the block to “skip” over the element.

Re: Ruby 2.7

#18

Post by obstacle1 »

ljm wrote: post #10
jolux wrote: post #5

Earlier quoted context omitted.

what's the purpose of Either and Maybe in a dynamically typed language?

Maybe I’ve just been bitten by the functional bug but I find they can communicate intent much better than scattering around null checks or catching exceptions (many of which require reading the source to understand what exceptions you might get). It’s great in large scale projects, which I think is where a dynamic language starts to show its warts.

An alternative to scattering null checks around or using exceptions for control flow could be more thoughtfully designing your data/object model. No additional language constructs required!

Re: Ruby 2.7

#19

Post by s_kilk »

tyingq wrote: post #13

Does the pattern matching do something that Ruby's map() can't do? Coming from Perl, map() there can return fewer elements than the source list, so pattern matching works already. A short skim of Ruby's map seems to imply it always returns something with the same number of elements. Edit: I was confused about what this feature did. So this subthread is still interesting, but mostly unrelated.

Map is data manipulation, whereas pattern-matching is control flow.

Re: Ruby 2.7

#20

Post by int_19h »

ljm wrote: post #10
jolux wrote: post #5

Earlier quoted context omitted.

what's the purpose of Either and Maybe in a dynamically typed language?

Maybe I’ve just been bitten by the functional bug but I find they can communicate intent much better than scattering around null checks or catching exceptions (many of which require reading the source to understand what exceptions you might get). It’s great in large scale projects, which I think is where a dynamic language starts to show its warts.

Given that we're talking about it in a pattern matching context, you'd just pattern match on x vs nil, rather than matching on Just x or None. And in case of Either, you'd match on the types that you expect.
Post reply on HN