Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
5  
Some of the GOF patterns are really just workarounds in OO languages for things that Functional Programming already provides. See stackoverflow.com/q/327955 –  Robert Harvey Oct 2 '12 at 20:31
2  
related: stackoverflow.com/q/89212 –  tugs Oct 2 '12 at 22:15
2  
Worth reading: Are design patterns really essential nowadays? –  Loki Astari Oct 2 '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 Answers 2

up vote 3 down vote accepted

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.

share|improve this answer
    
+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)!

share|improve this answer
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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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