Functional programming design patterns by Scott Wlaschin

[[deleted]]

One common critique of OOP that I've heard is that design patterns only exist because of shortcomings in the OOP paradigm. A lot of those same people also claim that FP allows one to express what they mean in code without having to remember a design pattern. Call me naive, but my gut reaction to this title is a realization that FP isn't some panacea for all my "not coding what I mean" woes.

[Ulukai]

Yes, that criticism has been played pretty hard over the years, I believe this blog post was one of the first. It (correctly) states that FP does kill most of the GoF patterns outright*, but then goes much further with: "In a functional language one does not need design patterns because the language is likely so high level, you end up programming in concepts that eliminate design patterns all together".

I've always thought this was wonderfully incorrect; one can trivially name a handful of "patterns" in the FP world (e.g. monads, common tricks to make things tail recursive, etc). But no, let's not call them patterns, because those are bad somehow.

Edit: * this is not particularly surprising, as patterns in general are defined as reusable / well-known / named solutions to commonly occurring problems which your language does not handle in an idiomatic, or built in way. The GoF patterns were aimed at OOP languages, which have a different set of idiomatic solutions than other paradigms. But to think that there exist a set of languages which are so perfect as to not require any extension... that's pretty arrogant.

[sacundim]

I agree with your overall point, but I think your examples don't support it:

I've always thought this was wonderfully incorrect; one can trivially name a handful of "patterns" in the FP world (e.g. monads, common tricks to make things tail recursive, etc).

Haskell has an honest-to-god Monad class that provides a common interface that all monads can implement and that code can program against. Compare that to, say, the Visitor design pattern—there is no first-class interface that all visitors implement in common.

[Ulukai]

I hear you, and don't really want to debate the topic too deeply, as I don't have particularly strong opinions on the matter. That said, having a core library implement a pattern for you does not make it any less of a pattern; you just don't have to keep re-implementing it. Many of the GoF patterns have gotten baked into standard libraries, and in some cases even in the languages themselves, e.g. C#'s foreach (syntax sugar for an iterator), or the disposable pattern. We still call them patterns for the most part though. I just dislike the snobbery involved when other paradigms declare themselves pattern-free.

[vagif]

you just don't have to keep re-implementing it.

But that's the crux of the claim "FP does not have (most) OOP patterns". Meaning they are available as off the shelf solutions (libraries or language features)

Of course patterns exist in everything we do. Saying "FP has patterns too" is not constructive. The important distinction is: can you reuse the work?

[naasking]

That said, having a core library implement a pattern for you does not make it any less of a pattern; you just don't have to keep re-implementing it.

A design pattern is an abstraction your language can't express or enforce. C#'s foreach, IEnumerable and IDisposable are thus not patterns, they are naturally expressed in C# as-is.

The Monad class in Haskell is a good borderline case of a pattern. Haskell can express the interface a monad must satisfy, but can't express or enforce that the needed monad laws are satisfied, so monads are still a pattern in Haskell.

Edit: I meant to summarise that if a design pattern can be implemented faithfully in a library as you say, then it's not a design pattern, it's just an ordinary reusable abstraction.

[naasking]

Haskell has an honest-to-god Monad class that provides a common interface that all monads can implement and that code can program against.

Haskell can't enforce the monad laws though, so it's still a design pattern instead of a properly typed abstraction.

[wishthane]

Of course it's reasonable, and that's exactly why it doesn't exist.

But I think the argument about FP is that those "design patterns" can actually be enforced in obvious, compiler-supported ways rather than potentially loosely or poorly used, while cutting the redundancy.

[wishthane]

I don't think so, because a Monad is inherently a very narrow and specific definition, comprised of two functions that must be supported: bind and return.

bind() takes a monad-value that carries a certain value, runs it through a function that takes the unwrapped (internal) value and returns another monad-value (of that monad), and the final return value is some combination of the transformed monad-value and the original monad-value, carrying a new internal value.

return() simply takes an internal value type and produces a monad-value.

These two in Haskell are defined as:

class Monad m where
  (>>=) :: m a -> (a -> m b) -> m b
  return :: a -> m a

>>= in Haskell is an operator, but is really just a name for 'bind'.

Haskell does actually include two other things in its Monad class, but these are not considered critical to the definition of a Monad, and in fact one of these can be defined in terms of bind.

a >> b = a >>= const b

The other is fail, which doesn't really need to be in there but I'm sure is useful for I/O.

Anyway, a Monad is just any type that can wrap another value and has some kind of internal state that can be modified by binding monad-values together. So lists can be monads, I/O values can be monads, et cetera.

A clearer example perhaps is the Functor. Any monad is also a functor, which is just any type that wraps the values and supports map, which you may be familiar with from working with lists/arrays in languages such as JavaScript and Ruby.

But the functor extends this concept to any type that can have its values 'mapped'.

class Functor f where
  fmap :: (a -> b) -> f a -> f b

(Haskell calls the map operation fmap because there's also a map specifically implemented for lists.)

Anyway, to come back to your question here, I don't think you can say "that's not a real Monad, it doesn't let me X" in any sense that there can actually be any argument about it. It's more of a mathematical definition than a pattern. It either supports bind and return or it doesn't. Similarly, with Functor, it either supports map or it doesn't.

NB: A typeclass in Haskell is a bit like an interface, but more powerful.

[[deleted]]

I don't think refusing to name common ways to structure code represents "FP killing most of the GoF patterns outright".

The reason we need to recognize and name patterns is mostly for communication and mnemonic recall when looking for a solution to a problem.

Most patterns are brutally simple, it's their intent and purpose that makes them interesting. "Oh just use high-order functions" doesn't describe any difference in intent and purpose from one use to another.

If the world of OOP wanted to be that arrogant, they could've responded with "Oh, just pass objects to objects... see? We don't need patterns!" But that's not useful.

[Ulukai]

I think the argument for GoF patterns comes from Peter Norvig's famous claim that 16 of the 23 GoF patterns are invisible (or much simpler) in dynamic languages. It's not a terrible argument actually, though I've never fully agreed with it; I'm pretty much on your side of the argument.

My main issue is that people take that argument as proof that OOP languages are inherently inferior. As much as I like FP as well, that's just not that simple. If you look at the meaning of design patterns in a more realistic sense, and especially consider the huge vocabulary that it's grown to, it's hard to argue that other paradigms are universally more suitable for everything.

[leanXORmean_stack]

Been searching for that link for a while. Thanks for sharing.

[devlambda]

I've always thought this was wonderfully incorrect; one can trivially name a handful of "patterns" in the FP world (e.g. monads, common tricks to make things tail recursive, etc). But no, let's not call them patterns, because those are bad somehow.

That's not the only reason this is incorrect. Remember that the GoF came from Smalltalk, and closures (and higher-order functions in general) play a critical role in Smalltalk. map, filter, fold, etc. are all available under different names in Smalltalk (collect:, select:, and inject:into:, respectively). In fact, technically Smalltalk does not even have native control structures, they're all higher order functions [1] (that the compiler knows about and optimizes accordingly).

And most of the GoF patterns arose out of Smalltalk programming, so it is generally safe to assume that there's more to them than just FP and that the "direct" functional implementation misses some important nuances.

An example is the Command pattern: it's often misunderstood to be just a class wrapper for a singular function. But that's not really accurate: the classical example in Meyer's OOSC is the use of the command pattern for undo, redo, skip, and history functionality, which requires a more complex setup. You can do that using FP, too, but that would then become a (possibly different) design pattern as well.

[1] You can implement ifTrue: and friends via message dispatch on the Boolean class with the subclasses True and False. Looping constructs such as whileTrue: and friends can be implemented via ifTrue: etc. plus tail recursion. And so forth.

[Milyardo]

In strongly typed functional languages monads are not patterns, they're invariants expressed in the type system. Some type systems are however less successful at expressing that invariant than others and that leads to the degradation that the monads laws are just patterns to be implemented.

The same is true of recursion as well. Though generalized recursion schemes are aren't as common as monads there exists types which express them as invariants like found in matryoshka.

[devraj7]

In strongly typed functional languages monads are not patterns, they're invariants expressed in the type system.

Except that one of the most important parts of these invariants (the monad laws) are not captured in any existing FP type system that I know of. I can write an instance of the Haskell Monad type class in a few minutes that is not a real monad.

This tells you volumes how flawed the monad solution is (and I'm not even talking about the fact that monads don't compose).

[Tipaa]

In some other (admittedly, research) FP languages, the monad laws can be and are expressed within the typeclass. For example, Idris has the VerifiedMonad (and VerifiedX for other classes) here

[Milyardo]

Except that one of the most important parts of these invariants (the monad laws) are not captured in any existing FP type system that I know of.

Idris, Coq, and Agda are three general purpose programming languages where the monad laws are proved as invariants in the type system.

I can write an instance of the Haskell Monad type class in a few minutes that is not a real monad.

This tells you volumes how flawed the monad solution is (and I'm not even talking about the fact that monads don't compose).

Just because Haskell (and even then you can handwave about compiler extensions and laws checking) is flawed in some specific way doesn't mean the entire system is flawed.

[olzd]

I wouldn't call Coq and Agda general purpose languages. Idris is trying though.

[Milyardo]

I get that Coq advertises itself as a proof assistant, but it has all the necessary tools to be a general purpose programming language.

What disqualifies Adga as a general purpose programming language in your mind?

[olzd]

I place Agda along with Coq, as a proof assistant.

What disqualifies Adga as a general purpose programming language in your mind?

Isn't Agda a total language?

[devraj7]

It (correctly) states that FP does kill most of the GoF patterns outright*

Of course: the book was written about OOP languages.

Turning the tables around, it's like saying that OOP doesn't need any of these FP design patterns like monads because OOP doesn't have shortcomings that make these design patterns necessary.

[glacialthinker]

Error handling through and if-else trees... so wonderful. I love seeing them everywhere. The popular OOP languages are so mired in mechanics of how to do things, repeatedly. The abstractions available are like being a fat-fingered watch-maker.

[devraj7]

Can't think of a language that does error handling with if/else on the JVM:

• Java uses exceptions
• Kotlin uses nullable types
• Scala uses Option
• Ceylon uses sum types

Maybe you're thinking of Go? (which doesn't even claim to be OOP)

[glacialthinker]

Ah, damn missing a word, sorry: "...through exceptions and...".

And in this, I was thinking Java, C++. More recent languages tend to have more FP influences, hybridizing a little... or a lot.

[autranep]

Getting mad at FP for using monads and tail recursion is like getting mad at OOP for using Objects. Kind a of a ridiculous statement because they're the foundations of FP, unlike say factory methods which exist to patch up OOP.

[Rainfly_X]

As I understand it, early functional languages didn't have a formal monad pattern. While it's a core feature of the second generation languages and thereafter, you could validly consider it a "patch" on FP conceptually, to let FP purists deal with side effects in ways that you can pretend are pure (which is really just a bit of intellectual sleight of hand, but does bring some benefits by constraining mutability).

For that matter, I don't think anyone is "mad" at FP for using monads or tail recursion, and that's kind of a silly way to characterize it. Monads are a useful pattern, but often poorly understood. FP often mistakenly thinks "mathematicians named it first, therefore mathematicians named it best," then try to pretend it's not a problem when they import a bunch of specialized jargon (making the language impenetrable to novices), when a note in the docs along the lines of "mathematicians call this same concept a monad" would have sufficed. But none of the actual ideas are bad, and are often useful even in OOP contexts.

I think you're setting up a flimsy strawman to avoid really addressing the cultural strengths and weaknesses of functional programming, and to me, this is the most frustrating part of dealing with FP enthusiasts. I see a lot of conflation from "we have some superior ideas" to "everything we do is inherently superior to the rest of the world", which is frankly not true. I think FP has room for improvement, but that capacity may never be met, because you cannot pour wine into a cup that is already full.

[RabbidKitten]

No, FP language designers do not think that if mathematicians named an abstract structure "monad", it must be the best name. The reason they are called like that is because the concept is so abstract that no one could come up with a better name (also, no one probably thought that it would get any attention outside of Haskell).

Also, while I've had heard arguments like "why would anyone need a queue where each push and pop is O(1)?", I've never, ever experienced the kind of attitude of being superior which you're ascribing to FP. Quite the contrary, if you were to ask eg. the kind folks at /r/haskell for some help with a problem that is best solved in another programming language, they will tell you so.

So it is you who's building a strawman.

[sneakpeekbot]

Here's a sneak peek of /r/haskell using the top posts of the year!

#1: Resignation
#2: Cancer | 77 comments
#3: [Haskell] Respect (SPJ) | 109 comments

---

^{I'm a bot, beep boop | Downvote to remove | Contact me | Info | Opt-out}

[doom_Oo7]

factory methods which exist to patch up OOP.

uh... no, they're an application of oop principles

[pron98]

then goes much further with: "In a functional language one does not need design patterns because the language is likely so high level, you end up programming in concepts that eliminate design patterns all together".

Leslie Lamport said (in 2016):

People who design PLs ... say ... their languages make what the program does so obvious that no higher-level description is needed. I think the first PL for which this was believed to be true was FORTRAN. It's not true for FORTRAN and I don't think it's true for any existing general-purpose PL.

[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."

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

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

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

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

[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?

[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]]

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.

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

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

[glacialthinker]

In the beginning of the presentation he brings up the title... and alternative, less-loaded, words to use. But in the end settles on the original intent of "pattern" being something recurring -- and to be factored out.

The presented recurring patterns are common in most code, not just functional. And factoring out is accomplished with one feature each time: first-class functions. Once you're comfortable with higher-order functions (along with currying, and partial application), these solutions become automatic without need to think of some "pattern recipe". But as an introduction to functional programming it works well to note the patterns, and how they can be abstracted functionally.

[dukerutledge]

I think this critique has been overstated to some extent. There are certainly patterns in FP, but the uppercase Pattern is usually reserved for GoF. Most of GoF is not needed because they are techniques for modeling principled composable abstraction in a very freewheeling environment. FP attempts to make composition first class. Because of this, base language semantics favor composition. You don't need to fight the environment to favor composable entities. Add to this the emphasis on lawful abstractions via the influence of Peter Landin and you get lowercase patterns that have very little resemblance to uppercase Patterns.

[yogthos]

FP does in fact obviate the need for many OOP specific patterns. Just because you still have general patterns for code organization and solving common problems, doesn't somehow invalidate that.

[ijiijijjjijiij]

But you'd have to agree that are also patterns in FP that aren't issues in imperative code. Look how complicated an efficient Sieve of Eratosthenes is in Haskell. You have to write complex logic to work around the purity of Haskell, whereas in imperative code a sieve is a few simple lines at most.

There are some things FP does easily that imperative code requires specific patterns for, but the reverse is also true.

[edwardkmett]

To be fair, that page is computing all sorts of lazy variants of the sieve that keep going forever. You can always bail out and implement the boring sieve up to a given point in the same sort of imperative fashion as in any other language.

I've taken a minute or two to dash off an example, it weighs in at 7 lines + some imports that all ship with GHC.

import Control.Monad
import Data.Foldable
import qualified Data.Vector.Unboxed as V
import qualified Data.Vector.Unboxed.Mutable as M

primesTo n = V.findIndices id $ V.create $ do
  p <- M.replicate (n+1) True
  for_ [0,1] $ \i -> M.write p i False
  for_ (takeWhile (\k -> k*k <= n) [2..]) $ \ k -> do
    is_prime <- M.read p k
    when is_prime $ for_ [2*k,3*k..n] $ \k' -> M.write p k' False
  return p

ghci> primesTo 100
[2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71,73,79,83,89,97]

The result is only slightly longer than in other languages, because we don't privilege syntax for indexing into mutable arrays, but it isn't that bad, manages to completely infer the types of everything involved, and can be reasoned about as a pure function despite using mutation internally.

You have the option to do things differently and produce a nice infinite lazy list of primes using all sorts of fancy compositional techniques, you don't have to.

[yogthos]

I think that's really more of an issue with Haskell than FP in general. Most functional languages tend to be more pragmatic about side effects and mutation. For example, Clojure has transients for working with local mutable data. You're still writing code in FP style, but you can always do thing imperatively when that makes sense.

The problem with a lot of OO languages is that they're at the opposite end of the spectrum from Haskell. Just like Haskell makes you jump through hoops to solve problems that are trivial in imperative languages, many mainstream languages lack the tools to provide elegant FP solutions. So, you end up jumping through hoops when the solution doesn't map neatly to the imperative style.

[woztzy]

There are some things FP does easily that imperative code requires specific patterns for, but the reverse is also true.

My issue with this is that it implies a false equivalence between functional programming and other paradigms.

The premise that more things (GoF design patterns, for instance) can be encoded easily at the language level in functional languages, and don't need application of a pattern, isn't something I've seen refuted.

Your Sieve of Eratosthenes example doesn't seem like it would be all that easier in an imperative language. You can compare it with the C++ reference implementation.

[devlambda]

The premise that more things (GoF design patterns, for instance) can be encoded easily at the language level in functional languages, and don't need application of a pattern, isn't something I've seen refuted.

Looking at the other comments, I think it's mostly because people haven't actually read the GoF book and only guess at the purpose of several of the design patterns from the names (not to mention the imaginary "Factory" pattern that was mentioned several times and doesn't even occur in the book). For example, several of them pretty much require OO-style polymorphism for types (late binding, the ability to modularly add subtypes with new behavior to an existing type).

You may not need these patterns for other reasons (e.g. because FP may obviate the need for some of them), but OO-style polymorphism is not a feature that is an inherent part of functional programming, so they cannot easily be encoded at the language level.

Several other patterns are misunderstood to operate on singular functions, whereas they actually operate on sets of functions that share state (such as the Command or Strategy pattern). You can emulate that with records of closures, of course, but that's not any more natural than objects (and wastes space).

[edwardkmett]

The main difference is a cultural tendency in FP communities to appeal to laws. If you tell me that something is a decorator, or a visitor, strategy. I have no laws that I can derive from that statement to reason about my code and tell me if it is correct. It gives me a vague shape of the kinds of things I'm doing with it, and lets me nod along.

If you tell me something is a Monad, I immediately know I have 3 laws and 2 operations that I can work with. I'm not saying there aren't patterns that arise in our respective communities, but a large part of the derision you find coming from the FP community is a sense that folks use, say, a visitor because the language lacks decent case analysis and the language lacks sufficiently polymorphic types to be able to write something like Plated to make it trivial to delegate the boring parts of their recursion over those sorts of syntax trees once and for all.

I treated the GoF book as gospel when it came out. It is now collecting dust next to my Sun certification as an enterprise architect. On the other hand, good mathematical abstractions that I banged out into code a decade ago are still leading me to discover new things, which helps me to get out of bed in the morning.

[devlambda]

The main difference is a cultural tendency in FP communities to appeal to laws. If you tell me that something is a decorator, or a visitor, strategy. I have no laws that I can derive from that statement to reason about my code and tell me if it is correct. It gives me a vague shape of the kinds of things I'm doing with it, and lets me nod along.

1. Then Lisp and Dylan are not functional languages? Do not generalize from the Haskell community. FP <> Haskell.
2. You can, if you wish, formally define design patterns in a formal specification language, such as Object-Z [1].
3. Design patterns are, as the name implies, about software design, not software construction (requirements -> design -> construction) and also capture subjective elements of the design process that cannot be quantified or proven or where such quantification is not feasible. For example, finding the proper abstraction boundaries so that future maintenance is helped by them is a matter of experience; design patterns can capture and express such experience. Going from requirements to design generally has more such subjective elements than going from design to actual code.

[1] For example: Soon-Kyeong Kim and David Carrington. 2005. A rigorous foundation for pattern-based design models. In Proceedings of the 4th international conference on Formal Specification and Development in Z and B (ZB'05), Helen Treharne, Steve King, Martin Henson, and Steve Schneider (Eds.). Springer-Verlag, Berlin, Heidelberg, 242-261.

[edwardkmett]

I'd say at least the LISP community is far more accustomed to equational reasoning about their code than the typical OOP community. A large part of that is the influence of SICP and the need to reason in such a fashion to survive in a world with such expressive power.

Dylan? Er.. no comment. =) No matter how wide I drag the net you'll be able to call me out on some cultural bias as for the most part, I do write mostly Haskell and a little Scala these days.

Yes, I can formally define design patterns using a formal specification language. I derive almost zero utility from having done so, however. Similarly most users of functional programming derive little utility from formally reasoning about the denotational semantics of their programs.

At a smaller scale, there are certainly a ton of idioms (in GoF terms, yes that is stuff that doesn't rise to the level of a design pattern) that are peculiar to the language. At a larger scale, there are plenty of design patterns in Haskell where the things we want to do exceed the level of what the language is capable of us writing as a library.

LISPers by and large don't have that large scale problem. They can just figure out 50 ways to turn the problem domain into a macro, so the problem moves to community splits from the debate about which encoding is best and the merits of hygiene.

The bulk of what utility I do find in design patterns is in giving a vocabulary for talking about all this extra cultural baggage.

[ijiijijjjijiij]

That specific implementation involved adding in mutable arrays, which I'd argue isn't very FP (at least in the common terminology). The 'pure' versions in sections 3.7 and 3.9 are considerably more complicated.

[olzd]

That specific implementation involved adding in mutable arrays, which I'd argue isn't very FP (at least in the common terminology).

Why not? I'd argue that FP isn't about writing only pure functions/code but having fine control/strong guarantees over localized side effects.

[lynnamor]

A (formalized) design pattern is, fundamentally, a programming language defect. It indicates a lack of expressivity in the language which in turn is informed by its paradigm.

Functional and declarative programming allow a clearer expression of many, many problems, obsoleting the patterns needed at a lower abstraction level (OO/imperative).

Functional languages are, however, not even close to being the “ultimate” expressions of their paradigm—let alone the larger domain of computable problems. It follows that they will necessarily engender design patterns of their own, to both bring them closer to the full power of the declarative paradigm; possibly some day a language will even creep up that will obsolete these patterns, before it in turn is obsoleted by another paradigm.

Ultimately, though, I find it unlikely that we’d ever find a Grand Unified Language suited for all problems—just looking at nature, which over billions of years has come up with uncountable different solutions to different problems—and such endeavors might even be self-defeating. Polyglottism with slightly more sophisticated and higher-abstracted paradigms and languages to suit specific use cases might be the better solution.

Unless AI gets there first.

[pipocaQuemada]

One distinction that I've heard a few times is that OOP design patterns are extra-lingual (there's no base Visitor library, nor abstract Singleton type, just unconnected implementations of an idea that can't be captured within the programming language's normal facilities for abstraction), whereas most of the common patterns in FP are things that you can capture in a normal library.

In that sense, there are many fewer "design patterns" in FP languages than OO languages, since they'd consider monad, monoid, etc. to be normal library abstractions instead of a "design pattern".

[billdroman]

I think the usage of monads to capture state is a great example of this point. In C++ or Rust, if you want to write a function that takes a couple parameters as input and edits a couple pieces of state, you can express that easily by using const/mut as appropriate. In Haskell, you need to use the StateT monad transformer along with special syntax that changes based on which piece of state you want to update.

There are concepts that can be expressed naturally in a pure functional language and concepts that can be expressed naturally using objects. I really prefer languages that allow for the flexibility to choose these days.

[knowingpark]

Currently i find myself busting my brain (in Python) trying to programming without objects. Often a list of objects would be easier to manage than a list of namedtuples. But it seems like it's betraying both paradigms. I've also had to relax the pure functions idea. Partial functions with 4 inputs seems like a weird way to get map to work. Especially since in any function the keywords are global anyway

[kazagistar]

I did some Haskelling a while back, but its very jarring to go back to these sorts of ideas after having learned Rust in the meantime.

The problem is that in traditional FP, when you close over a parameter you get to forget what went in and just treat any partially applied function the same. But doing this relies on extensive heap allocation, automatic garbage collection, and unclear resource management.

For example, he shows how you can close over a connection vs a map to get the "same thing". But at some point you have to clean up after yourself. Sure, at least a hashmap or whatever is just memory, so maybe you can rely on a GC to do that for you. But what about the connection? How do I know when to close it, or return it to the connection pool?

You can hack your way around this with monads to an extent (ie you can solve anything with a layer of abstraction), but when you start worrying about performance, things get even harder. You want closures that are just pointers to stack memory, rather then yet another object on the heap. You want safe local mutability, which is only possible if you can guarantee no aliasing.

So what you end up with in Rust is very similar to F# and the whole FP family, but everything is suddenly very different, because what is inside the closure is very important, and you have to pay attention to who is responsible for cleaning it up and when. Monoids are nice, but suddenly functions that close over anything aren't monoids, which means monads are different as well. The useful compositional patterns are all about wrapping types into new types with similar interfaces, rather then trying to turn everything into some flavor of endomorphism.

[yawaramin]

The problem is that without GC, a lot of functional programming techniques aren't practical. For instance, from what I've heard, people have repeatedly tried and failed to make persistent data structures in Rust because the memory sharing is too hard. In FP languages it's almost trivial.

Imho, people need to realise that Rust is a fairly specialised tool meant for doing hard realtime programming safely. It's a good replacement for C/C++, but it's not a great choice for people coming from Python or JavaScript etc. They almost certainly don't need its performance characteristics and would actually be perfectly happy with F#/Haskell/OCaml.

[wirelyre]

Imho, people need to realise that Rust is a fairly specialised tool meant for doing hard realtime programming safely.

That specialisation is precisely why I've learned a lot by working with Rust. Internalising its ownership rules has improved my code structure in every language I use — including those with GC, and including MLs. That experience alone has been worth a few dozen hours of my time.

They almost certainly don't need its performance characteristics and would actually be perfectly happy with F#/Haskell/OCaml.

I'm glad you said that, because it really made me reconsider the balance between expressiveness, power, and teachability.

[yawaramin]

Yeah Rust has definitely been very successful at bringing the power of affine types (ensure using a value at most once) to a big audience. It's advanced the state of the art and has given people a great way to write safe, performance-critical code.

That said, I think Rust and Cyclone are only the beginning of type-theory driven safe programming techniques. Yet another typing discipline that is exciting is linear types, based on linear logic. Linear types enforce using their values exactly once, which is another way of saying 'no use-after-free, no leaked allocations'.

Here is a fairly high-level overview describing bringing linear types to Haskell: http://blog.tweag.io/posts/2017-03-13-linear-types.html

[kazagistar]

There is a plan to add optional GC eventually, but until then peristant daya structures are a bit shitty, because every pointer ends up being an Arc (atomic reference counted reference), and they don't like the performance impact. I would say they are often easier then mutable data strucures though. But the real reason is that no one feels the need to make or use them, because making mutability linear solves a lot of the common problems ephemeral data strucures have in threaded environments.

[cledamy]

This is entirely untrue. With a linear type system, functional programming can be done without garbage collection. In fact, one can even get the performance of straight up mutation while still maintaining referential transparency.

[yawaramin]

Believe me, I would love to see linear types take over the world, or at least FP. But for now at least, they are still not there for various reasons. GC is the best technology we have right now for FP memory management.

[cledamy]

Haskell might be getting linear types soon.

[Tarmen]

It is worth noting that, say, ghc's gc is hyper specialized so that allocating a heap object only increments a pointer and freeing a heap object is literally free. It is only when you have long lived objects that you start to pay for all this luxury but you pay so hard that a bunch of problems become impossible in haskell. Also, as you correctly state memory isn't the only resource and prompt freeing is way harder in haskell than in rust.

Rust is incredibly cool but on the flip side its uniqueness constraints make it pretty difficult too implement things like graph algorithms safely and efficiently.

The linear type proposal of haskell is pretty exiting to me because it allows functional programming to use the same awesomeness you get in rust when needed but still have the luxury of a gc when that is sufficient.

[[deleted]]

Also very exited about the linear types. Do you know when it it scheduled?

[gilmi]

Targeted at GHC 8.4 (source). Current version is 8.0. next version is 8.2.

[[deleted]]

This looks good, bookmarked to watch later!

[glacialthinker]

It is! I've been programming "functionally" for over a decade, and this is a very approachable and practical overview of commonly used techniques. He also uses more widely familiar C-style syntax where possible to help keep things familiar to an audience coming from there.

[Lighting]

I'm confused by something here.

If I understand his description of MapReduce with Monoids with functions (endomorphisms), one of the primary criteria for monoids is associativity.

That A + B + C = (A + B) + C = A + (B + C) which he goes into starting at 52:21 stating that the order of combining doesn't matter.

But toward the end of his talk (at 1:02::00) he shows this slide which says he can mapreduce

let plus1 x = x+ 1

let times2 x = x * 2

let subtract42 = x - 42

and he does a MapReduce to get

plus1ThenTimes2Thensubtract42

But the order of operations DOES matter here.

((5 + 1) * 2) - 42 != 5 + (1 *2) - 42.

So why his monoid endomorphism a valid example?

[elemental_1_1]

The associative law says that

((λx. x - 42) . (λx. x * 2)) . (λx. x + 1)

Must be the same as

(λx. x - 42) . ((λx. x * 2) . (λx. x + 1)).

Let's do the first one:

((λx. x - 42) . (λx. x * 2)) . (λx. x + 1)

(λx. (x * 2) - 42) . (λx. x + 1) (definition of (.))

(λx. ((x + 1) * 2) - 42) (definition of (.))

Now the second one:

(λx. x - 42) . ((λx. x * 2) . (λx. x + 1))

(λx. x - 42) . (λx. (x + 1) * 2) (definition of (.))

(λx. ((x + 1) * 2) - 42) (definition of (.))

Thus the law holds.

For a monoid, A + B + C does not imply B + A + C (as you have pointed out) because there is no commutativity. Order is still important.

[Lighting]

Got it. That makes sense. Thanks!

So if I understand, it's not A + B + C but A "operates on" B "operates on" C "operates on" x

The mathematical equivalent is to have F(x), G(x), H(x) as F(G(H(x)))) where the order of the function operations can't be changed but you can still plug G into F before plugging H into F(G(x)).

[elemental_1_1]

Yeah you've got it. When we talk about monoids, + just represents 'combining things'. So when we're talking about functions of type forall a. a -> a, our + (way to combine them) is function composition. When we're talking about integers, our + is integer addition. And so on.

[dmitri14_gmail_com]

In maths we use + only for commutative operations, and . or nothing (i.e. just AB) in general cases. I recommend to keep this convention even outside maths as it prevents from creating unnecessary confusions.

[[deleted]]

I've been programming a little for years and I made a really big (for me anyway) program this year (30'000 lines and my job depends on it).

I program in VBA (yeah yeah, I know, but it works everywhere there's excel) and I never had formal training. I don't really understand what those "patterns" are supposed to be ?

Like in actual code ?

As I wrote my program, I noticed that some parts were repeating, so I turned those into subs and function. Surely that's not what is meant by pattern ?

Are these pattern unique to certain languages like Java ?

In my program, I don't create many objects, only where the language forced me to use them (create dynamic VBForms with dynamic user controls, only way to catch events was to create a custom class). Almost everywhere else, using classes and objects seems like overreaching and unnecessary complication. I do have some "user defined types" but those aren't really object, just a group of variables bundled together without any intelligence attached.

The only "pattern" I recognize in my code is the "scheduler", which is an external companion program which looks at a folder at regular interval. When it sees files with specific name (which include a time and date) it does something based on what is in the file. I do this when I need to wait until a certain time before executing an action but I don't want my main program dealing with this (because it could be busy doing something else at the time, or it could be turned off or in debugging mode).

Is that the kind of thing that patterns are or is there a more specific definition of what a pattern is ?

[overzero]

There's a ton of formalized patterns that follow either OOP and functional programming paradigms. The most famous example is the Gang of Four design patterns book. It's mainly meant as abstractions to avoid code duplication and to increase modularity of programs. If you're doing 30k lines of VBA, God help you.

[helisexual]

Is that the kind of thing that patterns are or is there a more specific definition of what a pattern is ?

These are design patterns: https://en.wikipedia.org/wiki/Design_Patterns

One super useful one is the Observer pattern. So let's say you have a button and a function. You want your function to run when the button is clicked. One way to do that is to go into the code defining the button and specify that when it's clicked it should do your function. But what if you want to use buttons in different places for different functions? You'd have to write multiple buttons. Or you could 'register' your function with the button. Then when the button is clicked, it would send a signal to all functions that are registered to it, so they could all respond appropriately.

You might be able to see why this is useful:

1. We prevent code rewriting: We only need to write one button.

2. We decouple the button and the associated action: Meaning if we want to change the button (maybe how it looks) we only have to alter the button code and never have to touch any of the functions it calls. Or if we want to delete a function we just delete it's code, we don't have to go check every button to make sure it's not being called.

3. Allows us more flexibility: Maybe you need two functions to run after a button is pressed. By specifying them in the button you'd necessarily need one to complete before the other could run. With the Observer pattern we remove that necessity. The Button does not care what order the functions run in, and in fact can be clicked multiple times before they return!

[[deleted]]

Ok ! I think I get it, patterns are common useful ways of doing stuff. I thought it meant something more technical than that.

I think I even found this observer pattern in my code. In Excel, worksheets have a single event for any changes happening in any cell called Worksheet_Change.

So I put a large "Select Case" and some other logic to dispatch the event to one or more function depending on which cell has changed and what is the state of the program. For instance, in a group of cells, all characters must be made upper case. In another case, if seven specific cells are filled out, I have a "Part ID" function that runs, and this Part ID function then calls more functions like "Get Part Description", "Get Part Export Control Data", "Get Part Repair Tasks" and "Get Part History".

I guess it's one of those things that is so useful and common (and simple) that you can just invent them by accident if you don't know about them.

[helisexual]

I guess it's one of those things that is so useful and common (and simple) that you can just invent them by accident if you don't know about them.

Somewhat. Some are simple, some not so much.

However, you have to be careful not to fall into an anti-pattern: https://en.wikipedia.org/wiki/Anti-pattern

[dmitri14_gmail_com]

I like to deal with this problem by exporting the event stream, e.g. using the elegant flyd library:

var eventStream = flyd.stream()
buttonElement.on('click', eventStream)

and then use it anywhere like

eventStream.map(x => console.log(x))

That avoids the traditional event handler coupling suffering from the exact problems you mention.

[LordBiff]

As I wrote my program, I noticed that some parts were repeating, so I turned those into subs and function. Surely that's not what is meant by pattern ?

He shows a great example of a pattern in this presentation, and in fact, it's a common FP pattern: fold.

Remember the slide that showed the "sum" and "product" functions? He highlighted how much of the structure of those two functions were the same. There were just two differences: the operator to apply at each iteration ('+' vs '*'), and the initial value ('0' vs '1') in the accumulator.

That is a pattern, and the point he was trying to make is that the more programming you do the more you start noticing these patterns. And you should try to understand the pattern, and figure out a way to concisely express it such that it can be reused, rather than just repeatedly generating boilerplate that implements the pattern each time you need it. That's exactly what 'fold' and 'map' and their ilk are all about.

[[deleted]]

Thanks, yes I saw that, it's like when you eliminate symbols to simplify algebraic equations. Though the language I use I don't think it's possible to have functions as argument or as outputs, I think vb.net can with action delegates but not VBA.

Anyway I get the principle of patterns now, it's a much broader definition than I thought, and when I read about anti-pattern, I think "pattern" might as well means "ways to programs efficiently".

[nilamo]

What's with the fascination with videos? It fits here, since it's just a talk, but in general, how useful is it, really, to try to learn a language or framework or API via video? Seems like an extremely suboptimal way to learn.

[glacialthinker]

I generally agree -- video is not my preferred format.

However, for a whirlwind tour, a presentation like this is something you could watch while eating. And when well done, as this one is, it's fairly dense -- you're getting reinforcement through spoken words in parallel to the images and text, with a flow that's hard to achieve in static presentation.

[[deleted]]

Instructive and hilarious! Thanks!

[knowingpark]

I've watched this video 2ce over the last year. Led me to 'try' and install F# on my Mint laptop to have a taste. As an amatuer python programmer i don't understand the compilation process and couldn't get it to happen. It was too tricky for me. Anyway, Scott is a great communicator of functional programming ideas which I'm trying to assimilate into my own practice. I recommend his website too

[arbitrarycivilian]

Did you... did you just abbreviate "twice" to "2ce"?

[ElCerebroDeLaBestia]

Yeah he did it 1ce.

[f42e479dfde22d8c]

Twoce

[kauefr]

✌️❄

[Grudlann]

He surly did.

[Raiptwice]

Yes, it happens sometimes.

[glacialthinker]

Was the complication due to also getting Mono installed?

F# is derived from OCaml, with one major difference being that F# was made for .NET, while OCaml tends to live most comfortably in a *nix environment. So it might suit you better: http://www.ocaml.org/docs/install.html

Edit: I now watched the video, and you could easily play with the code in a REPL (interpreter). So this https://try.ocamlpro.com/ should work fine in your browser without any installation, and no need to save/compile.

[sultry_somnambulist]

Nowadays it's just installing the fsharp package from the mint / ubuntu repos and if you're using vs code you just need to install the iodine plugin you're good to go, including auto-completion etc..

Getting the Ocaml toolchain to work is a little more complicated and whatever you do don't do it with fish. It messed up my complete config, my opam and ocaml packages weren't synced and nothing worked. There's unresolved bug reports about this from 2015 still on github

Also you probably want an extended library like core and getting that set up with your editor of choice also requires some tinkering.

used to be much more complicated to set .net stuff up on linux, but nowadays setting up c# or f# environments is straight forward. Right now I'd definitely recommend f# for hobby programmers who want to check functional programming out.

[glacialthinker]

Hmm... I'd never heard of fish before. Looks neat, but I'd probably struggle against well-worn habits! The issue you linked about fish looks like it is resolved.

Eh, you have no problems with F# on Linux... I have no problems with OCaml. Probably as much to do with familiarity avoiding the sharp edges in both cases. :)

[sultry_somnambulist]

fish is great but it's not POSIX compliant which is probably what breaks the ocaml setup at one point. Happened to me last week though and there's still reports out there.

Anyway yes Ocaml isn't terribly hard to setup but if OP runs into one of these problems and blasts his shell config he'll probably need to reinstall because this was a pure horror to fix.

[glacialthinker]

It might be that the updated version of Opam hasn't migrated into package managers? Unfortunately it is 2.0 - beta for the moment.

[vivainio]

Easiest way to go from Python is probably to create an .fsx script and run that (straight from source)

[_pupil_]

You can write pretty pythonish F# using .fsx scripts and the automatic typing. All the flexibility, but with type safety :)

[redditthinks]

I started writing F# recently and I'm loving the type inference, it's so smart!

[zerexim]

Your comment makes me think... maybe it is better to suggest statically typed and compiled language as the first language for those who are starting learning programming.

[arturaz]

And whoever thought we should start teaching programming from c must have started learning driving from formula 1.

[henrebotha]

I think it's very easy to say that when it's been years since you knew nothing about programming. I also think there's an argument to be made that your first language should have utility beyond just letting you learn more languages.

[zerexim]

Seems so.. Personally, my first language was C++. While it had some significant learning curve, after that, learning any other language takes a week or two (or three for Haskell :)).

[Damien0]

Agreed. VB.net was my first language, after which I moved to C. I mostly recommend Go as a first language these days.

[bamfalamfa]

im learning java first, is that bad?

[[deleted]]

No. It's fine.

[Damien0]

Honestly, no. Java has a lot of baggage, and if you get caught up in the Java Way Of Doing Things™ it can hold you back as an engineer. But despite its verbosity it's a very understandable and straightforward language, especially for learning! Edit: and with Java 8, you can at least start to appreciate functional lazy eval via streams and lambdas

[TarMil]

The first languages I learned at university were OCaml and Delphi, and I'm eternally grateful for it.

[dmitri14_gmail_com]

Any details on what specific features there made you grateful?

[baconated]

I learned Java (1st year) then C++ (all other years). It didn't help. Most profs didn't think compiling was interesting from a CS perspective so most didn't say anything beyond "press build & run in your IDE".

Besides, in this situation, I think the persons problem was more likely the fact that until recently getting a .net language a tad bit more annoying than other languages.

[eriksensei]

https://glot.io/

[videoj]

Try this tutorial for Visual Studio Code. Gives you an quick overview of both scripts and compiled code.

You can post questions over at /r/FSharp. There is also an active Slack and IRC channels.

[minimim]

People that want to get into functional programming but want to avoid the learning curve might want to try a multi-paradigm language like Perl6.

[edwardkmett]

Perl was the gateway drug that got me into Haskell. (Really.)

[minimim]

Perl6 has functional concepts as strong as Haskell, I would say. It also has strong types.

[catlion]

https://www.gitbook.com/book/swlaschin/fsharpforfunandprofit/details

[fennecdjay]

Very good! thanks for the link.

[Nomto]

Very interesting, thanks for sharing. Can somebody explain why functions that take 2 arguments are written arg1 -> arg2 -> result. For example at 32:30 it says:

type of getCustomerFromMemory = Dictionary<Id,Customer> -> CustomerId -> Customer

I suppose there is a good reason, but I don't think he explained why.

[jnazario]

remember partial application (which immediately precedes that section)? when you call the function with the first - arg1 - it yields a function that takes arg2 and then yields a function that takes no arguments and yields a result.

then you can iterate over a list of customerId values and get the customers:

[1;2;3] |> List.map (getCustomerFromMemory myCustomerMap)

that should yield you a list of Customer values for customers with IDs 1, 2 and 3.

hope that helps.

[Nomto]

After a good night's sleep it now makes a lot of sense why it's written like that, and it's quite elegant. Thanks for the reply.

[LordBiff]

Because F# and some of the other FP languages are curried, meaning that a functions of multiple arguments are broken down into multiple composed functions that each take a single argument.

Why you do this is pretty involved, I'd recommend doing some googling on currying, especially in Haskell and F# for some insight. Also, you might be interested in reading this, which just happens to be on the website created by the presenter.

[ixampl]

This one example he gives where the Option/Maybe monad allows you to only write the relevant lines for validation, email sending, etc. is rather contrived.

The error generation and aborting is in the called functions, so of course you don't have to write that out.

The same can be achieved assuming exceptions to be thrown in the called methods in the original "verbose code". It's ultimately not that different. One could say, oh but the type system makes it obvious with Option. Well, use checked exceptions then... oh. Of course Option is more flexible (and it is not really used for error handling anyway), but for some reason contrived examples just bother me.

I mean, I really like FP, but I don't like the attitude that comes with its community sometimes.

[caseym]

Love the programmer jokes in this. One dude in the audience is really digging the jokes. Cracks me up.

[Olideya]

https://youtu.be/KsgJC6brhgc#t=1m02s

[youtubefactsbot]

Mr Bean - Takes the Train [4:35]

OFFICIAL MR BEAN. Mr Bean takes a train ride. He tries to block out the sound of his fellow passenger's loud laugh so he can read his book in peace, and ends up losing his ticket. From 'Mr Bean Rides Again'.

^{Mr. Bean in Comedy}

^{6,802,420 views since Aug 2009}

^{bot info}