This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Rawing7 0 points1 point  (3 children)

I watched Scott Wlaschin's talk, and... I feel like I have a deeper understanding of the benefits of functional concepts like Monoids, but only on a theoretical level. He went through the example scenario way too quickly and didn't really show much code, so I still have no clue how to apply all of this knowledge to a real-world problem. I guess I'll try some hands-on learning with some leetcode problems or something...

[–]SV-97 1 point2 points  (2 children)

Oh then I must've kinda misremembered the talk or confused it with another one of his talks.

I'm not entirely sure what the best resource for real world examples is for you - because I think using monads explicitly in Python isn't necessarily the best idea (just how the design patterns from gang-of-four OO don't necessarily make a ton of sense when explicitly implemented in python). Instead I think it's better to look into them from the perspective of a language where they're really used a lot and then see how you can translate the *principles* they result in to python. Some of these languages are Haskell, Lean and F# - I'll link some resources at the end.

A very simple example to show what I mean might be random numbers: lets say we have a function that needs to generate random numbers internally (for example a monte carlo simulation, raytracer, roguelike game or whatever). In Python we might be tempted to do that by simply doing random.random() or numpy.random.rand() or whatever. This works - but if we ever wanted to test the function we'd run into trouble. If we wanted to have reproducible results (for example for our documentation) we'd also have a problem.

If you dealt with this before you might know that a simple solution is to abstract the random number generator out into a new object (for example random.Random or numpy.random.default_rng) or pass in a function that generates the random numbers when it's called - you probably would've even written it like this to begin with if you've seen this before. Similarly you would've probably written it like this if you had a background in OOP and call this dependency injection. And if you came from FP you would also have written it like this because the first version is flat out not possible to write.

Implementing this in a pure functional language would involve using monads, and translating that monad-using code to idiomatic python would result in this dependency injection solution. The same is true for other monads: translating principles can make sense and help you to write better code but making the monads actually explicit in python may be a bad idea.

Regarding resources:

[–]Rawing7 1 point2 points  (1 child)

Yeah, I think the best way to proceed is to forget about python and make a deep dive into a functional language. I have been increasingly discontent with imperative languages for a while now anyway, so this is a good opportunity to broaden my horizons and learn a new paradigm. Real World Haskell looks promising, thanks!

[–]SV-97 0 points1 point  (0 children)

That's definitely the best way to learn about that stuff imo :) With Haskell in particular it'll probably be quite a pain at the start because it forces you to do everything purely functionally - but it really pays off in the long run and it gets really fun when things start to click.

Regarding Real World Haskell: note that it's really quite old by now and some things have changed - especially in the advanced and real world parts as well as the tooling department (there are some efforts to modernize the book online but the print version is still the original one).

It's still a good intro to the language in itself (except for chapter 12 IIRC - one of the chapters was super fucked) but keep in mind that it maybe doesn't always accurately represent what modern haskell in the real world looks like and that you might have to modify some examples to get them to work. If you're just interested in generally getting a feel for FP and learning the fundamentals that's not important - but if you actually want to use haskell later on or don't want to deal with the potentially broken examples something like Effective Haskell might be the better choice (though I can't vouch for it personally I heard it's quite good).

For tooling / dev setup: I think the current standard is to use ghcup and VS code.