On Thursday, November 14, 2013 9:17:32 AM UTC-8, James Reeves wrote: > > On 14 November 2013 16:22, Brian Craft <craft...@gmail.com > <javascript:>>wrote: > >> >> 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. >> > > Except people *are* developing web applications in Clojure, so clearly > this isn't an accurate statement. >
I haven't seen a web application in clojure with the functionality of a django app, with the exception of polyglot applications that are using non-clojure frameworks to fill the gaps. I would very much like to see one. > > 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. > > > This certainly hasn't been my experience. > > Can you be certain this isn't a symptom of the tool you're using? > Frameworks like Django and Rails are designed to build web applications in > a very specific way, and this involves generating a lot of database and > HTML boilerplate. > > I can't say for sure whether it's because of Clojure, or because I'm > working on different problems these days, but I don't tend to deal with the > same issues I did when I used Rails. Nowadays I find myself building > systems out of small, isolated components, which seem to eliminate a lot of > issues Rails was designed to work around. > > For instance, database migrations. This was something I thought about a > lot a few years ago, until I gradually realised that I wasn't finding > myself in any situations where I needed them. > > I don't really understand this argument. What database tables would we not require if we used clojure? User passwords? Page content? User settings? Admin privileges? Of those tables, which ones would we not need admin interfaces for if we used clojure? I don't understand how choice of framework has any bearing on what data the app must store, what admin interfaces are required, what validation layers must be present, etc. You must validate all the user input. You must store all the data required by the app. You must have admin backends for all of the data used by the app. Using clojure doesn't change any of those requirements. And when we have changes to the data model, for example when finding that a new feature requires that we track an additional field for each user, or finding that a new clinical data set requires a more complex model of clinical samples, how would clojure allow us to avoid migrating the data model in the database, or update the model in a reliable way across several installs without using migrations? Again, I don't understand how the framework has anything to do with the necessity of updating a data model when new features or new data demand it. -- -- 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.
