I have been exploring Clojure for a while now, although I haven't used it on any nontrivial projects. Basically, I have just been getting comfortable with the syntax and some of the idioms. Coming from an OOP background, with Clojure being the first functional language that I have looked very much into, I'm naturally not as comfortable with the functional way of doing things.

That said, are there any specific workflows or design patterns that are common with creating large functional applications? I'd really like to start using functional programming "for real", but I'm afraid that with my current lack of expertise, it would result in an epic fail.

The "Gang of Four" is such a standard for OO programmers, but is there anything similar that is more directed at the functional paradigm? Most of the resources that I have found have great programming nuggets, but they don't step back to give a broader, more architectural look.

closed as too broad by gnat, user53019, user22815, Ixrec, Bart van Ingen Schenau Sep 12 '15 at 11:04

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.


Patterns of this kind are usually symptoms of a broken, unfit underlying model.

OOP is broken by design, unfit for the most of its applications, therefore it bursts with all that so called "patterns". Functional model is (just a bit) more flexible, and the need in "patterns" is not that obvious there.

Once you start applying a (natural for the functional programmers) language-oriented approach, using or creating DSLs for each specific problem domain, you'll find that no patterns are showing up at all, because you're always employing an adequate model for describing a problem.

Of course some recurring high level "patterns" or "recipes" are unavoidable even in the very abstract, clean and pure math, but they're of a different kind and of a different level of abstraction than the GoF patterns. You'll find monads useful, for example.

  • +1 for the last 2 paragraphs, I think that's spot on. Regarding OOP, I'm curious as to the rationale behind calling it broken, other than the fact that it's a generic tool often applied to specific problems (hence low-level patterns like the GoF ones coming into existence). Can you elaborate in brief, or post a link summing up your opinion? – Daniel B Oct 12 '12 at 12:58
  • @DanielB, there is nothing wrong with OOP per se, but the way it is usually applied is totally broken. This model fits only a few of the real world problems (and it really shines there, when applied appropriately), but for the rest it needs all that crutches and duct tape to fit. See my answer at programmers.stackexchange.com/questions/52608/… for example. – SK-logic Oct 12 '12 at 13:56
  • OK, I think I'm on the same page. In fact, I may have asked this exact question once before, sorry about that - the way you phrased that line just seems like you are implying more. – Daniel B Oct 12 '12 at 14:21

In my personal opinion, design patterns are semantic. I remember rewriting some of my old apps using MVC just to make sure I understood the pattern as well as I thought I did. But, in the end, I didn't gain anything from MVC over my original code.

However, if I were to apply my original code to a larger development environment and tell someone that there is an issue with this certain method... it would be hard for that developer to track down the problem. HOWEVER, if I said tht the ContractController was mucked up for some reason, (s)he would know exactly where to start.

Design patterns are great... but like I said, I think they are semantic!

EDIT: You evangelist types crack me up. How did anything ever get developed without MVC (or some other design pattern)!

  • 2
    semantic (sɪˈmæntɪk) — adj 1. of or relating to meaning or arising from distinctions between the meanings of different words or symbols 2. of or relating to semantics (the study of meaning) 3. logic concerned with the interpretation of a formal theory, as when truth tables are given as an account of the sentential connectives – Robert Harvey Oct 11 '12 at 22:32
  • +1 - my point was that design patterns are simply a means of communication! – aserwin Oct 11 '12 at 22:35
  • Design patterns are more than just a way to communicate; they are concrete, well-understood recipes that can be implemented in software to solve certain, commonly encountered problems. – Robert Harvey Oct 11 '12 at 22:37
  • That is what the books say. But I have never actually solved a problem through a design pattern that I couldn't solve without it. The only advantage I have noticed in my own experience is an ability to speak to each other about the code! ;) – aserwin Oct 11 '12 at 22:40
  • 1
    Regarding your edit: So you'd prefer to re-invent the wheel each time you write a new bit of code? – Robert Harvey Oct 12 '12 at 5:48

Not the answer you're looking for? Browse other questions tagged or ask your own question.