I had no idea these patterns existed. My knowledge capped out around the result returning function. The interpreter pattern blew my mind and reminded my of Clojure's philosophy of "its just data!".
Also, as a consequence, so easy to grasp AND to retain. Many teacher don’t reach either levels, a few manage to make themselves understood rather well but pertaining to Mastery is that the students will be able to additionally to having understood also to retrieve the connections made from their memory some days later. Hope this makes sense!
6:16: Is a black-box always a bad thing though? You only need to read the API the class gives you and then can use it. 11:04: You could argue that the tOOtle is also easy to reason about if you only care about reading the API it exports - Turtle(initialState), move(where), penUp(), penDown(), is pretty easy to understand. The point about the functional turtle being easy to test because you can just set the state upon construction so that it's in a particular corner also applies to the tOOtle, also just set the initial state via the constructor. You can also emulate the composition/piping shown at 11:00 by returning a reference to the turtle in each of its calls. That way you can Turtle(initialState).move(50).turn(20).move(50)... and so on. The only difference is the state is only known to the turtle, which is actually a benefit, considering he lists the state having to be managed by the client as a disadvantage of the functional turtle. Don't get me wrong, I think the functional turtle is really nice (it is particularly better when it comes to passing in dependencies), but I think the tOOtle was trashed a little too harshly, I don't think it being familiar is the only benefit is has.
@50:20 - I have a "Disadvantage" for #11 - "FP style dependency injection" (currying) approach: Let's say I have a Data module that contains all the functions needed to query and update my data store. Each one of these functions requires a connection string at the very minimum, and probably a logger function. So if I have 25 Data functions, then I will have to manually create 25 partially applied functions in my application's composition root. Additionally, every time I create a new function in my Data module, I will have to create boiler plate code to partially apply the new functions. I hate repeating myself, so that will quickly feel like tedious work to me. I think that counts as a disadvantage of this approach. On the other hand, I could simply fall back to OOP and create a DataRepository class (instead of a module) that takes a connection string and a logger in its constructor. Then I will have eliminated all the unnecessary boiler plate code of manually partially applying each and every function. Since F# combines OOP with FP, why not take advantage of the strengths of each?
I had the same thought. Maybe the question then is - how can the boilerplate be written once and stored/shared, such that we get back the encapsulation you'd want from a OO constructor/IOC injector? Functional AOP, if you will.
As long as all of the functions in question have the same (curried) interface, you can indeed create a unified context for them which preserves their dependencies using pure FP abstractions. In Haskell and similar languages, you might use the Reader monad or the Context monad, which express the idea of a context in which multiple operations share the same dependencies in a generic way. In F#, these kinds of computation contexts are provided by "builders", which allow you to build "computation expressions". More info here: fsharpforfunandprofit.com/series/computation-expressions.html
i had a lot of trouble with it, too. gladly, he doesn't clear his throat in the other talk he gives. i wonder (honest question) how possible it would be for some computer program to identify all the frames where he clears his throat (and mute the audio there)? i know nothing about sound, so i don't know if this is an easy problem or difficult problem.
@@silpheedTandy Thats interesting. Id say it wouldn't be very difficullt using even traditional algorithms [fourier transform?] considering that the amplitute of the cough is so much higher than his regular talking voice. You could probably use machine learning techniques to do it also.
I had no idea these patterns existed. My knowledge capped out around the result returning function.
The interpreter pattern blew my mind and reminded my of Clojure's philosophy of "its just data!".
1. Object Oriented Turtle 2:22
2. Abstract Data Turtle 6:58
3. Functional Turtle 8:31
4. State Monad 11:51
5. Error Handling 16:47
5½. Async Turtle 21:42
6. Batch Commands 24:24
7. Actor Model 29:02
8. Event Sourcing 31:25
9. Stream Processing 37:35
10. OO Style Dependency Injection 44:07
11. FP Style Dependency Injection 46:26
12. Interpreter 50:31
13. Capabilities 58:58
Christian Ray Leovido Thank you!
Are you the best thing since sliced bread
This is such an enlightening talk format. Giving solutions rather than scoped problems is a great way to teach! Love this talk!
Fantastic as always, I learn so much in such a short space of time but it's effortless. Clear and concise.
Also, as a consequence, so easy to grasp AND to retain. Many teacher don’t reach either levels, a few manage to make themselves understood rather well but pertaining to Mastery is that the students will be able to additionally to having understood also to retrieve the connections made from their memory some days later. Hope this makes sense!
the signature coughing boi in audience of every functional programming video on youtube is indeed present 😂
Scott, thank you so much, such a pleasure watching this. So much useful knowledge in this talk.
Superb talk! I always enjoy Scott's talks :)
6:16: Is a black-box always a bad thing though? You only need to read the API the class gives you and then can use it.
11:04: You could argue that the tOOtle is also easy to reason about if you only care about reading the API it exports - Turtle(initialState), move(where), penUp(), penDown(), is pretty easy to understand. The point about the functional turtle being easy to test because you can just set the state upon construction so that it's in a particular corner also applies to the tOOtle, also just set the initial state via the constructor. You can also emulate the composition/piping shown at 11:00 by returning a reference to the turtle in each of its calls. That way you can Turtle(initialState).move(50).turn(20).move(50)... and so on. The only difference is the state is only known to the turtle, which is actually a benefit, considering he lists the state having to be managed by the client as a disadvantage of the functional turtle. Don't get me wrong, I think the functional turtle is really nice (it is particularly better when it comes to passing in dependencies), but I think the tOOtle was trashed a little too harshly, I don't think it being familiar is the only benefit is has.
An absolutely wonderful talk! Such an eye opener for me
Brilliant talk - thank you very much Scott Wlaschin.
30 minutes in, mind completely blown
All 13 of these can be implemented in C# equally as well as F#.
this man is simply brilliant!
Scott is the best
You had me at the turtle slide... damn cute :)
The throat clearing kept me awake
As soon as I read this - he cleared his throat. I wish you hadn't said that - now i am distracted every time he does that
It was all planned. :-D The bell was a genius move that makes the structure of the presentation very clear.
@50:20 - I have a "Disadvantage" for #11 - "FP style dependency injection" (currying) approach:
Let's say I have a Data module that contains all the functions needed to query and update my data store. Each one of these functions requires a connection string at the very minimum, and probably a logger function. So if I have 25 Data functions, then I will have to manually create 25 partially applied functions in my application's composition root.
Additionally, every time I create a new function in my Data module, I will have to create boiler plate code to partially apply the new functions. I hate repeating myself, so that will quickly feel like tedious work to me. I think that counts as a disadvantage of this approach.
On the other hand, I could simply fall back to OOP and create a DataRepository class (instead of a module) that takes a connection string and a logger in its constructor. Then I will have eliminated all the unnecessary boiler plate code of manually partially applying each and every function.
Since F# combines OOP with FP, why not take advantage of the strengths of each?
Btw, great talk! I thoroughly enjoyed it, as I have enjoyed all of your talks.
I had the same thought. Maybe the question then is - how can the boilerplate be written once and stored/shared, such that we get back the encapsulation you'd want from a OO constructor/IOC injector? Functional AOP, if you will.
As long as all of the functions in question have the same (curried) interface, you can indeed create a unified context for them which preserves their dependencies using pure FP abstractions.
In Haskell and similar languages, you might use the Reader monad or the Context monad, which express the idea of a context in which multiple operations share the same dependencies in a generic way.
In F#, these kinds of computation contexts are provided by "builders", which allow you to build "computation expressions". More info here: fsharpforfunandprofit.com/series/computation-expressions.html
Should have done it in Fortran
Couldn't watch it with that noise or cough or what ever it fkin was. I'm sure it was a great talk.
i had a lot of trouble with it, too. gladly, he doesn't clear his throat in the other talk he gives.
i wonder (honest question) how possible it would be for some computer program to identify all the frames where he clears his throat (and mute the audio there)? i know nothing about sound, so i don't know if this is an easy problem or difficult problem.
aha! i found the same talk from a different conference: vimeo.com/221105519
@@silpheedTandy Thats interesting. Id say it wouldn't be very difficullt using even traditional algorithms [fourier transform?] considering that the amplitute of the cough is so much higher than his regular talking voice. You could probably use machine learning techniques to do it also.
OO sample is wrong by design. Another fp guy who uses strawman rhetoric trick:/
enlighten us please
How do you think is the right design?