I found this very informative posting compares Ruby on Rails to Django. I don''t want to start a flame war but its nice to see where Rails competitors are at. Have a look at magpiebrain.com/archives/2005/08/14/rails_and_django -- Scott F. Walter Scott F. Walter Principal Consultant Vivare, Inc. E: scott.walter-uosFFu51klvQT0dZR+AlfA@public.gmane.org E: scott-APWf0AbNa2kIjDr1QQGPvw@public.gmane.org Visit scottwalter.com <scottwalter.com> --Point. Click. Explore!
> I don''t want to start a flame war but its nice to see where > Rails competitors are at. Have a look at > magpiebrain.com/archives/2005/08/14/rails_and_django<rant> Comparisons are nice, especially for folks who are curious about either frameworks but WTF... how can one say this: "...my comparison is based on several days worth of Rails development and about a weekend''s worth of playing with Django." ...and then write this: "So which is right for you?" Am I missing something here? How can any sane person make a recommendation over fairly complex application frameworks w/o being particularly well-versed in either Ruby or Python and then give a recommendation based on what... 5-7 days worth of playing around with it?! Did this person actually build something with it and run the apps in production? &$#!% bloggers... :-) </rant>
He didn''t give a recommendation, from what I can tell. Instead, he summarized what might be a very important aspect -- a user with decent skills spending a few days getting a first impression of both frameworks. I think it''s a fair and interesting summary of his own first impression. -tj On Aug 16, 2005, at 1:50 PM, Dean Matsueda wrote:>> I don''t want to start a flame war but its nice to see where >> Rails competitors are at. Have a look at >> magpiebrain.com/archives/2005/08/14/rails_and_django >> > > <rant> > Comparisons are nice, especially for folks who are curious about > either > frameworks but WTF... how can one say this: > > "...my comparison is based on several days worth of Rails development > and about a weekend''s worth of playing with Django." > > ...and then write this: "So which is right for you?" > > Am I missing something here? How can any sane person make a > recommendation over fairly complex application frameworks w/o being > particularly well-versed in either Ruby or Python and then give a > recommendation based on what... 5-7 days worth of playing around with > it?! Did this person actually build something with it and run the > apps > in production? > > &$#!% bloggers... :-) > </rant> > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > lists.rubyonrails.org/mailman/listinfo/rails >
> He didn''t give a recommendation, from what I can tell.I read this to be a recommendation: " If you are developing a simple (in a domain model sense) application where you want to use Ajax to deliver a great UI, Rails is probably for you. If however you want to develop an entire site with different types of applications within it - then Django''s plugable applications and general approach might be what you''re after. "> Instead, he summarized what might be a very important aspect > -- a user with decent skills spending a few days getting a > first impression of both frameworks.Relating first impressions is one thing, but when your closing sub-heading is: "So which framework is right for you?" -- that''s an entirely different thing.> I think it''s a fair and interesting summary of his own first > impression.I agree that''s it''s an interesting read but I don''t agree that it''s fair to give a suggestion on which framework to use, depending on your application''s scope, and not having actually built a single app in production. But that''s just my take on the article.
He was open about the time he''d spent with each. I disagree that he gave any recommendations, instead saying what might be appropriate for different approaches. Asking a question as a sub-head is in no way a recommendation, either -- it''s a question. There is absolutely nothing scandalous in that write-up. You''re making way too much of it and reading far too much into it. I imagine you wouldn''t be saying this if the article had been unquestionably and unconditionally glowing in regards to RoR. On Aug 16, 2005, at 2:06 PM, Dean Matsueda wrote:> > >> He didn''t give a recommendation, from what I can tell. >> > > I read this to be a recommendation: > " > If you are developing a simple (in a domain model sense) application > where you want to use Ajax to deliver a great UI, Rails is probably > for > you. If however you want to develop an entire site with different > types > of applications within it - then Django''s plugable applications and > general approach might be what you''re after. > " > > >> Instead, he summarized what might be a very important aspect >> -- a user with decent skills spending a few days getting a >> first impression of both frameworks. >> > > Relating first impressions is one thing, but when your closing > sub-heading is: "So which framework is right for you?" -- that''s an > entirely different thing. > > >> I think it''s a fair and interesting summary of his own first >> impression. >> > > I agree that''s it''s an interesting read but I don''t agree that it''s > fair > to give a suggestion on which framework to use, depending on your > application''s scope, and not having actually built a single app in > production. > > But that''s just my take on the article. > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > lists.rubyonrails.org/mailman/listinfo/rails >
> There is absolutely nothing scandalous in that write-up. > You''re making way too much of it and reading far too much > into it.I''ll accept that. Again, that was my take on the article and if you have no issue with it, I respect that.> I imagine you wouldn''t be saying this if the article > had been unquestionably and unconditionally glowing in regards to RoR.Well, now perhaps we''re both making poor assumptions -- me about the author and you about me. :)
Hey guys. I toyed around with Django last night and did a quick writeup from the perspective of someone already using Rails. You can check it out at jvoorhis.com/articles/2005/08/16/first-impressions-of-django Jeremy Voorhis On 8/16/05, Toby Boudreaux <rails-lb8SQxIZKShBDgjK7y7TUQ@public.gmane.org> wrote:> He didn''t give a recommendation, from what I can tell. > > Instead, he summarized what might be a very important aspect -- a > user with decent skills spending a few days getting a first > impression of both frameworks. > > I think it''s a fair and interesting summary of his own first impression. > > -tj > > On Aug 16, 2005, at 1:50 PM, Dean Matsueda wrote: > > >> I don''t want to start a flame war but its nice to see where > >> Rails competitors are at. Have a look at > >> magpiebrain.com/archives/2005/08/14/rails_and_django > >> > > > > <rant> > > Comparisons are nice, especially for folks who are curious about > > either > > frameworks but WTF... how can one say this: > > > > "...my comparison is based on several days worth of Rails development > > and about a weekend''s worth of playing with Django." > > > > ...and then write this: "So which is right for you?" > > > > Am I missing something here? How can any sane person make a > > recommendation over fairly complex application frameworks w/o being > > particularly well-versed in either Ruby or Python and then give a > > recommendation based on what... 5-7 days worth of playing around with > > it?! Did this person actually build something with it and run the > > apps > > in production? > > > > &$#!% bloggers... :-) > > </rant> > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > lists.rubyonrails.org/mailman/listinfo/rails > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > lists.rubyonrails.org/mailman/listinfo/rails >
* Jeremy Voorhis (jvoorhis-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org) [050816 14:45]:> Hey guys. > > I toyed around with Django last night and did a quick writeup from the > perspective of someone already using Rails. > > You can check it out at > jvoorhis.com/articles/2005/08/16/first-impressions-of-django > > Jeremy VoorhisJeremy, Thanks for another thoughtful comparison. Something occurs to me after reading this that has to do with whether it''s "better" to use the database as a starting point when writing/generating/adapting models, or to use model code to generate a database schema, or even to use an intermediary (think Hibernate mapping file) as a starting point for both. Having seen up close how all three approaches work, I''ve settled into the Rails method of working from the schema and having my models be dynamically updated (mostly) as my preferred approach, but was never able to really put a finger on exactly *why* I felt this way. Granted, having used Hibernate (and Middlegen, having also looked at XDoclet) and watching the shotgun code smell lacerate an application when anything at or below the ORM level changes to even a minor degree, I''m not a proponent of the Hibernate approach... That does leave the "gather information from the database" and "express all information in the model" approaches for me to consider. Looking at what Django does versus what Rails does it crystallized in my mind why I feel the way I do. Simply put, there are two important factors to consider: 1. Deviations expressible in a clarification language. 2. Maintainability. When using an object-relational mapping framework, in my experience, there is a general "clarification language" which is used to map the relational database constructs to or from the object world constructs. Take the term "language" here loosely, as by this I mean the union of the lines written (SQL, OO, XML, etc.) to capture the mapping semantics between the database and the model. The clarification language is responsible for disambiguating all ambiguities in the ORM mapping, and for naming all functionality encapsulated in the mapping. The simplicity, applicability, and generality of the clarification language determines how little clarification code one must write to effect the mapping. In the bulk of cases (say 85%), given a decent clarification language, the clarifications to be written are small, as the object and/or tables can readily capture the most common constructs. This also explains why "Convention over Configuration" can eliminate masses of clarification code (whether OO, SQL, or XML) -- knowing the common usage patterns allows the clarification parser (if you will) to embed knowledge in itself, meaning that only deviations from the common usage need be noted. In the remaining cases (which, while fewer, are present in probably all non-trivial applications) the clarification language must describe complex details of arbitrary complexity to complete the O/R mapping. If we view the clarification parser''s encoding of common usage knowledge as a compression system it''s clear that there will always be incompressible usage patterns -- that is, there will always be complex behaviors which require more clarification code to express properly. I (and many others) consider frameworks good which ensure that clarification code grows large only when the usage patterns are rare. (By this metric I contend it is obvious that Hibernate, e.g., is a horrible ORM framework, at least along the clarification language dimension; I also happen to think ActiveRecord excels here). Now, here''s where things get interesting (damn, I''m still on factor 1 -- bear with me). SQL is the lingua franca of relational databases (let''s pretend for the moment that there really is just *one* SQL out there). SQL can encode very sophisticated constructs -- arbitrary table structures, arbitrary foreign key constraints, arbitrary data typing, indexing and uniqueness constraints, as well as complex beasts such as triggers, rules, views, temp tables, stored procedures, etc. Once we grant vendor quirks and SQL dialects we also have to contend with materialized views, various stored procedure languages, DBA-level considerations (tablespaces, partitions, table caches, aggregate types, etc.). SQL is a very complex beast. Talk to a DBA and you will learn that much of what they do is applying new rules (using SQL constructs, many DBA-specific) to the DDL schemae to coax performance, security, and availability from the database. Note that these are database-level considerations, which are necessary for good performance, but which provide very little of conceptual value to the OO layer sitting above them. I contend that the fan-out from an OO specification of database functionality to the database constructs necessary to construct a useful database is large. So large in fact that once the simplest database constructs are left behind for anything non-trivial the size of the non-SQL clarification language needed to express the variability of SQL begins to rapidly approach that of SQL. In fact, the complexity of a primarily OO clarification language (since that''s what we''re really talking about here) will almost certainly exceed the complexity of SQL since the declarative SQL language(s) suffer an impedance mismatch with the OO languages one might wish to use for clarification. (I believe this is why DHH''s aversion to mimicry of SQL inside Rails struck such a chord with me, and why I think he is correct to limit the scope of the Migrations functionality for Rails. It is useful, yes, but it cannot ever be a succint and powerful clarification language.) On the other hand, when a database is set up, tuned, optimized, etc., the information of relevance to the OO layer above it can readily be queried in a fairly standard way. The clarification that is necessary at the OO level addresses primarily OO constructs (and those DB constructs which may be useful to the OO layer but difficult to infer from the variety of databases out there -- consider foreign key detection in vanilla MySQL tables vs. Oracle tables). What exceptions there are can be specified succinctly in the language of the OO layer, using the many reuse techniques available (inheritance, domain-specific languages, mix-ins, encapsulation, instance methods, AOP, etc.). SQL (standard or no) provides little comparable to OO use techniques, making it a poor clarification language. In short, database concerns, of high importance at the database level, make little sense at the OO level. Specifying them is necessary once we leave the realm of trivial applications, but their specification at the OO level not only explodes the complexity of the clarification language, but fundamentally MAKES NO SENSE at the OO level. Considering the other factor, maintainability, is much more straightforward. We know that there will be change going forward. We don''t typically know what will change, but change will come. If we specify our database information in a primarily OO clarification language, OO code changes are merely OO code changes, but database changes are very expensive. This is due to the problems stated above (SQL->OO impedance mismatch, SQL/DBA complexity issues for performance/etc.) as well as the lack of powerful reuse constructs in the database layer: could we simply apply inheritance or aspects in the database we could mitigate our changes (though note that we would still be writing database code, using OO techniques at that!). The closer our clarification language comes to the complexity of SQL the more coupling we will end up having across the application to the things we need to do in the database. Conversely, if the database layer is built and the OO layer sits on top of it, then OO code changes are still OO code changes, while database level changes related to non-OO concerns (performance, etc.) have no impact on the OO layer, and database changes that are exposed to the OO layer can be managed using all the customary OO-level reuse constructs. If your language is dynamic enough (e.g., Ruby) and your clarification language takes advantage of that dynamicity (e.g., the DSL in ActiveRecord) then even significant database changes don''t result in major OO-layer changes. In short, if you want to reduce clarification footprint (and hence reduce coupling, bugs, promote maintainability, etc.) then you are better off maintaining your database with database tools, and letting your OO layer ask the database how it should behave. [ also posted at: rickbradley.com/chron/20050817 ] Rick -- rickbradley.com MUPRN: 941 | have babies? Because random email haiku | their husbands have crystal balls | and hollow-weenies.
Heya :) This was a GREAT post... I''ll comment (briefly) below...> -----Original Message----- > From: rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org [mailto:rails- > bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] On Behalf Of Rick Bradley > Sent: Wednesday, August 17, 2005 11:27 AM > To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > Subject: [Rails] O<->RM (was "Re: Comparing Ruby on Rails to Django") >[ lots of good stuff snipped ]> In short, if you want to reduce clarification footprint (and hence > reduce coupling, bugs, promote maintainability, etc.) then you are > better off maintaining your database with database tools, and letting > your OO layer ask the database how it should behave.I do see where your coming from on this... essentially the points you make are: * Database design and optimization is a complex and feature full beast for a reason * Building all the smarts needed to do that stuff right in a database generation tool is a big problem * Considering those points, it makes sense to hand tune your DB, and let the object frame work query it So far. I agree. However, when I follow those thoughts, suddenly I realize why I am reluctant to commit to Rails for non trivial projects. * Rails is fundamentally ignorant of all the stuff you mentioned. IT makes no use and as far as I know ignores triggers, stored procedures, compound keys and views. In short, your well thought out problem with building the smarts into DB generation is ALSO a discussion of why automatically inferring the model from a query of the DB is >also< difficult and complex. Now, in trivial cases this doesn''t matter and both Django and Rails will do well. But in a complex case a flexible, programmer edited "map" between object model and DB structure will be essential (as in Hibernate). Soulhuntre ---------- girl2.com - my girls the-estate.com - my legacy wiki.thegreybook.com - my project weblog.soulhuntre.com - my thoughts