
Standardized Ladder of Functional Programming [pdf] - panic
http://lambdaconf.us/downloads/documents/lambdaconf_slfp.pdf
======
plinkplonk
One way to process this list is to see it as an elitist construct intended to
put you down or degrade you or extract money from you for training etc.(which
might even be true, but generally it is better, ime, to assume that people are
genuinely trying to provide what they see as value)

The other is to ignore any insult, intended, perceived, or a mix of both,
ignore all the hierarchy labeling - 'beginner', 'advanced beginner', "standard
ladder" etc who tf cares? - and just see if there are skills you can pick up
or explore on your own.

That said, I laughed at 'equational reasoning' being considered an 'expert
skill'. It is _considered_ an advanced technique but imo the basics are
trivial to pick up, and I had a lecture/demo on this at a local fp conf. Sure
it can get very hard if you tackle a hard _problem_ , but that is true for
everything.

~~~
JackMorgan
I saw this pdf before all the angry comments, and was very excited to see a
list of fun topics to explore and learn. I love skill trees in Skyrim etc, and
to me this looked like a real life version! Time to level up!

~~~
nikojn
Yeah, not sure what all the fervour is about. I've found the biggest hurdle to
advancing is knowing what to study next; this helps solve that.

~~~
crystalPalace
I definitely agree that the most difficult part of learning something new
especially something as esoteric as FP is knowing where to start and then
where to go from there. I also benefited from and highly recommend functional-
programming-jargon([https://github.com/hemanth/functional-programming-
jargon](https://github.com/hemanth/functional-programming-jargon)).

------
andolanra
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.

~~~
jarcane
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.

~~~
pka
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.

~~~
AimHere
> "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.

~~~
pka
> But the point is that nobody's putting 'S-expression syntax languages' in a
> Lisp-centric list of essential functional programming skills.

They should've probably said "FP-only" (i.e. pure) languages to exclude
imperative languages that merely support functional programming constructs,
like Clojure, Erlang, etc.

I agree, many of the concepts that are useful in pure languages (i.e. monads)
are not that practical in imperative/impure or dynamic languages (at the cost
of reduced ability to reason about your program.)

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

It's the other way around - the items on this list are the more generic
concepts [0]. Less expressive languages lack the (practical) ability to reason
about those concepts generically, hence the need for more specialized
constructs, like i.e. streams, transducers, etc.

[0]
[https://en.wikipedia.org/wiki/Coinduction#Codata](https://en.wikipedia.org/wiki/Coinduction#Codata)

~~~
jarcane
_They should 've probably said "FP-only" (i.e. pure) languages to exclude
imperative languages that merely support functional programming constructs,
like Clojure, Erlang, etc._

Ahh, and there would be that definition again, the one at the root of the
problem.

Please find your nearest whiteboard and write the following 100 times or until
it sinks in: "Haskell is not the only Functional Programming language."

FFS, the languages that _invented_ functional programming are not Haskell, and
predate it by some time. Lisp dates back to 1958. Scheme first appeared in
1970. ML dates to 1973. Haskell didn't even exist until 1990.

This weird ahistorical definition of "functional programming" is both useless
and inaccurate. Strict typing and purity are not the sole measure of whether a
programming language is functional and never have been. It's only been in the
last few years that there seems to be this desperate push to define FP as
"Haskell", which as far as I can tell is the product more of a desperate kind
of evangelism than any sound argument for such a limited definition.

We get it, you like Haskell. But some of us also like Clojure, and Erlang, and
Elixir, and F#, and OCaml, etc. etc., and you don't get to just redefine terms
to cut out languages you don't like. Reality doesn't work that way.

~~~
willtim
But Haskell does stand out among your list as being a pure functional
programming language (it is not the only example of course). Whether this is a
good or bad thing, I will not get into. When programming in a pure language
you typically have to use some quite recent/advanced ideas such as monads and
lenses, just to get practical work done. This is not the case with Clojure,
F#, Scala, Erlang etc, where side-effects are idiomatic. In fact, if you tried
to go fully pure with these languages, you would run into problems with
performance.

To avoid confusion, they should have used the term "pure functional
programming" or even "typed pure functional programming".

~~~
jarcane
_To avoid confusion, they should have used the term "pure functional
programming" or even "typed pure functional programming"._

That's what was used when I started learning FP, which was maybe three or four
years ago. There was FP, and then purity was a secondary characteristic.
Haskell was pure and typed, but that didn't make other languages not FP, when
they still had all the same basic tools and the same idiomatic focus on
composition of functions over mutable state and imperative logic. No, you
didn't need a special magic word to allow you to have side-effects like I/O,
and most _also_ allowed for mutability (even Scheme had set! after all), but
they are first and foremost functional languages. In many ways, Haskell was
and still kind of is the odd one out, not counting experiemental academic
languages like Idris and Coq.

This wasn't even a controversial statement just a few years ago. But as
Haskell has been more and more in vogue, there's this weird fixation on
redefining the window of what "FP" is to only refer to, well, Haskell. And
it's very clearly what the LC list is all about, because so many of the
concepts described are both largely unique to Haskell and it's closest
relatives, and unnecessary to do practical, everyday work in a vast majority
of FP languages.

And ultimately, attitudes like that hurt the whole field. In trying to fix
Haskell's image problem by brute force, they wind up damning the larger domain
in the process.

------
alexandercrohde
I get the sense that most engineers would almost never use, and never need to
use, most things beyond advanced-beginner in this sheet. It may be fun to brag
about knowing how to use "embedded DSL with combinators," but is that really
the best thing to help your startup succeed?

I suppose I'm slightly bothered by the fetishizing of challenging knowledge
for challenge sake. Most of the people I know who learn about "Embedded DSLs
with combinators" and set theory seem to not be able to stop rubbing in how
smart they find themselves, and yet strangely they never seem to be the most
productive engineers (in terms of delivering useful and reliable code).

I know it can be a little disappointing to feel like there isn't a pot-of-gold
at the end of the rabbit-hole, but this is no different than most disciplines.
You use arithmetic daily, algebra weekly, calculus monthly, imaginary numbers
annually or less.

~~~
tikhonj
A lot of these techniques are things that take a bit more up-front effort but
pay off over the long (or even medium) term. I think that's why it might make
people _seem_ less productive—although of course a lot depends on your
perspective and experience. Measuring productivity is an open problem in
software engineering and, in my experience, people's intuitions about it are
all over the board, which means that nobody's any good at it.

DSLs are a great example of this long-term dynamic. Compared to throwing
together an ad-hoc library, a DSL approach takes a lot more design effort but,
ultimately results in a system that's more coherent, elegant and expressive.

I've worked on both kinds of projects and the difference is palpable: with the
first style, productivity is constant at best—getting things together in the
first place is a struggle, and then adding features or fixing bugs _continues_
to be a struggle. On the other hand, the second style of project is even
_more_ of a struggle at first, but once it works it's like magic: new features
are easier to add than you'd expect, and I've had way more things work _after
my first attempt_ than anyone has a right to expect.

I know which style _I_ prefer, and it's definitely not because I "fetishize
challenging knowledge for challenge sake"—it's because I'm willing to put
effort up front for a long-term reward. And it's not even _that_ long-
term—I've found these things pay off over _weeks_ or _months_ , not years, so
I'd take the same deliberate approach unless my deadlines were literally days
away.

~~~
alexandercrohde
Well, I can't speak to your career experience, but I can speak to mine.

My experience has been (31, SF) that companies are fundamentally disorganized,
frequently reinvent things (a behavior seen at all levels), are skewed by
politics, and ultimately are rarely successful due to the code. The fact is,
that for most startups it's not the code that's make-or-break (twitter,
snapchat, facebook, airbnb, uber), it's the business execution.

It's been my career experience that the only way to be a 10x engineer is to
prevent management from engaging in unnecessary projects (Bob wants to rewrite
X in node, Joe wants to make a service that only has the responsibility of
CRUD to 1 table, Sally wants to move it all to noSql). It's been my career
experience that soft skills give the best ROI.

So when I see a list like this, I find it hard to imagine how "Profunctor
Optics" is what Zynga (or any company I've worked at) needed to be successful.

~~~
runT1ME
>So when I see a list like this, I find it hard to imagine how "Profunctor
Optics" is what Zynga (or any company I've worked at) needed to be successful.

I mean, by that criteria, why learn anything?

The world is not just startups btw, I work on products that have very _very_
defined requirements. Hell, sometimes I'm implementing an RFC. FP is a huge
win for us, and yes i've used profunctor optics in a high performance network
application.

~~~
a_imho
>I mean, by that criteria, why learn anything?

This might be tongue in cheek, but I agree with the parent. Engineering
excellence will not further your career much, companies tend to oversell
meritocracy. Salaries flat out quickly, and there is a huge supply of good
enough developers, if you step out of the line too much.

~~~
runT1ME
> Salaries flat out quickly

What other professions besides lawyers or doctors regularly have a 3 or 4x
range for salaries of people more or less with the same job description?

~~~
a_imho
In addition to those? Actors, musicians, sport people. In the office?
Managers. Hence the advice, focus on soft skills. I would wager the top 1% on
the developer track earn nowhere near to the top 10% on the managerial track.
And your best bet is to regularly change jobs otherwise good luck getting
anything more than a 5-10% increase, while managerial salaries and bonuses
scale with the size of the organization. Also, there is a lot to be said about
the difficulty of the work.

------
sleexyz
Most useless thing ever created for functional programming anything.

It's not even biased towards Haskell; it's biased towards working at Slamdata,
where they abuse free monads for everything.

When you write Javascript and use first class functions (ideally without side-
effects, but who the fuck really cares), _that 's_ functional programming.

Tired of this elitism.

~~~
seanparsons
Elitism is learning more powerful constructs? There's a lot of elitism in the
construction industry then with people checking the load bearing of materials
rather than building everything from mud.

~~~
pron
Load bearing materials _actually_ carry significantly higher loads than mud;
those Haskell constructs have not even been used to build software as
intricate as common industry practice, let alone break new ground. Are they
truly more powerful? That's a popular hypothesis among those who are
aesthetically drawn to those concepts.

~~~
willtim
I gave you an example last week, which you are conveniently ignoring. We have
millions of lines of Haskell code at Standard Chartered bank. The type safety
and purity have helped us build a more reliable and maintainable codebase
compared to previous efforts. Ultimately the language is just a tool. If you
are not interested in type safety, purity or expressivity then it isn't the
tool for you.

~~~
pron
I am not ignoring anything. On the contrary: You yourself have said that the
kind of software you write isn't any bigger or more complex than similar
software written in more mainstream languages, and that you have no evidence
of significant bottom line benefit (except claim that your software is more
maintainable, but without any metrics). I never claimed that Haskell can't be
used to write simple software as well as other languages, or even marginally
better (for some definition of better). But the commenter I responded to
claimed that those advanced abstractions are analogous to building materials
that are used to build much bigger buildings than those possible without them.
You have not even made that claim.

No one is interested in type-safety or purity for their own sake (except for
aesthetic reasons). I'm interested in better, cheaper software. If Haskell's
purity (there are simpler languages with similar type systems) provides that
then there should be evidence of that before the claim is made. You have not
provided any such evidence, and even implied that you're not even carefully
collecting metrics that can be used to construct such evidence.

~~~
willtim
> I never claimed that Haskell can't be used to write simple software

I can assure you our software is not at all simple. Standard Chartered has
industry leading portfolio compression and XVA compute. Barclays has industry
leading pricing of exotic derivatives (including pricing on GPUs). Both
industry leading solutions built in Haskell on top of frameworks/APIs in
Haskell.

> No one is interested in type-safety or purity for their own sake (except for
> aesthetic reasons).

So are all forms of static verification just aesthetics to you? Or just those
offered in Haskell?

> I'm interested in better, cheaper software.

Then hire good people and let them use the tools they want.

The only evidence I could ever hope to offer is that good people build good
software. But that would never make an interesting management report.

~~~
pron
> So are all forms of static verification just aesthetics to you? Or just
> those offered in Haskell?

As someone who makes use of formal methods regularly, I am aware of how weak
Haskell's static guarantees are. That is not to say they may not be useful in
practice, but that's an empirical question, and the one that I'm desperately
waiting for answers to.

> The only evidence I could ever hope to offer is that good people build good
> software. But that would never make an interesting management report.

It also doesn't support the claims made that Haskell makes a significant
contribution.

~~~
willtim
Yes Haskell makes a significant contribution. The person responsible for our
industry leading portfolio compression joined us because we use Haskell.

~~~
pron
> Yes Haskell makes a significant contribution.

That's excellent. So please publish some numbers so we could estimate the
contribution. With so much hype and zero data I think that the skepticism is
very well justified.

> The person responsible for our industry leading portfolio compression joined
> us because we use Haskell.

I have no doubt that some people really like Haskell, but that's not data.

------
hvs
When working with functional languages (my current choice is Scala), I do feel
that they require a level of mastery that "traditional" imperative languages
do not. I also feel that if computer science/software engineering is ever
going to gain any sort of repeatability it will be through functional design.

That said, functional programming is incredibly difficult to do well without
years of practice and the languages still suffer from limitations with
performance that are hard to debug. While I still feel that functional
programming is the "future" of software engineering, I feel it is quite a ways
in the future.

~~~
stephen123
With time travel debuggers being the notable exception, where FP is enabling
much better debugging.

[http://debug.elm-lang.org/](http://debug.elm-lang.org/) as one example.

~~~
Sean1708
Maybe I'm missing something, but how is that different to something like
rr[0]?

[0]: [http://rr-project.org/](http://rr-project.org/)

~~~
dkoontz
From the rr site: Remember, you're debugging the recorded trace
deterministically; not a live, nondeterministic execution. The replayed
execution's address spaces, register contents, syscall data etc are exactly
the same in every run.

Elm's debugger (and similar projects like the Pux debugger from PureScript-
land) are live systems. They are replaying all events deterministically but
you can edit your code, reload it and then replay the exact same series of
events or toggle events on/off and see what the resulting state is. rr is
super cool and I'm very glad it exists but it's a static analysis tool where
the Elm debugger is almost REPL-like in terms of how you can play with things
and see the results live.

------
pron
Actual ladder:

1\. Writes simple programs

2\. Writes more complex programs

3\. Writes programs that are maintainable

4\. Writes programs that are maintainable by others, and communicate module
intent clearly to team members who interact with it

5\. Writes programs that are maintainable etc., and also make good use of
resources, both computational and human

The emphasis on language concepts seems so distracting that I wander how much
time people have left to make their program _externally_ better (better
functionality, better performance, more maintainable by others) rather than
_internally_ better (make use of clever abstractions). That the two are
related is a hypothesis which doesn't seem to be supported by evidence, and is
believed by those who enjoy thinking about the latter more than about the
former and want to justify their focus.

~~~
tempodox
+1.

Also, s/wander/wonder/.

------
pulisse
It says something slightly worrisome about the functional paradigm that
"profile, debug, and optimize purely functional code with minimal sacrifice"
is considered an expert-level skill.

~~~
llambda
Oh come on. Please do not troll. That says absolutely nothing about functional
programming in general and absolutely everything about the publisher. Not only
could this not be further from the truth, but it's a cheap and lazy attack on
a rigorous and proven paradigm. Give it a try. You might just surprise
yourself.

~~~
pron
> a rigorous and proven paradigm

I'll give you rigorous, but how is it proven? I think it is a fair guess that
the number of non-tiny programs (>100KLOC) making use of the "expert" concepts
and skills is ~0. The number of large programs (>1MLOC) at the proficient
level is also ~0.

~~~
seanparsons
I would surmise from what I've heard that Standard Chartered easily on their
own break this rule.

~~~
pron
What I heard is that all of their Haskell software combined is about ~1MLOC
(and they don't comprise a single system), and a huge chunk of that (a couple
100KLOCs at least) is the Haskell compiler itself, which they've modified and
consider a part of their codebase. The Haskell compiler is still the largest
Haskell program, and if it isn't, there are no more than a couple programs
that are larger.

~~~
tome
> a huge chunk of that (a couple 100KLOCs at least) is the Haskell compiler
> itself, which they've modified and consider a part of their codebase

Please don't talk about what you don't know. Standard Chartered's Haskell
compiler is written completely from scratch and is not based on any existing
compiler.

~~~
pron
Sorry, that's what I'd heard (or I may have misinterpreted "a variant of
Haskell" as "a variant of the Haskell compiler" all on my own); thank you for
correcting me. So what you're saying is that biggest Haskell program isn't
_the_ Haskell compiler, but that the _two_ biggest[1] Haskell programs are two
completely different Haskell compilers.

(Also, while it has little to do with my point, I've also heard that the
person behind SC's Haskell compiler is the one who'd written the first ever
Haskell compiler, long before he started working for SC; is that true?)

[1]: Please don't take this too literally. In the two decades that have passed
since Haskell was declared the language to end world hunger, someone may have
written a bigger program. Maybe even two.

~~~
tome
AFAIR the Mu compiler is not even the biggest program written in Haskell
inside Standard Chartered.

------
mannykannot
I am generally a pragmatic person, but some of these arguments are wandering
into a defense of ignorance. I am hoping that learning about these things will
improve my problem-solving in general, and I don't mind being labeled a
beginner.

It is also clear that there is not just one FP.

------
pyrale
Even being a Haskell enthusiast and loving playing with stuff in the list,
this does not reflect well on Lambda conf and, unfortunately, on Haskell.

The smugness and self-importance displayed in there is quite the opposite of
the virtue of code simplicity put forward by e.g. Don Stewart at HX this year.

~~~
js8
> e.g. Don Stewart at HX this year

Can you give some link? I wasn't able to google it.

~~~
dmit
[https://skillsmatter.com/skillscasts/9098-haskell-in-the-
lar...](https://skillsmatter.com/skillscasts/9098-haskell-in-the-large-the-
day-to-day-practice-of-using-haskell-to-write-large-systems)

Requires registration.

------
chriswarbo
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.

~~~
the_af
I agree with you about the gradual refactoring. I love FP and according to
that list, I'm mostly an "advanced beginner"... and I see nothing wrong with
that.

Even "just" refactoring Java or Python code to be more functional is a huge
win. Even "just" using Scala in a more or less FP way is a huge win. I don't
fret being unfamiliar with Lenses or whatnot yet.

------
lotsoflumens
"Copyright Fantasyland Institute of Learning" \- I think that says it all ...
in case you missed the big unicorn logo at the top.

~~~
qofcourse
I attended LambdaConf last year and felt it was not worth the money, to say
the very least.

------
mrwinalot
Any resources on where to go to learn these topics?

~~~
buffyoda
HaskellBook.com will teach you quite a number of them. :)

The Reddits for the different functional programming languages are a good
place to hangout (and a frequent source of blogs and videos on these topics),
and for FP in non-FP languages, there are good Github communities (e.g.
[http://github.com/fantasyland/](http://github.com/fantasyland/), no
association with FIOL).

I'd also humbly suggest that LambdaConf 2017 (May 25-27) is a great place to
learn more about functional programming. There will be a special two-day
LambdaConf workshop prior to the conference that introduces the basics of
functional programming (no background knowledge), another that is aimed at a
slightly more experience audience, and then at the subsequent conference,
plenty of workshops and sessions to learn many of these topics (and others).

It's a journey, but everyone can get there if they have the interest. Most of
the resources out there (blogs, videos, even e-books) are free, and the
remainder are low-cost if you are already working in tech.

Good luck and please just let any of us lurker functional programmers know if
you need a hand. :)

~~~
bogomipz
Is there anywhere to preview some content from HaskellBook.com ? Its a little
pricey for to just take a chance without seeing any same content. The TOC
looks good but that's not much indication of writing style.

~~~
leoc
There's a sample excerpt containing a few chapters:
[http://haskellbook.com/assets/img/sample.pdf](http://haskellbook.com/assets/img/sample.pdf)
.

------
barrystaes
In related news: How To Use Black Backgrounds To Make Sure Nobody Likes To
Print Your Document .

------
foo303
I love this list. Sure, shortcomings might be there, but trying to create a
list of actual topics and ranking them is not a bad thing. It would really
help folks at any end of the spectrum to explore new topics on their own.

------
kriro
Unicorn level: Explain what a monad is to CS101 students and have them grasp
the concept.

;P

------
hueving
s/Ladder of Functional Programming/Our Ranking of Things We like in Haskell/

~~~
toolslive
s/Functional Programming/Haskell ?

------
joostdevries
It's funny to see that singleton types are within the highest level: 'expert'.
While in Typescript they're, together with union types, the most intuïtive
thing ever. I guess that's because to express them in a language that doesn't
have native support requires advanced deftness in typelevel programming. Like
f.i. implementing them yourself in Scala 2.x. So I expect the coolness factor
of singleton types and union types to fall precipitously as soon as Scala
3.x/Dotty becomes prevalent. They'll be 'just' a powerful feature that
everybody understands and uses all the time.

~~~
sleexyz
wrong "singletons"

[http://stackoverflow.com/questions/16017294/singleton-
types-...](http://stackoverflow.com/questions/16017294/singleton-types-in-
haskell)

Singletons are a way to emulate dependent types with typeclasses, datakinds,
and GADTs

~~~
joostdevries
No it isn't [http://www.slideshare.net/yoozd/union-types-and-literal-
sing...](http://www.slideshare.net/yoozd/union-types-and-literal-singleton-
types-in-scala-and-typescript)

------
wlk
There was something similar suggested by Martin Odersky for scala few years
back: [http://www.scala-lang.org/old/node/8610](http://www.scala-
lang.org/old/node/8610)

It didn't get much traction back then.

But overall I like the idea as a roadmap for learning particular language or
skill set. I'd like to something like that but with references to material
where particular skill can be learned, etc

------
loup-vaillant
Reading this list, I was tempted to rename the hierarchy thus: Novice,
Apprentice, Journeyman, Expert, Master. Maybe I'm playing too much Skyrim…

------
Fiahil
I prefer this one : [http://www.scala-
lang.org/old/node/8610](http://www.scala-lang.org/old/node/8610)

I think it's a better idea to separate skills required to use most of the
language, and the ones required to create libraries.

------
agumonkey
speaking of functional programming language, here's a nice history of ML (from
stratchey to milner, landin et al.)

[https://www.youtube.com/watch?v=NVEgyJCTee4](https://www.youtube.com/watch?v=NVEgyJCTee4)

------
bamurphymac1
Looking forward to Chris Allen (@bitemyapp) opining on this over on lobsters.

~~~
coolsunglasses
I don't really want to though.

Here's a couple threads:
[https://twitter.com/bitemyapp/status/803720075702255616](https://twitter.com/bitemyapp/status/803720075702255616)

[https://twitter.com/jdegoes/status/803721209439514624](https://twitter.com/jdegoes/status/803721209439514624)

------
bbotond
Best way to convince someone that they will never, ever have any chance of
understanding functional programming and therefore should not even bother
trying it.

~~~
the_af
Why? Even at the level of Advanced Beginner (which is pretty concrete and
easily attainable), FP is already hugely useful. Everything at that level is
both useful and relatively easy to understand. It's going to improve your code
even if you use a language not particularly tailored for FP.

The rest is just icing on the cake, and you don't have to deal with it if you
don't find it interesting.

------
geooooooooobox
I just found the path of light, I feel truly blessed

