DEV Community

Cover image for Mastering Monadical Syntax in Ruby: A Practical Guide to Functional Elegance

Mastering Monadical Syntax in Ruby: A Practical Guide to Functional Elegance

Pimp My Ruby on November 22, 2023

My first encounter with Monadical writing was with the Haskell language. I immediately fell in love with the functional syntax. The challenge of th...
Collapse
 
topofocus profile image
Hartmut B.

Hi,
although I too am fascinated by the abstraction of Dry::Monads, I share the suspicions of others about readability and introducing just more »syntax sugar«.
The monads-concept feels natural in rust, where its an integrated part of the language, but is a kind of artificial for a pure oop-language like ruby.
Rubyists must not fall into the same traps, perl developers did in the past, by just implementing anything form other languages just because its "Zeitgeist".

Its definitively not a substitute of if then else branching, however, in certain circumstances a smart enhancement .
Thanks for sharing!

Collapse
 
pimp_my_ruby profile image
Pimp My Ruby

Hi !

Returning a String, a Boolean, or an Integer do not give enough context. Using monad is a simple way to identify if it's a Success or a Failure, depending on your business logic.

There are other gems that help you to encapsulate the logic. The concept of encapsulating logic in order to give more context is not new.

The idea behind all that is to improve readability. I agree it's a new syntax. But once someone explained you / show you some example, it's very easily understandable.

Of course, you cannot just erase all the if in your code with using Monads, it is not THAT magic ahah. And for sure, I still use some return Failure() if xxx.

Let me know if you want to talk more about it, and maybe I can find some more complex codes example ?

Collapse
 
cherryramatis profile image
Cherry Ramatis

Amazing didactics and introduction to the monad theme!

On the Try example, why should I use this method instead of just rescuing? seems strange to me since it's already an exception instead of a monad

Collapse
 
pimp_my_ruby profile image
Pimp My Ruby • Edited

Actually, the Try monads is just a mapping rescue

Try[Error] { '123' }
<==>
begin
  Success('123')
catch Error => e
  Failure(e)
end
Enter fullscreen mode Exit fullscreen mode

So it is "just" sugar syntax

Collapse
 
cherryramatis profile image
Cherry Ramatis

Oh this is awesome actually, so it's possible to use this as a way to always have the provided monads

Collapse
 
buckled0 profile image
Daniel Buckle

I like the implementation of getting rid of if-else statements but are you worried about readability for devs who’ve never experienced this kind of pattern?

Collapse
 
pimp_my_ruby profile image
Pimp My Ruby

Hi Daniel, thanks for your feedback !

IMO, Monad concept is not so hard to understand but hard to master.

When we introduced dry-monads and monads concepts to our peers at wecasa, the majority of them never used FP before. But in fact, people loved that instantly.
As a friend said " return Success() is the new return true ".
Once we show you basic examples, you may be able to understand the basic (as showed in the article).

The bind / fmap / do notation concept is something we needed to explain deeper because they mean nothing for an OO programmer.

But when you have the fundamentals (Maybe, Success, Failure, bind) in fact you're good to go. Harder concepts will come when you code a bigger architecture, or when you need to interact with bridges.

Collapse
 
romeolove profile image
Eric

I'm a great fan of your content !

Keep up the great work

Collapse
 
pimp_my_ruby profile image
Pimp My Ruby

Hi Éric, that's very kind thanks <3

Collapse
 
a_chris profile image
Christian

I keep fighting with dry-monads due to weird yield behaviours that conflicts with rescue and other annoying stuff. So I built to-result, a wrapper over dry-monads that offer the ToResult method. It's like Try but on steroids but you can use all the dry-monads stuff at the same time 😎🚀