I've been giving a lot of thought to frameworks and tempates lately, so 
I'll share my thoughts.  The goal of frameworks and templates, in my mind, 
is repeatable assembly.  Small, focused libraries don't get in the way of 
that design goal.  Frameworks and templates sit on top of the language.  
With a web framework, for example, two teams using the same framework will 
probably build a web application that will be very similar.  The problem, 
today, is that they won't be similar enough.  Even with frameworks we can 
still build wildly different code structures and come out with the same 
result.  That's how craftsmanship works, and we are in the age of 
craftsmanship in software.

Imaging you are at the vehicle junk yard, and you want to build a car.  You 
could take a bunch of parts from all over the yard and bolt them together 
and you might get it to work, but chances are it won't go anywhere.  You 
have a frame with a dashboard (console) and an engine (event generator), 
but they don't talk to each other.  What if the console could TELL the 
event generator what it wanted (ala erlang behaviors)?  What if the event 
handler could say, "Ah, I detect a console here that wants these two 
interfaces", and bang they start communicating.  Think of frameworks as the 
box of parts, and think of templates as the tool and die makers kit that 
sort of "punches out" the pieces in the correct configurations.  That's 
where I think we need to go.

Hope this helps.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Reply via email to