Thirteen ways of looking at a Turtle - Scott Wlaschin 

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

Best tech educator IMO

the signature coughing boi in audience of every functional programming video on youtube is indeed present 😂

Fantastic as always, I learn so much in such a short space of time but it's effortless. Clear and concise.

Scott, thank you so much, such a pleasure watching this. So much useful knowledge in this talk.

This is such an enlightening talk format. Giving solutions rather than scoped problems is a great way to teach! Love this talk!

An absolutely wonderful talk! Such an eye opener for me

Brilliant talk - thank you very much Scott Wlaschin.

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.

30 minutes in, mind completely blown

this man is simply brilliant!

You had me at the turtle slide... damn cute :)

Scott is the best

All 13 of these can be implemented in C# equally as well as F#.

The throat clearing kept me awake

@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?

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.

OO sample is wrong by design. Another fp guy who uses strawman rhetoric trick:/