Haskell: A Great Procedural Language

I try to avoid >>= and >> (or *>) because I know it trips people up; do-notation is more than fine. The exception is when parsing with one of the parsecs where you get a lot of <* and *> usage and all the tutorials use those symbols.

But I like <|> , it feels very clear that it has a sort of "or" meaning.

> It's almost never "we just don't have to care" when comparing to most other popular languages.

Struggling with Haskell type system is not an experience of somebody who has developed an intuition about Haskell type system. Granted, it is not a binary thing, you can have good intuition about some parts of it and struggle with others.

I think they way you put it is, while technically true, not fair. Those "most other" languages are very similar to one another. It is not C# achievement, that you don't struggle with its type system coming from Java.

This is like people struggling with Rust because of burrow checker, well, they have probably never programmed with burrow checker before.

Funny, but I remember the difference between `>>=` and `>>` even though I haven't written Haskell in a couple of years. `>>=` passes to the right the value coming from the left, while `>>` drops it.

To give an example, you use `>>=` after `readFile` to do something with the contents. You use `>>` after `putStrLn` since `putStrLn` doesn't return a meaningful value.

With the downside of 99% of all devs not understanding anything. Sure haskell may be a great language, but even greater languages are accessible.

> first class effects

There's not really first class effects though, ultimately just IO.

When will we get the best of both worlds where the imperative parts of a Haskell program run at C++/Rust speeds?

Thanks for sharing, I really liked that!

The fully qualified type is

    traverse :: (Traversable t, Applicative f) => (a -> f b) -> t a -> f (t b)

    data MyType ... = ... deriving (Traversable)

Can you kindly make a real word example that is not usual Maybe or Either example, that uses user defined data type?

I understand how Applicative works, but I don’t know how to apply (pun intended) to my data types.

I like Haskell, but I think it suffers from the same issues preventing most lisps to gain any traction: every codebase is different and reinvents its own DSL or uses different extensions.

Lispers hailing macros and metaprogramming cannot understand that power is also the very thing that makes jumping from project to project difficult, I have no intention of relearning your cleverly designed DSL or new extensions.

There's a reason why Java or PHP have plenty of widely used killer software, while monocle-wielding lispers and haskellers have very little to show after many decades.

It's not FP being the issue, it's just that their power attracts crowds interested in code more than the features/business/product.

I don't blame them, I love Haskell and Racket but I think very few teams can scale and make the compromise worth it.

I've used Haskell several times for implementing isolated 'maths business logic units in commercial backend applications.

In one such system I built had the main (REST API exposing) backend implemented in Kotlin with a separate application in Haskell doing a complex set of maths driven business rules against GIS data to calculate area specific prices.

The amount of IO on the Haskell side was fairly minimum and abstracted away quite nicely.

Haskell allowed expressing all complexity in a way that was easy to audit and translate from business/data analyst requirements.

Would do again :-) But only with the correct amount isolation so you can lean into Haskell's strong sides.

Everyone else is responding with FOSS, so I'll respond with some companies:

Co-Star, the astrology SaaS, is apparently written with a Haskell backend. I'd love to have seen the casting call for that.

I believe the Mercury bank also runs most of their backend stuff on Haskell. Functional languages in general are surprisingly common among financial investment firms.

Some of Target's stuff is written in Haskell. I think there was at least one big Facebook project that was written in Haskell, but they may have moved away from it by now. Awake Security does some Haskell stuff.

One thing which might be surprising is Haskell is apparently quite strong for general backend web dev.

https://hledger.org/

hledger - a plain text accounting tool

https://simplex.chat/

Private messenger for desktop and mobile platforms. It's mostly written in Haskell except for UI.

Don't forget Pandoc!

https://tidalcycles.org/ – think ImplicitCAD but for live music performances?

also http://detexify.kirelabs.org/classify.html was surprisingly useful in university

PostgREST and Hasura (before rewrite) are written in Haskell.

It's a thirty year-old language, it's bound to have cruft. However modern codebases tend to showcase a pretty efficient combination of language features, oftentimes optimised for productivity rather than research in lazy FP. Such codebases are https://github.com/flora-pm/flora-server or https://github.com/change-metrics/monocle

In practice it only detracts a little bit. You can enable GHC extensions project-wide and there are alternate standard libraries (preludes) that are more modern.

If you want a language that is very Haskell-like without the historical baggage or the laziness, PureScript is very good. It’s main compile target is JavaScript, so it’s built for different use cases.

Am I right in thinking that there are efforts to provide a better out-of-the-box experience, with some of that cruft dealt with for people who don't need the backwards compatibility? For myself, I found long prologues of extensions/options/whatever massively off-putting.

What cruft?

Maybe I'm not so bad for using "superfluous" braces quite often, although this is not specifically the reason why I do.

This is a bit surprising. Why replace `>>` with `*>` "because it's more modern"? Can't you just stick with what's working? The former hasn't been deprecated.

> Working with the IO monad is much more complex, especially if you want to use other monadic types inside that code.

Yes, mixing other monadic types with IO can be a challenge. One possible solution to that is not just not use other monadic types inside the code. Just use a general-purpose effect system instead. I recommend effectful or Bluefin (the latter my own project).

> Is there any parallel there

Of course. Promise is a monad, .then is more or less equivalent to the >>= operator and await makes it look more imperative-ish just like <- in Haskell.

Note that in JS you'll need to be inside an async function to use await, just like in Haskell you'll need to be inside the do notation to use <-. Otherwise, you'll need to play with .then just like you would need to play with >>= in Haskell.

About other languages, one way to achieve asynchronous behavior without having it implemented in the language is using ReactiveX (https://reactivex.io/). It's hard to understand at first, but it if you understand the IO Monad it becomes easy, as it's basically the same.

Yes, except in a lot of languages, a Promise is the representation of the result of a computation that may already be happening, whereas an IO is a computation that will have data injected into it by some interpreter. But it's a very close comparison, in the sense that both represent contexts that future computation can be appended on. Also, in some languages, the Promise type is truly monadic.

There’s a parallel because Promises in a language like JavaScript are “monad-like”, so they’re similar to the IO Monad here. I am not a functional wizard so I’m sure that was not a fair comparison in some way, but it’s how I have thought of it. They’re both a representation of a side effect and require that effect be respected before you can get to the value inside it

> The way I think about effectful computation and IO in Haskell is as a kind of enforced metaprogramming

If you think of effectful computation in Haskell to be a sort of metaprogramming, then indeed it will seem very complex, absurdly complex actually.

If you think of it as just the same as programming in any other language, except functions that do effects are tagged with a type that indicates that, then I think things will appear much simpler.

I prefer thinking of it as the latter, and it's been very effective (pun half intended) for me.

When you express it has "Haskell has the IO monad" and "Haskell has the Maybe monad", it's no biggie because other languages have them. All Java Objects might or might not be there (so they all implement Maybe). And all Java methods might or might not do IO, so they all implement IO.

The real sell is: Haskell objects which are not Maybe are definitely there. Functions which are not IO will always give the same input for the same output.

I think as long as the code sticks to the discipline of never actually doing I/O but only manipulating functions that perform them it would basically be doing the same thing as IO monads in Haskell.

So print(s) returns a function that when called prints s. Then there needs to be function that joins those functions, so print(a); print(b) evaluates to a function that once called prints out a and then b.

What makes Haskell special in my opinion is 1) it generalises this way of achieving "stateful" functions, 2) enforces such discipline for you and makes sure calling functions never produces side effects, and 3) some syntactic sugar (do, <-, etc) to make it easier to write this kind of code.

Also note that the above example only does output which would be the easier case. When it comes to code with input, there will suddenly be values which are unavailable until some side effects have been made, so the returned functions will also need to encode how those values are to be obtained and used, which complicates things further.

> Is this really so different from IO everywhere in Haskell?

It's a starting point. You'll have to somehow chain (e.g. you want to print "def" after "abc", how would you do that?). You'll also need to put a value into your IO, e.g. if you are inside that IO, all the computations will need to produce IO. If you solve those things, you'll have a Monad.

But, wait! You're in JS, right? You have IO Monads there, perhaps only don't know yet. They are the JS Promises! Look this:

// assuming that you have a sync input function, that receives a string from stdin and returns it

let input_str = new Promise((resolve, reject) => resolve(input());

let input_int = input_str.then(s => parseInt(s));

let square = input_int.then(n => n * n);

square.then(sq => console.log(sq));

If you want to proceed with your poor man's IO, you'll need to implement your "then". Going further, the equivalent in Haskell (not the best code, though) to that is:

main = result

  where input_str = getLine

        input_int = input_str >>= \s -> return (read s) :: IO Int

        square = input_int >>= \n -> return (n * n)

        result = square >>= \sq -> putStrLn (show sq)

main = do

  input_str <- getLine

  let input_int = read input_str :: Int

  let square = input_int * input_int

  putStrLn (show square)

let input_str = await new Promise((resolve, reject) => resolve(input()));

let input_int = parseInt(input_str);

let square = input_int * input_int;

console.log(square);

A function from a fixed input is a monad (called the “Reader” monad). If you constrain all IO to happen underneath that function then it will be deferred until you evaluate the result.

In those senses, these are the same. You can emulate the IO monad in this way.

Haskell provides guarantees that make this stronger. There is no way to perform IO-like side effects except via the IO monad. And no way to “evaluate” the IO monad except to declare it as your main entry point, compile, and hit play.

(Except unsafePerformIO, of course, the highly discouraged escape hatch).

These restrictions are actually what makes the use of the IO monad powerful. As you show, it’s easy to “add” it to a language, and also almost valueless. The value is in removing everything that’s not in the IO monad.

That IO is roughly the same. The point of Haskell is not to "have IO". It's to know that when something is _not_ in IO, it's pure. _That_ is what other languages don't have. (Although they could, as far as I know. It's a _restriction_ on exposed primitives, not a feature.)