Standardized Ladder of Functional Programming [pdf]
Some complaints about this list:<p>1. This list is <i>very</i> Haskell-focused: it includes lots of features which only make sense in Haskell or very Haskell-like languages, and lacks mention of many interesting functional programming concepts which don&#x27;t appear in Haskell (like ML-style  modules and functors, row types, macro systems and homoiconicity, and so forth.) There are a lot of functional languages which have very different ideas about how to program, and this list doesn&#x27;t reflect that.<p>2. Some of the &#x27;skill hierarchy&#x27; choices feel a bit confused and arbitrary. For example, &#x27;Use lenses &amp; prisms to manipulate data&#x27; appears as a <i>Competent</i> skill, but &#x27;Use optics to manipulate state&#x27; appears as a <i>Proficient</i> skill, despite being slightly different ways to refer to an effectively identical skill. (I assume the latter means &quot;…use lenses &amp; prisms to manipulate data, but in a state monad,&quot; which is only a tiny difference.)<p>3. While I like the idea of a list of a road-map to learning, I feel like this gives the unfortunate impression that many of these are <i>obligatory</i> skills. It calls itself a &quot;standard&quot; hierarchy (which makes it sound like a consensus, rather than just a single person&#x2F;group&#x27;s opinion) and has language like &quot;…skills that developers <i>must</i> master on their journey…&quot; (emphasis mine), but the list includes a lot of things that are <i>far</i> from necessary for deeply understanding functional programming. You could lead a long (academic or industry) career in functional programming without a deep understanding of many concepts listed: things like comonads, recursion schemes, finally tagless interpreters, higher-order abstract syntax, and so forth. All of them are useful concepts and deserve study, but you can <i>definitely</i> be a functional programming expert without ever having seen a comonad.<p>In many ways, I wish this list took a cue from Benjamin Pierce&#x27;s <i>Types and Programming Languages</i> which features not an ordered list but a <i>graph</i> of the concepts related in the book, and how they relate to other concepts. It would be more complicated, true, but also a lot more honest about the academic and intellectual path you might want to take through functional programming, and without giving the idea that you need to master the vagaries of dozens of Oleg Kiselyov&#x27;s papers just to be &quot;competent&quot; in functional programming.