How do you do this cleanly when, e.g., you need to make a network call and then based on what the result returned to you is, either do something with a local database, make a different network call, or return a result to your user. Also, error handling...
It seems to me like monads must be the logical conclusion to this style of programming, or else you wind up with a mess (or just abandoning this technique.)
Now of course, you don't have to cleanly separate a functional core from a stateful shell. But if you don't, all of your code is going to end up wrapped in nested Monads declaring all of the ways that it's inadvertently stateful, and that's a very painful way to program. So Haskell pushes you strongly towards having a functional core and stateful shell.
For projects written in Haskell, the wiki has a long list: https://wiki.haskell.org/Haskell_in_industry
Yeah, I guess the `do` notation makes it pretty painless. If you start mixing monads, though, things get hairy quickly.
It also provides a huge opportunity for testing. At a very high level, you describe all of your effects as a series of embedded, compostable DSLs that you define interpreters for. The awesome part is that you can switch out the interpreters at will, so you can, for example, replace something that handles network requests with something that returns dummy data almost effortlessly.
http://hackage.haskell.org/package/transformers-0.5.5.0/docs...
> It also provides a huge opportunity for testing. [...]
That's a neat point, thanks for bringing it up.
Most of the code (Layout.hs and StackSet.hs) is pure and has extensive unit (property-based) tests for all the pure functional core.
https://github.com/xmonad/xmonad/tree/master/tests/Propertie...
Then there is a layer that talks to X11 and interfaces with the functional core. (Core.hs and Main.hs)
You don’t need full blown monads to do this, just need to be cognizant to how you separate the what (functional core) from the how (imperative shell). I recommend giving it a try!
It's really extremely productive to code this way... I wrote a job scheduler from scratch in 3 months and never once had to write or use a mutex or semaphore. Immutability makes you very confident about your code.
Similarly, my UI guy wrote a UI in basically functional react. It's amazing. With very little js experience I made code patches that.. just worked because I was guaranteed that no function calls had mysterious side effects...
It's quiet the opposite really from what I've seen. Elixir places absolutely no constrains on when and how IO happens, and provides extremely useful primitives for shutting state between (VM) processes in otherwise stateless code. A library function that looks totally pure could, for example, boot an entirely different subsystem that fired a missile into the sun before providing a return value and you'd never know it if you didn't read the docs, or use one of many pieces of fantastic beam tooling to inspect the runtime state of the system.
This is part of what makes these languages pragmatic to work in. There are foot guns everywhere, but the VM ensures you sign into the foot gun registry whenever you use them.
For a fp react example: https://github.com/streamproject/cryptopotamus-web
Here is a good talk about these ideas: https://www.youtube.com/watch?v=US8QG9I1XW0
This is a good example:
https://www.theerlangelist.com/article/spawn_or_not
(Note the context is Elixir, so it’s talking about lightweight processes, not OS processes. It explains how to keep that stateful / effectful code very simple, and have all the real logic be pure functional code.)
A lot of apps out there do nothing more than fetching data from one service, and dumping it out to another.
The good part is the set of pure functions that take input and compute something from it.
But the awkward part (assuming you're coding in a typical mainstream imperative language) is the "transaction script" that gets an input, passes it to the pure functions, and then takes the result and writes it out. If there's no event loop and you're not using promises or something like that, it forces an awkward boundary right down the middle of your code that just feels unnatural.
Still, I think it's worth it for many problems. The vast majority of your code is pure functions -- simple, understandable, testable. The price you pay is this unnatural seam at each point of IO.
Monads are nice, but there's a lot of work on algebraic effects/effects in general which may pan out into something useful (and more general).