librelist archives

« back to archive

Design Patterns & Clojure

Design Patterns & Clojure

From:
Sean Chalmers
Date:
2013-06-13 @ 00:52
wall of text incoming !

Greetings...

We've just had a couple of emails go around at work regarding "Design
Patterns In Javascript" and looking through them it all seems rather
daunting as there are hundreds of different patterns available.

What I found interesting is that whilst design patterns seem to come up
frequently when doing JavaScript development of any appreciable scale, I've
not encountered a whisper of it in Clojure land. Even when reading up on
peoples reports on using Clojure in large scale or enterprise applications.

Is this sort of a by-product of the sort of loosey-goosey nature of
JavaScript compared to almost structured-by-the-act-of-creation aspect of
Clojure?

Since from what I've seen Clojure applications don't really subscribe to
patterns and more just evolve into the required design simply because of
how the language works and how it supports your application growing into a
domain specific language built to solve your issue.

Idle thoughts and pretty off the cuff so I'm sorry if I'm not being
terribly clear, but just wondering if anyone had any thoughts or had
encountered something similar with respect to how their
Clojure/ClojureScript apps have evolved compared to other languages...

Re: [foray] Design Patterns & Clojure

From:
Gary Deer
Date:
2013-06-13 @ 01:15
Stuart Sierra did a talk on functional design patterns
http://www.infoq.com/presentations/Clojure-Design-Patterns

He mentions that you have architecture patterns, design patterns, and
idioms.
My own observation is that Clojure allows you to compose smaller well
defined pieces, so if your pieces are idiomatic, then composing them is a
lot easier and you don't have to think about design patterns until they're
appropriate.

That's why my journey with Clojure started with replacing my loops and
iterators with reducers, etc.  (actually to be honest it started with
trying to write java in Clojure, but that ended very quickly)


On Wed, Jun 12, 2013 at 7:52 PM, Sean Chalmers <sclhiannan@gmail.com> wrote:

> wall of text incoming !
>
> Greetings...
>
> We've just had a couple of emails go around at work regarding "Design
> Patterns In Javascript" and looking through them it all seems rather
> daunting as there are hundreds of different patterns available.
>
> What I found interesting is that whilst design patterns seem to come up
> frequently when doing JavaScript development of any appreciable scale, I've
> not encountered a whisper of it in Clojure land. Even when reading up on
> peoples reports on using Clojure in large scale or enterprise applications.
>
> Is this sort of a by-product of the sort of loosey-goosey nature of
> JavaScript compared to almost structured-by-the-act-of-creation aspect of
> Clojure?
>
> Since from what I've seen Clojure applications don't really subscribe to
> patterns and more just evolve into the required design simply because of
> how the language works and how it supports your application growing into a
> domain specific language built to solve your issue.
>
> Idle thoughts and pretty off the cuff so I'm sorry if I'm not being
> terribly clear, but just wondering if anyone had any thoughts or had
> encountered something similar with respect to how their
> Clojure/ClojureScript apps have evolved compared to other languages...
>

Re: [foray] Design Patterns & Clojure

From:
Sean Corfield
Date:
2013-06-13 @ 01:16
On Jun 12, 2013, at 5:52 PM, Sean Chalmers wrote:
> Is this sort of a by-product of the sort of loosey-goosey nature of 
JavaScript compared to almost structured-by-the-act-of-creation aspect of 
Clojure?

It's more because many design patterns - esp. those from the OOP world - 
are either not needed in a functional language or they are implicit in the
typical program constructs already.

That's not to say there are _no_ design patterns used in functional 
programming - there are several but they tend to be very different where 
they are even observable at all.

Consider the classic "Design Patterns" book (a.k.a. "Gang of Four") and 
you'll see it has several "Creational Patterns" which are all OO-specific,
several "Structural Patterns" which are mostly OO-specific, and a longer 
list of "Behavioral Patterns" which are mostly replaced by higher order 
function usage in a functional language.

Several behavioral patterns are handled implicitly by function composition
or by abstracting different behavior (across several functions) into 
smaller functions that would be passed as arguments to a generic function 
instead.

The reason the patterns have evolved and been documented in OO code is 
because you have to construct specific organizations of collaborating 
objects to get around the fact that functions are not first class citizens
in most OO languages.

Does that help?

Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)



Re: [foray] Design Patterns & Clojure

From:
Sean Chalmers
Date:
2013-06-13 @ 02:01
Thanks everyone! Nice to know I'm not completely crazy. :)

I didn't think Clojure was entirely without patterns or reliable structures
but from my experience thus far it seemed to require less deliberate action
on the part of writing the code aside from generally 'thinking
functionally' and creating suitably sized and testable pieces that are then
composed into a large collaboration of moving parts. When compared to, at
least what it appeared to be, a process of:

1) Is there a pattern applicable to what I'm doing?
2) How well does this pattern fit my needs?
3) Does my application flow / data support this sort of pattern?
4) Should I change one of the former to suit the pattern or the pattern to
suit the former?
5) Write everything involved to make the pattern work
6) Am I debugging my pattern implementation or my applications
functionality?
7) Wash - rinse - repeat...

I'll have to check that presentation out too, ta for that. :)

Probably something more suited to a blog post, but thanks a heap for the
discussion! :D


On 13 June 2013 11:16, Sean Corfield <sean@corfield.org> wrote:

> On Jun 12, 2013, at 5:52 PM, Sean Chalmers wrote:
> > Is this sort of a by-product of the sort of loosey-goosey nature of
> JavaScript compared to almost structured-by-the-act-of-creation aspect of
> Clojure?
>
> It's more because many design patterns - esp. those from the OOP world -
> are either not needed in a functional language or they are implicit in the
> typical program constructs already.
>
> That's not to say there are _no_ design patterns used in functional
> programming - there are several but they tend to be very different where
> they are even observable at all.
>
> Consider the classic "Design Patterns" book (a.k.a. "Gang of Four") and
> you'll see it has several "Creational Patterns" which are all OO-specific,
> several "Structural Patterns" which are mostly OO-specific, and a longer
> list of "Behavioral Patterns" which are mostly replaced by higher order
> function usage in a functional language.
>
> Several behavioral patterns are handled implicitly by function composition
> or by abstracting different behavior (across several functions) into
> smaller functions that would be passed as arguments to a generic function
> instead.
>
> The reason the patterns have evolved and been documented in OO code is
> because you have to construct specific organizations of collaborating
> objects to get around the fact that functions are not first class citizens
> in most OO languages.
>
> Does that help?
>
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
>
>
>
>

Re: [foray] Design Patterns & Clojure

From:
Gary Deer
Date:
2013-06-13 @ 02:31
Since most of my Java code is lost in the abyss of Spring or ATG,
Dependency Injection is near and dear to my heart. Programming to
interfaces, decoupling classes from the classes they depend on...awesome
stuff.  In my shop DI is like tobasco sauce, we put that stuff on
everything.  But then I read page 460 of "Clojure Programming" and it blew
my mind.


On Wed, Jun 12, 2013 at 9:01 PM, Sean Chalmers <sclhiannan@gmail.com> wrote:

> Thanks everyone! Nice to know I'm not completely crazy. :)
>
> I didn't think Clojure was entirely without patterns or reliable
> structures but from my experience thus far it seemed to require less
> deliberate action on the part of writing the code aside from generally
> 'thinking functionally' and creating suitably sized and testable pieces
> that are then composed into a large collaboration of moving parts. When
> compared to, at least what it appeared to be, a process of:
>
> 1) Is there a pattern applicable to what I'm doing?
> 2) How well does this pattern fit my needs?
> 3) Does my application flow / data support this sort of pattern?
> 4) Should I change one of the former to suit the pattern or the pattern to
> suit the former?
> 5) Write everything involved to make the pattern work
> 6) Am I debugging my pattern implementation or my applications
> functionality?
> 7) Wash - rinse - repeat...
>
> I'll have to check that presentation out too, ta for that. :)
>
> Probably something more suited to a blog post, but thanks a heap for the
> discussion! :D
>
>
> On 13 June 2013 11:16, Sean Corfield <sean@corfield.org> wrote:
>
>> On Jun 12, 2013, at 5:52 PM, Sean Chalmers wrote:
>> > Is this sort of a by-product of the sort of loosey-goosey nature of
>> JavaScript compared to almost structured-by-the-act-of-creation aspect of
>> Clojure?
>>
>> It's more because many design patterns - esp. those from the OOP world -
>> are either not needed in a functional language or they are implicit in the
>> typical program constructs already.
>>
>> That's not to say there are _no_ design patterns used in functional
>> programming - there are several but they tend to be very different where
>> they are even observable at all.
>>
>> Consider the classic "Design Patterns" book (a.k.a. "Gang of Four") and
>> you'll see it has several "Creational Patterns" which are all OO-specific,
>> several "Structural Patterns" which are mostly OO-specific, and a longer
>> list of "Behavioral Patterns" which are mostly replaced by higher order
>> function usage in a functional language.
>>
>> Several behavioral patterns are handled implicitly by function
>> composition or by abstracting different behavior (across several functions)
>> into smaller functions that would be passed as arguments to a generic
>> function instead.
>>
>> The reason the patterns have evolved and been documented in OO code is
>> because you have to construct specific organizations of collaborating
>> objects to get around the fact that functions are not first class citizens
>> in most OO languages.
>>
>> Does that help?
>>
>> Sean A Corfield -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>>
>> "Perfection is the enemy of the good."
>> -- Gustave Flaubert, French realist novelist (1821-1880)
>>
>>
>>
>>
>>
>

Re: [foray] Design Patterns & Clojure

From:
Sean Corfield
Date:
2013-06-13 @ 02:49
On Jun 12, 2013, at 7:31 PM, Gary Deer wrote:
> Since most of my Java code is lost in the abyss of Spring or ATG, 
Dependency Injection is near and dear to my heart. Programming to 
interfaces, decoupling classes from the classes they depend on...awesome 
stuff.  In my shop DI is like tobasco sauce, we put that stuff on 
everything.  But then I read page 460 of "Clojure Programming" and it blew
my mind.

Yeah, Chapter 12 of Clojure Programming is a good example of how OO design
patterns are often irrelevant or trivial in a functional language. I'm not
sure I really agree with their example for DI because defprotocol is much 
more about programming to an interface. Because you're removing objects 
from the picture pretty much completely, DI simply ceases to be a concern:
there is no object construction graph to resolve; there are no objects to 
instantiate and initialize.

The power of protocols takes a while to really "grok" because you can 
define a protocol for some aspect of your code, along with a default 
implementation or two, and then anyone else can come along later and 
extend your protocol to cover their own types - or even existing Java 
(class) types from other libraries. A good example of this is something 
that was recently added to clojure.java.jdbc: a protocol for reading 
column data out of a result set object (Java). The default implementation 
does no translation, but it's easy for any user to extend that protocol to
some DB-specific type to perform a conversion automatically, e.g., Oracle 
timestamp, Postgres binary arrays - stuff that clojure.java.jdbc neither 
needs to know nor care about.

At World Singles we have a protocol for converting various date times to a
specific epoch-based number of days:

;; our internal epoch is based off January 1st, 2000:
(def ^:private epoch-joda (date-time 2000 1 1)) ; Joda Time instance

(def epoch (to-date epoch-joda)) ; java.util.Date instance

(defn joda-when-days
  "Given datetime as clj-time/date-time,
   return a number of days since epoch (i.e. 1/1/2000)."
  [when-time]
  (-> (interval epoch-joda when-time)
      (in-days)))

(defprotocol DaysSinceEpoch
  "Conversion from date/time to days since our application's epoch."
  (when-days [this] "Returns the number of days since January 1st, 2000"))

(extend-protocol DaysSinceEpoch
  org.joda.time.DateTime
  (when-days [this] (joda-when-days this))
  
  org.joda.time.DateMidnight
  (when-days [this] (joda-when-days this))

  org.joda.time.LocalDateTime
  (when-days [this] (joda-when-days this))

  java.util.Date
  (when-days [this] (joda-when-days (from-date this))))

This allows us to call (when-days some-date-object) and have it 
automatically perform the correct conversion - and we can extend it to any
future date formats we run across.

Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)



Re: [foray] Design Patterns & Clojure

From:
Fumiko Hanreich
Date:
2013-06-13 @ 05:39
Though I'm unable to add anything new to help, let me just say how thankful
I am for this thread Sean (Chalmers) started and its subsequent responses.
You bet I'm going to watch that link.  I'm not sure if I can understand
everything the first time, but so far, my journey with clojure has been
beautiful.  So, I know I will figure out / learn good patterns and
frameworks in clojure one day.
Thank you so much for the contributors to my most favorite thread :)

Fumiko


On Wed, Jun 12, 2013 at 7:01 PM, Sean Chalmers <sclhiannan@gmail.com> wrote:

> Thanks everyone! Nice to know I'm not completely crazy. :)
>
> I didn't think Clojure was entirely without patterns or reliable
> structures but from my experience thus far it seemed to require less
> deliberate action on the part of writing the code aside from generally
> 'thinking functionally' and creating suitably sized and testable pieces
> that are then composed into a large collaboration of moving parts. When
> compared to, at least what it appeared to be, a process of:
>
> 1) Is there a pattern applicable to what I'm doing?
> 2) How well does this pattern fit my needs?
> 3) Does my application flow / data support this sort of pattern?
> 4) Should I change one of the former to suit the pattern or the pattern to
> suit the former?
> 5) Write everything involved to make the pattern work
> 6) Am I debugging my pattern implementation or my applications
> functionality?
> 7) Wash - rinse - repeat...
>
> I'll have to check that presentation out too, ta for that. :)
>
> Probably something more suited to a blog post, but thanks a heap for the
> discussion! :D
>
>
> On 13 June 2013 11:16, Sean Corfield <sean@corfield.org> wrote:
>
>> On Jun 12, 2013, at 5:52 PM, Sean Chalmers wrote:
>> > Is this sort of a by-product of the sort of loosey-goosey nature of
>> JavaScript compared to almost structured-by-the-act-of-creation aspect of
>> Clojure?
>>
>> It's more because many design patterns - esp. those from the OOP world -
>> are either not needed in a functional language or they are implicit in the
>> typical program constructs already.
>>
>> That's not to say there are _no_ design patterns used in functional
>> programming - there are several but they tend to be very different where
>> they are even observable at all.
>>
>> Consider the classic "Design Patterns" book (a.k.a. "Gang of Four") and
>> you'll see it has several "Creational Patterns" which are all OO-specific,
>> several "Structural Patterns" which are mostly OO-specific, and a longer
>> list of "Behavioral Patterns" which are mostly replaced by higher order
>> function usage in a functional language.
>>
>> Several behavioral patterns are handled implicitly by function
>> composition or by abstracting different behavior (across several functions)
>> into smaller functions that would be passed as arguments to a generic
>> function instead.
>>
>> The reason the patterns have evolved and been documented in OO code is
>> because you have to construct specific organizations of collaborating
>> objects to get around the fact that functions are not first class citizens
>> in most OO languages.
>>
>> Does that help?
>>
>> Sean A Corfield -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>>
>> "Perfection is the enemy of the good."
>> -- Gustave Flaubert, French realist novelist (1821-1880)
>>
>>
>>
>>
>>
>

Re: [foray] Design Patterns & Clojure

From:
Sean Chalmers
Date:
2013-06-13 @ 06:02
Uni is almost over for the semester... and then... all the Clojure... :D
(and probably some Haskell, because I'm a John Carmack fan boy)


On 13 June 2013 15:39, Fumiko Hanreich <fhanreich@gmail.com> wrote:

> Though I'm unable to add anything new to help, let me just say how
> thankful I am for this thread Sean (Chalmers) started and its subsequent
> responses.  You bet I'm going to watch that link.  I'm not sure if I can
> understand everything the first time, but so far, my journey with clojure
> has been beautiful.  So, I know I will figure out / learn good patterns and
> frameworks in clojure one day.
> Thank you so much for the contributors to my most favorite thread :)
>
> Fumiko
>
>
> On Wed, Jun 12, 2013 at 7:01 PM, Sean Chalmers <sclhiannan@gmail.com>wrote:
>
>> Thanks everyone! Nice to know I'm not completely crazy. :)
>>
>> I didn't think Clojure was entirely without patterns or reliable
>> structures but from my experience thus far it seemed to require less
>> deliberate action on the part of writing the code aside from generally
>> 'thinking functionally' and creating suitably sized and testable pieces
>> that are then composed into a large collaboration of moving parts. When
>> compared to, at least what it appeared to be, a process of:
>>
>> 1) Is there a pattern applicable to what I'm doing?
>> 2) How well does this pattern fit my needs?
>> 3) Does my application flow / data support this sort of pattern?
>> 4) Should I change one of the former to suit the pattern or the pattern
>> to suit the former?
>> 5) Write everything involved to make the pattern work
>> 6) Am I debugging my pattern implementation or my applications
>> functionality?
>> 7) Wash - rinse - repeat...
>>
>> I'll have to check that presentation out too, ta for that. :)
>>
>> Probably something more suited to a blog post, but thanks a heap for the
>> discussion! :D
>>
>>
>> On 13 June 2013 11:16, Sean Corfield <sean@corfield.org> wrote:
>>
>>> On Jun 12, 2013, at 5:52 PM, Sean Chalmers wrote:
>>> > Is this sort of a by-product of the sort of loosey-goosey nature of
>>> JavaScript compared to almost structured-by-the-act-of-creation aspect of
>>> Clojure?
>>>
>>> It's more because many design patterns - esp. those from the OOP world -
>>> are either not needed in a functional language or they are implicit in the
>>> typical program constructs already.
>>>
>>> That's not to say there are _no_ design patterns used in functional
>>> programming - there are several but they tend to be very different where
>>> they are even observable at all.
>>>
>>> Consider the classic "Design Patterns" book (a.k.a. "Gang of Four") and
>>> you'll see it has several "Creational Patterns" which are all OO-specific,
>>> several "Structural Patterns" which are mostly OO-specific, and a longer
>>> list of "Behavioral Patterns" which are mostly replaced by higher order
>>> function usage in a functional language.
>>>
>>> Several behavioral patterns are handled implicitly by function
>>> composition or by abstracting different behavior (across several functions)
>>> into smaller functions that would be passed as arguments to a generic
>>> function instead.
>>>
>>> The reason the patterns have evolved and been documented in OO code is
>>> because you have to construct specific organizations of collaborating
>>> objects to get around the fact that functions are not first class citizens
>>> in most OO languages.
>>>
>>> Does that help?
>>>
>>> Sean A Corfield -- (904) 302-SEAN
>>> An Architect's View -- http://corfield.org/
>>>
>>> "Perfection is the enemy of the good."
>>> -- Gustave Flaubert, French realist novelist (1821-1880)
>>>
>>>
>>>
>>>
>>>
>>
>