Ruby 2.7
ruby-lang.org
Ruby 2.7
1–10 of 68 posts
Re: Ruby 2.7
#2great!
i truly like this language.
Re: Ruby 2.7
#3I know it's slow at the moment, but is anyone planning on using pattern matching for anything in particular? Curious what use cases are particularly suitable for it.
Re: Ruby 2.7
#4I know it's slow at the moment, but is anyone planning on using pattern matching for anything in particular? Curious what use cases are particularly suitable for it.
I’d love to, if it helps with things like Either/Maybe types. Although from what I’ve looked at briefly the syntax felt a little less intuitive than I’ve seen in other languages.
Will have to properly try it out.
Re: Ruby 2.7
#5I know it's slow at the moment, but is anyone planning on using pattern matching for anything in particular? Curious what use cases are particularly suitable for it.
I’d love to, if it helps with things like Either/Maybe types. Although from what I’ve looked at briefly the syntax felt a little less intuitive than I’ve seen in other languages. Will have to properly try it out.
what's the purpose of Either and Maybe in a dynamically typed language?
Re: Ruby 2.7
#6Earlier quoted context omitted.
I’d love to, if it helps with things like Either/Maybe types. Although from what I’ve looked at briefly the syntax felt a little less intuitive than I’ve seen in other languages. Will have to properly try it out.
what's the purpose of Either and Maybe in a dynamically typed language?
One use could be that you could capture source information in them, so when you get an unexpected None you can find where it came from.
Re: Ruby 2.7
#7Re: Ruby 2.7
#8Earlier quoted context omitted.
One use could be that you could capture source information in them, so when you get an unexpected None you can find where it came from.
What forces you to check for None?
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, can help you trace what went wrong.
Re: Ruby 2.7
#9Earlier quoted context omitted.
What forces you to check for None?
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 Ruby 3.0 will make this feasible. I'm not sure of the details of the type system they intend to implement; whether it supports ADTs and such.
Re: Ruby 2.7
#10Earlier quoted context omitted.
I’d love to, if it helps with things like Either/Maybe types. Although from what I’ve looked at briefly the syntax felt a little less intuitive than I’ve seen in other languages. Will have to properly try it out.
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.