Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×

What's the Secret Sauce in Ruby on Rails? 414

Posted by CmdrTaco 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? More

What's the Secret Sauce in Ruby on Rails?

Comments Filter:

  • A question... (Score:2, Insightful)

    by $1uck ( 710826 )
    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.
    • You've been looking only at the 'V' part of it all. Some people put things in V that belong in M or C. That's not Rails' fault.

    • Re:A question... (Score:5, Informative)

      by masklinn ( 823351 ) <slashdot.org@mas ... n.net minus city> on Sunday May 14, 2006 @10:42AM (#15329640)

      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)

      • Re:A question... (Score:3, Interesting)

        by $1uck ( 710826 )
        I should've figured as much before posting. I've just heard so much about RoR being the greatest thing since sliced bread. I really haven't been exposed to it, until I started looking into using AJAX for work (doing .NET and Java). When I saw some code and it reminded me of old ASP and JSP + Scriplets, I was just shocked.

        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

      • Re:A question... (Score:2, Informative)

        by FuzzzyLogik ( 592766 )
        You can use a lot of different templating languages here. A few off hand... Liquid [leetsoft.com] Markaby [hobix.com] You can write your own in fact. There's actually two that come in Rails, Builder for creating xml files (rxml) and the other you normally see for building html pages (rhtml suffix)

  • It's Ruby (Score:3, Insightful)

    by LABob ( 870126 ) on Sunday May 14, 2006 @10:44AM (#15329646)
    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.
    • It's by far the most flexible language I've ever used. It allows programmers to modify the most fundmental aspects of the language.

      I guess you will love LISP macros.
      • I feel that most languages these days can be divided into two categories; cheap imitations of LISP, and cheap imitations of Smalltalk. From what I've seen of Ruby, it's Smalltalk Lite with less nice syntax.

        I put the blame for this squarely on the shoulders of modern computer science degree schemes. It seems possible to get a degree in this field without encountering either language. People graduate thinking languages like Java and C are the state of the art, and then go on to re-invent concepts from t

        • 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.

          Changing subjects, one of *my* favorite "cheap Lisp imitations" (it's Lisp, not LISP) is Tcl:

          http://antirez.com/articoli/tclmisunderstood.html [antirez.com]

          which is in some ways more flexible th

  • It's multiparadigm. (Score:2, Informative)

    by Anonymous Coward
    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.

    • It draws the best from the OO world of Smalltalk, while also offering very solid functional features.

      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
      • In fact, every time I look at Ruby, all I see is a pale reflection of Smalltalk.

        Yep. I mean, it's a nice little language. Surely preferable to things like Perl or Python, but it's not particularly special. Most of the features that everyone seems to love about it are done much better in languages like Smalltalk and OCaml, but those languages just haven't been given the Nifty! label like Ruby and Python have.

        But people see thing like 3.times do |blah| something with blah end and get a little swoony.

      • Re:It's multiparadigm. (Score:5, Insightful)

        by rossifer ( 581396 ) on Sunday May 14, 2006 @07:06PM (#15331519) Journal
        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.

        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. .jar files (and the variations on that theme: .war, .ear, etc.) can package up lots of different things, and as long as people know what VM version to run it on, they're good.

        Regards,
        Ross

  • Relentlessly applying best practices (Score:5, Informative)

    by Scarblac ( 122480 ) <slashdot@gerlich.nl> on Sunday May 14, 2006 @10:48AM (#15329661) Homepage

    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.

    • 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

      Am I the only one who was reminded of Ajax at this point? Old technologies put together, lots of hype...

      • Re:Relentlessly applying best practices (Score:4, Interesting)

        by aldheorte ( 162967 ) on Sunday May 14, 2006 @01:36PM (#15330329)
        Yes as to hype, no as to technical merit.

        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)

          by I Like Pudding ( 323363 ) on Sunday May 14, 2006 @05:10PM (#15331131)
          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)

          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?
    • Nowdays one can use annotations in Java to replace almost all XML configuration files.

      Frankly, I don't see why Ruby is superior to Tapestry+Hibernate.
    • Everybody knows testing is essential, but I hadn't seen it integrated into a web framework so well before

      Zope encourages automated testing strongly ... too bad the rest of the thing is the titanic.

    • Re:Relentlessly applying best practices (Score:5, Interesting)

      by Decaff ( 42676 ) on Sunday May 14, 2006 @12:55PM (#15330159)
      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.

      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)

    by Bazman ( 4849 )
    Python programmers can get the same kind of experience without learning a new languge with Django [djangoproject.com]. 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?

    • That or TurboGears. (Score:5, Insightful)

      by cduffy ( 652 ) <charles+slashdot@dyfis.net> on Sunday May 14, 2006 @11:11AM (#15329721)

      (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:

      • Rails and Django are very tightly integrated -- whereas with TurboGears the toolkit is loose enough that one can easily pull just one piece out for a project which doesn't need the framework as a whole. Our department does a lot of small and varied projects (many of which aren't webapps but which still could use an XML-based template engine or a simple OR mapper or a simple servlet-like API for handling requests independent of any content generation), so this was important to us.
      • We have more people in-house who know Python than Ruby.
      • TurboGears appears to be under more active development than Django.

      The opposing reasons:

      • Django and Rails have more high-volume production sites using them.
      • The OR mapper used by TurboGears, SQLObject, lacks some functionality and useful design attributes provided by others. This doesn't impact us for our little in-house projects, and is less relevant now that TurboGears 0.9 is adding support for using SQLAlchemy as an alternative to SQLObject.

      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.

      • 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'...

  • Porn, and the consequences thereof, is the 'secret sauce' of Ruby on Rails.

    Those crazy open source programmers.
  • perl -we 'print "0 but true" ? 0+"0 but true" : "nope";'
    0
    • Well with your weird example, here is what I would use (not really because it violates lots of say what you mean rules).

      ruby -e 'puts 0 ? 0 : "not zero"'

      Have to take out the warnings because you are doing something weird. You do know that ONLY false, 1, and nil derive to a failing condition right?

      I like perl too, but your example isn't hard to come up with an equivalent. If you mean ruby can't do as many one liners from the command line, you are wrong there too.

      Anyway I need food.

  • What Java can learn from RoR (Score:3, Interesting)

    by tunabomber ( 259585 ) on Sunday May 14, 2006 @11:11AM (#15329720) Homepage
    From TFA:
    • Enable hot deploy where it will shorten the development feedback loop or support frameworks that enable hot deploy. This priority should be much higher on the Java side than it is now.

    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.

    • Use less XML and more convention. Conventions don't rule out configuration because you can use conventions to specify meaningful defaults and configuration to override convention. Using this approach, as Rails does, you get the best of both worlds: concise code with less repetition without sacrificing flexibility.

    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.

    • Work to incorporate more scripting languages, including BeanShell (see Resources), for exploring Java classes during the debugging process.

    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)

      by CastrTroy ( 595695 ) on Sunday May 14, 2006 @11:37AM (#15329799)
      That's one of the biggest things going against Java for the casual developer market too. Most shared hosts don't support Java for this very reason. You can't have users bringing down the server every time they need to update their code. This is probably the biggest reason why PHP is still as popular as it is. It's where a lot of developers get their start. I would love to use Java for my web development uses, but I'm not about to spend the money necessary to have web hosting that supports Java. I've also heard that there's some shared hosting companies that support Java, but they restart the server every night in order to accomodate this.
  • My problem with this Ruby on Rails paradigm is that I have faled to find a single package that will install on either windows or Linux. On both systems I have encountered dependencies and errors that I have failed to solve.

    Could it be that case that I have not found it yet but it exixts? Point me to the URL.

    • 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.
    • 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 [sgtpepper.net] unstable/
      deb-src http://www.sgtpepper.net/hyspro/deb [sgtpepper.net] 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 "

  • The secret sauce is ... (Score:3, Interesting)

    by Anonymous Coward on Sunday May 14, 2006 @11:20AM (#15329746)
    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.

  • Rabid IP Hoarders and their Sauces (Score:4, Insightful)

    by nead ( 258866 ) on Sunday May 14, 2006 @11:35AM (#15329788) Homepage
    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.

  • Podcast with Author Bruce Tate (Score:3, Interesting)

    by muchawi ( 124898 ) on Sunday May 14, 2006 @11:41AM (#15329810) Homepage
    SHAMELESS PLUG:

    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)

    by BorgCopyeditor ( 590345 ) on Sunday May 14, 2006 @11:42AM (#15329815)
    Farnsworth: Hmm. Let me see that vial, Bender. [He takes it and puts it in a microwave-like machine. A readout prints and he looks at it and gasps.] Good Lord! According to the spectrolizer, Spargle's magic ingredient was ... water. Ordinary water!

    [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.

  • 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:


    link_to :id => 'add user', :class => 'shiny button', :action => 'add_user'

    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)

      by killjoe ( 766577 ) on Sunday May 14, 2006 @04:09PM (#15330849)
      What's great about rails? Well other people have talked about it, basically it encourages good software practices. Test first, DRY, MVC etc.

      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.
    • I think a lot of the benefits of RoR mentioned in the article can be achieved with a good IDE like IntelliJ.

      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 pa

  • Still no Unicode (Score:5, Informative)

    by shutdown -p now ( 807394 ) on Sunday May 14, 2006 @11:58AM (#15329882) Journal
    The biggest problem with Ruby - and, by extension, Rails - in my book is almost complete lack of Unicode support. See for yourself [rubyonrails.com]:
    Please note that right now Rails basically knows nothing about Unicode and pretends everything is just bytes. It means that validates_length_of for multibyte characters will trigger errors at the wrong places, various kinds of Unicode whitespaces are not going to get trimmed and sometimes Rails will cut right into your characters. Absolute most of Rails internals makes no notion that multibyte text even exists, Rails just delegates all to the Ruby string handling code (which in current Ruby is all single-byte).

    This is being looked at, but in the meantime you use UTF8 encoded strings at your own risk and you can expect (and wil get) bugs and problems.

    It might not look like a big deal to English-speaking people, maybe also for Western Europe (they can usually get away with Latin-1). But the rest of us do need it... that, or going back to multiple charset/encoding hell.

    So, for now, it's Java or Python, and associated frameworks for me. But not RoR.

    • It might not look like a big deal to English-speaking people, maybe also for Western Europe (they can usually get away with Latin-1). But the rest of us do need it... that, or going back to multiple charset/encoding hell.

      That's pretty ironic given that ruby was developed by Japanese developers. I wonder what they did to deal with japanese characters.

      • Re:Still no Unicode (Score:5, Interesting)

        by Dom2 ( 838 ) on Sunday May 14, 2006 @01:04PM (#15330190) Homepage
        That's pretty ironic given that ruby was developed by Japanese developers. I wonder what they did to deal with japanese characters.
        There's a well-known dislike of Unicode in Japan. They mostly use other character encoding schemes, such as SJIS. For more information on how to use UTF-8 in Rails so far, see HowToUseUnicodeStrings [rubyonrails.com] on the rails wiki.

        -Dom

      • There's a lot of people in Asia who are very anti-Unicode and pro-wierd local encodings. Counter-intuitive to the western developer who uses Unicode for supporting Asian languages. I don't really get it either.
  • 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.
    • 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
  • 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
  • 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 [janiry.com] for C++ and Java, as a hint of what I'd be looking for.

    Is there anything good out there online? :-)
  • 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 tabl

  • Posted on IBM (Score:2, Informative)

    by zlogic ( 892404 )
    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.

    • Re:Posted on IBM (Score:3, Insightful)

      by misleb ( 129952 )
      Umm, TFA was actually making a good case for Ruby on Rails. So if they are being biased, it is in the opposite way that you would expect given IBM's interest in Java.

      -matthew

  • Ruby is slow (Score:4, Insightful)

    by SanityInAnarchy ( 655584 ) <ninja@slaphack.com> on Sunday May 14, 2006 @03:59PM (#15330816) Journal
    When it comes to Ruby, I have one wish:

    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 .net environment. Performance comparable to C#, developer time comparable to normal Ruby, bytecode obfuscated enough to use in commercial products.

    But that's depressing, too, because in the amount of time it would take me to learn enough about Ruby and .net to do that, not to mention the programming of that insane compiler, I could write hundreds of useful Ruby programs.

  • Easy one (Score:3, Funny)

    by arodland ( 127775 ) on Sunday May 14, 2006 @06:57PM (#15331491)
    The secret sauce is "Hype". And if you lift the bun, you find that there's more secret sauce than meat.

  • 5 to 10x more productive than Java? (Score:3, Insightful)

    by Anonymous Coward on Sunday May 14, 2006 @07:06PM (#15331516)
    If you know java, I simply find that hard to believe. If you don't know it, maybe you've taken a class, read some books on JSP, you "can write it." It starts to be more reasonable. There might be some O(1) type operations like the initial setup that can be done in Rails in a hour vs. the full work day for Java or something like that but very little in terms of actual production.


    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)

    by localman ( 111171 ) on Sunday May 14, 2006 @07:17PM (#15331557) Homepage
    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.

  • Biggest downfall of rails is not even mentioned (Score:3, Informative)

    by Jondo ( 693238 ) on Monday May 15, 2006 @03:37AM (#15333031)
    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.

Slashdot Top Deals

Function reject.

Close