Slashdot Mirror
What's the Secret Sauce in Ruby on Rails?
An anonymous reader writes "Ruby on Rails seems to be a lightning rod for controversy. At the heart of most of the controversy lies amazing productivity claims. Rails isn't a better hammer; it's a different kind of tool. This article explores the compromises and design decisions that went into making Rails so productive within its niche."
I've not seen a lot of RoR, but what I have seen reminded me a lot of ASP and JSP with lots of scriplets. Which I thought was bad form (code mixed with html). Have I just been looking at bad (or simple) examples? The article seems to hint that RoR does support MVC.
Eh, yeah. Front page is always green. Each section has a color (this is blue). Stories that are 'under construction' and can't be replied to are red.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
I've only used Rails a bit, but I've used Ruby a lot. It's by far the most flexible language I've ever used. It allows programmers to modify the most fundmental aspects of the language. Some argue this is a bad thing, and it may be. However, having the freedom to do that is very empowering. Don't get me wrong, other OO scripting languages are great too... Python for example. And, they share many concepts with Ruby. The things that make Ruby stand out (to me) are the ease of modification and syntax flexibility. IMO, Ruby is a wonderul toolkit that will allow one to build most anything, even more specialized tools like Rails.
What about the fact that Rails is licenced under the "MIT License" while Java is (semi-)propietary?
Nice summary. Too bad it's stolen verbatim from TFA.
I bet noone would realize, since nobody ever reads TFA. It's a sad world, when people steal summaries from the articles they link to.
The big benefit is that it's multiparadigm. It draws the best from the OO world of Smalltalk, while also offering very solid functional features. These are the traits of languages that are suitable for high-quality, fast-turnaround software development.
We can see Ruby applications that are comparable functionality-wise (and portability-wise) to C++ programs, but written in a 1/10 of the time with 1/20 the number of lines of code. That's why Ruby-based solutions are effective and popular.
As far as I've seen, there isn't that much actually new in RoR. But it's obvious that someone has had a great idea how a whole bunch of known stuff should fit together, in a way that encourages best practices (like a lot of testing, and code reuse). It has near perfect design.
The language Ruby wasn't new; Active Record wasn't new, nor was the idea, but it fits with Ruby really well. MVC was old, but the tiny bits of boilerplate needed makes it look like magic now and then. Everybody knows testing is essential, but I hadn't seen it integrated into a web framework so well before. The idea of "sensible defaults" can't have been new, but the switch from reams of XML (in Java web programming) to near invisible config is great. The object-oriented Javascript libraries it uses weren't new, nor are template languages, but the way in which they're added together is pretty seamless. Et cetera.
No wonder every web programming language community out there is rushing to put together it's own version of Rails... but the libraries don't always fit together as seamlessly. I think that Hansson's main achievements are recognizing that all the known best practices can be put together really well, and that Ruby and its libraries were a great fit for that.
I believe posters are recognized by their sig. So I made one.
Python programmers can get the same kind of experience without learning a new languge with Django. Yes there are differences to RoR but the productivity gains are there. Django gives you database/object linkage, templates, views and all that, and a free and very very usable database interface generated from your model spec.
Oh, of course there's a big backlash against web frameworks these days isn't there?
I tried Rails for a bit. Found it nice. I found the language Ruby more interesting than the Rails framework. Rails code I looked at looked very much like JSP/ASP/PHP gone bad. All sorts of code in HTML land. Then their was the compilation oddities.
I still believe that Java and PHP are better though. They also perform a hell of a lot faster and scale much better. For example, a friend was creating a site with Rails and wanted to put in integrated search. Several people attempted creating something like Apache's Lucene in Ruby but found that the Ruby's poor performance made the search incredible slow (you could time out before it finished getting your search results).
What I would think would be really cool is a Lua plugin for Apache. That would be sweet.
Actually, it can be said that the MIT license is in fact a very conservative license. It truly harkens back to the days of the Founding Fathers, when freedom was the utmost concern.
.NET), instead letting people focus on developing software.
It places very minimal restrictions upon users, while promoting free use of the software. I must repeat, with the MIT license, the emphasis is placed on freedom and liberty. It avoids the corporate shenaniganery we have come to associate with corporate software (such as Java, or
You don't need to be a lawyer to understand its terms. They're written so eloquently and comprehensibly that it is nearly impossible to not understand its terms.
In short, the MIT license is all about essential freedom, the kind America was initially built upon.
Porn, and the consequences thereof, is the 'secret sauce' of Ruby on Rails.
Those crazy open source programmers.
Would you kindly mod me +1 insightful?
I thought Ruby on Rails sounded cool, until I saw that it automatically pluralizes person to people. any computer language that does that, in my opinion is just to unpredictable to use.
Intron: the portion of DNA which expresses nothing useful.
So what? A summary should summarize the article (duh!). If the article itself does a good job at that, why reinvent the wheel?
Amen to that. I think on-the-fly reinterpration of code is the biggest thing that Rails (or just about any other interpreted scripting language) provides that is a severe handicap for Java. I configure tomcat on my dev system to continuously rescan bytecode files for changes, but what is really needed is an easy, standardized way to make minor modifications to classes on production appserver without having to bring the whole thing down. I know some Java appservers support things like this, but I said "easy and standardized" meaning it can be done via an ant task that figures out exactly what classes have been changed, then notifies the appserver of this so that they get reloaded efficiently.
I think the introduction of annotations with Java 1.5 also does a great job of cutting back on the amount of configuration files necessary. In addition, they leverage Java's biggest advantage over competing languages*- typesafety.
*yes, C# has typesafety as well, but that's basically the same language.
Eclipse's debugger does pretty much all I need, although things do get difficult when AOP or other bytecode modification is being used.
pi = 3.141592653589793helpimtrappedinauniversefactory7
(Django has been in use on high-volume production websites longer than Rails has existed, incidentally -- something which might be worthwhile when bringing it up in this kind of context).
After evaluating Rails and Django, my company ended up going with TurboGears for some of our toolage (our main product is a Java Servlet-based application, and that's not changing). The reasons:
The opposing reasons:
Anyhow -- Rails is nifty. Django is nifty. TurboGears is nifty. Quite likely all three of them have a place; I'd just like to urge people not to get so caught up in the hype over Rails that they forego evaluating other options.
Then it's been a sad world for a very long time.
Why not fork?
Could it be that case that I have not found it yet but it exixts? Point me to the URL.
thar RoR is using Ruby, a programming language that:
a. is fully object-oriented (not a hybrid like c++ or java). For example, you can have "hello".length() or 5.inspect() which means easier debugging and easy extensibility when you can ("can" != "should") add methods to any class at runtime.
b. supports mixins (flexibility of multiple inheritance without the complexity)
c. supports blocks and closures (if you've never used a language that supports blocks and closures, then you don't know what you're missing. I've coded professionally for more than a decade using assembly (intel & motorola chips), c, c++, cobol (ugh), delphi, java, python, etc. and when I discovered how to use blocks and closures in Ruby last year, I almost fainted because it makes coding so much more productive)
d. practical for both one-liners like perl and large/complex applications with a GUI interface
When I discovered Ruby last year and tried RoR for the first time this month (stayed away due to dislike of hype), it felt like I was previously chopping trees with a plastic spoon all this time instead of using a chainsaw--Ruby succeeds because it takes so many great features from other languages and combines them in a cohesive manner. RoR succeeds because it uses Ruby and provides a framework that encourages good coding (by providing MVC for example).
But there is a price for all of this. Speed. In order to provide so many productivity features, the performance will never reach that of c, c++, and many other languages. And I don't know when/if a compiler will ever be practical or available (like gcj for java producing huge binaries to print hello world).
Other drawbacks include poor release management (remember the ruby 1.8.3 fiasco) and poor support for wxWidgets (Ruby has better support for Fox toolkkit, but I use wxWidgets with C++ so this isn't ideal for me).
Anyway, I hope another new language comes along that'll blow away Ruby and another new web framework comes out that'll blow away RoR.
Blind loyalty to language/os/software/etc is for idiots who are afraid of change. Be aggressively disloyal to your products and force their developers to improve or fade away.
There are obvious borrowings from Smalltalk, LISP, Python, and Perl. There's a lot to like about Ruby's semantics; I just can't get past the syntax (which, in my opinion, borrowed quite a bit too much from Perl).
On Linux you just need to install ruby1.8 then download the gems package from online, install it, then do "gem install --remote rails". After that it's easy to keep things up-to-date and install more Ruby add-ons. I've never had any trouble.
Umm, what are you running? Everything installs via apt-get without a hitch on my Debian Sarge servers and similarly with urpmi on my Mandriva 2006 desktop. Do you have a very strange configuration, or a system that doesn't auto-meet dependencies? If you're on Debian or Mandriva feel free to email me and I'll try to help you out.
U.S. War Crimes blog. Email for free Mandriva support.
It really is tiresome to see people constantly ask "what's the special sauce" when in many instances it is clearly "nothing".
Sometimes good people use good methods to build well conceived applications that work precisely as their audience expects they should. Because these well-formed applications do not fail randomly, scale well and are easily supported marketing and business types presume that there absolutely must be something patentable in the mix.
One of the reasons I loath the term "Web 2.0" is because people presume there is some new wave of innovation occuring in application development when every Slashdot reader know's this isn't true.
Technologies mature, standards mature and hopefully people mature. The result is better software, not an abundance of new and novel special sauces.
It's par for the course here at slashdot. If it's not a clean lift from TFA, then chances are it's going to be incomprehensible. Writing skills on slashdot are that bad.
It's not offtopic, dumbass. It's orthogonal.
Be positive!
A slashdot editor that read TFA: priceless!
I interviewed the article's author, Bruce Tate, for the Ruby on Rails Podcast. He's a brilliant thinker and has taken bold steps to embrace Ruby inspite of his fame in the Java community.
Rails Podcast with Bruce Tate
It is Rails which does the pluralisation, this is not an inbuild Ruby feature! ;-)
Ruby istelf, being japanese, doesn't care about plural!
[Everyone gasps.]
Hermes: No!
Fry: Ah, so the real gift Spargle gave you was confidence. The confidence to be your best.
Farnsworth: Yes, ordinary water.... Laced with nothing more than a few spoonfuls of LSD.
Shop as usual. And avoid panic buying.
1. It's easy to build hash tables in Ruby- At any level of a hierarchical structure like HTML you can have an arbitrary number of child elements or attributes, all identified by a type tag. This happens to map perfectly onto ruby's hash tables, so to create an HTML link you can say:
:id => 'add user', :class => 'shiny button', :action => 'add_user'
link_to
2. Lack of superfluous syntax It is very elegant how every programming idea in ruby seems to require only a single syntax concept at a single location to put it into practice- For instance, if you need a class member variable, you just create a name starting with "@" (like @firstname) without having to declare the variable in a separate location in the file. This is taken advantage of very cleanly by the ROR system, so that programming web pages has a very "WYSIWYG-ish" feel- Every concept in you web site has a clear, understandable equivalent embodiment in the Ruby code
3. Dynamically detects missing methods- I don't know exactly how it works, but ruby classes are able to know when a method on an object is called at runtime that doesn't exist- So you can essentially enhance the functions an object supports at runtime... this allows Ruby toolkits, such as Rails, to essentially shoehorn their own custom language ideas into ruby (not quite at the level of Lisp's "defmacro", of course)
4. It was scalable from day one- Right from the start, ROR was designed to scale- In fact, it was already part of a commercial app before it even existed as a stand-alone product. This means it already overcame the greatest hurdle of any web-development framework from day one- Most Scheme/Lisp frameworks, for instance, still haven't achieved the level of scalabilty that ROR had right from the start.
5. It has a whiff of that mystical Scandinavian software guru-ism in it that make for seriously powerful software Creating a comprehensive web development system is a messy undertaking- ROR is the product of an obsessive Northern European fanaticism that somehow manages to combine an incredible pragmaticism and also manages to handle all of the many ways that web frameworks fail with the utmost of effectiveness. It isn't brilliant because it makes it easier to do complex things, as other frameworks try to- It's brilliant because it makes things that are already easy so much easier that all the complexity, though still complex, floats to the surface of your code and isn't obscured by the many "easy" parts.
6. No pre-processor Many of the more advanced web-frameworks, as in JAVA, require pre-processing of HTML templates with embedded JAVA- The dynamicity of Ruby makes this step hidden- Explicit preprocessors are practically and cognitively difficult for programmers to deal with.
These, I think, are some of the non-obvious reasons that give ROR the edge over other web frameworks.
Nice comment. Too bad its stolen verbatim from the article AND the summary.
There's controversy about Rails? Since when? I've never heard anyone say anything bad about it -- but maybe I'm too skewed in what I read. Maybe I'm listening to the programming equivalent of Fox News. =:-O
I, for one, welcome our new Antichrist overlord.
So, for now, it's Java or Python, and associated frameworks for me. But not RoR.
1) Just like in any language, whether a programmer actually follows the MVC structure is mostly up to the programmer. I mean, I suppose you could specify a templating language which is less powerful in order to more strictly enforce things, but that takes language development time, programmer memory to remember two sets of syntax/conventions, and might be an unhelpful restriction for RAD/prototyping, which Rails is often used for. But rails generates models, controllers, and views, so you can hardly blame Rails for people who put app logic in their views. Or did you just think it was app logic because it was written in Ruby and you are used to single-purpose templating languages?
2) Well-written Ruby which uses the C database bindings just isn't slow. My web app, Kiko, has been Slashdotted 3 times now, with up to 20,000 log ons an hour on a single processor box with 512mb of RAM -- and not only didn't go down, it never even got slow for our regular users. Erins.de gets millions of hits per day on just a couple of boxes. It has to be set up properly to take that kind of abuse, but it most definitely does. As for search, there's just no reason to implement full-text search in the scripting language. MySQL has full text search, PostgreSQL has tsearch2 (a set of C libraries), and presumably other mature databases have their own solutions. All Ruby/Rails has to do is call the C code and format the results. This is a textbook case of using the right library for the right job--if you're doing image processing in Python, do you write your own image processor or do you call ImageMagick just like you would in Rails? Seems to me that full text search on a database is the same kind of well-defined problem set, and should be treated the same way.
U.S. War Crimes blog. Email for free Mandriva support.
A reasonably up-to-date version of Rails (1.1.0) is directly installable in Debian testing and unstable; just use "apt-get install rails".
If you're using Debian stable or prefer to use Rubygems to get the most up-to-date stuff, add this to your sources.list:
deb http://www.sgtpepper.net/hyspro/deb unstable/
deb-src http://www.sgtpepper.net/hyspro/deb unstable/
Then "apt-get install rubygems".
Then "gem install rails".
Then set GEM_HOME to "/var/lib/gems/1.8" and add "/var/lib/gems/1.8/bin" to your path.
Then do "rails my_new_project" and have fun.
I have started a new web project and looked at RoR. Having done an app with Tapestry/Spring/Hibernate, I was sick of all the work one has to do to bring up a bunch of views in a browser and then persist results. I love RoR and Ruby for all the reasons mentioned in TFA. Note - I don't like the pluralisation default, but one can easily turn it off by setting the following in config/environment.rb:
. tss?l=RailsHibernate). The Data Mapper Pattern is almost certainly more efficient when implemented well (as Hibernate does). The coolest thing about Hibernate is that it is much more efficient than I am without a big effort on the persistence side, and I am concerned that Active Record will not be nearly as good. However, what are the odds that someone (or some group of people) will work on implementing a persistence solution within Rails that uses the Data Mapper Pattern? Pretty good, I would say. Once again, it probably won't be as good as Gavin King's work, but it will be "good enough". And if someone else does not do it, maybe I will start the project.
# Include your application configuration below
ActiveRecord::Base.pluralize_table_names = false
There were two scalability concerns I had about RoR:
(1) Ruby is interpreted and 'slow' - however, the JRuby team (http://headius.blogspot.com/) is working on running Ruby within a JVM (currently interpreted, but they are starting on a compiler). When they get to 1.0, the compiler won't be as good as Sun's, but it will probably be "good enough"
(2) RoR uses the Active Record Pattern and Hibernate uses the Data Mapper Pattern (http://www.theserverside.com/tt/articles/article
Given the above and the speed with which one can develop in RoR, the choice was obvious, to go with Ruby and Rails.
Reading TFA, I wouldn't use words like zealotry or fanaticism to describe either the article or the attitude of the Java programmers it seems to be aimed at. What I do see, though, is a terribly narrow-minded view of programming, and an obvious lack of broader experience. Let's take a few choice quotes.
From the About this series box, before we even get to the article itself:
Surely most of us would agree that any programmer is well-served by familiarity with a variety of languages, programming styles and tools, and by choosing the most appropriate for any given job. Which, despite the absurd claim above, has never been Java in all, or even most, cases.
From the "Hype and skepticism" section:
No-one who's looked into a wide range of programming languages (and I don't mean Java, C++, C# and Visual Basic.Net) would find those claims particularly surprising or implausible. The functional programming world has been outclassing workhorse industrial languages like C++, Delphi, Java and co. in productivity by an order of magnitude for a long time, at least for the kind of application that lends itself to a functional style. So-called scripting languages, which cut away much of the boilerplate baggage required by the workhorses, have proven to be a much more efficient tool for many kinds of project as well, often due to relatively simple features like supporting common data structures as first-class entities.
Moving on to the Rails philosophies, we see things like "Don't Repeat Yourself" being highlighted as "core opinions pervasive within Rails". Surely abstracting common code and data structures into reusable units is a basic principle of sound programming in pretty much any language?
Then we get to the "niche" for Rails:
I'd guess that's wildly optimistic, though it's certainly a common conceit among Java programmers IME. Not everything in the programming world is web-enabled, and much of it has no interest in becoming so either. Why would a high-performance scientific application, a CAD/CAM/CAE package, a FPS or the firmware in your washing machine care about database-backing and Web-enabling?
All-in-all, this seems to be an article aimed at die-hard Java programmers with little experience of the wider programming world. Its arguments support wider exposure to programming and good general programming principles, though it forgets to mention that Ruby on Rails is far from the only way of achieving those ends.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
exactly, this improves the amount of the article that most /.'ers will read by 100%
So which "cheap imitation" camp is Forth in then with its dictionary?
"I put the blame for this squarely on the shoulders of modern computer science degree schemes."
Guess all those self-educated CS'ers are immune.
"People graduate thinking languages like Java and C are the state of the art, and then go on to re-invent concepts from the '70s believing that they are novel."
And yet Prolog is still in the closet.
InstantRails is your friend:
http://instantrails.rubyforge.org/wiki/wiki.pl
Reality is the ultimate Rorschach.
As a programmer with a couple decades of experience, and having used a wide variety of languages, I don't see why people complain about VB. Can you give me some examples of why you think it's retarded?
There was no need to add that special case because in Perl, "0.0" does the exact same thing as "0 but true". Perl has a lot of such useless special cases - for instance the string "ignore" will not generate a warning in void context.
But Ruby, unlike Perl, has real booleans. So 0 is true. And "" is true. Thereby avoiding a very common source of Perl bugs. (Really, how many people religiously check defined in Perl? Not enough, else the need for "err" and "//" would have been apparent a long time ago.)
RoR is a good OS product that helps people solve problems that really bug them. It doesn't - contrary to lot's of other OSS projects - have a website that looks and works like crap . It's lead developers actually have social skills (and running businesses) and can talk coherently in a way that normal people actually understand them. They are tight with the blogging community and are smart enough not to be arrogant and thus convince even the most fanatic Java people to check out their toy. They started the whole webcast thing and built RoR for an actual real life business project they wanted to do (www.basecamphq.com) before going OSS.
Technology wise there is not that much new. Zope is still lightyears ahead of everything else (including RoR) but only last year did their website stop looking and acting like a total pile of doo-doo. Yet still Zope.org's Navigation is somewhat '99ish and much more intimidating and overwelming than the friendly and straightforward RoR Site.
Then there's Django. Which is very neat, partly even better than RoR (and friends with the RoR project), but went OSS a little later than RoR and thus needs to catch up on awareness a little. Symfony is PHPs late answer to the RoR induced MVC frenzy and still to new to gain awareness momentum. CakePHP and P4A seem ok but don't have the marketing stance to be of any significance anytime in the future. They're both so nineties it hurts and thus will wither and die.
Bottom line: RoR are a OSS project that isn't just good at coding or using exotic technologies, they actually have the skill to market it aswell. And they were the first in the framework camp. It's that simple.
We suffer more in our imagination than in reality. - Seneca
Sweet land of liberty, of thee I sing...
(weeps)
So the source should be attributed and the text placed in quotes. Out in the real world, stealing someone's work and pretending it's your own can be illegal and also make people look down on you
Only Access has consistantly worse apps. All languages have some stinkers, but there is something to be said for learning curves keeping PHBs from blowing their own peckers off.
That being said you can be very productive in VB if you're not a retard.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
Like it was pointed out in here other frameworks are older and more advanced then RoR.
Still RoR managed to break the mindset barrier of a typical US java programmer - and the sheer amount of people with such profile is so overwhelming that, in the end of the day, that's all that counts.
Folks ignored everything beyond J2EE for a long time. Think Zope history for example.
RoR happened at the moment java burden factor just reached some kind of a critical mass point.
The enthusiasm for RoR specifically surely is due to good marketing but I suspect typical American Japan-envy factor was as important.
Seriously, once you know the naming conventions, directory layouts, etc., it is very easy to find your way around a Rails project.
If you are working on a controller and want to mentally switch gears an modify the coresponding view, there is no doubt where to go (that is, which rhtml file to edit).
I find myself thinking about application problems and not framework problems. I am a little prejudiced right now: I am just finishing up the book "Ruby Quickly" for Manning (http://www.manning.com/watson/). I hate to admit it, but I am simply tired of developing in Java. Ruby is fun, and productive. I started a new AI project a few weeks ago, and I started all of the prototyping in Ruby. For one part of the system, Ruby is too slow, and I am replacing this bit of code with stuff written in Common Lisp. Still, for a large part of the system, Ruby is a great fit.
Can anyone give me a good, preferrably online, tutorial/introduction to RoR?
:-)
Being thorough isn't really a disadvantage; I'm not looking for a sloppy "learn RoR in 2 days" intro.
I thoroughly enjoyed e.g Bruce Eckel's free online books for C++ and Java, as a hint of what I'd be looking for.
Is there anything good out there online?
Beware: In C++, your friends can see your privates!
Since we're being pedantic: it wasn't a politics "discussion" until you joined in. :-P
all that stuff is lifted directly from Smalltalk
Well now I know RoR is bull because any article that is 90% about trying to debunk hype and talk about philosophy must be hiding something. You can easly find 10 Java programmers but if you're an expert in something that offers 10 to 1 productivity then you're going to be popular. My guess this is just another guy trying to drum up some business for himself. Not that there's anything wrong with that but you have to technical content to backup your claims. Let's see that "three lines of code to render a table".
Actually, Java developers ARE concerned about opening Java up. Here are some recent news articles from Googling "open java":
1 955870,00.aspu n-needs-turnaround-plan-that-/2006/04/26/1611586.h tm
http://www.thechannelinsider.com/article2/0,1895,
http://opensource.sys-con.com/read/216731.htm
http://www.tmcnet.com/usubmit/-analysis-new-ceo-s
http://www.technewsworld.com/story/50449.html
To all of which, Gosling has responded, "Nope", much to the chagrin of Java developers. If you haven't heard them, it's because you've been too busy complaining on Slashdot about Slashdotters using Slashdot to Slashdot.
This article is hosted at IBM, and IBM invests heavily in Java (SWT, Eclipse, etc.) So this article should be taken with a grain of salt. It's like Microsoft comparing .NET with Java (remember Microsoft's ".NET is X times faster than Java" statements?)
However it's nice to see that IBM knows that Ruby exists and knows its strong points - so that they may borrow the good stuff into Java.
If catwalk (TG's automatic DB front-end) had been working when I was exploring web frameworks a few months ago I probably would have gone with TurboGears.
The docs say its 'slated for 0.9'...
Ruby on Rails - the Bush administration of web frameworks.
This is what they do. They spam their marketing materials on one forum after another, glossing over finer points like the lack of Unicode and threading support, along with quite a number of tools professionals need in their development, and then use their meat or sock puppet accounts to downmod messages they don't want to reach their target marketing audience.
After using Ruby for several years, for general purpose scripting, and various other web development frameworks in Java/Perl/PHP/C#, etc... It seems clear to me that ROR really isn't another 'kind' of tool at all. It's simply a well desgined web framework, expressing some of the philosophy of the Ruby programming language.
The programming techniques ROR promotes aren't new, they're not crazy, or magical. They're not in the least 'different'.
The article lists:
1.) Seamless integration
2.) Convention 'over' configuration.
3.) Low Repetition.
4.) Immediate Feedback.
What web-framework would not want the framework they're using to work well with the underlying language? And Convention over configuration doesn't mean a lack of configuration, it simply means that intelligent defaults are generated. It makes common things easy, and uncommon things possible. And DRY is a main goal of software engineering, of design patterns, of object oriented programming--- which all have been in practice for over twenty years.
In this article, the author points out that it's based on an underlying MVC architecture. This isn't anything new for any other web development framework, for instance Struts. And even outside of an environment which starts with this design by default, software engineers are wise to follow design patterns. It seems he views the philosophy of convention over configuration as somehow making ROR inflexable, and incapable of solving some imagined wide range of web-development programs. Sure, 50% of applications are web-based and database backed--- but ROR programs don't have to be database backed (See Rails Recipes, page 57). And, I figure if a person is using a web-development framework, the lack of configurability in the expression of the application as being web-based is acceptable (although I suppose it's possible to replace the view portion of the application as well).
It's clear, from some messages I've read here--- several people choose 'not' to adhere to MVC, and code the majority of their application in the view portion. ROR really does little to 'enforce' the user to do one thing, or another, it merely provides tools that aid a person in producing a scalable, modularized, and reuseable, web-application.
Ruby is a fully object oriented programming language, that was built from the ground up on the principle of least surprise. Language constructs aren't built directly into the syntax, as they are in perl--- it adheres very closely to the smalltalk view of a truly object oriented language being composed of objects, and messages. The script isn't being augmented with a new 'breakpoint' keyword, but instead with a breakpoint function. There's very little that's magical about what ROR does, and most everything it does can be extended upon, reused, or changed.
It's not a new 'kind' of tool, it's just a clean integration of existing tools. It's an environment that has integrated a great deal of the components that have been in wide use by other web-development platforms for years, and provides a clean way to generate a template project using those pieces.
... by design. Thus, I presume, the use of the word 'Rails'.
:p)
You want a DB-driven site that hooks into a single DB for all its tables? You got it.
You want a site that hooks/controls multiple DBs, or want to stray too far from the paradigm? Not so much.
If your project is contained mostly or entirely within the Rails Venn diagram, you'll be happy. Otherwise, not so much.
(I looked into it for a site that would manage large #s of XML files, and found that going outside the one-DB-per-site model was very unfriendly, but then again, IANARP..
Unfortunately, Rails is limited by a couple of limitations that are really Ruby's limitations: most importantly the total Lack of Unicode support. I like most of the design of the Ruby language, but to not support Unicode in 2006 makes it essentially unusable for most projects where I would need it, including practically all Rails applications. Ruby is also not particularily fast, in some respects quite slow which also impacts Rails.
Zope has a seriously bad reputation from their 1.x and 2.x days. I don't know if they've reformed enough with 3.x, but Zope is "enterprise-grade" in a very real sense -- huge and complicated.
:)
I do appreciate RoR's marketing skills. They're really reaching out to Java and PHP users -- who I suppose are somewhat easy targets, considering how terrible web programming can be in those languages -- which I don't think the Perl or Python communities really tried to do. Since I'm a Python fan and Python is somewhat of a middle-ground between the looseness of Ruby and the solidness of Java, I'm hoping the Rails marketing brings some people our way
Just for correct referencing alone you should attribute material correctly to its source.
There would not be anything wrong if you quoted the summary and cited it correctly.
Rails code I looked at looked very much like JSP/ASP/PHP gone bad. All sorts of code in HTML land.
How is that the fault of Ruby on Rails? You're supposed to move code out into helpers for MVC reasons, readability reasons, and re-usability reasons.
"Sufferin' succotash."
So many frameworks, so little time...
I would love a comparison between Rails and perls Maypole and Catalyst or Phythons TurboGears and Django or php's cakePHP and smart3
Hard to find Ruby programmers, and their are more commonly known languages with comparable frameworks, some of which have been around longer (like maypole). Then again, Ruby fanatics are generally cream of the crop programmers and one wouldn't have to worry about PHP n00bs who can't really code or perl programmers who write line noise or the overhead of Java and it's seemingly required department of architects
Seems other languages are just as good, just harder to manage, but if you have top notch PHP programmers and Perl programmers who work well together to write maintainable code , I wonder how they would compare then?
What on earth are you talking about? Sure, Rails isn't appropriate for some projects, but it certainly is appropriate for others. Rails isn't missing any critical feature that makes it useless for web development in general, and it makes good on its promise of rapid development. Rails performs well in its (sizable) niche; take it outside that niche and of course you'll have problems, but that doesn't imply that it's useless for all applications.
One reason why I have so much impedance against Ruby is the different syntax. PHP has a C-like syntax, which makes it very easy to catch for someone who knows C and Perl. What's wrong with Ruby's syntax? Well, the dangling "end", for instance. It's too FORTRAN-like for my taste. "end" what? With curly braces, there is never any doubt on the block structure if you use a modern editor, with Ruby's "end" you can never be sure of what ends where. I also prefer the curly braces instead of "begin"/"end" for the simple reason that it means less ink on paper, less clutter, easier to read listings. They say the Ruby syntax is "flexible", well so is Forth.
Using Ruby instead of Java, OK, I can see why it's better. But I'm still waiting to see a good explanation why should someone use Ruby instead of PHP, or Perl, or Python, the three languages that have become so much associated with the "agile development" trend of software development.
1/0 paragraphs is infinity percent, or undefined percent.
ResidntGeek
They're really reaching out to Java and PHP users -- who I suppose are somewhat easy targets, considering how terrible web programming can be in those languages
And they're doing so from a position of strength and knowledge. Why, they even use PHP for the official Ruby on Rails site! Presumably to make sure they really know how their product stacks up against the competition.
When it comes to Ruby, I have one wish:
.net environment. Performance comparable to C#, developer time comparable to normal Ruby, bytecode obfuscated enough to use in commercial products.
.net to do that, not to mention the programming of that insane compiler, I could write hundreds of useful Ruby programs.
Compile it. For the love of God and all that is holy, Ruby is at least as slow as JavaScript, if not slower -- at least you can compile JavaScript into Java!
Perl6 shows some promise in that area, but I have some serious doubts. Ruby, as a language, does far too many things that simply assume it's a "scripting" language. For instance, it's possible to modify any class at runtime -- thus many core libraries probably rely on that feature. Also, all names in Ruby are kept around at runtime. I'm pretty sure that it actually is doing a hash lookup every time. For instance:
irb(main):026:0> class Fixnum
irb(main):027:1> def method_missing (name, *args )
irb(main):028:2> print 'Attempt to call '
irb(main):029:2> puts name
irb(main):030:2> end
irb(main):031:1> end
=> nil
irb(main):032:0> 5.foo
Attempt to call foo
=> nil
irb(main):033:0>
I'm sure that someone will find a much simpler / more efficient way of doing the above, but the point is the same. Obviously, whenever Ruby executes code that attempts to call '5.foo', or even '5 + 5' (which becomes something like 5.+(5)), it actually stores the code for the call as a call to a given name, and then looks up that name at runtime.
Now, good OO design generally involves making lots and lots of small classes, and even the bigger classes will have lots and lots of small methods. Good programming design in general tells us to refactor mercilessly, which will, in any language, tend to reduce the amount of code per method and increase the number of method calls. And even if you go the other way, and don't use any methods at all, the simplest line in Ruby (since it's a pure OO language) will break down into 5 or 10 method calls, at the very least.
What all this means is, Ruby is back to that old argument of developer time vs. application run time, and I hate that. I really love it when we can break out of that mold -- when we find that, most of the time, a compiler will produce better code than handcoded assembly, or a language-based garbage collector can actually run as fast or faster than a hand-coded, application specific refcounting scheme. Or when we find that Java, despite being bytecode, will, once you JIT it, run as fast or faster than equivalent C++. Or when we find that mod_perl can be close enough to the speed of a C program that it's not even worth considering using C instead.
But when it comes to choosing a language, they all have their performance wrinkles. C++ probably uses more memory than C, and always seems to take far longer to compile. Perl isn't anywhere near as fast as C, so whenever we find something where we need that extra speed, we rewrite chunks of a Perl module in C. Python is the same way, though Psyco looks promising, but Psyco is also x86 only, not even amd64. Java is as fast as anything, once a program starts, which takes far longer than anything else even if you've gcj'd it -- plus, the language sucks compared to Ruby. C# is as fast as Java, and so far seems to load much faster, but the language sucks (really a rehash of Java/C++), IronPython is nowhere near done, and even IronPython isn't as nice as Ruby -- plus, the platform is controlled by Microsoft.
Ruby has absolutely awesome syntax, can be 10x faster to develop in than most other languages, but due to the language design itself, it will always be much, much slower than Perl, and that's saying something. And it's just depressing when you find you can make a chunk of your program run 10x faster by porting from Ruby to C, only it will take 50x more code.
I guess what would make me happy is an insanely intelligent compiler for Ruby, that targeted the
But that's depressing, too, because in the amount of time it would take me to learn enough about Ruby and
Don't thank God, thank a doctor!
I've spent the last month experimenting with RoR and Django. Although I prefer Python as a language, I found RoR much more exciting to use. Everything is nestled into a nice package. I understand why it appeals to .NET and J2EE developers who are used to rigid environments. Despite all this, I don't think RoR is going to save your life. Get over it fan boys!
Here are some things I noticed about RoR:
- The RoR community is full of obnoxious zealots (similar to the those who idolize Steve Jobs). Many tutorials are filled with chit-chatty authors who believe programming is a whimsical ride. I don't want to hear your cute jokes. Get to the point and tell me how to use the tool.
- PHP is installed on almost every *nix host out there. I can cook something up in PHP and deploy it just about anywhere. This is not the case with RoR. You have to find a RoR-friendly host or have your own server.
- Lack of Ruby programmers. This is likely to change with time though.
- What's wrong with PHP? It's is great for rapid development and not every site fits into the MVC paradigm.
So why choose one language over the other when they both excel at different things? People didn't stop using telephones when the Internet was invented. You're better off using both tools and knowing when to use them. People get obsessed with this stuff, and take it too seriously. Why are you programming in the first place? To be cool?
Zope is the single largest waste of talent and innovation in the history of computer science. It's an amazingly well thought product, it solves every problem you might have when designing dynamic web sites, it solves problems you didn't even know, it comes functional out of the box, it takes seconds to install and get going, yadda yadda yadda.
Never in the history of computing science has so much innovation been so impossible to deal with. No real documentation, the simplest things are difficult, a buttload of half finished products none of which have any documentation to speak of. Most (yes MOST) zope products have no documentation other then it's name. You want to see a joke, go the zope collective on sourceforge. Now there is a crackup.
Dear Zope Community. I love the technology you have built, please make it so that I can use it. While you are at it please make it perform better then 1/10th of the speed of apache, php. You don't have to make it as fast, just don't make it like a joke.
While I am asking. Please create a sourforge or a CPAN for zope products so I can just install products without wading knee deep into dependency hell. Make it easy for me to keep my products updated. For examples of how to do this please see perl CPAN, ruby gems, apt, and yum.
Do this in time for zope3 so that the effort that went into that won't end up being a waste too.
Sorry if I am coming across a little harsh, I really love the ideas behind zope, I run a zope(plone) site, but it's much harder then it needs to be. Much harder then ROR for example.
evil is as evil does
Why not provide a couple links to a couple of projects using DDs so we can check them out.
In ROR the database IS your DD.
evil is as evil does
Perhaps you should look at Lisp/Smalltalk/Your favorite academic language not being able to market their way out of a wet paper back:-) If they've had since the 70ies to build something that'll take off, and they haven't, they're doing something wrong, and it sure isn't the languages themselves, because they are very nice indeed.
... while, which is not part of the core language).
Changing subjects, one of *my* favorite "cheap Lisp imitations" (it's Lisp, not LISP) is Tcl:
http://antirez.com/articoli/tclmisunderstood.html
which is in some ways more flexible than Ruby - you can redefine existing control structures like if and while, or create new ones of your own (such as do
http://www.welton.it/davidw/
The heavy use of sigils is not Ruby's fault, it's yours. I've written a lot of Ruby code and have rarely used sigils.
Sigils in Perl are mandatory and define whether a variable is a $scalar, a %hash, an @array or a &block of code. Ruby's sigils define scope: local (no sigil), @instance, @@class or $global variable, which is a good approach since it let's you know instantly whether a variable is local to the block of code or comes from another scope, which is far more important than its type.
So, unless you're using a lot of global variables, you shouldn't be heavily using sigils.
Finally, I don't see anything wrong with having regular expressions as part of the language. But if you don't like that, nothing stops you from using Regexp and Match objects.
The best way to predict the future is to invent it
Windows is like decaf - it tastes like the real thing, but it won't get you through the day.
The secret sauce is "Hype". And if you lift the bun, you find that there's more secret sauce than meat.
The crux of the problem with that argument was brought up by the author of webwork, if I'm not mistaken. If you're coding so much that you really can get a 10x improvment then you're clearly not doing enough design work to be making an app that's worth shit, regardless of the tool. Rails doesn't cut down on the thought time.
DHH kind of tries to disown that comment when he's challenged on it. It's just rails marketing and hype, someone has whispered "10x faster" and they repeat it but they don't stand behind it. One thing that you can bank on, there is a lot of hype around rails, the people who make it are responsible for contributing to that hype and there is very little in the way of concrete information about these outlandish claims.
It's okay at what it does. I personally don't care for the hype and I generally distrust when all you have is hype.
Something else to consider, rails by design scales by pushing everything in to the database. They have some minimal caching at the web tier but none at the db tier. You need to render more pages, buy a bigger database, that's the quick answer and they suggest that it works because "yahoo does it that way" This is kind of an, um, interesting way to address scalability. I like how they make sure that they compare rails to what yahoo does too, it's just a quick and subtle comparison but it works and leads you to believe that you could do something yahoo like in rails, when it couldn't be further from the truth. Activerecord doesn't exactly conserve queries, some fairly simple joins seem to result in a lot of queries and it's kind of heavy. It's sales and marketing's way of saying they haven't really addressed the issue. To be pragmatic about this, why on earth are there all the elaborate caching schemes in EJB and J2EE and JDO? Surely people didn't just think it was something fun to build, I know the rails crowd seems to hate java but don't they think anyone with any real skill worked on it ever? I buy the j2ee is complex argument but I need to understand their argument for the complexity being unneeded. If you're planning to move on to a different project before it actually has to scale, that's not really an argument. From my own experience building clustered j2ee apps, scaling by just shoving everything into the db and hitting it for each page simply isn't a practical option if you have any real traffic.
I haven't used Ruby or Rails. I only read the ten minute tutorial that got posted here a while back. Actually reminds me a lot of a object wrapper I wrote for perl that built class heirarchies automatically from a DB schema. It was pretty cool if I do say so myself, and so is Ruby on Rails.
However: I don't think it matters. In my experience it doesn't matter that much what programming language or model you use. Object oriented or procedural, strongly typed or loosely typed, monolithic or microscopic, chocolate or vanilla. Everything eventually bows to the reality of inherent complexity. I've seen each style done right and wrong, and if they're done right, the differences sort of wash out over time. My prediction is that Ruby on Rails is great for prototyping, but if you ever have a large buisness project that grows and develops for years it'll end up no more productive and maintainable than any other competently written code base, and probably no less productive either.
I'm not saying none of these choices matter: they do. There are certain things I've written that are much more sensible OO than procedural and visa-versa. In the end you make decisions on how to go about a particular project, and if you've made the right ones five years later you can still carefully move at a crawl and bring new people into the codebase with only a few weeks of training. And I don't think any technology shift will notably beat that. I'm still a believer that there's no silver bullet that will make development (especially long term development) a breeze.
But what do I know? Use what makes sense to you.
Cheers.
You must be new here. A lot of people don't read the summaries either.
What I would think would be really cool is a Lua plugin for Apache.
Google for "mod_lua".
Alliteration. Ruby on Rails: it just _sounds_ good.
What it actually _is_, I don't know. I know approximately what Ruby is, although not intimately, but I have no idea what the rails signifiy in technical terms, although they presumably connote rapidity of some sort. If I were a Ruby programmer, I'd certainly want to know what this Rails thing is all about.
Whether it sounds good enough to make me (as a Ruby outsider) want to learn the language is another question. Frankly if I were to learn Ruby it would probably be more due to the good things I have heard about it from sources like perl6-language, than due to Rails, because whatever other tools you use the quality of the core language is critical to their usefulness, so as a programmer it's the style of the language I want to know about first. (This is part of why I never picked up Java: the GUI libraries it comes with are supposed to be really great, but nobody with similar tastes in languages to mine ever has many attractive things to say about the design of the language itself; Ruby, OTOH, does regularly get positive comments from people whose opinions on language design I respect greatly.) Nonetheless, if I *did* take the time to learn Ruby, and if I found that I liked it as a language, Rails would definitely go on my to-learn list then, *despite* that I don't actually know what it does. Because, you know, it just sounds good. Probably looks good on a resume too.
Cut that out, or I will ship you to Norilsk in a box.
I'm reading more and more about how ROR as a web app scales very well for large scale sites. For yself I'm learning how to do some advanced things with it, here is my HOWTO speed up ruby-on-rails with memcached:
y -on-rails-with-memcached
http://fak3r.com/articles/2006/05/11/speed-up-rub
fak3r.com
There is no special sauce. It's just the latest hyped toolkit that will be gone next week. Look for Jarva or D++ or whatever trendy new thing pops up in software next week that does absolutely nothing.
Listen kids, there is no silver bullet. For all you folks that dropped out of college/high school who generate the ad clickthroughs that make these stories submittable: Fred Brooks, The Mythical Man-Month. Read it.
Why not provide a couple links to a couple of projects using DDs so we can check them out.
It has never been tried formaly in a commercial product I know of except for FoxPro. However, FoxPro did not document it and their implementation was poor IMO. However, here is a set of links about the concept:
http://www.geocities.com/tablizer/ddsamp.htm
http://www.geocities.com/tablizer/top.htm
In ROR the database IS your DD.
I am not sure what you mean. The DB native schemas usually don't contain sufficient info for GUI interaction by themselves. At best they can serve as a starting point.
Table-ized A.I.
Actually there's only one ruby lucene port, ferret, which is now written in c.
It's running plenty fast for me.
I've used rails for only a few months, but already have quite a good understanding of how everything works, and have even done some hacking/patching on the backend. I've also used ActiveRecord with some applications that are not web-based, all with good success. I love every convention in Rails, except for one, which I dearly hate.
ActiveRecord was designed quite obviously from the perspective of a MySQL user. The train of thought that a DB should only be a place to dump your data and nothing more is extremely prevalent with ActiveRecord. Things like referential constraints on foreign keys are completely ignored/not used, instead being defined in entirety in the model code. Perhaps my biggest aggrivation with ActiveRecord however is that it assumes I implement enumerations as varchar datatypes. I find this just plain wrong. Here's an example:
ActiveRecord way:
CREATE TABLE Users (
id integer primary key,
username varchar,
usertype varchar
);
ActiveRecord will then use its single-table inheritance logic and each subclass of User eg "Administrator" will have that name in the usertype field, stored as a string. From a data-modelling perspective, I find this so wrong. I naturally implement this using an extra table of usertypes and a foreign key in Users:
CREATE TABLE UserTypes ( id integer primary key, type varchar);
CREATE TABLE Users (
id integer primary key,
usertype integer references UserTypes(id)
);
I have managed to get ActiveRecord to play somewhat nicely with these types of constructions by redefining some class methods in ActiveRecord::Base, but I'm definately violating DRY.
This all said, and including the time I needed to spend hacking around in the ActiveRecord code, I am still more productive with Rails. Highly recommended, just with a hint of caution towards ActiveRecord paradigms and database integrity.
Ruby programs run in an interpreter written in C/yacc. The interpreter is slow and problematic (threads, unicode, it's all been said). Since ruby is defined by this one interpreter implementation (there's no written standard and the only way to create one would be by _fully_ understanding the interpreter), this tends to form a ceiling on Ruby's scalability.
Whence? Hence. Whither? Thither.
Bah! Why read the summary? The headline has more than enough information. So anyways, I think the Secret Sauce is Mayonnaise.
I think most of the attention ROR is getting is just hype and secondary hype. The first wave of hype drew a lot of PHP developers (90% without any real clue about programming) to evaluate ROR. And of course, compared to PHP ROR is like a gift from heaven.
After the hype around it persisted I tried it out myself. My impression was that it is nice but nothing worth that much hype -- plus I don't really like Ruby that much, its syntax seems to make too many things different just for the sake of it.
The good thing about ROR is that it belongs to a new current breed of web development framework putting emphasis on rapid, easy development. I like the pythonic Turbogears very much (especially the upcoming 0.9 release).
while (!asleep()) sheep++
1. Hierrarchical structures and hash tables are not related in any way. The advantage of easy declaration comes from syntax and not from hash tables. A language with syntax that allows easy declaration of hierrarchical structures has the advantage over a language that does not offer such a functionality, but overall this has nothing to do with hash tables. You could do the same thing in LISP and in a much better way.
2. Declaring members within methods is a bad practice: it makes maintenance more difficult. Suppose you want to change a member's name from @foo to @bar; the compiler\interpreter will not inform you that you did not change all references of @foo; now your object will have two members @foo and @bar.
3. The VM does a loopup in a map or a table. If the relevant entry in null, the method is declared as missing. But changing methods of a class at run-time is not good, because it allows the programmer to easily violate the contracts of the class. Not only you have destructive update in Ruby (please search online why destructive update is the root of all problems), but you can also change methods on the fly. Furthermore, LISP's 'defmacro' has nothing to do with methods: the 'defmacro' function introduces a new function which is to be invoked at compile time (thus a 'macro').
4. Scalability is not a factor of language, but of framework. Don't you think that J2EE scales well?
5. A web development system is not a messy undertaking; in fact it is very easy to build a web framework, since a web application is nothing more than a message-driven application. There are various frameworks in the market which make web development very easy in all languages (even C++ with FastCGI is a good solution).
6. There are Java frameworks that do not have a "pre-processor", like Echo, for example: all you have to do is write a web application as a desktop one, replacing Swing views with Web Views. I agree it is a bad idea to write Java within HTML, but you are presenting Java as if it is not capable of having a "language only" framework, i.e. a framework without XML/HTML, which is totally wrong.
Yup, but it's coming in Ruby 2.0!
I tagged this one as sauce. Nobody else did. Tagging ROCKS! :D
8 of 13 people found this answer helpful. Did you?
Why, they even use PHP for the official Ruby on Rails site!
That's because it's a website not a web application. The strength of PHP is for a little dynamic code here and there as you need it. The strength of Ruby on Rails is developing web applications.
Hey guys I am a student and I have been working with ruby on rails for the past 4 months. I have to say taht I dont like it. I find that it is a pain to learn a new programming language just to use it. Instead of HTML ruby on rails uses RHTML. This is a pretty easy code to learn and use but I still dont enjoy it. However I am impressed at how quickly you are able to set up a web site. I havnt been able to make a very good looking website but i was still able to make it quickly. Over all I think that RoR is not as great as I thought it would be and I prefer the old way of making web sites with DreamWeaver and Photoshop. I know that RoR is all free software which is good but I think that the price is the only good thing about RoR.
TurboGears is similar to Rails, but in Python. I don't believe it was inspired by Rails, but the TG people are using the Rails momentum to guide development (in terms of what's working for Rails and what isn't) as well as borrowing a few marketing ideas. (For example, the 20-Minute Wiki tutorial.)
I'm neither a RoR or TurboGears guru by any stretch, but near as I can tell, these are the main differences between Rails and TurboGears (real gurus are welcome to correct/add to this list):
1. No need to learn a new language (if you already know Python). Relatively few developers knew anything about Ruby before RoR became a hit, while lots of people know Python.
2. TurboGears comes with less magic built-in. Which is actually a boon for most people because a few that I've talked to thought that all of the magic in Rails ended up making non-trivial applications hard to both develop and debug. TurboGears is much more verbose. Sure, you have to write a few more lines of code for many typical tasks, but you also have a much better idea of what's going on in your application and can debug it quickly when it breaks.
3. TurboGears ties together several pre-existing projects into one framework rather than rolling their own. This offers a couple of nice benefits. First, it's less work that the TG developers have to do. They neither had to write nor have to maintain much of the code that TG rests upon. Second, it's possible that one sub-project can be substituted for another later on down the road. (I understand that they're already using this feature and are in the process of migrating SQLObject out and bringing SQLAlchemy in.)
4. Better documentation. Python is already exceedingly well documented and the TG folks are going out of their way to make sure that their framework is documented just as well. By contrast, if you're just starting out with Ruby and Rails, the best documentation available right now is a Ruby book and a Rails book, both by the same publisher. Part of the reason I didn't go too far into Rails was because I couldn't afford to invest in the books at the time. (There is a TurboGears book in the works by Mark Ramm which should be out later this year.)
Of course, one potential downside to TurboGears is that you have to learn how the various sub-projects work in order to use TurboGears. But they're not all that hard and are probably about the same amount of effort to learn as all of Rails.
There are also a couple other really nifty things about TG that I'd like to mention. (I don't know if rails has these or not.)
The templating engine, Kid, allows you to draft up a template and give right to your web designer, with placeholder text and all, and have them hack on it in Dreamweaver or whatever they use. When they're done, just copy it back into TurboGears and it simply works. Kid uses real HTML tags and attributes, so web browsers can view the templates directly and HTML editors can edit them without mucking up the template-specific stuff.
CatWalk, the built-in AJAX database editor can be enabled in your TurboGears app by inserting like two lines of code. Talk about sweet.
Unicode is a sore on the face of programming. UTF-8 may not be superoptimal but it definitely makes life a lot easier when dealing with L11N and I15N. This is more than just "Speak English Or Die" mentality, it's more of efficiency and in many cases ASCII is more than adequate for the program, yet it has to cater to double size characters that eat up memory with pretty little zeros everywhere.
If you don't realize the issues with putting logic into the database (never mind the performance hit) you've got some serious learning to do.
If you're looking for "advantages", I would suggest MVC architecture in general. Without that basic understanding, you will never see the benefits in Ruby/Rails.
Rails solves problems. Plain and simple. It was built from day 1 to address a specific problem, (basecamp) and now the creators have found that a lot of people have very similar problems to solve. That's it. That's why it's so good.
It does not try to solve every problem, like J2EE. It is not a solution looking for a problem, like it's many Python-based cousins. It won't solve every problem, and makes no claims to do so.
But if your problem is a web-application with a (smallish) number of variables, RoR is a godsend.
Do not associate 'secret sauce' with 'porn'. I had a Big Mac for lunch, and it brings, er, unsettling images to mind.
i believe this relates to intelligent defaults. if you name your table and its id column correctly, rails knows enough about it to display a crud page without the designer coding one iota of html. of course, it is basic. but it does work.
Well, most column names I encounter are not well-suited for report listings as-is. Anyhow, that is a matter of grabbing the schema information. Whether the existing schema is copied into a starting Data Dict or used for coded defaults is really the same thing more or less. A data dict approach can default to the column name for titles also if no title is given. I've implemented DDs this way.
click on the CRUD links and you get pages that will perform the functions. again, w/o one iota of html coding. it is basic, but entirely functional.
I am not sure what you mean by "CRUD links". A lot of cross links and drill-downs can be specified declaratively also, such as providing the name of the description column to serve as the click-link, and telling it what the primary key is. I just like working with such info in tables rather than code if given a choie. If you like it the other way around, I will respect your choice as your personal preference.
Table-ized A.I.