Lambda World 2018 - The Complexity Trap: Think Before You Leap - Daniel Westheide

My take away: When confronted with problems, take a step back to see if there is a way those problems could not even exist, instead of pushing straightforward into finding a solution

Once I commented on Reddit (and got lots of negative points) that "throwing more and more types on your code won't make it magically better/simpler/flexible". I expect the same here.

I liked most of the talk and agreed with most of what Daniel said, but the point about Tagless Final isn't complete.

If you abstract on effects and use powerful typeclasses like cats-effect's Sync/Async/LiftIO, etc., then you can no longer even use Id in tests.
The interpreter for your algebra should also not be any different in the tests than the one you use in production, you're just going to stub the dependencies so that you can verify how you interact with them (so you're not testing the test interpreter, but the real one).

And if we lose the reason for testability, or swapping effects (which I agree does not happen very often or at all), there's still one important point - you describe your interpreter in terms of its abilities, and you limit these abilities as much as possible.
In a video app, you might have `VideoUploadService[F[_]: Monad: VideoStore: UserNotifications]`, and you immediately see what the interpreter is capable of. By hiding abilities to execute arbitrary side effects (which would be given by e.g. having `F[_]: Sync`), you constrain your interpreter to just a few capabilities. Then you can stub the VideoStore and UserNotification interpreters, and unit test yours (in fact, even with Id).

I agree, we should fight complexity, and we must not use development process as a playground. But I think the way, that Daniel presented here is incorrect in the example of SPA. We reduce complexity by reducing features, this in my opinion wrong, and could lead business to be replaced by competitors. All in all, if we don't need SPA, we can say, "html is too hard to maintain, let's leave only CLI for our users". And then why we ever need UI? Why we ever need IO? Ironically, we will come to Haskell without Monads :)

Complexity would be fiddling with the mic adjusting its settings, instead of switching to a different one