There's a huge advantage to not everything being async/await. Knowing exactly when you yield control can give you atomicity and more determinism for free.
You could use XML data structures in which some of the elements are programs that you can execute (program is data), other are graphic, other are links to more XML data and so on. And your program is able to process that information.
Use of compile-time type checking to make changing interfaces easier is a great trick. A great trick may mislead many to see it as the only one in the book. Then you get dumbfounded looks and a troublesome question arises: how can these large systems written in not-so-static languages (indeed, no thought about "systems") possibly grow and evolve? And yet, they do.
Maybe it's time to reconcile with reality: there is more than one way to operate; there is value in more than one paradigm.
Everything is of course possible, but at what cost?
In my experience, with large projects, you get to pick 2:
Dynamic typing
Development velocity
Reliability
I've seen multiple large projects grind to a near halt in their development speed, and I've seen some retain development speed, but unreliably crash after various changes.
UT coverage is expensive. System tests don't catch everything. Either you fear changes, and the system rots, or you work very slowly with coverage for everything.
Unfortunately, that doesn't match my experience at all. Haskell requires understanding many more concepts to use effectively than Clojure. Lazy evaluation, large syntax, and the advanced type system all add complexity. My experience is that it takes people a long time before they're able to read and write idiomatic Haskell code without assistance.
With Clojure, we're able to do a very quick ramp up, and then have new hires write code with very little assistance from the rest of the team. I simply haven't seen this be the case with Haskell even for experienced developers.
I suspect the problem is mentoring. It took me months to get basic Haskell.
The people I mentored, though, could clarify any misunderstanding and get explanations from multiple viewpoints from me -- after years of experience with these abstractions. With such mentoring, you don't have to go through all the confusion phases.
The core point here is that Haskell is a more complex language that requires understanding and applying more concepts to write effective idiomatic code. Mentoring does help, but you still need to build a mental model of using the language, and there isn't a shortcut for that. Clojure requires a smaller mental model than Haskell, and that makes it easier to learn. The end result is that you have to spend less time ramping people up.
If Haskell works for your team that's great though, it did not work for mine.
I think the thing is, if you want to write at a Clojure-level-abstraction, Haskell won’t stop you doing that and I get the impression that it’s actually the way a lot of Haskell programmers operate. (Chas Emerick has recently been advocating this approach and I get the impression it’s actually the style of GHC itself.)
Clojure people use the untyped equivalent of row types, i.e. being able to arbitrarily add and remove fields to and from a record. That would be nice to have in Haskell (though personally it's nowhere near a dealbreaker for me).
Right! that definition was the type, thanks for the correction :) still, the Maybe monad is used for computations that may fail, which is often the purpose of the null pointer.
