> Monads really are just a convenient way to build up action values

Except when they aren't, because lists/arrays (with map) and Maybe (with map) and .. are something totally different. And that's the problem with _all_ these monad tutorials/how-tos/...: the problem is, that monads (and functors) are not burritos or elephants but _both_. So they are hard to understand looking only at a single instance.

Btw. monads are not the only way FP deals with effects, see algebraic effects. https://github.com/yallop/effects-bibliography https://www.youtube.com/watch?v=DNp3ifNpgPM

Haskell without laziness is Purescript, btw.

  actA >>= \a -> 
  actB a >>= \b -> 
  pure doSomethingWith b

  actA(a => 
    actB(a, b => 
      doSomethingWith(b)
    )
  )
      

- as of now it's tied mostly to the JS ecosystem and runtime(s): that means no TCO, which _really_ hurts when using monads that require on a lot of recursion. And in fact purescript sometimes has to take a performance penalty and use specific trampolined stack-safe monads to avoid stack overflows

- Haskell layout rules may be complex, but purescript's break in weird and unintuitive ways (by layout rules I mean the indentation-sensitive syntax)

- Haskell is catching up on _a lot_ of the feature that made/make purescript great (mostly talking about syntactic things right now, like RecordDotSyntax, QualifiedDo, BlockArguments...)

- as it turns out, when programming "Haskell-style", laziness is really damn effective. So many times I've had to forcefully (and painfully) introduce laziness in purescript to make things behave well...

As much as I like purescript, I think if you want that kind of strict programming, maybe OCaML or a derivative thereof (or maybe even ReasonML/Rescript?) would work better? I feel like whenever I use purescript it looks so similar to Haskell that I try doing things the haskell way and it just doesn't work, and the "purescript" way will often look weird to a trained haskeller.

But even so, I think something is lost in reducing monads to a clump of related behaviors and properties. You still need intuition about what these behaviors actually mean and what kinds of real-world objects actually conform to these properties.

So you are right that monad "is not" a nondeterministic computation or a container or whatever, but a monad "is" a common set of behaviors/properties that we should expect nondeterministic computations and containers to conform to.

Abstraction without intuition is obfuscation!

[1] https://en.wikipedia.org/wiki/Eternalism_(philosophy_of_time...

Functional programs don't _do_ anything, they are a list of commands some external interpreter (what you call the runtime, but doesn't have to be a runtime) will execute or compile.

Functional programs only contain descriptions of the various commands, but it is an external interpreter executing the commands.

Functional programs return "recipes".

"recipes" are picked up by some executor that will turn them in dishes (the side effect).

If all of this seems generic allow me some typescript.

```

// we can declare a a function that takes no argument and return a value IO.

type IO<A> = () => A

declare const program: () => void; // thus can be rewritten as

declare const program: IO<void> // this is the PURE function I can reason about

declare const execute: IO<void> => void // this is the interpreter that will execute the commands and have side effects

```

Now, let's declare a side effectful functions:

```

const log: (s: string) => IO<void>

// desugarized: (s: string) => () => void `` `

Notice how the signature is similar to the standard console.log: (s: string) => void

except that it's lazy. Laziness is one of the most convenient ways to express "commands" rather than side effects in a language like JavaScript, but there are also alternatives.

Now we can have a pure program that logs to the console some string.

`log("foo")` does not "execute" any console.log, it still needs to be executed:

```

const program: IO<void> = log("foo");

// program() will actually print "foo" in stdout

```

Note: we could've encoded IO in different ways, e.g. with a struct/interface rather than a function and had the interpreter actually reason about the side effect on its own.

Now, the only missing part is: how do I compose such IO functions together? Well, there are various ways but the most common ones are applicative functors and monads. I am not going to delve deeper in this comment on those topics because it would take long but I hope I have transmitted my point:

in functional programs you return programs (I like to think about them as recipes, recipes don't DO anything), those programs may compose effectful commands, the actual execution of the commands is shoved inside an external interpreter.

This is quite obvious in some languages like Haskell, it's less obvious in others.

But why would someone want to do this? It feels like mental overhead. So what advantages are there to a system like this?

You never have to reset state if you do not have it in the first place. You get other bugs still, but you don't have the most common class of bugs.

But, you need some state. You just want to discourage it. Some of it can come from laziness, but with difficulty. (Chris Okasaki’s Purely Functional Data Structures uses it to de-amortize the bound on a FIFO queue.) Other things, like ring buffers, are harder to argue.

So you want to be able to express an array of IORefs, say, for your ring buffer. But the people who use it become aware that it is a stateful construct and must be used that way.

Read “what color is your function?” for a counterpoint, of course.

  a = f()
  b = f()
  c = g(a, b)

  a = f()
  c = g(a, a)

This may (not) make programs easier to reason about.

The laziness allows the pure language constructs like "if" to be lifted up into the IO value. That is, if you embed an if statement into one of the (pure) functions used in an IO value somewhere, only the branch that the "if" would take is ever evaluated. However, technically speaking, you can also look at the branches happening for all inputs; if you input a true or a false from the user, you can look at that as a true branch, a false branch, and some additional error branches, even if the code doesn't look like it. A strict language would not permit this. (Though even in a strict language, real-world useful IO values end up with enough function calls in them that a strict language wouldn't manifest the full tree either.)

If you input a full Int32, you can look at that as defining 2^32 possible branches in the IO value, and the execution will take one of them. In reality, the program does not do 2^32 different things, and a better view of what the program is doing is the more conventional one for almost every purpose. (Although that view will still pass through a lot of possible states!) But in terms of understanding how the IO value is "pure", this view is momentarily helpful.

The only operation in a Haskell program that violates this is unsafePerformIO, which really does penetrate this abstraction and work like a "normal" program. Otherwise, no matter how much Haskell code you write, technically all you're doing is making a bigger and more complicated pure IO value, which defines how to have an effect on the world but does not itself have an effect on the world. Executing the program is what finally puts the two together.

To put it another way, Haskell has a completely clear separation between being a program and executing a program. If I say to someone, "pick up that glass, fill it with water, and water this plant", that statement is itself a "pure value". The execution of that statement is where things get impure. Some languages do not have this clear separation, most notably Perl but the dynamic languages in general don't. Many others do, as having a compilation step all but forces this sort of separation, they just don't think of it that way and there can be leaks here and there, and features that may blur the line deliberately. Haskell does have a very clear separation, and in that separation, with laziness, it is almost like IO is just one big macro language for putting together programs, in some sense beyond what even Lisp would dream of.

And in another sense it's just a funny way to write conventional programs with really weird pretensions, and there's a certain value to that point of view too, which is that when you're done blissing out on the hippie math juice, when you actually sit down and write code in Haskell you're doing much the same thing you do in any other language and treat IO just like any other source code. But, as with the story of enlightenment... "first it was a mountain, then it was not a mountain, then it was a mountain again"... where you end up on this journey is not quite the same as where you started.

Or simply

input -> fn1 -> fn2 -> fnn -> mutate!

Where 'fn' are all immutable.

Example: input “I step forward”, output “monster appears”, next input “I try to shoot it”.

That second input wouldn’t be there if the output weren’t executed.

  input -> fn1 -> fn2 -> fnn -> mutate!

In any case, what I'm going for is that in both imperative and functional programming languages I would have a function/method like "handleInput" that takes an input and decides what to do with it. The difference would be that in a classical OOP setting handleInput would be a method of your GameState class [1] while in FP handleInput would look something like "Input -> (GameState -> GameState)", i.e. a function that takes an input value and returns a function that transforms the game state in some way (alternatively and equivalently, thanks to associativity/currying: a function that takes an input value and a current game state and returns a new game state).

[1] I know, this obviously is a very contrived example, it'd only work for very simple games. Game programming patterns are interesting but not the focus here.

I had real performance problems a while back attempting to build a very large file, my code could only produce the write instructions out of order and the file was too big to hold in memory, so what I ended up doing was writing writing instructions in radix-grouped batches to a bunch of temporary files, and then reading and evaluating them to build the large file.

This seems counter-intuitive, as it more than doubles both the amount of data written to disk as well as adds a reading-step, but doing it this way means the data is written in a way the hardware can deal with a lot more efficiently. Sequential access to and from the instruction files (off a mechanical drive), and densely clustered writes to the big output file. (on an SSD, strictly sequential writes matters less than being in the same block)

This reduced the runtime from several hours to like 5 minutes.

For example, it took me a while to realize that most of the it's actually faster to read/write compressed data overall - you'd think that reading from a disk and decompressing the data would be slower than just reading uncompressed data from a disk directly, but due to the vast difference in disk IO performance and CPU decompression performance it's almost always faster to perform disk IO compressed. I'm writing almost always since I'm not sure how the tradeoff looks for current high performance PCIe SSDs (or other storage devices with very fast IO).

That doesn't sound right.

Not that I've ever seriously tried to learn Haskell, but in the past every time I've lazily come across an article about it it's always seemed like a bizarre confusing world, even though I know how functional programming (in the sense of purity) works.

Now there's just one thing missing. We all know what this style of programming is. It's asynchronous programming with callbacks. Seriously, Haskell folks, if you started with "all side effecting functions are kind of like async operations with a completion callback (the stuff people do in JavaScript all day), and then we have some syntactic sugar to make it suck less" you'd have a much easier time getting people to wrap their head around all this.

(Yes, I know the details aren't exactly the same, but drawing parallels to stuff people already know matters)

Seriously, this idea of there being a central effect dispatcher (the bit that runs `main` behind the scenes) is so eerily like the coroutine scheduler in async coroutine paradigms that I can't believe more people haven't drawn parallels between these programming styles.

If people stuck to just explaining the IO monad specifically, which is a lot like async code with callbacks, then things would be better.

I wrote about this a few years ago: https://two-wrongs.com/the-what-are-monads-fallacy

I think you're right in saying that async is not representative of all monads, but it does help with questions that many beginners have, like "How do I get the value out of the maybe/IO/your-monad-here?"

The async analogy works for some monads like ST and IO and whathaveyou but it's not generally useful, due to the wide variety of types that are monads.

In contrast, there are easily understood reasons to use the monad interface of a promise/async. That's why I think it's a good monad for understanding the structure of monadic binding.

The way I see it is kinda like this, and I hope it makes some sense to others:

You can get the value out of a list... but there might be many or none. You can get the value out of a maybe... if it's there. You can even get the value out of the async function... but you'll just have to hold up what you're doing to wait for it.

This kind of (roughly) non-determinism is how I understand the concept of "effect", which is what Haskell frequently uses monads to model. A function returning a `M a` becomes "deterministic" (it always returns an `M a`) and benefits from the sort of equational reasoning that we like.

To be clear, the use of monads to represent effects is a software engineering decision and not inherent to monads.

It's definitely helped my understanding and I suspect it would help others too.

Self-plug: I even wrote a short post about this quite recently, after making a similar comment on HN (https://frogulis.net/writing/async-monad)

Probably the best reason to use FP imo. It just cuts out so much overhead when trying to read other people’s code.

In ML languages, code forms a beautiful tree structure where you can see the binding definition of each binding by looking down and right.

    let x = 
      something
      really
      big 
      and 
      complicated

    let x = null;

    x = something();

    x = somethingElse(x);

    x = anotherThing(x);

something(x, result);

somethingElse(result, result2);

anotherThing(result2, result3);

with the occasional surprise mutation when you just have to do

something(x)

and x contains the result.

I also got caught recently with MomentJS with that one when doing mydate.add and discovering it also mutated the original instead of just returning the result.

I'm a very average programmer and far from a FP purist (I mostly use JS and Rails) and I'm surprised how much I now use some FP principles and how it feels very natural to me.

C# extension methods aren't the perfect solution for this, but I love that they exist to at least make chaining possible without needing to modify the class that I'm applying the function to. D has an even better version of this called UFCS which makes it so `Bar something(Foo f)` can either be called as `something(x)` or `x.something()` without needing any special annotations like C# requires.

To illustrate:

    let x = 
      let mutable maxScore = 0
      
      for item in items do
        if item.Score > maxScore then
          maxScore <- item.Score

      maxScore

    const x = 
      (() => {
        let maxScore = 0;
        
        for (const item of items) {
          if (item.score > maxScore) {
            maxScore = item.Score;
          }
        }

        return maxScore;
      })();

Extension methods are definitely useful in OOP languages. However, a much cleaner language design is to remove the need for a "class" altogether and just have free-functions, function composition and a pipe operator.

None of this is something you can't simulate in OOP / procedural languages, it's just much more clunky.

    let x = anotherThing(
      somethingElse(
        something()
      )
    );

    let x = anotherThing(
      somethingElse(
        something(
         x, y, z
        ), 1, 2, 3
      ), "a", "b", "c"
    );

    let x = anotherThing(
      somethingElse(
        something(x, y, z),
        1, 2, 3
      ),
      "a", "b", "c"
    );

Well, actually I agree with you - sometimes. I have actually written helper functions to get similar pipeline processing capabilities in js.

    function pipe(...args) {
      return args.reduce((x, fn) => fn(x), null);
    }

    pipe(
      () => 2,
      (x) => 7*x,
      console.log
    )

I have a tidbit in the first paragraphs: http://blog.vmchale.com/article/effects

Certainly laziness has influenced a lot of things in the world of FP. But it's really helpful to distinguish laziness from FP, especially considering the problems that laziness introduces.

I mean, I get where you're coming from, but the thing that you've described is that a monad and there's not an easy way to get it there.

But yes, I am with you, you want to explain to someone that Haskell's model of side effects is a sort of metaprogramming, much simpler than macros, we just give you a data type for “a program which does some stuff and eventually can produce a ______” and ask you to define a value called `main` which is a program which produces nothing special. And it's the compiler's job to take that program and give it to you as a binary executable that you can run whenever you like.

You also want to give people a number of other examples of things that are monads. “a nullable ____”, “a list of ____s,” “an int (summable) with a ____,” and maybe an example that is not like “a function from ____s to ints,” or “a set of ___s.”

The key to telling someone what a monad is, involves trying to explain to them that in some sense “a program which produces a program which produces an int” is not terribly more descriptive than just “a program which produces an int.” If you can combine this with the adjective being outputtish and universal you have a monad.

Ultimately, that's very similar to what old-school ways of declaring Promises do in Javascript. You're creating a data structure that you then attach a new function to execute with the results.

What we talk about when we have about monads is the highly generic interface coupled with the highly generic combinators. This is not something shared by arrays and promises. In other words, none of them are monads in any practically meaningful sense.

It's not "practically meaningless"; it's depth-first-search logic programming (as per How to Replace Failure by a List of Successes https://rkrishnan.org/files/wadler-1985.pdf )

Yes, and monadic code suffers from the same problem, that's why Haskell has do-notation

   do 
     b <- fun1 a
     c <- fun2 b 
     pure c   -- using Purescript's pure instead of Haskell's `return` 

   bind(fun1, (a) => bind(fun2, (b) => pure(b)))

E.g. you may have a dry-run function that doesn't actually change the state but only describes what it would do. Or you could have a function that generates a verbose log of all steps executed. Etc.

That doesn't necessarily work for IO, as that gets special treatment by the runtime, but you can do it with your own types.

I do understand that in reality it's simply a tag value to ensure that the compiler correctly orders and threads operations correctly, but I still think it's semantically cute :D

FWIW C and C++ also have this operator, it does bitwise right shift assignment there.

Erlang is a functional programming language and doesn't need to jump through hoops to do side effects.

So is OCaml. So is...

You could finagle your way around that, but the result would be something like unsafePerformIO in current Haskell, where it's hard work to ensure that it's used correctly.

No where was this more apparent in my career then when I was on a team of Scala-using FP programmers who were building part of a real hardware provisioning system (and the org structure tipped in their favor) - the number of arguments about the sheer amount of things which can and definitely would go bad across hundreds of servers when you tried to do things - versus their desire to ignore these problems as infrequent so they wouldn't have to try and code the handling in a functional way (FP is terrible at logging, so even getting that done adequately was an argument).

Basically the paradigm does tend towards collapsing once the problem grows too complicated for someone to keep in their head because it actively fights the sort of procedural reasoning humans do pretty much natively in favor of dealing with abstract math which very few people are any good at.

I gave an internal talk about FP approaches like .map, .flatMap, etc. (as well as `Try[T]`). Although I didn't call it "FP", I called it "type-safe error handling" (i.e. `null` and `throw e` lie about their types, and are hence not type-safe)

Um, what? You can't just drop this without elaborating. I've never seen anybody have problems logging in a functional language.

The thing is, if for some reason you really think you need to log inside a pure function, you either need an intermediate variable or your perceived needs are severely misguided.

And here we see a person slinging unsubstantiated accusations

> if for some reason you really think you need to log inside a pure function, you either need an intermediate variable or your perceived needs are severely misguided.

Clear demonstration of "it looks like hardly anyone is doing any useful logging in Haskell".

Because, as we know, the fact that "you can repeat an execution" immediately makes your need to log anything in that execution as "misguided".

Not really, unsafePerformIO has its place - just its not in typical Haskell programs.

Haskell is referentially transparent, but you can't say the same for many other FP languages like erlang, or ocaml.

I do not consider the attempts of making the entire language referentially transparent and the exclusive use of lazy evaluation, like in Haskell, as being useful.

Obviously there are people who like these features and who use Haskell, but in any case whenever FP languages are mentioned they should not be reduced to those that have made the controversial Haskell choices.

Lisp, Scheme, Common Lisp, Clojure, Raket, Caml Light, OCaml, Standard ML, F#, Scala, MLton, Concurrent ML among other lesser known ones.

> ipfs resolve -r /ipns/nauseam.eth/coding/random/how-side-effects-work-in-fp/: no link named "coding" under QmdzzonFE9eX6FGs8UbCyoC2XS5NQjaG6gaqhgeUyTHnag

It's really hard to take someone serious when they make big, untrue, statements saying the real web is "centralized" right on every page of their site, to peddle crypto scams.

https://chadnauseam.com/reasoning-quiz

> Neo-Nazis are holding a demonstration in a small town, waving swastikas around and shouting about Hitler. They seem to be pretty peaceful so far, so the First Amendment says you probably can’t get rid of them. However, their demonstration is near a main street and it could be a minor inconvenience to the traffic trying to go through.

>

> [ ] Allow the neo-Nazis to demonstrate.

>

> [ ] Break up the demonstration on the grounds of ‘blocking traffic’.

I am at a loss for words. Nazi sympathy under the guise of tolerance.

Well, it's not completely centralized, but it's more centralized than using IPFS for the backend and ENS for the namespace. I think that's hard to debate right? If I take down my server right now chadnauseam.com will go down for everyone. But if anyone has my IPFS page pinned, it will stay up for everyone no matter what I do (barring exploits in IPFS I don't know about). So in that sense it really is more decentralized.

> Nazi sympathy under the guise of tolerance.

I don't understand why you see a quiz that gives you the option to pick either way as promoting one option over the other

That is, this code:

x = foo()

y = bar(x)

z = bar(x)

Should mean the same thing as:

y = bar(foo())

z = bar(foo())

Because it's obvious to anyone that has written any sort of complex program that those are not the same thing. foo() can be an expensive operation like an HTTP call. Or it might depend on a database which can change state underneath it.

I assume FP has answers for these things but the tutorials never cover them. They all imagine a world without state or expensive operations to show how wonderful it is. And that's an easy world to program in.

They are the same thing in Haskell (except for when forcing the thunks into eager values happens, due to the weirdness of laziness, but that has nothing to do with purity).

> I assume FP has answers for these things but the tutorials never cover them.

Except this one does:

> The <- works like an =, except it signals that equational reasoning doesn't apply to this value. You can't replace what_the_user_typed with getline - your program won't compile.

That just raises a different problem:

y = bar(generateUUID())

z = bar(generateUUID())

>Except this one does:

It doesn't explain it in the context of real world programming.

    y = bar(generateUUID()) 
    z = bar(generateUUID())

  yuuid <- generateUUID
  zuuid <- generateUUID

  y = bar yuuid
  z = bar zuuid

Yes that's true, and it's unfortunate.

  import System.Random

  randomInt :: IO Int
  randomInt = randomIO

  isEven1 :: Int -> Bool
  isEven1 n = (n `rem` 2) == 0

  isEven2 :: IO Int -> IO Bool
  isEven2 n = do
      m <- n
      return $ isEven1 m

  example1 :: IO ()
  example1 = do
      i1 <- randomInt
      let result1 = isEven1 i1
      putStrLn $ show result1

      i2 <- randomInt
      let result2 = isEven1 i2
      putStrLn $ show result2

      let result2' = isEven1 i2
      putStrLn $ show result2'

  example2 :: IO ()
  example2 = do
      result1 <- isEven2 randomInt
      putStrLn $ show result1

      result2 <- isEven2 randomInt
      putStrLn $ show result2

  randomIntIsEven :: IO Bool
  randomIntIsEven = isEven2 randomInt

  example3 :: IO ()
  example3 = do
      result1 <- randomIntIsEven
      putStrLn $ show result1

      result2 <- randomIntIsEven
      putStrLn $ show result2

  main :: IO ()
  main = do
      putStrLn "Example 1:"
      example1
      putStrLn "Example 2:"
      example2
      putStrLn "Example 3:"
      example3

In example2, result1 and result2 may differ, which is signalled by "<-" (instead of "=").

In example3, result1 and result3 may differ, which is signalled by "<-" (instead of "="). Another argument here is that they may differ, because example3 is the same as example2, except it used randomIntIsEven in place of isEven2 randomInt. But we defined randomIntIsEven to be equal to isEven2 randomInt, so result1 and result2 being able to be different in example2 but not in example3, or vice versa, would be a contradiction.

  generateUUID :: IO UUID

  uuidY <- generateUUID
  y = bar uuidY
  uuidZ <- generateUUID
  z = bar uuidZ

  y = bar =<< generateUUID
  z = generateUUID >>= bar

Side-note #2: that's actually not too far away from how random number generators work in haskell: either you pass the state around, or you do it in IO.

Not in Haskell! I recommend reading the rest of the post.

This isn’t even special to FP, it’s a basic problem when building a compiler, namely whether inlining/common subexpression elimination is beneficial.

To drive the point home, even in a language like Haskell these two examples might have a factor of two in execution time between them.

Case 1:

x = foo()

y = bar(x)

z = bar(x)

Case 2:

y = bar(foo())

z = bar(foo())

In case 1 the value of x must be kept in memory across the entire execution of bar(x) since you need it for the second invocation of bar. In case 2, the result of foo() can be discarded once bar is done with it.

To use a contrived example, imagine a program that has 100 mb of available memory.

foo() returns a data struct that is 95 mb in size.

def bar(some_big_data_struct)

   some_small_data = some_big_data_struct[:some_key]

   [A bunch of other code that allocates and then releases 90 mb]

   return some_other_small_data

In Case 1 I get an OOM error. In Case 2 I (or the runtime) can reclaim the 95 mb that some_big_data_struct uses and the program works.

Clearly that's a contrived situation but it illustrates my original point. There's a huge gap between theoretical pure functions and what we have to deal with in the real world. These sorts of FP tutorials never go into the weeds and explore these problems.

It can't, in Haskell, because it's a pure language. That's basically the definition of pure! But you still need effects, even in a "pure" language, and the whole point of the article is about how to support effects in a pure language.