6 ms·

Some complaints about this list: 1. This list is very Haskell-focused: it includes lots of features which only make sense in Haskell or very Haskell-like langu

Some complaints about this list: 1. This list is very 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'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't reflect that. 2. Some of the 'skill hierarchy' choices feel a bit confused and arbitrary. For example, 'Use lenses & prisms to manipulate data' appears as a Competent skill, but 'Use optics to manipulate state' appears as a Proficient skill, despite being slightly different ways to refer to an effectively identical skill. (I assume the latter means "…use lenses & prisms to manipulate data, but in a state monad," which is only a tiny difference.) 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 obligatory skills. It calls itself a "standard" hierarchy (which makes it sound like a consensus, rather than just a single person/group's opinion) and has language like "…skills that developers must master on their journey…" (emphasis mine), but the list includes a lot of things that are far 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 definitely be a functional programming expert without ever having seen a comonad. In many ways, I wish this list took a cue from Benjamin Pierce's Types and Programming Languages which features not an ordered list but a graph 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's papers just to be "competent" in functional programming.

tel 10y ago
> not an ordered list but a graph of the concepts I like this idea a lot
- sitkack 10y ago
  I feel like this should be part of dbpedia.
brianberns 10y ago
> This list is very Haskell-focused I agree. My preferred language (F#) doesn't even support many of the listed concepts beyond "Advanced Beginner".
- premium-concern 10y ago
  That says more about your preferred language than the listed concepts. A language limited to a level of advanced beginners is not necessarily bad, though.
  - chriswarbo 10y ago
    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!
bjz_ 10y ago
> In many ways, I wish this list took a cue from Benjamin Pierce's Types and Programming Languages which features not an ordered list but a graph of the concepts related in the book His dependency graph for Software Foundations is even cooler, and clickable! http://www.cis.upenn.edu/~bcpierce/sf/current/deps.html http://www.cis.upenn.edu/~bcpierce/sf/current/deps.html
jarcane 10y ago
This is ... much more politely and detailedly stated than I managed on Twitter. I work in FP, programming Clojure for real-world web applications every single day, and 90% of this list is completely meaningless to me. It's nothing less than more of the Haskellite strain of "everything must be hideously complicated type theory or it's not 'real' FP." And that shit can fuck right off. It's incredibly hostile and disrespectful both to new programmers and existing ones. It's even harmful to Haskell itself as a language, because this persistent attitude that you have to learn advanced type theory just to get anything done in Haskell is one of the biggest barriers to adoption and learning of the language, especially when even most of the material supposedly for "beginners" insists on thrusting this attitude on the reader. Once again, just as they did by platforming an open fascist, LC demonstrates a complete cluelessness both of the community it claims to represent, and of the impact their "representation" has on said community.
- pron 10y ago
  I think that Haskell's takeover of the term "functional programming" in certain circles/contexts is both inevitable and nothing you should care about (I, too, program in Clojure, an imperative-functional language, and I don't mind it not being perceived as "true FP"). See this relevant discussion: https://www.reddit.com/r/programming/comments/59hubc/happiness_is_a_boring_stack/d99rzsm/ https://www.reddit.com/r/programming/comments/59hubc/happine...
- Veen 10y ago
  Was with you all the way to the end, where you chose to insert a bit of entirely irrelevant politicking.
- pka 10y ago
  The fact that it's meaningless to you doesn't mean it doesn't have any meaning :) Your "hideously complicated type theory" is many peoples' "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. Many of the concepts make sense when having an explicit type system, so if you want types you may want to learn them. Others I suspect you are already using, even if you don't know them by name. Have you ever used streams? Congratulations, this is what codata is.
deleted 10y ago
[deleted]

tel 10y ago

> not an ordered list but a graph of the concepts I like this idea a lot

sitkack 10y ago
I feel like this should be part of dbpedia.

brianberns 10y ago

> This list is very Haskell-focused I agree. My preferred language (F#) doesn't even support many of the listed concepts beyond "Advanced Beginner".

premium-concern 10y ago
That says more about your preferred language than the listed concepts. A language limited to a level of advanced beginners is not necessarily bad, though.
- chriswarbo 10y ago
  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!

bjz_ 10y ago

> In many ways, I wish this list took a cue from Benjamin Pierce's Types and Programming Languages which features not an ordered list but a graph of the concepts related in the book His dependency graph for Software Foundations is even cooler, and clickable! http://www.cis.upenn.edu/~bcpierce/sf/current/deps.html http://www.cis.upenn.edu/~bcpierce/sf/current/deps.html

jarcane 10y ago

This is ... much more politely and detailedly stated than I managed on Twitter. I work in FP, programming Clojure for real-world web applications every single day, and 90% of this list is completely meaningless to me. It's nothing less than more of the Haskellite strain of "everything must be hideously complicated type theory or it's not 'real' FP." And that shit can fuck right off. It's incredibly hostile and disrespectful both to new programmers and existing ones. It's even harmful to Haskell itself as a language, because this persistent attitude that you have to learn advanced type theory just to get anything done in Haskell is one of the biggest barriers to adoption and learning of the language, especially when even most of the material supposedly for "beginners" insists on thrusting this attitude on the reader. Once again, just as they did by platforming an open fascist, LC demonstrates a complete cluelessness both of the community it claims to represent, and of the impact their "representation" has on said community.

pron 10y ago
I think that Haskell's takeover of the term "functional programming" in certain circles/contexts is both inevitable and nothing you should care about (I, too, program in Clojure, an imperative-functional language, and I don't mind it not being perceived as "true FP"). See this relevant discussion: https://www.reddit.com/r/programming/comments/59hubc/happiness_is_a_boring_stack/d99rzsm/ https://www.reddit.com/r/programming/comments/59hubc/happine...
Veen 10y ago
Was with you all the way to the end, where you chose to insert a bit of entirely irrelevant politicking.
pka 10y ago
The fact that it's meaningless to you doesn't mean it doesn't have any meaning :) Your "hideously complicated type theory" is many peoples' "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. Many of the concepts make sense when having an explicit type system, so if you want types you may want to learn them. Others I suspect you are already using, even if you don't know them by name. Have you ever used streams? Congratulations, this is what codata is.

deleted 10y ago

[deleted]