Intuition is, so to speak, an attempt to match against evolved brain structures which reflects some constraints of the environment in which it has been evolved.
Babies could read faces. This is exactly what I am talking about. Just this.
I would love to have type-clases a-la Haskell (implicits with parametric polymorphism, which is dead-simple and well understood) and universal pattern matching everywhere, but this is, of course, just a dream.
I would love to have ML/Scala-style syntax for curried functions and function definition via pattern-matching with guards, which is also, it seems, out of questions.
Actuall, the more of ML a strict language gets in - the better.
What is really funny is that Bell Labs did a lot of ML research, especially on stdlib, but Go team is ignoring everything which is not of the C flavour. Pity.
Again, ML is absolutely wonderful, and type-classes are the biggest single major innovation since Smalltalk.
It is better to lean towards ML instead of heading towards Javascript.
Oh, applying a poorly understood abstract concepts to poorly understood vastly complex and still intractable stochastic process, which is what real genetics is. (daily reminder - each gamete is unique perturbation of host's DNA)
Yes, it was really good read, thank you. I hope I could write as clearly.
Look, however, at the use of "is" in my comment and yours. You are applying "is" to some abstract, nonexistent categories, categorizing abstractions and naming the resulting categories. I use "is" to describe what is going on, particularly in Haskell and Scala.
The whole abstract hierarchy I regard no more meaningful as hierarchy of chakras in crya yoga texts or similar sectarian pseudo-logical but disconnected from reality teachings.
While I really appreciate that you have mastered this abstract hierarchy and could in clear and precise language explain it (which is what a mathematician supposed to do)
I personally refuse to take statements like "any abstract datatype is a monad" seriously.
It is a plain type-error. You are trying to say that a triangle is a number. The correct and precise way is to say "could be viewed as", because you are literally superimpose one abstraction upon another, or view one through another, if you wish.
All these nested generalizations could be superimposed on programming, but it is fundamentally wrong to say that something in programming "is" one of these abstractions.
You are speaking like a mathematician, I am speaking like a non- (or rather anti-) Plato-Hegelian philosopher.
May be. I think a Monad is an abstraction which generalizes a transition, similar to a step of logical deduction.
It Haskell a similar concept is actually used to compose what they call actions, originally used to implement IO. Out of this particular design choice, there are some specialized instances of Monads in Haskell, including State Monad.
In the context of a lazy language, like Haskell, where the order of evaluation is not defined and each expression is an implicit thunk, monadic composition is necessary and sufficient to implement serialized sequenced actions, defined as different instances of Monad type-class and to ensure, by the type checker, that these actions are of proper type (isolated from any other instances) and are properly serialized. Just this.
As a consequence of being desugared into function composition with parameter passing (>>=), which is only relevant for a lazy language, there is literally no way to access the state from outside of each pair of nested functions, so things like ST or STM are implemented as Monad.
All this is relevant for Haskell and irrelevant in Scala, where you don't have to compose functions to ensure order of evaluation. Algebraic data types and "semicolons" is good-enough.
To be a Monad you have to implement at least 2 functions >>=, and return, which must follow so called Monadic laws (of proper composition - associativity, etc). flatMap is just a function.
One more time - Futures are orthogonal to Monads. They may be viewed as such, but it is not necessary. Having only flatMap is sufficient for a strict language.
It so annoying to have your legitimate posts being flagged by some SJW idiots. HN became a safe-space for mediocre, intelligence-cosplaying snowflakes. Do your homework first, before flagging others.
That means they do meaningless unnecessary wrapping too. It is even more ridiculous for a weak-typed language.
The only point of a Monad is that in a lazy language it desugars into an implicit nested functions, which guarantees the order of evaluation.
The monadic code, then, could be generalized over >>=, >> and return, and given that, specialized instances of a Monad class could be made, like Maybe, ST and what not.
The only meaning in performing these steps is to establish a guaranteed order of evaluation (via implicit nesting of functions) for serialized abstractions.
But that is ok, most of Javascript coders never studied CS fundamentals or comparative PL.
This is exactly what is called "unnecessary wrapping".
There is no meaning in wrapping anything into a Monad in a strict language, where the order of evaluation is well-defined, narcissistic snowflakery aside.
In other words, a Monad in the context of CS or PL is the solution to a problem which does not arise in Scala.
And, of course, an option type does not have to be a Maybe Monad, like any other Either Of type.
I (foreigner) rode 18,000 km on an Enfield bike all over Indian Himalayas.
Someday I will bootstrap this
https://himalayan-enfield-riders.com/