The Cult of the Haskell Programmer

Some other features I really miss from Haskell when programming in other languages are the dedicated function composition and application operators, curried functions by default, and support for partial application of operators.

What truly sets Haskell apart is how much the language shoehorns you into being an architecture and abstraction astronaut

How does monadic IO follow from laziness?

It’s a great language for sure. I do worry about the bus factor though, especially given they’ve not had a major release since the most prolific contributor left after some community issues.

Try using it for concrete problems you have today, start small. I used it to write a small calorie counting web app and some other tiny projects and picked it up that way.

That's why I like ocaml and racket (or scheme). Functional, but you don't need to jump through hoops to do basic stuff like I/o.

> I'm pretty good mathematically, and the syntax is just beautiful to me.

Ironically, I think the syntax probably is causing some of your problems here. Haskell seems to have a problem where the syntax is so dense that simple operations get confusing. And the strong typing pulls a lot of the learning pain up front. You might be better off learning functional programming independently of Haskell's type system to get a feel for how to do it, then come back and get the types correct and learn the advanced tricks.

If you want an unsolicited tip; don't bother trying to "understand monads", there isn't much there to understand - they are what they are (it doesn't get much more basic than the Maybe monad). Look at the code that uses monads - they are an answer to being unable to solve problems the imperative way. So the point of a monad is programmers want to write code in a certain way and without monads there would be a monad-shaped hole in the code that needs to be filled. If the code was written in a dynamic imperative style, monads wouldn't be so interesting.

A chunk of monads are just obviously necessary and simplifying once you start using ... whatever the Haskell equivalent of a pipe or threading macro is ... and make the mistake of trying to use functions designed for an imperative style.

Monads are easy. They're just a design pattern that provides a formal abstraction over operation sequencing with additional computation. If you just accept them as they are, rather than attempting to grok them by approaching them by analogy ("monads are like burritos"), you will make your life much easier.

That's the secret to Haskell. There's no "getting it". There's just using it.

You might benefit from this video [1] on the "Functional Core, Imperative Shell" pattern in Ruby (a very object-oriented language), which sounds like one of the things you are having trouble with.

The talk is about segmenting IO and mutation from the rest of your program. The core of your program should be just pure functions and the IO part of your program should be "at the edge".

For example, consider a game loop. Game loops tend to have a while loop like this:

function loop() { while (should_not_close_window) { update(); // Run update function which updates mutable state draw(); // Draw from the mutable state } }

If we wanted to segment IO, we would return an immutable type/value from the update function instead like:

function loop(old_state) { const new_state = update(old_state); // Call a function which returns a new state given an old_state. draw(new_state); // Draw function still uses IO because drawing is inherently imperative

  if (new_state.should_not_close_window) {
    loop(new_state); // Call the loop function with the new state; this tail recursion replaces the previous while-loop). The program automatically exits the loop if new_state.should_not_close_window is false.
  }

}

The key thing is to turn as much of your program into a function that takes a value and returns a new value as possible, and let the IO code be only there for operations which cannot be done without IO (like drawing).

There are some cases where you might find yourself wanting to perform IO inside the update call but that can be handled by setting some state (inside your root state object) which the boundary of your program interprets as "do IO at the boundary".

For example, let's add an async handler to the loop (async often being IO like disk writes).

// Function to handle async messages function handleAsync(old_state) { for (const msg of old_state.msgs) { execMsg(msg); // Call function to pattern match and execute this specific message } const new_state = remove_msgs(old_state); // Call function that returns same state, except msgs is now the empty list (because the msgs have been handled) return new_state }

Where type msgs could be a list of types like | WriteFile of string | MaximiseScreen

The main loop will be modified by putting a call to this handleAsync function after update, like this:

function loop(old_state) { const mid_state = update(old_state); const new_state = handle_async(mid_state); draw(new_state);

  if (new_state.should_not_close_window) {
    loop(new_state);
  }

}

The majority of your code should be in the pure update() function which returns a new value (this example doesn't explain anything about pure functions at all) and IO should be minimised.

Generally, don't do IO (except at the boundary/root of your application). When you want to do IO, add some kind of message/datatype value to your state object and do the IO when your state object bubbles up, rreturning to the root of your application.

The talk likely explains this better but I hope my attempt at giving an explanation was helpful.

[1] https://www.destroyallsoftware.com/talks/boundaries

Hi, thanks for sharing this. I'm actively trying to understand the roadblocks to onboarding new users to Haskell, and trying to fix them.

If you'd like to share any more about your experience I would really value hearing about it. Perhaps you could link to forum discussions you've been involved in, documentation you found confusing, or programs you've written that you got stuck on.

You're also welcome to contact me privately if you like. My contact details are in my profile.

shoot me an email, which is on my profile. I can help. I honestly was where you were a few years ago, and worked through it.

A few direct observations based upon what you said:

- working with monads takes some practice and understanding. There are several things that need to be learned to work with them, none of which really are directly addressed by educational materials. My advice here is to find someone who is willing to help you work through direct, concrete problems you're having, and/or work though a well-designed resource, such as haskellbook.com. You will still likely need another resource to talk to about issues tho.

- re: entire program understood before writing any code: I am not sure specifically what you mean here, but I think you're talking about how making a change in haskell can necessitate quite a large refactoring, where in another language it might be a trivial change. This is... indeed sad at times, but otoh, this is intractably linked with _other_ notions in haskell: functions should be total, side effects should be isolated, etc. So you _will_ need to do a refactor if you need to introduce side effects to a new part of your program. This is how you get the benefit of having isolated effects.

- re understanding the entire standard library: yeah, this is part of the unfortunate reality. Haskell is an active research language, and that research has borne fruit. So, practices have changed, which means that there is a lot of legacy gotchas around. Not only that, but things that you might do trivially in another language may require using a seemingly esoteric functionality in haskell (traversable imo is the canonical exemplar). Overall this means that learning haskell is a much larger effort than it could otherwise be.

Thus, I think there is certainly room for a haskell successor that addresses these issues, however, this doesn't exist yet, and haskell is still the best option we have at this point.

> allowing procedural/local mutation, but making the procedures themselves 'pure' and taking care to control side effects on the program scale?

This is what Haskell does by encouraging you to bundle the part of your code that does mutation into, for example, a state monad, and pass the result of the monadic computation to other pure functions.

If you like another language that's a bit like Haskell-but-more-practical, give OCaml a try. They even have a for-loop in OCaml!

Your profile says

> Emacs/Lisp forever

I think of Haskell as the declarative statically typed lisp I’ve always wanted.

Rust is indeed more practical than Haskell, I wouldn't deny that. But Rust lacks full support for higher-kinded types. Exploring a few type classes (known as traits in Rust) like Applicative, Foldable, Traversable can really open your mind. An exaggerated quip by Haskellers is that there are entire libraries on NPM that simply implement the single function `traverse`. While that's an exaggeration, it really helps to look at a few dozen things the single `traverse` function can do to realize its generality.

Could you elaborate on the "more practical" bit?

I just thought of one more thing. I really like -fdefer-type-errors in GHC and wish Rust has something similar.

Both Rust and Haskell are very opinionated in the way the program is organized. Adding a seemingly small feature can often result in larger-than-expected refactoring. (In Haskell, one might need a new monad transformer layer or convert non-monadic code to monadic; in Rust one might have to rethink ownership patterns or add Rc to many places.) In GHC, type errors can be deferred until run time, until the point where the expression containing the type error is forced. If the expression containing the type error is never evaluated, the program works; if it is, you get an exception raised. This combines especially well with laziness: for example one can find the length of a list even though evaluating the element of the list would result in runtime exceptions. This is useful when I'm halfway through a large refactoring, when there are plenty of errors remaining, but I want to run my test suite to determine whether the parts without compiler errors actually pass their tests.