DEV Community

Discovering the notion of Monad in Javascript

artydev on October 30, 2023

You already know what Monads are about, so I won't repeat what you can read about them in the numerous articles on the net. I am taking the point ...
Read full post
Collapse
 
efpage profile image
Eckehard •

But what is the advantage? Is there any real use where building functions like Matryoshka dolls really makes things easier?

Collapse
 
artydev profile image
artydev • • Edited

:-D,
Your questions are always pertinents.

Look at the last example how the getBadge function does not have to deal if a user is valid or not, it's always passed a valid user.

With that "mecanics", chained function are not called if the value does not respond to some criterias

Demo

Collapse
 
efpage profile image
Eckehard •

I cannot even think how this could be easy...

attendees is not an array of objects, but an array of PseudoNomads. I cannot even imagine, if the code below is ok or not, as I do not know, what an array of Pseudonomads is or what Pseudonomad() returns. I first have to understand how this was defined to check the whole code.:

[Hal, John, Alice]
  .map(u => u.map(getBadge()))
  .filter(u => u.value)
Enter fullscreen mode Exit fullscreen mode

The second line look suspicious, as it would execute Hal.map(getBadge), but Hal is not an array, but a pseudonomad. But ok, getBadge() is a function that returns a function, why not...

So, here is the explanation of the nested arrow functions you use, which is not easy to understand:

const transform = (value) => (fn) => fn(value)
transform(5)(addTwo)
Enter fullscreen mode Exit fullscreen mode

Oh, how nice, A function with two argument brackets. Is this valid Javascript?
Can we remove the round brackets on value or fn, as is allowed for arrow functions with one argument? What value will numberbadge have, as this is a local variable? Hard to say...

Assume, we find this code somewhere in the wild? Even with your explanation by hand I´m struggeling to understand the code I see. What precisely is this?

({value, map (fn) {return fn(this.value)}})
Enter fullscreen mode Exit fullscreen mode

not a valid Javascript expression that I have ever seen. You will hardly findy any help for this, as map is explained to be an array function, not anything you could use alone. But I even could not tell if this could be an object or not.

Pseudonomad() looks like an arrow function that returns an object embraced in round brackets. If you do not know this exact and rare construction, it is virtually impossible to understand the code. Unreadable code is the small sister of unmaintainable code and a good reason to bury a whole project after some time.

And what is about debugging? Do we have to go the whole way down to the core of the Matryoshka to find any errors?

I´m not sure that this programmatical shell games could really be appealing.

Thread Thread
 
artydev profile image
artydev • • Edited

Eckehard,
I must first apologize to have made such a poor presentation of the concept of Monads.
But they are really not that easy to explain.

The followed example should have gave you a better understanding of why they are usefull.
Indeed we are assured to never have to deal with "null reference object" and that is very nice.

I really enjoin you to document yourself about functional programming in JS, and what are Monads and their usefullness.

Here is a presentation : Functional Programming with JavaScript

Those concepts are largely olders than Object Oriented Programming.

Javascript is a language mainly based on Scheme which is a functional programming language rather than Java.

In FP, functions are not differents than any other variables, they are first class citizens.
They can be assigned to a variable, pass as arguments to other functions.
From an O.O programmer, FP is a real shift in mind.

POO is rarely used as it should be, and in large programs it can be very complex to follow the thread of execution because of inheritance, aggregation, implementation , abstract and virtual classes, privacy, sealed, static and so on, too much concepts for me.

In FP you simply let the flow of data running through composed transformations, for me it is easier to follow.

Look why POO can sometimes pose problems by looking at this code from : FP

What is the real outcome of result ? Is it that easy to solve it ?
and this is a very simple program.

class Flock {
  constructor(n) {
    this.seagulls = n;
  }

  conjoin(other) {
    this.seagulls += other.seagulls;
    return this;
  }

  breed(other) {
    this.seagulls = this.seagulls * other.seagulls;
    return this;
  }
}

const flockA = new Flock(4);
const flockB = new Flock(2);
const flockC = new Flock(0);
const result = flockA
  .conjoin(flockC)
  .breed(flockB)
  .conjoin(flockA.breed(flockB))
  .seagulls;
Enter fullscreen mode Exit fullscreen mode

FP is a paradigm not easy to apprehend, but a nice tools in your toolbox nothing less nothing more.

Thread Thread
 
efpage profile image
Eckehard • • Edited

Thank you much for explaining backgrounds. Im really struggeling to get a clue on all this concepts. If I learn something that could make my life easier, i would really appreciate to adopt this. It does not matter how old a concept is, as long as it is useful.

Speaking of OOP you will find different concepts in history, initial ideas have been developed in 1966, so it will not have a lack in maturity. But there are different concepts like objects that pass messages only (smalltalk) or objects as a unity of procedures and data (C++ or Object Pascal). None of this concepts realy fits perfectly into the Javascript world, as JS lacks some core concepts. But there are cases where using structures of OOP is most useful.

I assume, this is very similar with Functional Programming, and there are situations where passing functions as a parameter can be most helpful. But as with any concept there should be a good reason to use it. If you force people to use objects and classes where simple data would do a better job, they will probably not get a clue on the benefits of OOP. This is a very similar situation here, where we build a shell game of hidden relations that are more confusing than helpful.

There are some basic rules that we should keep in mind:

  • Keep it simple
  • Don´t repeat yourself

If it´s hard to explain and the resulting code is hard to read, hard to understand and hard to debug, it is possibly not as simple as it should be.

I know that this was only an example to show the principles, but if relations and dataflows in a simple example are that confusing, how should we get a larger codebase up and running?

Thread Thread
 
artydev profile image
artydev • • Edited

Haskell is not particularly easy to grasp but it is very used in financial companies.
I can't event imagine OOP projects contolling hypermulthreadings software running on multicores CPU.
Again every paradigm as it's use and I can assure you this is the case for Functional Programming.

In FP, it's not the really the usage that is difficult to apprehend, because it is very declarative, but the theories behind it.