What's the Secret Sauce in Ruby on Rails?
Posted by
CmdrTaco
on Sun May 14, 2006 10:25 AM
from the having-a-hard-time-caring dept.
from the having-a-hard-time-caring dept.
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."
This discussion has been archived.
No new comments can be posted.
What's the Secret Sauce in Ruby on Rails?
|
Log In/Create an Account
| Top
| 414 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
A question... (Score:2, Insightful)
Re:A question... (Score:5, Informative)
Fact is that Rails template (rhtml files, the views) are scripted directly using Ruby (there is no specific view/template language). This means that they can be abused, not that they should.
When used well, Rails views are actually quite clean due to the high readability of Ruby itself and the ability to rapidly create so-called Helpers (Ruby methods that you can call from your views, to build specific HTML structures from generic datum, since you come from JSP land think Taglibs, but much simpler to define & use)
Seems like DHH found Ruby simple enough to just use it as a templating language (and it works quite well), that's his choice, other frameworks in other languages picked a different one (Python's Django has a template-specific language for example, much simpler and less powerful than full blown Ruby but much less prone to abuse either)
Oddities (Score:1, Offtopic)
(http://butsuri.homelinux.net/)
Is this standard procedure for all new stories or is this some kind of gimick/pun on web developement stories?
It's Ruby (Score:3, Insightful)
Liberal license (Score:1, Insightful)
Re:Liberal license (Score:5, Interesting)
(http://del.icio.us/Abcd1234/)
It's multiparadigm. (Score:2, Informative)
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.
Re:It's multiparadigm. (Score:5, Insightful)
(Last Journal: Thursday January 06 2005, @02:26PM)
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
Relentlessly applying best practices (Score:5, Informative)
(http://marshallbrain.com/manna1.htm)
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.
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:Relentlessly applying best practices (Score:5, Insightful)
(Last Journal: Friday March 31 2006, @10:51PM)
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: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!
Django, anyone? (Score:2, Informative)
(Last Journal: Sunday July 13 2003, @10:38AM)
Oh, of course there's a big backlash against web frameworks these days isn't there?
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.
porn. (Score:2)
Those crazy open source programmers.
i thought Ruby on Rails (Score:1, Funny)
Re:i thought Ruby on Rails (Score:4, Funny)
-matthew
Yes, but can Ruby do this? (Score:2)
What Java can learn from RoR (Score:3, Interesting)
(http://slashdot.org/)
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.
Re:What Java can learn from RoR (Score:4, Interesting)
(http://www.kibbee.ca/)
My problem Ruby on Rails (Score:2)
Could it be that case that I have not found it yet but it exixts? Point me to the URL.
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.
Rabid IP Hoarders and their Sauces (Score:4, Insightful)
(http://nick.neadwerx.com/)
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.
Podcast with Author Bruce Tate (Score:3, Interesting)
(http://nubyonrails.com/)
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]
Special sauce? (Score:5, Funny)
[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.
Hidden reasons why ROR works so well... (Score:5, Informative)
(http://www.lisperati.com/)
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.
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.
What Controversy? (Score:1)
(Last Journal: Friday May 20 2005, @12:26PM)
Still no Unicode (Score:5, Informative)
So, for now, it's Java or Python, and associated frameworks for me. But not RoR.
Re:Still no Unicode (Score:5, Interesting)
(http://happygiraffe.net/blog/)
-Dom
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.
Japanese factor ... (Score:1)
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.
RoR works well with my brain :-) (Score:2)
(http://www.markwatson.com/)
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.
Tutorial for RoR? (Score:2)
(Last Journal: Monday February 13 2006, @07:11PM)
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 [janiry.com] for C++ and Java, as a hint of what I'd be looking for.
Is there anything good out there online?
Hype and skepticism (Score:2)
Posted on IBM (Score:2, Informative)
(http://zlogic.da.ru/)
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.
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.
Rails is nice, but definitely limited... (Score:1)
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..
Ruby limitations (Score:2)
(Last Journal: Sunday December 10 2006, @10:25AM)
CRUD screen secrets - Data Dictionaries (Score:1)
(http://www.geocities.com/tablizer | Last Journal: Saturday March 15 2003, @01:22PM)
* Data dictionaries
* Overridable event options as needed for stuff DD's don't do well or nitty exceptions to the rule.
* A good table browser to edit the DD's (something lacking in current web UI stuff).
I'll pit such against R-Rails any day. It is a lot quicker to fill out a table and inspect a table than to type in and verify code (at least for me). Coding nitty attributes is for people who like wrist injuries.
what about Phython, Perl, PHP frameworks? (Score:1)
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 [oreilly.com] , I wonder how they would compare then?
What about PHP? (Score:2)
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.
Ruby is slow (Score:4, Insightful)
(Last Journal: Tuesday October 30, @10:59AM)
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
just another tool (Score:1)
Easy one (Score:3, Funny)
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.
Talking out my ass... (Score:3, Insightful)
(http://www.sophiafieldphotography.com/)
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.
I thought the secret to Ruby on Rails' success was (Score:1)
(http://mistersanity.blogspot.com/ | Last Journal: Tuesday May 29, @04:42PM)
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.
Scaling... (Score:2)
(http://fak3r.com/)
http://fak3r.com/articles/2006/05/11/speed-up-rub
Hype (Score:2)
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.
Biggest downfall of rails is not even mentioned (Score:3, Informative)
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.
Hype, Fanboyism (Score:2)
(http://fforw.de/)
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 [turbogears.org] very much (especially the upcoming 0.9 release).
Tagging (Score:2)
(http://www.dutchvirtual.nl/ | Last Journal: Friday August 10, @07:04AM)
Ruby on Rails (Score:1)
If you like RoR, try TurboGears (Score:2)
(http://bityard.net/ | Last Journal: Thursday August 08 2002, @04:18PM)
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 [compoundthinking.com] 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 [turbogears.org], 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 [checkandshare.com], the built-in AJAX database editor can be enabled in your TurboGears app by inserting like two lines of code. Talk about sweet.
Easy Answer (Score:1)
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.
Re:Nice Summary. (Score:2, Funny)
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.
Ob. Simpsons quote: (Score:1, Troll)
(Last Journal: Monday June 05 2006, @10:46AM)
Re:Rails zealots aren't hammers, they're just tool (Score:4, Interesting)
(http://slashdot.org/)
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: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?
Re:Nice Summary. (Score:2)
(Last Journal: Sunday November 27 2005, @02:29PM)
Re:Nice Summary. (Score:1, Funny)
(http://www.cinetica.it/)
A slashdot editor that read TFA: priceless!
Re:Nice Summary. (Score:4, Funny)
Zealotry, or simply inexperience? (Score:4, Informative)
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.
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.
Re:Nice Summary. (Score:3, Insightful)
(Last Journal: Tuesday May 01 2007, @04:06PM)
Re:The parent is an honest complaint (Score:1)
Re:The parent is an honest complaint (Score:2)
(http://www.achacha.org/)