9:24 - If code doesn't work for you to, in scala 3.4.2 you need to write "given listFunctor: Functor[List] with" IDK what happened with "as" keyword Im new to this too :P
This is one of the best videos i watched on this channel, this is a must for all those wanting to do proper functional programming, and of course the rest of the category theory programming imo (monad, monoid, type classes -- supported in scala 3 now without too much typing-- and many others)
Really like the video. After a mid video epiphany I would love to see a series of this small type classes building something larger for free. E.g. Functor + Applicative + Monoid of Tree allows me to do X for free, for some X that is complex.
Hi, question: I still do not understand the exact applicability of an Functor, or better say, in combination with a typeclass. I do understand the concept of "mapping" and reusing this construct to multiple datatypes, but, you said in the video that you reduced this API to a single method with the given functor implementation. How I see it, is, what you actually did is moving the implementation to multiple typeclasses (list, option, leaf etc.). You need the implementation of the map function for different types. Why using all these abstract and complicated language constructs to reduce the method/api to a single method? So, why not just define a simple trait / interface? No typeclasses, no extention functions, no implicit stuff (dependency), no misdirection etc.
Legit question. The idea is we're moving code so we can keep a "stable" API and then "plug" in different implementations as we see fit. The moving of code to reduce duplication happens at all levels. Think of the standard OO polymorphism: it serves a similar purpose, whereby you rely on an instance of a general type (e.g. Animal) in a stable API but then at runtime you can use Cats, Dogs, Crocodiles in your actual logic, instead of explicitly handling Cats, Dogs, Crocodiles directly in your public API.
At 4:23 you mention that java.util.Optional has the same semantics as scala.Option, but that is not true; Java's Optional can't contain null, but Some(null) is perfectly allowed in Scala. While probably no programmer on earth would explicitly instantiate an Option with null on its initial creation, this situation can still occur when trying to map a function over an option. If the function used as the argument for map returns null, then Java's Optional#map will return the empty Optional, but Scala's Option#map will return Some(null).
Partially true. Some(null) is allowed in Scala but it's an anti-pattern, much like Optional.of(null). The map method of optionals will return None if the resulting optional is empty. Even so, the validity of the statement does not change: the semantics are the same, as both Scala Option and Java Optional were built for the same purpose.
What is a generic for you? And why you think a Functor is something similar? - BTW, I would encourage you to ask this and future questions in the gitter channel or in the Scala sub-reddit since you would get more audience :)
A "generic" is the language feature of using the same code for more than one type, e.g. the List logic is the same for Ints, Strings, etc. A Functor is a particular kind of concept (a "mappable" data structure) that we attach to a particular set of types (in this case, List, Option and Tree).
![[#2024MAMA] BIGBANG (빅뱅) - 뱅뱅뱅 (BANG BANG BANG) + FANTASTIC BABY | Mnet 241123 방송](http://i.ytimg.com/vi/EQsYfiPR9uM/mqdefault.jpg)
9:24 - If code doesn't work for you to, in scala 3.4.2 you need to write "given listFunctor: Functor[List] with" IDK what happened with "as" keyword Im new to this too :P
I'm positively mind blown after this tutorial, 10/10
This is one of the best videos i watched on this channel, this is a must for all those wanting to do proper functional programming, and of course the rest of the category theory programming imo (monad, monoid, type classes -- supported in scala 3 now without too much typing-- and many others)
Glad you liked it!
As always, a high quality tutorial and explanation 👍 particularly excited to see more examples of Scala 3 in action.
Glad you liked it!
_Looks at Scala history page_ : "Scala was designed to be a better Java"
Me: Oh sweet! I'm going to learn a new language.
Me after the video: :O
I have grasped it finally. Thank you, Daniel! I can't wait to watch another similar one for monads.
Glad it helped!
Wow Daniel !!
This video is very inspiring
Scala rocks !!
11:37 line 32 could you further abstract over the concrete type C[Int]... similar to C[?] perhaps
Top notch quality. Loved it.
You are awesome, still looking your videos one by one
Hi Daniel
Thanks!! Yet another awesome video :-) . Great content, and perfect length.
Glad you liked it!
Great Explanation, now please consider to make video on Applicative.
The Cats course has all of them in great detail!
Very good! Takes the ghost out of the Functor
That's the goal
Really like the video. After a mid video epiphany I would love to see a series of this small type classes building something larger for free. E.g. Functor + Applicative + Monoid of Tree allows me to do X for free, for some X that is complex.
Nice nuanced wish. Will think of something
Hi, question: I still do not understand the exact applicability of an Functor, or better say, in combination with a typeclass. I do understand the concept of "mapping" and reusing this construct to multiple datatypes, but, you said in the video that you reduced this API to a single method with the given functor implementation. How I see it, is, what you actually did is moving the implementation to multiple typeclasses (list, option, leaf etc.). You need the implementation of the map function for different types. Why using all these abstract and complicated language constructs to reduce the method/api to a single method? So, why not just define a simple trait / interface? No typeclasses, no extention functions, no implicit stuff (dependency), no misdirection etc.
Legit question. The idea is we're moving code so we can keep a "stable" API and then "plug" in different implementations as we see fit.
The moving of code to reduce duplication happens at all levels. Think of the standard OO polymorphism: it serves a similar purpose, whereby you rely on an instance of a general type (e.g. Animal) in a stable API but then at runtime you can use Cats, Dogs, Crocodiles in your actual logic, instead of explicitly handling Cats, Dogs, Crocodiles directly in your public API.
Quick comment this works with Scala 3.0.0M3 but there have been some syntax changes. Fundamentally the as token was dropped.
Thanks for the tip - take the ideas and stick the new syntax.
beautiful
At 4:23 you mention that java.util.Optional has the same semantics as scala.Option, but that is not true; Java's Optional can't contain null, but Some(null) is perfectly allowed in Scala. While probably no programmer on earth would explicitly instantiate an Option with null on its initial creation, this situation can still occur when trying to map a function over an option. If the function used as the argument for map returns null, then Java's Optional#map will return the empty Optional, but Scala's Option#map will return Some(null).
Partially true. Some(null) is allowed in Scala but it's an anti-pattern, much like Optional.of(null). The map method of optionals will return None if the resulting optional is empty.
Even so, the validity of the statement does not change: the semantics are the same, as both Scala Option and Java Optional were built for the same purpose.
quite the beginner here so sorry if its a dumb question -how does a functor differ from a generic ?
btw thank you for all your vids, they are invaluable !
What is a generic for you? And why you think a Functor is something similar? - BTW, I would encourage you to ask this and future questions in the gitter channel or in the Scala sub-reddit since you would get more audience :)
A "generic" is the language feature of using the same code for more than one type, e.g. the List logic is the same for Ints, Strings, etc. A Functor is a particular kind of concept (a "mappable" data structure) that we attach to a particular set of types (in this case, List, Option and Tree).
@@rockthejvm thank you for this just seen it !!my understanding is slowly but surely improving, thanks to you ! appreciate it
great
Is there a button to like the video twice?
:D