What Is IO Monad? (2018) [video]

Did they fix strings?

Yeah, Promise really helps illustrating these concepts. Also while being less explicit in the syntax, the combination of Promise and Promise.then forms a functor that

- maps type x to type Promise<x>

- maps function x -> y to function Promise<x> -> Promise<y>

I added some content and fixed short errors to turn this into a webpage here: https://frogulis.net/writing/async-monad

Really just an epic, prolific streamer. Super technical, super deep dives, and on top of all that, an excellent educator.

Here is a series he did on developing a Forth-like language from scratch, up until it's self compiling (and a few more videos after that):

https://www.youtube.com/watch?v=8QP2fDBIxjM&list=PLpM-Dvs8t0...

Here is a series on doing advent of code in HolyC in templeOS:

https://www.youtube.com/watch?v=MMqd-6wNJQ4&list=PLpM-Dvs8t0...

Just look at the breadth of videos, from openGL to Excel:

https://www.youtube.com/c/TsodingDaily/playlists

I do wish he would do revisit more haskell :)

Yes! This is exactly how I prefer to explain monads to non-Haskellers. A monad is just a unified abstraction for a certain type of callback which pops up in a bunch of different places (promises, optionals, randomness etc.). In some ways, it’s almost like a formalised version of an design pattern in the OOP sense. There’s really no need for category theory or strained analogies to understand or use monads in normal Haskell code.

(Of course, the theoretical underpinnings are still very interesting in and of themselves! They’re also a source for new patterns — things like free monads and comonads are very, very useful indeed. But it’s entirely possible to program Haskell without knowing a thing about category theory; most Haskellers don’t.)

Bit too harsh but I can see where you're coming from. Kotlin with the Arrow library for Functional Programming is a nice balance between nice guarantees and correctness of Haskell and practicality IMO.

I have the opposite experience. A year of using Haskell for my side projects taught me more about how to make code production ready than years of Java.

But I suppose it depends on the environment you end up with. All the Java I did was with people where you could get away with murder in the code. All the Haskell I did was with people who carefully consider network failure, memory usage, readability, timeouts, pathological logging loops, etc., and would push back on code that isn't easy to use, maintain, and troubleshoot.

I have a similar experience and I agree. I think there is a solid, relatively practical language hiding under all the language extensions, but the never ending desire of the community to solve problems of abstraction vs. real user problems makes it a dead end in terms of time spent.

And funnily enough, the time I've spent really learning shell/awk/sed (pretty much the exact opposite of Haskell!) was one of the best investments of my career!

I don't think I even know what you mean by 'how computers really work'. Isn't the point of languages to create abstractions so I don't need to learn how a CPU works?

I understand why Haskell will never become the language of industry. Lazy evaluation, a hundred and one extensions, the fact you would need to retrain everybody... but I'm not really interested in that. Haskell is a place for ideas, not really practicality. This has been gone over time and again.

The reason I use Haskell for personal projects is because they all end up being very few lines of code compared to imperative versions, and it usually just works. For me that's enough benefit to learn it.

It would be nice if an ML language actually became popular at some point. But that won't be for a long time.

Totally agree with you here: Haskell is only good for programming in the theoretical language of computation, something like the pure lambda calculus. This is an easier way to think logically for some people. For others it's simpler to conceptualize in the physical language of computation, something like shifting the tape back and forth on the Turing machine. In this case C++ and Erlang win the day without questions. Haskell is cool (and even rumored to be useful) but there may never be a world changing unicorn using it as their daily driver.

Haskell can also be very useful for practical real world programs, not just researchers. Check out IHP: https://ihp.digitallyinduced.com/ This might change your mind a bit :-)

> Almost nothing has carried over to what companies use or want day to day

I wonder what is your view on functions and local variables? Do you find structuring programs with them useful or just an academic exercise?

I had the "privilege" to work with assembler programs, written in 1970s and 1980s, that were mostly one big procedure, with a huge bunch of shared global variables. Back then, it was very efficient way to program (that's why it was used), and down to metal. But it was unmaintainable mess.

(And that's what we want from a compiler - to transform program from maintainable and somewhat abstract description down to unmaintainable spaghetti that can be, however, executed very efficiently.)

Pure functional programs are just taking it step further, saying that most functions shouldn't need full access to their execution environment (operating system). The result is, supposedly, even more maintainable programs.

I have learned a ton of things that didn't carry over to what I do in the industry. That doesn't make those useless, unpractical theoretical BS.

The issue with your POV is, IMO, that you lack imagination for how vast the industry really is. There are millions of problems that are being solved with Python, PHP, Java, you name it, that can as well be done with Haskell. And constraining those solutions through the lens of "how computers really work" is unpractical, theoretical BS.

Let’s be honest with ourselves: like 90% of the whole industry is writing CRUD apps, which are complex the same way history is — there is plenty of detail, differing accounts of how one thing happened, but in the end, the actual process is quite trivial. It could be an excel table if it scaled and would have nice to use interface for end users. While these programs definitely have depth and long-running projects grown to such size that no one person can hold it in their head, I have to say they are not difficult to program at all. So they can be written in literally everything.

But let’s take a compiler backend or a JIT compiler — you may very well need much more powerful abstractions for these, and having the language help you with that can be a huge boost. In this area, the concepts you may have learned would definitely apply much more often.

You've probably been using IO monads as long as you've been programming: [Unix pipes as IO monads](https://www.okmij.org/ftp/Computation/monadic-shell.html)

Haskell for Imperative Programmers [0] is the best material I've come across recently for Haskell beginners.

[0] https://www.youtube.com/playlist?list=PLe7Ei6viL6jGp1Rfu0dil...

Shameless plug for something I wrote :P

# Lambdas, Functions, Functors and Monads

Even most OOP programmers are now familiar with map and, having used it quite a bit, have an intuitive understanding of what any given call to map will do.

Does anyone know a bit more about map, what it is and where it came from?

## Category Theory

A lot of Functional Programming derives from a field of Mathematics called Category Theory.

Very briefly, Category Theory is the study of functions, where "function" refers to a process that associates to each element of a set X a single element of a set Y.

Pure functions have only inputs and outputs- no access to anything other than what was sent in, and no ability to mutate what was sent in or generate other side effects.

Now, I suck at math, but fortunately we don't need to know math to learn more about concepts programming languages have borrowed from Category Theory.

Learning about it can make us better programmers if we go from an intuitive, but maybe a bit vague, understanding of things like map to fully understanding them!

## Functor (map)

A *Functor* is anything that can be mapped over. Map, the defining function of a Functor, is quite simple.

  interface Functor<A> {
      fun <B> map (function: (A) -> B) : Functor<B>
  }

This just says

> Given a Functor of A, when map is called with a function of A to B, return a Functor of B

### An example

This is all just a bunch of mumbo jumbo, but in our day to day programming, Functors (or potential Functors) are everywhere!

Lists are a great candidate for a concrete example.

  class BoringList<A>(val backingList : List<A>) { }

The above class is just a wrapper (with no added behavior) around a list. Let's make it do something interesting by declaring it a Functor.

  class InterestingList<A>(val backingList : List<A>) : Functor<A> {
  
    override fun <B> map(function: (A) -> B): InterestingList<B> {
        //implement - DON'T CHEAT by simply calling map on backingList
    }

  }

  fun main(args: Array<String>) {
      //experiment
  }

Example implementation (very imperative, but that's ok)

  class InterestingList<A>(val backingList : List<A>) : Functor<A> {

    override fun <B> map(function: (A) -> B): InterestingList<B> {

        //the current InterestingList is of type A but we need to return
        //a InterestingList of type B, so first, make a new backingList
        //of type B
        val transformedList = ArrayList<B>()

        for (item in backingList) {
            //apply the provided function to each item
            val transformedItem = function(item)
            //add them to the transformedList of type B
            transformedList.add(transformedItem)
        }

        //return an InterestingList of type B
        return InterestingList(transformedList)
    }

  }

  fun main(args: Array<String>) {

    val interestingList = InterestingList(listOf("foo", "bar"))

    //when calling map on InterestingList<String> with a function: (String) -> Int, we get InterestingList<Int>
    val mappedInterestingList = interestingList.map { string -> string.length }

  }

### Other examples

Now, we've used List as an example, but remember: Functors (or potential Functors) are everywhere! It's easy to think of Functors as "containers", but it's more useful to think of them as a "computational context", since eg Options and Futures can also have map.

* The Functor of List applies the function to all elements in the list

* The Functor of Option applies the function if it's non-empty. (or rather, any function applied to Nothing is still Nothing)

* The Functor of Future applies the function to a result once a result is available.

### Functor laws

Now, can someone think of a few important things to keep in mind when implementing map?

Eg, what if your implementation of map for a List always returned an empty list, or a list twice the size of the given list? Or what if it mutated the items it mapped over, or called a bunch of other god knows what functions? That would be not so good!

So when implementing Functors you actually have to observe the Functor Laws. There is nothing mysterious about these laws; their role is to guarantee map behaves sanely and actually performs a mapping operation (as opposed to some other nonsense). The first law is:

  map id = id

id is the identity function, which returns its argument unaltered. The first law states that mapping id over a functorial value must return the functorial value unchanged. Next, the second law:

  map (g . f) = map g . map f

It states that it should not matter whether we map a composed function or first map one function and then the other (assuming the application order remains the same in both cases).

## Monad (flatMap)

A *Monad* is anything that can be flatMapped over. Sounds scary! It's actually surprisingly easy to understand, but can be a little more complex to implement. Don't feel bad if you don't get it right!

FlatMap, the defining function of a Monad, is quite simple.

  interface Monad<A> {
    fun <B> flatMap (function: (A) -> Monad<B>) : Monad<B>
  }

This just says

> Given a Monad of A, when flatMap is called with a function of A to Monad B, return a Monad of B

If you recall Functor

  interface Functor<A> {
    fun <B> map (function: (A) -> B) : Functor<B>
  }

Which just says

> Given a Functor of A, when map is called with a function of A to B, return a Functor of B

The two are EXACTLY the same except instead of a function of A to B, it's a function of A to Monad B.

### An example

Let's return to the concrete example of the list: if you call map on your list with a function of A to List B, what will you end up with?

You would end up with a list of lists! And all flatMap does is "flatten" that into a single list.

  interface Monad<A> {
    fun <B> flatMap (function: (A) -> Monad<B>) : Monad<B> //yes!
    fun <B> flatMap (function: (A) -> Monad<B>) : Monad<Monad<B>> //no!
  }

Implementing is left to the overachievers.

### Other examples

Remember: just like Functors, Monads (or potential Monads) are everywhere!

* The Monad of List flattens lists of lists.

* The Monad of Option allows chaining many potentially absent things together, short circuits if any of them are empty, and returns a flattened end result.

* The Monad of Future allows chaining together computations that don't have a result yet, and returns a flattened end result.

### The Monad laws

Just like when implementing map for Functors the implementation must satisfy the Functor Laws, when implementing flatMap for Monads, the implementation must satisfy the Monad Laws. I will not get into them here, but for anyone who's interested this is a great resource https://en.wikibooks.org/wiki/Haskell/Understanding_monads

## A missed opportunity

As we've seen, map and flatMap really shouldn't be these random functions that sometimes get added to things and sometimes not. Functional programming languages usually have an interface Functor, and an interface Monad etc which all classes that implement map and flatMap extend, and there's no reason why it shouldn't be like that in Java or Kotlin as well.

Unfortunately, neither Java nor Kotlin do this, which is kind of a missed opportunity.

## But why?

Most of us instinctively reached for looping language constructs like `for` and `while`.

So since we're so used to that, where's the benefit in all this new map, flatMap etc nonsense? It's difficult to understand, hard to read etc etc.

A few differences could be pointed out.

### An example

    //this looks fine but will actually blow up, can you tell why?
    int[] array = {1, 2, 3};
    int[] doubled = int[array.size];
    for (int i = 0; i <= array.size; i++){
        doubled[i] = array[i] \* 2;
    }
    //even if it didn't blow up, there's still a lot of noise about *how* to
    //double that is completely besides the point of *what* we actually want,
    //which is simply to multiply the items by 2

#### Imperative vs Declarative

loops describe in detail how to do something while map hides implementation details and let's you focus on what to do. And since describing in detail how to do something isn't required, the risk of bugs in the how part is completely eliminated.

#### Stateful vs Stateless

loops are literally stateful operations where we're, well, looping through a collection item by item (in a certain order) using something to keep track of how far we've looped. Sometimes the state matters to what's happening inside the loop, eg when we find what we're looking for and return early. Mapping operations have no such state, so the risk of bugs due to state are completely eliminated.

#### Meaningless vs Meaningful

loops have no real meaning. Eg, it's possible to loop through things and do nothing, mutate the items as you loop through them, mutate the collection you're looping through, return something from an enclosing method... Loops can do anything. Map on the other hand is a specific thing, has a specific use case, does no more and no less, makes guarantees as to what it does and doesn't do etc etc. This allows us to reason about code more effectively than with loops where we have to play compiler and debugger and keep a bunch of state in mind all the while trying to understand what's actually being done inside.

These are just a few examples, I'm sure more could be thought of!

A monad is just a monoid in the category of endofunctors

I think monads are what we would ordinarily call "environment" or "context" of execution. Monad just describes how to compose the interactions with the context. Usually this is some serialization of these interactions but can be other things.

IO monad is where the environment (context of execution) is just your entire operating system. In imperative languages, this is a normal state of affairs, but functional programmers view that with similar suspicion that most programmers of today view global variables.

That's why in general "different monads don't compose", because it's like trying to compose two different environments (as we know, for example, porting between different OSes is not trivial). You can define it (with monad transformers) but it's often a lot of work.

One advantage of monads is that they can communicate via the type that a function is not pure. I remember a serious bug in a trading system (distributed over multiple time zones), that was caused by Java's toString reading the system locale from the OS. In Haskell, such a function would have a type that makes it clear the function is not pure, e.g. toString : Date -> IO String.

Monads are not the only way of tracking effects in the type, but they are one way. For example, Java has "checked exceptions", which also represent an effect in the type system.

Monads also allow one to assemble a computational ready for execution later. One can therefore write an Async library, without needing baked-in language support.

If you've ever used a language like Rust that has sum types, and you've gotten a Option<T> from a function and wanted to put it into some other function that takes a T, then you have a good intuition for what a monad is. Monads unwrap the T from the sum type so you can chain those kinds of function calls.

This is relevant for IO because it can maybe fail.

I gave a try explaining it the easiest way I could here: https://news.ycombinator.com/item?id=28844533

That just gets better and better

`Monad is just a cute name for flatMap`

Hahaha! I swear this is exactly how I feel halfway through every monad tutorial I find.