Learn Physics with Functional Programming

> My point isn't that it errors. It's completely reasonable to expect even a beginner to do basic troubleshooting. My point is that the error specifically mentions monads.

Right, and the Python errors mention all sorts of things a beginner is not expected to understand, like "builtin_function_or_method". I don't think "understanding builtin_function_or_method" is required to write the Python and I don't think "understanding Monad" is required to write the Haskell.

> If our requirements changed to now read and sum an arbitrary number of inputs together, I'd expect a beginner could change the Python program to do so. I'm skeptical they could make the required changes to the Haskell version (without understanding monads).

Where do I have to "understand monads" to write this?

    main = do
      iters <- readLn
    
      let loop n total =
            if n == iters
            then print total
            else do
              x <- readLn
              loop (n + 1) (total + x)
    
      loop 0 0

I had to understand that in Haskell looping is done via recursion (which is mindbending initially, if you come from imperative programming), but I don't see that I had to understand monads. FWIW the Python that I'd write is

    def main():
        iters = input()
    
        total = 0
    
        for _ in range(iters):
            x = input()
            total += x
    
        print total

This is simpler. But I could write a Haskell version that uses an IORef to get roughly the same code structure as the Python.

    main2 = do
      iters <- readLn
    
      total <- newIORef 0
    
      for_ [1..iters] $ \_ -> do
        x <- readLn
        modifyIORef' total (+ x)
    
      theTotal <- readIORef total
    
      print theTotal

I would say this requires understanding the mutability/immutability distinction to know why we use an IORef at all (but you'd get that with OCaml[1] too) and it still requires understanding do notation, but I don't see that it requires "understanding monads"!

Now, if I were writing this for real I probably would use a version with a state monad transformer so it was

    main3 = do
      iters <- readLn
    
      total <-
        flip runStateT 0 $ for_ [1..iters] $ \_ -> do
          x <- lift readLn
          modify' (+ x)
    
      print total

That would require some understanding of monads so that you can understand how they are transformed with monad transformers!

[1] https://www.cs.cornell.edu/courses/cs3110/2018sp/l/14-mutabl...

> Fixing mine requires understanding how `do` and `<-` interact, which I remain skeptical can be done without exposing oneself to monads.

I think this is the major point of contention between us.

I don't think that understanding how to use `do` requires "understanding monads". My example was to demonstrate that understanding how to use `do` for the IO monad is not really much different from understanding how to write a sequence of statements in Python. There's one big difference: you have to use both `<-` and `let`, and you have to know that the former is used to get a value out of something of type `IO a` and the latter is just normal variable binding. But that still doesn't require "understanding monads"! It just requires knowing there's a special thing called `IO` that wraps things with effects.

I do think that understanding how to use `do` for arbitrary monads requires understanding monads! But that was not required to solve the problem lmm originally proposed, nor your extension.

I also do think that most pedagogical Haskell material focuses too much on "understanding fine details" and that applies particularly to monads. My point is that another approach is possible. That is simply to use `do` notation intuitively via analogy with imperative languages (which is a perfectly fine thing to do).

> The recommended way of writing a program in most languages demands some level of understanding what you're writing

Sure, some. I think this discussion is about exactly what and how much, when it comes to Haskell.

> the recommended way of doing that is to understand Monad.

That doesn't ring true to me, not from how I learned Haskell and not by analogy with how I learned other languages. I don't remember having to "understand Monad" to write in "do" notation. Quite the opposite in fact. I vividly remember trying to "understand Monad" and being unable to, and then just giving up and trying to use do notation, finding it easy, completely unhelped by what I was trying to "understand", and regretting having spent all the time "understanding". But it's been a long time since I learned a language so maybe I'm mistaken. I would appreciate the point of view of others who have fresher eyes.

I will concede that people have a harder time learning Haskell than Python (although I don't think anyone understands the exact reasons) but you gave a very specific example of a program that is supposedly requires some deep understanding to write in Haskell. I wanted to give a counterpoint so people can decide for themselves. That's as far as my claim goes.