Ahem.. Your comment misses the point. We chose RAILS because it met 90% of our needs... not because of some claims it would solve any problem. We then selected RAILS over Grails then based on the time it required us to code, the # of code lines was a very good measure then to make our final selection between these two.
This is why we use a mix of RAILS, Clojure and Spring. We chose the components best fitted to do specific things in our design. We did not choose a buzz word and then tried to make everything a nail so we could use a single hammer. For the medical record read-only view we did in Compojure/Clojure to extract a tree like model from the database and do html rendering with hiccup. Why ? because it was a perfect match for Clojure's abilities and it's very concise code-wise. There are around 50 tables to grab to display a medical record. Rails would have been too complex to implement over this since we only need to provide a read only view. Choosing between frameworks or making them coexist requires some knowledge about them, then you can have a selection process and see were you can apply them. Doing the reverse is non sense (choosing a framework based on some hyped reviews and then use for every need). BTW, we are driving interactions between several services in an hospital here, you can bet it's a bit more complex than a grocery list :) I totally agree that Clojure is a better tool to create abstractions, however we need to deliver now something that works today in the real world. Reusing what is available if it eases the pain to deliver is common sense. We cannot rewrite the whole universe in Clojure in one year. That's a fact. It's improving but will take some time to cover a number of areas. None of the above choices we made are static in time. They will change as things evolve over time and yes we tend to favor Clojure as much as possible to replace the other frameworks when an alternate solution is ready. We do not necessarily wait for prime time here, we are willing to push things in production that are not yet polished but not at the expense of increased delivery times and efforts. And again no we are not in the retail business at all :))) Luc P. Chris Riddoch <riddo...@gmail.com> wrote .. > On Tue, Nov 2, 2010 at 10:49 AM, Luke VanderHart > <luke.vanderh...@gmail.com> wrote: > > fanvie, two comments: > > > > 1. It will get better over time, of course, as standard practices for > > Clojure shake out. > > 2. You don't need 99% of the special crap that Spring/Grails gives > > you. Clojure's abstractions are smaller, yes, but the're just as > > powerful, and give you more control, in a more standardized way, then > > Spring does. > > Given other responses, I'd like to chime in with some agreement with > Luke. I think it's important to be aware of what frameworks do for > you, and what they don't do. It can be very easy, in a framework like > Rails, to get a simple UI for doing basic CRUD operations on a single > table, and for indicating basic relationships in the model. And > someone's written a little HTML here and there to save you a little > effort in the view. > > But what frameworks *don't* give you is a solution to the particular > problem you're working on, and while it seems at first like they've > already written 80% of your app, you'll quickly find that it's really > a lot closer to 8% -- and the easy 8%, at that. > > For anything more complicated than a grocery list, the differences > between frameworks is dwarfed by the application-specific logic of > your project. I'm always amused when people try out some framework by > making a blog, "proving" their framework is better because they could > do it in 20 lines of code instead of 30. > > Beware frameworks that claim to be "easy." It usually means that the > complexity lurks somewhere else. > > -- > Chris Riddoch > > -- > 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 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
