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."
A question... (Score:2, Insightful)
Re:A question... (Score:3, Insightful)
It's Ruby (Score:3, Insightful)
Liberal license (Score:1, Insightful)
Conservative, not liberal. (Score:1, Insightful)
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.
Re:Nice Summary. (Score:2, Insightful)
So what? A summary should summarize the article (duh!). If the article itself does a good job at that, why reinvent the wheel?
That or TurboGears. (Score:5, Insightful)
(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.
Rabid IP Hoarders and their Sauces (Score:4, Insightful)
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.
Re:i thought Ruby on Rails (Score:3, Insightful)
For those unfamiliar with Rails, the it pluralizes the name of an activerecord class to get the name of the associated table. So if your class was named "Person", it would, by default, link it to the database table called "people". This is only default behaviour and, unsurprisingly, this can be overridden. It's a feature of the Rails framework, and nothing to do with Ruby.
Re:What is retarded about VB? (Score:2, Insightful)
Of course, it all depends on the programmer, in the same way that, say, carpenters can do both good work and bad. Good just takes so much longer, and is a lot more challenging.
Re:Nice Summary. (Score:3, Insightful)
It's the retards that use it. (Score:2, Insightful)
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.
Re:i thought Ruby on Rails (Score:3, Insightful)
Re:Nice Summary. (Score:1, Insightful)
There would not be anything wrong if you quoted the summary and cited it correctly.
Re:Posted on IBM (Score:3, Insightful)
-matthew
Re:Rails is nice, but definitely limited... (Score:3, Insightful)
This is by design, obviously. And in a way it can actually encourage good modular design. Where someone doing Java or PHP might be tempted to write one monster application that controls two DBs, the Rails developer is encouraged to write separate applications that communicate with each other trough a well defined interface. And if the two databases don't represent two differnt modules/applications, maybe they shouldn't be different databases.
That said, I agree, Rails is limited and there will always be a place for other frameworks or unstructured freeform coding such as one might do in PHP.
-matthew
Re:What's the Secret Sauce in Ruby on Rails? (Score:3, Insightful)
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.
Re:Liberal license (Score:3, Insightful)
Yes, I'm sure many young real-world developers think that way. Now, they should think about what happens when Sun goes out of business, or when they sell Java to Microsoft, or when they just can't afford to pour money into Java anymore, or any of a number of other possibilities. Think it can't happen?
Well, back in the day, we didn't think it would happen to companies like DEC or Symbolics, but it did. That's why real-world developers, after getting screwed by companies like Sun, decided to rely increasingly on open source software, because in the long run, it gets the job done more predictably and with less risk.
Using and contributing to open source software for most people is just business: it primarily reduces risk by ensuring long-term availability and stability of a platform, in a way that no company has ever been able to.
Re:Liberal license (Score:3, Insightful)
Ruby is slow (Score:4, Insightful)
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
Re:CRUD screen secrets - Data Dictionaries (Score:3, Insightful)
In ROR the database IS your DD.
Re:What about PHP? (Score:3, Insightful)
phpGroupware? You've got to be kidding! There is just no comparison.
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.
Try Ruby for a week, seriously. I came from a mostly Perl/C/PHP syntax background and had little trouble picking up on Ruby. Once you start using code blocks, closures, true OO design, and all the Ruby nicities, you'll never want to fart around with PHP again. Here is an example of some really slick (in my opinion) ruby code. Lets say you have two arrays of objects that you want to add together, remove duplicates, and sort by an arbitrary attribute:
combined = (array1 + array2).uniq.sort_by { |obj| obj.someattribute }
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.
Of all the trivial complaints, that has to top them all.
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.
Of the 3 you mention, only Python really matches Ruby. Perl is still king for processing text, but it is somewhat specialized in that. PHP is more or less just the lowest common denomonator among modern web programming languages. As a language it is nothing special and in many ways it is sloppy on inconsistent. I haven't used PHP 5 much, but last tiem I checked, object oriented PHP was a complete joke. Its only advantages are that it is easy to learn and runs just about anywhere.
-matthew
Re:Relentlessly applying best practices (Score:5, Insightful)
The only part of that I'll give you is the poor IE implementation of CSS. Browsers' main problem lies in their non-compliance with standards. Solution: test in multiple browsers. WOW, THAT WAS HARD. Next up: JavaScript. Poor design? I was shocked at how powerful the language is when I finally started digging into it after years of avoidance. Poor imlpementation? Not really - just many different implementations. Of course, this can and has already been worked around with libs that abstract the differences away for you. HTML? It still is used as a basic markup language, with all the heavy lifting being pushed into the CSS. Now, CSS is nowhere near perfect, but it does function admirably in the scope of AJAX (when not using IE's broken ass implementation).
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.
I half-agree. You imply a minimalism that isn't present. The framework is quite complicated in places and does a lot of tricky things. You see, programming with just the essential mechanisms sucks; you've gone back to CGI.pm. What Rails does is provide a massive lever with which to move your problem. The Actual Work Done Per Line of Code metric exceeds any other framework I have used before. Code efficiency is the watchword, not simplicity.
Built on top of Ruby, which is itself a pretty thin simplification wrapper over C++,
No it isn't. Ruby's implementation is a big, slow VM that doesn't act much like C++ at all. Really, the poor performance is the only thing I dont like about the language.
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.
That sounds like marketroid speak, and is about 3/4ths BS. Perforate the abstraction layer? Jesus. And just who is running around writing C++ extensions for web apps? Almost nobody. Takes too damn long, and isn't as safe as running through the VM.
Short, brutal version: AJAX built on crap by script kiddies, Rails on bedrock by software engineers.
DHH is something closer to a hacker, not to mention the fact that rails utilizes AJAX and, more generally, javascript all over the place. Does that make AJAX apps built on top Rails rock? Or does all that terrible, awful AJAX stuff diminish Rails? Maybe they, I don't know, utilise the same foundation technologies and standards and complement each other quite nicely? Maybe you are an idiot?
Re:It's Ruby (Score:1, Insightful)
Languages are about helping us solve problems. Each embodies a certain programming philosophy to increase chances of success. For example, programming OO in Smalltalk (and probably Ruby as well) has certain real advantages for the OO programmer.. because Smalltalk is a more powerful abstraction language than Java or C++ are. That is because Smalltalk simplifies the general OO mechanisms and reduces unnecessary clutter that Java and C++ force you to carry.
It's all about making you more productive and making the code more reusable and maintainable. Java and C++ are just not as good as Smalltalk (and probably Ruby) for this.
It's not about whether you have good programmers or not. Language can influence productivity and bugs. For example, I worked with a highly experienced C++ team. They then switched to Java and productivity rose beyond levels we had achieved with C++, in spite of the lack of experience with the new language and the unchartered waters we were navigating. (In this case, Java's exception model, ease of use and huge library availability allowed us to: not waste time implementing what others had done, find and fix bugs quickly, have less weird side effects, use things like threading to make our app more advanced).
It's not just the programmer.. the tool the programmer selects is very important. In fact, the good programmer chooses the right tool instead of slaving with the wrong one.
Re:Nice Summary. (Score:3, Insightful)
5 to 10x more productive than Java? (Score:3, Insightful)
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.
Re:It's multiparadigm. (Score:5, Insightful)
Deliverable packaging. Extracting a Smalltalk program from the development environment for distribution is, to be generous, annoying. Which is one of the reasons why Smalltalk works so well in an academic environment, but never caught on for commercial work. Ruby, on the other hand, is about as tough for someone else to deploy as Perl (it isn't).
This is one of the places where Java really changed things and is IMHO, the big reason for why Java has become so popular.
Regards,
Ross
Talking out my ass... (Score:3, Insightful)
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.
Re:What about PHP? (Score:3, Insightful)
Sorry, I don't mean to sound like such a Ruby fanboy. I am really not. It is just that it frustrates me when people like the grand parent shut themselves out to learning something new. He says that he doesn't want to "waste a minute" on Ruby but he doesn't realize that he's probably already wasted countless hours writing PHP hacks that aren't even very reusable.
-matthew