Il giorno giovedì 14 novembre 2013 17:22:03 UTC+1, Brian Craft ha scritto: > > > > On Thursday, November 14, 2013 2:28:51 AM UTC-8, Sean Johnson wrote: >> >> Framework vs. ecosystem of interoperable libraries. The monolithic >> framework (see Rails and Django) is not the way web development is done in >> Clojure. Instead imagine the Clojure world as a set of legos. You get to >> build whatever you want with your legos, selecting just the blocks you >> need, in the colors and sizes you want, and they all snap together [1]. The >> benefit to this approach is simplicity. There is a LOT to know about the >> Rails and Django frameworks, as they are big, mature things that have grown >> to solve all the common web development needs, and you start your >> development with ALL of that framework. Your starting point with Clojure on >> the other hand is much simpler. It will seem too simple... at first you'll >> be wondering... where is all the "stuff"? You start with maybe just ring >> and compojure (web middleware and routing) and a few lines of your code and >> your first couple of stories are already complete. You add libraries as you >> find you need them as you build out your app over time, but at all times >> your app is as simple as it can be, and only has the "stuff" it needs. It's >> therefore much easier to understand and less a "big ball of mud". >> > > I don't believe the legos analogy is very accurate for clojure. Or, > rather, it's more of a vision than a reality. I'm unaware of any libraries > in clojure that you can piece together to give you the features of > django-south, django admin, and the forms/validation/db layers, for > example. Today, clojure web libraries are more like an auto parts store: > your chance of putting together a complete car from the inventory is slim > indeed, and your chance of doing it in a timely fashion is exactly zero. > There are about a dozen migration libraries for clojure, for example, but > none of them integrate very well with the other libraries because there > isn't much in the way of a data modeling framework for the different > components to leverage. Also, I don't think any of them provide the > simplicity of south, where your data model is declared in one place (rather > than in a sequence of sql commands that you have to interpret to deduce the > final data model), and migrations are derived from changes in the data > model. > > The putting of things together is the hard part of software engineering. This > makes a huge difference in development time. Clean algorithms are easy > in comparison. Rich talks about the importance of taking things apart, but > you can't take things apart that never fit together in the first place. > IIRC he actually suggested that one take things apart such that they fit > together again. I agree with this, but I don't think it describes much of > clojure web tooling today. > > Also, the overwhelming majority of db and web work is boilerplate. That's > what django provides: all the mindless boilerplate that is completely > uninteresting to your problem domain, but necessary to launch a web site. > With the current clojure web tools, there is no solution for most of that > boilerplate, which can easily add an order of magnitude to your development > time. > > And again, I will have to reevaluate all of this in light of caribou, > which appears to address much of it. Also, I'd be very happy to hear that > I'm wrong, if anyone has example projects to show, or libraries I've missed. >
Indeed, Caribou seems to fit quite nicely in all this: the data model is first class, and gives you at good amount of ready-made wiring and boilerplate code. Same thing (to a maybe lesser degree) does Luminus<http://www.luminusweb.net/>. I agree that taking things apart is a win, working with simple things gives you a lot of power and flexibility. On the other hand there is a tension between use and reuse. However it doesn't mean that you can *only* work with simple components. I think that the approach taken by Luminus (and maybe Caribou, I've just started exploring it) is the best of both worlds: a template that assembles simple libraries with in a good default structure that you can use like a normal framework, but you still have the power to dive into the guts of the system and change it to suit your unique needs if you need to. Probaby it comes down to a stratified design<ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-986.pdf>: simple components, assembled in a higher level template (still a component, not so reusable but much more usable) with a reasonable wiring and boilerplate code already in place but that doesn't stop you if you want to change it. It doesn't have the disadvantages of a framework, but neither requires you to "compos[e] art out of found objects" (quoting Pedestal documentation). Cheers, Manuel -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
