Are Monads a Waste of Time?

Surely there's a middle ground here. Most code written by university students in any language is problematic and not professional-quality. The specific deficiencies exhibited may vary from language to language. The extreme you illustrate here is clearly undesirable in any professional context, but that doesn't mean it reflects the code written by any professional Haskell developers out there.

The attraction of Haskell is to build correct software in a mathematically principled way. With practice, it is also remarkably productive, certainly more so than Go when used as a general purpose language. Haskell is simply much more expressive and capable of abstracting over many more things (perhaps this is why you say it is hard to read). The Haskell ecosystem is also constantly evolving and solving more and more real world problems, often problems that have not been solved in other languages. Modern Haskell effectful streaming libraries actually make reasoning about stream processing much easier than in say Java, where the presence of effects (exceptions etc) destroys reasoning.

> Go is now my favorite language.

Is this really true? Or is it just the tool you are now most familiar with? It's certainly a much more riskier proposition to try and feed the kids writing Haskell.

Quoting Rob Pike on Google's own Go programmers: "They're typically fairly young, fresh out of school, probably learned Java ... They're not capable of understanding a brilliant language ... So the language that we give them has to be easy for them to understand and easy to adopt."

The Go toolset can obviously get the job done, but I don't understand why it would be anyone's favourite language, it doesn't even sound like it's Rob Pike's favourite language.

Pure FP is just using math as its primary source of programming patterns and techniques, while most other languages, like OOP, use arbitrary conventions to abstract code. Because mutation gives you tremendous flexibility, you can model many kinds of patterns, give it some analogy like inheritance in animals, and then write a language that has it out of the box. Haskell on the other is using math to construct its patterns, so while the learning curve is higher, eventually you realize this is the ultimate abstraction (category theory), and it cannot go more abstract than that. This is useful in some scenarios requiring more logical rigor, but I agree it's not always the best tool.

I think Haskell is full of good ideas waiting to be reused in a successor language, with a focus on software engineering as well as just purity (Multiple senses of the term!) and rigour in abstraction.

The ideas are sound - When I write pseudo"Haskell" in other languages (Especially those with enforced purity), the rewards are fairly good for relatively little extra work - but Haskell (The language) is, even putting nicely, rough around the edges.

I never went to university and don't have a PhD.

I find Haskell prevents me from being too clever and keeps me honest.

Monads are a part of that toolbox which prevent me from using unconstrained effects in my code.

https://patrickmn.com/software/the-haskell-pyramid/

parts of it's type system has a lot of gnarly dark corners, but the those parts aren't necessary to line-of-business kind of programming. unfortunately, those are the ones that get discussed on social media - which it sounds like you were inundated in / attracted to

the core type system is pretty lean

This is pretty similar to what happened to me. I was implementing an algorithm that had multiple parts and the data would arrive asynchronously.

The first time, I wrote the multipart algorithm using a functional style to encode each state. As the algorithm grew, it became more and more difficult to reason about and managing dependencies between the parts was harder, not easier.

When this became unwieldy, I rewrote it. However, when I wrote it the second time, I wrote the algorithm in a way that made it appear imperative. Everything was linear, starting with part B, then part C, etc. A small backend managed state, but you could read through the algorithm code and it almost seemed like it would run synchronously.

The second method was easier to read, debug, and modify. I will probably not go back to the functional method anytime soon.

Haskell's value was never in actual "engineering" (someone somewhere is itching to point me to no fewer than 4 Haskell projects that nobody cares about) but rather in "research". To this day, I don't understand Monads, even though somehow I used the heck out of them in my C# days, and I loved "reactive" programming which also supposedly comes from Haskell, and for that - I'm grateful. Haskell tries dozens of ideas nobody but computer language theorists care about but, once in a while, something cool drops out that is adopted and made usable for mere mortals like myself.

Seems unrelated to the topic under discussion.

I’m in the same boat. I deep dived into Haskell for two years. It was fun and interesting at first but lost its appeal for some of the reasons you mention. I also enjoy using Go.

Even the creators of Haskell have conceded that lazy-by-default was problematic

https://www.google.com/search?q="the+next+haskell+will+be+st...

So true. Haskell is great to learn about functional programming and programming language theory in general. But to get things done, it's just not as practical.

you should try modern erlang. If you try really hard, you can get both the advanced abstract concepts plus obscure machine specific optimizations.

I'd encourage you to look into Kotlin. It's got the 20% of FP features that give 80% of the benefits, while still having generics and a thriving ecosystem (JVM). As someone with a similar personal trajectory, it really hits the sweet spot.

I'm sorry, but it just sounds like you're a terrible functional programmer. There are basic software engineering principles you need to use when using a functional language, just like any other programming language.

To emphasize, of course the monad interface isn't useful if the only implementation of it that you use is also the monadic implementation used by an imperative language. But if you "just" use an imperative language, you lose all the other implementations because the language hardwires the "conventional" one at the bottom. You lose the parser implementation of the monad interface, the free monad implementations (which are useful for writing "programs" that are then separated from their interpreter), the software transactional memory implementation, the probability implementation, the effects-controlling implementations (that go beyond "either in IO or not" to implement more granular controls), and the many other things that have been implemented.

Obviously that's ultimately a viable solution since almost every programming language works that way. But if you're going to ask "is the ability to implement the monad interface worth it for some given language?", you aren't going to get anywhere if you consider only one of the many implementations of the interface.

Why would anybody use the iterable interface if all it could do is the equivalent of "for (i = 0; i < arr.len; i++)" and couldn't iterate over a binary tree or hash table as well? Why would anyone use any interface if an interface only has one implementation, ever? The problem lies in the question, not the value of the interface.

(I'm trying to get better at phrasing my posts about "monads" better because one of the major problems they have is that people think of "monad" as a noun. But it is an interface, just like in Java or a Rust trait, that can be implemented by a type; it just so happens that the interface is not something that can be cleanly represented in most statically typed languages because of the high-order polymorphism. "Monad" is an adjective, not a noun. And "monads" aren't "about managing state" any more than the Iterable interface is about "incrementing an integer to walk over an array"; the conceptual error is the exact same kind in both cases.)

A little off topic, but I wanted to thank you for your comment ‘..delimits a stateful computation which can then be embedded in a pure one in a principle way’

I always think of it the other way around: I write pure code, and then embed the pure code in IO, etc. I tend to have boilerplate bits of impure code that I use as an after thought once I have pure code written and tested in a repl.

I think that to progress, I need to swap my view of Haskell, and spend much more time on the impure parts, and earlier in my dev process.

> For example, the continuation monad, which is just a library in Haskell, can't be implemented in most imperative languages without extending the language itself (async in JS, C#, etc).

I don't know about other languages, but the continuation monad is pretty trivial to write using promises. These can either be provided natively or using a promise library. It's a little more verbose than Haskell, but it's actually a useful pattern in JS.

https://codepen.io/anon/pen/JpLLJR?editors=0011

FWIW, I'm no JS expert, so its probably likely that there's a library out there that provide the functionality of applyAsync and composeAsync that I wrote.

Indeed, one of the advantages monads give is the abstraction over different types of computations with side effects (state, exceptions, non-determinism etc)

Great tutorial:

http://binaryanalysisplatform.github.io/bap/api/v1.3.0/Monad...

> delimits a stateful computation which can then be embedded in a pure one in a principled way

You probably meant to say smth different, but to many this reads like "you can embed and call impure code inside pure code while the pure code stay pure" which doesn't make much sense. I mean, you always do the opposite: embed/call pure code from the impure one.

Monads are not directly related to handling side effects. Or to the famous IO that you're refeering here. What a Monad does is to force sequencing by creating a data dependency.

Speaking of IO ...

In an imperative program you get guaranteed ordering of those instructions, but that ordering is thread local, meaning that the compiler, the runtime, the kernel, the CPU are all free to reorder instructions for optimal execution and ordering between threads is forced via memory barriers, which is in fact incredibly error prone.

In an FP language such as Haskell you get the extra problem that the compiler is even more free to rewrite and execute your code in any order it sees fit due to non-strictness and to referential transparency.

What the IO monad does is to "suspend side effects" and to force ordering on evaluation. And guess what, the IO monad is useful even in your average imperative program for describing concurrent logic.

Here are the implementations I contributed to:

1. https://monix.io/docs/2x/eval/task.html (Scala)

2. https://github.com/typelevel/cats-effect (Scala)

3. https://funfix.org (JavaScript)

If you've ever worked with JS Promises, think of IO as a non-broken, pure, awesome alternative.

And this is just IO. There are other monads as well. List is a monad, Option and Either are monads ;-)

---

I recommend you let go of your misconceptions and do some learning because this is a freaking useful concept.

The separation of pure and impure code in Haskell isn't something inherent to monads but is instead a side-effect (hah) of the typing rules of the language. It's easy to see how this separation need not hold when using monads (look at any monad library in virtually any other language), but more importantly there are ways to accomplish this separation without the use of monads (an effect-tracking type system is being developed along side OCaml's algebraic effects/multicore project).

> The benefit of State and IO monads is not that you can use them everywhere so you now have an imperative language. The benefit is you can explicitly delimit their use, and you still get the "easier to reason about" for the rest of the code.

It is also important to note that apart from providing the ability to write imperative code, monads encapsulate computation. In my understanding, this is where their use shines. Getting to wrap values in such contexts in certain imperative languages could be tedious. Using a monad, one passes around the value within the context of the monad. There is a computation(aka context) that is associated with the value in the monad and that computation is performed before a value is yielded.

I agree, but Monads also simplify non-blocking concurrent programming, allowing users to think sequentially, see F# Async and Haskell IO. C# had to add Async/Await support in the compiler and I would argue it is not as pleasant as the F# version using Monads.

There are some monads (or things close to monads) that are quite common in imperative languages. Java has

  - CompletableFuture  
  - Optional  
  - Stream  
  - dependency injection can be seen as a monad

Agreed. The "islands of immutability" approach.

Monad is practically synonymous with choice. Any time you multiplex on whatever is represented by a thing to choose a different thing, you're doing a monadic operation whether you want to or not. The difference is whether or not your language has libraries for this or you have to program it yourself every time.

I really like D's approach instead. A function declared pure can have no side effects but it can do whatever kind of mess it wants within its own code. It can have loops, assignments, reassignments, memory allocations, but it can't mutate variables outside its scope nor can it call any impure functions. I find this is a very practical compromise that lets you have the good parts of purity without ever getting the urge to write a blog post about monads.

https://dlang.org/spec/function.html#pure-functions

The weird thing is that you end up with something that looks like 2 different programming languages in one (talking about Haskell)

Also, Haskell's implementation of it is a bit weird an unintuitive (and the shortcuts just hide the messiness)

Given that you need state to interact with the outside world, making it more complicated in that essential area makes the learning curve harder

Does it make sense to view IO/State monads in Haskell as analogous to unsafe blocks in Rust?

I feel like a recurring theme I find in Idris (though keep in mind it's just something I play with every now and then, not something I use with any kind of regularity) is that it has this "feels like Haskell, but less frustrating and cleaner" quality. I feel like I make less dumb mistakes while using it, and it gives me pretty much all the stuff I love about Haskell.

You of course have the relatively simple effects system (as mentioned),, but you also have the ability to use `do` notation without being in the monad context, and eager evaluation, which I find makes my program simpler to reason about.

My advice is not to worry about it (unless the itch bugs you so much that you're willing to invest a lot of time researching the answer).

I don't think you'll ever get a single, straight answer that satisfies you. Just reading this discussion, I'm sure you can see that people describe monads in wildly different ways. Some descriptions are minimalist (perhaps a bit reductionist): it's just an algebraic data structure, nothing to get excited about. Many rely heavily on metaphors: containers, "programmable syntax", and yes, even burritos have been used to explain them. Some conflate monads with properties that do show up often in monadic code, but aren't themselves inherently monadic (immutable data, pure functions, sequencing of evaluation). Some are very language-limited, in the sense that the description invariably turns into a debate over the semantic fine-points of the language being used (this will almost always happen when Haskell gets discussed, because expression evaluation is a very subtle thing in Haskell). Frankly it's a mess. The only safe ground you have is the algebraic definition, but that's not terribly useful for building an intuition about how one might use them.

I think that you (and me, and most everyday programmers) would use them in your code only if you were using some library that was designed in a monadic style. In Haskell, so many libraries use monads these days that it's a given: using Haskell for any practical purpose means using monads, whether you want to or not. In Ocaml (about as close to Haskell as you can get without being purely functional), they show up mainly in third-party libraries, mostly when you want to do something tricky like asynchronous I/O -- again, you use monads if you want to use the library. But in run-of-the-mill imperative languages, though, monads don't tend to show up very often, and when they do, they usually are very specific to one library or another.

The definition of the thing we call “monads” is a poor place to start understanding what they’re for. The only way to understand monads is to use a number of monads, and you’ll start to see why they’re useful.

One great monad is the Option monad. It lets you represent, at the type level, the two casss of having something or not having. Think about when you use a python query operation that may return nothing. You don’t know if you’ll get back an empty list, or a null, or what. If the API returned an option, this would indicate what happens when you get nothing back. That’s cool. You can then do computations against maybe having a value. Option.map(lambda) will apply that lambda function to the value only if it exists, saving your program from blowing up on a null. Even better, tho, you can chain a bunch of operations that may fail together. In the map example, ifyour lambda also returns an option, you would end up with the type Option[Option[A]]. Monads implement a flatten method that will turn an Option[Option[A]] into an Option[A]. They abbreviate this with “flatMap”, which can be implemented as a call to map, followed by a call to flatten.

Futures are another great monad that help model asynchronous operations. Val f = Future(mydatabasequery) will return a Future[A], read as “future of type A”. You can perform computations on the result using the map function: f.map(lambda). You don’t know when this will happen, you just know it will. If your lambda also returns a Future, you will end up with Future[Future[A]]. You convert this into a Future[A] with the Future.flatten function. The shorthand for this is.flatMap(lambda).

Another great monad is the Either[A, B] monad. It’s like the Option monad, but rather than having None or Something, you have Left or Right. If you have an operation that may throw an exception, you can wrap it in an Either. A left value will be some error, and the right value will be success. You can conditionally perform operations on the success using the Map function: Either.map(lambda). If the Either doesn’t have a Right value, it will not execute your lambda, saving you from performing an incoherent operation. In python sometimes you might return either a string or an int, representing failure or success. Either[String, Int] is just formalizing that pattern, and letting your compiler prove that you’ve handled both cases. You can model sequential computations that may fail using either: if your lambda returns an either, you’ll get an either[string, either[string, int]]. You can flatten these using the Either.flatten method. The shorthand for this would be flatMap.

In computer science, a monad is a notation representing an intermediate value and its computational context. E.g., data necessary to continue the next steps of a calculation, or some kind of marker of the value's source (IO monad.)

It's an abstraction which rarely carries its own weight, but it's necessary to understand Haskell for what seem to amount to cultural reasons. Other strongly typed functional languages don't place nearly so much emphasis on it.

I would say... Monads are a concept that are useful when you are programing with monoids.

Do not bother trying to understand monads if you don't already have a good understanding of monoids.

Starting with monads is like trying to learn to divide before you learn to count.

For me, I really like the “programmable semi-colon” metaphor, where essentially a monad glues together computations and has additional context/actions carried along between the glued computations.

If you’re looking for external resources, it really helped my understanding by reading all the definitions you’ll find online, looking at every example (including the source code on hackage!), and building some play examples myself. It also helped me to first understand functors, applicative functors, then monoids as I was going through other resources.

Tom Stuart did a seriously great talk about this, which really helped my understanding of monads. You can read it as a blog post, but I recommend watching the video. It's worth finding the time for. https://codon.com/refactoring-ruby-with-monads

Monad is an interface which a lot of useful "context" types conform to - I find that if a function returns any kind of "secondary value" or "effect" (think the sort of things aspect-oriented programming is supposed to be for - permissions, logging, database transaction boundaries) this can usually be represented by a type which will form a monad. http://blog.sigfpe.com/2007/04/homeland-security-threat-leve... is a simple example if you don't mind the Haskell syntax.

The concept is useful because it means that we can implement generic functions that work for any monad - http://m50d.github.io/2013/01/16/generic-contexts was one practical example I met at my job (if you can read Scala - I feel it's quite Pythonlike but YMMV). Better still, these functions already exist for you - things like the "traverse" function I described there, or cataM (write a function that operates on one level of a tree and returns a type in a monadic context, get the corresponding function that operates on the whole tree), are just a library import away.

Why do you want to use them? They make it practical to replace "magic" with plain old values - somewhat cumbersome values, but values that are usable enough that the advantages of working with plain old code start to show. If you're using Python, anything you're using decorators for is a very good candidate; I already mentioned AOP. A really simple example would be error handling: in a lot of languages you have the choice between https://blog.golang.org/errors-are-values (explicit, clear, but too cumbersome to use in practice; means your functions are hard to read because all the error handling gets in the way of reading the business logic) and exceptions (concise, but magic and invisible; code with exceptions can end up with really surprising control flow). Monads give you a middle way: https://fsharpforfunandprofit.com/rop/ , where your error handling is visible enough to not be a surprise when it happens, but hidden away enough that you can read the "happy path" code without getting too distracted.

You don't typically need them in normal programming.

Have you used the Python twisted framework? The way it chains continuations is a good example of a monadic bind in the wild.

On the off chance that you know C# and Linq:

    // A Box that holds stuff
    public class BoxOfStuff<TStuff>
    {
        public TStuff Value { get; private set; }

        public BoxOfStuff(TStuff value)
        {
            Value = value;
        }
    }

    // Class that holds methods for working with Boxes of stuff
    public static class Ext
    {
        // Takes something and puts it in a box
        public static BoxOfStuff<TStuff> PutInABox<TStuff>(this TStuff thingToPutInTheBox)
        {
            return new BoxOfStuff<TStuff>(thingToPutInTheBox);
        }

        // Converts a Box containing one thing into a Box containing something else
        public static BoxOfStuff<TOtherStuff> ConvertBox<TStuff, TOtherStuff>(this BoxOfStuff<TStuff> theBoxItself, 
            Func<TStuff, BoxOfStuff<TOtherStuff>> functionThatConvertsTheBox)
        {
            return functionThatConvertsTheBox(theBoxItself.Value);
        }
    }

    // Class that holds a string value
    public class StringHolder
    {
        public string Value;
        
        public StringHolder(string value)
        {
            Value = value;
        }
        
        public override string ToString()
        {
            return Value;
        }
    }

    var result = new StringHolder("A random string").PutInABox()
        .ConvertBox(randomString => new Random((int)DateTime.Now.Ticks).Next().PutInABox()
                .ConvertBox(randomNumber => (Guid.NewGuid()).PutInABox()
                        .ConvertBox(guid => ($"{randomString}, {randomNumber}, {guid}").PutInABox())));
        
    Console.WriteLine(result);

    // Compare the above result to this:    
    public static class LinqExt
    {
        public static IEnumerable<T> ToEnumerable<T>(this T t)
        {
            return new List<T> { t };
        }
    }

    var linqResult = new StringHolder("A random string").ToEnumerable()
        .SelectMany(randomString => new Random((int)DateTime.Now.Ticks).Next().ToEnumerable()
                .SelectMany(randomNumber => Guid.NewGuid().ToEnumerable()
                        .SelectMany(guid => ($"{randomString}, {randomNumber}, {guid}").ToEnumerable())));
                
    Console.WriteLine(linqResult);

This is analogous to:

IEnumerable + ToEnumerable (the Identity function) + SelectMany (the Bind function). To be honest, this is a fairly loose, non-rigorous definition even by programming standards, but if you've used LINQ before it should give you an idea of how useful Monads can be and how they can be used.

LINQ works the way it does because of Monads. In fact, if I were to add a Map function (Select) to BoxOfStuff and rename ConvertBox to SelectMany, I could use query syntax eg.

   var result = from thing in myBoxOfStuff
                select thing.ToString();

Basically the traditional way to do I/O is to just call I/O functions (like printing to the terminal and reading keyboard input) in the middle of the program.

There is another way, which consists of having the program only consist of a pure function that returns the kind of an I/O function to call, its parameters, plus a closure that takes the result of the I/O function, and returns again a pair of I/O function kind, parameters and closure.

Then, an external "executor" can just perform the I/O, call the closure with the result, perform the I/O again, etc.

The result of this is the program can be executed to do I/O, but all functions are side effect free (they just compute a result based on the arguments).

The tuple of I/O function kind to call plus parameters plus closure is called an "I/O monad" (or equivalently it can be just the closure).

Now in this model if you want to have subroutines you need them to return an I/O monad, and need to be able to "chain" the rest of the computation to it, which is done by adding a method to the I/O monad called "bind".

These subroutines might not do any I/O, but it's still convenient to return an I/O monad, so an operation called "return" is added, which returns an I/O monad whose I/O function simply returns the parameter to return.

This interface with those "bind" and "return" functions is called a "monad", of which the I/O monad is an instance (along with some obvious properties, like that calling bind twice is the same as calling it once with the composition of the two functions, and that return and bind also commute in the same obvious way).

Another example is the "state monad", which is like the I/O monad except the operations are "read variable #i" and "write variable #i" (Haskell uses STRef objects instead of variable indices, but it's essentially the same).

While the I/O monad can only be executed "externally" to the program, the state monad can be executed internally: a pure function can be written that takes an array of initial values of the variables, a state monad instance and executes the state monad instance and gives back the final variable values.

So this gives a more complicated way of expressing imperative programming that has the advantage of only involving pure functions and thus being usable in pure languages like Haskell.

Now, why isn't this the best thing since sliced bread?

The obvious problem is that a naive implementation is massively inefficient, since every time you want to perform a memory write you need to stuff the stack of the program into the heap and return it as a closure.

Furthermore, monads for normal I/O and state are just not very useful: isolating the computation can be done with Rust's model of lifetimes and linear types, the ability to execute it in different ways can be achieved by providing a dynamically-dispatched set of I/O functions, and stopping the computation can be performed with unwinding.

The only practical advantage of monads is that you can pause the computation and have the state on the heap instead of the stack. This is why efficiently implemented languages like Rust (and in this case Java/C#/JavaScript) only use monads to implement futures/promises, where this ability is exactly what is wanted, and don't use state monads or I/O monads for synchronous I/O.

As an aside, the reason futures/promises are the best way to do I/O is that when the computation is paused, the state is stored on a heap in a compact layout (as a future/promise monad instance), while with either threads or coroutines it consists of an inefficiently laid out machine stack in userspace (that also takes a lot of virtual address space since it must be able to grow arbitrarily) and in case of native threads a machine stack and thread structure in kernel space as well.

The async/await and future/promise support in Java, C# and JavaScript is essentially a direct implementation of the Haskell monad model, with the downside of requiring an allocation for each await.

However, there's also way to have a monad-like style while preserving near-optimal performance, which is used in Rust's async/await generators.

The idea is that instead of having monads be closures that return closures, they instead become generic "objects" with a method that, upon being called, updates the state of the object and returns a description of the I/O operation to perform (or even just performs it with parameters provided by the caller), and is called again and again until it signals that the computation is done (this of course involves mutable state, but the mutation can be restricted with ownership).

"bind" can then be performed by simply defining a larger object that embeds the inner "monad" and the whole thing can be monomorphized, thus removing any dynamic dispatch and having a program that behaves as normal, except that instead of storing variables in the stack, it stores them in a single variable that needs to be immovable, either by heap allocating or ensure it's not moved on the stack. Note however that you need further allocations for recursion and in general for any dynamic calls whose state does not have a bounded size.

TLDR: monads primarily exists because Haskell must be pure and doesn't care about performance, but also because they are the only way to do memory-efficient async I/O

When I worked at Basho, the senior Erlang developers definitely thought/talked about monads and how useful they could be in certain situations.

(I, alas, was and remain insufficiently clueful about monads to understand the discussions.)

Erlang is pure, but it's not lazy, so it's not an issue like in Haskell.

The monad abstraction takes a lot of unlike programming features and abstracts away most of the important stuff to show something they have in common. The question is whether users of those features need to know about this abstraction? Why should we care that they have something in common? They're mostly different.

As concepts get more abstract, they get harder to teach. I don't think knowing that JavaScript promises are a monad is all that helpful when learning to do async I/O.

You're using monads whenever you code in any imperative language. The "bind" pattern is simply so pervasive that you don't even recognize that it's there, but any time you use information obtained through one side-effect as part of another side-effect, that's a monad. That trivial read-a-name-and-print-a-greeting program which frequently shows up on the first day of Intro to Programming? Yep, that's using a monad.

The difference with functional programming is that you can choose not to use monads, and IO, and other powerful abstractions which are baked in so pervasively into other languages. This enables more powerful static analysis and code reuse, but it also means that you need to be aware of what you're giving up in the process, such as the ability to choose effects at runtime based on the results of prior effects. People who have been using monads throughout their entire programming career are thus suddenly faced with trying to understand what a monad actually is and what sets it apart from non-monadic code. This leads to people writing tutorials and papers and blog posts, which causes people to think it's some super-complex concept accessible only to genius mathematicians, which leads to more tutorials...

The neat thing is, once you've begun to see the pattern, it turns out to be useful in other areas besides sequencing I/O effects; non-determinism, coroutines, generators, parsers, and so on. Most languages make sequencing I/O effects so easy you don't even notice it's happening, but other monadic patterns, lacking built-in syntax, are far more unwieldy. Haskell puts them all on the same footing via the Monad typeclass and do-notation.

Monads are too general though. Saying 'try monads' to solve a problem is like telling someone, 'try vowels' when they're trying pronounce a word.

Your intuition about the benefits of pure functions & immutability are spot-on, and I think that any proponent of monads would agree that these are fundamentally more important concepts than monads themselves. (Many of the ways that people use monads would break, or lose their point, if the data they operated over could be mutated outside of the monadic context.)

You can get an awfully long way with immutable data structures without involving monads. There are plenty of languages that give priority to immutable data, but don't have monads in any inherent way: Prolog, Erlang, Ocaml, and Scheme (to a slightly lesser extent) all come to mind.

> not all assignment makes a function impure

That's exactly what the ST monad/STRef's are for. {new,read,write}STRef let you manipulate mutable references while keeping track of their scope in the type of the reference. runST encapsulates a chunk of code that manipulates mutable variables in an externally-pure way into a pure function. The "Lazy Functional State Threads"[1] paper on it is a pretty good read.

[1]: https://www.microsoft.com/en-us/research/wp-content/uploads/...

Those posts by Degoes are more polemical than techniques that he actually uses in production.

Your comment is really pedantic. Obviously the concern is whether using monads is a waste. If I say "television is a waste of time" are you also going to correct me that tvs just are?

Very funny. Although like most humour, somewhat wasted here.

> I'm currently working on a little utility library for editing rich text with Haskell and I've used the continuation monad to automatically derive a zipper for my data structure.

Could you go into more detail about this?

No, but the state is part of the type signature, so the scope is explicit.

I agree, although it's funny because the community has been trying to come up with replacements for mtl for some time now.

OK, I'll bite. Here's the essential truth of functional programming, applicable to all of real programming: Constrain your state space or die.

Hello, most of your points seem wrong in the extreme and I feel like addressing them. I confess I pressed the enter key hard a few times as I wrote this, gritting my teeth at some of your points. But I have tried to keep a level tone to help people see that many of these points either are simply FUD or, in a few cases, haven't been true for well over a decade.

But, first and foremost, it's very clear you've conflated Haskell (and perhaps Purescript?) with all functional programming. This is a mistake, and many functional languages do not make use of pure functions, laziness, monads, or algebraic data types.

> - it tries to abstract away von Neumann architecture and make it more math-like, stateless, true and permanent. Yet von Neumann is completely stateful (resembling real-world in its complexity and model approach),

Most languages abstract away von Neumann architecture to some point. This is generally seen as a feature, as the notion of "von Neumann" itself has evolved substantially over time such that many historical practices are no longer meaningful (example: overlays).

For the last 2 decades, it's been considered Industry Best Practice to do this, as we're increasingly finding we don't want the limitations of this classical architecture to limit our computations or computers.

For example, it's quite easy to push computations to GPUs or TPUs in Haskell because by default it doesn't force assumptions onto users about what state means.

> causing all kinds of frictions, for which monads and other syntactic sugar were invented

No, Monads were not invented to solve this problem in Haskell. They were a subsequent improvement to the original solution.

> while Turing complete, it has some weird properties, making it difficult or inefficient to change communication between various components that are using deep function calls when such a need arises in the future.

This is quite untrue. And if it were true then it's quite a curious chain of events that functional composition has only become more mainstream and relied upon in many languages, and before the proliferation of closures and functional composition frameworks and techniques (e.g., Dependency Injection) came into being to model the kinds of interactions composed functions make natural.

> This leads to using mutable "shortcuts" that render a lot of advantages functional programming might have had useless and starts resembling imperative/OOP programming with its issues again

I am surely not alone in having no idea what you're talking about other than perhaps the occasional use of unsafePerformIO in haskell, but even then.

> - trivial things like IO can't be modeled without side-effects, so any software requiring input from keyboard, loading external files etc. can't be pure

Monads are a way of modeling impure computation purely. And IO is a side effect. It's absolutely wrong to suggest the IO monad is some short of shortcut or inherently impure, or that it's deficient in any way compared to a block of Javascript for modeling the real world.

None of that is true.

> - often functional constructs make code unreadable despite readability being one of the main reasons for its existence

This is a matter of opinion and training. One could make the same argument of React/Redux reducers (really, the state transitions are in the actions?), Google's Guice DI framework (what is happening), or elaborate builder-notation spec framework tests.

Most people will find languages like Clojure or Ocaml pretty familiar.

What I will agree with is that languages that more closely model referential transparency tend to appeal to some tools modeled after category theory that require up-front study to really understand and apply. Most languages have one or two things like this: Ruby has proc vs block, Python has many arbitrary restrictions and list comprehensions, C has pointers, C++ has generics, Java has reflection, Javascript has callbacks, Haskell has Functor->Applicative->Monad.

> - bottom-up creation of algorithms is preferred by many language authors, making it difficult for beginners

This has nothing to do with FP and everything to do with programming in a modular fashion. Every language with modules naturally leads people to bottom up styles. That includes Javascript.

> - if you really want to know how it works, it takes 5+ years PhD level of studies in abstract math

The Haskell compiler is a big, complex piece of work. But so is the C++ compiler, the Java JVM is surely bigger, the CLR is fantastically complex, and have you ever looked at some of the bugs in the Python interpreter?

Of course it takes dedicated study to understand a modern compiler. That's only natural.

> Disclaimer: I approach 100 languages I've used in production,

Okay. 100.

> worked for companies that created some of the most popular languages and hate them all

Who? Maybe we've worked together.

> I hope to work on AI-assisted language creation in the near future.

You're very late to the starting line here.

These are largely the reasons I've come to when declining to use a functional language. We have a guy at our office who never shuts up about FP and monads in particular. He's almost like a preacher in that regard. I never really saw any sort of advantage or why he's so gung-ho about it.

One of the sins I see in his programming and design is that he focuses on what a thing is, rather than what the thing does. He's always balls deep into grafting together all these category-theoretic structures into a system, but I feel he rarely sees the forest for the trees. Also, all of his FP projects are still "in progress" and never seem to reach a stage of stability.

He could just be a shitty engineer, and perhaps shitty engineer + functional programming = pile of shit of a higher order.