Hello, there is another comparsion http://web1.theserverside.com/articles/article.tss?l=RailsHibernate of Java (Hibernate) with RoR. I''m not so big expert, but I think they are worying 10x productivity :-) And yes, I''m comming from java world too. Never going back in my heart, max for my wallet. Have a nice day. -- Ing. Josef Pospisil
Of course there is competition. Biased or not, I thought this article was valuable. I learned something about both Hibernate and Rails (especially the deeper details of the database access). I''m glad to have seen this :) On Thu, 31 Mar 2005 09:36:50 +0200, Josef Pospisil <perails-9Vj9tDbzfuSlVyrhU4qvOw@public.gmane.org> wrote:> Hello, > > there is another comparsion > http://web1.theserverside.com/articles/article.tss?l=RailsHibernate of > Java (Hibernate) with RoR. I''m not so big expert, but I think they are > worying 10x productivity :-) > > And yes, I''m comming from java world too. Never going back in my heart, > max for my wallet. > > Have a nice day. > > -- > Ing. Josef Pospisil > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
I think the same. Guy looks like big proffesinal with deep undestanding of hibernate (ok he wrote a book about it), but he missed somethind like :dependent etc, so maybe one of RoR heavy weight can write some little correction to this article. Please. I love intelectual wars. It is one of the world engines :-). -- Ing. Josef Pospisil On 31.3.2005, at 9:59, Michael Teter wrote:> Of course there is competition. > > Biased or not, I thought this article was valuable. I learned > something about both Hibernate and Rails (especially the deeper > details of the database access). > > I''m glad to have seen this :) > > > On Thu, 31 Mar 2005 09:36:50 +0200, Josef Pospisil <perails-9Vj9tDbzfuSlVyrhU4qvOw@public.gmane.org> > wrote: >> Hello, >> >> there is another comparsion >> http://web1.theserverside.com/articles/article.tss?l=RailsHibernate of >> Java (Hibernate) with RoR. I''m not so big expert, but I think they are >> worying 10x productivity :-) >> >> And yes, I''m comming from java world too. Never going back in my >> heart, >> max for my wallet. >> >> Have a nice day. >> >> -- >> Ing. Josef Pospisil >> >> _______________________________________________ >> Rails mailing list >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Yes, I meant to say, I look forward to reading an informed Rails rebuttal essay. On Thu, 31 Mar 2005 10:13:27 +0200, Josef Pospisil <perails-9Vj9tDbzfuSlVyrhU4qvOw@public.gmane.org> wrote:> I think the same. Guy looks like big proffesinal with deep undestanding > of hibernate (ok he wrote a book about it), but he missed somethind > like :dependent etc, so maybe one of RoR heavy weight can write some > little correction to this article. > > Please. I love intelectual wars. It is one of the world engines :-). > > -- > Ing. Josef Pospisil > On 31.3.2005, at 9:59, Michael Teter wrote: > > > Of course there is competition. > > > > Biased or not, I thought this article was valuable. I learned > > something about both Hibernate and Rails (especially the deeper > > details of the database access). > > > > I''m glad to have seen this :) > > > > > > On Thu, 31 Mar 2005 09:36:50 +0200, Josef Pospisil <perails-9Vj9tDbzfuSlVyrhU4qvOw@public.gmane.org> > > wrote: > >> Hello, > >> > >> there is another comparsion > >> http://web1.theserverside.com/articles/article.tss?l=RailsHibernate of > >> Java (Hibernate) with RoR. I''m not so big expert, but I think they are > >> worying 10x productivity :-) > >> > >> And yes, I''m comming from java world too. Never going back in my > >> heart, > >> max for my wallet. > >> > >> Have a nice day. > >> > >> -- > >> Ing. Josef Pospisil > >> > >> _______________________________________________ > >> Rails mailing list > >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > >> http://lists.rubyonrails.org/mailman/listinfo/rails > >> > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Quote: Rails development is "at least ten times faster with Rails than you could with a typical Java framework" Well, considering that Rails development will have to be very hard with a typical Java framework, I have no problems confirming that this must be true :-D //jarkko On 31.3.2005, at 11:30, Michael Teter wrote:> Yes, I meant to say, I look forward to reading an informed Rails > rebuttal essay. > > On Thu, 31 Mar 2005 10:13:27 +0200, Josef Pospisil <perails-9Vj9tDbzfuSlVyrhU4qvOw@public.gmane.org> > wrote: >> I think the same. Guy looks like big proffesinal with deep >> undestanding >> of hibernate (ok he wrote a book about it), but he missed somethind >> like :dependent etc, so maybe one of RoR heavy weight can write some >> little correction to this article. >> >> Please. I love intelectual wars. It is one of the world engines :-). >> >> -- >> Ing. Josef Pospisil >> On 31.3.2005, at 9:59, Michael Teter wrote: >> >>> Of course there is competition. >>> >>> Biased or not, I thought this article was valuable. I learned >>> something about both Hibernate and Rails (especially the deeper >>> details of the database access). >>> >>> I''m glad to have seen this :) >>> >>> >>> On Thu, 31 Mar 2005 09:36:50 +0200, Josef Pospisil >>> <perails-9Vj9tDbzfuSlVyrhU4qvOw@public.gmane.org> >>> wrote: >>>> Hello, >>>> >>>> there is another comparsion >>>> http://web1.theserverside.com/articles/article.tss?l=RailsHibernate >>>> of >>>> Java (Hibernate) with RoR. I''m not so big expert, but I think they >>>> are >>>> worying 10x productivity :-) >>>> >>>> And yes, I''m comming from java world too. Never going back in my >>>> heart, >>>> max for my wallet. >>>> >>>> Have a nice day. >>>> >>>> -- >>>> Ing. Josef Pospisil >>>> >>>> _______________________________________________ >>>> Rails mailing list >>>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >>>> http://lists.rubyonrails.org/mailman/listinfo/rails >>>> >>> _______________________________________________ >>> Rails mailing list >>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >>> http://lists.rubyonrails.org/mailman/listinfo/rails >>> >> >> _______________________________________________ >> Rails mailing list >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Jarkko Laine http://jlaine.net http://odesign.fi _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
:-D I even think that get Java framework (any I tried) to work is ten time harder than make rails application. I''m currently starting "big" project with tens of models and really weird structure (doctoral study on university with all documents) so I''ll refer how it goes. I believe it will be goooooood :-). -- Ing. Josef Pospisil On 31.3.2005, at 10:42, Jarkko Laine wrote:> Quote: > Rails development is "at least ten times faster with Rails than you > could with a typical Java framework" > > Well, considering that Rails development will have to be very hard > with a typical Java framework, I have no problems confirming that this > must be true :-D > > //jarkko > > > On 31.3.2005, at 11:30, Michael Teter wrote: > >> Yes, I meant to say, I look forward to reading an informed Rails >> rebuttal essay. >> >> On Thu, 31 Mar 2005 10:13:27 +0200, Josef Pospisil >> <perails-9Vj9tDbzfuSlVyrhU4qvOw@public.gmane.org> wrote: >>> I think the same. Guy looks like big proffesinal with deep >>> undestanding >>> of hibernate (ok he wrote a book about it), but he missed somethind >>> like :dependent etc, so maybe one of RoR heavy weight can write some >>> little correction to this article. >>> >>> Please. I love intelectual wars. It is one of the world engines :-). >>> >>> -- >>> Ing. Josef Pospisil >>> On 31.3.2005, at 9:59, Michael Teter wrote: >>> >>>> Of course there is competition. >>>> >>>> Biased or not, I thought this article was valuable. I learned >>>> something about both Hibernate and Rails (especially the deeper >>>> details of the database access). >>>> >>>> I''m glad to have seen this :) >>>> >>>> >>>> On Thu, 31 Mar 2005 09:36:50 +0200, Josef Pospisil >>>> <perails-9Vj9tDbzfuSlVyrhU4qvOw@public.gmane.org> >>>> wrote: >>>>> Hello, >>>>> >>>>> there is another comparsion >>>>> http://web1.theserverside.com/articles/article.tss? >>>>> l=RailsHibernate of >>>>> Java (Hibernate) with RoR. I''m not so big expert, but I think they >>>>> are >>>>> worying 10x productivity :-) >>>>> >>>>> And yes, I''m comming from java world too. Never going back in my >>>>> heart, >>>>> max for my wallet. >>>>> >>>>> Have a nice day. >>>>> >>>>> -- >>>>> Ing. Josef Pospisil >>>>> >>>>> _______________________________________________ >>>>> Rails mailing list >>>>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >>>>> http://lists.rubyonrails.org/mailman/listinfo/rails >>>>> >>>> _______________________________________________ >>>> Rails mailing list >>>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >>>> http://lists.rubyonrails.org/mailman/listinfo/rails >>>> >>> >>> _______________________________________________ >>> Rails mailing list >>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >>> http://lists.rubyonrails.org/mailman/listinfo/rails >>> >> _______________________________________________ >> Rails mailing list >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> > -- > Jarkko Laine > http://jlaine.net > http://odesign.fi > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Mar 31, 2005, at 09:36, Josef Pospisil wrote:> there is another comparsion > http://web1.theserverside.com/articles/article.tss?l=RailsHibernate of > Java (Hibernate) with RoR. I''m not so big expert, but I think they are > worying 10x productivity :-) > > And yes, I''m comming from java world too. Never going back in my > heart, max for my wallet.Well... language issue aside... there is more to the Java platform than The Cult of the Exxon Valdez (aka J2EE)... http://en.wikipedia.org/wiki/Exxon_Valdez_oil_spill Perhaps of particular interest to train-spotters is WebObjects: "About WebObjects" http://developer.apple.com/documentation/WebObjects/ WebObjects_Overview/AboutWebObjects/chapter_2_section_1.html "Enterprise Objects" http://developer.apple.com/documentation/WebObjects/ WebObjects_Overview/EnterpriseObjects/chapter_3_section_1.html Specially WebObjects''s DirectToWeb is very similar to RoR''s scaffolding for all practical purposes: "The Direct to Web Approach" http://developer.apple.com/documentation/WebObjects/ WebObjects_Overview/WebApplications/chapter_4_section_6.htm WebObjects has numerous open source siblings and cousins: Java http://jakarta.apache.org/tapestry/ http://www.objectstyle.org/cayenne/ Objective-C http://www.gnustepweb.org/ http://sope.opengroupware.org/en/sope_appserver/ As with many other things, choice is good: "Choose life. Choose a job. Choose a starter home. Choose dental insurance, leisure wear and matching luggage." http://www.imdb.com/title/tt0117951/ Cheers -- PA, Onnay Equitursay http://alt.textdrive.com/
Hi,> As with many other things, choice is good: > > "Choose life. Choose a job. Choose a starter home. Choose dental > insurance, leisure wear and matching luggage."Too many choices, and people end up choosing nothing: http://www.itconversations.com/shows/detail252.html Sometimes it''s braver to say: choose this! Then to let people freak out with so many choices. :-) Cheers, Joao
On Thursday 31 March 2005 13:10, PA wrote:> WebObjects has numerous open source siblings and cousins:One of them is sws/sds for ruby, e.g. But none has the elegance of ror anyway. -- Best regards, Stanislav Karchebny Skype name: berkus Get skype for free from www.skype.com Information in this email is confidential and proprietary.
I''m just finishing up this book. I''ve had a hard time agreeing with some of his conclusions, but it is still a very worthwhile read. I think it can explain a lot about the way software choices have led us to our current state. I think the lack of choice, or at least an obvious preferred way, are the reasons I like the software that I do. - Wilkes On Mar 31, 2005, at 6:06 AM, Joao Pedrosa wrote:> Hi, > >> As with many other things, choice is good: >> >> "Choose life. Choose a job. Choose a starter home. Choose dental >> insurance, leisure wear and matching luggage." > > Too many choices, and people end up choosing nothing: > http://www.itconversations.com/shows/detail252.html > > Sometimes it''s braver to say: choose this! Then to let > people freak out with so many choices. :-) > > Cheers, > Joao > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On Mar 31, 2005, at 14:06, Joao Pedrosa wrote:> Too many choices, and people end up choosing nothing: > http://www.itconversations.com/shows/detail252.html > > Sometimes it''s braver to say: choose this! Then to let > people freak out with so many choices. :-)Right... http://www.edwardtufte.com/tufte/graphics/book_stalincover2_full.gif Cheers -- PA, Onnay Equitursay http://alt.textdrive.com/
Hi, On Thu, 31 Mar 2005 16:24:29 +0200, PA <petite.abeille-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > On Mar 31, 2005, at 14:06, Joao Pedrosa wrote: > > > Too many choices, and people end up choosing nothing: > > http://www.itconversations.com/shows/detail252.html > > > > Sometimes it''s braver to say: choose this! Then to let > > people freak out with so many choices. :-) > > Right... > > http://www.edwardtufte.com/tufte/graphics/book_stalincover2_full.gifOuch! Extremisms as always. :-) But I would trust your opinion, PA, over most of the ones that usually control the masses, though you aren''t a Hitler or anything. Maybe you should shut up, so I won''t follow your ideas if I so feel like it? :-) Because even if not on purpose, but you promote Lua, right? :-) Cheers, Joao
I found this comment interesting in the article: "The question is, what fields does this object have? You have to fire up MySQL Front (or whatever) and look at the database schema. When the number of domain models is small, this isn''t a big deal. But when your project has 40+ tables/50ish domain objects (like a Hibernate project I''m currently working on), this would seem pretty painful. Ultimately, this might come down to preference, but having the details in the code makes it easier to understand and alter." Well, its true that Hibernate uses xdoclet tags in the comments to define the mappings to y our tables, but couldn''t you just as easily define your table definitions in RoR within the comments as well? Its not a requirement for it to work properly (whereas in Hibernate, it is), but it solves the problem of having to fireup your sql browser just to view the tables. This doesn''t seem like a valid argument to me since you can easily do the same thing in Rails (or any other language. After all, they are just definitions in your comments) On Thu, 31 Mar 2005 16:24:29 +0200, PA <petite.abeille-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > On Mar 31, 2005, at 14:06, Joao Pedrosa wrote: > > > Too many choices, and people end up choosing nothing: > > http://www.itconversations.com/shows/detail252.html > > > > Sometimes it''s braver to say: choose this! Then to let > > people freak out with so many choices. :-) > > Right... > > http://www.edwardtufte.com/tufte/graphics/book_stalincover2_full.gif > > Cheers > > -- > PA, Onnay Equitursay > http://alt.textdrive.com/ > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- - Ramin
Ramin wrote:>I found this comment interesting in the article: > >"The question is, what fields does this object have? You have to fire >up MySQL Front (or whatever) and look at the database schema. When the >number of domain models is small, this isn''t a big deal. But when your >project has 40+ tables/50ish domain objects (like a Hibernate project >I''m currently working on), this would seem pretty painful. Ultimately, >this might come down to preference, but having the details in the code >makes it easier to understand and alter." > >Well, its true that Hibernate uses xdoclet tags in the comments to >define the mappings to y our tables, but couldn''t you just as easily >define your table definitions in RoR within the comments as well? Its >not a requirement for it to work properly (whereas in Hibernate, it >is), but it solves the problem of having to fireup your sql browser >just to view the tables. This doesn''t seem like a valid argument to me >since you can easily do the same thing in Rails (or any other >language. After all, they are just definitions in your comments) > >Yeah but since almost everyone writing Java is using an IDE with intelligent auto-complete, its much slicker to have it defined as a field than in a comment. You''ll see it in the class browser, when you ctrl-space, etc. Even if Ruby had an IDE with well-baked features like this it would not solve the issue, and it would create two new issues: first, DRY. This could be solved by making a string constant or something thats actually used to generate the database objects, but then you have the second issue, which the author of this article never points out about Hibernate (but I did for him in a comment): ALTER TABLE (or making modifications in pgAdmin, whatever). I can change my data model quickly and easily without losing my data, and my RoR model keeps up. The ability to quickly rework my design is a consequence of DRY and is evidenced in many places in RoR but in my limited time with the framework I''ve found this one to be very significant. If I change schema in XDoclet tags and rerun my Ant schmorgas after a minute or so its done and all my data is gone. Gee, thanks. Yeah, I could put that data somewhere else but then I''d have to map it back into the new schema, so there I''ve gone and repeated myself. Since changing the data model is painful, I''m reluctant to make changes that aren''t essential and I end up with complications and concessions.
The point here is that with a Java object, you know what its properties are. You can look at the class definition, or the class browser in your IDE, or use auto-completion. It''s kind of the same as Java being strongly-typed vs Ruby. With Java, you explicitly declare all the variables - with RoR, they''re implicitly defined from the DB table. As in the article, I think that Java''s way would probably work better in a large-scale project, simply because it becomes much easier to view a class''s composition. In the end, they''re just two different ways of doing the same thing, and it all boils down to personal preference. On Thu, 31 Mar 2005 09:54:32 -0500, Ramin <i8ramin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I found this comment interesting in the article: > > "The question is, what fields does this object have? You have to fire > up MySQL Front (or whatever) and look at the database schema. When the > number of domain models is small, this isn''t a big deal. But when your > project has 40+ tables/50ish domain objects (like a Hibernate project > I''m currently working on), this would seem pretty painful. Ultimately, > this might come down to preference, but having the details in the code > makes it easier to understand and alter." > > Well, its true that Hibernate uses xdoclet tags in the comments to > define the mappings to y our tables, but couldn''t you just as easily > define your table definitions in RoR within the comments as well? Its > not a requirement for it to work properly (whereas in Hibernate, it > is), but it solves the problem of having to fireup your sql browser > just to view the tables. This doesn''t seem like a valid argument to me > since you can easily do the same thing in Rails (or any other > language. After all, they are just definitions in your comments) > > > On Thu, 31 Mar 2005 16:24:29 +0200, PA <petite.abeille-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > On Mar 31, 2005, at 14:06, Joao Pedrosa wrote: > > > > > Too many choices, and people end up choosing nothing: > > > http://www.itconversations.com/shows/detail252.html > > > > > > Sometimes it''s braver to say: choose this! Then to let > > > people freak out with so many choices. :-) > > > > Right... > > > > http://www.edwardtufte.com/tufte/graphics/book_stalincover2_full.gif > > > > Cheers > > > > -- > > PA, Onnay Equitursay > > http://alt.textdrive.com/ > > > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > -- > - Ramin > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Webobjects is pretty damned cool and it''s pretty cheap. It will be interesting to see what apple says about it in WWDC coming up in June. Last year they seemed to hint that they are not that interested in it anymore. I think they want to make it a Mac only product using coredata but that''s just my guess. If anybody here is going to WWDC maybe we can all get together! PA wrote:> > On Mar 31, 2005, at 09:36, Josef Pospisil wrote: > >> there is another comparsion >> http://web1.theserverside.com/articles/article.tss?l=RailsHibernate >> of Java (Hibernate) with RoR. I''m not so big expert, but I think >> they are worying 10x productivity :-) >> >> And yes, I''m comming from java world too. Never going back in my >> heart, max for my wallet. > > > Well... language issue aside... there is more to the Java platform > than The Cult of the Exxon Valdez (aka J2EE)... > > http://en.wikipedia.org/wiki/Exxon_Valdez_oil_spill > > Perhaps of particular interest to train-spotters is WebObjects: > > "About WebObjects" > http://developer.apple.com/documentation/WebObjects/ > WebObjects_Overview/AboutWebObjects/chapter_2_section_1.html > > "Enterprise Objects" > http://developer.apple.com/documentation/WebObjects/ > WebObjects_Overview/EnterpriseObjects/chapter_3_section_1.html > > Specially WebObjects''s DirectToWeb is very similar to RoR''s > scaffolding for all practical purposes: > > "The Direct to Web Approach" > http://developer.apple.com/documentation/WebObjects/ > WebObjects_Overview/WebApplications/chapter_4_section_6.htm > > WebObjects has numerous open source siblings and cousins: > > Java > > http://jakarta.apache.org/tapestry/ > http://www.objectstyle.org/cayenne/ > > Objective-C > > http://www.gnustepweb.org/ > http://sope.opengroupware.org/en/sope_appserver/ > > As with many other things, choice is good: > > "Choose life. Choose a job. Choose a starter home. Choose dental > insurance, leisure wear and matching luggage." > > http://www.imdb.com/title/tt0117951/ > > Cheers > > -- > PA, Onnay Equitursay > http://alt.textdrive.com/ > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On Mar 31, 2005, at 16:43, Joao Pedrosa wrote:> control the masses, though you aren''t a Hitler or anything. Maybe you > should shut up, so I won''t follow your ideas if I so feel like it? :-) > Because even if not on purpose, but you promote Lua, right? :-)Here you go :)) "Lua — Story of O" a post-structuralist object oriented system http://alt.textdrive.com/lua/19/lua-story-of-o Cheers -- PA, Onnay Equitursay http://alt.textdrive.com/
Rebuttal? Maybe, but it could be very interesting a *civilized discussion* of the "issues" about relationships, and optimization options that could be added (if really needed) without altering the essence of Ror, which would be a clear sign that elegant and "simple" solutions can be adapted to address more complex scenarios. Andres Michael Teter wrote:>Yes, I meant to say, I look forward to reading an informed Rails rebuttal essay. > >On Thu, 31 Mar 2005 10:13:27 +0200, Josef Pospisil <perails-9Vj9tDbzfuSlVyrhU4qvOw@public.gmane.org> wrote: > > >>I think the same. Guy looks like big proffesinal with deep undestanding >>of hibernate (ok he wrote a book about it), but he missed somethind >>like :dependent etc, so maybe one of RoR heavy weight can write some >>little correction to this article. >> >>Please. I love intelectual wars. It is one of the world engines :-). >> >>-- >>Ing. Josef Pospisil >>On 31.3.2005, at 9:59, Michael Teter wrote: >> >> >> >>>Of course there is competition. >>> >>>Biased or not, I thought this article was valuable. I learned >>>something about both Hibernate and Rails (especially the deeper >>>details of the database access). >>> >>>I''m glad to have seen this :) >>> >>> >>>On Thu, 31 Mar 2005 09:36:50 +0200, Josef Pospisil <perails-9Vj9tDbzfuSlVyrhU4qvOw@public.gmane.org> >>>wrote: >>> >>> >>>>Hello, >>>> >>>>there is another comparsion >>>>http://web1.theserverside.com/articles/article.tss?l=RailsHibernate of >>>>Java (Hibernate) with RoR. I''m not so big expert, but I think they are >>>>worying 10x productivity :-) >>>> >>>>And yes, I''m comming from java world too. Never going back in my >>>>heart, >>>>max for my wallet. >>>> >>>>Have a nice day. >>>> >>>>-- >>>>Ing. Josef Pospisil >>>> >>>>_______________________________________________ >>>>Rails mailing list >>>>Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >>>>http://lists.rubyonrails.org/mailman/listinfo/rails >>>> >>>> >>>> >>>_______________________________________________ >>>Rails mailing list >>>Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >>>http://lists.rubyonrails.org/mailman/listinfo/rails >>> >>> >>> >>_______________________________________________ >>Rails mailing list >>Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >>http://lists.rubyonrails.org/mailman/listinfo/rails >> >> >> >_______________________________________________ >Rails mailing list >Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >http://lists.rubyonrails.org/mailman/listinfo/rails > > >
On Thu, 31 Mar 2005, Pat Maddox wrote:> The point here is that with a Java object, you know what its properties are. > You can look at the class definition, or the class browser in your IDE, or > use auto-completion.what if your object is a soap or rmi object? what if you are dynamically generating code, compiling it, and loading class files (which i have done)? what if you are looking at an interface that has only a jar file behind it - you can see only 10% of the available methods and even with those cannot see how they are implemented - not only that but the next release may add/delete some; in fact the object behind your interface may not even be the same in two invocations of the code.> It''s kind of the same as Java being strongly-typed vs Ruby. With Java, you > explicitly declare all the variables - with RoR, they''re implicitly defined > from the DB table. As in the article, I think that Java''s way would > probably work better in a large-scale project, simply because it becomes > much easier to view a class''s composition.or much harder since the class will be 10 times larger - especially for large projects. many, many studies have proven the fact that coders produce precisely the same number of lines of code per day no matter which language they program in. with this in mind, your comment strikes me as a sort of reverse logic : it''s like saying "if i were climbing a really big mountain i''d chose to step one inch at time instead of one foot - that way i''ll get to the top faster." although i admit that analogy is not quite perfect. in any case i would say this - i''ve written over a dozen ruby projects with > 3000 lines of code. in each case the equivalent project, written in java, would have been at least 30,000 TLOC and would have required more than just me to create. until (perhaps you have) one has written a large project in ruby it''s really not saying much to say ''you think'' it won''t scale as well for large projects - the irony here is that i''ve had a very hard time writing ''large'' projects - they simply colapse into so few lines of code because of ruby''s expressive power that i can''t seem to crack the 5000 line mark.> In the end, they''re just two different ways of doing the same thing, and it > all boils down to personal preference.you can say __exactly__ the same thing about a hammer and a nail-gun and precisely same relationship applies: one person can frame a door with a hammer while the other frames the entire house with the nail gun. cheers. -a -- ==============================================================================| email :: ara [dot] t [dot] howard [at] noaa [dot] gov | phone :: 303.497.6469 | if you love the sacred and despise the ordinary, you are still bobbing in the | ocean of delusion. --lin-chi ===============================================================================
>>>many, many studies have proven the fact that coders produce precisely the same number of lines of code per day no matter which language <<< So you''re saying that a coder using IBM''s WebSphere development platform or VS.net and another using Ruby on Rails with a any text editor produce the same amount of code per day? I find it hard to believe that ''fact''. Regards, Abdullah --- "Ara.T.Howard" <Ara.T.Howard-32lpuo7BZBA@public.gmane.org> wrote:> On Thu, 31 Mar 2005, Pat Maddox wrote: > > > The point here is that with a Java object, you > know what its properties are. > > You can look at the class definition, or the class > browser in your IDE, or > > use auto-completion. > > what if your object is a soap or rmi object? what > if you are dynamically > generating code, compiling it, and loading class > files (which i have done)? > what if you are looking at an interface that has > only a jar file behind it - > you can see only 10% of the available methods and > even with those cannot see > how they are implemented - not only that but the > next release may add/delete > some; in fact the object behind your interface may > not even be the same in two > invocations of the code. > > > It''s kind of the same as Java being strongly-typed > vs Ruby. With Java, you > > explicitly declare all the variables - with RoR, > they''re implicitly defined > > from the DB table. As in the article, I think > that Java''s way would > > probably work better in a large-scale project, > simply because it becomes > > much easier to view a class''s composition. > > or much harder since the class will be 10 times > larger - especially for large > projects. many, many studies have proven the fact > that coders produce > precisely the same number of lines of code per day > no matter which language > they program in. with this in mind, your comment > strikes me as a sort of > reverse logic : it''s like saying "if i were climbing > a really big mountain i''d > chose to step one inch at time instead of one foot - > that way i''ll get to the > top faster." although i admit that analogy is not > quite perfect. in any case > i would say this - i''ve written over a dozen ruby > projects with > 3000 lines > of code. in each case the equivalent project, > written in java, would have > been at least 30,000 TLOC and would have required > more than just me to create. > until (perhaps you have) one has written a large > project in ruby it''s really > not saying much to say ''you think'' it won''t scale as > well for large projects - > the irony here is that i''ve had a very hard time > writing ''large'' projects - > they simply colapse into so few lines of code > because of ruby''s expressive > power that i can''t seem to crack the 5000 line mark. > > > In the end, they''re just two different ways of > doing the same thing, and it > > all boils down to personal preference. > > you can say __exactly__ the same thing about a > hammer and a nail-gun and > precisely same relationship applies: one person can > frame a door with a hammer > while the other frames the entire house with the > nail gun. > > cheers. > > -a > -- >==============================================================================> | email :: ara [dot] t [dot] howard [at] noaa> [dot] gov > | phone :: 303.497.6469 > | if you love the sacred and despise the ordinary, > you are still bobbing in the > | ocean of delusion. --lin-chi >==============================================================================> _______________________________________________> Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
I would have to agree that coders produce the same number of lines of code, but the real question is, does the code perform the same functionality or does it do more? If I write 100 lines of Java code and all it does is make a connection to my database but the same 100 lines of Ruby code connects to the db, retrieves my information sets it to my model, calls my controllers and displays my view in html. Then I would say the Ruby code does more in the same 100 lines of code. But what do I know.. im a RubyNuby On Thu, 31 Mar 2005 11:25:17 -0800 (PST), Abdullah Jibaly <amjibaly-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote:> >>> > many, many studies have proven the fact that coders > produce > precisely the same number of lines of code per day no > matter which > language > <<< > > So you''re saying that a coder using IBM''s WebSphere > development platform or VS.net and another using Ruby > on Rails with a any text editor produce the same > amount of code per day? I find it hard to believe that > ''fact''. > > Regards, > Abdullah > > --- "Ara.T.Howard" <Ara.T.Howard-32lpuo7BZBA@public.gmane.org> wrote: > > On Thu, 31 Mar 2005, Pat Maddox wrote: > > > > > The point here is that with a Java object, you > > know what its properties are. > > > You can look at the class definition, or the class > > browser in your IDE, or > > > use auto-completion. > > > > what if your object is a soap or rmi object? what > > if you are dynamically > > generating code, compiling it, and loading class > > files (which i have done)? > > what if you are looking at an interface that has > > only a jar file behind it - > > you can see only 10% of the available methods and > > even with those cannot see > > how they are implemented - not only that but the > > next release may add/delete > > some; in fact the object behind your interface may > > not even be the same in two > > invocations of the code. > > > > > It''s kind of the same as Java being strongly-typed > > vs Ruby. With Java, you > > > explicitly declare all the variables - with RoR, > > they''re implicitly defined > > > from the DB table. As in the article, I think > > that Java''s way would > > > probably work better in a large-scale project, > > simply because it becomes > > > much easier to view a class''s composition. > > > > or much harder since the class will be 10 times > > larger - especially for large > > projects. many, many studies have proven the fact > > that coders produce > > precisely the same number of lines of code per day > > no matter which language > > they program in. with this in mind, your comment > > strikes me as a sort of > > reverse logic : it''s like saying "if i were climbing > > a really big mountain i''d > > chose to step one inch at time instead of one foot - > > that way i''ll get to the > > top faster." although i admit that analogy is not > > quite perfect. in any case > > i would say this - i''ve written over a dozen ruby > > projects with > 3000 lines > > of code. in each case the equivalent project, > > written in java, would have > > been at least 30,000 TLOC and would have required > > more than just me to create. > > until (perhaps you have) one has written a large > > project in ruby it''s really > > not saying much to say ''you think'' it won''t scale as > > well for large projects - > > the irony here is that i''ve had a very hard time > > writing ''large'' projects - > > they simply colapse into so few lines of code > > because of ruby''s expressive > > power that i can''t seem to crack the 5000 line mark. > > > > > In the end, they''re just two different ways of > > doing the same thing, and it > > > all boils down to personal preference. > > > > you can say __exactly__ the same thing about a > > hammer and a nail-gun and > > precisely same relationship applies: one person can > > frame a door with a hammer > > while the other frames the entire house with the > > nail gun. > > > > cheers. > > > > -a > > -- > > > ==============================================================================> > | email :: ara [dot] t [dot] howard [at] noaa > > [dot] gov > > | phone :: 303.497.6469 > > | if you love the sacred and despise the ordinary, > > you are still bobbing in the > > | ocean of delusion. --lin-chi > > > ==============================================================================> > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- - Ramin
* Josef Pospisil (perails-9Vj9tDbzfuSlVyrhU4qvOw@public.gmane.org) [050331 02:39]:> there is another comparsion > http://web1.theserverside.com/articles/article.tss?l=RailsHibernate of > Java (Hibernate) with RoR. I''m not so big expert, but I think they are > worying 10x productivity :-)This was an interesting article, and I think instructive. Imagine what it would cost to hire a Hibernate expert to critique Active Record -- Mr. Peak went and did the job for free, and calmly. I think the critical points he makes can be divided into three categories: 1 - Misconceptions: there is a Rails way to do things and he missed it; or there are recent or lightly-documented features that he probably couldn''t have been aware of, and therefore saw a problem where there probably isn''t one. Perhaps getting these things in the critical documentation path for new Rails users is important. 2 - Good feature suggestions: there is something that Hibernate does well which could very easily work in the Rails Way, but just hasn''t been added (or hasn''t occurred to anyone to add). These things are low-hanging Rails enhancements that people could pick off and get their thanks from the Rails community. 3 - Well-founded critiques that need addressing but are not trivial: these are the truly valuable gems in any critique, and are worth serious consideration. I don''t see the Hibernate-puts-the-fields-in-the-comments discussion somehow hiding a "3", but rather a "1" (I liked Ara''s take on this, frankly). Building a framework in such a way that the answer to its inefficiency is "let''s make a better editor" is not a feature -- or at least I don''t want to live in a world where it''s deemed to be so. The primary "3" critique I see that falls out of this Hibernate vs. Active Record comparison is what Mr. Peak calls the "dreaded N+1 select problem". I contend that as a developer I cannot be oblivious of how database queries are issued by ActiveRecord if I want my application to run efficiently in many common usage models. We can argue whether I should expect to be oblivious, though lazy-loading in AR hints that the framework is trying to take on the burden of efficiency allowing me to be mostly oblivious... If I pull some objects and then iterate through their associated objects one-by-one I will generate N+1 queries in Rails. If I know to pre-fetch these associated objects I can often get away with 2 queries, though I have to jump through some hoops to get my data set up similarly to the comfortable N+1 query way. I get the feeling sometimes that this is AR''s "elephant in the room": whenever someone hints that AR is generating a metric assload of queries and maybe that is a problem, it seems that someone else will quickly come in and say that the person should just go and do profiling, because, well, my app runs fast enough. Were the critique true about a Rails competitor, but not true about Rails, I think some of us would rightly be pointing out this obvious inefficiency in the other framework. I think we need to recognize the elephant in the room. Premature optimization is the root of most evil, I agree. This I take to mean that unless a specific instance of profiling turns up a problem with N+1 query behavior causing a slowdown then we shouldn''t be discussing optimizations for this "issue". However, experience tells me that having N+1 queries where 2 would do is going to tend to have a significant impact at run-time, all else being equal. Not only this, but, having a background in algorithms, I can never idly condone use of an inefficient algorithm when an efficient algorithm can be implemented with equal ease. The time trade-off between an O(n^2) sorting algorithm and an O(n log n) sorting algorithm is dramatic for even common data sets: go implement bubble sort and merge sort and run them a few dozen times over a million or so strings and look at the difference in run-times. I consider implementing bubble sort (or its other O(n^2) cousins) negligent at best -- and we''re really just talking about some comparisons and arrays swaps. When a database query is typically the most expensive operation (as it is in a Rails app), it''s difficult to condone O(n) queries versus O(1) queries on real data sets -- unless the cost to the programmer is very very high. What would cause high costs to the programmer (of Rails as a framework, or of applications)? Off the top of my head I can think of a few things, and, since I''m not particularly creative, I expect the real issues to be immediately uncovered by the clearer thinkers on the list: - Lazy evaluation has such advantages that it''s best to keep it as a default, so the application programmer needs to consider when N+1 behavior is impending and then use a different construct to avoid it. This requires more thought on the part of the application developer, and may become truly convoluted. - Detecting N+1 situations without the help of the application programmer is difficult for the Rails framework (e.g., "I''ve seen 3 Company records accessed from 3 Person records -- should I look at all the Person objects and fetch their Company associations now?") - Detecting N+1 situations automatically may incur significant overhead in computation and/or data structure complexity inside Rails towards little payoff (no payoff for some class of applications). - Mis-detecting N+1 situations may incur a high query penalty, fetching a huge set of associated objects when only the first couple were actually used. - In some cases it would be useful to optimize N+1 queries away for a single action, while some applications would benefit by optimizing N+1 queries away completely, yet some applications would never want this optimization. This seems to me to say that any addressing of this "N+1 query" issue should introduce the simplest of mechanisms that could possibly work, with the least intrusive syntax. It seems that only the application developer has the knowledge to decide when N+1 optimization is warranted, and even then this should only come as a result of profiling. That is, just program without thinking about this issue, but if profiling shows a hot spot related to N+1 queries then there should be a mechanism to help with optimization. The default would be to use the current behavior. When profiling shows that N+1 queries are creating hot spots in an application then application programmers could specify that a code region (or a time region) get a constant-query behavior (where all associated objects are pulled in when an AR find is called). For example, the code-region could merely be a block: def foo(...) ActiveRecord::Base.fetch_associations do @things = Thing.find_by_name(''house'') # ... end end or the behavior could be part of an AR transaction, or perhaps (un)setting an AR instance variable would trigger the change in behavior (in which case the environment would dictate the default for the application). This isn''t really a good stab at a design, more just trying to feel out the shape of the elephant (or get the bike-shed ready for painting, depending on your point of view). Thoughts? Rick -- http://www.rickbradley.com MUPRN: 61 | both machines but random email haiku | the other three should be free | on both machines.
* Rick Bradley (rick-xSCPAUIMY+WN9aS15agKxg@public.gmane.org) [050331 15:00]:
Not sure what happened to the Subject: of that post. I''d put something
in front of the ''(was ...)'' part, but it disappeared. Well,
pick your
own topic. Probably something to do with "N+1 queries".
Rick
--
http://www.rickbradley.com MUPRN: 576
| these figures were
random email haiku | released last week, they have
| not gotten >much play.
On Thu, 31 Mar 2005, Abdullah Jibaly wrote:>>>> > many, many studies have proven the fact that coders > produce > precisely the same number of lines of code per day no > matter which > language > <<< > > So you''re saying that a coder using IBM''s WebSphere development platform or > VS.net and another using Ruby on Rails with a any text editor produce the > same amount of code per day? I find it hard to believe that ''fact''.your statement is really only adding to the assertion. i''m talking lines of code written by the __programmer__. basically this is constant per programmer and varies about 10:1 from best to worst programmers. now, code generators are not only another factor but a __negative__ one is some senses because it''s also been shown that the number of bugs relates linearly to tloc : more code of any sort (written/generated) means more bugs. think about that for a minute - it means that spewing out 1000 lines of java code vs 100 lines of ruby code will introduce, on average, 10 times as many bugs. so, not only are your (the programmer) faculties limited but tools that leverage them (generators) are going to aid/harm you with at a constant ratio. both are arguments for coding and generating in the highest level language possible to maximize the idea to lines of code ratio (what you __write__) and to simoultaneously minimize tloc. if you are interested in this a good read is http://paulgraham.com/avg.html cheers. -a -- ==============================================================================| email :: ara [dot] t [dot] howard [at] noaa [dot] gov | phone :: 303.497.6469 | if you love the sacred and despise the ordinary, you are still bobbing in the | ocean of delusion. --lin-chi ===============================================================================
Interesting thoughts Rick.
For me, a more concise (and perhaps rubyish/railsish) way to express the
programmer''s intent is something like this:
@things = Thing.greedy_find_by_name(''house'')
Where AR responds to the "greedy_" prefix to a method name by, well,
being greedy and pulling in all the records for the object graph at once.
Trevor
Rick Bradley wrote:
> For example, the code-region could merely be a block:
>
> def foo(...)
> ActiveRecord::Base.fetch_associations do
> @things = Thing.find_by_name(''house'')
> # ...
> end
> end
>
> or the behavior could be part of an AR transaction, or perhaps
> (un)setting an AR instance variable would trigger the change in
> behavior (in which case the environment would dictate the default for
> the application).
>
> This isn''t really a good stab at a design, more just trying to
feel out
> the shape of the elephant (or get the bike-shed ready for painting,
> depending on your point of view).
>
> Thoughts?
>
> Rick
I like the greedy modifier. Another idea would be to have another
argument that specifies which composite objects should be loaded:
@things = Thing.find_by_name(''house'',
''room'')
That might work in case you want to just load one composite object
that may have a huge object graph underneath it. That way you''re only
going one layer deep.
I''m not exactly sure how that''d work, and it could get messy,
but
something along those lines would be nice.
On Thu, 31 Mar 2005 12:58:56 -0800, Trevor Squires
<trevor-k8q5a0yEZAgS+FvcfC7Uqw@public.gmane.org>
wrote:> Interesting thoughts Rick.
>
> For me, a more concise (and perhaps rubyish/railsish) way to express the
> programmer''s intent is something like this:
>
> @things = Thing.greedy_find_by_name(''house'')
>
> Where AR responds to the "greedy_" prefix to a method name by,
well,
> being greedy and pulling in all the records for the object graph at once.
>
> Trevor
>
> Rick Bradley wrote:
>
> > For example, the code-region could merely be a block:
> >
> > def foo(...)
> > ActiveRecord::Base.fetch_associations do
> > @things = Thing.find_by_name(''house'')
> > # ...
> > end
> > end
> >
> > or the behavior could be part of an AR transaction, or perhaps
> > (un)setting an AR instance variable would trigger the change in
> > behavior (in which case the environment would dictate the default for
> > the application).
> >
> > This isn''t really a good stab at a design, more just trying
to feel out
> > the shape of the elephant (or get the bike-shed ready for painting,
> > depending on your point of view).
> >
> > Thoughts?
> >
> > Rick
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
On Thu, 31 Mar 2005 14:15:10 -0700, Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I like the greedy modifier. Another idea would be to have another > argument that specifies which composite objects should be loaded: > > @things = Thing.find_by_name(''house'', ''room'') > > That might work in case you want to just load one composite object > that may have a huge object graph underneath it. That way you''re only > going one layer deep. > > I''m not exactly sure how that''d work, and it could get messy, but > something along those lines would be nice. >I agree, to a point; however, I''d very much like to be able to filter the associated objects returned, as well. Something like: @things = Thing.find_all_by_type(''widget'', :associations => { :rooms, :where => "size > 10" }) That would grab me all the Thing objects with type ''widget'', and their associated rooms that are larger than 10 units. Meh, maybe going far beyond what AR''s supposed to do, but man that would be great syntax for some things that I work on :) Dave -- Dave Goodlad dgoodlad-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org or dave-eHfbeeWWzZOw5LPnMra/2Q@public.gmane.org http://david.goodlad.ca/
What was the essay saying about associated (sub) records having all their fields become strings? So person.address.zip is converted to a string... why? On Thu, 31 Mar 2005 14:15:10 -0700, Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I like the greedy modifier. Another idea would be to have another > argument that specifies which composite objects should be loaded: > > @things = Thing.find_by_name(''house'', ''room'') > > That might work in case you want to just load one composite object > that may have a huge object graph underneath it. That way you''re only > going one layer deep. > > I''m not exactly sure how that''d work, and it could get messy, but > something along those lines would be nice. > > > On Thu, 31 Mar 2005 12:58:56 -0800, Trevor Squires <trevor-k8q5a0yEZAgS+FvcfC7Uqw@public.gmane.org> wrote: > > Interesting thoughts Rick. > > > > For me, a more concise (and perhaps rubyish/railsish) way to express the > > programmer''s intent is something like this: > > > > @things = Thing.greedy_find_by_name(''house'') > > > > Where AR responds to the "greedy_" prefix to a method name by, well, > > being greedy and pulling in all the records for the object graph at once. > > > > Trevor > > > > Rick Bradley wrote: > > > > > For example, the code-region could merely be a block: > > > > > > def foo(...) > > > ActiveRecord::Base.fetch_associations do > > > @things = Thing.find_by_name(''house'') > > > # ... > > > end > > > end > > > > > > or the behavior could be part of an AR transaction, or perhaps > > > (un)setting an AR instance variable would trigger the change in > > > behavior (in which case the environment would dictate the default for > > > the application). > > > > > > This isn''t really a good stab at a design, more just trying to feel out > > > the shape of the elephant (or get the bike-shed ready for painting, > > > depending on your point of view). > > > > > > Thoughts? > > > > > > Rick > > > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
I''m not disagreeing with your conclusion, just that studies which compare lines of codes/day in different languages are pretty much worthless, because of so many factors, one of them being editors that insert template code as mentioned. LOC count only makes sense when comparing two similar projects (same language, expreience level, editors etc)... Regards, Abdullah --- "Ara.T.Howard" <Ara.T.Howard-32lpuo7BZBA@public.gmane.org> wrote:> On Thu, 31 Mar 2005, Abdullah Jibaly wrote: > > >>>> > > many, many studies have proven the fact that > coders > > produce > > precisely the same number of lines of code per day > no > > matter which > > language > > <<< > > > > So you''re saying that a coder using IBM''s > WebSphere development platform or > > VS.net and another using Ruby on Rails with a any > text editor produce the > > same amount of code per day? I find it hard to > believe that ''fact''. > > your statement is really only adding to the > assertion. i''m talking lines of > code written by the __programmer__. basically this > is constant per programmer > and varies about 10:1 from best to worst > programmers. now, code generators > are not only another factor but a __negative__ one > is some senses because it''s > also been shown that the number of bugs relates > linearly to tloc : more code > of any sort (written/generated) means more bugs. > think about that for a > minute - it means that spewing out 1000 lines of > java code vs 100 lines of > ruby code will introduce, on average, 10 times as > many bugs. so, not only are > your (the programmer) faculties limited but tools > that leverage them > (generators) are going to aid/harm you with at a > constant ratio. both are > arguments for coding and generating in the highest > level language possible to > maximize the idea to lines of code ratio (what you > __write__) and to > simoultaneously minimize tloc. > > if you are interested in this a good read is > http://paulgraham.com/avg.html > > cheers. > > -a > -- >==============================================================================> | email :: ara [dot] t [dot] howard [at] noaa> [dot] gov > | phone :: 303.497.6469 > | if you love the sacred and despise the ordinary, > you are still bobbing in the > | ocean of delusion. --lin-chi >==============================================================================> _______________________________________________> Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Pat and David - those are both good ideas that I hadn''t considered when just dealing with *my* needs. And it''s for that reason that I instinctively want to put on the brakes here. AR is really good at what it does but like Rick I find N+1 a problem - not a deal-breaker just a problem. Now piggybacking is a solution to some of that problem but it doesn''t give you a result identical to the current N+1 lazy loading. So if I take a long, cold stare at what bugs me, it''s not that I want a greedy_ modifier or an :associations filter or whatever. I simply want a way to build an object graph identical to the one I get with N+1 lazy loading... while being able to exercise greater control over hits to the DB. I wonder if trying to bloat (verbing my nouns here) AR into something that satisfies you, me and everyone else will just become... urm Hibernate. And Hibernate isn''t very good at being AR - which is why I like using AR and why I''m turning all reluctant. So maybe what I (and perhaps we) need is a way to hook into the instantiation points of AR because for me - that''s were my problem seems to lie. Maybe DHH or an AR guru can advise on how much of this conversation has merit but my first step is going to be actually reading the AR code tonight to see what''s available. Thanks for listening, Trevor David Goodlad wrote:> On Thu, 31 Mar 2005 14:15:10 -0700, Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > >>I like the greedy modifier. Another idea would be to have another >>argument that specifies which composite objects should be loaded: >> >>@things = Thing.find_by_name(''house'', ''room'') >> >>That might work in case you want to just load one composite object >>that may have a huge object graph underneath it. That way you''re only >>going one layer deep. >> >>I''m not exactly sure how that''d work, and it could get messy, but >>something along those lines would be nice. >> > > > I agree, to a point; however, I''d very much like to be able to filter > the associated objects returned, as well. Something like: > > @things = Thing.find_all_by_type(''widget'', :associations => { :rooms, > :where => "size > 10" }) > > That would grab me all the Thing objects with type ''widget'', and their > associated rooms that are larger than 10 units. > > Meh, maybe going far beyond what AR''s supposed to do, but man that > would be great syntax for some things that I work on :) > > Dave >
On Friday, April 1, 2005, 7:47:29 AM, Abdullah wrote:> I''m not disagreeing with your conclusion, just that > studies which compare lines of codes/day in different > languages are pretty much worthless, because of so > many factors, one of them being editors that insert > template code as mentioned. LOC count only makes sense > when comparing two similar projects (same language, > expreience level, editors etc)...Those factors should be discussed and evaluated, not used to discredit the whole notion. Ara specifically addressed the problem of editors that insert template code. My additional take is this: if it takes one "programmer action" to generate 20 lines of (template-driven) code, then you''re working at too low a level. The programmer didn''t explicitly write that code, but he has to maintain it. It''s static code, which doesn''t change as requirements/design/implementation change. And it''s burying the idea - the "programmer''s action" - in 20 lines of code. Compare Ruby, for instance. The programmer''s action only requires one line of code, which (in RoR''s case) probably involves some metaprogramming (background code generation) of some kind. Now which is easier to modify as requirements/design/implementation change? Ruby''s one line or XYZ''s 20 lines? In which case is it easier to find and fix bugs? I believe, but can''t prove, Ara''s assertion that #bugs is proportional to TLOC. When a programming environment is spewing out code for you, it''s saying "this code is _your_ problem". Static code generation sux. Anyway, you weren''t broadly disagreeing, so this broadside isn''t aimed at you (Abdullah) or anyone in particular. It''s just that LOC is being used as a WMD lately, so my 2 cents had to go somewhere. Cheers, Gavin
* Gavin Sinclair (gsinclair-81uBx+iSpXA0n/F98K4Iww@public.gmane.org) [050331 20:15]:> I believe, but can''t prove, Ara''s assertion that #bugs is proportional > to TLOC. When a programming environment is spewing out code for you, > it''s saying "this code is _your_ problem".Another way to look at things is that coupling (whether between classes, between packages, or between tables and classes, etc.) hampers maintenance. The more tightly coupled code is the more bugs will be introduced during maintenance. Generating more code is either completely useless (i.e., the code is just verbose but contains no real functionality), or eventually increases coupling. This is clearly true in the case of the getter/setter code so often generated by editors for Java developers (see also Hibernate). It''s not only safe to say, but would be quantifiable in a straightforward manner, that for Java code where the editor is spitting out getters and setters that the LOC is proportional to the coupling in the system. Put another way (as you''ve essentially said), as the tools are generating code they are also generating future bugs. So: Code undergoes maintenance. During maintenance higher coupling means more bugs. More LOC nearly always means more coupling. Therefore more LOC means more bugs over time -- whether the code is written by hand or by tool. The code written by tools such as those used in the Java world creates exactly the kind of high-coupling code maintainers would like to avoid. This is, of course, the entire point behind DRY, and one of the pillars of Rails'' success -- and "n-fold improvements in productivity". The thing that seems to perplex people (there *cannot* be a silver bullet(!)) about Rails is that there''s long been this trade-off: if the tools make it easy to get started they''re going to fall down for "real" tasks, or you''re going to pay for maintenance costs down the road. This is because code has always been too verbose (except for APL, which is unmaintainable ;-) and coupling has been too high; as well, the frameworks leave too much for the developer to keep re-inventing. Ruby makes the code terse, yet readable; DRY in Rails keeps the coupling low; and a well-designed framework takes the years of experience finding the commonalities of web development and puts the grunt-work behind the scenes in the framework, where it belongs, instead of expecting the developer to reinvent it yet again. Terse, maintainable, uncoupled, powerful code. Looking back at it this way it''s not rocket science, but it''s pretty clear why no other system has been able to be as close to a silver bullet without violating that legendary proscription. Rick -- http://www.rickbradley.com MUPRN: 41 | alsa makes it random email haiku | another way I had | to patch the driver.
Being tightly coupled to the database isn''t an awful thing. Both Rails and Hibernate will tightly couple your code the to db, the difference is that it''s not explicit in Rails. But change the DB schema and your code''s going to break. The trade-off in explicitly defining the properties of a class is worthwhile, in my opinion. Once you write the db schema and have an app going, it''s not likely to change. I''ve written and refactored plenty of apps that work with an existing db, and changing the schema is out of the question. Spend a little extra time explicitly defining the class, and it pays off later on as you take advantage of code inspectors while you write your app. The underyling db isn''t going to change enough to make it a huge pain to change your code. If it does, you have to reflect those changes in your code whether it''s Rails or Hibernate - and with Hibernate, you can use refactoring tools to make it a much simpler process. On Thu, 31 Mar 2005 20:34:26 -0500, Rick Bradley <rick-xSCPAUIMY+WN9aS15agKxg@public.gmane.org> wrote:> * Gavin Sinclair (gsinclair-81uBx+iSpXA0n/F98K4Iww@public.gmane.org) [050331 20:15]: > > I believe, but can''t prove, Ara''s assertion that #bugs is proportional > > to TLOC. When a programming environment is spewing out code for you, > > it''s saying "this code is _your_ problem". > > Another way to look at things is that coupling (whether between classes, > between packages, or between tables and classes, etc.) hampers > maintenance. The more tightly coupled code is the more bugs will be > introduced during maintenance. Generating more code is either > completely useless (i.e., the code is just verbose but contains no real > functionality), or eventually increases coupling. This is clearly true > in the case of the getter/setter code so often generated by editors for > Java developers (see also Hibernate). It''s not only safe to say, but > would be quantifiable in a straightforward manner, that for Java code > where the editor is spitting out getters and setters that the LOC is > proportional to the coupling in the system. Put another way (as you''ve > essentially said), as the tools are generating code they are also > generating future bugs. > > So: > > Code undergoes maintenance. During maintenance higher coupling means > more bugs. More LOC nearly always means more coupling. Therefore more > LOC means more bugs over time -- whether the code is written by hand or > by tool. The code written by tools such as those used in the Java world > creates exactly the kind of high-coupling code maintainers would like to > avoid. > > This is, of course, the entire point behind DRY, and one of the pillars > of Rails'' success -- and "n-fold improvements in productivity". > > The thing that seems to perplex people (there *cannot* be a silver > bullet(!)) about Rails is that there''s long been this trade-off: if > the tools make it easy to get started they''re going to fall down for > "real" tasks, or you''re going to pay for maintenance costs down the > road. This is because code has always been too verbose (except for APL, > which is unmaintainable ;-) and coupling has been too high; as well, the > frameworks leave too much for the developer to keep re-inventing. Ruby > makes the code terse, yet readable; DRY in Rails keeps the coupling low; > and a well-designed framework takes the years of experience finding the > commonalities of web development and puts the grunt-work behind the > scenes in the framework, where it belongs, instead of expecting the > developer to reinvent it yet again. > > Terse, maintainable, uncoupled, powerful code. Looking back at it this > way it''s not rocket science, but it''s pretty clear why no other system > has been able to be as close to a silver bullet without violating that > legendary proscription. > > Rick > -- > http://www.rickbradley.com MUPRN: 41 > | alsa makes it > random email haiku | another way I had > | to patch the driver. > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Btw, I''d like to poing out that I''m a RoR convert :) The majority of my web apps will be in RoR from now on. Some things still bother me though, like how it''s not strongly typed, and the fact that I can''t open a source file and see the exact properties a class has. It is nice and simple, but I wish there were perhaps a strict toggle that would allow you to choose stricter rules. On Thu, 31 Mar 2005 19:11:34 -0700, Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Being tightly coupled to the database isn''t an awful thing. Both > Rails and Hibernate will tightly couple your code the to db, the > difference is that it''s not explicit in Rails. But change the DB > schema and your code''s going to break. > > The trade-off in explicitly defining the properties of a class is > worthwhile, in my opinion. Once you write the db schema and have an > app going, it''s not likely to change. I''ve written and refactored > plenty of apps that work with an existing db, and changing the schema > is out of the question. Spend a little extra time explicitly defining > the class, and it pays off later on as you take advantage of code > inspectors while you write your app. The underyling db isn''t going to > change enough to make it a huge pain to change your code. If it does, > you have to reflect those changes in your code whether it''s Rails or > Hibernate - and with Hibernate, you can use refactoring tools to make > it a much simpler process. > > > On Thu, 31 Mar 2005 20:34:26 -0500, Rick Bradley <rick-xSCPAUIMY+WN9aS15agKxg@public.gmane.org> wrote: > > * Gavin Sinclair (gsinclair-81uBx+iSpXA0n/F98K4Iww@public.gmane.org) [050331 20:15]: > > > I believe, but can''t prove, Ara''s assertion that #bugs is proportional > > > to TLOC. When a programming environment is spewing out code for you, > > > it''s saying "this code is _your_ problem". > > > > Another way to look at things is that coupling (whether between classes, > > between packages, or between tables and classes, etc.) hampers > > maintenance. The more tightly coupled code is the more bugs will be > > introduced during maintenance. Generating more code is either > > completely useless (i.e., the code is just verbose but contains no real > > functionality), or eventually increases coupling. This is clearly true > > in the case of the getter/setter code so often generated by editors for > > Java developers (see also Hibernate). It''s not only safe to say, but > > would be quantifiable in a straightforward manner, that for Java code > > where the editor is spitting out getters and setters that the LOC is > > proportional to the coupling in the system. Put another way (as you''ve > > essentially said), as the tools are generating code they are also > > generating future bugs. > > > > So: > > > > Code undergoes maintenance. During maintenance higher coupling means > > more bugs. More LOC nearly always means more coupling. Therefore more > > LOC means more bugs over time -- whether the code is written by hand or > > by tool. The code written by tools such as those used in the Java world > > creates exactly the kind of high-coupling code maintainers would like to > > avoid. > > > > This is, of course, the entire point behind DRY, and one of the pillars > > of Rails'' success -- and "n-fold improvements in productivity". > > > > The thing that seems to perplex people (there *cannot* be a silver > > bullet(!)) about Rails is that there''s long been this trade-off: if > > the tools make it easy to get started they''re going to fall down for > > "real" tasks, or you''re going to pay for maintenance costs down the > > road. This is because code has always been too verbose (except for APL, > > which is unmaintainable ;-) and coupling has been too high; as well, the > > frameworks leave too much for the developer to keep re-inventing. Ruby > > makes the code terse, yet readable; DRY in Rails keeps the coupling low; > > and a well-designed framework takes the years of experience finding the > > commonalities of web development and puts the grunt-work behind the > > scenes in the framework, where it belongs, instead of expecting the > > developer to reinvent it yet again. > > > > Terse, maintainable, uncoupled, powerful code. Looking back at it this > > way it''s not rocket science, but it''s pretty clear why no other system > > has been able to be as close to a silver bullet without violating that > > legendary proscription. > > > > Rick > > -- > > http://www.rickbradley.com MUPRN: 41 > > | alsa makes it > > random email haiku | another way I had > > | to patch the driver. > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > >
Btw, I''d like to point out that I''m a RoR convert :) The majority of my web apps will be in RoR from now on. Some things still bother me though, like how it''s not strongly typed, and the fact that I can''t open a source file and see the exact properties a class has. It is nice and simple, but I wish there were perhaps a strict toggle that would allow you to choose stricter rules. On Thu, 31 Mar 2005 19:11:34 -0700, Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Being tightly coupled to the database isn''t an awful thing. Both > Rails and Hibernate will tightly couple your code the to db, the > difference is that it''s not explicit in Rails. But change the DB > schema and your code''s going to break. > > The trade-off in explicitly defining the properties of a class is > worthwhile, in my opinion. Once you write the db schema and have an > app going, it''s not likely to change. I''ve written and refactored > plenty of apps that work with an existing db, and changing the schema > is out of the question. Spend a little extra time explicitly defining > the class, and it pays off later on as you take advantage of code > inspectors while you write your app. The underyling db isn''t going to > change enough to make it a huge pain to change your code. If it does, > you have to reflect those changes in your code whether it''s Rails or > Hibernate - and with Hibernate, you can use refactoring tools to make > it a much simpler process. > > > On Thu, 31 Mar 2005 20:34:26 -0500, Rick Bradley <rick-xSCPAUIMY+WN9aS15agKxg@public.gmane.org> wrote: > > * Gavin Sinclair (gsinclair-81uBx+iSpXA0n/F98K4Iww@public.gmane.org) [050331 20:15]: > > > I believe, but can''t prove, Ara''s assertion that #bugs is proportional > > > to TLOC. When a programming environment is spewing out code for you, > > > it''s saying "this code is _your_ problem". > > > > Another way to look at things is that coupling (whether between classes, > > between packages, or between tables and classes, etc.) hampers > > maintenance. The more tightly coupled code is the more bugs will be > > introduced during maintenance. Generating more code is either > > completely useless (i.e., the code is just verbose but contains no real > > functionality), or eventually increases coupling. This is clearly true > > in the case of the getter/setter code so often generated by editors for > > Java developers (see also Hibernate). It''s not only safe to say, but > > would be quantifiable in a straightforward manner, that for Java code > > where the editor is spitting out getters and setters that the LOC is > > proportional to the coupling in the system. Put another way (as you''ve > > essentially said), as the tools are generating code they are also > > generating future bugs. > > > > So: > > > > Code undergoes maintenance. During maintenance higher coupling means > > more bugs. More LOC nearly always means more coupling. Therefore more > > LOC means more bugs over time -- whether the code is written by hand or > > by tool. The code written by tools such as those used in the Java world > > creates exactly the kind of high-coupling code maintainers would like to > > avoid. > > > > This is, of course, the entire point behind DRY, and one of the pillars > > of Rails'' success -- and "n-fold improvements in productivity". > > > > The thing that seems to perplex people (there *cannot* be a silver > > bullet(!)) about Rails is that there''s long been this trade-off: if > > the tools make it easy to get started they''re going to fall down for > > "real" tasks, or you''re going to pay for maintenance costs down the > > road. This is because code has always been too verbose (except for APL, > > which is unmaintainable ;-) and coupling has been too high; as well, the > > frameworks leave too much for the developer to keep re-inventing. Ruby > > makes the code terse, yet readable; DRY in Rails keeps the coupling low; > > and a well-designed framework takes the years of experience finding the > > commonalities of web development and puts the grunt-work behind the > > scenes in the framework, where it belongs, instead of expecting the > > developer to reinvent it yet again. > > > > Terse, maintainable, uncoupled, powerful code. Looking back at it this > > way it''s not rocket science, but it''s pretty clear why no other system > > has been able to be as close to a silver bullet without violating that > > legendary proscription. > > > > Rick > > -- > > http://www.rickbradley.com MUPRN: 41 > > | alsa makes it > > random email haiku | another way I had > > | to patch the driver. > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > >
On Thu, 31 Mar 2005 19:13:32 -0700, Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Btw, I''d like to poing out that I''m a RoR convert :) The majority of > my web apps will be in RoR from now on. Some things still bother me > though, like how it''s not strongly typed, and the fact that I can''t > open a source file and see the exact properties a class has. It is > nice and simple, but I wish there were perhaps a strict toggle that > would allow you to choose stricter rules.Hi, Have you heard of "duck typing"? http://en.wikipedia.org/wiki/Duck_typing http://www.rubygarden.org/ruby?DuckTyping http://c2.com/cgi/wiki?DuckTyping Joe
Pat Maddox wrote:>Btw, I''d like to point out that I''m a RoR convert :) The majority of >my web apps will be in RoR from now on. Some things still bother me >though, like how it''s not strongly typed, and the fact that I can''t >open a source file and see the exact properties a class has. It is > >Yeah, I am still learning RoR, but, as I see, it''s basically a rapid prototyping tool. It works great on small projects which involve one person, but I can''t imagine using it for large projects that involve creating complex hierarchies of code. You simply can''t do this without strong typing and tighter code control in general... Well, you can, but you''ll be sorry when you do. All this is fine, really -- Java is overkill for some of the smaller stuff, and RoR fills the niche nicely.
On Mar 31, 2005 10:15 PM, Stanislav Freidin <bugmaster-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote:> You simply can''t do this without > strong typing and tighter code control in general... Well, you can, but > you''ll be sorry when you do.Ahaha... Shaking my head, shrugging my shoulders... Yours truly, Nicholas
On Friday, April 1, 2005, 1:15:10 PM, Stanislav wrote:> Pat Maddox wrote:>>Btw, I''d like to point out that I''m a RoR convert :) The majority of >>my web apps will be in RoR from now on. Some things still bother me >>though, like how it''s not strongly typed, and the fact that I can''t >>open a source file and see the exact properties a class has. It is >> >> > Yeah, I am still learning RoR, but, as I see, it''s basically a rapid > prototyping tool. It works great on small projects which involve one > person, but I can''t imagine using it for large projects that involve > creating complex hierarchies of code. You simply can''t do this without > strong typing and tighter code control in general... Well, you can, but > you''ll be sorry when you do.> All this is fine, really -- Java is overkill for some of the smaller > stuff, and RoR fills the niche nicely.I won''t disagree too profusely with these points. I''ll just say that Rails (and Ruby in general) raises the bar of what a "small project" by one person can achieve by an order of magnitude. It''s also perfectly suitable for a small team with good communication. I agree it''s not suited for a cubicle farm, or for very complex projects. But that key point - that using this technology one person can achieve much more than they might have expected - is something people don''t usually take into account when coming from a different background. For existing Ruby programmers, it''s par for the course. Cheers, Gavin
That''s dead on. I don''t have much experience with RoR, but it seems to me that using it allows you to scale projects down to a more manageable size. All of a sudden, projects that may have taken 8-12 months working alone can be condensed down to 2-3. Hell, I wrote a fully functional (albeit quite ugly :) blog in a little under an hour, having never touched the language. I bet it would have taken 15-20 minutes if I had some clue of how Rails worked. I definitely can''t say that about Java, at least if I were to write it from scratch and not use any components I''ve already written. On Mar 31, 2005 8:27 PM, Gavin Sinclair <gsinclair-81uBx+iSpXA0n/F98K4Iww@public.gmane.org> wrote:> On Friday, April 1, 2005, 1:15:10 PM, Stanislav wrote: > > > Pat Maddox wrote: > > >>Btw, I''d like to point out that I''m a RoR convert :) The majority of > >>my web apps will be in RoR from now on. Some things still bother me > >>though, like how it''s not strongly typed, and the fact that I can''t > >>open a source file and see the exact properties a class has. It is > >> > >> > > Yeah, I am still learning RoR, but, as I see, it''s basically a rapid > > prototyping tool. It works great on small projects which involve one > > person, but I can''t imagine using it for large projects that involve > > creating complex hierarchies of code. You simply can''t do this without > > strong typing and tighter code control in general... Well, you can, but > > you''ll be sorry when you do. > > > All this is fine, really -- Java is overkill for some of the smaller > > stuff, and RoR fills the niche nicely. > > I won''t disagree too profusely with these points. I''ll just say that > Rails (and Ruby in general) raises the bar of what a "small project" > by one person can achieve by an order of magnitude. It''s also > perfectly suitable for a small team with good communication. I agree > it''s not suited for a cubicle farm, or for very complex projects. > > But that key point - that using this technology one person can achieve > much more than they might have expected - is something people don''t > usually take into account when coming from a different background. > For existing Ruby programmers, it''s par for the course. > > Cheers, > Gavin > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Okay, but here''s what I have in my own little dotnet world, where
I''m
trying to take RoR goodness and replicate the parts I like:
Persons persons = Person.FindAll();
persons.PrefetchAccounts();
foreach (Account a in person.Accounts)
dosomething(a);
Hopefully that''s clear. In my case, the collections of entities are a
special class unto themselves. So it was relatively easy to add a
Prefetch* function that grabs all the related entities in one shot.
If I were doing a straight sql join, I''d have 1 query. With RoR,
it''s
1+N, where N is the number of persons. With the Prefetch* function,
it''s 2 queries.
Can this be replicated in Ruby, by somehow subclassing or hacking into
container classes?
On Mar 31, 2005 5:08 PM, Trevor Squires
<trevor-k8q5a0yEZAgS+FvcfC7Uqw@public.gmane.org>
wrote:> Pat and David - those are both good ideas that I hadn''t considered
when
> just dealing with *my* needs.
>
> And it''s for that reason that I instinctively want to put on the
brakes
> here.
>
> AR is really good at what it does but like Rick I find N+1 a problem -
> not a deal-breaker just a problem.
>
> Now piggybacking is a solution to some of that problem but it
doesn''t
> give you a result identical to the current N+1 lazy loading.
>
> So if I take a long, cold stare at what bugs me, it''s not that I
want a
> greedy_ modifier or an :associations filter or whatever. I simply want
> a way to build an object graph identical to the one I get with N+1 lazy
> loading... while being able to exercise greater control over hits to the
DB.
>
> I wonder if trying to bloat (verbing my nouns here) AR into something
> that satisfies you, me and everyone else will just become... urm
> Hibernate. And Hibernate isn''t very good at being AR - which is
why I
> like using AR and why I''m turning all reluctant.
>
> So maybe what I (and perhaps we) need is a way to hook into the
> instantiation points of AR because for me - that''s were my problem
seems
> to lie.
>
> Maybe DHH or an AR guru can advise on how much of this conversation has
> merit but my first step is going to be actually reading the AR code
> tonight to see what''s available.
>
> Thanks for listening,
> Trevor
>
> David Goodlad wrote:
> > On Thu, 31 Mar 2005 14:15:10 -0700, Pat Maddox
<pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> >>I like the greedy modifier. Another idea would be to have another
> >>argument that specifies which composite objects should be loaded:
> >>
> >>@things = Thing.find_by_name(''house'',
''room'')
> >>
> >>That might work in case you want to just load one composite object
> >>that may have a huge object graph underneath it. That way
you''re only
> >>going one layer deep.
> >>
> >>I''m not exactly sure how that''d work, and it
could get messy, but
> >>something along those lines would be nice.
> >>
> >
> >
> > I agree, to a point; however, I''d very much like to be able
to filter
> > the associated objects returned, as well. Something like:
> >
> > @things = Thing.find_all_by_type(''widget'',
:associations => { :rooms,
> > :where => "size > 10" })
> >
> > That would grab me all the Thing objects with type
''widget'', and their
> > associated rooms that are larger than 10 units.
> >
> > Meh, maybe going far beyond what AR''s supposed to do, but man
that
> > would be great syntax for some things that I work on :)
> >
> > Dave
> >
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
Okay, so just take a look at this: http://page.mi.fu-berlin.de/~prechelt/Biblio/jccpprtTR.pdf In this study, for the same problem: - the Java and C++ guys took 2-3 times longer than the Perl and Python people to write their solution - the Java and C++ solutions were 2-3 times longer in language-specific LOC than the Perl and Python versions - therefore, the LOC/hour rate is consistent and is independent of the language used So you can think that LOC is language-related, and Abdullah can not believe the whole thing, and Ara can say there are many, many studies ... but I know of just this one. And it says LOC == time, independent of language. I don''t know what tools or code generators any of the coders used, and I don''t care. So until someone points out a couple of quantitative studies that refute this one quantitative study I know about, LOC == time, and if Java code is 3x that of Ruby code, then solutions take 3x longer. My form of estimation isn''t faith-based. Steve P.S. that last bit of snarkiness was pointed at Abdullah On Mar 31, 2005 2:50 PM, Ramin <i8ramin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I would have to agree that coders produce the same number of lines of > code, but the real question is, does the code perform the same > functionality or does it do more? If I write 100 lines of Java code > and all it does is make a connection to my database but the same 100 > lines of Ruby code connects to the db, retrieves my information sets > it to my model, calls my controllers and displays my view in html. > Then I would say the Ruby code does more in the same 100 lines of > code. > > But what do I know.. im a RubyNuby > > On Thu, 31 Mar 2005 11:25:17 -0800 (PST), Abdullah Jibaly > <amjibaly-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote: > > >>> > > many, many studies have proven the fact that coders > > produce > > precisely the same number of lines of code per day no > > matter which > > language > > <<< > > > > So you''re saying that a coder using IBM''s WebSphere > > development platform or VS.net and another using Ruby > > on Rails with a any text editor produce the same > > amount of code per day? I find it hard to believe that > > ''fact''. > > > > Regards, > > Abdullah > > > > --- "Ara.T.Howard" <Ara.T.Howard-32lpuo7BZBA@public.gmane.org> wrote: > > > On Thu, 31 Mar 2005, Pat Maddox wrote: > > > > > > > The point here is that with a Java object, you > > > know what its properties are. > > > > You can look at the class definition, or the class > > > browser in your IDE, or > > > > use auto-completion. > > > > > > what if your object is a soap or rmi object? what > > > if you are dynamically > > > generating code, compiling it, and loading class > > > files (which i have done)? > > > what if you are looking at an interface that has > > > only a jar file behind it - > > > you can see only 10% of the available methods and > > > even with those cannot see > > > how they are implemented - not only that but the > > > next release may add/delete > > > some; in fact the object behind your interface may > > > not even be the same in two > > > invocations of the code. > > > > > > > It''s kind of the same as Java being strongly-typed > > > vs Ruby. With Java, you > > > > explicitly declare all the variables - with RoR, > > > they''re implicitly defined > > > > from the DB table. As in the article, I think > > > that Java''s way would > > > > probably work better in a large-scale project, > > > simply because it becomes > > > > much easier to view a class''s composition. > > > > > > or much harder since the class will be 10 times > > > larger - especially for large > > > projects. many, many studies have proven the fact > > > that coders produce > > > precisely the same number of lines of code per day > > > no matter which language > > > they program in. with this in mind, your comment > > > strikes me as a sort of > > > reverse logic : it''s like saying "if i were climbing > > > a really big mountain i''d > > > chose to step one inch at time instead of one foot - > > > that way i''ll get to the > > > top faster." although i admit that analogy is not > > > quite perfect. in any case > > > i would say this - i''ve written over a dozen ruby > > > projects with > 3000 lines > > > of code. in each case the equivalent project, > > > written in java, would have > > > been at least 30,000 TLOC and would have required > > > more than just me to create. > > > until (perhaps you have) one has written a large > > > project in ruby it''s really > > > not saying much to say ''you think'' it won''t scale as > > > well for large projects - > > > the irony here is that i''ve had a very hard time > > > writing ''large'' projects - > > > they simply colapse into so few lines of code > > > because of ruby''s expressive > > > power that i can''t seem to crack the 5000 line mark. > > > > > > > In the end, they''re just two different ways of > > > doing the same thing, and it > > > > all boils down to personal preference. > > > > > > you can say __exactly__ the same thing about a > > > hammer and a nail-gun and > > > precisely same relationship applies: one person can > > > frame a door with a hammer > > > while the other frames the entire house with the > > > nail gun. > > > > > > cheers. > > > > > > -a > > > -- > > > > > ==============================================================================> > > | email :: ara [dot] t [dot] howard [at] noaa > > > [dot] gov > > > | phone :: 303.497.6469 > > > | if you love the sacred and despise the ordinary, > > > you are still bobbing in the > > > | ocean of delusion. --lin-chi > > > > > ==============================================================================> > > _______________________________________________ > > > Rails mailing list > > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > -- > - Ramin > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On Mar 31, 2005 11:30 PM, Steve Willer <steve.willer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> My form of estimation isn''t faith-based.I understand your reasoning, but you need a lot more than a single sample point to establish a measure of dependence. Think back to your stats courses and I''m sure you''ll remember all the related material. Keep in mind that a model which only includes LOC and time is a gross simplification of the number of factors involved. Your resident devil''s advocate,
On Mar 31, 2005 11:17 PM, Steve Willer <steve.willer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Can this be replicated in Ruby, by somehow subclassing or hacking into > container classes?Keep in mind that has_many and habtm associations already use subclassed container objects. Another possiblity might be: @people = Person.find_all :load_associated => :account or, if you want to load multiple assocated fields, @people = Person.find_all :load_associated => [:account, :acl_roles] Is anyone working on this? I seem to recall someone was doing some work, but can''t remember who.
Are there any studies that compare the long-term maintenance work performed on these solutions? On Mar 31, 2005 9:36 PM, Nicholas Seckar <nseckar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On Mar 31, 2005 11:30 PM, Steve Willer <steve.willer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > My form of estimation isn''t faith-based. > I understand your reasoning, but you need a lot more than a single > sample point to establish a measure of dependence. Think back to your > stats courses and I''m sure you''ll remember all the related material. > Keep in mind that a model which only includes LOC and time is a gross > simplification of the number of factors involved. > > Your resident devil''s advocate, > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Jarkko Laine wrote:> Quote: > Rails development is "at least ten times faster with Rails than you > could with a typical Java framework" > > Well, considering that Rails development will have to be very hard > with a typical Java framework, I have no problems confirming that this > must be true :-DWell, this is false. It depends on what the application is designed to do. Many advanced applications (eg. banking) can have extensive 3rd party libraries written in Java where none are available under Ruby. For many things Ruby and Rails are good. For many things Java is good. It depends on the circumstances. The quote is either too general or written by, at a time, a narrow minded and/or ignorant person. - Adam PS. I meant no offense.. really.
For sure, I absolutely semi-agree with you. That study I cited is a single sample point, but the study itself is comprised of multiple sample points. I certainly welcome any other quantitative data that anyone can point out (I haven''t been able to find any), but until then, that single study of multiple sample points will have to do for me. I wouldn''t even bother paying attention to a truly single point of data ... there''s an old quote about how the singular form of "data" is not "anecdote", or some such. On Mar 31, 2005 11:36 PM, Nicholas Seckar <nseckar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On Mar 31, 2005 11:30 PM, Steve Willer <steve.willer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > My form of estimation isn''t faith-based. > I understand your reasoning, but you need a lot more than a single > sample point to establish a measure of dependence. Think back to your > stats courses and I''m sure you''ll remember all the related material. > Keep in mind that a model which only includes LOC and time is a gross > simplification of the number of factors involved. > > Your resident devil''s advocate, >
On Apr 1, 2005 12:04 AM, Adam M. <gnuman1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Well, this is false.Jarkko was making a play on words. "It would be difficult to do Rails development with a Java framework." -- Rails isn''t a Java framework. Easier to spot if you replace Rails and Java with unrelated things. "It would be difficult to find golf balls with <insert something that doesn''t find golf balls>" (Yea, so I got lazy and gave you a lame example...)> The quote is either too general or > written by, at a time, a narrow minded and/or ignorant person.
Ara.T.Howard wrote:> your statement is really only adding to the assertion. i''m talking > lines of code written by the __programmer__. basically this is > constant per programmer and varies about 10:1 from best to worst > programmers.I agree with this.> now, code generators are not only another factor but a > __negative__ one is some senses because it''s also been shown that the > number of bugs relates linearly to tloc : more code of any sort > (written/generated) means more bugs.Those correlations are not based on generated code but hand built code. One good example of a code generator that results in less errors per tloc would be ZenTest for ruby. -- J. Lambert
On 1.4.2005, at 08:04, Adam M. wrote:> Jarkko Laine wrote: > >> Quote: >> Rails development is "at least ten times faster with Rails than you >> could with a typical Java framework" >> >> Well, considering that Rails development will have to be very hard >> with a typical Java framework, I have no problems confirming that this >> must be true :-D > > > Well, this is false. It depends on what the application is designed to > do. Many advanced applications (eg. banking) can have extensive 3rd > party libraries written in Java where none are available under Ruby.Like Ulysses said, I was making a (bad) joke about a small typo in the article. What the article said (but didn''t mean of course) would be equivalent to say that Windows GUI development is at least ten times faster with a Windows PC than with a dummy unix terminal. The smiley in the end was meant to indicate that my take wasn''t meant to be taken completely seriously.> The quote is either too general or > written by, at a time, a narrow minded and/or ignorant person.While the latter is absolutely true, I doubt that the quote should be taken as a proof of that. Yours truly, //jarkko -- Jarkko Laine http://jlaine.net http://odesign.fi _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Yes, that could work as well. How would you mixin load_associated with find_by_foo or find_by_sql, though? The prefetch thing has the advantage of being a separate API that doesn''t get in the way of current functions ... it exists purely as an additive little bit of optimization that doesn''t change the behavior otherwise. The disadvantage is just that it''s 2 queries instead of one (or if you want to load 4 related tables, it''s 5). On Mar 31, 2005 11:42 PM, Nicholas Seckar <nseckar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On Mar 31, 2005 11:17 PM, Steve Willer <steve.willer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > Can this be replicated in Ruby, by somehow subclassing or hacking into > > container classes? > Keep in mind that has_many and habtm associations already use > subclassed container objects. Another possiblity might be: > > @people = Person.find_all :load_associated => :account > > or, if you want to load multiple assocated fields, > > @people = Person.find_all :load_associated => [:account, :acl_roles] > > Is anyone working on this? I seem to recall someone was doing some > work, but can''t remember who. >
Steve Willer wrote:>Okay, so just take a look at this: >http://page.mi.fu-berlin.de/~prechelt/Biblio/jccpprtTR.pdf > >In this study, for the same problem: > > - the Java and C++ guys took 2-3 times longer than the Perl and >Python people to write their solution > - the Java and C++ solutions were 2-3 times longer in >language-specific LOC than the Perl and Python versions > - therefore, the LOC/hour rate is consistent and is independent of >the language used > >I don''t think anyone can argue that Rails isn''t faster to develop in. Obviously, it''s faster to develop in. That''s not the point. The point is (at least, from my POV) that large projects which are possible in Java would be impossible on Rails, due to its lack of strong typing, a strict class hierarchy, and of course the lack of 3rd party libraries (that last part is fixable, of course). Rails is basically like Lego, and Java is sort of like nuts and bolts (or Meccano, for those who are old like me). You can build things really quickly with Lego, but, at some point, you''re gonna need something stronger.. Also note, however, that most people will never reach that point. To-do lists, blogs, meetup sites, etc. are what most people need, and Rails is perfect for relatively simple projects such as these. Rails fills a niche, and it does it very well.
We all know what Lego is, so we all understand your point. However, just because you just made up a nice analogy that "proves" your point, doesn''t make it a fact, or even a good argument at all. All you''ve argued is that Meccano is better for building strong structures than is Lego. Instead of describing Rails as opposed to Java as an anology, please give us an example, preferably derived from reality, of something that would _actually_ be impossible to do using Rails. In other words; show, don''t tell. Regards, Tomas Jogin> I don''t think anyone can argue that Rails isn''t faster to develop in. > Obviously, it''s faster to develop in. That''s not the point. The point is > (at least, from my POV) that large projects which are possible in Java > would be impossible on Rails, due to its lack of strong typing, a strict > class hierarchy, and of course the lack of 3rd party libraries (that > last part is fixable, of course). > > Rails is basically like Lego, and Java is sort of like nuts and bolts > (or Meccano, for those who are old like me). You can build things really > quickly with Lego, but, at some point, you''re gonna need something > stronger..
Are there not "large" smalltalk projects out there? (I''m asking out of curiosity, I actually don''t know.) On Apr 1, 2005 10:03 AM, Stanislav Freidin <bugmaster-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote:> Steve Willer wrote: > > >Okay, so just take a look at this: > >http://page.mi.fu-berlin.de/~prechelt/Biblio/jccpprtTR.pdf > > > >In this study, for the same problem: > > > > - the Java and C++ guys took 2-3 times longer than the Perl and > >Python people to write their solution > > - the Java and C++ solutions were 2-3 times longer in > >language-specific LOC than the Perl and Python versions > > - therefore, the LOC/hour rate is consistent and is independent of > >the language used > > > > > I don''t think anyone can argue that Rails isn''t faster to develop in. > Obviously, it''s faster to develop in. That''s not the point. The point is > (at least, from my POV) that large projects which are possible in Java > would be impossible on Rails, due to its lack of strong typing, a strict > class hierarchy, and of course the lack of 3rd party libraries (that > last part is fixable, of course). > > Rails is basically like Lego, and Java is sort of like nuts and bolts > (or Meccano, for those who are old like me). You can build things really > quickly with Lego, but, at some point, you''re gonna need something > stronger.. > > Also note, however, that most people will never reach that point. To-do > lists, blogs, meetup sites, etc. are what most people need, and Rails is > perfect for relatively simple projects such as these. Rails fills a > niche, and it does it very well. > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On Apr 1, 2005 10:03 AM, Stanislav Freidin <bugmaster-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote:> I don''t think anyone can argue that Rails isn''t faster to develop in. > Obviously, it''s faster to develop in. That''s not the point. The point is > (at least, from my POV) that large projects which are possible in Java > would be impossible on Rails, due to its lack of strong typing, a strict > class hierarchy, and of course the lack of 3rd party libraries (that > last part is fixable, of course).OK, I''ll bite. On "impossible": Inigo Montoya: You keep using that word. I do not think it means what you think it means. (From http://www.imdb.com/title/tt0093779/quotes). I''ve been on a lot of large Java projects, and on *none* of them has their success depended upon strong typing (or the presence of or lack of a strict hierarchy, though I''m not sure where you''re going with that). Each of them has succeeded or failed based on the people working on them, not the "enterpriseness" of their technology. That being said, in each case in which there was a team full of quality people, we would''ve gotten a *lot* more done if we''d been using something less restrictive than Java. I certainly can''t think of one of them that would''ve been impossible in Ruby, even before Rails existed. Now I will grant you that on the teams which have been, er, somewhat pathetic, they probably would''ve imploded faster if we''d been using something dynamic like Ruby... but that actually would''ve been a good thing :-) As someone who''s been on both sides of the "enterprise" fence, I''m getting tired of being told what''s possible and what''s not. You''re simply the latest in a string, though... nothing personal. Thanks for letting me vent, -- Nathaniel <:((><
On Apr 1, 2005 9:03 AM, Stanislav Freidin <bugmaster-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote:> I don''t think anyone can argue that Rails isn''t faster to develop in. > Obviously, it''s faster to develop in. That''s not the point. The point is > (at least, from my POV) that large projects which are possible in Java > would be impossible on Rails, due to its lack of strong typing, a strict > class hierarchy, and of course the lack of 3rd party libraries (that > last part is fixable, of course).I hate read this sort of thing first thing in the morning. First off, Ruby is strongly typed (everything has a type), it just isn''t staticly typed. I think static type is has it''s place in a mathematical sort of application, and when it''s done in the Haskell way via type inference. For business apps, I think it is far more trouble than it is worth. Ask any Lisper or Smalltalker who have built extremely large applications in these late bound languages. I don''t understand the "strict class hierarchy" thing. Are you refering to using modules as mix-in''s? I''m not sure what 3rd party libraries you are refering to. Does ruby have dozens of ORM frameworks or web app frameworks? No, but I think that is a good thing. Take a look at what is on ruby-gems or rubyforge.org. What libraries are you looking for that ruby doesn''t offer? I''m certain there are some, but as you say, that "is fixable."> Rails is basically like Lego, and Java is sort of like nuts and bolts > (or Meccano, for those who are old like me). You can build things really > quickly with Lego, but, at some point, you''re gonna need something > stronger..I prefer to think of Ruby as clay, and Java as an Erector set. With Java, you get a lot of pieces, but they just don''t bend too far without breaking.> Also note, however, that most people will never reach that point. To-do > lists, blogs, meetup sites, etc. are what most people need, and Rails is > perfect for relatively simple projects such as these. Rails fills a > niche, and it does it very well.I agree, but that doesn''t mean that it doesn''t scale. If anything is going to keep ruby from scaling it would be lack of a sophisticated IDE to allow easy navigation of a large code base. I would even draw that into question. Sorry for the rant. The static vs. dynamic typing has been beaten into the ground, but it still gets me fired up. - Wilkes
One of the librarys we need on Ruby that we haven''t been able to find is something comparable to OpenSymphony Quartz http://opensymphony.com/quartz/ used for job scheduling, and no Cron is not enough, could you point me to something comparable? thanks. Wilkes Joiner wrote:> On Apr 1, 2005 9:03 AM, Stanislav Freidin <bugmaster-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote: > >>I don''t think anyone can argue that Rails isn''t faster to develop in. >>Obviously, it''s faster to develop in. That''s not the point. The point is >>(at least, from my POV) that large projects which are possible in Java >>would be impossible on Rails, due to its lack of strong typing, a strict >>class hierarchy, and of course the lack of 3rd party libraries (that >>last part is fixable, of course). > > > I hate read this sort of thing first thing in the morning. First off, > Ruby is strongly typed (everything has a type), it just isn''t staticly > typed. I think static type is has it''s place in a mathematical sort > of application, and when it''s done in the Haskell way via type > inference. For business apps, I think it is far more trouble than it > is worth. Ask any Lisper or Smalltalker who have built extremely > large applications in these late bound languages. > > I don''t understand the "strict class hierarchy" thing. Are you > refering to using modules as mix-in''s? > > I''m not sure what 3rd party libraries you are refering to. Does ruby > have dozens of ORM frameworks or web app frameworks? No, but I think > that is a good thing. Take a look at what is on ruby-gems or > rubyforge.org. What libraries are you looking for that ruby doesn''t > offer? I''m certain there are some, but as you say, that "is fixable." > > >>Rails is basically like Lego, and Java is sort of like nuts and bolts >>(or Meccano, for those who are old like me). You can build things really >>quickly with Lego, but, at some point, you''re gonna need something >>stronger.. > > > I prefer to think of Ruby as clay, and Java as an Erector set. With > Java, you get a lot of pieces, but they just don''t bend too far > without breaking. > > >>Also note, however, that most people will never reach that point. To-do >>lists, blogs, meetup sites, etc. are what most people need, and Rails is >>perfect for relatively simple projects such as these. Rails fills a >>niche, and it does it very well. > > > I agree, but that doesn''t mean that it doesn''t scale. If anything is > going to keep ruby from scaling it would be lack of a sophisticated > IDE to allow easy navigation of a large code base. I would even draw > that into question. > > Sorry for the rant. The static vs. dynamic typing has been beaten > into the ground, but it still gets me fired up. > > - Wilkes > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails
Right, and even if Ruby were more strongly typed and compiled and whatnot (like if you have to declare all instance variables in the class def), strong typing can''t test nearly as well as unit tests. So if you have a good set of UT''s, you''re doing much better quality-wise than a non-UT''d compiled system, regardless of language of implementation. I am curious what the definition of a "large system" in this kind of ongoing debate. Stanislav, is 70k lines enough to count as "large"? Because I was responsible for dev and architecture of a system that large. It was in Perl, and with our strong standards and good set of UT''s, I think we did quite well in avoiding bugs. There''s a data point for the dataset I''m sure you''re recording and analyzing. On Apr 1, 2005 10:25 AM, Wilkes Joiner <wilkesjoiner-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On Apr 1, 2005 9:03 AM, Stanislav Freidin <bugmaster-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote: > > I don''t think anyone can argue that Rails isn''t faster to develop in. > > Obviously, it''s faster to develop in. That''s not the point. The point is > > (at least, from my POV) that large projects which are possible in Java > > would be impossible on Rails, due to its lack of strong typing, a strict > > class hierarchy, and of course the lack of 3rd party libraries (that > > last part is fixable, of course). > > I hate read this sort of thing first thing in the morning. First off, > Ruby is strongly typed (everything has a type), it just isn''t staticly > typed. I think static type is has it''s place in a mathematical sort > of application, and when it''s done in the Haskell way via type > inference. For business apps, I think it is far more trouble than it > is worth. Ask any Lisper or Smalltalker who have built extremely > large applications in these late bound languages. > > I don''t understand the "strict class hierarchy" thing. Are you > refering to using modules as mix-in''s? > > I''m not sure what 3rd party libraries you are refering to. Does ruby > have dozens of ORM frameworks or web app frameworks? No, but I think > that is a good thing. Take a look at what is on ruby-gems or > rubyforge.org. What libraries are you looking for that ruby doesn''t > offer? I''m certain there are some, but as you say, that "is fixable." > > > Rails is basically like Lego, and Java is sort of like nuts and bolts > > (or Meccano, for those who are old like me). You can build things really > > quickly with Lego, but, at some point, you''re gonna need something > > stronger.. > > I prefer to think of Ruby as clay, and Java as an Erector set. With > Java, you get a lot of pieces, but they just don''t bend too far > without breaking. > > > Also note, however, that most people will never reach that point. To-do > > lists, blogs, meetup sites, etc. are what most people need, and Rails is > > perfect for relatively simple projects such as these. Rails fills a > > niche, and it does it very well. > > I agree, but that doesn''t mean that it doesn''t scale. If anything is > going to keep ruby from scaling it would be lack of a sophisticated > IDE to allow easy navigation of a large code base. I would even draw > that into question. > > Sorry for the rant. The static vs. dynamic typing has been beaten > into the ground, but it still gets me fired up. > > - Wilkes > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Steve, I think one disadvantage with your "prefetch" method is that the second query is pretty much a great-big-OR-statement (DBs still do that with the "in" keyword right?). Even so, it might be the only viable strategy. Note - I''m new to rails and ruby and only spent one evening reading the AR code and thinking about this. The AR code is pretty interesting and impressive - partly for what AR *doesn''t* do to get its work done... Anyhow, my feeble brain tells me that single table inheritance is a real spanner in the works for any sort of up-front "eager" sql. From what I can see in the case of STI, you have no up-front guarantee what queries will be eventually executed by traversing the object graph. It doesn''t look insurmountable. Thanks, Trevor Steve Willer wrote:> Yes, that could work as well. How would you mixin load_associated > with find_by_foo or find_by_sql, though? > > The prefetch thing has the advantage of being a separate API that > doesn''t get in the way of current functions ... it exists purely as an > additive little bit of optimization that doesn''t change the behavior > otherwise. > > The disadvantage is just that it''s 2 queries instead of one (or if you > want to load 4 related tables, it''s 5). > > > On Mar 31, 2005 11:42 PM, Nicholas Seckar <nseckar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > >>On Mar 31, 2005 11:17 PM, Steve Willer <steve.willer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> >>>Can this be replicated in Ruby, by somehow subclassing or hacking into >>>container classes? >> >>Keep in mind that has_many and habtm associations already use >>subclassed container objects. Another possiblity might be: >> >>@people = Person.find_all :load_associated => :account >> >>or, if you want to load multiple assocated fields, >> >>@people = Person.find_all :load_associated => [:account, :acl_roles] >> >>Is anyone working on this? I seem to recall someone was doing some >>work, but can''t remember who. >> > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails
Tomas Jogin wrote:>Instead of describing Rails as opposed to Java as an anology, please >give us an example, preferably derived from reality, of something that >would _actually_ be impossible to do using Rails. In other words; >show, don''t tell. > >I thouhgt I did that when I said,>>I don''t think anyone can argue that Rails isn''t faster to develop in. >>Obviously, it''s faster to develop in. That''s not the point. The point is >>(at least, from my POV) that large projects which are possible in Java >>would be impossible on Rails, due to its lack of strong typing, a strict >>class hierarchy, and of course the lack of 3rd party libraries (that >>last part is fixable, of course). >> >>Specifically, if you want to build a full-scale content management system, with fast O-R mapping (er, as in, fast-performing), detailed permissions, complex object relations (this user-created object contains these two others and references this third, etc.), versioning, and a lot of custom business logic... this will be a lot harder to do in Rails than in Java. It would not be strictly impossible (just as it won''t be impossible to do all this in assembly), of course, but it will be hard. The reason for this is that Ruby does not support strong typing, and Rails prefers to do its own O-R mapping, and to construct your objects in a certain way. This is fine, and a lot faster than anything Java has ever come up with, but it won''t work in a large project, with tens of thousands of lines of code, and multiple people involved. The lack of strong typing is really bad for that kind of situations, as are the other shortcomings of Ruby. Fortunately, very few programming projects are that large or that complex (as I''ve stated above), so you shouldn''t have to worry. Well, ok, Rails would probably perform poorly in a scientific setting where lots of fast math is needed, but that''s not really all that important.
Tomas Jogin wrote:>Instead of describing Rails as opposed to Java as an anology, please >give us an example, preferably derived from reality, of something that >would _actually_ be impossible to do using Rails. In other words; >show, don''t tell. > >I thouhgt I did that when I said,>>I don''t think anyone can argue that Rails isn''t faster to develop in. >>Obviously, it''s faster to develop in. That''s not the point. The point is >>(at least, from my POV) that large projects which are possible in Java >>would be impossible on Rails, due to its lack of strong typing, a strict >>class hierarchy, and of course the lack of 3rd party libraries (that >>last part is fixable, of course). >> >>Specifically, if you want to build a full-scale content management system, with fast O-R mapping (er, as in, fast-performing), detailed permissions, complex object relations (this user-created object contains these two others and references this third, etc.), versioning, and a lot of custom business logic... this will be a lot harder to do in Rails than in Java. It would not be strictly impossible (just as it won''t be impossible to do all this in assembly), of course, but it will be hard. The reason for this is that Ruby does not support strong typing, and Rails prefers to do its own O-R mapping, and to construct your objects in a certain way. This is fine, and a lot faster than anything Java has ever come up with, but it won''t work in a large project, with tens of thousands of lines of code, and multiple people involved. The lack of strong typing is really bad for that kind of situations, as are the other shortcomings of Ruby. Fortunately, very few programming projects are that large or that complex (as I''ve stated above), so you shouldn''t have to worry. Well, ok, Rails would probably perform poorly in a scientific setting where lots of fast math is needed, but that''s not really all that important.
Nathaniel Talbott wrote:>Now I will grant you that on the teams which have been, er, somewhat >pathetic, they probably would''ve imploded faster if we''d been using >something dynamic like Ruby... but that actually would''ve been a good >thing :-) > >First of all, you''re right, "impossible" is too strong a word. I should downgrade it to "very hard". However, I think you hit the nail on the head here, but in a different manner than you meant to. A team of excellent, stellar, genius-level programmers can solve any project in any language, in record time. That''s what makes them geniuses (er... genii ?) Sadly, the rest of us are not that smart, and that''s why we need the programming language to do some of the things for us. Java is good because there is usually only one way to do something in it, which cuts down the complexity (at the cost of some flexibility, of course). Java is also good because it has strong typing, and a strongly typed code practically FORCES you to think about your design before you start coding. I know that almost everyone on this list will immediately flame me upon reading that last line, saying things such as "design is evil", "it''s more important to get something out quickly", "I am Xtreme !", etc. So, let me just say preemptively that I am NOT advocating for some sort of an uber-huge month-long design phase, followed by an implementation phase. I am talking about the small, invisible design that all of us do in our heads, and that teams of programmers do on napkins. As soon as you start putting down some types, you are forced to think about your class hierarchies, and that forces you to think about what calls what and why, how the different parts of your project can be isolated from one another, etc. None of this is important for small projects, where the different pieces of the code are self-evident. This only becomes important in large projects, where spaghetti code == death. And of course, Java is at least slightly more efficient at run-time, which is always a plus when you need to get that response time to 40ms/user -- again, small projects don''t need this.
Steve Willer wrote:>Right, and even if Ruby were more strongly typed and compiled and >whatnot (like if you have to declare all instance variables in the >class def), strong typing can''t test nearly as well as unit tests. So >if you have a good set of UT''s, you''re doing much better quality-wise >than a non-UT''d compiled system, regardless of language of >implementation. > >Absolutely true. However, strong typing/compiling has one advantage that unit tests don''t: it''s automatic. Yes, ideally, you should always unit-test 100% of your program; however, you are human and make mistakes, and the compiler does not.>I am curious what the definition of a "large system" in this kind of >ongoing debate. Stanislav, is 70k lines enough to count as "large"? > >(see my other posts for response)
Argh ! Sorry, I must have hit "reply all" when responding to the last message... Please disregard.
On Apr 1, 2005 11:53 AM, Stanislav Freidin <bugmaster-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote:> Specifically, if you want to build a full-scale content management > system, with fast O-R mapping (er, as in, fast-performing), detailed > permissions, complex object relations (this user-created object contains > these two others and references this third, etc.), versioning, and a lot > of custom business logic... this will be a lot harder to do in Rails > than in Java. It would not be strictly impossible (just as it won''t be > impossible to do all this in assembly), of course, but it will be hard. > > The reason for this is that Ruby does not support strong typing, and > Rails prefers to do its own O-R mapping, and to construct your objects > in a certain way. This is fine, and a lot faster than anything Java has > ever come up with, but it won''t work in a large project, with tens of > thousands of lines of code, and multiple people involved. The lack of > strong typing is really bad for that kind of situations, as are the > other shortcomings of Ruby.*sigh* First of all, as has already been said, Ruby *is* strongly typed. You''re thinking of static typing, I believe. Secondly, do you have any substantiation for your claims? Any at all? Can you give one hard point of data in support of the "you must have static typing for large (in terms of complexity and/or people) projects"? Because Smalltalk provides multiple data points to the contrary. Sorry, but this meme is getting really old, and I''m tired of letting it pass. -- Nathaniel <:((><
On Apr 1, 2005 12:01 PM, Stanislav Freidin <bugmaster-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote:> Nathaniel Talbott wrote: > > >Now I will grant you that on the teams which have been, er, somewhat > >pathetic, they probably would''ve imploded faster if we''d been using > >something dynamic like Ruby... but that actually would''ve been a good > >thing :-) > > > > > First of all, you''re right, "impossible" is too strong a word. I should > downgrade it to "very hard". > > However, I think you hit the nail on the head here, but in a different > manner than you meant to. A team of excellent, stellar, genius-level > programmers can solve any project in any language, in record time. > That''s what makes them geniuses (er... genii ?) Sadly, the rest of us > are not that smart, and that''s why we need the programming language to > do some of the things for us.I''ve been on multiple projects, and I haven''t yet seen one on which Java contributed to the success. If anything, it has indirectly contributed to the failure of a few of them, because it hid the fact that the projects were failing under a mountain of inscrutable code. It is a misconception that one needs geniuses in order to succeed. It is also a misconception that technology of *any* kind can allow incompetent programmers to succeed. That said, I find it hard to imagine any team of competent programmers that wouldn''t be more productive in Ruby (and, by extension, Rails) than they could be in Java. -- Nathaniel <:((><
On Apr 1, 2005 11:53 AM, Stanislav Freidin <bugmaster-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote:> I thouhgt I did that when I said,No, you *said* "... strong typing, strict class hierarchy, and 3rd party libs" Dropping a few phrases doesn''t constitute showing. To show something, I suggest you start with a fact everyone can accept, and form a logical line of reasoning that terminates at the statement you wish to show. That seems like what you''ve tried to do. You start with saying "Rails is faster to develop in..." but then you jump straight to your conclusion. I''m not seeing the steps in between. You''ve assumed that we all agree static typing is required for large systems. Smalltalk provides an excellent counter example to this claim. In addition I''m not sure what you mean by "strict class hierarchy." Ruby''s object model inherited a lot from Smalltalk, and is very flexible, powerful, and clean. This sounds like one of those filler arguments people use so they can have a total of 3.> Specifically, if you want to build a full-scale content management > system, with fast O-R mapping (er, as in, fast-performing), detailed > permissions, complex object relations (this user-created object contains > these two others and references this third, etc.), versioning, and a lot > of custom business logic... this will be a lot harder to do in Rails > than in Java. It would not be strictly impossible (just as it won''t be > impossible to do all this in assembly), of course, but it will be hard.> The reason for this is that Ruby does not support strong typing,Convince me that it is required.> Rails prefers to do its own O-R mapping,You can use any O-R mapper for Rails'' model classes. They don''t even have to use a database.> The lack of strong typing is really badThe only time I have wished for static typing is when working with poor programmers or/and documentation.
> Specifically, if you want to build a full-scale content management > system, with fast O-R mapping (er, as in, fast-performing), detailedOh, so you''re saying Ruby/Rails can''t handle a lot of simultaneous users/requests? How many _can''t_ it handle then?> permissions, complex object relations (this user-created object contains > these two others and references this third, etc.), versioning, and a lot > of custom business logic... this will be a lot harder to do in Rails > than in Java. It would not be strictly impossible (just as it won''t be > impossible to do all this in assembly), of course, but it will be hard.How is that? How is any of what you mention near-impossible or hard using Ruby? Why should a statically typed language be used? Try to be concrete.> The reason for this is that Ruby does not support strong typing, and > Rails prefers to do its own O-R mapping, and to construct your objects > in a certain way. This is fine, and a lot faster than anything Java has > ever come up with, but it won''t work in a large project, with tens of > thousands of lines of code, and multiple people involved.It won''t work? Why is that? What about dynamically typed languages make them especially inappropriate in teams (of more than how many people)? Why does more lines equate to less approriate for dynamically typed languages? Intrigued, Tomas Jogin
* Stanislav Freidin (bugmaster-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org) [050401 11:57]:> The reason for this is that Ruby does not support strong typing, and > Rails prefers to do its own O-R mapping, and to construct your objects > in a certain way. This is fine, and a lot faster than anything Java has > ever come up with, but it won''t work in a large project, with tens of > thousands of lines of code, and multiple people involved. The lack of > strong typing is really bad for that kind of situations, as are the > other shortcomings of Ruby. > > Fortunately, very few programming projects are that large or that > complex (as I''ve stated above), so you shouldn''t have to worry.I, personally, get the impression that many of the arguments in this thread presume the conclusion (e.g., "Rails can''t be as good as Java on big projects") and state "reasons" simply as assumptions, even though the reasons may not support the argument, and as well may not even be true. It would probably help for those arguing that Ruby or Rails can''t succeed where Java is being deployed actually give examples of the sorts of things Rails cannot do, rather than simply stating Rails cannot do certain things. It would help the Rails community at least get a grip on the boundaries of Rails'' capabilities. If there are things Rails truly is poor at, then the community could address whether Rails should grow to address them, or whether Rails should exclude certain types of projects. To pick a specific nit, arguing that Rails "won''t work" when you have n*10KLOC and a cubicle farm presumes that if you started with Rails you would''ve written n*10KLOC and hired a farm of cubicle dwellers. I don''t think anyone yet has put forth evidence to test a contention to this effect -- and an experiment could well be very difficult to construct. My gut feeling is that groups who would, at this time, undertake development with Rails on a sizeable project are going to be more likely to succeed with less code and less people. This isn''t necessarily due to something inherent in Rails ("silver bullet", etc.) but primarily due to the nature of early adopters of an agile technology: those people are likely technically educated, entrepreneurial, and already pushing the efficiency of the current non-Rails agile tools they''ve already been looking for. They''re likely to have an idea of their design, a decent agile methodology, and are simply looking for an even more efficient toolchain. They would succeed with another technology(!), but they see an (at least minor) efficiency or competitiveness advantage in using Rails and therefore choose to succeed with Rails instead of the alternatives. Until such time as Rails becomes mainstream (which could frankly take years) it will be difficult to tell how the non-early-adopters fare in contrast to other so-called "Enterprise" toolchains such as .NET, J2EE+EJB+Struts+..., etc. Early on, however, the comparisons are going to be apples and oranges. Cubicle farms spewing out n*10KLOC applications are (my contention) not early adopters, not filled top-to-bottom with high productivity agile developers who are all simply trying to find a new toolset which will further push an extra %m of efficiency, etc. It''s possible that such an organization exists, but HIGHLY unlikely on average -- consider how much money and effort it takes to recruit 10 people who are highly qualified and efficient, now think about hiring 30 of them (I''ve seen it done in one place and the cost and effort required appears to be exponential). Rather, these cubicle farms are mainstream "Enterprise" shops. How these shops fare with Rails vs. Java frameworks vs. .NET will be telling, but such a comparison is some years off I''m afraid. These enterprise cubicle farms are where the bulk of the code in industry is produced (again, my contention). This is the vast area under the development efficiency bell curve, but it''s not the 2-sigma area at the high end of the curve. That area is almost entirely occupied by small groups, individuals, tight teams where each member is working at high efficiency in collaboration with his highly efficient peers. Those people are more likely to be early adopters, risk-takers, and to gain the most from using a new high-efficiency toolchain, especially while few people know about it. I believe that''s the basis behind the current Rails phenomenon. Eventually Rails will no longer be early-adopter territory, and some early adopters may move on to yet another toolchain exploiting whatever advantages it has for their personal productivity. When that begins to happen it will be interesting to see if Rails still multiplies productivity for the newer (more mainstream) user base. I.e., is Rails just a good tool for people who know how to work efficiently, or is it also a good tool for people who, on the average, don''t? Rick -- http://www.rickbradley.com MUPRN: 927 | been talking about random email haiku | trying to make some cds, you know, | record his own stuff.
On Fri, 1 Apr 2005, Stanislav Freidin wrote:> The reason for this is that Ruby does not support strong typing,no offense - but you do not understand the term ''strong typing.'' ruby is absolutely strongly typed. it is NOT statically typed - rather it is dynamically typed. perl is both neither statically typed nor strongly typed. gaining an understanding of the meaning of these terms will illuminate many aspects of this discussion. for example, ocaml, which is much, much, much more strongly typed that java, c++, or c (provably typed) is also, like ruby, dynamically typed. what this means is that the compiler/interpreter KNOWS when you type s = "foobar" that s is a string object. yet later you may say let s = 42 and the compiler/interpreter will now know that s is a number. it HAS a type and only methods of that type may be call on the object. contrast this with perl where you can do $i = "1"; print $i + 41; that is, call the ''+'' operator on a string and have it behave as a number - and you may begin to see the difference. this is really critical to understand before any constructive critisms might be put forth.> and Rails prefers to do its own O-R mapping, and to construct your objects > in a certain way. This is fine, and a lot faster than anything Java has ever > come up with, but it won''t work in a large project, with tens of thousands > of lines of code, and multiple people involved. The lack of strong typing is > really bad for that kind of situations, as are the other shortcomings of > Ruby.again. this statement is simply 100% wrong. ruby is 100% strongly typed. i think the term you want is ''statically typed.''> Fortunately, very few programming projects are that large or that complex > (as I''ve stated above), so you shouldn''t have to worry. > > Well, ok, Rails would probably perform poorly in a scientific setting where > lots of fast math is needed, but that''s not really all that important.my job is doing satelite image processing for global image products. as we speak i''m running over 20,000 jobs on our cluster (driven by under 3000 lines of ruby code) generating images larger than 3GB. we do some heavy lifting with c and idl but also quite a bit of image processing with ruby using combinations of narray and mmap. if you are interested i can send you a c program which runs twice as slowly as the same program written in ruby - btw. the ruby program is 50 times shorter too. i''m acutally working on a book about scientific application programming with ruby and can assert, from my own experience and those of research subjects, that your statement is not really based in reality. consider that nearly everyone in our building uses gsl or numerical recipes from fortran/c to do anything even mildly complex - that is to say they are simply calling canned sub-routines. doing the same thing in ruby - calling a gsl routine - is, of course, of exactly the same cost. the real ironly is that most fortran codes are doing things like parsing input files and contructing pathnames before simply calling a library routine. it''s always the same old story : good algorithims and intelligent use of io make fast programs. period. cheers. -a -- ==============================================================================| email :: ara [dot] t [dot] howard [at] noaa [dot] gov | phone :: 303.497.6469 | if you love the sacred and despise the ordinary, you are still bobbing in the | ocean of delusion. --lin-chi ===============================================================================
On Fri, 1 Apr 2005, Stanislav Freidin wrote:> Nathaniel Talbott wrote: > >> Now I will grant you that on the teams which have been, er, somewhat >> pathetic, they probably would''ve imploded faster if we''d been using >> something dynamic like Ruby... but that actually would''ve been a good >> thing :-) >> > First of all, you''re right, "impossible" is too strong a word. I should > downgrade it to "very hard". > > However, I think you hit the nail on the head here, but in a different > manner than you meant to. A team of excellent, stellar, genius-level > programmers can solve any project in any language, in record time. That''s > what makes them geniuses (er... genii ?) Sadly, the rest of us are not that > smart, and that''s why we need the programming language to do some of the > things for us. Java is good because there is usually only one way to do > something in it, which cuts down the complexity (at the cost of some > flexibility, of course). Java is also good because it has strong typing, and > a strongly typed code practically FORCES you to think about your design > before you start coding.java is strongly typed. ruby is strongly typed. python is strongly typed. ocaml is strongly typed. fortran is strongly typed. c is strongly typed. perl is not strongly typed. sh is not strongly typed. which one should i choose? typing has absolutely nothing to do with imposing a sound design - otherwise fortran programs would have much better designs that python ones. __static_typing__ (which i think you mean to say) can help catch some errors at compiletime vs. runtime. but even this does nothing to your design and is only one thing amoungst a plethora of factors influencing the design and implementation of a large project. -a -- ==============================================================================| email :: ara [dot] t [dot] howard [at] noaa [dot] gov | phone :: 303.497.6469 | if you love the sacred and despise the ordinary, you are still bobbing in the | ocean of delusion. --lin-chi ===============================================================================
* Ara.T.Howard <Ara.T.Howard-32lpuo7BZBA@public.gmane.org> [2005-04-01 10:53:46 -0700]:> java is strongly typed. ruby is strongly typed. python is strongly typed. > ocaml is strongly typed. fortran is strongly typed. c is strongly typed.I thought C was weakly typed. -- Jim Freeze Code Red. Code Ruby
On Fri, 1 Apr 2005, Jim Freeze wrote:> * Ara.T.Howard <Ara.T.Howard-32lpuo7BZBA@public.gmane.org> [2005-04-01 10:53:46 -0700]: > >> java is strongly typed. ruby is strongly typed. python is strongly typed. >> ocaml is strongly typed. fortran is strongly typed. c is strongly typed. > > I thought C was weakly typed.good catch. it is, strictly speaking. but if you ignore typedefs, enums, and type coercion it''s basically strongly typed. it''s probably more accurate to call both c and c++ weakly typed. cheers. -a -- ==============================================================================| email :: ara [dot] t [dot] howard [at] noaa [dot] gov | phone :: 303.497.6469 | if you love the sacred and despise the ordinary, you are still bobbing in the | ocean of delusion. --lin-chi ===============================================================================
Oh man! Just another "my web framework is bigger/better than yours" =D I won''t use Rails if (some examples): - I have a "complex" class design (I mean, N levels of subclassing, "interface" tables, etc...) -- Reason: I really don''t want to write custom SQL just to bring performance (I''d prefer tons of joins instead of tons of queries) I need to communicate w/ other systems -- Reason a) I don''t want to use "ugly" field names on my application code, such as TABLE01234.FIELDAB23456. So, the mapping strategy is the best approach to keep my code clean. Some applications uses some "strange" naming convenion for databases/tables/fields: "tbl_mytable", "str_field", "bol_field", etc... Its almost acceptable to access their values using something like "class.str_my_ugly_field", but have anyone used SAP and/or PeopleSoft? That table/field names are really (I mean: REALLY) ugly =) And no, thanks, I don''t want to use views just because its the best solution that can be done "in Rails". Its too "hacky" for me. -- Reason b) Does Ruby have some "messaging" service, such as JMS (I''m serious, I don''t know) ? And the decisive, and PERSONAL, one (shame on me): I don''t trust enough in Rails, since its a "new" framework. And I don''t trust myself doing huge things in Rails. Obviously, w/ more time, Rails will be getting more and more trust from the community, but today, its just a "must know" technology, to develop small applications "today" and, maybe, big applications "tomorrow". I''m not nuts (though) to start a "billing application for a huge telephony company" in Rails. I have more trust on Java w/ EJB than RoR for a "high risk" application such that. In time: Ruby (so, Rails too) can do everything, just like in any another language. Rails is a good web framework just because it increases the development productivity. But if I have to hand write SQL, write my persistence strategy (to save on filesystem, instead a database), write my l10n kit and others, Rails is loosing its most valuable feature. (omg, I''m really nuts... i''ll be crucified!!!) regards, juca On Apr 1, 2005 2:17 PM, Nicholas Seckar <nseckar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > On Apr 1, 2005 11:53 AM, Stanislav Freidin <bugmaster-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> > wrote: > > I thouhgt I did that when I said, > No, you *said* "... strong typing, strict class hierarchy, and 3rd party > libs" > > Dropping a few phrases doesn''t constitute showing. To show something, > I suggest you start with a fact everyone can accept, and form a > logical line of reasoning that terminates at the statement you wish to > show. That seems like what you''ve tried to do. You start with saying > "Rails is faster to develop in..." but then you jump straight to your > conclusion. I''m not seeing the steps in between. > > You''ve assumed that we all agree static typing is required for large > systems. Smalltalk provides an excellent counter example to this > claim. In addition I''m not sure what you mean by "strict class > hierarchy." Ruby''s object model inherited a lot from Smalltalk, and is > very flexible, powerful, and clean. This sounds like one of those > filler arguments people use so they can have a total of 3. > > > Specifically, if you want to build a full-scale content management > > system, with fast O-R mapping (er, as in, fast-performing), detailed > > permissions, complex object relations (this user-created object contains > > these two others and references this third, etc.), versioning, and a lot > > of custom business logic... this will be a lot harder to do in Rails > > than in Java. It would not be strictly impossible (just as it won''t be > > impossible to do all this in assembly), of course, but it will be hard. > > > The reason for this is that Ruby does not support strong typing, > Convince me that it is required. > > > Rails prefers to do its own O-R mapping, > You can use any O-R mapper for Rails'' model classes. They don''t even > have to use a database. > > > The lack of strong typing is really bad > The only time I have wished for static typing is when working with > poor programmers or/and documentation. > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- juraci krohling costa http://jkcosta.info _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Here''s the main difference I see between Ruby and Java, as far as the
typing goes. I''ll admit that this whole discussion has gotten me very
confused between strongly-typed, weakly-typed, etc. Anyway, the
difference is that Java code is self-documenting code. Here are two
classes, in Java and Ruby:
public class Duck {
String name;
int weight;
public void setName(String name) { this.name = name; }
public String getName() { return name; }
public void setWeight(int weight) { this.weight = weight; }
public int getWeight() { return weight; }
public void quack() { System.out.println("quack"); }
}
class Duck
def quack
puts "quack"
end
end
Now there''s no denying that the Ruby code is shorter, and if they both
use the same data source, they''ll have the same properties and
function the same. But I can look at the Java code and know what it
actually does. If I look at the Ruby version, I''ve got no clue.
Easily solved by good documentation, of course. And a decent
programmer can figure it out enough, document it so he knows for the
future. The fact of the matter is that most programmers you encounter
aren''t good programmers, and even more don''t document.
Self-documenting code, like Java, makes things a lot easier, imo.
On Apr 1, 2005 10:53 AM, Ara.T.Howard
<Ara.T.Howard-32lpuo7BZBA@public.gmane.org> wrote:> On Fri, 1 Apr 2005, Stanislav Freidin wrote:
>
> > Nathaniel Talbott wrote:
> >
> >> Now I will grant you that on the teams which have been, er,
somewhat
> >> pathetic, they probably would''ve imploded faster if
we''d been using
> >> something dynamic like Ruby... but that actually would''ve
been a good
> >> thing :-)
> >>
> > First of all, you''re right, "impossible" is too
strong a word. I should
> > downgrade it to "very hard".
> >
> > However, I think you hit the nail on the head here, but in a different
> > manner than you meant to. A team of excellent, stellar, genius-level
> > programmers can solve any project in any language, in record time.
That''s
> > what makes them geniuses (er... genii ?) Sadly, the rest of us are not
that
> > smart, and that''s why we need the programming language to do
some of the
> > things for us. Java is good because there is usually only one way to
do
> > something in it, which cuts down the complexity (at the cost of some
> > flexibility, of course). Java is also good because it has strong
typing, and
> > a strongly typed code practically FORCES you to think about your
design
> > before you start coding.
>
> java is strongly typed. ruby is strongly typed. python is strongly typed.
> ocaml is strongly typed. fortran is strongly typed. c is strongly typed.
>
> perl is not strongly typed. sh is not strongly typed.
>
> which one should i choose?
>
> typing has absolutely nothing to do with imposing a sound design -
otherwise
> fortran programs would have much better designs that python ones.
>
> __static_typing__ (which i think you mean to say) can help catch some
errors
> at compiletime vs. runtime. but even this does nothing to your design and
is
> only one thing amoungst a plethora of factors influencing the design and
> implementation of a large project.
>
> -a
> --
>
==============================================================================>
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
> | phone :: 303.497.6469
> | if you love the sacred and despise the ordinary, you are still bobbing in
the
> | ocean of delusion. --lin-chi
>
==============================================================================>
_______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
On Apr 1, 2005, at 2:55 PM, Pat Maddox wrote:> Here''s the main difference I see between Ruby and Java, as far as the > typing goes. I''ll admit that this whole discussion has gotten me very > confused between strongly-typed, weakly-typed, etc. Anyway, the > difference is that Java code is self-documenting code. Here are two > classes, in Java and Ruby: > > public class Duck { > String name; > int weight; > > public void setName(String name) { this.name = name; } > public String getName() { return name; } > public void setWeight(int weight) { this.weight = weight; } > public int getWeight() { return weight; } > > public void quack() { System.out.println("quack"); } > } > > class Duck > def quack > puts "quack" > end > end > > Now there''s no denying that the Ruby code is shorter, and if they both > use the same data source, they''ll have the same properties and > function the same. But I can look at the Java code and know what it > actually does. If I look at the Ruby version, I''ve got no clue.That''s probably because these two classes are not functionally equivalent. You don''t just magically get name, weight, or whatever else you can imagine with the Ruby class. Let''s stop this Ruby vs Java nonsense, especially if facts are going to be discarded. -Scott _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Pat, maybe I''m too new or something but those two classes
aren''t
equivalent are they? Was that your intention?
Off the top of my head isn''t the ruby version more like this?
class Duck
attr_accessor :name, :weight
def quack
puts "quack"
end
end
Trevor
Pat Maddox wrote:> Here''s the main difference I see between Ruby and Java, as far as
the
> typing goes. I''ll admit that this whole discussion has gotten me
very
> confused between strongly-typed, weakly-typed, etc. Anyway, the
> difference is that Java code is self-documenting code. Here are two
> classes, in Java and Ruby:
>
> public class Duck {
> String name;
> int weight;
>
> public void setName(String name) { this.name = name; }
> public String getName() { return name; }
> public void setWeight(int weight) { this.weight = weight; }
> public int getWeight() { return weight; }
>
> public void quack() { System.out.println("quack"); }
> }
>
> class Duck
> def quack
> puts "quack"
> end
> end
>
> Now there''s no denying that the Ruby code is shorter, and if they
both
> use the same data source, they''ll have the same properties and
> function the same. But I can look at the Java code and know what it
> actually does. If I look at the Ruby version, I''ve got no clue.
>
> Easily solved by good documentation, of course. And a decent
> programmer can figure it out enough, document it so he knows for the
> future. The fact of the matter is that most programmers you encounter
> aren''t good programmers, and even more don''t document.
> Self-documenting code, like Java, makes things a lot easier, imo.
>
Actually, they aren''t the same, since he doesn''t extended ActiveRecord::Base :-) So, its not the difference between "ruby" and "java", but between "value object" (or "pojo", or "dto") in most Java frameworks and in Rails. regards, juca On Apr 1, 2005 5:05 PM, Trevor Squires <trevor-k8q5a0yEZAgS+FvcfC7Uqw@public.gmane.org> wrote:> > Pat, maybe I''m too new or something but those two classes aren''t > equivalent are they? Was that your intention? > > Off the top of my head isn''t the ruby version more like this? > > class Duck > attr_accessor :name, :weight > > def quack > puts "quack" > end > end > > Trevor > > Pat Maddox wrote: > > Here''s the main difference I see between Ruby and Java, as far as the > > typing goes. I''ll admit that this whole discussion has gotten me very > > confused between strongly-typed, weakly-typed, etc. Anyway, the > > difference is that Java code is self-documenting code. Here are two > > classes, in Java and Ruby: > > > > public class Duck { > > String name; > > int weight; > > > > public void setName(String name) { this.name <http://this.name> = name; > } > > public String getName() { return name; } > > public void setWeight(int weight) { this.weight = weight; } > > public int getWeight() { return weight; } > > > > public void quack() { System.out.println("quack"); } > > } > > > > class Duck > > def quack > > puts "quack" > > end > > end > > > > Now there''s no denying that the Ruby code is shorter, and if they both > > use the same data source, they''ll have the same properties and > > function the same. But I can look at the Java code and know what it > > actually does. If I look at the Ruby version, I''ve got no clue. > > > > Easily solved by good documentation, of course. And a decent > > programmer can figure it out enough, document it so he knows for the > > future. The fact of the matter is that most programmers you encounter > > aren''t good programmers, and even more don''t document. > > Self-documenting code, like Java, makes things a lot easier, imo. > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- juraci krohling costa http://jkcosta.info _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
You don''t need the accessors though. If there''s a name and weight field in the db, you can do myDuck.name = "Donald" You can''t take a look at the class and know that there''s a name field, though On Apr 1, 2005 1:05 PM, Trevor Squires <trevor-k8q5a0yEZAgS+FvcfC7Uqw@public.gmane.org> wrote:> Pat, maybe I''m too new or something but those two classes aren''t > equivalent are they? Was that your intention? > > Off the top of my head isn''t the ruby version more like this? > > class Duck > attr_accessor :name, :weight > > def quack > puts "quack" > end > end > > Trevor > > Pat Maddox wrote: > > Here''s the main difference I see between Ruby and Java, as far as the > > typing goes. I''ll admit that this whole discussion has gotten me very > > confused between strongly-typed, weakly-typed, etc. Anyway, the > > difference is that Java code is self-documenting code. Here are two > > classes, in Java and Ruby: > > > > public class Duck { > > String name; > > int weight; > > > > public void setName(String name) { this.name = name; } > > public String getName() { return name; } > > public void setWeight(int weight) { this.weight = weight; } > > public int getWeight() { return weight; } > > > > public void quack() { System.out.println("quack"); } > > } > > > > class Duck > > def quack > > puts "quack" > > end > > end > > > > Now there''s no denying that the Ruby code is shorter, and if they both > > use the same data source, they''ll have the same properties and > > function the same. But I can look at the Java code and know what it > > actually does. If I look at the Ruby version, I''ve got no clue. > > > > Easily solved by good documentation, of course. And a decent > > programmer can figure it out enough, document it so he knows for the > > future. The fact of the matter is that most programmers you encounter > > aren''t good programmers, and even more don''t document. > > Self-documenting code, like Java, makes things a lot easier, imo. > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
if you want to campare apples to apples the Java would be
public class Duck {
String name;
int weight;
public void quack() { System.out.println("quack"); }
}
getters and setters are convention not requirements
after that they''re pretty equally NON-documenting but if you think
getters and setters are helpful for documentation then add them to
your Ruby classes.
-Kate
(masukomi-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org)
On Apr 1, 2005 2:55 PM, Pat Maddox
<pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:> Here''s the main difference I see between Ruby and Java, as far as
the
> typing goes. I''ll admit that this whole discussion has gotten me
very
> confused between strongly-typed, weakly-typed, etc. Anyway, the
> difference is that Java code is self-documenting code. Here are two
> classes, in Java and Ruby:
>
> public class Duck {
> String name;
> int weight;
>
> public void setName(String name) { this.name = name; }
> public String getName() { return name; }
> public void setWeight(int weight) { this.weight = weight; }
> public int getWeight() { return weight; }
>
> public void quack() { System.out.println("quack"); }
> }
>
> class Duck
> def quack
> puts "quack"
> end
> end
>
> Now there''s no denying that the Ruby code is shorter, and if they
both
> use the same data source, they''ll have the same properties and
> function the same. But I can look at the Java code and know what it
> actually does. If I look at the Ruby version, I''ve got no clue.
>
> Easily solved by good documentation, of course. And a decent
> programmer can figure it out enough, document it so he knows for the
> future. The fact of the matter is that most programmers you encounter
> aren''t good programmers, and even more don''t document.
> Self-documenting code, like Java, makes things a lot easier, imo.
>
>
> On Apr 1, 2005 10:53 AM, Ara.T.Howard
<Ara.T.Howard-32lpuo7BZBA@public.gmane.org> wrote:
> > On Fri, 1 Apr 2005, Stanislav Freidin wrote:
> >
> > > Nathaniel Talbott wrote:
> > >
> > >> Now I will grant you that on the teams which have been, er,
somewhat
> > >> pathetic, they probably would''ve imploded faster if
we''d been using
> > >> something dynamic like Ruby... but that actually
would''ve been a good
> > >> thing :-)
> > >>
> > > First of all, you''re right, "impossible" is
too strong a word. I should
> > > downgrade it to "very hard".
> > >
> > > However, I think you hit the nail on the head here, but in a
different
> > > manner than you meant to. A team of excellent, stellar,
genius-level
> > > programmers can solve any project in any language, in record
time. That''s
> > > what makes them geniuses (er... genii ?) Sadly, the rest of us
are not that
> > > smart, and that''s why we need the programming language
to do some of the
> > > things for us. Java is good because there is usually only one way
to do
> > > something in it, which cuts down the complexity (at the cost of
some
> > > flexibility, of course). Java is also good because it has strong
typing, and
> > > a strongly typed code practically FORCES you to think about your
design
> > > before you start coding.
> >
> > java is strongly typed. ruby is strongly typed. python is strongly
typed.
> > ocaml is strongly typed. fortran is strongly typed. c is strongly
typed.
> >
> > perl is not strongly typed. sh is not strongly typed.
> >
> > which one should i choose?
> >
> > typing has absolutely nothing to do with imposing a sound design -
otherwise
> > fortran programs would have much better designs that python ones.
> >
> > __static_typing__ (which i think you mean to say) can help catch some
errors
> > at compiletime vs. runtime. but even this does nothing to your design
and is
> > only one thing amoungst a plethora of factors influencing the design
and
> > implementation of a large project.
> >
> > -a
> > --
> >
==============================================================================>
> | email :: ara [dot] t [dot] howard [at] noaa [dot] gov
> > | phone :: 303.497.6469
> > | if you love the sacred and despise the ordinary, you are still
bobbing in the
> > | ocean of delusion. --lin-chi
> >
==============================================================================>
> _______________________________________________
> > Rails mailing list
> > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> >
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
Who said anything about a db? Perhaps if the class extended ActiveRecord::Base, that might be a valid point.> You don''t need the accessors though. If there''s a name and weight > field in the db, you can do > > myDuck.name = "Donald" > > You can''t take a look at the class and know that there''s a name field, > though > > On Apr 1, 2005 1:05 PM, Trevor Squires <trevor-k8q5a0yEZAgS+FvcfC7Uqw@public.gmane.org> wrote: >> Pat, maybe I''m too new or something but those two classes aren''t >> equivalent are they? Was that your intention? >> >> Off the top of my head isn''t the ruby version more like this? >> >> class Duck >> attr_accessor :name, :weight >> >> def quack >> puts "quack" >> end >> end >> >> Trevor >> >> Pat Maddox wrote: >> > Here''s the main difference I see between Ruby and Java, as far as the >> > typing goes. I''ll admit that this whole discussion has gotten me very >> > confused between strongly-typed, weakly-typed, etc. Anyway, the >> > difference is that Java code is self-documenting code. Here are two >> > classes, in Java and Ruby: >> > >> > public class Duck { >> > String name; >> > int weight; >> > >> > public void setName(String name) { this.name = name; } >> > public String getName() { return name; } >> > public void setWeight(int weight) { this.weight = weight; } >> > public int getWeight() { return weight; } >> > >> > public void quack() { System.out.println("quack"); } >> > } >> > >> > class Duck >> > def quack >> > puts "quack" >> > end >> > end >> > >> > Now there''s no denying that the Ruby code is shorter, and if they both >> > use the same data source, they''ll have the same properties and >> > function the same. But I can look at the Java code and know what it >> > actually does. If I look at the Ruby version, I''ve got no clue. >> > >> > Easily solved by good documentation, of course. And a decent >> > programmer can figure it out enough, document it so he knows for the >> > future. The fact of the matter is that most programmers you encounter >> > aren''t good programmers, and even more don''t document. >> > Self-documenting code, like Java, makes things a lot easier, imo. >> > >> >> _______________________________________________ >> Rails mailing list >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >---------- Scanned for viruses by ClamAV
Sorry, I left that out. Duck should extend ActiveRecord::Base On Apr 1, 2005 1:40 PM, Kevin Williams <kevin-P4szbAuRZ8UqDJ6do+/SaQ@public.gmane.org> wrote:> Who said anything about a db? Perhaps if the class extended > ActiveRecord::Base, that might be a valid point. > > > You don''t need the accessors though. If there''s a name and weight > > field in the db, you can do > > > > myDuck.name = "Donald" > > > > You can''t take a look at the class and know that there''s a name field, > > though > > > > On Apr 1, 2005 1:05 PM, Trevor Squires <trevor-k8q5a0yEZAgS+FvcfC7Uqw@public.gmane.org> wrote: > >> Pat, maybe I''m too new or something but those two classes aren''t > >> equivalent are they? Was that your intention? > >> > >> Off the top of my head isn''t the ruby version more like this? > >> > >> class Duck > >> attr_accessor :name, :weight > >> > >> def quack > >> puts "quack" > >> end > >> end > >> > >> Trevor > >> > >> Pat Maddox wrote: > >> > Here''s the main difference I see between Ruby and Java, as far as the > >> > typing goes. I''ll admit that this whole discussion has gotten me very > >> > confused between strongly-typed, weakly-typed, etc. Anyway, the > >> > difference is that Java code is self-documenting code. Here are two > >> > classes, in Java and Ruby: > >> > > >> > public class Duck { > >> > String name; > >> > int weight; > >> > > >> > public void setName(String name) { this.name = name; } > >> > public String getName() { return name; } > >> > public void setWeight(int weight) { this.weight = weight; } > >> > public int getWeight() { return weight; } > >> > > >> > public void quack() { System.out.println("quack"); } > >> > } > >> > > >> > class Duck > >> > def quack > >> > puts "quack" > >> > end > >> > end > >> > > >> > Now there''s no denying that the Ruby code is shorter, and if they both > >> > use the same data source, they''ll have the same properties and > >> > function the same. But I can look at the Java code and know what it > >> > actually does. If I look at the Ruby version, I''ve got no clue. > >> > > >> > Easily solved by good documentation, of course. And a decent > >> > programmer can figure it out enough, document it so he knows for the > >> > future. The fact of the matter is that most programmers you encounter > >> > aren''t good programmers, and even more don''t document. > >> > Self-documenting code, like Java, makes things a lot easier, imo. > >> > > >> > >> _______________________________________________ > >> Rails mailing list > >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > >> http://lists.rubyonrails.org/mailman/listinfo/rails > >> > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > ---------- > Scanned for viruses by ClamAV > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
In article <f38b43ef0504010904256c7c90-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>, ntalbott- Re5JQEeQqe8AvxtiuMwx3w-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org says...> Can you give one hard point of data in support of the "you must have > static typing for large (in terms of complexity and/or people) > projects"? Because Smalltalk provides multiple data points to the > contrary.In the old days, all the AOL server code was written in PL/1, the native language of our minicomputers. I''d say PL/1 is weakly typed; you define a pointer as simply a "pointer", and it can point to any struct. And I''d say AOL is large, though obviously bigger today than then. As a result of PL/1''s lack of type support, all our code double-checked the structure type (via extra "type" fields, versioning, and the like) when it received a message that supposedly contained a certain struct. I can''t remember a single time that I ever saw a "this received; that expected" that would have been solved or even detected, by stronger typing. It was always a state-machine problem, and it was usually on the first day of development, right after the first compile, when you realized you forgot something obvious. Never saw it in production, certainly. As others have said, accidentally assigning a "cucumber" object to a mailing list of "people" just isn''t the type of mistake actual programmers make. -- Jay Levitt | Wellesley, MA | I feel calm. I feel ready. I can only Faster: jay at jay dot fm | conclude that''s because I don''t have a http://www.jay.fm | full grasp of the situation. - Mark Adler
>>>>> I can look at the Java code and know what it >>>>> actually does. If I look at the Ruby version, I''ve got no clue.If you look at the Ruby version and know the database structure, then you know exactly what is going on. The Rails philosophy is don''t repeat yourself (DRY), and writing code like you did in the Java version is repeating yourself since the database already has that information. You may not agree with DRY, in which case you are absolutely free to do things like: class Duck < ActiveRecord::Base def name=(n) super n end def name super end def weight=(n) super n end def weight super end def quack puts "quack" end end But again, you are repeating yourself unnecessarily. Can you think of a time when you don''t want your developers to be intimately familiar with the database structure? If not, then why repeat something that your developers are intimately familiar with? -Lucas http://tech.rufy.com/
On Apr 1, 2005 1:58 PM, Lucas Carlson <rails-1eRuzFDw/cg@public.gmane.org> wrote:> >>>>> I can look at the Java code and know what it > >>>>> actually does. If I look at the Ruby version, I''ve got no clue. > > If you look at the Ruby version and know the database structure, then > you know exactly what is going on. The Rails philosophy is don''t repeat > yourself (DRY), and writing code like you did in the Java version is > repeating yourself since the database already has that information.And if you don''t know the database structure? I know it''s unlikely, but I also don''t think you should HAVE to know about the database structure in order to use it. Consider a scenario where one programmer writes all the model classes, and passes them around to everyone else in the team to use. If I''m a different part of the team, and want to use a Duck, I should be able to just use it without having to look at the db. I don''t see having the same variable names in the DB as in the code as repeating yourself. I see it as a division between layers, which is simply good architecture.> > You may not agree with DRY, in which case you are absolutely free to do > things like: > > class Duck < ActiveRecord::Base > def name=(n) > super n > end > > def name > super > end > > def weight=(n) > super n > end > > def weight > super > end > > def quack > puts "quack" > end > end > > But again, you are repeating yourself unnecessarily. > > Can you think of a time when you don''t want your developers to be > intimately familiar with the database structure? If not, then why > repeat something that your developers are intimately familiar with?As I said above, the people using the model classes aren''t always the same as those writing them. The example I presented is very simple, but I think that illustrates the point fairly well. For a class as simple as that, there should be no reason to have to look to the database to figure out what it is.
> And of course, Java is at least slightly more efficient at run-time, > which is always a plus when you need to get that response time to > 40ms/user -- again, small projects don''t need this.This is the only concrete example you''ve given. 40ms/user amounts to 25 requests/second. We have projects that process 1,000 requests/second (TJ/bougyman and his 10-machine cluster doing mortgage application processing with a Rails application). So getting 25 req/sec seems like a fairly doable task with a decent hardware and a bit of tuning. -- David Heinemeier Hansson, http://www.basecamphq.com/ -- Web-based Project Management http://www.rubyonrails.org/ -- Web-application framework for Ruby http://www.loudthinking.com/ -- Broadcasting Brain
> I don''t see having the same variable names in the DB as in the code as > repeating yourself. I see it as a division between layers, which is > simply good architecture.It is far from a division between layers, it is explicitly tying two layers together. For example, changing a column name in the DB requires you to change the Java getters and setters. DRY is all about compartimentalizing your code, it says that if there is a change to be made, you should theoretically only have to change one piece of the project. This is far from the case in any J2EE example I have ever seen. Again, you may not agree with DRY. You may think that repeating yourself is necessary sometimes. This is probably why you like Java frameworks more than Rails, and that is just fine. I have a brilliant programmer friend who does Java development and he had to spend 6 hours one day simply changing the name of a single button. This was because the J2EE app was not DRY and he had to track down many places that needed to be changed. This is why I prefer DRY apps.> And if you don''t know the database structure?If you don''t know the database structure, you simply don''t know what you are doing. The only difference between the Java version and the Rails version in your example is where you go to learn about the database structure. I personally would never want any programmer on a team that didn''t know the database structure, that is just asking for trouble and misunderstandings. Even if one person was doing model work and one was doing controller/view work, I would want them both to know the database backend, I think that''s the heart of most web development. Furthermore, your point is completely moot since Rails does not require you to be DRY, it only encourages it. You can be just as explicit in Rails as you are in Java if you would like. -Lucas http://tech.rufy.com/
>> And of course, Java is at least slightly more efficient at run-time, >> which is always a plus when you need to get that response time to >> 40ms/user -- again, small projects don''t need this.Where is the proof? Show me the numbers. I am not saying that Rails is faster or that Java is faster, but that it is ridiculous to make claims like this. Sure running a for-loop in Java is faster than an equivalent one in Ruby, but most J2EE apps literally have HUNDREDS of functions going on when you look at the stack trace for simple page queries. Most Rails apps have about 40. This is mostly due to Java and J2EE''s heavy reliance on patterns, but all of those extra functions and processes take time. It is not so clear that Java is slightly more efficient at run-time in any way except for the fact that the code has been compiled. Furthermore, talk to the Java developers at Friendster (who have written many books on Java web development) and ask them why they chose to move away from Java. Again, these claims (as they stand) are empty and worthless. -Lucas http://tech.rufy.com/
So it all trickles down to "self-documenting" code then (a.k.a. Do Repeat Yourself)? All for the benefit of talentless cubicle fields of programmers, run by talentless managers, who can''t write nor read actual documentation?
On Apr 1, 2005 2:59 PM, Lucas Carlson <rails-1eRuzFDw/cg@public.gmane.org> wrote:> > I don''t see having the same variable names in the DB as in the code as > > repeating yourself. I see it as a division between layers, which is > > simply good architecture. > > It is far from a division between layers, it is explicitly tying two > layers together. For example, changing a column name in the DB requires > you to change the Java getters and setters. DRY is all about > compartimentalizing your code, it says that if there is a change to be > made, you should theoretically only have to change one piece of the > project. This is far from the case in any J2EE example I have ever > seen.Hrm, actually I would just change the @hibernate.column tag one place in my source. None of the other code breaks. Compare that to Ruby, where if the underlying db changes, I have to hunt down every bit of code that references that particular column. Of course I could do def oldcol return newcol end That just doesn''t seem very elegant to me.> > Again, you may not agree with DRY. You may think that repeating > yourself is necessary sometimes. This is probably why you like Java > frameworks more than Rails, and that is just fine. I have a brilliant > programmer friend who does Java development and he had to spend 6 hours > one day simply changing the name of a single button. This was because > the J2EE app was not DRY and he had to track down many places that > needed to be changed. This is why I prefer DRY apps.I prefer Rails to Java frameworks. I just feel that there are some flaws in Rails - as I do with every Java framework I''ve used.> > > And if you don''t know the database structure? > > If you don''t know the database structure, you simply don''t know what > you are doing. The only difference between the Java version and the > Rails version in your example is where you go to learn about the > database structure. > > I personally would never want any programmer on a team that didn''t know > the database structure, that is just asking for trouble and > misunderstandings. Even if one person was doing model work and one was > doing controller/view work, I would want them both to know the database > backend, I think that''s the heart of most web development.In my example, I just want to be able to make a duck quack. There''s no reason I should have to know where it comes from. I prefer to write object-oriented code, not database-driven code.
> Hrm, actually I would just change the @hibernate.column tag one place > in my source. None of the other code breaks.I am not saying that you have to change a lot of things in your code, I am saying that you have to change more than 1 thing. DRY is about keeping things in only 1 place.> You can? That''s what I''m saying I''d like to see. The example I saw > above was > def name > super > end > > That''s kind of a messy solution to me, having to define an accessor > method just to see what the properties are.That''s exactly what you are doing in your example: public String getName() { return name; }> Here''s another thing: > myDuck.bark > > I''d like to know, before I run the code, that that''s not going to > work. The best I can do at this point is find out that the syntax is > OK.In the java world, it would suck to have to wait until run-time because compiling takes so long. Ruby, as you know, has no compile-time. Thus you would probably catch this error just as quick in Ruby''s run-time as you would in Java''s compile time. Furthermore, if you are a good pragmatic programmer and do your unit tests, this is moot.> Surely no competent programmer is going to try to make a duck > bark, but if you pass an argument to a library method, the problems > all come up at run-time, not compile-time.--and from an earlier email--> a decent programmer can figure it out easily enough, document it so he > knows for the > future. The fact of the matter is that most programmers you encounter > aren''t good programmers, and even more don''t document.-- One of your core arguments seems to be that Rails is flawed because bad programmers will have a harder time using it. If you read Paul Graham''s article: http://paulgraham.com/javacover.html you will notice his second point is that Java is "aimed low". Bad programmers are going to produce bad code no matter what you do. I don''t think that baby-sitting bad programmers should hold back good programmers.> Object-oriented programming versus database-driven programming. > Simple choice to me.This is totally not about oop vs. database-driven programming. Your complaint is about the explicitness of ActiveRecord, this does not have to do with OOP or database-driven programming. It is about DRY and whether or not a framework should babysit bad programmers. -Lucas http://tech.rufy.com/
Sometimes, the only database "API" that the developers get is a list of views, their fields, and stored procs, and hopefully a list of how these things quasi-interrelate. For instance, if you have a vertically-partitioned table in SQL Server 2000 (i.e., transactions_2005, transactions_2004, etc.), which are of course hidden behind a view, then it''s not really much different, it''s just that the layer of obfuscation is now within the database (which is required sometimes for security reasons, SarbOx, HIPAA, etc), instead of Rails, Hibernate, whatever. There are some good, time-proven reasons for developing against updatable views and stored procedures instead of table objects as well... On Apr 1, 2005 12:58 PM, Lucas Carlson <rails-1eRuzFDw/cg@public.gmane.org> wrote:> >>>>> I can look at the Java code and know what it > >>>>> actually does. If I look at the Ruby version, I''ve got no clue. > > If you look at the Ruby version and know the database structure, then > you know exactly what is going on. The Rails philosophy is don''t repeat > yourself (DRY), and writing code like you did in the Java version is > repeating yourself since the database already has that information. > > You may not agree with DRY, in which case you are absolutely free to do > things like: > > class Duck < ActiveRecord::Base > def name=(n) > super n > end > > def name > super > end > > def weight=(n) > super n > end > > def weight > super > end > > def quack > puts "quack" > end > end > > But again, you are repeating yourself unnecessarily. > > Can you think of a time when you don''t want your developers to be > intimately familiar with the database structure? If not, then why > repeat something that your developers are intimately familiar with? > > -Lucas > http://tech.rufy.com/ > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
> > The Rails philosophy is don''t repeat yourself (DRY), and writing code like > you did in the Java version is repeating yourself since the database already > has that information. >Not exactly :-) I usually prefer to make java classes before database modelling. To me, is more logical to think in "things" (classes) than "tables". So, to prove that I "dont repeat myself", try to do this in Eclipse w/ XDoclet plugins (any other IDE should do the same, but I use Eclipse for everything) /** @hibernate.class */ public class User { private String id; private String name; } Then, click the right button and choose: "generate getters and setters" (if you haven''t set keyboard shortcuts) Then, for each getter method, type: /** @hibernate.property */ Then, run XDoclet :-) Again, its not a "my framework is better than yours" discussion. I just want to show that compare apple w/ grape, usually, is invalid ;-) Rails is supposed to be a "high productivity" framework, and it is. But please, don''t compare two different things :-) regards, juca On Apr 1, 2005 5:58 PM, Lucas Carlson <rails-1eRuzFDw/cg@public.gmane.org> wrote:> > >>>>> I can look at the Java code and know what it > >>>>> actually does. If I look at the Ruby version, I''ve got no clue. > > If you look at the Ruby version and know the database structure, then > you know exactly what is going on. The Rails philosophy is don''t repeat > yourself (DRY), and writing code like you did in the Java version is > repeating yourself since the database already has that information. > > You may not agree with DRY, in which case you are absolutely free to do > things like: > > class Duck < ActiveRecord::Base > def name=(n) > super n > end > > def name > super > end > > def weight=(n) > super n > end > > def weight > super > end > > def quack > puts "quack" > end > end > > But again, you are repeating yourself unnecessarily. > > Can you think of a time when you don''t want your developers to be > intimately familiar with the database structure? If not, then why > repeat something that your developers are intimately familiar with? > > -Lucas > http://tech.rufy.com/ > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- juraci krohling costa http://jkcosta.info _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Why don''t you just run these commands in mysql, save it as a text file
and put right there with you models fort reference?
mysql> use rails_development
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show tables;
+-----------------------------+
| Tables_in_rails_development |
+-----------------------------+
| comments |
| posts |
| users |
+-----------------------------+
3 rows in set (0.00 sec)
mysql> explain comments;
+----------+-------------+------+-----+---------------------
+----------------+
| Field | Type | Null | Key | Default | Extra
|
+----------+-------------+------+-----+---------------------
+----------------+
| id | tinyint(11) | | PRI | NULL |
auto_increment |
| tstamp | datetime | | | 0000-00-00 00:00:00 |
|
| com | text | | | |
|
| posts_id | tinyint(11) | | | 0 |
|
| users_id | tinyint(11) | | | 0 |
|
+----------+-------------+------+-----+---------------------
+----------------+
5 rows in set (0.00 sec)
mysql> explain posts;
+---------+--------------+------+-----+---------------------
+----------------+
| Field | Type | Null | Key | Default | Extra
|
+---------+--------------+------+-----+---------------------
+----------------+
| id | tinyint(11) | | PRI | NULL |
auto_increment |
| tstamp | datetime | | | 0000-00-00 00:00:00 |
|
| title | varchar(100) | | | |
|
| content | text | | MUL | |
|
+---------+--------------+------+-----+---------------------
+----------------+
4 rows in set (0.00 sec)
mysql> explain users;
+----------+-------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+----------+-------------+------+-----+---------+----------------+
| id | tinyint(11) | | PRI | NULL | auto_increment |
| username | varchar(50) | | | | |
| password | varchar(50) | | | | |
+----------+-------------+------+-----+---------+----------------+
3 rows in set (0.00 sec)
There you go! No repeating yourself in the code and look all the info
is right there ;-)
-Ezra
On Apr 1, 2005, at 1:36 PM, Pat Maddox wrote:
> On Apr 1, 2005 1:58 PM, Lucas Carlson
<rails-1eRuzFDw/cg@public.gmane.org> wrote:
>>>>>>> I can look at the Java code and know what it
>>>>>>> actually does. If I look at the Ruby version,
I''ve got no clue.
>>
>> If you look at the Ruby version and know the database structure, then
>> you know exactly what is going on. The Rails philosophy is
don''t
>> repeat
>> yourself (DRY), and writing code like you did in the Java version is
>> repeating yourself since the database already has that information.
>
> And if you don''t know the database structure? I know
it''s unlikely,
> but I also don''t think you should HAVE to know about the database
> structure in order to use it. Consider a scenario where one
> programmer writes all the model classes, and passes them around to
> everyone else in the team to use. If I''m a different part of the
> team, and want to use a Duck, I should be able to just use it without
> having to look at the db.
>
> I don''t see having the same variable names in the DB as in the
code as
> repeating yourself. I see it as a division between layers, which is
> simply good architecture.
>
>>
>> You may not agree with DRY, in which case you are absolutely free to
>> do
>> things like:
>>
>> class Duck < ActiveRecord::Base
>> def name=(n)
>> super n
>> end
>>
>> def name
>> super
>> end
>>
>> def weight=(n)
>> super n
>> end
>>
>> def weight
>> super
>> end
>>
>> def quack
>> puts "quack"
>> end
>> end
>>
>> But again, you are repeating yourself unnecessarily.
>>
>> Can you think of a time when you don''t want your developers to
be
>> intimately familiar with the database structure? If not, then why
>> repeat something that your developers are intimately familiar with?
>
> As I said above, the people using the model classes aren''t always
the
> same as those writing them. The example I presented is very simple,
> but I think that illustrates the point fairly well. For a class as
> simple as that, there should be no reason to have to look to the
> database to figure out what it is.
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
-Ezra Zygmuntowicz
Yakima Herald-Republic
WebMaster
509-577-7732
ezra-gdxLOakOTQ9oetBuM9ipNAC/G2K4zDHf@public.gmane.org
_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails
In article <ec31d51ddda580e8c0f463d3379b714f-1eRuzFDw/cg@public.gmane.org>, rails- 1eRuzFDw/cg-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org says...> I have a brilliant > programmer friend who does Java development and he had to spend 6 hours > one day simply changing the name of a single button.This bears repeating! DRY is one of the single most exciting things I find about Rails. In my previous life, to add a field to a database that was updated by a CRUD-style form, I had to change the following: - Form displayed to user - Listing of fields on form used by GUI app - "get" API of library used to talk to database worker server - Code used by GUI app to call library to get record - Internal "get" message struct used by library to talk to worker - External structure used to pass results from lib to GUI - Internal structure used by GUI app to store db record - Code used by GUI app to display record in form - Code used by GUI app to fetch results from form - Internal structure used by GUI app to store form results - Library API, structs, etc. for appropriate "set" function - Code in worker to parse get/set messages and access database - Internal struct in worker used to access database record - Database schema And, needless to say, the library changes ended up triggering a source- management rebuild of every single app that called the library, whether or not it cared about this new field. Yessir, I''m looking forward to Rails. -- Jay Levitt | Wellesley, MA | I feel calm. I feel ready. I can only Faster: jay at jay dot fm | conclude that''s because I don''t have a http://www.jay.fm | full grasp of the situation. - Mark Adler
I spent this morning reading this thread and felt compelled to comment on some of the ''enterprise level'' stuff. It was suggested that dynamically typed languages are not suitable for large multi-person applications. The company I work for proves this to be untrue. We have a number of applications developed in Smalltalk - one of which has 50+ staff, 10K classes and has been running for most of the last 10 years. The company is happy with the product, the team are happy with their work, the users are delighted with what they can do. This application has allowed the company to generate hundereds of millions, perhaps billions, of dollars of profit. If that isn''t enterprise level I don''t know what is! Static typing has it''s advantages - it is not always a bad thing. Personally I prefer dynamic languages but I can understand people who feel differently. Arguing about personal preference - that''s what it is - is kind of pointless. On the other side of the fence people are claiming that Ruby and Rails are suitable for enterprise[1] level development; these claims are pure speculation. As far as I know no-one has written anything on that scale. Once some people have tried we''ll have some evidence one way or another. We all know that Java is suitable since people, including me, do it day after day. Personally I''m sure that Ruby would be a viable language for enterprise development if it had the same backing as Java. I think that if some of the library shortcomings can be addressed then it will be. I''ll come back to these shortcomings in a moment. As for Rails I''m not sure that it will be suitable for enterprise level work. Actually when I say that I mean the same as everyone else Active Record may not be suitable. Action Pack I''m pretty sure could be used. The only problem I see with AR is the Active Record pattern itself. The databases I use are massive and complicated, the structure designed to make them as flexible as possible; thousands of tables, 10''s, 100''s, or 1000''s of millions of rows, 1000''s of applications accessing them. This poses three (at least) problems: 1)The table structure doesn''t match any object model I want in my application - not even close. I can''t create a new view set of views on top of this indescriminately because of the performance implications for the thousands of other applications using them. 2)The only way to make db''s this size maintainable is to insist that all access is via stored procedures. AR doesn''t work very well when it can''t see a db structure. 3)The n+1 queries problem is a killer where n is a million plus. AR is a good solution to a lot of problems. I don''t think this is one of them. Does that make it bad? No, of course not. It just makes it unsuitable for this kind of development. My gut feeling is that Action Pack backed by an iBATTIS type framework written in Ruby would be capable of a lot more of what I need. There would still be issues - things like distributed transactions across different RDBMS; but they are not as commonly needed. Libraries, I said I would come back to it, here it is. Ruby is missing libraries that are essential to get it acceptance in big organisations. Database access for instance. Ruby doesn''t have a standard interface to different databases. Ruby DBI is the closest, but it is at version 0.0.21 and hasn''t had a release since 2003 so it is a dead library. Even if it was live I still couldn''t use it since it doesn''t support Sybase the db my organisation uses as standard. If DBI was viable rails would use it. It ( to my knowledge ) doesn''t. Too many Ruby projects are one man bands for people to trust it DBI, Wee, Ruby itself, Nitro, Og, Needle, Copeland, Rake. Maybe because Ruby is powerful it doesn''t need a lot of people on an open source project. But it is much more fragile because of that. With Java projects tend to have more people so they are more robust in terms of community and surviving boredom of the original author. There are also groups that take in projects that were written by individuals and provide a group infrastructure around them. The recent integration of iBATTIs into the jakarta project as an example. I hope Ruby makes it big I really do. I love writing in it. I squeeze it in at work whereve I can. I''m just not sure it will unless the libs thing is sorted. R. [1] I hate the word enterprise, but since that is what the thread is about I have to keep using it.
Nathaniel Talbott wrote:>First of all, as has already been said, Ruby *is* strongly typed. >You''re thinking of static typing, I believe. > >Yeah, probably, but when I use the term "static typing", people complain that I should say "strong typing", instead. Go figure.>Secondly, do you have any substantiation for your claims? Any at all? > >You got me there. All I have is some personal experience with several projects. One project with weak/dynamic typing failed altogether because maintenance and upgrades became impossible. One project almost failed, but we managed to switch to Java just in time. The all-Java project went reasonably smoothly. Do I have strong, statistical proof that strong/static typing (or lack thereof) was the major culprit ? No. I''d like to see your hard data, if you have any. Note that we are only considering major projects here, with large teams working on a huge amount of code -- for small projects, Rails is best, as I''d said. Also, I''ve never had the chance to program in Smalltalk, so I can''t comment on it one way or the other.
First of all, yes, I did mean "statically typed". Moving on:>It won''t work? Why is that? What about dynamically typed languages >make them especially inappropriate in teams (of more than how many >people)? Why does more lines equate to less approriate for dynamically >typed languages? > >I thought I posted my reasoning earlier on this thread, but I guess the message got lost somehow. I will reiterate my basic arguements, but I will also expand on them a bit. First, I will assume that programming is easy, and debugging is hard. This has been my personal experience -- if you don''t believe this is true, please tell me why. But, based on this, we''d want a tool that 1). Makes it harder to make mistakes that one would later have to debug, and 2). Automates at least some part of the debugging process. We obviously cannot make a tool that automates debugging 100%, at least, not until we have Strong AI -- but any small step in that direction is a good thing. I claim that static typing satisfies both (1) and (2). 1). Static typing requires you to figure out at least an approximate picture of your class hierarchy before you start coding; it also forces you to maintain a certain level of discipline as you are extending and refactoring your code, because you can''t change variables around willy-nilly without wrecking the rest of the code. In a statically-typed program, it is usually self-evident what inherits what, and why. Some languages, such as Java, choose to utilize static typing even further by disallowing multiple inheritance. This can be damned inconvenient at times, but it also cuts down on complexity a great deal (I''ll mention the tradeoffs later on). 2). Static typing, and the compile phase in general, can automatically detect and eliminate some simple mistakes that are easy to make. For example, in Ruby it''s possible to say, a = SomeClass.new ...some code here... a = SomeOtherClass.new ...more code here... This presents no problems if SomeClass and SomeOtherClass do not have methods with similar (or, worse, identical) names. But if they do, and someone forgot about the re-assignment to a, he''ll be in for a nasty surprise. This is even worse if you consider some other dynamically typed languages (not Ruby, AFAIK), where the "+" operator is overloaded to do string concatenation. A statically-typed language, however, will not allow any of this to happen. Things get even more complex when we allow runtime re-definition of methods (as Ruby does). It is very easy to re-define a method, but very difficult to predict what will happen if some other code relies on the old behavior of the method. Method re-definition is impossible in a statically-typed language, so, again, that''s not a problem. Both statically-typed and dynamically-typed languages can allow multiple inheritance. However, in a statically-typed language (such as strict C++), the programmer must specify which instance variables belong to which class. Dynamically-typed languages do not require this, and thus, as the Ruby book points out, can produce some nasty surprises:> Not only do we have access to the methods defined in the mixin, but we > get access to the necessary instance variables as well. There''s a risk > here, of course, that different mixins may use an instance variable > with the same name and create a collision... > [code snipped, you can look at it here: > http://www.rubycentral.com/book/tut_modules.html]> The two bits of code that we mix in both use an instance variable > named @numNotes. Unfortunately, the result is probably not what the > author intended.For those people who use lots of math (granted, that''s not too many people), statically typed languages can also provide warnings and errors about loss of precision. If you are trying to assign a 64-bit constant to a 32-bit variable, chances are you''re doing something wrong on a more fundamental level, and the compiler will catch you. Additionally, the comile phase for compiled languages can detect common errors not related to types, such as "unreachable code", "expression is always false", etc. These types of errors are easy to make, but hard to debug. Many people have pointed out that your unit tests should catch all of these errors, regardless of whether the compiler catches them or not. This is 100% true, but I''d still rather have the compiler as backup, in case I happen to miss a unit test. Obviously, there are some tradeoffs involved with static typing -- nothing is free. Some of these tradeoffs are: * More keystrokes ("int a=5" vs "a=5") * Slower coding (since you have to think about types before you can start writing code) * Reduced flexibility (no more dynamic re-definition of methods, etc.) * Depending on your language of choice, loss of multiple inheritance (you might have to deal with wrapper classes instead, which is more cumbersome) * Again, depending on your language of choice, loss of operator overloading. * Slower, more work-intensive refactoring process. So, in summary, static typing does two things for you: 1). Forces you to do some thinking before you start coding 2). Reduce or eliminate ambiguities in your code. For small projects, involving one or two people, the tradeoffs are simply not worth it. If I am writing a simple blog application all by myself, I can keep the entire design of it in my head at all times. Messing around with strict class hierarchies, etc. will only slow me down; having to hit that "compile" button (or command, or whatever) every time I change anything will just annoy me. For large projects, involving many teams of people, the reduced complexity of statically typed code, as well as all the automated safeguards, becomes essential. When no single person has a total and complete understanding of every line of code, the reduced complexity of the code overall ensures that people are still able to work together without stepping on each other''s toes. My web formatting system cannot inadvertently break your O-R mapping, and vice versa. If you forgot that you re-assigned the variable "a" to something else, the compiler will stop you before you commit the code and cause my unit tests to break. ************ DISCLAIMER ************* I am not some kind of guru, or an evil Microsoft spy, or a secret memetic agent of Bjorne Stroustrup, or whatever. I am just a guy. All of the above is my personal opinion, nothing more. Also, I am but one man. This mailing list contains many, many other men. If I haven''t responded to your message, I''m sorry, but there''s only so much I can do in one day...
Pat Maddox wrote:>public class Duck { > String name; > int weight; > > public void setName(String name) { this.name = name; } > public String getName() { return name; } > public void setWeight(int weight) { this.weight = weight; } > public int getWeight() { return weight; } > > public void quack() { System.out.println("quack"); } >} > >class Duck > def quack > puts "quack" > end >end > >Now there''s no denying that the Ruby code is shorter, and if they both >use the same data source, they''ll have the same properties and >function the same. But I can look at the Java code and know what it >actually does. If I look at the Ruby version, I''ve got no clue. > >Yeah, that''s a good point, I couldn''t have said it better myself. Basically, statically typed languages require you to do more work, but reduce ambiguity in your code. Dynamically typed languages require you to do a lot less work, but when it comes to running the code, all bets are off.>Easily solved by good documentation, of course. And a decent >programmer can figure it out enough, document it so he knows for the >future. The fact of the matter is that most programmers you encounter > >I think I am a semi-decent programmer, but I occasionally find it difficult to maintain proper documentation in order, especially when I am refactoring something. I prefer self-documenting code.
kate rhodes wrote:>if you want to campare apples to apples the Java would be > >public class Duck { > String name; > int weight; > > public void quack() { System.out.println("quack"); } > } > >getters and setters are convention not requirements > >Yes, but even without getters and setters, I can take a look at the class and see that it contains the "name" and "weight" properties. I can''t do that with the Rails version.
Robert Lally wrote:>1)The table structure doesn''t match any object model I want in my >application - not even close. I can''t create a new view set of views >on top of this indescriminately because of the performance >implications for the thousands of other applications using them. > >Yes, this was the case with the major CMS project I was involved with, as well. We didn''t even use views most of the time... we had to cache a lot of data in one-off tables, just to increase performance.>AR is a good solution to a lot of problems. I don''t think this is one >of them. Does that make it bad? No, of course not. It just makes it >unsuitable for this kind of development. > >Absolutely. I would go even furhter, and claim that NO language (or "enterprise-class" system or whatever) -- not Ruby, not Java, not C++, nothing -- will ever be good enough for all tasks. Some languages will always be better at some tasks than others. I don''t see anything wrong with this, however.
On Sat, Apr 02, 2005 at 02:14:43AM -0800, Stanislav Freidin wrote:> kate rhodes wrote: > > >if you want to campare apples to apples the Java would be > > > >public class Duck { > > String name; > > int weight; > > > > public void quack() { System.out.println("quack"); } > >} > > > >getters and setters are convention not requirements > > > > > Yes, but even without getters and setters, I can take a look at the > class and see that it contains the "name" and "weight" properties. I > can''t do that with the Rails version.You could do that, but then you wouldn''t be able to change database schema and have Rails automatically adjusted to it. You''d have to change data declaration in your code - you have two places where you define your data-types instead of just one and this may lead to some errors. I find myself doing extremely well with Rails ''non- verbosity'', and I always have database schema in the other window so I can see what I''m dealing with. I think its a bit redundant to have the same info in more than one place, its just like appending a long changelog at the beginning of any source file (which can take more than a few pages and make reading the code quite hard) when you have the same information in your SVN for example. By the way look at the Java source files - 80% of their content are comments that describe _every_ entity in the class in so verbose way that I''m unable to read this code. Sometimes there are half-page or even longer descriptions of what a certain method do, how, and what was the weather when someone wrote it. I guess it strongly depends on what you prefer - if you are eager to change some more code just because you added/removed/modified a single column in the database then you''d have a hard time getting used to Rails. Its the same case as with strong typing to avoid "errors" that "could" emerge when you don''t explicitly specify the variable type. Real life shows that all those "helpful" things like strong typing, mucho comments and so on are not really saving us from bugs and wrong code, and additionaly they slow down the development 10 times. -- KN
What I particularly like about Hibernate is the ability to start from the domain model, and construct the class hierarchies, associations, aggregations that I need in pure OO fashion, unit test them, integrate them and then just have Hibernate generate the nice normalized db schema from my classes. If the object model changes then Hibernate can update the db schema accordingly. So this follows the Object -> Relational mapping design-wise. ActiveRecord on the other hand is a Relational -> Object mapper, you need to have the db structure in place before you do any work with your domain classes. I also like the fact that with Java I can get a full-Java production environment, be it Tomcat, Jetty, WebLogic, etc. With Rails I need to consider using fastcgi for production in association with a web server like Apache or Lighttpd. Webrick doesn''t cut it for production. Fastcgi is a must, because Rails is single threaded, this means you need to spawn as many fastcgi ruby processes as many simultaneous connections you want to handle.
Ara.T.Howard wrote:> On Fri, 1 Apr 2005, Jim Freeze wrote: > >> * Ara.T.Howard <Ara.T.Howard-32lpuo7BZBA@public.gmane.org> [2005-04-01 10:53:46 -0700]: >> >>> java is strongly typed. ruby is strongly typed. python is strongly >>> typed. >>> ocaml is strongly typed. fortran is strongly typed. c is strongly >>> typed. >> >> I thought C was weakly typed. > > good catch. > > it is, strictly speaking. but if you ignore typedefs, enums, and type > coercion it''s basically strongly typed. it''s probably more accurate to > call > both c and c++ weakly typed.C and C++ are basically strongly and statically typed, but both give the programmer the ability to break the type system. The Java advocates in this thread haven''t mentioned the fact that, at least up until the release of Java 1.5, all use of collections in Java is dynamically typed. Is this a big problem in practice? Apart from the ugliness of having to cast, in my experience, it isn''t. Justin
On Sat, 2 Apr 2005, Stanislav Freidin wrote:>> public class Duck { >> String name; >> int weight; >> >> public void setName(String name) { this.name = name; } >> public String getName() { return name; } >> public void setWeight(int weight) { this.weight = weight; } >> public int getWeight() { return weight; } >> >> public void quack() { System.out.println("quack"); } >> } >> >> class Duck >> def quack >> puts "quack" >> end >> end >> >> Now there''s no denying that the Ruby code is shorter, and if they both use >> the same data source, they''ll have the same properties and function the >> same. But I can look at the Java code and know what it actually does. If >> I look at the Ruby version, I''ve got no clue. >> > Yeah, that''s a good point, I couldn''t have said it better myself. Basically, > statically typed languages require you to do more work, but reduce ambiguity > in your code. Dynamically typed languages require you to do a lot less work, > but when it comes to running the code, all bets are off.the reduction in ambiguity fails when the code reaches 30,000 lines. consider this fact: a human being''s understanding is based not only on __what__ is said but __how_much__ is said. this is a simple fact : we cannot wrap our brains around the entire internet, for example, now matter how clearly every fact on it is communicated. this is a __major__ factor in real projects that must be addressed if a realistic assesment of comprehesion is to be made: the number of lines of code and number of source files bears a direct influence on the ability for one person to understand the entire source base. in pratice this turns out to be much more important that a comparison of 10 lines of static vs dynamic code - i could post a 4000 C program i''ve converted to 300 lines of ruby, which do you think you''d have an easier time understanding, maintaining, or debugging? i would go so far to say that, beyond a certain very low threshold (1000 lines or so) tloc and elegant design are far more important than static typing to ensure reliability, readability, and, most importantly, correctness. research certainly supports this (some studies already noted in this thread) showing that the number of bugs scales in a linear fashion to tloc. by extension, using the java and ruby examples from above, the java snippet has roughly twice as many bugs as the ruby version. in fact, i can see one now : weight should be declared ''unsigned int'', not an ''int''. this is a silly example but brings up a good point : i''ve never worked with any programmer that even understood static typing, mostly due to the fact that accurate type definitions in all common statically typed langs are totally impossible to comprehend. for example this simple type declaration void (*signal(int, void (*)(int )))(int ); totally baffles most programmers. as proof i point out that a program was created long ago to unravel c declarations for mere mortals: cdecl. using it you may find out that ~ > echo ''explain void (*signal(int, void (*)(int )))(int );'' | cdecl -c /dev/stdin declare signal as function (int, pointer to function (int) returning void) returning pointer to function (int) returning void clear as mud eh? another common mistake illustrating this are functions declared as void foobar(const char *); when really the coder meant void foobar(const char const *); but, because the programmer does not understand the difference - she has false sense of confindence that foobar will not modify the string passed to it. but of course it can with the first definition. furthermore, any large c or c-- project will have thousands of lines which subvert the type system in order to shut the compiler up - resulting in array''s getting free-d and const data being written over, etc, etc. witness the popularity of the ''any'' containers on the boost c-- lib : they do nothing but subvert the typing system and people love them. a good friend of mine works for a very large company which produces a massive java product for monitoring heterogeneous systems. he was telling me that no single person in the company undertands even a significant portion of the code base - this is a function of two things : tloc and bad design. in summary static typing does not ensure ''correctness'' when the code grows beyond a rather small size __unless__ the compiler is smart enough to prove all uses as being correct which java, c, and c++ compilers are not. even then it can quickly become a hindrance if it contributes to to code bloat (double declaration in *.h *.c files for example) and obfusication since the code base size then quickly becomes the predomination factor in comprehension, correctness, and robustness. again, studies bear this out : the same program written in statically typed languages like c, c++, and java will contain more bugs and are less robust than those written in even weakly typed languanges like perl - this is thought to be a function of tloc.>> Easily solved by good documentation, of course. And a decent programmer >> can figure it out enough, document it so he knows for the future. The fact >> of the matter is that most programmers you encounter >> > I think I am a semi-decent programmer, but I occasionally find it difficult > to maintain proper documentation in order, especially when I am refactoring > something. I prefer self-documenting code.at least we agree here. however, i would refine that by saying "i prefer the fewest number of lines of self-documenting code." cheers. -a -- ==============================================================================| email :: ara [dot] t [dot] howard [at] noaa [dot] gov | phone :: 303.497.6469 | if you love the sacred and despise the ordinary, you are still bobbing in the | ocean of delusion. --lin-chi ===============================================================================
Robert Lally wrote:>I spent this morning reading this thread and felt compelled to comment >on some of the ''enterprise level'' stuff. > >Ruby on Rails is designed for making websites, specifically websites like Basecamp (where it was extracted from). From what I can tell though, most developers doing development with Java are building departmental web apps that mostly interact with a single database. This isn''t "enterprise" development, and using "enterprise" tools for this work is wasteful. Hence the emergence of Spring, PicoContainer and other "light" frameworks that more closely address the real issues these developers face. I think Rails probably addresses them even better. If you are building an ERP system and tying together dozens of systems of record on various platforms - you probably ought to use something other than Rails. You might also want to kill yourself.
Zsolt wrote:> If the object model changes then Hibernate can update the db schema > accordingly. So this follows the Object -> Relational mapping > design-wise. >Does it do this without dropping your tables and losing your data?
Yes, you just need to set hibernate.hbm2ddl.auto in your hibernate config. On Apr 2, 2005 8:59 AM, Jeremy Huffman <jeremy-S3UG9Ld25dVMf0S0rWojDQC/G2K4zDHf@public.gmane.org> wrote:> > > Zsolt wrote: > > > If the object model changes then Hibernate can update the db schema > > accordingly. So this follows the Object -> Relational mapping > > design-wise. > > > Does it do this without dropping your tables and losing your data? > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
* Pat Maddox (pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org) [050402 11:39]:> > Zsolt wrote: > > Does it do this without dropping your tables and losing your data?> Yes, you just need to set hibernate.hbm2ddl.auto in your hibernate config./me wonders why the no-data-loss option isn''t the default. Rick -- http://www.rickbradley.com MUPRN: 347 | he starts flaming the random email haiku | list and gets "accidently | unsubscribed"? Hmmm.
Stanislav Freidin wrote:> Robert Lally wrote: > >> AR is a good solution to a lot of problems. I don''t think this is one >> of them. Does that make it bad? No, of course not. It just makes it >> unsuitable for this kind of development. >> >> > Absolutely. I would go even furhter, and claim that NO language (or "enterprise-class" system or whatever) -- not Ruby, not Java, not C++, nothing -- will ever be good enough for all tasks. Some languages will always be better at some tasks than others. I don''t see anything wrong with this, however.I agree that some tasks may be more suited to one language than another. For instance writing an OS may be better in C than in Ruby. But then there are tools that convert Ruby -> C. So would it be better to write in Ruby and generate the C or not? I don''t really know. The goal of corporations is to have developers use a single tool for everything. They want plug and play developers with easy to understand skill sets. It is a stupid idea ... but that''s what they want. If your goal is to pick just one language for an org to use, or at least minimise the number of languages used, then at the moment between Java and Ruby there is no question of which is the best choice. I can do pretty much anything in Java I can in Ruby and some things I can''t. Is it as easy to do the possible things? Probably not. Managment of large organisattions tend not to care. I hope, but never expect, to see Ruby as a mainstream development language. My plan is to use it as much as I can and see where things go. If a time comes when I can use it every day great, if not ... that''s what my free time is for. R.
On Apr 02, 2005, at 19:09, Rick Bradley wrote:> /me wonders why the no-data-loss option isn''t the default.Not every databases support altering existing tables. As an aside, EOF''s EOModeler and Cayenne''s Modeler provide the same functionality, plus some: http://developer.apple.com/documentation/WebObjects/UsingEOModeler/ http://www.objectstyle.org/cayenne/modelerguide/modeler-intro/index.html Cheers -- PA, Onnay Equitursay http://alt.textdrive.com/
It is not only about the enterprise - simple convenience too. I am a bit lost when I have to make a PHP app talk to a DB without resorting to ADODB (i.e. to a common data access layer that I know absolutely out of my head). On 2-apr-05, at 11:04, Robert Lally wrote:> > Libraries, I said I would come back to it, here it is. Ruby is missing > libraries that are essential to get it acceptance in big > organisations. Database access for instance. Ruby doesn''t have a > standard interface to different databases. Ruby DBI is the closest, > but it is at version 0.0.21 and hasn''t had a release since 2003 so it > is a dead library. Even if it was live I still couldn''t use it since > it doesn''t support Sybase the db my organisation uses as standard. If > DBI was viable rails would use it. It ( to my knowledge ) doesn''t. Too > many Ruby projects are one man bands for people to trust it DBI, Wee, > Ruby itself, Nitro, Og, Needle, Copeland, Rake. >-- Julian "Julik" Tarkhanov
* Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [0436 22:36]:> On Apr 1, 2005 1:58 PM, Lucas Carlson <rails-1eRuzFDw/cg@public.gmane.org> wrote: > > >>>>> I can look at the Java code and know what it > > >>>>> actually does. If I look at the Ruby version, I''ve got no clue. > > > > If you look at the Ruby version and know the database structure, then > > you know exactly what is going on. The Rails philosophy is don''t repeat > > yourself (DRY), and writing code like you did in the Java version is > > repeating yourself since the database already has that information. > > And if you don''t know the database structure? I know it''s unlikely,rasputnik@eris:rails$ ./script/console development Loading development environment. irb(main):001:0> p = Player.find_by_username(''stinky'') => #<Player:0x8f52f84 @attributes={"username"=>"stinky", "lname"=>"McGinty", "id"=>"1", "fname"=>"Stinky", "password"=>nil, "email"=>nil}> irb(main):002:0> p.attribute_names => ["email", "fname", "id", "lname", "password", "username"] irb(main):003:0> quit next! -- ''When the door hits you in the ass on the way out, clean off the smudge your ass leaves, please'' -- Alien loves Predator Rasputin :: Jack of All Trades - Master of Nuns
* Stanislav Freidin <bugmaster-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> [0413 11:13]:> kate rhodes wrote: > > >if you want to campare apples to apples the Java would be > > > >public class Duck { > > String name; > > int weight; > > > > public void quack() { System.out.println("quack"); } > >} > > > >getters and setters are convention not requirements > > > > > Yes, but even without getters and setters, I can take a look at the > class and see that it contains the "name" and "weight" properties. I > can''t do that with the Rails version.You can look at the instance you have at hand (see my reply to Pat). ''Looking at the class'' does''nt make much sense in a dynamic language. -- ''Robots don''t have emotions, and that sometimes makes me feel sad.'' -- Bender Rasputin :: Jack of All Trades - Master of Nuns
I don''t think you should have to instantiate an object of a class in order to determine what attributes that class has. As I''ve said before, this is just personal preference. I''d rather look at a class definition and know what it does, not have to go through a bunch of other steps. On Apr 2, 2005 12:23 PM, Dick Davies <rasputnik-ogHSZ3ARDZIOXkKaSkYkkl6hYfS7NtTn@public.gmane.org> wrote:> * Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [0436 22:36]: > > On Apr 1, 2005 1:58 PM, Lucas Carlson <rails-1eRuzFDw/cg@public.gmane.org> wrote: > > > >>>>> I can look at the Java code and know what it > > > >>>>> actually does. If I look at the Ruby version, I''ve got no clue. > > > > > > If you look at the Ruby version and know the database structure, then > > > you know exactly what is going on. The Rails philosophy is don''t repeat > > > yourself (DRY), and writing code like you did in the Java version is > > > repeating yourself since the database already has that information. > > > > And if you don''t know the database structure? I know it''s unlikely, > > rasputnik@eris:rails$ ./script/console development > Loading development environment. > irb(main):001:0> p = Player.find_by_username(''stinky'') > => #<Player:0x8f52f84 @attributes={"username"=>"stinky", "lname"=>"McGinty", "id"=>"1", "fname"=>"Stinky", "password"=>nil, "email"=>nil}> > irb(main):002:0> p.attribute_names > => ["email", "fname", "id", "lname", "password", "username"] > irb(main):003:0> quit > > next! > > -- > ''When the door hits you in the ass on the way out, clean off the smudge > your ass leaves, please'' > -- Alien loves Predator > Rasputin :: Jack of All Trades - Master of Nuns >
* Zsolt <zsolt.szasz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [0416 12:16]:> I also like the fact that with Java I can get a full-Java production > environment, be it Tomcat, Jetty, WebLogic, etc. With Rails I need to > consider using fastcgi for production in association with a web server > like Apache or Lighttpd. Webrick doesn''t cut it for production. Fastcgi > is a must, because Rails is single threaded, this means you need to > spawn as many fastcgi ruby processes as many simultaneous connections > you want to handle.I could say the same about threads, the only obvious difference being it''s a hell of a lot easier to debug and monitor resource usage on several processes than a JVM. (Please don''t come back with ''I can use a huge proprietary product to do that.'' It''s the usual answer to any criticism of Java''s bloated unwieldiness and it got old last century.) Having configured lighttpd - fastcgi - rails and tomcat, I know which I''d rather spend 10 minutes / a couple of hours pissing about with. And that''s nothing fancy, just ssl. Try adding unit testing and an ant task (which you get out of the box with rails). I can build ruby faster than I can download a JDK on broadband. Don''t get me started on trying to get a native JVM built on a non solaris/linux/windows/osx platform, signing SCSL agreements and swearing at a humongous dependency tree isn''t my idea of a fun evening. I''m out of that disco and I have never looked back. -- ''The pie is ready. You guys like swarms of things, right?'' -- Bender Rasputin :: Jack of All Trades - Master of Nuns
* Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [0429 20:29]:> I don''t think you should have to instantiate an object of a class in > order to determine what attributes that class has.I think that''s another big difference between static languages and dynamic ones. I can''t be bothered to go through another duck-typing vs. static typing / compile-time vs. dynamic language tennis match again, it''s very well covered on the ruby-talk archives and the rubygarden wiki if you''re interested. It really helps to use a language with this philosophy before you ''get it''.> As I''ve said before, this is just personal preference. I''d rather > look at a class definition and know what it does, not have to go > through a bunch of other steps.Each to their own. I''ve used Javas reflection API and I can understand it instilling a reluctance for digging around at runtime :)> > * Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [0436 22:36]: > > > > > > And if you don''t know the database structure? I know it''s unlikely,> > irb(main):002:0> p.attribute_names > > => ["email", "fname", "id", "lname", "password", "username"]-- ''Yeah, well I''m gonna build my own themepark! With blackjack aaand Hookers! Actually, forget the park. And the blackjack.'' -- Bender Rasputin :: Jack of All Trades - Master of Nuns
On Friday 01 April 2005 01:03 pm, Jim Freeze wrote:> * Ara.T.Howard <Ara.T.Howard-32lpuo7BZBA@public.gmane.org> [2005-04-01 10:53:46 -0700]: > > java is strongly typed. ruby is strongly typed. python is strongly > > typed. ocaml is strongly typed. fortran is strongly typed. c is > > strongly typed. > > I thought C was weakly typed.Stong vs Weak typing isn''t a binary either/or condition. Its a graduated scale from very weakly typed languages to very strongly typed languages. C is statically typed with a type system that is fairly easy to fool accidently. C++ strengthens the type system by covering most of the accidental type "gotchas", but still is pretty easy to break is you set out to do it. Languages like Eiffel and Ada are very strongly typed where you have to take extraordinary (in Ada''s case) or obscure (in Eiffel''s case) measures to break the type system. -- -- Jim Weirich jim-Fxty1mrVU9GlFc2d6oM/ew@public.gmane.org http://onestepback.org ----------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
How does it do this? It generates alter table statements based on your current db and current model? What if its a change that can''t be done with alter table? Pat Maddox wrote:>Yes, you just need to set hibernate.hbm2ddl.auto in your hibernate config. > >On Apr 2, 2005 8:59 AM, Jeremy Huffman <jeremy-S3UG9Ld25dVMf0S0rWojDQC/G2K4zDHf@public.gmane.org> wrote: > > >>Zsolt wrote: >> >> >> >>> If the object model changes then Hibernate can update the db schema >>>accordingly. So this follows the Object -> Relational mapping >>>design-wise. >>> >>> >>> >>Does it do this without dropping your tables and losing your data? >>_______________________________________________ >>Rails mailing list >>Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >>http://lists.rubyonrails.org/mailman/listinfo/rails >> >> >> >_______________________________________________ >Rails mailing list >Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >http://lists.rubyonrails.org/mailman/listinfo/rails > > > >
Dick Davies wrote:> * Zsolt <zsolt.szasz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [0416 12:16]: > > >>I also like the fact that with Java I can get a full-Java production >>environment, be it Tomcat, Jetty, WebLogic, etc. With Rails I need to >>consider using fastcgi for production in association with a web server >>like Apache or Lighttpd. Webrick doesn''t cut it for production. Fastcgi >>is a must, because Rails is single threaded, this means you need to >>spawn as many fastcgi ruby processes as many simultaneous connections >>you want to handle. > > > I could say the same about threads, the only obvious difference being > it''s a hell of a lot easier to debug and monitor resource usage on several > processes than a JVM. > (Please don''t come back with ''I can use a huge proprietary product to do > that.'' It''s the usual answer to any criticism of Java''s bloated > unwieldiness and it got old last century.) >There is no need for a commercial product to monitor a production app, Java 5 comes with the jconsole tool that displays real time performance metrics gathered from the VM, see http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html for an overview. Any service that exposes JMX (Java Management Extensions) beans can be monitored. Hibernate 3 exposes a lot of runtime metrics, see http://www.hibernate.org/hib_docs/v3/api/org/hibernate/jmx/StatisticsServiceMBean.html This information is quite helpful in optimizing performance. What can you configure in your lighttpd-fastcgi-rails stack besides how many fastcgi processes are spawned and how often they are reclaimed? I am writing a Rails app myself and I am searching for information on production environments...> > Having configured lighttpd - fastcgi - rails and tomcat, I know which I''d > rather spend 10 minutes / a couple of hours pissing about with. > And that''s nothing fancy, just ssl. Try adding unit testing and an ant task > (which you get out of the box with rails). >I hope you patched the ruby fastcgi bindings, it seems there is a bug that causes up to 16k leakage on each request.> > I can build ruby faster than I can download a JDK on broadband. > Don''t get me started on trying to get a native JVM built on a non > solaris/linux/windows/osx platform, signing SCSL agreements and swearing at > a humongous dependency tree isn''t my idea of a fun evening. >True, Java is not open source... What platforms are you talking about specifically?> I''m out of that disco and I have never looked back. >
There are also "create table" and "drop table" statements, if needed :) But honestly, what kind of change is so impossible that it is not achievable using sql DDL statements?? Jeremy Huffman wrote:> How does it do this? It generates alter table statements based on your > current db and current model? What if its a change that can''t be done > with alter table? > > Pat Maddox wrote: > >> Yes, you just need to set hibernate.hbm2ddl.auto in your hibernate >> config. >> >>
I don''t know, I''ve never bothered to look at the source to see exactly how it does it. I just know that it does it without requiring any work on my part, and that''s good enough for me. If you''re really interested, it''s all open source, I''m sure you can find it somewhere in there. On Apr 2, 2005 1:37 PM, Jeremy Huffman <jeremy-S3UG9Ld25dVMf0S0rWojDQC/G2K4zDHf@public.gmane.org> wrote:> How does it do this? It generates alter table statements based on your > current db and current model? What if its a change that can''t be done > with alter table? > > Pat Maddox wrote: > > >Yes, you just need to set hibernate.hbm2ddl.auto in your hibernate config. > > > >On Apr 2, 2005 8:59 AM, Jeremy Huffman <jeremy-S3UG9Ld25dVMf0S0rWojDQC/G2K4zDHf@public.gmane.org> wrote: > > > > > >>Zsolt wrote: > >> > >> > >> > >>> If the object model changes then Hibernate can update the db schema > >>>accordingly. So this follows the Object -> Relational mapping > >>>design-wise. > >>> > >>> > >>> > >>Does it do this without dropping your tables and losing your data? > >>_______________________________________________ > >>Rails mailing list > >>Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > >>http://lists.rubyonrails.org/mailman/listinfo/rails > >> > >> > >> > >_______________________________________________ > >Rails mailing list > >Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > >http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > >
I think you are missing the point. If you drop table you''ve lost your data. If hibernate''s method of keeping my data in synch with my model is to drop my tables with each build, I have to maintain that data in separate tables or files and modify *those* when the schema changes. So, I''m repeating myself. Zsolt wrote:> There are also "create table" and "drop table" statements, if needed > :) But honestly, what kind of change is so impossible that it is not > achievable using sql DDL statements?? > > > Jeremy Huffman wrote: > >> How does it do this? It generates alter table statements based on >> your current db and current model? What if its a change that can''t be >> done with alter table? >> >> Pat Maddox wrote: >> >>> Yes, you just need to set hibernate.hbm2ddl.auto in your hibernate >>> config. >>> >>> > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > >
Ara.T.Howard wrote:> the reduction in ambiguity fails when the code reaches 30,000 lines. > consider > this fact: a human being''s understanding is based not only on __what__ > is said > but __how_much__ is said. this is a simple fact : we cannot wrap our > brainsThis is true in general, yet does not apply in this case. On a large project, no one will ever attempt to read the entire code. Yes, I think we can all agree that everyone probably SHOULD attempt to read the code, but few people will -- because they can either sit there and read code all day, or actually write their own code. So, when a person looks at the code he did not write, he is usually asking himself a single question: "how does this class work, and what can I do with it ?" The statically typed, self-documenting language has a clear advantage.> the number of lines of code and number of source files bears a direct > influence on the ability for one person to understand the entire > source base.By that token, Perl should be one of the easiest languages to understand. It''s not.> langs are totally impossible to comprehend. for example this simple type > declaration > > void (*signal(int, void (*)(int )))(int ); > > totally baffles most programmers. as proof i point out that a program > wasYes, I agree, C and C++ have a very crappy syntax, which is why I avoid them whenever possible. I also dislike their typecasting, for the same reasons I dislike dynamic typing. However, these are not the languages that are mentioned in the title of this thread :-)> ~ > echo ''explain void (*signal(int, void (*)(int )))(int );'' | > cdecl -c /dev/stdin > > declare signal as function (int, pointer to function (int) returning > void) > returning pointer to function (int) returning void > clear as mud eh?Yeah. As I said, I dislike C''s syntax, but I can understand the reasoning for it. C is nothing but a thin layer on top of assembly language; prettiness and powerful single-line constructs are not the goal of this language. The goal is to be as efficient, and as predictable (in terms of machine code) as possible. This is why you find C compilers for embedded microcontrollers, but you don''t find Lisp interpreters for them. Like any language, C fills a niche, and it does it well. Note, though, that the title of this thread is still "JAVA people want to beat us" :-)
Robert Lally wrote:>I agree that some tasks may be more suited to one language than >another. For instance writing an OS may be better in C than in Ruby. >But then there are tools that convert Ruby -> C. So would it be better >to write in Ruby and generate the C or not? I don''t really know. > >It would not. I can explain why I think that, if you''re interested, but it''s a bit off-topic.>The goal of corporations is to have developers use a single tool for >everything. They want plug and play developers with easy to understand >skill sets. It is a stupid idea ... but that''s what they want. If your > >No, the goal of corporations is to outdo their competitors somehow; they don''t care about the means, only about the end result. In my experience, most managers don''t know what a "programming language" is at all, so they can''t make decisions about it one way or another... Maybe I''m just jaded, I don''t know.
Dick Davies wrote:>You can look at the instance you have at hand (see my reply to Pat). >''Looking at the class'' does''nt make much sense in a dynamic language. > >... which is exactly why I prefer static typing :-) This way, I can look at the code and figure out what it does; I don''t need to analyze it at runtime as though it were some sort of an alien artifact.
You''re missing something about how it works then. Hibernate''s doesn''t drop your table whenever you make changes to your model - only if you explicitly tell it to. On Apr 2, 2005 2:59 PM, Jeremy Huffman <jeremy-S3UG9Ld25dVMf0S0rWojDQC/G2K4zDHf@public.gmane.org> wrote:> I think you are missing the point. If you drop table you''ve lost your > data. If hibernate''s method of keeping my data in synch with my model is > to drop my tables with each build, I have to maintain that data in > separate tables or files and modify *those* when the schema changes. So, > I''m repeating myself. > > Zsolt wrote: > > > There are also "create table" and "drop table" statements, if needed > > :) But honestly, what kind of change is so impossible that it is not > > achievable using sql DDL statements?? > > > > > > Jeremy Huffman wrote: > > > >> How does it do this? It generates alter table statements based on > >> your current db and current model? What if its a change that can''t be > >> done with alter table? > >> > >> Pat Maddox wrote: > >> > >>> Yes, you just need to set hibernate.hbm2ddl.auto in your hibernate > >>> config. > >>> > >>> > > > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Look, if hibernate generates alter table statements to add a column when I''ve added that member and Xdoclet tag to a java class then great, thats really sharp. But some model changes cannot be done without the programmer specifying how the model will change and how the data will map into it. So I may have a SQL script with some renames, an insert into ... select ... , etc. This is very common, and it varies by DBMS what you can or cannot accomplish with alter table. So if you have to do this, and then modify your hibernate classes to reflect the new model you have repeated yourself. If you don''t do this, then you have lost your data and repeated yourself by re-creating it. If you use Rails, then maybe you''ll do nothing at all. Pat Maddox wrote:>You''re missing something about how it works then. Hibernate''s doesn''t >drop your table whenever you make changes to your model - only if you >explicitly tell it to. > > > >On Apr 2, 2005 2:59 PM, Jeremy Huffman <jeremy-S3UG9Ld25dVMf0S0rWojDQC/G2K4zDHf@public.gmane.org> wrote: > > >>I think you are missing the point. If you drop table you''ve lost your >>data. If hibernate''s method of keeping my data in synch with my model is >>to drop my tables with each build, I have to maintain that data in >>separate tables or files and modify *those* when the schema changes. So, >>I''m repeating myself. >> >>Zsolt wrote: >> >> >> >>>There are also "create table" and "drop table" statements, if needed >>>:) But honestly, what kind of change is so impossible that it is not >>>achievable using sql DDL statements?? >>> >>> >>>Jeremy Huffman wrote: >>> >>> >>> >>>>How does it do this? It generates alter table statements based on >>>>your current db and current model? What if its a change that can''t be >>>>done with alter table? >>>> >>>>Pat Maddox wrote: >>>> >>>> >>>> >>>>>Yes, you just need to set hibernate.hbm2ddl.auto in your hibernate >>>>>config. >>>>> >>>>> >>>>> >>>>> >>>_______________________________________________ >>>Rails mailing list >>>Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >>>http://lists.rubyonrails.org/mailman/listinfo/rails >>> >>> >>> >>> >>_______________________________________________ >>Rails mailing list >>Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >>http://lists.rubyonrails.org/mailman/listinfo/rails >> >> >> >_______________________________________________ >Rails mailing list >Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >http://lists.rubyonrails.org/mailman/listinfo/rails > > > >
That''s a lot of maybes. I''ve never made any changes to the db that weren''t easily done with an alter table, so that worked for me. I''ve only used it with MySQL and PostGreSQL. Sure, in some cases it won''t work out, and you have to do more work. So don''t use it if you want. For the many common cases where it does work well, it''s nothing evil. Your series of questions made it pretty clear you''re trying to poke a hole in how Hibernate does things, and the frustration showed in the last one. All I''m saying is that it''s not even a big deal, because I don''t support 100% of the existing DBMSes, thus I don''t write or care about 100% DBMS portable code. Hibernate works for me in that regard. On Apr 2, 2005 4:44 PM, Jeremy Huffman <jeremy-S3UG9Ld25dVMf0S0rWojDQC/G2K4zDHf@public.gmane.org> wrote:> Look, if hibernate generates alter table statements to add a column when > I''ve added that member and Xdoclet tag to a java class then great, thats > really sharp. But some model changes cannot be done without the > programmer specifying how the model will change and how the data will > map into it. So I may have a SQL script with some renames, an insert > into ... select ... , etc. This is very common, and it varies by DBMS > what you can or cannot accomplish with alter table. So if you have to do > this, and then modify your hibernate classes to reflect the new model > you have repeated yourself. If you don''t do this, then you have lost > your data and repeated yourself by re-creating it. If you use Rails, > then maybe you''ll do nothing at all. > > Pat Maddox wrote: > > >You''re missing something about how it works then. Hibernate''s doesn''t > >drop your table whenever you make changes to your model - only if you > >explicitly tell it to. > > > > > > > >On Apr 2, 2005 2:59 PM, Jeremy Huffman <jeremy-S3UG9Ld25dVMf0S0rWojDQC/G2K4zDHf@public.gmane.org> wrote: > > > > > >>I think you are missing the point. If you drop table you''ve lost your > >>data. If hibernate''s method of keeping my data in synch with my model is > >>to drop my tables with each build, I have to maintain that data in > >>separate tables or files and modify *those* when the schema changes. So, > >>I''m repeating myself. > >> > >>Zsolt wrote: > >> > >> > >> > >>>There are also "create table" and "drop table" statements, if needed > >>>:) But honestly, what kind of change is so impossible that it is not > >>>achievable using sql DDL statements?? > >>> > >>> > >>>Jeremy Huffman wrote: > >>> > >>> > >>> > >>>>How does it do this? It generates alter table statements based on > >>>>your current db and current model? What if its a change that can''t be > >>>>done with alter table? > >>>> > >>>>Pat Maddox wrote: > >>>> > >>>> > >>>> > >>>>>Yes, you just need to set hibernate.hbm2ddl.auto in your hibernate > >>>>>config. > >>>>> > >>>>> > >>>>> > >>>>> > >>>_______________________________________________ > >>>Rails mailing list > >>>Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > >>>http://lists.rubyonrails.org/mailman/listinfo/rails > >>> > >>> > >>> > >>> > >>_______________________________________________ > >>Rails mailing list > >>Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > >>http://lists.rubyonrails.org/mailman/listinfo/rails > >> > >> > >> > >_______________________________________________ > >Rails mailing list > >Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > >http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > >
I posted my views on my blog at http://www.sitharus.com/blog/archives/2005/04/rails_vs_java.html Anyway, I am getting fed up with this cluttering up my Rails folder, it''s really not suited to this list. Try alt.flamewars or alt.neverendingarguments on usenet for a better place ;) -- Phillip Hutchings http://www.sitharus.com/ sitharus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org / sitharus-QrR4M9swfipWk0Htik3J/w@public.gmane.org
> Anyway, I am getting fed up with this cluttering up my Rails folder, > it''s really not suited to this list. Try alt.flamewars or > alt.neverendingarguments on usenet for a better place ;)I think stuff like "Would I deploy Rails on a complex application? No, not yet." is what keeps the flamewars alive because of the missing bounds. When is something complex? Is the e-commerce project Jeremy Kemper is working on for CD Baby that''s aiming to replace 70 KLOC PHP and handles millions of dollars in sales complex? Or do we need to go to the 10K domain objects, running-for-10-years, 50-guys setup in Smalltalk that another one in the thread was talking about? It''s funny, though. I actually consider the complex label to be somewhat of a badmouthing term in most cases. That if you''re aiming to build a complex application, your priorities aren''t straight. Naturally, some domains are inherently complex and defines simplification, but I reckon far less than receives the complex approach by default. But I digress... The point is that an unbounded "can''t do complex" assertion amounts to slander. And that''s what provokes the push back. Now, I surely shouldn''t be one to say that provocations aren''t a meaningful way to start a heated discussion :). As long as you''re fully aware of the consequences and that is your intent, then so be it. -- David Heinemeier Hansson, http://www.basecamphq.com/ -- Web-based Project Management http://www.rubyonrails.org/ -- Web-application framework for Ruby http://www.loudthinking.com/ -- Broadcasting Brain
On Apr 3, 2005 10:37 PM, David Heinemeier Hansson <david-OiTZALl8rpK0mm7Ywyx6yg@public.gmane.org> wrote:> > Anyway, I am getting fed up with this cluttering up my Rails folder, > > it''s really not suited to this list. Try alt.flamewars or > > alt.neverendingarguments on usenet for a better place ;) > > I think stuff like "Would I deploy Rails on a complex application? No, > not yet." is what keeps the flamewars alive because of the missing > bounds. When is something complex? Is the e-commerce project Jeremy > Kemper is working on for CD Baby that''s aiming to replace 70 KLOC PHP > and handles millions of dollars in sales complex? Or do we need to go > to the 10K domain objects, running-for-10-years, 50-guys setup in > Smalltalk that another one in the thread was talking about?I think my recipes app that is ~300 lines of code in Rails would be complex in PHP, especially with things like ingredient linking and many-to-many tags. Why? Rails is far simpler than PHP in my opinion, less development time and fewer lines of code for me to maintain.> It''s funny, though. I actually consider the complex label to be > somewhat of a badmouthing term in most cases. That if you''re aiming to > build a complex application, your priorities aren''t straight. > Naturally, some domains are inherently complex and defines > simplification, but I reckon far less than receives the complex > approach by default. But I digress...You never aim to build a complex application, unless you''re extremely misguided. Always aim for the simplest possible solution.> The point is that an unbounded "can''t do complex" assertion amounts to > slander. And that''s what provokes the push back. Now, I surely > shouldn''t be one to say that provocations aren''t a meaningful way to > start a heated discussion :). As long as you''re fully aware of the > consequences and that is your intent, then so be it.Complex is a matter of opinion. The system I work on for my day job was ~10k lines of PHP code last time I ran doxygen, it''s complex by my standards. If I could convince my boss to allow me to clean up the entire thing (8ish years of legacy code) it''d be straight on to Rails. Some people may think that their 50k Java apps are complex - but how many lines are generated by their IDE? So I guess the answer to ''Would you deploy a complex application on Rails'' is yes, for me. I think the ability to create an maintain any application on any framework is a reflection of programmer ability, not the framework directly. However, Rails will never silence the nay-sayers until we have something that performs the same tasks as the Java apps. I choose not to listen to them and just get on with what I do. -- Phillip Hutchings http://www.sitharus.com/ sitharus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org / sitharus-QrR4M9swfipWk0Htik3J/w@public.gmane.org
I''ve been following this thread for a while, and as "one of those Java guys" whose also pretty into rails, I thought I''d share my take on it. It got pretty long so I threw it up on http://myelinate.com/entry/show/J2EE-vs-Rails The whole thread is a big pain in the ass. I don''t really see it as an either or sort of thing. I''ve been a full-time Java Architect for going on 5 years now -- I originally started my career at Sun''s Java Center -- and Java is a great language and environment with it''s share of annoyances. IDEA IntelliJ, for example, is an amazing development environment, and if you would be well advised to check it out and learn what you lose with the simplicity of using a text editor as a programming program. (What exactly is so great about a text editor? I mean it''s great that we can leverage the power of the unix pipe, but it''s like a untouchable idol or something.) Java/J2EE and Ruby/Rails are two wholly different things. J2EE provides a framework and architectural building blocks with which you architect and build a solution to a wide class of difficult problems. Rails is an achitecture itself which you use to build a solution for a smaller, bounded problem -- database backed websites. And it certainly solves that problem well. I find Rails an energizing environment to work with, and the more I get into it the more ideas I have and the deeper I want to go. But the nimbleness of the language is it to some extent off-set by the architectural choices which have been made, and which have an air of "no you''re wrong, this is the one true way" attitude of certain Rails luminaries. I think we''ve been down that road enough and are willing to ascribe it to youthful enthusiasm. And to be honest, there''s plenty of people in the Java community whose knee-jerk defensiveness has been pretty ugly. I started this post wanting to talk about Hibernate vs ActiveRecord, because that''s what the original article which triggered this whole thing started with. The biggest issue in my mind is: for the particular application that I''m currently designing, does the "ActiveRecord":http://www.martinfowler.com/eaaCatalog/activeRecord.html pattern or "DataMapper":http://www.martinfowler.com/eaaCatalog/dataMapper.html pattern make the most amount of sense? We can discuss the merits of this, but if you are using Rails, the "decision has already been made for you":http://www.loudthinking.com/arc/000209.html Perhaps for the majority of web applications out there -- or, if you''ve got people coming in from the semantic paucity of the PHP universe -- modeling your domain objects as rows of data in inter-related tables is good enough. There''s an incredible impedance mismatch (OO vs RDB) there which is the reason why we have DataMapper in the first place. That''s not going to cut it for the non-trivial case, even if by non-trivial I mean <5% of the problem domain. Hibernate does solve those problems. You need to map to existing schema? No problem. You need to split subclasses across different tables? You want to query collections aggressively using outer joins, rather than N+1? Simple. How about actually caching objects, or dealing with distributed cache invalidation? Tweak the config. (I have personal issues with the whole Share Nothing architecture. Don''t mind me.) Come to think of it, TopLink has a better solution for these problems than Hibernate does -- its Object caching is sort of unearthly in its power. But Hibernate is free and the basis for EJB 3.0, so it''s the dominant Java player. In many ways, you could say that Hibernate is "better" than ActiveRecord in every way except for ease of use, where ActiveRecord blows the competition out of the water. "Easy to use" is a completely valid definition for "better" -- it is, for example, why Rails is going to take over the low end market -- but the high end will always define "better" as "more complete," and then be surprised when the low end prices them out of the market. ActiveRecord doesn''t have an answer to creating an in memory OODB from a RDB because it''s not designed to do that. The architecture is specified and the tradeoffs have been made for you. Does this matter? I''m not fully certain at this point, I''m still "learning how it works":http://myelinate.com/entry/show/ActiveRecord-modules-acts_as_nested_list Let''s just acknowledge that we aren''t talking about the same thing. You get quite a lot from the overt simplicity of "just making the rows of your database tables come alive," and maybe that''s worth the trade off for the majority of people. But it''s an architectural mandate of using ActiveRecord as a persistence layer, and if that doesn''t fit your needs you have to completely throw ActiveRecord out instead of incrementally improving your already working and tested code. No discussion about Java and Rails would be complete without at least briefly touching upon the Java world''s visceral aversion to deriving from a common base class for domain objects. This has always been a problem using Entity Beans, and is one of the more damning charges against the Struts framework. (Which for those PHP/Ruby folks out there, is one of the more common Java MVC frameworks which, to the agreement of many, is considered to Suck. I prefer Spring-MVC, and WebWork2 is popular, but Tapestry is probably the most interesting and Seaside-like. Don''t get me started about Java Server Faces...) With Java''s single inheritance static object model, deriving from an (abstract or concrete) class is problematic. Especially for creating regression tests, but there are other issues. The problems were not clear initially, and it is somewhat of a lesson learned through being burned, so Java folks aren''t going to forget it any time soon. This issue is largely assuaged by Ruby''s dynamic typing. I''m getting a little winded here, but I''ll point you to: http://blogs.pragprog.com/cgi-bin/pragdave.cgi/Tech/TransparentIOC.rdoc J2EE and Rails are very different. J2EE focuses in the completeness of the problem domain, while Rails is focusing on the completeness of a particular solution within a domain. They both have their place, but J2EE''s architectural possibilities are more vast, so people prone to being "architects" are obviously going to chafe under Rails regime. Even if they tend to over engineer to solve problems which they may not actually have. My team uses Spring + Hibernate for most projects at work, and we use TopLink for others. I''m very happy with it so far, and there are some things that it does which Rails isn''t yet up to. I do think that Rails is an important technology -- it''s certainly a lot of fun and I''ve been spending a lot of time developing my personal projects with it. But let''s realize that, while they both can send HTML data over a socket, they aim to solve much different problem with different constraints. Rails is giving you everything on a platter, while J2EE gives you a huge framework to deal with abstruse, integrating the enterprise type problems.
Phillip Hutchings wrote:>On Apr 3, 2005 10:37 PM, David Heinemeier Hansson ><david-OiTZALl8rpK0mm7Ywyx6yg@public.gmane.org> wrote: > > > > > >>The point is that an unbounded "can''t do complex" assertion amounts to >>slander. And that''s what provokes the push back. Now, I surely >>shouldn''t be one to say that provocations aren''t a meaningful way to >>start a heated discussion :). As long as you''re fully aware of the >>consequences and that is your intent, then so be it. >> >> > >Complex is a matter of opinion. The system I work on for my day job >was ~10k lines of PHP code last time I ran doxygen, it''s complex by my >standards. If I could convince my boss to allow me to clean up the >entire thing (8ish years of legacy code) it''d be straight on to Rails. >Some people may think that their 50k Java apps are complex - but how >many lines are generated by their IDE? > > >I agree a problem is the definition of complexity. I don''t think the complexity of an implementation says anything at all good about a language or platform. Rather, whats good is if you can make a simple implementation of a complex domain. Measuring size and complexity is a great problem in software development. There is no really good benchmark for objectively determining the size of the feature set. So unless you attempt to write the same application in two languages you can''t really compare apples to apples. Even those comparisans are usually flawed when they speak about effort since doing the first implementation teaches you so much about your problem domain and the type of user interaction you want which you can apply the second time around without stopping to think about it.
Pat Maddox wrote:>That''s a lot of maybes. I''ve never made any changes to the db that >weren''t easily done with an alter table, so that worked for me. I''ve >only used it with MySQL and PostGreSQL. Sure, in some cases it won''t >work out, and you have to do more work. So don''t use it if you want. >For the many common cases where it does work well, it''s nothing evil. > >Your series of questions made it pretty clear you''re trying to poke a >hole in how Hibernate does things, and the frustration showed in the >last one. All I''m saying is that it''s not even a big deal, because I >don''t support 100% of the existing DBMSes, thus I don''t write or care >about 100% DBMS portable code. Hibernate works for me in that regard. > > > >Actually I''m not trying to poke a hole in Hibernate - I had assumed there was a hole here and I''m glad to hear that there isn''t. If you can truly make all (or nearly all) your model changes only one time, in the .java file - then that is a big win. I assumed this was really only practical for the first iteration and that later changes would have you making them in the database manually and then in the model - thanks for clearing it up.
On Apr 3, 2005 1:39 AM, Julian ''Julik'' Tarkhanov <listbox-RY+snkucC20@public.gmane.org> wrote:> It is not only about the enterprise - simple convenience too. > I am a bit lost when I have to make a PHP app talk to a DB without > resorting to ADODB (i.e. to a common data access layer that I know > absolutely out of my head).Sorry for being OOT, but since I''m coming from the PHP world, I want to respond to this. In PHP 4 world you had several good choices (in my order of preference): PEAR MDB[2], ADODB, PEAR DB. In PHP 5 you''ll have to add Creole+Propel which looks very good, and the API is Java-ish. In the upcoming PHP 5.1 you''ll have PDO and it''s going to be supported by the previously mentioned database libraries. I like MDB because it has fully database-independent schemas and you can alter your schemas, update your database, without losing data (at least I tried that in MySQL).> On 2-apr-05, at 11:04, Robert Lally wrote: > > > > Libraries, I said I would come back to it, here it is. Ruby is missing > > libraries that are essential to get it acceptance in big > > organisations. Database access for instance. Ruby doesn''t have a > > standard interface to different databases. Ruby DBI is the closest,VERY. Very true. When I downloaded mysql-ruby, I wondered, "what the heck is this? compile it first?" As a Windows user we always had the privilege of always downloading binary versions of any software ;-) If I compare Ruby with PHP (regarding database support), PHP from the very early days had supplied a completely binary distribution with mysql [extension] support built-in. True, the API varies between databases but at least it works and you don''t need to care about any other stuff other than use it. And with the invent of database abstraction libraries, we can develop [nearly] database-independent apps with it. I guess this is to be expected for a "not very mature" (sorry) product such as Ruby (as a whole development platform, not just the interpreter).> > DBI was viable rails would use it. It ( to my knowledge ) doesn''t. Too > > many Ruby projects are one man bands for people to trust it DBI, Wee, > > Ruby itself, Nitro, Og, Needle, Copeland, Rake.I don''t really think "one man projects" are a bad thing, if the maintainer actively develops on it (for whatever reason...) Linux [kernel] is basically a one man project. The excellent PEAR MDB library on PHP is also Lukas Smith''s personal project. Even the core PEAR library itself (on PHP too) is also one man project. The really bad thing would be if the project somehow goes ''abandoned'', as this happens too often on many one-manned open source projects. Look at Netscape 4... it''s hardly a "one man project". But it was sooo terrible that the open source community (whoever they are) decided to rebuild the project from scratch even though Netscape''s source code is already open. -- Hendy Irawan - http://dev.gauldong.net - GaulDong Developer Center
Generics have been in Mono for a while now, IIRC. Hendy Irawan wrote:> On Apr 3, 2005 5:20 AM, Stanislav Freidin <bugmaster-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote: > >>Dick Davies wrote: >> >> >>>You can look at the instance you have at hand (see my reply to Pat). >>>''Looking at the class'' does''nt make much sense in a dynamic language. >>> >> >>... which is exactly why I prefer static typing :-) This way, I can look >>at the code and figure out what it does; I don''t need to analyze it at >>runtime as though it were some sort of an alien artifact. > > > So, it''s true: Ruby doesn''t have class variables/properties/attributes? > What about static class members? > > Damn, I guess I should have read more of the FAQs... The only reason > why I use PHP is because it has the widest support/features/blabla, > not because I particularly liked the language. Ruby seems promising > but the libraries suck (currently), and even more about webhosting > support for this particular [minor?] language. I have to say my only > favorite programming language would be C#, if only it already had > generics (templates, for you C++ guys), ... plus explicitly specified > dynamic properties (i.e. "expando" properties) would be great. >---------- Scanned for viruses by ClamAV
On Apr 3, 2005 5:20 AM, Stanislav Freidin <bugmaster-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote:> Dick Davies wrote: > > >You can look at the instance you have at hand (see my reply to Pat). > >''Looking at the class'' does''nt make much sense in a dynamic language. > > > ... which is exactly why I prefer static typing :-) This way, I can look > at the code and figure out what it does; I don''t need to analyze it at > runtime as though it were some sort of an alien artifact.So, it''s true: Ruby doesn''t have class variables/properties/attributes? What about static class members? Damn, I guess I should have read more of the FAQs... The only reason why I use PHP is because it has the widest support/features/blabla, not because I particularly liked the language. Ruby seems promising but the libraries suck (currently), and even more about webhosting support for this particular [minor?] language. I have to say my only favorite programming language would be C#, if only it already had generics (templates, for you C++ guys), ... plus explicitly specified dynamic properties (i.e. "expando" properties) would be great. -- Hendy Irawan - http://dev.gauldong.net - GaulDong Developer Center
Hi, On Apr 3, 2005 2:22 PM, Hendy Irawan <gauldong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On Apr 3, 2005 5:20 AM, Stanislav Freidin <bugmaster-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote: > > Dick Davies wrote: > > > > >You can look at the instance you have at hand (see my reply to Pat). > > >''Looking at the class'' does''nt make much sense in a dynamic language. > > > > > ... which is exactly why I prefer static typing :-) This way, I can look > > at the code and figure out what it does; I don''t need to analyze it at > > runtime as though it were some sort of an alien artifact. > > So, it''s true: Ruby doesn''t have class variables/properties/attributes? > What about static class members? > > Damn, I guess I should have read more of the FAQs... The only reason > why I use PHP is because it has the widest support/features/blabla, > not because I particularly liked the language. Ruby seems promising > but the libraries suck (currently), and even more about webhosting > support for this particular [minor?] language. I have to say my only > favorite programming language would be C#, if only it already had > generics (templates, for you C++ guys), ... plus explicitly specified > dynamic properties (i.e. "expando" properties) would be great.I''m kind of disillusioned about mainstream programming. Good luck finding the one true awesome tool that''s not Ruby. :-) Cheers, Joao
Hendy, On 3.4.2005, at 20:22, Hendy Irawan wrote:> On Apr 3, 2005 5:20 AM, Stanislav Freidin <bugmaster-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> > wrote: >> Dick Davies wrote: >> >>> You can look at the instance you have at hand (see my reply to Pat). >>> ''Looking at the class'' does''nt make much sense in a dynamic language. >>> >> ... which is exactly why I prefer static typing :-) This way, I can >> look >> at the code and figure out what it does; I don''t need to analyze it at >> runtime as though it were some sort of an alien artifact. > > So, it''s true: Ruby doesn''t have class variables/properties/attributes? > What about static class members?These things have nothing to do with static typing. And no, someone has told you lies. Ruby does have class variables, methods and what not. It is very thoroughly thought-of "real" object language so it indeed has most excellent support for OO concepts, maybe the best of all programming languages. (Only maybe.This isn''t supposed to be provocative at all). The fact that Ruby doesn''t have static typing is not a missing feature, it''s a design decision. To fully understand and appreciate the OO (and other) features in Ruby, I strongly suggest reading Programming Ruby, second edition [1] or the free online version of the first edition [2]. Cheers, Jarkko [1] http://www.pragmaticprogrammer.com/titles/ruby/index.html [2] http://www.rubycentral.com/book/ -- Jarkko Laine http://jlaine.net http://odesign.fi _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
In article <b244e1b2050403083413142a68-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>, wschenk- Re5JQEeQqe8AvxtiuMwx3w-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org says...> Java/J2EE and Ruby/Rails are two wholly different things. J2EE > provides a framework and architectural building blocks with which you > architect and build a solution to a wide class of difficult problems. > Rails is an achitecture itself which you use to build a solution for a > smaller, bounded problem -- database backed websites. And it > certainly solves that problem well.That is so well put that it bears repeating. Then again, I haven''t used either yet much. Maybe all the big words just impressed me. But it sounds right. -- Jay Levitt | Wellesley, MA | I feel calm. I feel ready. I can only Faster: jay at jay dot fm | conclude that''s because I don''t have a http://www.jay.fm | full grasp of the situation. - Mark Adler
Heya :)> -----Original Message----- > From: rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org [mailto:rails- > bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] On Behalf Of David Heinemeier Hansson > Sent: Sunday, April 03, 2005 6:38 AM > To: sitharus-QrR4M9swfipWk0Htik3J/w@public.gmane.org; rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > Subject: Re: [Rails] Re: Java people want to beat us > > > Anyway, I am getting fed up with this cluttering up my Rails folder, > > it''s really not suited to this list. Try alt.flamewars or > > alt.neverendingarguments on usenet for a better place ;) > > I think stuff like "Would I deploy Rails on a complex application? No, > not yet." is what keeps the flamewars alive because of the missing > bounds.I agree. It''s sort of like making a declaration on what operating system is "better" :) Personally, I see both sides. I work on a lot of simple (to me) systems where AcriveRecord makes sense... and others that are complex (to me) where limiting my ORM in the fashion AR is limited would simply not work. In terms of languages, the same thing applies. Ruby is a great language, rapidly taking the place of PHP in my mind for many smaller problem spaces - but I would not use Ruby for a large (to me) project ... the dynamic typing is inherently risky (to me) for this purpose. Soulhuntre ---------- http://www.girl2.com - my girls http://www.the-estate.com - my legacy http://wiki.thegreybook.com - my project http://weblog.soulhuntre.com - my thoughts
Hear hear! This annoying thread is at least throwing up (excuse the double entendre) more than its fair share of well-written, insightful commentaries. Well done, Will. On Monday, April 4, 2005, 1:34:06 AM, Will wrote:> I''ve been following this thread for a while, and as "one of those Java > guys" whose also pretty into rails, I thought I''d share my take on > it. It got pretty long so I threw it up on> http://myelinate.com/entry/show/J2EE-vs-Rails> [...]
Hi...> > So, it''s true: Ruby doesn''t have class variables/properties/attributes? > > What about static class members? > > These things have nothing to do with static typing. And no, someone has > told you lies. Ruby does have class variables, methods and what not. It > is very thoroughly thought-of "real" object language so it indeed has > most excellent support for OO concepts, maybe the best of all > programming languages. (Only maybe.This isn''t supposed to be > provocative at all). > > The fact that Ruby doesn''t have static typing is not a missing feature, > it''s a design decision. To fully understand and appreciate the OO (and > other) features in Ruby, I strongly suggest reading Programming Ruby, > second edition [1] or the free online version of the first edition [2].So it does... I have just read the [first chapter] of Programming Ruby, so it has [static] class variables after all. But it doesn''t seem to have a way of declaring instance variables in the class definition? I mean, something like this in C#: /// <summary>Some documentation</summary> public int SomeVariable; if in the future I want to change it to: /// <summary>Some documentation</summary> public int SomeVariable { get { return someVariable; } set { someVariable = value; } } (which basically is the same thing, I just need it to demonstrate the property can be treated as a member variable no matter how the internal implementation is). It seems in Ruby I have to declare the accessors right from the start, or...? And the <summary> line is there for a purpose. I like to declare a variable by its own line and add documentation above. This will hold true for all and any programming language I work with... -- Hendy Irawan - http://dev.gauldong.net - GaulDong Developer Center
* Hendy Irawan <gauldong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [0435 13:35]:> /// <summary>Some documentation</summary> > public int SomeVariable; > > if in the future I want to change it to: > > /// <summary>Some documentation</summary> > public int SomeVariable { get { return someVariable; } set { > someVariable = value; } } > > (which basically is the same thing, I just need it to demonstrate the > property can be treated as a member variable no matter how the > internal implementation is). > > It seems in Ruby I have to declare the accessors right from the start, or...?yes, because data is private by default. However, you can replace attr_accessor :value with def value generate_value_on_the_fly end and no one will have to be nailed to anything. -- ''Some people, when confronted with a problem, think I know, I''ll use regular expressions. Now they have two problems.'' -- Jamie Zawinski Rasputin :: Jack of All Trades - Master of Nuns
Sorry for making this on rails... I guess this should be on ruby-talk or even on nothing ;-)> Keep on reading ;-) You will learn that Ruby is a really dynamic > language and that you can open up any class whenever you want and do > the changes you want to. There is no compilation so nothing is bound in > the compile-time. I didn''t completely understand what you were after, > tho, so O''m not sure if this answered your question.While I like dynamic languages (like PHP and Ruby)... I also think that it''s sometimes dangerous. While developing websites with PHP it''s easy to make a critical typo in one file and NOT causing an error. Some say "well that''s the dynamic part" but to me these kinds of circumstances are more frustrating than helping. Fortunately in PHP 4 they''re actually parsing the file first before actually running (i.e. interpreting) it, so if there are any critical (i.e. parse-time) typos they''ll get addressed even before the script runs. It still doesn''t help for runtime errors, or on files which are part of the project but never got run because the code isn''t even executed. In developing with statically typed, compiled, languages, we have the luxury that if the project compiles, then you can be "almost" sure that all of your files are "free from typos" and at least all functions are referring to actually existing functions, all types refer to existing types, etc. and you''ll only get runtime exceptions, not "Function not found: ''putz'', did you mean ''puts''?" (I wish compilers/interpreters had this sort of Google-like suggestion ;-) in the middle of running the program. PHP, which started as completely dynamic, is now adding more static typing functionality into it. Like "type hinting", which appears on PHP 5. Hey!? Isn''t that static typing? Yes, it is, on a dynamically typed language. IMHO, dynamic languages should be able to perform most of the static typing languages do (including static type checks, like PHP''s type hinting) but remove the limitations of static typed languages. BTW who controlled Ruby? And... errr... Rails? -- Hendy Irawan - http://dev.gauldong.net - GaulDong Developer Center
On Apr 4, 2005 8:11 PM, Dick Davies <rasputnik-ogHSZ3ARDZIOXkKaSkYkkl6hYfS7NtTn@public.gmane.org> wrote:> * Hendy Irawan <gauldong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [0435 13:35]: > yes, because data is private by default.A "different" private, as I read...> However, you can replace > > attr_accessor :value > > with > > def value > generate_value_on_the_fly > end > > and no one will have to be nailed to anything.Nice... so what''s the difference between a method and a variable/property in Ruby? attr_accessor :somevar with: def somevar return anothervar end def somevar=(value) # is this the way to do it? anothervar=value end the same thing? But if I do define (methods) somevar and somevar=(value), how can I declare these as a "property" (remember, we actually had defined these methods, so we can''t define another ''attr_accessor'' that refers to the same variables, right?)? In C#, getters and setters are anonymous... so we''re actually treating the property like a normal member field/variable. In Java, you had to use that get*/set* syntactic salt so you''d sprinkle the documentation of the actual "property/variable" on these two functions (I never liked explicitly named getter/setters by the way). In Ruby? -- Hendy Irawan - http://dev.gauldong.net - GaulDong Developer Center
On Apr 4, 2005 9:09 PM, Gavin Sinclair <gsinclair-81uBx+iSpXA0n/F98K4Iww@public.gmane.org> wrote:> On Monday, April 4, 2005, 11:27:39 PM, Hendy wrote: > > > and you''ll only get runtime exceptions, > > not "Function not found: ''putz'', did you mean ''puts''?" (I wish > > compilers/interpreters had this sort of Google-like suggestion ;-) in > > the middle of running the program. > > Untested, example code only:...> > You have to define String#closest_match(array). You should also > remember the user''s answer so you don''t ask the same question all the > time.Nice ;-) I didn''t expect that to be responsed ;-) But thanks! :-D -- Hendy Irawan - http://dev.gauldong.net - GaulDong Developer Center
On Apr 4, 2005 9:27 AM, Hendy Irawan <gauldong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Sorry for making this on rails... I guess this should be on ruby-talk > or even on nothing ;-) > > > Keep on reading ;-) You will learn that Ruby is a really dynamic > > language and that you can open up any class whenever you want and do > > the changes you want to. There is no compilation so nothing is bound in > > the compile-time. I didn''t completely understand what you were after, > > tho, so O''m not sure if this answered your question. > While I like dynamic languages (like PHP and Ruby)... I also think > that it''s sometimes dangerous. While developing websites with PHP it''s > easy to make a critical typo in one file and NOT causing an error. > Some say "well that''s the dynamic part" but to me these kinds of > circumstances are more frustrating than helping. Fortunately in PHP 4 > they''re actually parsing the file first before actually running (i.e. > interpreting) it, so if there are any critical (i.e. parse-time) typos > they''ll get addressed even before the script runs. It still doesn''t > help for runtime errors, or on files which are part of the project but > never got run because the code isn''t even executed. > > In developing with statically typed, compiled, languages, we have the > luxury that if the project compiles, then you can be "almost" sure > that all of your files are "free from typos" and at least all > functions are referring to actually existing functions, all types > refer to existing types, etc. and you''ll only get runtime exceptions, > not "Function not found: ''putz'', did you mean ''puts''?" (I wish > compilers/interpreters had this sort of Google-like suggestion ;-) in > the middle of running the program. > > PHP, which started as completely dynamic, is now adding more static > typing functionality into it. Like "type hinting", which appears on > PHP 5. Hey!? Isn''t that static typing? Yes, it is, on a dynamically > typed language. IMHO, dynamic languages should be able to perform most > of the static typing languages do (including static type checks, like > PHP''s type hinting) but remove the limitations of static typed > languages. > > BTW who controlled Ruby? And... errr... Rails? > > -- > Hendy Irawan - http://dev.gauldong.net - GaulDong Developer Center > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >That is why people who like dynamic languages, tend to really like unit testing too. Unit testing catches not only these sort of type issues, but will catch additional bugs as well. If you do a good job of unit testing then (in my experience), the errors you are worried about do not happen. Patrick
On Apr 4, 2005 10:12 PM, Patrick Hurley <phurley-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> That is why people who like dynamic languages, tend to really like > unit testing too. Unit testing catches not only these sort of type > issues, but will catch additional bugs as well. If you do a good job > of unit testing then (in my experience), the errors you are worried > about do not happen.Very true. Unfortunately I had even heard of "test-driven development" is only just a month ago. Anyways, is it actually possible to test rails apps? I mean, even running it would mean starting up all those [heavy] framework stuff, database reflection thingy and whatnot... (that''s possible, but remember that most unit tests should run as fast as possible, and, errrr... somewhat "independent" so one test shouldn''t affect another''s results). Do we expect our app to "uncouple" from Rails? Perhaps not? Or we create a Rails mock object? (isn''t that would be too complicated?) I''d like to hear some of your experiences and all of you guys too... -- Hendy Irawan - http://dev.gauldong.net - GaulDong Developer Center
On Apr 4, 2005 8:20 AM, Hendy Irawan <gauldong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On Apr 4, 2005 10:12 PM, Patrick Hurley <phurley-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > That is why people who like dynamic languages, tend to really like > > unit testing too. Unit testing catches not only these sort of type > > issues, but will catch additional bugs as well. If you do a good job > > of unit testing then (in my experience), the errors you are worried > > about do not happen. > > Very true. Unfortunately I had even heard of "test-driven development" > is only just a month ago. Anyways, is it actually possible to test > rails apps? I mean, even running it would mean starting up all those > [heavy] framework stuff, database reflection thingy and whatnot... > (that''s possible, but remember that most unit tests should run as fast > as possible, and, errrr... somewhat "independent" so one test > shouldn''t affect another''s results). Do we expect our app to > "uncouple" from Rails? Perhaps not? Or we create a Rails mock object? > (isn''t that would be too complicated?) > > I''d like to hear some of your experiences and all of you guys too... > -- > Hendy Irawan - http://dev.gauldong.net - GaulDong Developer Center > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >Rails is set up from the start to not only support but to _encourage_ testing. Unit testing for your models and functional testing for controllers and mailing are both automatically done when you run ''rake'' in your rails root directory. Skeleton files for testing any new model/controller are automatically generated when you use the ''generate'' script to create skeleton implementation files as well. The is a ''testing'' environment available by default, which uses a separate database, automatically clears it out for each test, and sets up fixture data for you as well. As for running as fast as possible, the initial startup of the test run takes, maybe, 5 seconds, after which all the tests run very quickly (depending on what you''re doing in them). Dave -- Dave Goodlad dgoodlad-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org or dave-eHfbeeWWzZOw5LPnMra/2Q@public.gmane.org http://david.goodlad.ca/
* Hendy Irawan <gauldong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [0420 16:20]:> is only just a month ago. Anyways, is it actually possible to test > rails apps? I mean, even running it would mean starting up all those > [heavy] framework stuff, database reflection thingy and whatnot...Are you talking from experience, or are you guessing?> (that''s possible, but remember that most unit tests should run as fast > as possible, and, errrr... somewhat "independent" so one test > shouldn''t affect another''s results).Have you read the docs? Maybe try that, you seem to be making a lot of assumptions. There''s a testing book at: http://manuals.rubyonrails.com/read/book/5 -- ''Everybody I know who is right always agrees with ME.'' -- Rev Lady Mal Rasputin :: Jack of All Trades - Master of Nuns
On 04/04/2005, at 11:34 PM, Hendy Irawan wrote:> Nice... so what''s the difference between a method and a > variable/property in Ruby?From the perspective of the user of your object, nothing. Ruby has language constructs for the ''Uniform Access Principle'', just like C#. Ruby provides the convenience methods attr_reader, attr_writer and attr_accessor, which you can use at the top of your class to define your properties. Then, when you need to, you can remove the attr_''s and put in the relevant property and property=(value) functions. For example, run this code in Ruby: class SimpleCar attr_accessor :engine end class ComplexCar def engine @engine end def engine=(newEngine) @engine = newEngine end end c1 = SimpleCar.new c1.engine = ''v8'' c2 = ComplexCar.new c2.engine = ''v8'' puts "c1 = #{c1.engine}, c2 = #{c2.engine}" On 04/04/2005, at 11:27 PM, Hendy Irawan wrote:> PHP, which started as completely dynamic, is now adding more static > typing functionality into it. Like "type hinting", which appears on > PHP 5. Hey!? Isn''t that static typing? Yes, it is, on a dynamically > typed language. IMHO, dynamic languages should be able to perform most > of the static typing languages do (including static type checks, like > PHP''s type hinting) but remove the limitations of static typed > languages.Say again: Strongly typed, not statically typed!! Ruby gives you *exactly* what you are asking for. Why not install it and have a look through the examples here: http://www.rubycentral.com/book/tut_classes.html And after that, why not install Rails and give it a go yourself. You''ll learn a lot more by doing. - tim lucas
On Apr 4, 2005 12:44 PM, Tim Lucas <t.lucas-l/qNJNvq70OzaBltdDZI6w@public.gmane.org> wrote:> On 04/04/2005, at 11:27 PM, Hendy Irawan wrote: > > PHP, which started as completely dynamic, is now adding more static > > typing functionality into it. Like "type hinting", which appears on > > PHP 5. Hey!? Isn''t that static typing? Yes, it is, on a dynamically > > typed language. IMHO, dynamic languages should be able to perform most > > of the static typing languages do (including static type checks, like > > PHP''s type hinting) but remove the limitations of static typed > > languages. > > Say again: Strongly typed, not statically typed!!Uh, I think Hendy is talking about static typing. I know nothing about PHP, but "type hinting" sounds like the sort of mess the Python community is going through with optional static typing. I don''t see any reference one way or another to strongly typed. It also sounds like Hendy also wants type inferencing. Check out Haskell or OCaml for good implementations. - Wilkes P.S. I feel guilty for contributing to this thread, :(
On Apr 5, 2005 12:44 AM, Tim Lucas <t.lucas-l/qNJNvq70OzaBltdDZI6w@public.gmane.org> wrote:> Say again: Strongly typed, not statically typed!!okay... okay...! strongly typed! strongly typed! at least you knew what I meant...> And after that, why not install Rails and give it a go yourself. You''ll > learn a lot more by doing.Actually I did... sort of, a few minutes ago. My previous installation wasn''t very successful because of missing zlib.dll while installing rubygems (and then how the hell would I install rails?), downloading the (new) zlib[wapi].dll from the zlib site didn''t solve the problem, actually it caused a crash (sort of segfault) rather than the previous [nice] "zlib.dll not found" dialog box. several moments later, I had to redownload all rails dependencies manually because they''ve changed (note that I, unlike some of you guys, don''t have the luxury of limitless Internet connection all the time, I''m behind a slow, restrictive proxy, that only allows HTTP/1.0 GET/POST requests on port 80 and the URL is even more restricted, duh!) Fired up SciTE: name = gets puts name Hit F5. Then it sort of hangs (on the gets line, I guess). I guess it''s because the output capturing thing or else... I guess it''s because of SciTE''s configuration. Anyways, I''ve got the new shiny 12 MB Ruby installer that I''ve been downloading for the past several hours/days... I''ll look forward to what I can (and cannot) do with it. BTW, with the principle of "least surprise": a = "Ruby" b = a a[0] = "J" puts b # prints "Juby" Does that really follow the "least surprise" principle? Although it''s understandable that Ruby treats everything as objects including strings (C# also has similar treatment), it''ll take some time to getting used to this... errr... unique behavior. (I haven''t tried that on C#, but I suppose that since in C# a string is immutable, any string operation would always generate another string object, hence the above code, if translated to C#, won''t cause any confusion for C#ers). -- Hendy Irawan - http://dev.gauldong.net - GaulDong Developer Center
On Apr 5, 2005 12:57 AM, Wilkes Joiner <wilkesjoiner-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Uh, I think Hendy is talking about static typing. I know nothing > about PHP, but "type hinting" sounds like the sort of mess the Python > community is going through with optional static typing. I don''t see > any reference one way or another to strongly typed.Thanks... but for me it doesn''t really matter though... Maybe (I hope) a more accurate way to describe what I meant would be "a way for the language to let me know if a parameter/variable/etc. isn''t of the type I explicitly told it to be". The "way" can be a warning, notice, an error, or whatever, anything as long as there is a way: irb(main):016:0> a = "5" => "5" irb(main):017:0> b = a + 3 TypeError: cannot convert Fixnum into String from (irb):17:in `+'' from (irb):17 It would be great if I could have specified a as int so it''d fail when I assigned "5" (this "5" can come from arbitrary source, not literally typed as the above). This is much more vital on method parameters. While doing programming on C/C++, sometimes you don''t really have to look on API reference even if you don''t remember all of the API. Even the worst "Intellisense" will still give you parameter types of a function. Sometimes parameter types are more descriptive that the parameter names (ever heard of param1, param2, or a, b?). PHP currently don''t have this to some extent, and PHP5 only provides type hinting on function parameters that are objects (so I can typehint a SomeClass object, but cannot typehint an int, and anyway it doesn''t force type just "hint" it). So does Ruby have "type hinting" or sort of it? All of the examples I looked at just used plain nontyped variables both for parameter passing and variable assignment.> It also sounds like Hendy also wants type inferencing. Check out > Haskell or OCaml for good implementations.Thanks Wilkes, while I''m not sure what "type inferencing" it (and how I would want it?), I''ve ever tried Haskell for several minutes and it looked great for implementing one-liner fibonacci or prime... or any other mathematical tasks easier than most non-declarative programming languages. But I won''t use it for web app dev, at least not for today. It''s a great language, like Ruby and PHP, but I guess not to be compared to, since it''s for a different purpose (? if not, then just add Haskell to the subject of this thread ;-).> - Wilkes > P.S. I feel guilty for contributing to this thread, :(Why? Had I been too annoying? :-( -- Hendy Irawan - http://dev.gauldong.net - GaulDong Developer Center
* Hendy Irawan <gauldong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [0427 14:27]:> Sorry for making this on rails... I guess this should be on ruby-talk > or even on nothing ;-) > > > Keep on reading ;-) You will learn that Ruby is a really dynamic > > language and that you can open up any class whenever you want and do > > the changes you want to. There is no compilation so nothing is bound in > > the compile-time. I didn''t completely understand what you were after, > > tho, so O''m not sure if this answered your question. > While I like dynamic languages (like PHP and Ruby)... I also think > that it''s sometimes dangerous.Have a look round the ruby-talk archives for threads on ''duck typing'' - this has been thrashed about for weeks at a time more than once. -- ''You were doing well until everyone died'' -- God Rasputin :: Jack of All Trades - Master of Nuns
a and b reference the same object. If you modify it, you modify it! Try that it C# or Java with an array referenced by two variables and you''ll get the same result. What is really different here is that a String in Ruby can be viewed as an array. Hendy Irawan wrote:>On Apr 5, 2005 12:44 AM, Tim Lucas <t.lucas-l/qNJNvq70OzaBltdDZI6w@public.gmane.org> wrote: > > >>Say again: Strongly typed, not statically typed!! >> >> >okay... okay...! strongly typed! strongly typed! >at least you knew what I meant... > > > >>And after that, why not install Rails and give it a go yourself. You''ll >>learn a lot more by doing. >> >> >Actually I did... sort of, a few minutes ago. My previous installation >wasn''t very successful because of missing zlib.dll while installing >rubygems (and then how the hell would I install rails?), downloading >the (new) zlib[wapi].dll from the zlib site didn''t solve the problem, >actually it caused a crash (sort of segfault) rather than the previous >[nice] "zlib.dll not found" dialog box. several moments later, I had >to redownload all rails dependencies manually because they''ve changed >(note that I, unlike some of you guys, don''t have the luxury of >limitless Internet connection all the time, I''m behind a slow, >restrictive proxy, that only allows HTTP/1.0 GET/POST requests on port >80 and the URL is even more restricted, duh!) > >Fired up SciTE: >name = gets >puts name > >Hit F5. Then it sort of hangs (on the gets line, I guess). I guess >it''s because the output capturing thing or else... I guess it''s >because of SciTE''s configuration. > >Anyways, I''ve got the new shiny 12 MB Ruby installer that I''ve been >downloading for the past several hours/days... I''ll look forward to >what I can (and cannot) do with it. > >BTW, with the principle of "least surprise": > >a = "Ruby" >b = a >a[0] = "J" >puts b # prints "Juby" > >Does that really follow the "least surprise" principle? Although it''s >understandable that Ruby treats everything as objects including >strings (C# also has similar treatment), it''ll take some time to >getting used to this... errr... unique behavior. (I haven''t tried that >on C#, but I suppose that since in C# a string is immutable, any >string operation would always generate another string object, hence >the above code, if translated to C#, won''t cause any confusion for >C#ers). > > >