tag:blogger.com,1999:blog-20975090.post6649103859750828840..comments2024-03-11T10:18:55.852-05:00Comments on Headius: Ruby on Grails? Why the hell not?Charles Oliver Nutterhttp://www.blogger.com/profile/06400331959739924670noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-20975090.post-29210725875543729392007-07-15T15:21:00.000-05:002007-07-15T15:21:00.000-05:00"Ruby on Grails? What the hell?"One of the strengt..."Ruby on Grails? What the hell?"<BR/><BR/>One of the strengths of Grails is that it provides Rails-like RAD for people who have no desire to use an archaic, stomach-churning language such as Ruby.<BR/><BR/>Language design has come on a long way since Ruby came along and in that time we have learnt a lot about transparency and maintainability as features that emerge from subtleties in the language. Rails is popular <I>despite</I> Ruby not because of it.<BR/><BR/>This, of course, actually reinforces your point about the value of a RAD web framework that is independent of the language choice. The framework should allow the language used to model the domain and craft the views and controllers to be pluggable.<BR/><BR/>Groovy, Ruby, pure-Java, even an XML language with a domain-modeling GUI on top -- all of these and more would find legions of supporter who would benefit from it all being backed by a unified and familiar framework and deployment model.Anonymoushttps://www.blogger.com/profile/17202233483193992480noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-51106922041507757832007-03-29T23:51:00.000-05:002007-03-29T23:51:00.000-05:00gjyjgjyjAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-20975090.post-23910509702044871132007-03-21T17:47:00.000-05:002007-03-21T17:47:00.000-05:00It's great to see so many hints that I'll probably...It's great to see so many hints that I'll probably want to be using Java in some forms quite a bit in the coming decade. I had recently thought I'd avoid it for the most part in favor of Ruby and Objective C. The improvements to Java itself and the beans are almost as compelling as the proliferation of languages coming to the vm.<BR/><BR/>I think Ruby on Grails will be a very strong move that helps to combine the momentum of Ruby with the mass of Java to bring more standardization around our theories about drying up the web. If Python and Helma and others end up fully compatible, so much the better. Unlike some here, I would generally suspect that all this noise would bring a lot more users to Groovy, in web context and others.schwabsaucehttps://www.blogger.com/profile/13380977650990236527noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-62502870906495289432007-03-14T04:40:00.000-05:002007-03-14T04:40:00.000-05:00Nice post Scott. I think that reflects the situati...Nice post Scott. I think that reflects the situation very well.Graeme Rocherhttps://www.blogger.com/profile/12301973191113958910noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-34219496985212426702007-03-13T23:12:00.000-05:002007-03-13T23:12:00.000-05:00I just had dinner with Charles a couple of weeks a...I just had dinner with Charles a couple of weeks ago at a No Fluff, Just Stuff show in Milwaukee. Unless his thoughts have drastically changed in the interim, I don't think that he is "bull baiting" as he implies.<BR/><BR/>As we talked, we both came to the same conclusion: JRuby is for folks who like the Ruby dialect. Groovy is for folks who like the Java dialect. Plain and simple. JRuby is less an effort to integrate Ruby with Java than a project that allows copy/paste source code compatibility with C/Ruby on the JVM with only minor exceptions. Groovy offers the same copy/paste compatibility with Java.<BR/><BR/>If you have an existing Ruby on Rails app and you want to run it on the JVM, JRuby is a great choice. If you have experience with well established Java libraries like Spring and Hibernate, but are envious of the scaffolding and convention over configuration of your Rails brethren, Grails fits the bill. <BR/><BR/>Grails is nowhere close to a straight port of Rails to another language. Inspired by: yes. Ported from: no. Grails (and Groovy) respect the idioms of the Java language. While a JRuby port of Grails is an interesting thought experiment, I think that it kinda misses the point. That doesn't mean you shouldn't try it, but I wouldn't hold out hope for widespread Java/Groovy community support any more than Ruby folks are dying for a Java version of Rails. Both frameworks are reflective of the strengths of their respective underlying languages. <BR/><BR/>And speaking of respect, Charles' posts to the Groovy mailing lists have been exceedingly polite and well thought out. Certainly no one would be naive enough in this day and age to argue that programming languages are a zero sum game -- that one is inherently better than all the rest. <BR/><BR/>Charles is doing great work for JRuby. But not all roads lead to Ruby. One man's JRuby is another man's Groovy. Or Jython. Or JavaScript. Or best of all -- any one of them, used in the right circumstances.Scott Davishttps://www.blogger.com/profile/06279233145190323422noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-59486341550687913222007-03-13T18:31:00.000-05:002007-03-13T18:31:00.000-05:00Why hibernate and not the JPA spec (who cares if t...Why hibernate and not the JPA spec (who cares if this is kodo, toplink, hibernate).<BR/><BR/>Why Xfire and not the JaxWS Java EE (SE) standard?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20975090.post-49150946623375269512007-03-13T07:10:00.000-05:002007-03-13T07:10:00.000-05:00Justin, here are some comments about what you aske...Justin, <BR/>here are some comments about what you asked:<BR/>"if I want to mix carefully tuned Spring MVC/Spring/Hibernate application content with admin pages using a lighter-weight framework against the same database"<BR/><BR/>Spring:<BR/>I think you could launch Spring from your config/environment.rb to initialize your beans with Spring before your JRUBY on Rails apps use them. But that would only help for the J2EE stuff, because for Rails already has some kind of IOC (via Ruby mixins or dynamic redefinitions) support wich is more mannageable than Spring.<BR/><BR/>Struts MVC: <BR/>If you use Struts or an other MVC framework in your JRuby on Rails app, really I tink you couldn't use a lot of Rails then, may be only ActiveRecord. That'll be interesting to discover if you can make the to action dispatcher co-exist to server both JSP/MVC and RHTML/MVC though. Does anybody know about that point? Still I think Rails MVC outperform any other J2EE MVC.<BR/><BR/>Hibernate:<BR/>You got it, that's one of the best reasons to bridge Rails and the J2EE world. As far as I know Rails, that would be totally easy to use Hibernate as the ORM layer instead of ActiveRecord. I already used Rails almost without ActiveRecord (with a legacy data base) and I think wrapping a n Hibernate bean into an ActiveRecord object (or even skip it would be easy) and very welcome if your mapping is dirty.<BR/>For instance, you could forward all the methods from your ActiveRecord/other wrapper instance to the corresponding Hibernate bean via the method_missing ruby method (I did similar things already between several ActiveRecord objects for instance).<BR/><BR/>Beside the speed of the J2EE stack itself, using ActiveRecord-JDBC could also may be allow us to use a faster database: Hypersonic to name it. Swapping my DB to this one (all working in your RAM if you have enough RAM) is one of the first things I'll try if I can switch to JRuby on Rails.<BR/><BR/>Regards and long life to JRuby on Rails.Raphaël Valyihttps://www.blogger.com/profile/01805258585519968165noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-80060179207314883142007-03-12T19:14:00.000-05:002007-03-12T19:14:00.000-05:00You are right that something like Grails, built on...You are right that something like Grails, built on the same Java frameworks, could be done in JRuby. My guess is that it wouldn't <I>be</I> Grails - or else it wouldn't be a natural use of Ruby. I feel that Grails should be given space to grow up in its own way, becoming a showcase for Groovy, just as Rails is for Ruby.<BR/><BR/>I'd rather think about what - apart from language preference - might cause someone to choose Grails rather than Rails on JRuby. Can Rails/JRuby be adjusted (e.g. via Java-specific plugins) to reduce the difference? For example, if I want to mix carefully tuned Spring MVC/Spring/Hibernate application content with admin pages using a lighter-weight framework against the same database - Grails supports this, with one O/R mapping; could Rails/JRuby?<BR/><BR/>Regarding the use of Java in Grails, that seems fine to me. In a Groovy application there's less of an obstacle to doing parts in Java than there would be for doing parts of a Ruby application in C. Given the openness of Ruby, it would be possible (if a bit scary) for a JRuby/Java plugin to replace parts of the Rails implementation with more efficient Java code - have you been at all tempted to do this?<BR/><BR/>Keep up the excellent work - it's truly impressive, as is your colleagues' work on NetBeans support for Ruby/JRuby.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20975090.post-81047178138457200762007-03-12T04:54:00.000-05:002007-03-12T04:54:00.000-05:00Hi Charles,I would be happy to give you a tour of ...Hi Charles,<BR/><BR/>I would be happy to give you a tour of the codebase. <BR/><BR/>In terms of supporting Ruby, its just a matter of resources. See my post in response:<BR/><BR/>http://graemerocher.blogspot.com/2007/03/charles-nutter-ruby-on-grails-story.html<BR/><BR/>;-)<BR/><BR/>Cheers<BR/>GraemeGraeme Rocherhttps://www.blogger.com/profile/12301973191113958910noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-24838468571838083302007-03-11T12:11:00.000-05:002007-03-11T12:11:00.000-05:00I'm using both traditionnal J2EE stuff from GRails...I'm using both traditionnal J2EE stuff from GRails at work (Struts(2), Spring, Hibernate, Apache commons...) and Rails stuff at home.<BR/><BR/>My point is that Rails is just much better as an MVC framework + most of the other features web development requires. <BR/><BR/>First, it's a lot DRYer so the learning curve is much faster (and this is due to language level feature such as closures and multiple implementation inheritance through mixins Ruby provides where Java will have to use overkill decorators/factory patterns leading to obscur APIs)<BR/><BR/>Second, there is absolutely no justification for a faster language in the MVC wiring of web development. the MVC wiring is not where the time is spent.<BR/><BR/>Tird, the "static types" argument is crappy for the MVC and the mapping stuff as those are full of static flaws: HQL validity is not enforced at compilation time (with free IDE at least), neither is the type of your queries, neither are your JSP properties/EL expressions in your views, neither is your Spring wiring. Considering all this Rails+ easy unit testing just makes more sense.<BR/><BR/>I could only find some advantages of Hibernate for existing very complex mappings where ActiveRecord won't make it. Still ActiveRecord miht be easier (thus more efficient) in 90% of the use cases.<BR/><BR/>So I think Struts and all other J2EE MVC frameworks are really unproductive compared to the MVC from Rails.<BR/><BR/>Finally, I think your proposal might only be good at trying to increase the JRuby momentum by attracting developpers from GRails into a common synergy. Also, more importanty, this could open the door to a smooth transition to Rails in legacy web apps where Hibernate mappings are common and could be reused for more Rail oriented MVC.<BR/><BR/>Peace.<BR/><BR/>Raphaël Valyi.Raphaël Valyihttps://www.blogger.com/profile/01805258585519968165noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-13517430061886031402007-03-11T10:04:00.000-05:002007-03-11T10:04:00.000-05:00Why not? Supporting other dynamic languages would...Why not? Supporting other dynamic languages would make grails stronger.<BR/><BR/>It would also make a significant statement: the developers of groovy and grails do not suffer from the same hegemonic tendencies as other similar dynamic language projects. Imagine how the rails creator would response to this same question. Which raises an interesting question about defending groovy from the hegemony of other scripting languages...<BR/><BR/>Would there be any reason to provide multiple language support for the build or other parts of the framework that <I>are</I> written in Groovy?<BR/><BR/>Would there be any benefit to using Java less in Grails? The developers seem to have given a lot of thought to when they should use groovy over Java. In fact, it would be interesting to hear more about their criteria, because it is definitely easier to write Groovy code than Java. Is it for performance? Is it because it seems like the right thing to do?<BR/>It's hard to say, I've written builders in Groovy and Java, and I'd like to think the choice is a matter of taste and context.Donaldhttps://www.blogger.com/profile/04725921333166621781noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-1423291737730784282007-03-11T09:08:00.000-05:002007-03-11T09:08:00.000-05:00I've been working on integrating Groovy with Strus...I've been working on integrating Groovy with Strus 2 and Spring. I have taken two different approaches:<BR/><BR/>1. Instantiating my actions in Struts 2, and then having Spring wire their dependencies.<BR/><BR/>2. Having Spring instantiate the actions, and wire their dependencies.<BR/><BR/>Spring has growing support for scripted beans, including dynamic recompilation. (ie. You don't need to recomile/redeploy your web app to see the change.)<BR/><BR/>The advantage of using Spring to instantiate the beans, is that they can be written in any scripting language supported by Spring. So, you could have a JRuby action, a Groovy service bean, a JRuby DAO, and a Java domain entity using JPA or Hibernate for example.<BR/><BR/>My issue right now is that Spring seems to wrap all scripted beans in a proxy. Therefore you need to have them implement an interface for any methods you want to publicly expose. (That's a PITA for simple things like a Struts 2 Action, which are highly dynamic.) Also, Spring does not support "prototype" scripted beans currently. Although I've submitted a patch for that to their JIRA.<BR/><BR/>Take a look at <A HREF="http://www.vitarara.org/cms/node/109" REL="nofollow">my latest ramblings</A> on this subject.Vita Rarahttps://www.blogger.com/profile/14237598315022861781noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-47212384567746573942007-03-10T23:51:00.000-06:002007-03-10T23:51:00.000-06:00This is actually a really cool idea. I don't have...This is actually a really cool idea. I don't have much experience with either rails or grails, but I am familiar enough with the two to know that they each have their respective strengths. Offering grails running on JRuby would only open the door to non-groovy enthusiasts (like myself).Daniel Spiewakhttps://www.blogger.com/profile/17323566514229790079noreply@blogger.com