Standardized Ladder of Functional Programming [pdf]

I disagree. This list contains lots of "Haskellisms" like monad transformers and lenses, which are effectively design patterns which have emerged over time as powerful ways to work within and around the idiosyncracies of Haskell.

We could argue all day about whether different 'families' of FP languages, like MLs, Lisps, Joys, etc. are more or less "advanced", so let's avoid any ambiguity and stick to the Haskell family of languages. Let's pick a language which is strictly more advanced and powerful than Haskell, such as Agda or Idris: not only can we implement all of the Haskell concepts in these languages (especially Idris, since we can toggle totality checking, rather than having to work around it), but the inclusion of dependent types lets us implement many more powerful patterns, and even simplifies many of the Haskell patterns (e.g. there's no need for hacks like singletons, normal functions can be used instead of type families, etc.).

So, given this vast landscape of new possibilities, which of the many 'design pattern' concepts have been chosen from these ultra-advanced, super-powerful languages?

> Dependent-Types, Singleton Types

That's it! Apparently the only new concept in these languages is the fact that dependent types exist; but even that's been constrained to a Haskell context, by lumping it in with singletons!

There's no mention of proof objects (de Bruijn criterion, etc.), computational content, erasure or proof irrelevance. No mention of tactic languages. They do give kinds and rank-n types, but they don't mention cumulative universes! No HoTT concepts are mentioned, like types-as-spaces, identity-as-paths or univalence. There's not even a mention of intensionality vs extensionality!

So what about skills? Surely there'd be specifics like modelling divergence co-inductively via Partial/Delay? Maybe propagating invariants with initial algebras, even if it's just a Vector example? What about something trivial, like heterogeneous equality?

> Use proof systems to formally prove properties of code.

> Use dependent-typing to prove more properties at compile time

Again, they've just listed that "these things exist", rather than giving any specifics whatsoever.

What about Haskell? Does that exist? You bet! It even has this thing called lenses; and not only do they exist, there are all sorts of nuanced proficiencies to them!

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.

> "hideously horrible paren-based syntax" - i.e. Lisp. So, how many people don't learn Lisp only because of its syntax? I'd say a lot.

But the point is that nobody's putting 'S-expression syntax languages' in a Lisp-centric list of essential functional programming skills. The idea that half this stuff is supposedly mandatory is a skewed perspective.

> Others I suspect you are already using, even if you don't know them by name.

And if the list is comprised of Haskell-centric jargon for more generic notions, that's obviously grounds for criticism.

How many LOC do you think Verizon OnCue involves? Don't know myself but I picture it as being large and they're all in on this type of stuff

Completely agree!

.... except! I really think Lenses are a concept orthogonal to Haskell. They can be implemented anywhere and usually make good sense. I think we have a long way to go before we've come to understand their best place in functional programming—especially construed as widely as you note.