What's the Secret Sauce in Ruby on Rails? 414
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."
Re:Rails zealots aren't hammers, they're just tool (Score:4, Interesting)
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.
Re:Relentlessly applying best practices (Score:3, Interesting)
Am I the only one who was reminded of Ajax at this point? Old technologies put together, lots of hype...
Re:A question... (Score:3, Interesting)
As to your sig, I can't say I have any love for VB (especially after being forced to use it), but after trying to deal with the MFC and doing GUI aps in C++ on a windows machine, I understand why it was created. Still think they should've just done a better job with the MFC or created something less retarded than VB.
What Java can learn from RoR (Score:3, Interesting)
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.
The secret sauce is ... (Score:3, Interesting)
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.
Re:What Java can learn from RoR (Score:4, Interesting)
Podcast with Author Bruce Tate (Score:3, Interesting)
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 [rubyonrails.com]
Re:Liberal license (Score:5, Interesting)
RoR hype == good product + good marketing. Period. (Score:5, Interesting)
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.
Re:It's multiparadigm. (Score:3, Interesting)
Uhh, dude... that is Smalltalk. Smalltalk was specifically designed to meld OO development methodologies with the power of functional languages like LISP. Why do you think that blocks and functions are first class objects in Smalltalk? Or that it has proper lexical closures?
In fact, every time I look at Ruby, all I see is a pale reflection of Smalltalk. I've yet to see anything new it brings to the table.
Re:Relentlessly applying best practices (Score:5, Interesting)
No, it really doesn't, and to claim it does is to ignore the wide range of uses of object persistence. What it has is a great design for getting web interfaces up and running quickly on databases. It has a very poor design for long-term maintenance and growth of applications.
The ActiveRecord pattern is of limited use, especially as implemented in Rails. Your code is not isolated from major changes in the schema, and the dynamic nature of Ruby means that the consequences of such changes can't be tracked by compilation or refactoring tools; especially as the model classes don't even exist as code. Tests are a good way to help with this, but try and design tests to deal with potential schema changes for a large application that may have transactions involving thousands of records...
To see what a good persistence system should be like, take a look at Kodo or Xcalia - very high performance persistence system that allow exactly the same code and queries (which are automatically highly optimised for the particular database - not some minimal portable subset of SQL as in Rails) to be run on small embedded databases and high-end clustered systems. Unlike Rails, these systems can handle transactions of hundreds of thousands of records (something that is not that uncommon for commercial work) without thrashing disk or memory. You can also use the same code to persist and read to XML, LDAP and many other types of store. And yes, these systems also have 'convention over configuration' like Rails - they got there first, and had it years before RoR.
RoR has some great ideas, and definitely has its uses, but to claim it has near perfect design is way out, and sorry, but best practise in data model design in object oriented languages like Ruby does not involve basing things on non-OOP relational tables!
Re:Still no Unicode (Score:5, Interesting)
-Dom
Re:Relentlessly applying best practices (Score:4, Interesting)
AJAX is based on technologies with extremely poor design and implementation, such as browsers, JavaScript, and HTML (poorly designed for this application, perfectly ok for marking up documents). Rails takes lessons learned from a decade of server-side Web development, as well as the catastrophe that has become J2EE through over-engineering, and simplifies it to the essential mechanisms. Built on top of Ruby, which is itself a pretty thin simplification wrapper over C++, it combines the simplification of Web site development best practices (MVC, proper tiers, etc.) with the power of an high level development language overlaid directly on top of a low level near-assembly language, with the ability to perforate the abstraction layer (first through modifying Rails source in Ruby, then through C extensions) if needed for performance or other reasons.
Short, brutal version: AJAX built on crap by script kiddies, Rails on bedrock by software engineers.
Re:What's the Secret Sauce in Ruby on Rails? (Score:2, Interesting)
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.
RAILS is a different tool? (Score:2, Interesting)
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.
Re:Hidden reasons why ROR works so well... (Score:4, Interesting)
What's great about Ruby? Community, community, community. The ruby community seems to be adopting the mantra of DRY (don't repeat yourself). If any project comes along and it shows superiority then the whole community gets behind it and it quickly becomes a de-facto standard. That's what happened with rails even though there were/are competing frameworks. Same thing with Mutt for example.
Lastly the Ruby community early on were not afraid to take great ideas from the ecosystem. Gems for example is the ruby version of CPAN (the best thing about perl is CPAN). The python guys still haven't figured out why CPAN and gem are important. Ruby community doesn't seem to suffer from the not invented here syndrome.
Re:RoR hype == good product + good marketing. Peri (Score:3, Interesting)
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.
Re:It's Ruby (Score:3, Interesting)
Actually, Java has considerably more features than C++, including garbage collection, runtime safety, well-defined dynamic loading, full reflection, and runtime code generation.
With a tool like Ruby, someone has created these "library" routines for him.
Ruby's libraries are poor compared to Perl's or Python's, so if it all were up to library code, Ruby wouldn't be popular.
so, what innovation did C/C++ give us? General Purpose tools. The fact that these can turn their hand to anything, is, IMHO, the reason they're so popular today compared to any other language that can do X, Y, or Z better.
Neither C nor C++ were the first general purpose languages by a long shot, nor have they ever been the best. The thing that made C popular was that it was free with UNIX to universities and was easy to implement. The thing that made C++ popular was that it was a simple (simplistic, as it turned out) extension of C that was fully backwards compatible. That's all. There was no innovation in either of those languages.
Re:Hidden reasons why ROR works so well... (Score:3, Interesting)
I can recompile any changed java classes on the fly (unless changing class structure). No need to recompile and restart the entire application.
Autocomplete kicks ass. When invoking a method that takes a Foo object, autocomplete can show a list of all methods that return Foo or its subclasses. This is impossible in rails for several reasons. Lack of type-safety means you can pass any object as a parameter. Also, the auto-magic method names in ruby (like find_by_last_name_and_department) make this impossible, since the methods don't really even exist until invoked.
Immediate feedback about syntax errors: If I misspell a method name, the editor flags it instantly. Contrast to a rails application where you won't see the bug until you invoke the action.
Compile catches bugs at compile-time instead of runtime. If I refactor a method and it's still used somewhere, the compiler will find it. I suppose writing good tests in your rails app should catch this, if you have 100% test method coverage, but that seems like a pretty steep tradeoff.
Namespace conflict! This single issue pretty much soured a friend of mine who was trying to learn ruby on rails. He was writing a simple test app for a trouble ticketing system. On the request edit page, he defined a @request global var, which mucked up the @request used by rails. Unclear "missing method" error messages popped up, and it took quite a while to figure out.
There are some serious benefits to rails as well, the list you have is a good overview of the subtler advantages. I love the way you generate XML in rails, it fits the language so perfectly, because of the variable args, code blocks, and on-the-fly hashtable generation. It's definitely gratifying to see how much you can do with how little code, although in some places (like error checking) I think the concepts may have been overextended a bit. After evaluating my list of gripes with rails, and how it could be fixed, I came right back to what looked pretty much like WebObjects + IntelliJ (except for the hideous URLs in WO apps).