Do notation considered harmful

You are right. The title should have (2009) appended.

> https://gitlab.haskell.org/ghc/ghc/-/wikis/applicative-do

can't help but chuckle at the accomplishment of 40 years of research in functional PL, ending up with almost C-like syntax once again.

I remember reading the Typeclassopedia nine years ago and feeling really annoyed (in an OCD way) that monad is not a subclass of applicative.

> do x <- a >>= b ...

Please at least keep everything flowing in the same direction!

do x <- b =<< a ...

I think the position that do-notation is harmful is nowadays in the minority. Personally, I prefer it to long chains of monadic operators.

It proved so convenient that there are extensions like "ApplicativeDo" that let you use do-notation in contexts other than monadic: https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...

> Imperative programming is the most natural thing for people. "Do this, then that, then that, in that order."

I'm not sure. For example, do users of Excel really care in which order the cells are calculated, beyond the order imposed by the data dependencies they have defined?

What work could you not get done in Haskell?

I think you're right that imperative semantics are natural for people in some contexts, but far from all the time. For someone who has worked hard day after day for years to fit all kinds of problems into an imperative mould, it will of course appear more "natural" than for others.

Cooking recipes are good examples of imperative "scripts", and for the most part it would be silly to try to write them in a declarative style. But note that they too often contain declarative formulas, like "if the pancakes stick to the pan, use more butter". It's the most natural thing in the world to add such regulative rules. There is no mention of exactly when this rule should be applied, in the sense of where it fits into a sequence, and trying to formulate it that way would be cumbersome.

It's a big drawback for the industry languages you allude to (and for the software industry as a whole) that there is no simple way to integrate such rules into programs. (I suppose aspect oriented programming is/was an attempt at that.)

You can also read through the rules for any board game. They typically consist of a mix of imperative, sequential instructions, regulative rules, and constraints. Why? Because that is the most natural thing.

You're misunderstanding Haskell and do-notation. Haskell does not "[attempt] to appear imperative to be palatable to more people".

Haskell has to have a way of handling effects because no useful program can be written without effects. Even if that is as simple as printing output on completion, that is still an effect. Haskell furthermore needs to integrate effects into the language in such as way it does not break the substitution model of evaluation because 1) that's the goal of Haskell as defined back in 1992-ish and 2) order of evaluation is hard to reason about in a lazy language. Monads are Haskell's solution to this, and do-notation is syntax that makes monads easier to use. There is nothing here to do with popularity.

Furthermore, claims that "Imperative programming is the most natural thing for people" is not true. All programming is an artificial construction. There is no "naturalness" to be found here, only familiarity and prior experience. In my experience non-programmers take easily to functional programming. Experienced imperative programmers may struggle a bit.

> it attempts to appear imperative to be palatable to more people

I doubt that was the reasoning, given the Haskell slogan of "Avoid success at all costs".

Imperative is most natural when you have mutable state and side effect. Haskell does not deny that. But even imperative languages (anything above assembler) have both statements and expressions. Haskell just tries to move as much as possible to expressions, and reduce and isolate mutable state and side effects.

The way I see it, they try to separate the "pure" from the "imperative" world but the imperative world is like trying to write a completely different language.

Then they try to "make it easy" through some constructs like 'do' and >>= but it still feels like controlling an airplane using an Atari joystick.

In language and API design it seems it's very easy to shoot yourself in the foot and create problems that wouldn't exist in the first place had a more sensible approach been taken (which I agree it is hard sometimes).

> Imperative programming is the most natural thing for people. "Do this, then that, then that, in that order."

No way. Have you ever mentored technical people who aren't specifically trained programmers by education?

These kinds of people will have no problem writing huge SQL queries with joins nested four levels deep, or pages and pages of declarative Pandas or R code using weird transformation and filter logic, but they'll have humongous problems understanding simple loops or variable assignment.

Another data point to consider: Excel is the most popular programming environment in the world, and it's also declarative, not imperative.

I also like that it exists. It's interesting if nothing else.

> Imperative programming is the most natural thing for people. "Do this, then that, then that, in that order."

I think back to the sandwich example most of us had in CS class. Step by step, how do you make a sandwich? And then the teacher will always trip us up with a step we forgot.

The problem is that with current computer programming, you can't just say "Make me a sandwich" you have to specify it in excruciating detail. Naturally, an imperative form suits this.

But if we could in fact get sandwich making right, roll it out via code-reuse, and collapse that into one command, a more functional style might suit. Say what you want to achieve, instead of how to achieve it, and suddenly the order matters a bit less. Let the computer care about that.

Maybe that's not possible with current architectures or programming languages, I don't know. It would be nice though.

I don’t think I’d judge the language too much based on this article. It’s over a decade old and modern Haskell has progressed quite a bit since then. During the 2010s the language community really shifted towards becoming more practical. It certainly has still maintained an academic element too but that side of things doesn’t dominate nearly as much anymore.

> Haskell rejects the imperative model, yet it attempts to appear imperative to be palatable to more people while retaining a pure functional model under the hood. But that causes it to be criticized by the pure-minded.

The point of do notation is to rebuild imperative programming atop a rigorous foundation. Haskell is a deliberately flexible language: if you want to do imperative programming in it, you can (as long as you do it properly). But most users eventually find that the imperative model isn't actually something you want or need, even if you thought you did when you started.

> So who is it for?

People for whom the defect rate of traditional imperative programming is too high, or for whom achieving an acceptable defect rate in a traditional language takes too much time.

IMO, imperative programming is only intuitive for imperative tasks. Many common programming tasks may be imperative, but many are not.

Looking up a product number, placing that product in cart, and checking out is a naturally imperative flow. Humans would think about this somewhat imperatively and iteratively if they were doing it in the real world.

However, other tasks like formatting or searching data are usually not intuitively imperative in my experience. As programmers, we build a habit for translating these ideas to imperative sequences, but I don’t think that’s obvious to people who haven’t practiced it.

Compare a regular expression to a 40 line manually-written matching algorithm. If you ignore syntax, I think many people would agree that the regular expression which directly describes the goal is more intuitive to think about than the imperative machinery that achieves the same thing.

Actually this is wrong - for example one study [0] shows only 12% of non-programmers approach problems like this while 54% use event-based approaches. Anecdotally, I've found good mathematicians who come to programming after their studies tend to dislike imperative systems too.

http://alumni.cs.ucr.edu/~ratana/PaneRatanamahatanaMyers00.p...

Honestly, I think that the reason why Haskell never got adopted is that they never really tried. A ton of the decisions over the years they’ve made would’ve been insane for an industry language, but appear to have been non-problematic for their goals. What would’ve happened if they’d tried is an interesting counter factual.

My biggest problem with Haskell is that is damn near impossible for me to mentally parse. I always end up liberally sprinkling my code with parenthesis and “$” hoping to make the compiler happy. I never managed to develop a mental framework to help me out here.

Yes, I think you have a key point there. Using the same-ish syntax for effects as for pure code is a tricky problem of ergonomics: get it too similar/implicit, and people will be confused about when effects happen and when pure code runs. Get it too dissimilar/explicit, and it gets cumbersome to write.

I actually think do notation hits a great middle point, where it's obvious you're in effectful code, yet familiar and similar enough to pure expressions to be convenient.

For me, that's similar to writing

  if(var == true) {

  }

It's more verbose than necessary, but not wrong.

> they'll get a hint to simplify it and eventually they'll learn the idiomatic way.

I can confirm that, the recent IntelliJ Haskell (https://plugins.jetbrains.com/plugin/8258-intellij-haskell) does a pretty good job notifying beginners about redundant "do" blocks and eta-reduction possibilities (with a help from HLint). The redundant blocks are even highlighted in real-time right on the editor.

> the order of statements in a "do" expression does determine the order of execution

Not really, unless you take a very specific definition for "order of execution". There are plenty of monads where order of statements is unrelated to the order of execution, Identity, for example!

Then use {} around your binders. This sets x to 11, for example.

    x =
    
        let { y
                         =
    
       5
     
            ;
     
      z =
    
    
        6 }
    
                       in y

      + z

> Why does introducing let add indentation?

Scheme has lexically scoped (define var value). It de-sugars into let under the hood. Not everyone in Lisp likes such a thing, though.

I prefer my lexical scopes to be enclosed.

In C coding, I stick to "variables at the top of a block". If I need a scope somewhere, I put it in braces:

   x = f();

   {
      int z = whatever();
      foo(z);
   }
   // here we know that the scope of z has ended.

In C99 and later, you can remove these braces, but then the scope doesn't end until the enclosing block (possibly the whole function). That's a conceptual problem for me, because I really want that z to exist only in that two-line bubble.

It's more than just a conceptual problem. I might have another such a bubble which also uses the name z, and I want to be able to move them around easily. If I remove the braces, I can have only one z the first occurrence controls the initialization and everywhere else it's of the same type.

I could have some goto around the bubble also:

   goto after;
   ...

   {
      int z = whatever();
      foo(z);
   }

   after:
   ...

If the braces are removed, there is a problem: the goto jumps into a scope where z is visible, but has skipped the initializer z = whatever(). (This is a huge problem in C++ due to construction being potentially skipped so seem to recall it's a required diagnostic in that language, but not in C.)

Basically "just piss new identifiers into the current scope" is a terrible language design in my view.

In Lisp, there is a further problem of things being harder to analyze. let is easily destructured by position. The operator is in the car, the bindings in the cadr, the body in the cddr. (Common Lisp somewhat complicates things with declarations in the body.)

With define we have to do the desugaring to let before we can continue to walk the code. Essentially, it behaves like a macro, but not a regular macro: a macro that has influence outside of its form. That's just another reason to eschew it.

A good way to avoid indentation is to use sequential let* and then do all your work in successive variable binding statements. Then have a single expression in the body to calculate a value to return.

In let* , you're permitted to re-use identifiers, if that helps you:

   (let* ((x (this))
          (x (* x 3))
          ...)

If you need to evaluate something for a side effect, you can stick it into a progn, or bind it to a dummy variable (which may have to be declared ignore in Common Lisp):

   (let* ((x (progn (effect) (this)))
          (dummy (effect))
          (y (bar x))
          ...)
     (calculate y))

Now you can insert new variables and computations without any change in indentation.

In C, I use the comma operator as progn to keep code as a sequence of initializations, while inserting a needed effect, like in this function:

http://www.kylheku.com/cgit/txr/tree/eval.c?h=txr-237#n1465

  static val expand_eval(val form, val env, val menv)
  {
    val lfe_save = last_form_evaled;
    val form_ex = (last_form_evaled = nil,
                   expand(form, menv));
    val loading = cdr(lookup_var(dyn_env, load_recursive_s));
    val ret = ((void) (loading || uw_release_deferred_warnings()),
               eval(form_ex, default_null_arg(env), form));
    last_form_evaled = lfe_save;
    return ret;
  }

The nulling out of last_form_evaled is inserted into the unbroken sequence of initializations via the comma operator.

In Haskell your code doesn't "do IO", you write (and compose) IO actions which describe what IO will be done at runtime. Only at runtime do the side effects occur. The code itself is still pure and referentially transparent.

No, not if you include the state of the world in the type signature. If you make every primitive IO function take a RealWorld value and return one, you can thread the execution correctly using the last one as an argument to the next.

But then the question is what happens if you reuse a RealWorld that you already called a function with. That leads you to types with values that can only be used once, uniqueness types (https://en.wikipedia.org/wiki/Uniqueness_type). Which is the solution for IO that Clean, the other lazy functional language, uses.

To add to lgas' point:

The distinction between functions with side effects and descriptions of what IO will be done at run-time has many practical consequences. For example, if you execute the Haskell code

  greet name = do
    putStrLn ("Hello, " ++ name)
  repeat3 action = do
    putStrLn "Doing it thrice."
    action
    action
    action
    putStrLn "Done it thrice."
  main = 
    repeat3 (greet "themagicalcake")

you get the following output:

  Doing it thrice.
  Hello, themagicalcake
  Hello, themagicalcake
  Hello, themagicalcake
  Done it thrice.

But if you execute the similar-looking Python script

  def greet(name):
    print ('Hello %s' % name)
  def repeat3(action):
    print ('Doing it thrice.')
    action()
    action()
    action()
    print ('Done it thrice.')
  if __name__ == "__main__":
    repeat3(greet('themagicalcake'))

you get

  Hello themagicalcake
  Doing it thrice.
  Traceback (most recent call last):
    File "test.py", line 10, in <module>
      repeat3(greet('themagicalcake'))
    File "test.py", line 5, in repeat3
      action()
  TypeError: 'NoneType' object is not callable

instead. The Haskell value `greet "themagicalcake"` has type `IO ()`: it is a value that describes IO to be done at runtime. In contrast, the Python value returned by the call `greet('themagicalcake')` has type `NoneType`, and this value does not describe anything. Calling `greet` itself had the side-effect of printing "Hello themagicalcake".

Do we even need side effects? Most programs seem to be about transforming some input to an output and/or storing/retrieving state in a transactional manner. Perhaps I/O and transactional storage could be kept outside a language and instead be managed by its containing environment?

For example, console I/O: The input from the console could be transformed (possibly with some state) and sent back out (possibly triggering an associated state update) as a fairly natural pure function call. It would have the type state -> input -> (state', output), and the 'runtime' would be responsible for gluing this all together.