Thanks so much for these videos, even when they are on something I've used before and though I knew very well there are some awesome takeaways. I have a handfull of things I'd be excited to hear broken down by you - Traversals - Lens's - denotational semantics - Transformers Or you mentioned how we tend to take monads as a sledgehammer to any problem when there are other natural representations for some such as applicative or arrow, could you give some examples of domains that fit particularly well into each one or helpful intuition on which is best for which scenario? :)
Monad Transformers will be the topic of the next video! Traversels will also be talked about at some point probably. Arrows are very helpful when the dataflow of your algorithm has to split at certain points (e.g. boolean circuits or a bayesian networks). John Hughs presents an interesting example of a data stream impremented with arrows and gives a nice explanation on the limitations of monads: "But whereas monadic computations are parameterised over the type of their output, but not their input, arrow computations are parameterised over both. The way monadic programs take input cannot be varied by varying the monad, but arrow programs, in contrast, can take their input in many different ways depending on the particular arrow used. The stream function example above illustrates an arrow which takes its input in a different way, as a stream of values rather than a single value, so this is an example of a kind of computation which cannot be represented as a monad." ( www.cse.chalmers.se/~rjmh/afp-arrows.pdf ) What is "best" for a given situation is a hard question to answer. If composition is very important, I think that arrows are better suited than monads. There are very exotic examples where applicatives are actually the way to go ( wiki.haskell.org/Applicative_functor ). In this case conditional initialization cannot be done by a monad but CAN be done by an applicative.
I’m appreciative of your efforts and approach but between this video and the previous one, I am pretty sure you’ve lost the imperative programmers referred to in the title of this series! The levels of abstraction required to implement a simple pipe are orders of magnitude greater than with imperative programming.
This series is aimed at programmers with an imperative mindset wanting to learn Haskell. I think a big part of learning how Haskell works (and differs from many other languages) is the sometimes daunting amount of abstraction. If a viewer has stuck around for 37 episodes I think they are ready to go down the rabbit hole. ;) Atleast that's what I'm hoping! The next two or three videos will probably close this excursion into abstract / formal topics and come back to lighter topics.
Your find your videos a much better resource to learn Haskell than many "professionally written" textbooks. Understandable, concise and to-the-point.
I love your videos. They are an important part of my journey to learn Haskell and FP in general. Thank you for making this content!
Thanks for these videos Phillip. They are a great source for newcomers to Haskell.
Thanks so much for this video and this series in general
i know I am quite randomly asking but do anyone know of a good website to watch new tv shows online?
I have never used my brain harder than when watching this video 😅
You should have talked about proc notation as well.
It would be interesting to explain the instance definition of ArrowApply (->), especially the recursive usage of variable 'd' in
let (c,d) = f(b,d).
11:45 In the 'delete' flow example the filter should test for (/= w).
Thanks so much for these videos, even when they are on something I've used before and though I knew very well there are some awesome takeaways. I have a handfull of things I'd be excited to hear broken down by you
- Traversals
- Lens's
- denotational semantics
- Transformers
Or you mentioned how we tend to take monads as a sledgehammer to any problem when there are other natural representations for some such as applicative or arrow, could you give some examples of domains that fit particularly well into each one or helpful intuition on which is best for which scenario? :)
Monad Transformers will be the topic of the next video! Traversels will also be talked about at some point probably.
Arrows are very helpful when the dataflow of your algorithm has to split at certain points (e.g. boolean circuits or a bayesian networks). John Hughs presents an interesting example of a data stream impremented with arrows and gives a nice explanation on the limitations of monads: "But whereas monadic computations are parameterised over the type of their output, but not their input, arrow computations are parameterised over both. The way monadic programs take input cannot be varied by varying the monad, but arrow programs, in contrast, can take their input in many different ways depending on the particular arrow used. The stream function example above illustrates an arrow which takes its input in a different way, as a stream of values rather than a single value, so this is an example of a kind of computation which cannot be represented as a monad." ( www.cse.chalmers.se/~rjmh/afp-arrows.pdf )
What is "best" for a given situation is a hard question to answer. If composition is very important, I think that arrows are better suited than monads.
There are very exotic examples where applicatives are actually the way to go ( wiki.haskell.org/Applicative_functor ). In this case conditional initialization cannot be done by a monad but CAN be done by an applicative.
Thanks for the references and looking forward to the Transformers video!
Why no "Arrow proc" notation?
hi i'm just starting but it is your newest video so i ask here: will you do a video about stack and project menagment for haskell ?
It's unlikely since I don't really know much about these topics!
These videos are helpful.
I’m appreciative of your efforts and approach but between this video and the previous one, I am pretty sure you’ve lost the imperative programmers referred to in the title of this series!
The levels of abstraction required to implement a simple pipe are orders of magnitude greater than with imperative programming.
This series is aimed at programmers with an imperative mindset wanting to learn Haskell. I think a big part of learning how Haskell works (and differs from many other languages) is the sometimes daunting amount of abstraction. If a viewer has stuck around for 37 episodes I think they are ready to go down the rabbit hole. ;)
Atleast that's what I'm hoping! The next two or three videos will probably close this excursion into abstract / formal topics and come back to lighter topics.
Yass.. Thanks for the video
this one was abstract haha