no you don't actually need algebraic effects. Servant works greatly without them, and I don't see so much benefit of abstracting your code with them right now.
You rightly lost him at polysemy. Just use `ReaderT env m` (RIO) and use type classes to constrain effects on `m` when you need to. polysemy itself isn't bad, but this constant churn w/ people re-implementing algebraic effects is a part of in-community hipsterism more than anything. `ReaderT` solves almost all practical problems app developers stumble upon but some people aren't interesting in just solving problems. More power to them, but leave them in their corners to do their thing and focus on being productive. If you haven't, read "The ReaderT Design Pattern" by FP-complete/Michael Snoyman and process it and realize it basically will cover almost all use cases you've ever had.
@@mccGoNZooo Just ran across this. I see the statement *something* solves almost all practical problems. You stated that *something* was ReaderT, and long ago that *something* once was stated by others to be assembly language, procedural programming, global mutable states, you name it. I am not necessarily against the ReaderT pattern, but deep in its nature, ReaderT Config IO is just trying to write impure-by-default programs with read only global variables. It might just work, but that does not imply we should live with it. I recall SPJ once said something like "it is better for Haskell not to get very popular", because wide adoption will almost always bring in many users (usually big enterprises) who constantly pull back on the evolution of the language.
Maybe it is painless later. But to setup Haskell on the computer is excruciating. I could never figure out how to do it correctly. Always a bunch of installation errors. Ghcup, stack, doesn't matter. You will loose hours to make it work for a day. It'll stop working another day and you won't be able to figure out why.
that's why I'm in love in Haskell
Just wow! I was already interested in Haskell, now I'm really interested. Thanks so much!
Before you start with cabal))
Servant is truly a blessing in Haskell
I giggled at "maybe extend your haskell knowledge"
Servent seems really cool. But polysemy did not click at all with me.
Great talk!
Heh. You spelled "painful" wrong.
Intriguing...
Reksio
So Polysemy is the same as free monads (freer library)? Or what is the difference?
The readme says "It's like freer-simple but more powerful", unfortunately don't know what that "more powerful" means there :)
*Thank you!*
I lost him at polysemy. Guess I need to learn GADTs
no you don't actually need algebraic effects. Servant works greatly without them, and I don't see so much benefit of abstracting your code with them right now.
You rightly lost him at polysemy. Just use `ReaderT env m` (RIO) and use type classes to constrain effects on `m` when you need to. polysemy itself isn't bad, but this constant churn w/ people re-implementing algebraic effects is a part of in-community hipsterism more than anything. `ReaderT` solves almost all practical problems app developers stumble upon but some people aren't interesting in just solving problems. More power to them, but leave them in their corners to do their thing and focus on being productive.
If you haven't, read "The ReaderT Design Pattern" by FP-complete/Michael Snoyman and process it and realize it basically will cover almost all use cases you've ever had.
@@mccGoNZooo the most wholesome comment I've read in a while. Couldn't agree more.
@@mccGoNZooo Just ran across this. I see the statement *something* solves almost all practical problems. You stated that *something* was ReaderT, and long ago that *something* once was stated by others to be assembly language, procedural programming, global mutable states, you name it. I am not necessarily against the ReaderT pattern, but deep in its nature, ReaderT Config IO is just trying to write impure-by-default programs with read only global variables. It might just work, but that does not imply we should live with it. I recall SPJ once said something like "it is better for Haskell not to get very popular", because wide adoption will almost always bring in many users (usually big enterprises) who constantly pull back on the evolution of the language.
Rename it to "Painless software development with cabal")
Maybe it is painless later. But to setup Haskell on the computer is excruciating. I could never figure out how to do it correctly. Always a bunch of installation errors. Ghcup, stack, doesn't matter. You will loose hours to make it work for a day. It'll stop working another day and you won't be able to figure out why.
nix adresses this (and for installing other software too)
Control.Monad.Tardis
Haskell not magic so elixir
Apples and oranges