14 ms·

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 ca

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!
- Confusion 17y ago
  Not only can you talk in patterns, but your code can be written in patterns in a direct way. I have never bought this argument. What does it even mean? In every language, an implementation of a design pattern can be clearly distinguished as such. This is a good thing: it allows you to easily describe parts of of your application. This part produces objects, that part provides an interface to a bunch of other code, the other part determines which algorithm should currently be used, etc.
  - gord 17y ago
    Sure, it is a matter of degree - we could ask, how much extra crud is needed? I think lisp like languages have less crud, and so the idea is clearer. This is partly because lisps can act on their own expressions, transform them. This follows from extremely uniform or consistent grammar. Now you could say C++ can do that, but look at the amount of machinery needed in Boost to add something like a lambda or an accumulator 'pattern' to the language. Its a matter of degree - sure you can write a DSL in C++ [recursive descent, lex/yac, boost, macros etc] but in lisp this really is just a natural part of the language - syntactic sugar can be manufactured. Lets take the idea of a callback - this is an excellent design pattern that gives you a great deal of power. You could implement using function pointers in C, or say functor objects with operator() in C++... either way, I contend there is a lot more crud and boilerplate than there is in lisp where a lambda is a fundamental construct of the language. The more surrounding crud or machinery, the less clear the concept. In other words, patterns in lisp can be _more_ clearly distinguished as such, because there is less cruft. Often the name of the concept or pattern actually occurs in the code as a function name, for example.
    - axod 17y ago
      >> "I think lisp like languages have less crud, and so the idea is clearer." Part of being a good programmer is being able to see through crud. Personally, I don't really care about crud. It doesn't bother me. I think it's a good skill to learn to be able to recognize and understand code that's within a bowl of crud.

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!

Confusion 17y ago
Not only can you talk in patterns, but your code can be written in patterns in a direct way. I have never bought this argument. What does it even mean? In every language, an implementation of a design pattern can be clearly distinguished as such. This is a good thing: it allows you to easily describe parts of of your application. This part produces objects, that part provides an interface to a bunch of other code, the other part determines which algorithm should currently be used, etc.
- gord 17y ago
  Sure, it is a matter of degree - we could ask, how much extra crud is needed? I think lisp like languages have less crud, and so the idea is clearer. This is partly because lisps can act on their own expressions, transform them. This follows from extremely uniform or consistent grammar. Now you could say C++ can do that, but look at the amount of machinery needed in Boost to add something like a lambda or an accumulator 'pattern' to the language. Its a matter of degree - sure you can write a DSL in C++ [recursive descent, lex/yac, boost, macros etc] but in lisp this really is just a natural part of the language - syntactic sugar can be manufactured. Lets take the idea of a callback - this is an excellent design pattern that gives you a great deal of power. You could implement using function pointers in C, or say functor objects with operator() in C++... either way, I contend there is a lot more crud and boilerplate than there is in lisp where a lambda is a fundamental construct of the language. The more surrounding crud or machinery, the less clear the concept. In other words, patterns in lisp can be _more_ clearly distinguished as such, because there is less cruft. Often the name of the concept or pattern actually occurs in the code as a function name, for example.
  - axod 17y ago
    >> "I think lisp like languages have less crud, and so the idea is clearer." Part of being a good programmer is being able to see through crud. Personally, I don't really care about crud. It doesn't bother me. I think it's a good skill to learn to be able to recognize and understand code that's within a bowl of crud.