For many years now I’ve been using a mental model and intuition that has guided me well for understanding and teaching and using functors, applicatives, monads, and other related Haskell abstractions, as well as for approaching learning new ones. Sometimes when teaching Haskell I talk about this concept and assume everyone already has heard it, but I realize that it’s something universal yet easy to miss depending on how you’re learning it. So, here it is: how I understand the Functor and other related abstractions and free constructions in Haskell. The crux is this: instead of thinking about what fmap changes, ask: what does fmap keep constant? This isn’t a rigorous understanding and isn’t going to explain every aspect about every Functor, and will probably only be useful if you already know a little bit about Functors in Haskell. But it’s a nice intuition trick that has yet to majorly mislead me.

From the highly eclectic blog of Mark Dominus

The research Val programming language uses value-oriented programming. Lucian Radu Teodorescu explores this paradigm.

You might have heard people say that functional programming is more academic, and real engineering is done in imperative style. I’m going to show you that real engineering is functional, and …

In this course we explain how category theory—a branch of mathematics known for its ability to organize the key abstractions that structure much of the mathematical universe—has become useful for writing elegant and maintainable code. In particular, we'll use examples from the Haskell programming language to motivate category-theoretic constructs, and then explain these constructs from a more abstract and inclusive viewpoint. Hands-on programming exercises will be used to demonstrate categorical ideas like 'the universal property of products' in working Haskell code.

A space to discuss and keep up software development and manage your software career

If you start learning about functional programming, it won’t be long before you come across the idea of pure functions. And as you go on, you will discover functional programmers appear to be obsessed with them. “Pure functions let you reason about your code,” they say. “Pure functions are less likely to start a thermonuclear war.” “Pure functions giveyou referential transparency”. On and on it goes. And they have a point. Pure functions are a good thing. But what do you do with the impure bits of your code?

My six-year-old son walked up to me yesterday. “What are you reading?” At the time, I was reading part of Janis Voigtländer’s habilitation thesis. Unsure where to even start, I decided to just ans…

Danish software design

Many functional programming articles teach abstract functional techniques. That is, composition, pipelining, higher order functions. This one is different. I...

Functors, Applicatives, and Monads in Plain English - This is a no-bullshit zone

Practical Functional Programming in PHP

A PHP library with commonly used code blocks

Mostly adequate guide to FP (in javascript)

Immutable collections, with filter, map, join, sort, slice, and other methods. Well-suited for functional programming and memory-intensive applications. Runs especially fast in PHP7. - jkoudys/immu...

Functors, Applicative Functors and Monads in PHP

Ivan Cukic - Monads in ChainsMeeting C++ 2014Slides: http://meetingcpp.com/index.php/tv14/items/22.html

Before we get into this, allow me to introduce myself — you’re probably going to wonder who I think I am before this is over. I’m Eric Elliott, author of “Programming JavaScript Applications”…

Update: It's nearly five years since this post was written. Although much of the code will still work, some parts are now broken. (At the moment, you'd have to replace partition with groupBy and replace use(...).over(...) with useWith(..., [...]).) . I'm not going to try to keep updating this code since there are plenty of places online now to learn the basics of Ramda. This post still reflects much of the rationale for Ramda, and much of the code is still all right, but caveat emptor. ---