I agree with others that there's far too much Hasochism in this list. I do think of FP as being like a ladder or spectrum, but rather than progressing towards s

I agree with others that there's far too much Hasochism in this list. I do think of FP as being like a ladder or spectrum, but rather than progressing towards some elitist niche, I see it as more empowering and anti elitist. In my opinion, if you refactor a Java class to change a setter into something which returns an altered copy, you've just made your code a little bit 'more functional'; if you use a list comprehension in Python instead of a for-loop, you're code's become 'more functional'; and so on. The nice thing is that many of these small changes are also good practices to be following regardless of whether you want to be 'functional' or not. Regarding the 'advanced' concepts, I'd say they exist mostly for library/DSL authors who don't want their users to have to care about those concepts. Using libraries based on these ideas is great, as the author may have chosen these techniques in order to give the library correctness guarantees, or efficient resource usage, or good error messages, etc. Using these ideas to write a library can, occasionally, provide a solution to an otherwise tricky situation, e.g. if you need to maintain state, whilst offering the users a pure interface. Using these ideas to write a library for your own usage changes the cost/benefit calculation considerably, since you're not limited to providing an API: if you want efficient resource usage, can you achieve that by keeping resources in mind when writing the application code? If so, you probably don't need to over-engineer one particular component to enforce this for you. And so on. Another thing I'd change about this ordering is to put dependent types much earlier, e.g. at "advanced beginner". Dependent type systems are very simple; they're just a slightly more complex version of lambda calculus. Sure you can use dependent types in complicated ways, just as you can write complicated lambda functions. They're certainly easier to grasp, and strictly more powerful, than Haskell's complicated mess of monomorphism restrictions, singletons, kinds, type families, etc.