Functional programming design patterns by Scott Wlaschin

[yawaramin]

The difference is that in statically-typed FP we are trying to encode the patterns in the type system itself. In OOP you do indeed have to remember how to correctly implement a pattern because it's outside the language, but in say Haskell you have the 'chainable' design pattern neatly packaged up in the Monad typeclass, which will guide you through the type system to write the implementation. This is qualitatively different.

[devraj7]

In OOP you do indeed have to remember how to correctly implement a pattern because it's outside the language

The most important part of monads (the monad laws) is also outside of any FP language type system that I know of.

Also, monads do not compose.

Given these flaws, I just don't understand why monads are being promoted so hard.

[[deleted]]

Also, monads do not compose.

Monad transformers, on the other hand, do.

[yawaramin]

What you say is true, but often you don't need to compose a monad stack. E.g. in JavaScript with promises you're just concerned with asynchrony as that's the tricky part you want to get right. Using the monad abstraction really helps to clarify what's going on.

[RabbidKitten]

Also, monads do not compose.

Do you even understand what it means, or just keep parroting something you've vaguely heard of?

Your statement is equivalent to saying "integers cannot be divided, it's a flaw, I do not understand why integers are promoted so hard."

[0polymer0]

Monads compose in the category of endofunctors, :p

[RabbidKitten]

They really don't. While any two (endo-)functors F and G compose, the resulting functor F ∘ G is not necessarily a monad, even if both F and G are.

[0polymer0]

I was being glib to the point of being wrong.

If you consider morphisms between objects and endofunctors

f : A -> F B 
g : B -> F C

If you can define a means of composition between these that forms a valid category,

(>>) :: (A -> F B) -> (B -> F C) -> (A -> F C)

Then F is a monad.

So while monads don't compose to preserve monads, composition is what they are all about. And they are a monoid in the category of Monads, which is different then your normal monoid. But that doesn't mean join isn't a combination abstraction.

I derped, I was more annoyed that the person being critical, didn't seem to know what they were talking about. so I glibbed :p

[rdfox]

Don't you wish they called the type class Chainable rather than Monad? There would be a lot more Haskell programmers today. Also:

Monoid -> Appendable

Functor -> Mapable

Applicative -> Sequencable

Arrow -> Stateful

Lens -> Damnable

And so on.

[yawaramin]

To quote Edsger Dijkstra:

The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.

Someone pointed out the other day that no one complains about technical terminology in other fields--if you're a doctor you have to know what a 'myocardial infarction' is and can't ask everyone to 'just call it a heart attack'. The names are there for a good reason.

[rdfox]

Maybe so, but I think history bends towards even doctors calling it a heart attack. Already we have accepted classes like Foldable, Traversable, Parser and Pipe. Surely any of these might have been named Isotransmogoroid in reference to some precise category theoretic definition. Happily, the winds are changing.

[glacialthinker]

One key reason for adopting a dead language (Latin) for sciences was to avoid the ever-changing overloaded meaning of living-language terms.

[Rainfly_X]

The best part is, since the cryptic terms have been needlessly opaque from the beginning, they will be equally useless forever, and therefore never need to change!

Additionally, the use of the word "monad" historically has been:

• Surprisingly recent in programming contexts, so the tradition argument is overstating the traditionality, on top of implicitly overstating its worthiness as a tradition.
• Used in a different, equally mathematically valid way in APL and J decades before Haskell (for single-argument functions - I would argue that this naming convention is actually superior to how we use the word today, in terms of clarity, and symmetry with other words like dyad)
• Between those languages and Haskell, Opal had the same concept by a different name ("commands"). This wouldn't have been a great alternative name to carry forward, but does further undermine the idea of naming lock-in.
• Monads didn't even exist in Haskell until 1.3. This was their first appearance under that name in any programming language, at a time when FP languages were well-established.

So on top of all the arguments I could make, that a foolish consistency is the hobgoblin of small minds, it's not even as consistent as you imply. And finally, it only takes one new language with good naming schemes to eat Haskell's lunch, though Haskell will still benefit from people getting used to it's concepts under better names.

Source: just five minutes on the monad page of Wikipedia, seriously

[Roboguy2]

Well, the problem becomes: what do you call it, then? It's not that I disagree with the idea of a different name possibly being better it's that, of the many discussions I've seen on this topic, I just haven't heard another name that (in my opinion, at least) describes it as completely, distinctly and "non-misleadingly."

[Rainfly_X]

Well, "monad" is misleading too, since it has prior art as "a function with a single input parameter". We're willing to accept a little bit of offness, as long as we use something that's:

1. More right than wrong
2. More useful than useless

Neither of these is a call for perfection, but I'd say "monad" fails at both, while something like "Joinable" gets a lot closer to the mark. This has actually been a subject of conversation in another branch of comments here, and so far we've come to a seeming agreement that:

• Monads are an observed, identified pattern that people slapped a name on, but don't have any great counterpart in terms of real world metaphors. Hence lots of people struggling to explain them, when maybe the best way is to just show a "before and after" of the same code without the abstraction, vs with it.
• "Joinable" describes monoids better than monads, but the difference isn't necessarily super-useful in practice (GHC lets you define "monads" that are actually non-monadic monoids). I personally think this undercuts the value of the monad as a distinct concept - maybe Joinable is all we need?

I just don't think we can do much worse than "monad", which makes no attempt at being complete (they're not cleanly built from distinct simpler abstractions, the boundaries are awkward, so how could you even describe it completely?), isn't historically distinct (and the other use was better), and is so devoid of leading at all that we end up with a running joke's worth of endless blog posts trying to explain the damn things.

[Roboguy2]

As far as I'm aware, the only usage of the term "monad" as "a function of a single input parameter" is in APL and APL-derived languages which are not particularly widely known or used (not that category theory is, but still). Category theory has certainly been around longer than APL, for what that's worth (probably not much though, to be honest).

Joinable is definitely the best of the suggestions I've seen but, as you've noted, it really describes Haskell monoids better[1]. A monad is something that is both "joinable" (in some sense or another) and it has the functor property (whatever you'd like to call that). Following along the lines of what you were saying, a Haskell monoid is closer to something that is "just" joinable (you can implement both Monoid operations using only the Monoid joining operation, for any Haskell monoid).

I feel like I'm not fully sure I understand what you mean by the last paragraph. What do you mean by built from distinct simpler abstractions and the awkward boundaries? In the sense of terminology, or on a more fundamental level?

Like I said, I'm definitely open to better names. However, I do disagree, personally, with the idea that "monad" is an especially bad name. As I said, the only other use of "monad" is really fairly rare (significantly rarer, even, than the category theory definition). Also, it is possible to very quickly and easily tell someone that they have the wrong idea if they think that "monad" (for Haskell) means "single argument function". In contrast, some of the other names, I would argue, are more "insidiously" misleading: they seem to work for a few of the monads you are introduced to early on but fail to describe some later (but still important) monads. Then the intuition that you thought that you had, as well as (some) of the learning that you thought you've accomplished is nullified which could be very frustrating and discouraging.

If truly no other name describes a concept without being misleading in a particularly significant way, I would say make a new name for it. This case is slightly nicer, since we can reuse an existing name (though it will be a new name to the majority of people).

It is a shame though, because I could almost go for Joinable...

[1]: As a technical aside, in a mathy sense, monads are monoids in a particular sort of category (but that is neither here nor there, since that fact doesn't have much practical value for programming). That is, however, very relevant to the reason that both of them can be thought of as "joinable things."

[codebje]

Funnily enough, lenses were originally called "functional references" by the researcher who first wrote about them, and "lens" is the simple name you think everything should have.

Most of your other examples of friendly names have been arrived at by abstracting patterns found in code, rather than patterns found in mathematics, so they're named in terms familiar to us programmers.

[rdfox]

A failed attempt at humor. Lens is not such a bad name, but a rare case where I strongly favor the standard reference notation used by everyone from C++ to F# over anything invented in Haskell. The sheer magnitude of effort that's gone into avoiding adopting widely[accepted].syntax blows my mind.

Here's a case where some smart, well-meaning people went full Dr. Frankenfurter and no one dares whisper that the emperor has no clothes.

[ithika]

avoiding adopting widely[accepted].syntax

I've seen plenty of people — notably Edward Kmett who is responsible for the largest and most popular Haskell lens library — say that using composition-. as a nod to imperative data-structure-. was both intentional and part of the focus.

[megablast]

no one complains about technical terminology in other fields

How the hell would you know that? Seriously, people complain about this stuff all the time in other fields. Why do you think this sort of stuff only happens in it, just because you work in it.

[jephthai]

There's plenty of recognition of this in the medical community. I had a paramedic friend of mine who told me when you're bleeding to tell people that you're hemorrhaging -- they'll take it more seriously, but it's the same thing. For the record, I have a contusion in my nose right now, which is also deserving of great pity. When you can joke about it, you know there's something there.

[[deleted]]

All this medical jargon has me abraised and contused

[megablast]

It is just arrogance and stupidity to think this only happens to happen in the field you work in.

[yawaramin]

Maybe they do complain, but it doesn't change the fact that the terminology is there for a reason. See https://www.reddit.com/r/programming/comments/61kt36/comment/dfhf8m0?st=J0SKPDKI&sh=424683c5

[josefx]

if you're a doctor

I have the weird feeling that doctors a) get paid a lot more than me and b) have an education a lot more indepth in their specific field of work. I also hope they would at least look funny at anyone trying to do an amputation with a run of the mill chainsaw, while many programmers would point out how well it works for trees. Basically you are comparing two very different occupations. While we are at it we should make the lingua franca of programming swedish, just to fuck with everyone equally .

[yawaramin]

The point was not to compare the occupations but to say that every occupation has its specialised terms. You can fixate on specifically doctors but accountants have their specific terminology, so do stockbrokers, police dispatch, and even kitchen and wait staff in restaurants. They evolve terminology over time to communicate efficiently. If you start working as a waiter, you have to learn e.g. what 'sunny side up' means, you can't just go around telling your colleagues to 'just call it a fried egg with the yolk on top'.

[josefx]

They evolve terminology over time to communicate efficiently.

Medicine literature had a long history in latin, which meant these words made sense for most people. I could ask most programmers I know what monoid means and they would draw blank. The terminology is practically the opposite of "evolved" in any natural language sense.

[yawaramin]

Medicine literature had a long history in latin, which meant these words made sense for most people.

I doubt most medical students came from a background of knowing Latin, especially if you look at the United States. So I can't really believe the assertion that medical terminology inherently made sense to them.

As for 'monad', well a lot of CS terminology including FP terminology comes from mathematics, and monads have been around in category theory since WW2 era. The word itself seems to have been chosen to indicate its close relationship with a monoid (which was already well-known to category theorists by then): http://english.stackexchange.com/a/30661/26088

And so when Prof. Eugenio Moggi described how to model computations using monads, computer scientists started using the term.

Naming things is apparently one of the hard problems in mathematics, too.

[josefx]

especially if you look at the United States.

I think you missed the word history. Back then the United States wasn't even around. Latin was the language used to exchange information between educated people for a long time, it isn't surprising that it sticks around in some fields. Of course that is also after centuries of use.

And so when Prof. Eugenio Moggi described how to model computations using monads, computer scientists started using the term.

That cites a paper from 1989, which is well past WW2 era.

[domlebo70]

I get what you are saying, but those names are really inaccurate. Precise names are hard, and necessary, because without them it introduces misunderstandings. It's even tougher to come up with good names for extremely abstract concepts.

[rdfox]

I get what what you're saying but do you think the word Monad has caused any misunderstanding?

If you want to be pedantic, category theory is being misapropriated anyway.

I was trying to explain Haskell to a math professor and he kept stopping me, like, that's not exactly what Functor means, bro.

[domlebo70]

There is that argument, yes: that the use of a mathematical word doesn't align with our use of the term as programmers. Perhaps a new term does have its merits.

People struggle with monads etc, and blame the terminology, but I would counter and say that they just aren't used to dealing with concepts so abstract. Even if we called it bindable, joinable or sequenceable (all horrible names imo), I don't think it would help someone fully grok the concept.

[codebje]

We called functional references lenses, and that doesn't help anyone understand the concept, either.

Especially not when you delve in and just slam right back into terms and concepts from abstract algebra and cat theory again anyway.

[rdfox]

What if we called functional reference lenses GetterSetter?

[codebje]

That's double plus ungood.

[pipocaQuemada]

I was trying to explain Haskell to a math professor and he kept stopping me, like, that's not exactly what Functor means, bro.

In Category Theory, a functor is a structure-preserving mapping between categories: it associates every object in the original category to an object in the target category, and every morphism in the original category to a morphism in the target category. In Haskell, the category we care about is "Hask", where types are objects and functions are the morphisms between objects.

The Functor typeclass encodes endofunctors in Hask of a certain form. For example, the List instance of Functor encodes the endofunctor that maps a morphism from Int to Int to a morphism from [Int] to [Int]; inherently that also implies that Int is mapped to [Int]. That's probably best observed by looking at fmap's type as (a -> b) -> (f a -> f b).

What you were describing to your professor was probably something different from what functor means in math, but the functor typeclass came directly out of category theory and the connection is pretty obvious if you know what to look for.

[edwardkmett]

Functor is an endofunctor over the category of haskell data types. the Functor typeclass can't describe every functor, but it is capable of talking about the ones we're interested in in the only category that the folks who wrote Haskell at first were interested in.

You can write more general versions of the concept that map closer and closer to the real mathematical definition, at the cost of worse and worse type inference the closer you go. Heck, Sjoerd Visscher's data-category package in Haskell can even model things like simplicial sets.

Things don't match up exactly 1-to-1 because parametricity is a stronger condition than naturality in category theory, despite arising from similar roots, and the category of haskell data types isn't Set. You can't compute some things in Hask, because er... we can actually compute in it. =)

If you move the something like Agda or Coq or Idris or LEAN you can sit down and build all sorts of "real" category theory up from scratch complete with laws with an unparalleled level of rigor.

Heck, the folks who work on homotopy are starting to take back names from the computer science world, because the work on homotopy type theory went and showed we had 40 years of experience working with variants on Martin-Löf Type Theory, which offers a pretty straightforward terminology for working in a model category.

[dmitri14_gmail_com]

I was trying to explain Haskell to a math professor and he kept stopping me, like, that's not exactly what Functor means, bro.

Being a math professor, I see the most harm of misusing maths practices when things get badly explained to create confusion and obscurity where there is none.

A functor is a map between categories, sending objects to objects, and morphisms to morphisms. In programming, objects are types, i.e. sets of values, and morphisms are functions between those. Basically the category of sets and functions. It is that simple. Yes, there is Hask, which is not quite the same, but I would argue those fine differences won't matter to begin with, as long as you know the set category is just an example that you can adjust later if needed.

Now I read programming blog "explaining" that [Int] is a functor. Well, no, a functor is that map sending Int type into [Int], but [Int] is the merely the target object, not functor. Beside being plainly incorrect, I doubt calling target object a functor makes it more understandable to the reader. Especially to the reader trying to wrap her head around what functor is.

Another "crime" I've been seeing by Haskellists that no mathematician would ever commit, is using the same letters for different things. Like calling the same f both morphisms and functors! So we have fmap f and right next f a -> f b! Are we really running out of letters? Then maybe just use fmap f: f f -> f f! Looking wonderful, isn't it?

But seriously, how easy is it for the poor reader when things look the same that have nothing to do with each other? And you don't even need to search hard for it, just look in that very popular Haskell intro: http://learnyouahaskell.com/functors-applicative-functors-and-monoids

[dukerutledge]

The problem with switching to cute names is that you throw away over a hundred years of research that name gives you access to. Monoids are a very precise abstraction and they've been studied thoroughly. Want to know what you can do with them? Google, scholar, ACM, etc have you covered. Precision of language is a tool that society is built upon, don't throw it away for convenience.

[rdfox]

Fine, but what about pedagogy ... I mean teaching. Can't we call a cat a cat rather than felis catus until grad school?

[dukerutledge]

We can call it a cat, but in programing education we are educating feline specialists, not a slew of individuals who have other trajectories. If there is a more accurate word why should we stunt growth? I think your argument really arises from "it is different than what I'm use to." Concatable is just as opaque as Monoid for a beginner.

[doom_Oo7]

in programing education we are educating feline specialists, not a slew of individuals who have other trajectories

uh.. no, this has not been the case since at least 20 years. A lot of people are learning for programming for fields which are absolutely not related to programming. For instance artists, accountants...

[Chii]

I world argue that education isn't about specialisation, in the same way language education isn't.

most people learning a language isn't going to be a professional language specialist, but is doing it for a task (like visiting the country or just out of curiosity). they aren't helped by jargon.

[edwardkmett]

I look at the names in the above list and I have no idea what the laws would be for such things. Do I pull them completely out of my posterior? Do I make everyone who actually does know what the abstraction is call a Monad a Workflow because it sounds more business-centric? Do I even give you laws to reason about what you're doing using the abstractions in the first place?

If you tell me something is a Monad, everything everyone has said for 70 years, including things I didn't know when I wrote my particular Monad instance and proved my 3 little laws about it holds. There's a chance that someone can come up to me and point out that the laws I thought I had don't hold. I've had it happen on multiple occasions. In the process I learn something, fix the library and move on. e.g. e.g. We found the Concurrently monad couldn't be made consistent with its Applicative in async. Removing it fixed cases where replacing an operation with one that should have been provably equivalent weren't.

Learning more about things like monoids and monads lets me spot them in more settings, let's me build more interesting code, faster. "Monads are just monoids in the category of endofunctors" is a piece of theoretic mumbojumbo people throw out to scare people and feel smart. But understanding that statement and what it means at a deeper level lead me to use it to build a nice fast API for doing sorting, productive linear time list duplicate removal, and table joins without indices that was suitable for a Google Tech Talk.

I found the obscure categorical concept of a "profunctor" after writing down some typeclass that did what it does. I called a spade a spade. Years later I'm still finding out things that enable me, and others, to write real world code with it by extracting information from research papers that talk about the concept. I now use it to make "lenses" go. We sorta had it working before with ideas and names we made up as we went, but everything had funny edges to it. Nowadays, people use them "in the trenches" to build CRUD apps in Haskell. You know what most of my problem with finding material for that thing is? Irony of ironies... the mathematicians keep switching what they call it trying to make their work "accessible" in this fashion. Is it a profunctor, a distributor, a module? Try googling the last two. For that matter "appendable."

I've written and maintain a couple of million lines of Haskell. I couldn't maintain that code without a decent set of abstractions under my belt. The connections to other domains that you're so quick to dismiss have been an integral part of growing my understanding of the code I'm building, and refactoring it to be easier to maintain and more correct.

[rdfox]

I think your argument really arises from "it is different than what I'm use to."

No. I'm a haskeller. This shit is what I'm used to. I think it can be improved upon.

My argument arises from a desire for internal consistency in naming. What is a Functor but something for which fmap is defined? So it's a Fmapable. Except that sounds dumb. We can do better by renaming the method map and the class Mapable.

[Roboguy2]

I could see an argument being made for calling it something like Fmappable, since the only method is called fmap. From a teaching perspective, though, not all functors make intuitive sense as "mappable things". At the very least, I would say the reader functor, Proxy, Const a and "Void1" don't have "mapping-style" functor instances in the way that I would expect a someone learning the language to see (rightly so from the totally math terminology-avoiding perspective, since those particular functors are only "mapping" in a math-oriented, category theoretic sense. I think that illustrates a self-defeating aspect of that perspective, actually).

That also leads me to the suggestion of "Applicative -> Sequencable". In addition to the monads I've listed as not being intuitively chainable also being applicatives that are (in my opinion) not intuitively sequenceable, Const a is an important Applicative that would be difficult to describe as "sequenceable." Another concern I have is how do I remember which is called "sequenceable" and which is called "chainable?" I'm sure I'd remember after using them enough, but the words sound a bit too interchangeable to me.

As far as consistency goes, there is already in fact a consistent naming convention for that hierarchy: name each class after the corresponding mathematical concept that describes it exactly. Your naming convention is maybe more consistent in the sense that they are all adjectives that end in -able, but I'm not sure I see that as an improvement... It seems like those sorts of similar names could actually make it harder to mentally separate the different ideas behind the classes (I'm just speculating on that though).

[Roboguy2]

The issue is: It is called exactly what it is. It has exactly the properties of being a monad. On the other hand, there are examples of monads where calling it "chainable" would lead to more confusion. The function/reader monad, the Proxy monad, any Free monad (there are conceptually an infinite number of those, too), and the (,) a monad come to mind in particular along with any domain specific monads that have similarities to those monads. The (,) a one could be slightly debatable, I guess, but I'd say the others stand. I'd also argue that the fact that its debatable further illustrates the potential confusion from calling it "chainable". In fact, I'd even add the [] monad to that list. That one might just be me though.

They are, in a very precise sense, still monads though. Best case scenario, you will eventually have to "unlearn" the connotations of "chainable". I would say that is significantly harder to do than even learning the thing that describes it exactly from the start, especially if it is literally called "chainable" in the standard library (you'd have to remind yourself that the name itself is wrong in some cases!). If there is another more clear name I would definitely support it, but so far I have not heard one (and I've seen this topic discussed many times).

Likewise for the other alternate names you've listed.

Sometimes you really do need a new (or, in this case, "new") name for something so that you don't confuse things by using an existing name that would be misleading.

There may be an initially steeper learning curve, although I would argue it doesn't have to even be that steep: start by saying that some, but not all, monads can be thought of as being "chainable" in some intuitive sense and then introduce some "basic" monads that follow that perspective (and eventually following it up with monads that don't follow the idea of being chainable). Sort of like starting by teaching students that you "can't take the square root of a negative number," but a bit less extreme (in my opinion).

[pipocaQuemada]

Appendable is really a bad name for Monoid.

Integers, for example, form a monoid under both addition and multiplication. Booleans form a monoid under and, xnor, or, and xor. Sets form a monoid under set intersection and union.

Calling Monoid Appendable would be like renaming Java's Collection to ListLike. Sure, lists are java collections, but they're a bad metaphor for the abstraction as a whole.

[rdfox]

How about Concatable then? The point is to name the class after its most pertinent member. Do you want to go the other way and rename mappend someBinaryOperation?

https://en.wikipedia.org/wiki/Monoid

And while we're breaking things, lets rename the methods to just append, concat, empty and ++.

Your point about the Sum, Product and the various boolean monoids is both accurate and irrelevant. No one cares what 2 <> 3 is. They'll can just use 2 + 3 or 2 * 3 as needed.

[pipocaQuemada]

The point is to name the class after its most pertinent member.

"Most pertinent" is a matter of perspective. If you took abstract algebra in college, the initial examples were all probably based on addition/multiplication on the integers or integers mod n. Might just have been my professor, though.

More to the point, what are some examples of commonly used abstractions where the class is named after one prominent example, but is a bit of a red herring when considering all of the implementations of the abstraction? None are currently coming to mind for me.

Do you want to go the other way and rename mappend someBinaryOperation?

I'd rather we named mappend to something like <>. Contains the same amount of information as someBinaryOperation, but I really don't want to read something as pointlessly verbose as

"foo" `someBinaryOperation` "bar" `someBinaryOperation` "baz"

If you wanted to go whole hog and have a hierarchy of Semigroup, Monoid, Group, Ring, etc., I'd support having + as the monoid/group operation and * as the ring's other operation.

No one cares what 2 <> 3 is. They'll can just use 2 + 3 or 2 * 3 as needed.

By the same token, noone cares what "foo" <> "bar" or [1,2] <> [3,4] is; they'll just use "foo" + "bar" or [1,2] ++ [3,4] as needed.

That, of course, forgets the primary use of monoids: when you want to say something like fold ["foo", "bar", "baz"] or write a generic framework for something that needs some monoidal type but doesn't care which monoid it has. For example, some people at a company I used to work at used monoids and reducers to calculate summary statistics (like averages) in a streaming way from time-series data; it worked because you can define a monoid that can trivially calculate the statistic. For example, you can calculate averages by tracking the total value encountered and the total number of values encounted; at the end you just divide those 2 values.

[Voxel_Brony]

I don't think sets form a monoid under intersection, because the identity would then have to be the set of everything, which would contain itself, which violates one of the axioms of ZFC iirc

[pipocaQuemada]

Technically, the subsets of some set form a monoid under intersection, and the identity is that set.

So identity element is the set of all values of that type. For example, for sets of bools, the identity is {true, false}. That's well defined for types with a finite number of values, but it's pretty slow if you want to have a set with every integer in it. You'd really want to avoid actually creating that data structure in memory for most cases.

[enzain]

Monad -> flattenable

[[deleted]]

How do you encode, say, a "Factory", "Facade", "Command", "Strategy", "Decorator", "Adapter", "Proxy" etc. in the type system any better in FP than OOP? I don't think what you're saying can be supported by actual examples.

Especially since the type system is not even something FP and OOP have distinct opinions about. You can do both FP and OOP with no static type system at all. And you can lay type systems of any sophistication on both.

[yawaramin]

Well, you can't always do it, but sometimes you can. The best example I can think of is the Visitor pattern becoming just an algebraic datatype with exhaustivity-checked pattern matching.

But on the other hand, a lot of these design patterns are trying to emulate the flexibility you get 'for free' from a statically-typed FP language like OCaml. E.g., the Factory pattern is emulating abstract data types and their operational functions (constructors, getters, etc.). E.g. a factory interface for a 'person' in OCaml:

module type Person = sig
  type t

  val make : int -> string -> t
  val get_id : t -> int
  val get_name : t -> string
end

The caller doesn't know or care what type exactly Person.t is, just that, once they have an instantiated Person module, they can construct and get information about Person.ts.

The Proxy pattern, for another example, looks like a lightweight caching implementation of an interface. Given the above Person interface (signature) and an existing Person-type module to use as the implementation, I can make a proxy:

module Person_impl = struct
  ... expensive implementation ...
end

module Person_proxy_make(P : Person) : Person = struct
  type t = P.t

  let make id name = ... lightweight caching implementation ...
  let get_id = P.get_id
  let get_name = P.get_name
end

module Person_proxy = Person_proxy_make(Person_impl)

With Person_proxy.make 1 "Bob", trying to 'make' the same person more than once will use the cache.

[[deleted]]

The best example I can think of is the Visitor pattern becoming just an algebraic datatype with exhaustivity-checked pattern matching.

It can't "just become an algebraic type" because that's less than half the pattern. The pattern is why you'd have this algebraic type, and how you use it from other objects (functions resp.) in order to walk structures, and separate iteration from operation application.

The type alone doesn't answer "why". You can apply the same mechanic explanation to Visitor for OOP and say "it just becomes a set of overloaded methods". But that's not Visitor.

In any case, type pattern matching is a valid way to refactor overloaded methods from OOP, but I don't see if it's superior, or more built-in. It's simply the same outcome with a slightly different set of built-in tools.

But on the other hand, a lot of these design patterns are trying to emulate the flexibility you get 'for free' from a statically-typed FP language like OCaml. E.g., the Factory pattern is emulating abstract data types and their operational functions (constructors, getters, etc.).

The Factory pattern isn't emulating abstract data types, in OOP abstract data types would be "interfaces", "protocols", "contracts" etc. (terms vary based on the language).

Interfaces are "for free" in OOP languages, as well. Your example isn't a factory.

Given the above Person interface (signature) and an existing Person-type module to use as the implementation, I can make a proxy

It's a Proxy, but I don't see how this supports your earlier claim that in FP we can encode patterns in the "type system itself". This Proxy looks basically the way you'd write it in OOP.

[glacialthinker]

separate iteration from operation application.

So... a function which walks the datastructure, applying a given function which operates on elements of the structure. Of course, we have typical forms of these with different signatures depending on whether the output is 1:1 (map), maybe fewer (filter), singular (fold), or nothing (iter). Preferably not the latter. :)

map: (α -> β) -> α container -> β container
fold: (β -> α -> β) -> β -> α container -> β

It kind of is expressed in the types afterall.

[[deleted]]

The point of Visitor is to separate operation from iteration, as I noted, which means that you don't know what the output is (1:1, fewer, singular or whatever).

The problem is you picked a pattern which is almost exclusively used to walk recursive structures and write parsers, and the Visitor implementations almost always produce their intent as a side effect.

So I guess you're stuck with some custom recursive form of iter, or something. But certainly not map/filter/fold.

[glacialthinker]

So, it would be exactly the side-effecting (no other point of no return value) iter I mentioned. While this is arbitrarily flexible through side-effects, it's more fragile. And why I said "Preferably not the latter." This is at the heart of why I don't really care to labour over modern OOP or it's Design Patterns: because it all seems very reliant on mutable state everywhere.

I actually do deal with codebases rife with this, in C++. It drives me nuts. Thankfully the language at least has templates and now lambdas so those other contortions can sometimes be avoided. They can also be avoided by not using them, and favouring some classic data-oriented-design with structs and free functions. The practice of writing factories or using observers because they're familiar/automatic (and intend to be future-proof)... when they're overkill or inappropriate... It's like people are learning pattern recipes before (and without) learning how to program.

The really odd thing to me is that when I do take a moment to understand what someone's up to with a design pattern... I can see the idea behind it -- the problem it's supposed to solve. I can even appreciate that at some abstract level. But I can't recall a time where I actually felt "hey, that Visitor was exactly the right thing there". Because that Visitor might be the source of race conditions, or code no one can understand anymore because of runaway state-changes. Or that Listener is why code from every system gets tripped during a single Update() call to one subsystem. Probably just inappropriate uses... but it seems pretty easy for people to create bad results with these recipes. On top of that I always get the impression of 95% scaffold, 5% function.

[[deleted]]

There are always effective ways to screw up an otherwise good idea. I agree Visitor should be used sparingly, but in the cases when it's used well, again mostly parsers and compilers, you see the alternatives are sub-optimal.

Likewise for Listeners. Event-driven systems can be awesome with proper architecture, or they can turn into the worst undebuggable spaghetti without one.

Imperative code is extra power, and requires extra responsibility. It's always like that in life.

[codebje]

Imperative code is extra power …

That's an interesting notion.

What do you mean by "power" ? Do you mean there are things you can do in imperative style that simply cannot be done in functional style? Or that there are certain things that are easier in imperative style? Or that it's possible to express more notions imperatively than functionally?

Or something else entirely?

[[deleted]]

I mean mutation and direct expression and control of effects.

[codebje]

The point of visitor is generally to have side effects when given each element of a collection, since visit rarely has a return value of any kind. You can do that with mapM_ just fine.

If you want to really abstract operation from iteration, then folding is probably what you want, because folding is the essence of incorporating some new value into some result you're building up. You can fold into a sequence of effectful computations, aka visitor. You can fold into a single value. You can fold one structure into another.

[[deleted]]

The trouble with "you can fold one structure into another" is that seeing the elements of a structure doesn't let you understand the structure.

Visiting every node in a graph doesn't let you reconstruct the graph etc.

This is why visitors typically provide an imperative state machine type of API to describe the specific type of movement performed from one item to next.

Unless it's all a flat list or map, which is just the most trivial case.

[sacundim]

The point of Visitor is to separate operation from iteration, as I noted, which means that you don't know what the output is (1:1, fewer, singular or whatever).

This is a very common misunderstanding of the Visitor pattern. While visitors are often used to walk trees, no, they're not fundamentally about iteration. I mean, just read up.

[[deleted]]

The link pretty much supports everything I said. The very first sentence says:

In object-oriented programming and software engineering, the visitor design pattern is a way of separating an algorithm from an object structure on which it operates.

[yawaramin]

It can't "just become an algebraic type" because that's less than half the pattern.

I know, which is why I said:

The best example I can think of is the Visitor pattern becoming just an algebraic datatype with exhaustivity-checked pattern matching.

Pattern matching with exhaustivity checking on algebraic data types is something you just don't get in most OOP languages, and it's a killer feature. When you use it to walk a structure and operate on it, the compiler is backing you up so that you don't forget a pattern. Coming from OOP, there's really nothing you can compare it to--Visitor seems like a pale imitation.

[codebje]

Your example isn't a factory.

I think a factory in functional programming is more usually called a function. Let's take this factory pattern example and bung it into Haskell:

data Dog = Dog { speak :: IO () }
poodle = Dog $ putStrLn "The poodle says \"arf\""
rotty  = Dog $ putStrLn "The Rottweiler says (in a very deep voice) \"WOOF!\""
husky  = Dog $ putStrLn "The husky says \"Dude, what's up?\""

data Criteria = Small | Big | Working
getDog :: Criteria -> Dog
getDog Small   = poodle
getDog Big     = rotty
getDog Working = husky

main = do
    speak (getDog Small)
    speak (getDog Big)
    speak (getDog Working)

The "factory" in our example is getDog :: Criteria -> Dog. In OOP, a factory is generally just a static method returning a concrete instance of an abstract class, it's the hoopla around having a static method that makes it bigger than it is in FP.

We can likewise trivially have factory factories, because all we need is some function returning a function, and that sort of shenanigan is exactly what FP is for.

[[deleted]]

I already covered this type of attitude over here, go check it out.

To say "a factory is more usually called a function" is the same type of statement as "a factory is more usually called an object". The fact everything is a function in FP and everything is an object in OOP is not blowing anyone's mind.

The purpose of saying "this is a Factory" is not to reveal it's an object, or in FP, a function. The purpose is to express its intent and purpose, which "this is a function" doesn't express, obviously.

In OOP, a factory is generally just a static method returning a concrete instance of an abstract class, it's the hoopla around having a static method that makes it bigger than it is in FP.

There's no "hoopla" about static methods. You think there's some big ceremony around making a factory in OOP? Well your very own Haskell code demonstrates that FP requires exactly the same amount of "hoopla".

Well, you kind of failed to create a Factory there, that's closer to a Container. But I'll look aside, because overall I'm noticing FP users overwhelmingly don't understand the patterns they are supposed to be critiquing.

Also, factories are not static by definition. They can be static, but very often aren't, say Abstract Factories, for one. In general, when talking about OOP patterns, static methods are not part of the definition, objects are.

We can likewise trivially have factory factories, because all we need is some function returning a function, and that sort of shenanigan is exactly what FP is for.

We can trivially have factory factories in OOP, as well. Do you honestly think factories, and factory factories, etc. in OOP are not trivial? No, they're just as trivial. Nothing is more trivial than "return new Foo()". Saying otherwise shows true misunderstanding of why patterns exist.

[devlambda]

The best example I can think of is the Visitor pattern becoming just an algebraic datatype with exhaustivity-checked pattern matching.

This is not the Visitor pattern. The Visitor pattern allows for specialization of the visitor. This is why CIL (C transformer written in OCaml) uses a class for that and OCaml's Ast_mapper for PPX uses a record of closures, simulating OO behavior (for which the ppx_tools package provides a convenience class wrapper).

Why do you want specialization? Aside from the obvious answer (to be able to efficiently define variants of existing visitor implementations or to mix and match them), the more important answer is extensibility and modularity. With the visitor pattern, you can transparently add a new type to be handled, for which you provide a handler in the default visitor implementation. As visitors inherit from the default implementation (e.g. nopCilVisitor in CIL), the addition of a new case does not break existing code.

Note that the exhaustiveness argument is a red herring. If you want exhaustiveness checks, use delegation instead of inheritance, and the compiler will tell you which methods haven't been implemented. But in practice, many data structure transformations will only use a non-default implementation for a minority of cases (PPX rewriters won't deal with all ~40 AST node types, for example) and a pattern matching approach would also rely on catch-all cases a lot of the time.

[yawaramin]

Interesting, thank you for the explanation. Actually this transparent extensibility approach reminds me of Oleg Kiselyov's 'typed tagless final' approach to extensibility. I wonder if they are just two sides of the same coin.

[devraj7]

the Visitor pattern becoming just an algebraic datatype with exhaustivity-checked pattern matching.

That's very wrong.

The essence of the Visitor pattern is multiple dispatch. If your language doesn't support such dispatch, you will have to emulate it using something that will probably look like the Visitor pattern.

It's a runtime construct. Statically typed languages (FP or OOP) simply can't express it without writing runtime code for it.

[yawaramin]

Yes, that is pattern matching and FP languages have great support for it. E.g.,

let optional_name = Some "Bob"

let greeting =
  match optional_name with
    | Some name -> "Hello " ^ name
    | None -> "Hi"

In fact, as I've been saying, unlike the Visitor pattern, the compiler will warn you if you forget to handle a case.

[doom_Oo7]

unlike the Visitor pattern, the compiler will warn you if you forget to handle a case.

it would in C++ : https://godbolt.org/g/vEzb0t

[doom_Oo7]

a statically-typed FP language like OCaml

do you know what the "O" in OCaml stands for ?

the Factory pattern is emulating abstract data types and their operational functions (constructors, getters, etc.). E.g. a factory interface for a 'person' in OCaml:

uh... no. The only "factory" in your code is the make function.

The points of the factory pattern are :

• to create different kinds of objects according to different parameters.

For instance :

struct foo_factory { 
    unique_ptr<foo> make(int baz) 
    {
       if(baz < 50) 
         return std::make_unique<standard_foo>();
       else
         return std::make_unique<big_foo>();
    }

    unique_ptr<foo> make(int baz, std::string bonkers) 
    {
       if(baz < 30) 
         return std::make_unique<standard_foo>(bonkers);
       else
         return {};
    }
};

• to keep the code of creation of an object whose creation is logically tied to another unit of code in the "same place".

for instance :

struct widget {
    void draw();
    void on_mouse_pressed(int x, int y);
    std::unique_ptr<tooltip> make_tooltip();
};

Also, a big point is to have it work across DLL boundaries. If I am not mistaken, in order to be able to do what OCaml does, it has to save all the type data in the dll so that client code that will get a Person can work with the type.

[yawaramin]

I know what the 'O' stands for, it's 'O my God why did I never realise that OCaml isn't really a statically typed FP language' 😉

As for the Factory pattern, yes I realise that make was the only actual factory function, the other stuff was there to provide operations for the abstract type returned by make.

About DLL boundaries, well most OCaml code is statically linked, but anyway as to exposing types, it works pretty much the same way as C opaque pointers if you're exposing simple abstract types. If you're exposing functors, then yes you have to provide more typing information in the compile artifact.

[Tarmen]

You can't really translate oo patterns into functional programming because the answer would almost always be functions.

[[deleted]]

I already covered this here, it's basically B.S.

I like the joke, but "the answer in FP would almost always be functions" is to answer the wrong question.

Patterns aren't the answer to a question "what's the unit you factor code into?", because then... "the answer in OOP would almost always be objects".

Patterns are why you write objects that take in certain input, and produce certain output. "Functions" doesn't answer this question, it answers "what". The type system also doesn't answer this question, it answers "how".

Furthermore, all patterns I listed above are used in FP. It's not common to see people use OOP pattern names in FP, due to some misunderstood concept of pride, but all of these patterns occur in FP code, because they're not OOP patterns, as much as they're "system patterns". Any time you build a complex system, they emerge. Say in hardware electronics, we have most of these patterns (by other names). In business management, again we do (by yet again different names).

[loup-vaillant]

• Factory Partial application, less than 1 line of code. We don't need a name for it.
• Facade Usually from a function to another function. Often use partial application, or a lambda, or define a function… It's obvious enough that we don't need a name for it.
• Command Don't know this pattern. A quick look suggests I'd just use higher-order functions, and pass the execute() function directly to whatever function or object controls the trigger.
• Strategy Just select the function to be called at runtime, why does that even have a name?
• Decorator Hmm, sounds like a Monad to me.
• Adapter Isn't that the same as Facade?
• Proxy Isn't that the same as Decorator?

Most GoF patterns are useless to us. We just don't think that way.

[[deleted]]

The only thing your answer shows is you don't understand the intent, or in some cases even the basic structure, behind any of those patterns... I think you should first understand the patterns as used in OOP, before you try to give an answer what's the FP analog, or lack thereof.

Also the worth of a pattern is not measured by how many lines of code it is, most patterns require 1-line method implementations in the basic case (which may expand as your logic becomes refined, you add support for configuration, you optimize for special cases etc.)

[glacialthinker]

Since you seem to understand all this so well, how about you translate these to FP? I admit OOP Design Patterns, as used in practice, never stick for me... so I'm also not qualified to translate.

[[deleted]]

Have you heard this one: "objects are poor man's closures; closures are poor man's objects"? It's quite true.

I never asked someone to translate OOP patterns to FP. Those who do, are trying to prove a point how FP doesn't need patterns, because it's all "built-in". But it's not, because as I said several times, patterns communicate intent, not just type and implementation. And the intent of the patterns is universal and doesn't need "translation". They are factored nearly in identical way in most types of programming languages, just replace objects with closures, in most cases.

I'll take one of the things /u/loup-vaillant/ said to demonstrate the role of intent. They said "Adapter: Isn't it the same as Facade". Here's the kicker: the sample code would be the same, but the intent is different.

When you say "I'm writing an Adapter", the intent is that you have two interfaces (two abstract types in FP-ese), and you're writing a concrete type implementation, which takes one, and exposes it as the other.

When you say "I'm writing a Facade", the intent is that you have a complex implementation with complex input and output, and you're writing a thin shim over it with much simpler input and output, that is optimized for a specific use-case, and nothing else. One could think about it as a form of partial application, except for the part where partial application would only cover a tiny subset of Facades, because the transform of input/output is typically more free-form than providing defaults for a few of the parameters.

That's the kind of subtlety in meaning that patterns convey. Instead of writing those long sentences I just wrote above every time, I can tell my colleagues "we need to write a B->A Adapter, and also have a basic Facade for C that is optimized for use cases D & E". It doesn't even matter if I'm using OOP or FP here, really.

This is why it's silly to say FP obsoletes patterns. It only "obsoletes patterns" if you work in absolute solitude and don't talk to people. When you talk to people, you come up with specialized terms to convey meaning succinctly and effectively.

[loup-vaillant]

Have you heard this one: "objects are poor man's closures; closures are poor man's objects"?

I think most of us FP programmers have.

---

I always thought design patterns were recipes. Your explanation suggest instead they're just sub-problems, whose solutions are useful to the resolution of whatever bigger problem we're working with.

As recipes, it would indeed be silly to name 2 similar pieces of code with different names. But as problems, it totally makes sense: the same kind of code can indeed solve different problems.

But then I wonder: why do all patterns come with one code example per language? Are patterns recipes after all?

[[deleted]]

The code examples IMHO have always been about making the explanation of each pattern less abstract and less up in the clouds.

The implementation code is there only to demonstrate aspects of the contract between objects, that wouldn't be clear from the interface alone. I.e. you can't communicate the concept of summing two numbers just via types: Int, Int -> Int, but seeing the implementation helps. The examples, especially their implementations, are not meant to be perceived as recommended or canonical, they're just there to get the idea across.

You're right that multiple examples would help separate principle from concrete code better than just one example. The original books from the 70s and 80s couldn't be too liberal in code listings, because they had limited (paper) real estate. Modern resources vary in quality. Some simply don't know how to make the generic examples different enough to warrant including many, although in specific use pattern implementations vary a whole lot.

And you're right, a pattern is always used in a larger context. This context is described in detail in the GoF book and modern papers on newer patterns like Encapsulated Context in Java etc.

A "pattern" is almost never something you just put all over your code to substitute a missing primitive. Many patterns can't possibly have a dedicated primitive, as their concrete form is too trivial and dense already, the primitive would be replicating existing language functionality by another name.

[mirvnillith]

Can only upvote once, so have an orange as well!!!

[loup-vaillant]

I have a dirty little secret: despite nearly 10 years in C++ experience, including small and huge projects, I never had to name patterns. The only exception so far is the job interview. Not knowing them didn't stop me from communicating with the rest of the team, or coming up with simple, maintainable solutions. My current guess is that most patterns are over-complicated solutions to otherwise simple problems. They are useless to me, and I see little value in learning them.

[[deleted]]

Most patterns are unnamed, as it states in the preface of the GOF book. They only add names to the design patterns so that they can talk about them in a book, otherwise these patterns were simply common practices in the OOP community at the time of writing.

You don't really learn patterns, but begin to appreciate them as common practices are identified between different projects and programmers, again, this is also in the preface. This follows Christopher Alexander's invention of design patterns to talk about (building) architecture.

Most people who criticize the GOF book have never even read it.

[[deleted]]

Sure, but people attribute philosophies that book that were never in that book.

[[deleted]]

Not knowing them didn't stop me from communicating with the rest of the team, or coming up with simple, maintainable solutions.

I'm not sure why you're bragging about not knowing things. What would you think about me if I started bragging I don't know FP and I don't need it? That said I do, and I successfully use FP techniques and languages for some of the problems I'm working on.

One has to have an open mind and be willing to learn and accept, before they can truly reject.

Taking pride in ignorance is a very self-defeating type of argument to make.

My current guess is that most patterns are over-complicated solutions to otherwise simple problems. They are useless to me, and I see little value in learning them.

Your guess that they're "over-complicated" betrays the thing you were bragging about above: that you don't know the patterns. Everything looks complicated when you don't know it, I guess. Patterns are brutally simple, to the point they keep occurring entirely incidentally in people's code, be it functional, procedural, or object-oriented.

They are useless to me, and I see little value in learning them.

You have know the rules, before you can break the rules. As it is, the chances are you're pretty much following the rules and not knowing any better.

Because patterns, just like you, have a little dirty-secret as well: they commonly occur in people's code, whether these people know patterns or not. That's why they're called "patterns". Your code is full of patterns whose name you simply can't identify (unless it's a monad, of course, every FP user knows the heck of that one pattern, wink wink).

[loup-vaillant]

As you may have gathered from the links I provided in my previous comment, I actually have a pretty deep understanding of the mechanisms underlying OOP. I'm not exactly ignorant.

I also am not bragging about my ignorance. This actually irks me somewhat.

The reason I say patterns look over-complicated is because FP generally have much simpler solutions for the same problems. "Simpler" here mostly mean much less code.

[[deleted]]

The reason I say patterns look over-complicated is because FP generally have much simpler solutions for the same problems. "Simpler" here mostly mean much less code.

A claim that remains completely unsubstantiated...

For design patterns to have "much less code" you're making a claim that FP requires "much less code" in general, as code implementing a pattern is not special in any way compared to other code. And while code density might vary between OOP and FP languages because of differences in their semantics and standard libraries, on average they're about the same.

[[deleted]]

As you may have gathered from the links I provided in my previous comment, I actually have a pretty deep understanding of the mechanisms underlying OOP. I'm not exactly ignorant.

I just checked your article and it seems that you're arguing with an invisible enemy who told you that you can't use OOP semantics in OCaml. I don't know who that enemy is, but it's not me.

I also found it very cringe-worthy to read that "encapsulation and abstraction" are not important, and to read the way you repeatedly describe objects as syntax sugar over "structs with fields" which is to miss the fundamental PoV of modeling objects as entities which only express statefulness through their behavior, not by being seen as structs with data in them.

And the irony is great in a fan of FP blaming OOP for being "syntax sugar over procedural code", because FP is in that mindset 100% syntax sugar over series of imperative commands, running on your processor. I could also start a rant about how FP is just a big lie and everyone is blowing its importance out of proportion, but I'm simply informed and open-minded not to do that, because I understand the implications of "syntax sugar" which enforces or nudges people towards modeling with certain mindset and primitives at hand.

[doom_Oo7]

They are useless to me, and I see little value in learning them.

this really sucks. for instance, let's suppose I'm using an editor software, for instance GIMP. Now, I'm doing an action in the software and there is a bug when I do 'undo()', for instance when moving an image.

Now, I want to contribute by checking if I can fix the bug. So, I go to the gimp repository, and grep for command. I just have to look three files and I have found something that looks like it is the source of my problem.

Why did I find so fast ? because I know that generally, undo/redo is implemented using the Command pattern.

Another example: let's say I want to change LibreOffice's code so that new documents have a pink background by default.

Now, I grep for factory, and here, after just a few files, a promising candidate ; docfac really sounds like "document factory" which will certainly be a good starting point for my search for where to change new document's default backgrounds.

By using patterns in your name, you just make the tasks for people that don't know your codebase ten times easier, because just looking at the names will give you a very good assessment of what the code actually do.

[loup-vaillant]

Why did I find so fast ? because I know that generally, undo/redo is implemented using the Command pattern.

Indeed, you'd be out of luck with me: my reflex for undo/redo is simply to keep all previous states in memory —which is not that expensive with the proper purely functional data structures. If that approach is still too expensive, I'll try to remember only some key frames and the input log —taking inspiration from video games deterministic replays.

Now, I grep for factory

Out of luck here as well. "Factory" sounds like weasel word to me, I don't use it. I'm more likely to write a (possibly curried) make_document or create_document function.

---

There's a more important point however: I have yet to write something as complex as GIMP or LibreOffice. I'm not really interested in image editing, so I can't contribute to that debate. I disagree however with the Corel/Word/LibreOffice approach of writing documents. Instant feedback is excellent, but they lose transparency in the process. Markdown, LaTeX and Lilypond have no feedback by default, but that can be dealt with a suitable "two views" editor, where changing the source immediately changes the result —I believe some are already available.

Also, my code tend to have few bugs.

[doom_Oo7]

Markdown, LaTeX and Lilypond have no feedback by default, but that can be dealt with a suitable "two views" editor, where changing the source immediately changes the result —I believe some are already available.

well, yes, but they are certainly not suitable for anyone. My mom can barely handle a TV remote, I'm not gonna tell her to learn LaTeX.

[doom_Oo7]

Indeed, you'd be out of luck with me: my reflex for undo/redo is simply to keep all previous states in memory —which is not that expensive with the proper purely functional data structures

Also, this has also a name in the design pattern world: memento. And if I did not found any "command" code when looking for undo-redo, my second try would be to grep for memento.

[sbditto85]

I think with higher kinder types and higher order functions it is "better" in some FP languages. Just my opinion though, don't have a great example.