6 ms·

"Design Patterns are the disease, Clojure is the cure..."

38 points by swannodette 17y ago

crucini 17y ago
Like most language advocacy, this piece implicitly compares the beloved language to one other. In this case, Java. "Java sucks, so use language X!". Problem is, this argument works for many values of X. I think the elevator pitch for Clojure is more like: "Java libraries without Java verbosity". Or: "Lisp finally meets the real world". (I've played with Clojure, and found a startling contrast in seeing Java objects inside such a friendly, dynamic environment.)
- jrockway 17y ago
  My elevator pitch is, "A slow lisp without a real object system."
  - radu_floricica 17y ago
    I'd been half a decade since Java hasn't been considered slow, and in clojure when you really care about speed you can always go to java's level. As for what a real object system is... does this even mean anything?
    - stcredzero 17y ago
      I'd been half a decade since Java hasn't been considered slow This is precisely why snark doesn't work. Snark isn't based on substantive analysis and argument. Instead, it's the same sort of stuff that had lots of us geeks ostracized in high school. It's the hipster/school clique side of human dominance and group-think instincts. It's the reason why such inaccurate yet ineradicable notions continue to circulate in the programming field. If one considers oneself a thoughtful computer programming expert, leave out the snark!
  - Shooter 17y ago
    slow And yet you like Perl?! ;-)
    - jrockway 17y ago
      I do not like Perl for programs that need to execute quickly.
      - gaius 17y ago
        And if your bottleneck is I/O?
        jrockway 17y ago
        If the bottleneck is development time, I use Perl. It also works well in IO-bound apps. I don't want to say something like, "do you know who I am", but you maybe click the links in my profile before trying to convince me of Perl's merits :)
        gaius 17y ago
        I'm no great fan of Perl - yet in its niche, performance is not a reason not to use it.
  - swannodette 17y ago
    Slow compared to what? Most benchmarks I've seen show that it easily beats most of the other popular dynamic languages if you care about that. In my own experience with macro hackery you can often get very close to Java (2x-3x). The lack of an object system is a downright feature since it forces you to take a functional approach. Most of the things you would want from an object system (polymorphism, multiple inheritance) are readily available via multimethods/hierarchies. If you really want something CLOS-like, there's a library for that, http://code.google.com/p/explorersguild/wiki/XGModelAndGF http://code.google.com/p/explorersguild/wiki/XGModelAndGF.
    - jrockway 17y ago
      forces you to take a functional approach I don't think Clojure is really a functional langauge, it's more of an imperitive/OO mix with immutable objects. Immutable objects aren't "functional programming", they're simply common sense. Functional programming is about composing parts of programs ("functions") with generic combinators. I have not seen anyone in Clojure doing this. Haskell is a different story; combinators are very reusable, and there is no way to combine functions (and other "categories") without them. (In Clojure, you combine program fragments by typing a closing paren and then opening a new one. Your program doesn't control its sequence of operations, a Magical Runtime does that for you. Inflexible.) The reusability in Haskell is quite interesting; for example, application in a monad is defined as "liftM2 ($)", the usual function application operator ("($)", itself a function of two arguments) lifted into a monadic context for functions of two arguments. Cool. The reusability is everywhere; you use the same Arrow combinators to traverse an XML document as you do to parse plain text. (See HXT and PArrows.) And of course, you compose Arrows with (.) (the function composition function), because (.) works on all Categories, not just functions. That is functional programming; Clojure is just immutable data and parens. (Both good ideas, mind you. But it's not doing anything that Pure Java can't.)
      - weavejester 17y ago
        Your definition of "functional programming" is unusual. Wikipedia defines it as: "A programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data" Wikipedia goes on to consider Erlang and Scheme functional programming languages, so it would seem your definition of what consists a functional programming language is more narrow than the norm. Most people would consider Clojure to be a functional programming language, just not a pure functional programming language. I'm also not sure why you describe a language with macros as being "Inflexible". I've used Clojure and Haskell extensively, and Clojure wins on flexibility. It's a dynamically-typed Lisp, after all.
- radu_floricica 17y ago
  I think the shortest code example would be: button.addActionListener(new ActionListener() public void actionPerformed(ActionEvent e) { System.out.println("Button clicked"); }}); vs defining a two line function then writing: (add-action-listener button #(println "Button clicked")) Or maybe: (new Thread #(println "In thread"))
  - vicaya 17y ago
    Well, although the syntax/idiom is different, the design pattern is the same the Observer pattern. IMHO, design patterns transcend language idioms and enable people to understand/communicate higher level abstraction.
    - durin42 17y ago
      The difference to me has been that really great programming languages cause me to not notice my use of design patterns, because they become trivial. For example, Factories are basically nonexistent in idiomatic Python, because they're essentially free with the language.
    - mattrepl 17y ago
      As design patterns became popular in the world of statically typed, class-based OO languages that lacked first-class functions (C++, then Java and C#) there always seemed to be an emphasis on the implementation details, namely counterfeit function objects. The higher level abstraction aspects of a design pattern are usually better expressed without introducing codewords. E.g., the Observer pattern is just, "let's call a function on objects that want notification." It's the baggage that comes along with implementing these abstractions in blub that justifies a name as a pointer. Related to the above, design patterns connote boilerplate; all that generic code that's needed to setup the pattern in blub.
alrex021 17y ago
Design Patterns may be the "disease", but Clojure has nothing really to do with this, "the cure". Lisp has been the cure before the term Design Patterns even came into the CS vocabulary.
- swannodette 17y ago
  Agreed. I think other popular functional programming languages could fill in for Clojure here in regard to the criticism of Design Patterns. But Clojure has other niceties as well :)
- stcredzero 17y ago
  Design Patterns aren't like a disease so much as they're like a symptom!
  - sharkbrainguy 17y ago
    or perhaps it's more accurate to say that they are the pound of cure that an ounce of prevention obviates.
- gord 17y ago
  The move from mainstream OO, cast in a mediocre language like C++ or Java, to having some way to talk about higher level combinations [which the language cannot express] is quite an improvement. After a positive experience with GoF patterns its hard to convince people that these patterns are just a natural part of working in lisp [or clojure] : Not only can you talk in patterns, but your code can be written in patterns in a direct way. The same of UML and other formal diagramming systems - you get more expressive power much more directly via a 'domain specific language' in lisp. All the big fads are subsumed with a wave of the hand. Unfortunately some universities take what they think is a pragmatic path of least resistance and teach popular languages such as Java in place of a much more subtle and powerful language. I wonder at the sheer human waste in leagues of emasculated coders churning out verbose Java/XML/SQL 'business' apps in cubicles, forced by convention to work in an ugly way - those businesses would be much better served in terms of efficiency, quality and innovation by using a good language, and their staff much happier. Thank Gods and the lords of Kobol for giving us Python, Ruby and Clojure that they might seep through the cracks and weaken the stranglehold of obfuscation and verbosity!
vsync 17y ago
Posted this on the article's comments: I have been following Clojure with some interest lately. I'm still a Common Lisp guy though because Clojure is still in flux and evolving rapidly from what I see. I also see the fact that all Clojure programs are Java programs as a plus and a minus: a plus because you get access to all the Java libraries and JITs and whatnot out there, but a minus because there can't be any independent Clojure port. In the real world to make an interesting port of Clojure you will also have to port all of Java so applications work. It's like if no one wrote Unix/Linux applications but only Windows and counted on Wine always being there. With regard to state -- and Paul Barry already touched on this -- I recently started implementing a small app which needs some persistent state. I thought to try doing it in Clojure but found out that while Common Lisp has tools like Rucksack and Elephant and CLSQL, if I wanted it in Clojure I would need first to create all my data structures as Java objects (albeit with (. blahblah) wrappers if I wanted) then run them through some clumsy Java ORM, or deal with raw JDBC or Java Berkeley DB. If I missed something that's already out there and available I would love to be pointed to it, but it seems to me Clojure could benefit from a native persistence mechanism or library that takes advantage of its concurrency strengths, or at least a native API for something like Berkeley DB that can deal well with it.
- ericlavigne 17y ago
  There is a Berkeley DB wrapper for Clojure. I haven't tried it yet, but it looks like the nicest Clojure persistence library I've seen so far. http://github.com/gcv/cupboard http://github.com/gcv/cupboard
- tcc619 17y ago
  "but a minus because there can't be any independent Clojure port" there's work on a clojure port on the CLR, u can check out more on the clojure website or the github project page.
- cemerick 17y ago
  The ongoing work of making clojure self-hosting will make the CLR port easier, and make things like a Obj-C, LLVM, etc., port possible.
brown9-2 17y ago
Can anyone link me to (or provide themselves) a comparison of Clojure to Groovy? I might regret admitting it but functional/dynamic programming is new to me, but I'd love to learn more about it. Groovy and Clojure sound pretty similar to me, minus the Lisp part, so I'm curious what some of the other major differences are.
- holygoat 17y ago
  http://stackoverflow.com/questions/1314732/scala-vs-groovy-vs-clojure http://stackoverflow.com/questions/1314732/scala-vs-groovy-v... From what I've read, Groovy is monstrously slow. That alone should rule it out.
  - regularfry 17y ago
    You'd think it would rule Ruby out as well, but no...
xtho 17y ago
A pointless self-promotion that lacks any arguments and explanations etc. Catchy title though.
joe_the_user 17y ago
It would have been nice if the link named "sample code" linked, to, uh, code rather than a git hub node that one might extract some code from, in maybe fifteen minutes. All the other links seemed to be announcements for the guy speaking and article itself had no real meat. Show me some code does something hard easily and something easy, easily. And don't make have it be factorial, I know functional programming can do factorial.
- gord 17y ago
  I put my hand on my heart and tell you, after programming for 15 years in C and C++ on windows and linux, I am happy to throw it away after seeing how much better the same things can be done in 'lispy' languages [scheme, clojure, ruby] Have a look at PGs 'on-lisp', 'the little schemer', the SICP book + video lectures, or 'practical common lisp' - they have example after example - finding fixed points, data query language, numerical approximations, symbolic algebra, pattern matching, logic languages, momoizing all expressed very clearly. An excellent article you might enjoy is 'Functional Programming for the Rest of Us' : http://www.defmacro.org/ramblings/fp.html http://www.defmacro.org/ramblings/fp.html [by a YC alumni, Slava]
jister 17y ago
Everything has its place in software development, may it be closure or design patterns.

38 points by swannodette 17y ago

Like most language advocacy, this piece implicitly compares the beloved language to one other. In this case, Java. "Java sucks, so use language X!". Problem is, this argument works for many values of X. I think the elevator pitch for Clojure is more like: "Java libraries without Java verbosity". Or: "Lisp finally meets the real world". (I've played with Clojure, and found a startling contrast in seeing Java objects inside such a friendly, dynamic environment.)

jrockway 17y ago
My elevator pitch is, "A slow lisp without a real object system."
- radu_floricica 17y ago
  I'd been half a decade since Java hasn't been considered slow, and in clojure when you really care about speed you can always go to java's level. As for what a real object system is... does this even mean anything?
  - stcredzero 17y ago
    I'd been half a decade since Java hasn't been considered slow This is precisely why snark doesn't work. Snark isn't based on substantive analysis and argument. Instead, it's the same sort of stuff that had lots of us geeks ostracized in high school. It's the hipster/school clique side of human dominance and group-think instincts. It's the reason why such inaccurate yet ineradicable notions continue to circulate in the programming field. If one considers oneself a thoughtful computer programming expert, leave out the snark!
- Shooter 17y ago
  slow And yet you like Perl?! ;-)
  - jrockway 17y ago
    I do not like Perl for programs that need to execute quickly.
    - gaius 17y ago
      And if your bottleneck is I/O?
      - jrockway 17y ago
        If the bottleneck is development time, I use Perl. It also works well in IO-bound apps. I don't want to say something like, "do you know who I am", but you maybe click the links in my profile before trying to convince me of Perl's merits :)
        gaius 17y ago
        I'm no great fan of Perl - yet in its niche, performance is not a reason not to use it.
- swannodette 17y ago
  Slow compared to what? Most benchmarks I've seen show that it easily beats most of the other popular dynamic languages if you care about that. In my own experience with macro hackery you can often get very close to Java (2x-3x). The lack of an object system is a downright feature since it forces you to take a functional approach. Most of the things you would want from an object system (polymorphism, multiple inheritance) are readily available via multimethods/hierarchies. If you really want something CLOS-like, there's a library for that, http://code.google.com/p/explorersguild/wiki/XGModelAndGF http://code.google.com/p/explorersguild/wiki/XGModelAndGF.
  - jrockway 17y ago
    forces you to take a functional approach I don't think Clojure is really a functional langauge, it's more of an imperitive/OO mix with immutable objects. Immutable objects aren't "functional programming", they're simply common sense. Functional programming is about composing parts of programs ("functions") with generic combinators. I have not seen anyone in Clojure doing this. Haskell is a different story; combinators are very reusable, and there is no way to combine functions (and other "categories") without them. (In Clojure, you combine program fragments by typing a closing paren and then opening a new one. Your program doesn't control its sequence of operations, a Magical Runtime does that for you. Inflexible.) The reusability in Haskell is quite interesting; for example, application in a monad is defined as "liftM2 ($)", the usual function application operator ("($)", itself a function of two arguments) lifted into a monadic context for functions of two arguments. Cool. The reusability is everywhere; you use the same Arrow combinators to traverse an XML document as you do to parse plain text. (See HXT and PArrows.) And of course, you compose Arrows with (.) (the function composition function), because (.) works on all Categories, not just functions. That is functional programming; Clojure is just immutable data and parens. (Both good ideas, mind you. But it's not doing anything that Pure Java can't.)
    - weavejester 17y ago
      Your definition of "functional programming" is unusual. Wikipedia defines it as: "A programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data" Wikipedia goes on to consider Erlang and Scheme functional programming languages, so it would seem your definition of what consists a functional programming language is more narrow than the norm. Most people would consider Clojure to be a functional programming language, just not a pure functional programming language. I'm also not sure why you describe a language with macros as being "Inflexible". I've used Clojure and Haskell extensively, and Clojure wins on flexibility. It's a dynamically-typed Lisp, after all.
radu_floricica 17y ago
I think the shortest code example would be: button.addActionListener(new ActionListener() public void actionPerformed(ActionEvent e) { System.out.println("Button clicked"); }}); vs defining a two line function then writing: (add-action-listener button #(println "Button clicked")) Or maybe: (new Thread #(println "In thread"))
- vicaya 17y ago
  Well, although the syntax/idiom is different, the design pattern is the same the Observer pattern. IMHO, design patterns transcend language idioms and enable people to understand/communicate higher level abstraction.
  - durin42 17y ago
    The difference to me has been that really great programming languages cause me to not notice my use of design patterns, because they become trivial. For example, Factories are basically nonexistent in idiomatic Python, because they're essentially free with the language.
  - mattrepl 17y ago
    As design patterns became popular in the world of statically typed, class-based OO languages that lacked first-class functions (C++, then Java and C#) there always seemed to be an emphasis on the implementation details, namely counterfeit function objects. The higher level abstraction aspects of a design pattern are usually better expressed without introducing codewords. E.g., the Observer pattern is just, "let's call a function on objects that want notification." It's the baggage that comes along with implementing these abstractions in blub that justifies a name as a pointer. Related to the above, design patterns connote boilerplate; all that generic code that's needed to setup the pattern in blub.

alrex021 17y ago

Design Patterns may be the "disease", but Clojure has nothing really to do with this, "the cure". Lisp has been the cure before the term Design Patterns even came into the CS vocabulary.

swannodette 17y ago
Agreed. I think other popular functional programming languages could fill in for Clojure here in regard to the criticism of Design Patterns. But Clojure has other niceties as well :)
stcredzero 17y ago
Design Patterns aren't like a disease so much as they're like a symptom!
- sharkbrainguy 17y ago
  or perhaps it's more accurate to say that they are the pound of cure that an ounce of prevention obviates.
gord 17y ago
The move from mainstream OO, cast in a mediocre language like C++ or Java, to having some way to talk about higher level combinations [which the language cannot express] is quite an improvement. After a positive experience with GoF patterns its hard to convince people that these patterns are just a natural part of working in lisp [or clojure] : Not only can you talk in patterns, but your code can be written in patterns in a direct way. The same of UML and other formal diagramming systems - you get more expressive power much more directly via a 'domain specific language' in lisp. All the big fads are subsumed with a wave of the hand. Unfortunately some universities take what they think is a pragmatic path of least resistance and teach popular languages such as Java in place of a much more subtle and powerful language. I wonder at the sheer human waste in leagues of emasculated coders churning out verbose Java/XML/SQL 'business' apps in cubicles, forced by convention to work in an ugly way - those businesses would be much better served in terms of efficiency, quality and innovation by using a good language, and their staff much happier. Thank Gods and the lords of Kobol for giving us Python, Ruby and Clojure that they might seep through the cracks and weaken the stranglehold of obfuscation and verbosity!

vsync 17y ago

Posted this on the article's comments: I have been following Clojure with some interest lately. I'm still a Common Lisp guy though because Clojure is still in flux and evolving rapidly from what I see. I also see the fact that all Clojure programs are Java programs as a plus and a minus: a plus because you get access to all the Java libraries and JITs and whatnot out there, but a minus because there can't be any independent Clojure port. In the real world to make an interesting port of Clojure you will also have to port all of Java so applications work. It's like if no one wrote Unix/Linux applications but only Windows and counted on Wine always being there. With regard to state -- and Paul Barry already touched on this -- I recently started implementing a small app which needs some persistent state. I thought to try doing it in Clojure but found out that while Common Lisp has tools like Rucksack and Elephant and CLSQL, if I wanted it in Clojure I would need first to create all my data structures as Java objects (albeit with (. blahblah) wrappers if I wanted) then run them through some clumsy Java ORM, or deal with raw JDBC or Java Berkeley DB. If I missed something that's already out there and available I would love to be pointed to it, but it seems to me Clojure could benefit from a native persistence mechanism or library that takes advantage of its concurrency strengths, or at least a native API for something like Berkeley DB that can deal well with it.

ericlavigne 17y ago
There is a Berkeley DB wrapper for Clojure. I haven't tried it yet, but it looks like the nicest Clojure persistence library I've seen so far. http://github.com/gcv/cupboard http://github.com/gcv/cupboard
tcc619 17y ago
"but a minus because there can't be any independent Clojure port" there's work on a clojure port on the CLR, u can check out more on the clojure website or the github project page.
cemerick 17y ago
The ongoing work of making clojure self-hosting will make the CLR port easier, and make things like a Obj-C, LLVM, etc., port possible.

brown9-2 17y ago

Can anyone link me to (or provide themselves) a comparison of Clojure to Groovy? I might regret admitting it but functional/dynamic programming is new to me, but I'd love to learn more about it. Groovy and Clojure sound pretty similar to me, minus the Lisp part, so I'm curious what some of the other major differences are.

holygoat 17y ago
http://stackoverflow.com/questions/1314732/scala-vs-groovy-vs-clojure http://stackoverflow.com/questions/1314732/scala-vs-groovy-v... From what I've read, Groovy is monstrously slow. That alone should rule it out.
- regularfry 17y ago
  You'd think it would rule Ruby out as well, but no...

xtho 17y ago

A pointless self-promotion that lacks any arguments and explanations etc. Catchy title though.

joe_the_user 17y ago

It would have been nice if the link named "sample code" linked, to, uh, code rather than a git hub node that one might extract some code from, in maybe fifteen minutes. All the other links seemed to be announcements for the guy speaking and article itself had no real meat. Show me some code does something hard easily and something easy, easily. And don't make have it be factorial, I know functional programming can do factorial.

gord 17y ago
I put my hand on my heart and tell you, after programming for 15 years in C and C++ on windows and linux, I am happy to throw it away after seeing how much better the same things can be done in 'lispy' languages [scheme, clojure, ruby] Have a look at PGs 'on-lisp', 'the little schemer', the SICP book + video lectures, or 'practical common lisp' - they have example after example - finding fixed points, data query language, numerical approximations, symbolic algebra, pattern matching, logic languages, momoizing all expressed very clearly. An excellent article you might enjoy is 'Functional Programming for the Rest of Us' : http://www.defmacro.org/ramblings/fp.html http://www.defmacro.org/ramblings/fp.html [by a YC alumni, Slava]

jister 17y ago

Everything has its place in software development, may it be closure or design patterns.