13

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.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
Andrew
  • 240
  • 1
  • 6
  • 6
    Some of the GOF patterns are really just workarounds in OO languages for things that Functional Programming already provides. See http://stackoverflow.com/q/327955 – Robert Harvey Oct 02 '12 at 20:31
  • 2
    related: http://stackoverflow.com/q/89212 – tugs Oct 02 '12 at 22:15
  • 2
    Worth reading: [Are design patterns really essential nowadays?](http://programmers.stackexchange.com/q/70877/12917) – Martin York Oct 02 '12 at 22:28
  • I think there's a bit too much focus on GoF / OOP-specific patterns in this discussion. Can anyone post some actual functional programming-specific patterns (which don't just try to prove the triviality of GoF in functional languages)? – Daniel B Oct 12 '12 at 13:09

2 Answers2

3

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.

SK-logic
  • 8,497
  • 4
  • 25
  • 37
  • +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 http://programmers.stackexchange.com/questions/52608/what-is-object-oriented-programming-ill-suited-for/52618#52618 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
-3

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)!

aserwin
  • 161
  • 6
  • 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
  • Nobody argues that design patterns are the *only* way to solve the problems that they are designed to solve, just that they are effective at solving those problems. – Robert Harvey Oct 11 '12 at 22:42
  • Their effectiveness isn't in question (at least not by me), the question is AT WHAT are they effective? In my experience, as I have stated, the advantage is primarily as a means of enforcement, replacement for the coding standards we used to pass around, making it easier to communicate changes and upgrades. Again, this is simply my own experience. I am not master developer... Senior AT BEST. – aserwin Oct 11 '12 at 22:45
  • 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 05:48