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