Refactoring Ruby with Monads • Hacker News Board

Re: Refactoring Ruby with Monads

#21

Post by prezjordan » Sat, Oct 04, 2014, 2:42 AM UTC

aftbit wrote: post #19

For the author's toy example, I don't see how this is better than using begin... rescue. def weather_for(project) begin project.creator.address. country.capital.weather rescue NoMethodError nil end end

Because you may want to chain weather_for with some other methods and have this same "if nil don't break!" strategy. We would end up putting `rescue NoMethodError` everywhere and end up right where we started.

Instead, he later changes weather_for to accept and return this new `Optional` construct, making it chainable, and dealing with this "if nil don't break!" in one spot and one spot only.

Re: Refactoring Ruby with Monads

#22

Post by nshepperd » Sat, Oct 04, 2014, 3:01 AM UTC

aftbit wrote: post #19

For the author's toy example, I don't see how this is better than using begin... rescue. def weather_for(project) begin project.creator.address. country.capital.weather rescue NoMethodError nil end end

If that does what it looks like, then Optional is better than that in one respect: begin/rescue will catch all NoMethodErrors, including unrelated ones. But you probably do want an error to be thrown if you typo and write "project.creator.adress" by mistake.

Re: Refactoring Ruby with Monads

#23

Post by SEMW » Sat, Oct 04, 2014, 11:21 AM UTC

jmcgough wrote: post #20

for those who haven't seen the talk, he says during it that he's not actually advocating that people implement this in their codebase :p

As someone currently maintaining a Ruby codebase originally written by the author, I winced at that ;)

Re: Refactoring Ruby with Monads

#24

Post by hywel » Sat, Oct 04, 2014, 12:06 PM UTC

This is an excellent article but one of its main achievements is to make Ruby work like PHP (swallowing nil errors). The difference between try and Eventually isn't just that try is on every Object, but that the calling code gets to decide when a nil is unexpected. Personally, I'd rather get errors from nils which I can fix, than swallowed nil values that I'll probably never know about.

Re: Refactoring Ruby with Monads

#25

Post by tomstuart » Sat, Oct 04, 2014, 12:44 PM UTC

SEMW wrote: post #23

jmcgough wrote: post #20

for those who haven't seen the talk, he says during it that he's not actually advocating that people implement this in their codebase :p

As someone currently maintaining a Ruby codebase originally written by the author, I winced at that ;)

I apologise for that codebase! Let’s just say I’ve learned a lot about building Rails apps since 2007. ;)

Re: Refactoring Ruby with Monads

#26

Post by zimbatm » Sat, Oct 04, 2014, 1:57 PM UTC

Recently I benchmarked a small network server written in Haskell. During the load testing the GHC runtime would allocate at rates of 1.6GB/s which is highly unusual from my experience but is apparently normal for pure functional languages. The impressive bit is that during the operations the heap was never bigger than 50MB and GC pauses longer than 100ms.

If we where to re-write all our ruby code to be purely functional I don't think that CRuby GC would keep up very long with that kind of memory pressure.

Re: Refactoring Ruby with Monads

#27

Post by V-2 » Sat, Oct 04, 2014, 2:32 PM UTC

vinceguidry wrote: post #2

Please don't actually do this. Ruby is not a functional language, if your project really needs to be functional all the way through just use Haskell or whatever. Otherwise just pull out the parts of your code would benefit from being expressed in functional style into a module and work on implementing a proper DSL.

Just because a language isn't functional doesn't mean it can't benefit from some goodies of the FP paradigm.

C# is very successful with adapting bits and pieces from "other worlds" (such as FP, or dynamic typing etc.)

Re: Refactoring Ruby with Monads

#28

Post by jhund » Sat, Oct 04, 2014, 4:00 PM UTC

Alternatively one could use NullObjects for the Optional use case: http://devblog.avdi.org/2011/05/30/null-objects-and-falsines...

Re: Refactoring Ruby with Monads

#29

Post by imanaccount247 » Sat, Oct 04, 2014, 4:15 PM UTC

zimbatm wrote: post #26

Recently I benchmarked a small network server written in Haskell. During the load testing the GHC runtime would allocate at rates of 1.6GB/s which is highly unusual from my experience but is apparently normal for pure functional languages. The impressive bit is that during the operations the heap was never bigger than 50MB and GC pauses longer than 100ms. If we where to re-write all our ruby code to be purely functio…

>but is apparently normal for pure functional languages

Where did you hear that?

>and GC pauses longer than 100ms.

Yikes! That is not normal at all. You wouldn't be able to write a decent webserver in haskell if that were normal.

Re: Refactoring Ruby with Monads

#30

Post by imanaccount247 » Sat, Oct 04, 2014, 4:18 PM UTC

vinceguidry wrote: post #2

Please don't actually do this. Ruby is not a functional language, if your project really needs to be functional all the way through just use Haskell or whatever. Otherwise just pull out the parts of your code would benefit from being expressed in functional style into a module and work on implementing a proper DSL.

Why? What do you think is so wrong with ruby that using techniques from FP there is terrible? Virtually every other language handles it fine, and I can't seem to find anything about ruby that would make it a problem.