I've been dipping my toe into FP for decades, but most of the teaching material is opaque for anyone who isn't mathematically literate. Scott is the first FP teacher I've found who can explain the value of FP for regular line-of-business type work. This talk is pure gold - along with his website and his outstanding book on functional DDD. If anyone is struggling to understand the essence of functional thinking, direct them here!
Tool #1 - Combining things with Monoids - 13:12 Effects - 27:04 Tool #2 - Moving functions between worlds with "map" - 32:50 Tool #3 - Moving values between worlds with "return" - 37:15 Tool #4 - Chaining world-crossing functions with "bind" - 38:12 Tool #5 - Combining effects in parallel with applicatives - 54:28 Example - Using all the tools together - 59:45
I always really enjoy Scotts presentations. He's had a great blend of theoretical and practical knowledge that really make some of the more abstract parts of functional programming accessible to mere mortals. I enjoy watching others like Briam Beckman too, but his genius often takes for granted his audience, and I have to pause the video to look up term from category theory that he assumes you're initmately aware of.
Well, thank you Scott - now I just can't use Go anymore. I knew it's error handling is ugly but knowing how elegant the solution can be is even more painful.
My sentiments exactly. I started porting a complex C# app to Go in the hope of achieving greater simplicity and ran into a wall. Go seems designed to enable inexpensive drones in cubicles to churn out out basic but ugly code. I found myself increasing hating everything I was writing - it worked, but it was hideous. Then I found F# and haven't looked back. Porting my C# to F# - it's shorter, cleaner, more elegant, easier to test and easier to change. I'm not saying that you can't write good code in C# or Go - but the language is fighting you rather than helping you. F# almost forces you to write good code. Developing has become fun again.
There seems to be a mistake in the monoids section: A composition of two functions cannot be a monoid, even if they return the same type. Example: a function "inc" that increments its parameter by 1, and a function "sqr" that returns the square of its parameter. "inc >> sqr" is not the same as "sqr >> inc".
What you're describing is commutativity, not associativity. The latter would require the function inc >> (sqr >> double) to be the same as the function (inc >> sqr) >> double. The order of application is the same, but the order of composition can vary.
I loved this video but so disappointed that you didn't spend more time on applicatives. It's a concept I don't understand and you made me more interested in it but I still don't really understand how to use it lol
I watched it again and want to like it again, but I can't! Nr of likes might be monoids cause they are reducible, they turn out not to be repeatable 😣 Isn't there a functional pattern to make it repeatable too? 😁
Can we think of map/lift as wrapping a type in another type? Since plain map takes a function f, and say a list [1,2,3], then map(f, [1,2,3]) returns [f(1), f(2), f(3)]. If types are functions in pure FP, then the result looks to me like a list of a new type. I'm excited if this is true, because that'd be the first cogent sentence about FP I've written :)
I always noticed how non-FP languages seems bad at FP. Now I know how to explain it: all of non-FP languages brings some form of "lambda syntax" to pass functions as parameters, but they couldn't bring the whole "FP toolbox" as elegantly as a truly-FP language.
Yeah! When JS started to have arrow functions and flatMap I thought wow isn't that pinnacle FP, but no, Js doesn't have a Maybe type, If you create a maybe type on your own then you need to implement the Functor, Monad and Applicative classes too. You'll also need a Either, and implement the classes on Either, etc. Simply put it's missing the entire GHC.Base lol
I didn't understand everything completely, but this seems like the best introduction to functional programming concepts for object-oriented programmers that I've seen yet. Scott starts by noting that outsiders often ask, "why do functional programmers use so many strange words," like monoid, functor, monad, etc. That's definitely a concern I had, and he does a good job explaining those terms, and even to justify their widespread use by saying that they're just jargon, which practitioners of every discipline use to save time, and that the main reason people don't like functional programming jargon is that it's simply not the jargon that they're familiar with. However, one of the things he doesn't explain, but which seems even more confusing to me personally, is why functional programmers use so many strange, unpronounceable, and unsearchable symbols. That seems far less justifiable to me.
Once you get used to the symbols, they become intuitive and readable. Mathematicians do exactly the same thing, for the same reasons. Which is easier to grok: Add two hundred and twenty two to one hundred and fourteen. Then divide the result by one hundred and thirty six. Then multiply the result by three hundred and two. ((222 + 114) / 136) * 302 In functional pseudocode this might look like: add 222 114 |> divide 136 |> multiply 302 which is even easier to read. In another talk, Scott cites a quote which basically says that it's a major error to design a language that's easy to read for the first half-hour and more difficult to read ever after. You simply have to trust that the notation makes sense and get over the initial discomfort. Languages like OCaml and F# and Haskell are designed by people who are a lot smarter than us, and we simply have to trust their judgement till we master the basics and build some fluency.
Because they want you to think that they are more intelligent than you. Every bullshitter in the world does that all the time. Just ask your local priest about the meaning of "doxology". ;-)
@@lepidoptera9337 Have you ever actually used an ML-style language? The notation takes about a day to learn. It cuts out substantial amounts of boilerplate and makes the intent of the code much easier to grok. Personally, I find I can churn out reliable and readable code significantly more quickly in F# vs C#. This is a pretty typical reaction from people who make the switch. The idea that functional languages are only for mathematical programming is a myth. I'd recommend you read Scott Wlaschin's Domain Modelling Made Functional - one of the best programming books I've read in decades of coding. He shows how an ML-style language can create robust, concise and maintainable line-of-business code.
@@tullochgorum6323 If you have boilerplate in your code, then you are doing something wrong, already. Your boss doesn't pay you to write software systems that need a lot of boilerplate. He pays you to get the damn software finished. :-) I can also churn out a lot of code very quickly in Python. But when I need something that has 100% uptime and zero bugs, then I use C. C does exactly what you ask it to do. Every bug is on YOU. I guess you just can't stomach that kind of responsibility. ;-)
OMG, just how much bullshit is he talking here? A member function of a class can't be used on its own??? He must be the only person on Earth who thinks that. That's like saying "a function of a library can't be used without using absolutely everything else in that library". Does he even know how his linker works? I think not. ;-)
Be humble even in the web space. Everybody knows a member function of a class thing. But that's not general high level approach of OO world. Possibility is different from Generality anyway. I think it's better to learn the skill to extract good and something useful from giants not to boast contextless snippets of exceptions.
In my opinion this is the most important talk about Functional Programming
It doesn't seem to contain any less bullshit than any other talk on FP. ;-)
I've been dipping my toe into FP for decades, but most of the teaching material is opaque for anyone who isn't mathematically literate. Scott is the first FP teacher I've found who can explain the value of FP for regular line-of-business type work.
This talk is pure gold - along with his website and his outstanding book on functional DDD.
If anyone is struggling to understand the essence of functional thinking, direct them here!
The essence of FP thinking seems to be mostly bullshit. ;-)
Scott Wlaschin is the best. Excellent ability to simplify complex ideas. His blog is one of the best resources on learning proper programming; i.e. FP
Tool #1 - Combining things with Monoids - 13:12
Effects - 27:04
Tool #2 - Moving functions between worlds with "map" - 32:50
Tool #3 - Moving values between worlds with "return" - 37:15
Tool #4 - Chaining world-crossing functions with "bind" - 38:12
Tool #5 - Combining effects in parallel with applicatives - 54:28
Example - Using all the tools together - 59:45
Good Human
Scott Wlaschin is so awesome! He made me a better software developer.
this lecture should have more views
One of the best video I have seen on FP, truly a gem
I always enjoy a speaker who distinguishes "unfamiliar" from "complicated".
Great talk 👍
You’re handling well almost every topic of FP only in an hour
Impressive 👏👏
This is so awesome! I’ve been working on learning FP for a couple months now and this cleared a lot of things up.
I always really enjoy Scotts presentations. He's had a great blend of theoretical and practical knowledge that really make some of the more abstract parts of functional programming accessible to mere mortals.
I enjoy watching others like Briam Beckman too, but his genius often takes for granted his audience, and I have to pause the video to look up term from category theory that he assumes you're initmately aware of.
The best talk about FP. It really turns my head around.
A timeless talk!
Well, thank you Scott - now I just can't use Go anymore. I knew it's error handling is ugly but knowing how elegant the solution can be is even more painful.
I really find Go very bad, rust is far better
My sentiments exactly. I started porting a complex C# app to Go in the hope of achieving greater simplicity and ran into a wall.
Go seems designed to enable inexpensive drones in cubicles to churn out out basic but ugly code. I found myself increasing hating everything I was writing - it worked, but it was hideous.
Then I found F# and haven't looked back. Porting my C# to F# - it's shorter, cleaner, more elegant, easier to test and easier to change.
I'm not saying that you can't write good code in C# or Go - but the language is fighting you rather than helping you. F# almost forces you to write good code.
Developing has become fun again.
I rarely thumb up videos on TH-cam. But for this talk I have to.
I would like to suggest everyone to learn LISP or even better Clojure. FP concepts are much easier to understand in LISP.
Very nice talk thank you!
turn up the volume...
What does a "points function" mean? Scott is using that term several times along the talk, especially in 53:48 when he presents Kleisli.
Beautiful explanation!
Wonderful! Thanks Scott.
There seems to be a mistake in the monoids section:
A composition of two functions cannot be a monoid, even if they return the same type.
Example: a function "inc" that increments its parameter by 1, and a function "sqr" that returns the square of its parameter.
"inc >> sqr" is not the same as "sqr >> inc".
What you're describing is commutativity, not associativity. The latter would require the function inc >> (sqr >> double) to be the same as the function (inc >> sqr) >> double. The order of application is the same, but the order of composition can vary.
@@AntonBurger Thank you, this makes sense to me now.
I loved this video but so disappointed that you didn't spend more time on applicatives. It's a concept I don't understand and you made me more interested in it but I still don't really understand how to use it lol
I watched it again and want to like it again, but I can't!
Nr of likes might be monoids cause they are reducible, they turn out not to be repeatable 😣
Isn't there a functional pattern to make it repeatable too? 😁
Can we think of map/lift as wrapping a type in another type? Since plain map takes a function f, and say a list [1,2,3], then map(f, [1,2,3]) returns [f(1), f(2), f(3)]. If types are functions in pure FP, then the result looks to me like a list of a new type.
I'm excited if this is true, because that'd be the first cogent sentence about FP I've written :)
it's been a year but yes that is true! a map is what is called a "Higher-kinded type".
1:02:52 final code
Love your talk
The best 1hour spent in FP
Exactly my thoughts at the 50 minute mark
I always noticed how non-FP languages seems bad at FP. Now I know how to explain it: all of non-FP languages brings some form of "lambda syntax" to pass functions as parameters, but they couldn't bring the whole "FP toolbox" as elegantly as a truly-FP language.
Yeah! When JS started to have arrow functions and flatMap I thought wow isn't that pinnacle FP, but no, Js doesn't have a Maybe type, If you create a maybe type on your own then you need to implement the Functor, Monad and Applicative classes too. You'll also need a Either, and implement the classes on Either, etc. Simply put it's missing the entire GHC.Base lol
You can do absolutely everything in every Turing-complete language. :-)
The coughing in public is so 2019!!!
listening a talk with someone in the audience coughing a lot, in 2021.
Right? not sure why that guy didnt just step out... LOL
Still listening in 2022!
@@pepineros4681 the video is just over an hour long… how long is it going to take you to finish it?
I love the content, but the coughing is seriously driving me crazy.
I didn't understand everything completely, but this seems like the best introduction to functional programming concepts for object-oriented programmers that I've seen yet.
Scott starts by noting that outsiders often ask, "why do functional programmers use so many strange words," like monoid, functor, monad, etc. That's definitely a concern I had, and he does a good job explaining those terms, and even to justify their widespread use by saying that they're just jargon, which practitioners of every discipline use to save time, and that the main reason people don't like functional programming jargon is that it's simply not the jargon that they're familiar with.
However, one of the things he doesn't explain, but which seems even more confusing to me personally, is why functional programmers use so many strange, unpronounceable, and unsearchable symbols. That seems far less justifiable to me.
Once you get used to the symbols, they become intuitive and readable. Mathematicians do exactly the same thing, for the same reasons.
Which is easier to grok:
Add two hundred and twenty two to one hundred and fourteen. Then divide the result by one hundred and thirty six. Then multiply the result by three hundred and two.
((222 + 114) / 136) * 302
In functional pseudocode this might look like:
add 222 114 |> divide 136 |> multiply 302
which is even easier to read.
In another talk, Scott cites a quote which basically says that it's a major error to design a language that's easy to read for the first half-hour and more difficult to read ever after.
You simply have to trust that the notation makes sense and get over the initial discomfort. Languages like OCaml and F# and Haskell are designed by people who are a lot smarter than us, and we simply have to trust their judgement till we master the basics and build some fluency.
Because they want you to think that they are more intelligent than you. Every bullshitter in the world does that all the time. Just ask your local priest about the meaning of "doxology". ;-)
@@tullochgorum6323 Your boss doesn't pay you to be a mathematician-wannabe. He pays you to get the damn software finished. ;-)
@@lepidoptera9337 Have you ever actually used an ML-style language?
The notation takes about a day to learn. It cuts out substantial amounts of boilerplate and makes the intent of the code much easier to grok.
Personally, I find I can churn out reliable and readable code significantly more quickly in F# vs C#. This is a pretty typical reaction from people who make the switch.
The idea that functional languages are only for mathematical programming is a myth. I'd recommend you read Scott Wlaschin's Domain Modelling Made Functional - one of the best programming books I've read in decades of coding.
He shows how an ML-style language can create robust, concise and maintainable line-of-business code.
@@tullochgorum6323 If you have boilerplate in your code, then you are doing something wrong, already. Your boss doesn't pay you to write software systems that need a lot of boilerplate. He pays you to get the damn software finished. :-)
I can also churn out a lot of code very quickly in Python. But when I need something that has 100% uptime and zero bugs, then I use C. C does exactly what you ask it to do. Every bug is on YOU. I guess you just can't stomach that kind of responsibility. ;-)
"Chainable". This guy just explained monads with a single word.
How does that differ from an ordinary function, except that you just gave it a fancy new name. ;-)
Volume is a problem
Yeah and its relation to surface area is baffling.
Is this guy seriously going to be coughing constantly the entire talk!? It’s driving me insane!
I'm going to have to stop watching if this keeps up. it's too much
OMG, just how much bullshit is he talking here? A member function of a class can't be used on its own??? He must be the only person on Earth who thinks that. That's like saying "a function of a library can't be used without using absolutely everything else in that library". Does he even know how his linker works? I think not. ;-)
Be humble even in the web space. Everybody knows a member function of a class thing. But that's not general high level approach of OO world. Possibility is different from Generality anyway. I think it's better to learn the skill to extract good and something useful from giants not to boast contextless snippets of exceptions.
@@soonshin-sam-kwon I don't see giants here, only dwarves and trolls. :-)
Beautiful explanation!