One great way to learn about FP is to read the documentation for Ramda.js [0] and tinker with their playground. For even more ideas check out Ramda-adjunct [1] and Fantasyland [2].
Anyway don’t put FP on a pedestal, main thing is to focus on the core principles of avoiding external mutation and making helper functions. Doesn’t always work because some languages like Rust don’t have legit support for currying (afaik in 2023 August), but in those cases you can hack it with builder methods to an extent.
Finally, if you want to understand the middle of the midwit meme, check out this wiki article and connect the free monoid to the Kleene star (0 or more copies of your pattern) and Kleene plus (1 or more copies of your pattern). Those are also in regex so it can help you remember the regex symbols. https://en.wikipedia.org/wiki/Free_monoid?wprov=sfti1
The simplest example might be {0}^* in which case we find:
“”, “0”, “00”, “000” …
a language with only one letter in the alphabet could still make all the natural numbers like that.
With Boolean alphabet (two variant enum) we have {0,1}^+ which omits the empty monoid by using the + operator:
“0”, “1”, “00”, “01”, …
note this sequence will eventually yield every possible Turing tape, which is the same thing as listing every possible series of coin flip results assuming no coins land on their side (Turing’s undecidability paradox might be bullshit, but that’s another story)
I meekly suggest, FP can save you days of headache if the only thing you do is clone your data and mutate the clone. Yes, that’s inefficient, so is dealing with infinite bugs due to state mutation in multiple places. Also, you can look into HAMTs / immutable / persistent data structures to juggle the pointers and copy-on-write on the storage data structure if you find yourself repeatedly cloning data then it would accelerate your stuff.
Rust isn’t great for letting you do FP things like other languages, but it does have the best type system imho which makes it the leading functional programming language right now imho. If you’re not using too many specialized python packages then I recommend using Rust instead, even for toy demos, as you can be more confident your code works without needing to run it and wait for a crash like you would in debugging python, and the tests also run faster in rust due to the incremental compilation. Use cargo-watch and you can retest your code every time you save your work.
I usually write a make command to cargo watch and rerun each test file : code file pair independently so then you won’t rerun your tests in other modules when you change the one you work on (faster but might miss stuff if you change API contracts which touch other parts of your codebase)
