You are right, Type Class and Higher-kinded types can be challenging to understand at first. But the good news is, we will see a lot of examples of using them in the rest of this course.
Good video. You're one of the few people even in fp who actually know that there's different kinds of polymorphism than just "polymorphism". However, your example of a generic function returning `${a}` isn't correct because that's basically calling tostring while a real generic function has no idea what functions a can use. This is another reason TS isn't suited to teaching FP, on top of the fact that it doesn't even have a real type system and every type is just an alias. The strategy pattern is an OOP idea, in FP that's just something you get with higher order functions automatically. If you're trying to compare this to OOP then you should probably have mentioned that typeclasses implement the expression problem in the way OOP does it by default, so really it's sum types and pattern matching that give FP the one up, but typeclasses are actually very familiar to OOP users, just in a less flexible manner. One question that i never understood though. Are typeclasses kinds themselves? When i first learned about them i thought of them as types of types but then learning about kinds messed with that mental model
@@webvv Well this video wasn't meant to focus on it so it'd be hard to really give a good example because explaining parametric polymorphism requires multiple examples. By just passing in an `a` the only thing you can do with it is return it which is why the most generic function is identity. But I think emphasizing that while polymorphism is about using the same interface, parametric polymorphism is a way to "use the same code for different types" while ad-hoc is a way to "have unique code per type". This means that parametric polymorphism is very general code that knows nearly nothing about its generic arguments and is more concerned with some general structure, while ad-hoc is specific and knows a lot about the arguments. Also you emphasize ad-hoc as being something special and used a lot in FP but as I mentioned, OOP uses it a ton. In fact overriding, overloading, and subtyping are all ad-hoc polymorphism. FP having typeclasses is more like it trying to be like OOP than something unique about it (I don't mean that literally, just from the perspective of somebody new).
Is there a reason to use weird names and definitions like haskel does? Examples: 1) Why Either when you never sure if there is only 2 ways. If it is call it Result like rust. 2) Same with Maybe->Option 3) parametirkgjskwl polymorkdkfgjjs. Jesus. In rust we have implementation s. Need different implementations for different types - ez. I like easy. I dont like weird definitions that you can't remember and need to read a lot of books and still not be sure what is what. I find fp-ts really confusing. While its mostly coming from haskel, there is almost zero practical documentation. Also typescript does terrible job. Ok my crying is over.
I don't see how this is coding at the level of kinds. Isn't this type level programming? Kinds exist because we want to abstract over types and have polymorphism but we're not abstractions over kinds or else we would need to add another level of abstraction
Whoof! That was a hard one to digest. Thank you for the explanation!
You are right, Type Class and Higher-kinded types can be challenging to understand at first. But the good news is, we will see a lot of examples of using them in the rest of this course.
So knowledgeable of the topic
❤️
Amazing video!
Now I realize why it was so difficult for me to understand type classes with Fp-ts😅
You are not alone, it took me some time to wrap my head around figuring out how things work.
Excellent
❤️
I love your explanations!
Thank you Recardo for following the series!
Nice explanation. Keep up the good work!
Thank you, will do!
Good video. You're one of the few people even in fp who actually know that there's different kinds of polymorphism than just "polymorphism".
However, your example of a generic function returning `${a}` isn't correct because that's basically calling tostring while a real generic function has no idea what functions a can use. This is another reason TS isn't suited to teaching FP, on top of the fact that it doesn't even have a real type system and every type is just an alias.
The strategy pattern is an OOP idea, in FP that's just something you get with higher order functions automatically. If you're trying to compare this to OOP then you should probably have mentioned that typeclasses implement the expression problem in the way OOP does it by default, so really it's sum types and pattern matching that give FP the one up, but typeclasses are actually very familiar to OOP users, just in a less flexible manner.
One question that i never understood though. Are typeclasses kinds themselves? When i first learned about them i thought of them as types of types but then learning about kinds messed with that mental model
Thank you for your feedback. For the Parametric polymorphism what do you think can be a good example?
About your question, I don’t know the answer.
@@webvv Well this video wasn't meant to focus on it so it'd be hard to really give a good example because explaining parametric polymorphism requires multiple examples. By just passing in an `a` the only thing you can do with it is return it which is why the most generic function is identity.
But I think emphasizing that while polymorphism is about using the same interface, parametric polymorphism is a way to "use the same code for different types" while ad-hoc is a way to "have unique code per type". This means that parametric polymorphism is very general code that knows nearly nothing about its generic arguments and is more concerned with some general structure, while ad-hoc is specific and knows a lot about the arguments.
Also you emphasize ad-hoc as being something special and used a lot in FP but as I mentioned, OOP uses it a ton. In fact overriding, overloading, and subtyping are all ad-hoc polymorphism. FP having typeclasses is more like it trying to be like OOP than something unique about it (I don't mean that literally, just from the perspective of somebody new).
Is there a reason to use weird names and definitions like haskel does?
Examples:
1) Why Either when you never sure if there is only 2 ways. If it is call it Result like rust.
2) Same with Maybe->Option
3) parametirkgjskwl polymorkdkfgjjs. Jesus. In rust we have implementation s. Need different implementations for different types - ez.
I like easy. I dont like weird definitions that you can't remember and need to read a lot of books and still not be sure what is what.
I find fp-ts really confusing. While its mostly coming from haskel, there is almost zero practical documentation.
Also typescript does terrible job.
Ok my crying is over.
great
Thanks
thank you! very interesting :)
You’re very welcome :)
I don't see how this is coding at the level of kinds. Isn't this type level programming? Kinds exist because we want to abstract over types and have polymorphism but we're not abstractions over kinds or else we would need to add another level of abstraction