Good talk, thanks for sharing. I was hoping a bit more on error handling (raiseError, attempt, etc) but I guess that is a topic it can take 1 hour on its own.
The only question here is (which is really bothring me): if we've already push our team go this far into the world of categories, monoids, arrows etc... why not we just move one step further: that we change our lang of choice to Haskell.
Or let me put it this way: think if we are going to build such a feature toggle framework, which links each peace of code to an user story from eg jira. Let's asume the team works with a trunk based manner: each line of code will be ACTRUALLY DEPLOYED TO PROD if it's pushed to the repo. At the same time, whether or not the line of code should be ACTUALLY EXECUTED, or the behaviour of the whole software should be determined by the status of the "user story": whether the idea is A/B testing, rolled back, done, managed by the toggle system. What should the model of this feature toggle (story toggle) management system be like? If we use monadic combinators to orchestrate our codes pieces, the model could be very easy to understand in the context of arrows&categories and could be implemented relatively easier in languages such as Haskell. And might even be some how transparent to the developer of each story.
cats is a higher-order library, meant to solve advanced problems, built on typeclasses, which are not for beginners. There's no point watering it down to some useless "hello world" examples just to make it beginner friendly.
Excellent talk, the best so far that I have found on the subject.
Nice talk, very clear with well explained motivations for using IO
Good talk, thanks for sharing. I was hoping a bit more on error handling (raiseError, attempt, etc) but I guess that is a topic it can take 1 hour on its own.
Thanks, nice talk. Time to get into Cats ;-)
Very nice presentation, thank You! :)
Excellent! Thanks!!
What is the library these slides were compiled with?
The only question here is (which is really bothring me): if we've already push our team go this far into the world of categories, monoids, arrows etc... why not we just move one step further: that we change our lang of choice to Haskell.
Or let me put it this way: think if we are going to build such a feature toggle framework, which links each peace of code to an user story from eg jira. Let's asume the team works with a trunk based manner: each line of code will be ACTRUALLY DEPLOYED TO PROD if it's pushed to the repo. At the same time, whether or not the line of code should be ACTUALLY EXECUTED, or the behaviour of the whole software should be determined by the status of the "user story": whether the idea is A/B testing, rolled back, done, managed by the toggle system.
What should the model of this feature toggle (story toggle) management system be like? If we use monadic combinators to orchestrate our codes pieces, the model could be very easy to understand in the context of arrows&categories and could be implemented relatively easier in languages such as Haskell. And might even be some how transparent to the developer of each story.
It doesnt seem beginner friendly :)
agreed. but yes to bit and pieces. makes me still thankful.
Agree. Don’t get me wrong. Cats ecosystem is great.
cats is a higher-order library, meant to solve advanced problems, built on typeclasses, which are not for beginners. There's no point watering it down to some useless "hello world" examples just to make it beginner friendly.
@@abhijit-sarkar got it, professor. 🫡
don't get me wrong, this is a great video.