Freeis out of style but it's still great for some applications.
FreeApplicativeif you want to limit them to applicative composition. Among others.
Monad.join, if you're interested
I believe pretty strongly in doing local releases for OSS because of the attribution it provides, since attribution and reputation are technically the only trust mechanisms we have to go on.
For our internal stuff, my company only allows releases from CI because we don't want to trust any single individual to release code. PRs have to be approved by someone other than the author(s) of the code, and then it's published on merge.
(I haven't figured out how to make this strategy work with sbt-ci-release yet, so for the most part we're using sbt-release instead. Maybe if it only released tags that were on the default branch, since those commits must have had to go through the PR approval process? Idk.)
:point_up: September 24, 2020 5:52 PM @tpolecat
Free is kind of a specialized weirdo thing at this point.
:laughing: ... glad to see attitudes have changed in the last few years. I was mocked for saying this in my book: "It was trendy, circa 2015, to write FP programs in terms of Free".
Free for prototyping sometimes. It can be a useful tool to see how your effect algebra teases apart at a granular level without actually committing to an implementation, but it really only works for algebraic effects, and you very quickly bump up against some annoying type metaprogramming problems if you want to push it.
FreeT was a pretty awesome kernel for Coop, and I don't regret that design choice, but similarly I wouldn't put Coop into a production code path.
I think we've pretty much all learned that there are better ways of encoding effect composition than
Free, and simultaneously the mocking it enables, while powerful, isn't that useful in practice, even with tools like Smock. That kind of mocking is usually better achieved with a sprinkling of polymorphism, whether via final tagless or some other encoding.
It's still a cool toy though
I don’t see the problem with writing everything in IO.
It's not unlike writing everything with
String, you can do it and there's a lot of code doing just fine with that, but generally better modelling yields better maintainability and ease of undestanding
I never thought of it that way before
yeah I never made the connection to newtyping
it really boils down to how you view effects
usingparameter lists, we can have something more ergonomical than any other language