7 Reasons Ruby on Rails Sucks!

I'm going to have to admit I never thought I'd see trolling on WDF... But ok. Let's address these as if they're reasonable complaints rather than an incredibly obvious case of different tastes.

If you really dislike those, no one's really stopping you from renaming them... In fact, Ruby supports that quite happily. gsub isn't the best-named method, true, but then again I use that rarely, and it's one of relatively few such methods. In fact, it's probably one of the worst-named methods. puts isn't particularly hard to figure out (put string... Is it really that tough for you?). In the end, this is the unfortunate Perl influence dribbling in. Much of the Ruby API is better thought out anyway. For renaming them, by the way:

Code:

alias :println :puts
class String
  alias :replace_all :gsub
end

It's less typing and it's used relatively infrequently. Not to mention the fact that just about any language that wants to support functions as first-class objects with minimal typing has to resort to some sort of shortening (function(param1, param2) {} for anonymous functions in Javascript, anyone?). But wait, let's look at your wonderful proposed syntax:

Code:

5.times { as time ...

With separation between the parameters and the other stuff done how? Let's see the Smalltalk way:

Code:

5 times: [ :time | "..." ]

But don't worry, it's okay, when you get closures in Java you get this pretty thing:

Code:

5.times({ int time -> /* do whatever */ });

Oh how I look forward to it...

Plus if you know just about anything about inheritance, < makes perfect sense as an inheritance indicator.

Ah. You're one of those. i.e., those who speak without investigating. Try this on for size sometime:

Code:

5.times { puts 'test'; puts "Now I'm a separate command!" }

As it turns out, curly braces aren't for all command groups, they're for blocks (aka anonymous functions). And typically they're used for single-line blocks, with multiline blocks delimited by a [minicode]do..end[/minicode]. There's a more significant difference between {} and do..end (precedence), but it isn't relevant here.

In fact, the Ruby parser will let you break a statement over two lines if it's evident that the statement isn't over yet:

Code:

a_method_with_two_parameters 1,
   "another parameter"

You... Don't. Shorthands are for common cases, you don't introduce them for every special case in the world. That would be idiotic language design...

Not terribly ambiguous. If it's followed by a number, then it's either a float or invalid. Makes sense, since identifiers can't start with a number in just about any language.

Also, do you find yourself using naked floating point numbers in your code often? That tends to be bad practice, which is why Checkstyle tends to catch magic numbers like that in the Java world. Personally, I can't think of a single instance where I've sent a message to any literal floats.

... That isn't particularly confusing. You're sending the `times' message to the `3' object. The block is just another parameter...

Also? That's what you were doing above, as well. Everything in Ruby, as in Smalltalk, involves sending messages to objects. That *is* Ruby. That is the paradigm. You came to Ruby looking for Java, I think, and found something else and were surprised. Apparently you don't react well to surprise...

Umm... Yes. Welcome to the world of *actual* object oriented languages. You can go back to C if you want, but you seem to more or less like Java, where "Ruby sucks!" would also be an object... Yeah, overhead. If I were writing myself an ultra-optimized differential equation solver, that would be a problem.

In short, your distinction between values and objects is invalid in a language like Ruby, Smalltalk, or even Python.

This'll throw you for a loop, though, if that annoys you: nil is also an object -- a singleton instance of NilClass. You can even add methods to it if you want.

EDIT: A quick point I forgot to make. Language design is just about always a matter of preference. Ruby has definitely borrowed some nasty aspects from Perl, but they're gradually being phased out as it develops. The stupid one-letter globals are the best example, but there's already a package to make them full English names. As with any language, there are problems with Ruby. It just so happens that most of the things you mentioned weren't problems, they were results of your completely misunderstanding the very paradigm of the language. If you don't understand that, there's no way you're going to like the language. That's like saying ML's syntax looks like garbage before you've understood how pattern matching works and what exactly the syntax facilitates -- what paradigm it supports.

I have to admit I'm amused you think I haven't worked on larger projects, as I have... In fact, I've worked on a J2EE-based framework with a bunch of other people that was meant to be used by a bunch more other people. I don't dislike Java without having used it, I dislike it even though I program in it a fair amount

And yes, I'm very well aware of the potential for abuse in several of these features. This is why so many people feel liberated by Ruby, however: it puts trust in the programmer(s) that they know what they are doing, and that they know it well. This is a burden and a freedom we really aren't used to in the software world, because few languages put forth that trust. And yes, it's certainly dangerous in larger-scale projects where you have no guarantee that everyone is as good as you are. This is why you'll always hear me say that I don't like Java, but I know that it needs to exist in order to deal with the fact that not everyone is a good programmer. Java (more so than a lot of other languages, actually) is crippled intentionally -- things like the lack of operator overloading, for example -- for fear that it's `too dangerous'.

In the hands of a great programmer -- and there are many of them in the Ruby world -- Ruby can give you incredibly good results, because of all those features that make it `dangerous' and more. Placed in the hands of a poor programmer, it can give you disastrous results. But Matz (the creator of Ruby) decided that his philosophy would be to trust the programmer. After all, there are already plenty of other languages that don't.

Still, I should point out that the Ruby community in general puts a very large stress on readable code and on unit testing and on many other aspects of development that make it safer that often aren't stressed as heavily in other communities. Discipline is encouraged by the community, even if it isn't enforced by the language. The fact that three different levels of testing are included in Rails should be some testament to that.

If you're looking for another language that gives you nearly all the flexibility of Ruby and has the same `if you're a poor programmer, you can really mess things up' characteristic, but that hasn't been well used (i.e., used with discipline) until very recently, look at Javascript.

The biggest problem with this post is the title is incorrect! None of your complaints have anything to do with ruby on rails, everything you mention (be it wrong or right) is specific to ruby syntax, none of which has anything to do with ruby on rails in the slightest.

Your argument is equivalent to saying CakePHP sucks, and then proceeding to list a number of gripes you have with PHP syntax. The solution however is very simple, if you don't like ruby syntax, don't use ruby

I am going to come down on smoseley side here. This is just my opinion, but this quote of shadowfiend highlights why I don't even want to get into the depths of Ruby.

It reminds me of PERL. You can be so incredibly clever in PERL. But I have found that I end up being the person who has to come back to the code a year later and figure out whats going on.

Personally, I don't want a language to be clever. I don't want it to be liberating. I just want it to be simple! Symbols, redifining things, ambigious line endings. It reminds me of all the things I don't like about PERL.

It is just personal opinion of course; a matter of taste.

I rarely meet a coder who is happy working on another person's code. Everyone seems to like to rewrite things.

Slashdot recently linked a blog post about why Ruby will push Java to die of old age. It seems relevant to this discussion.
http://littletutorials.com/2008/05/28/13-reasons-java-die-old-age/

The last thing you will hear me argue is that Ruby is a silver bullet. I've picked up a couple of languages since Ruby, in fact, and I have no intent of stopping.

Your fears of Perlisms are, of course, quite justified -- this is indeed a danger of Ruby. But as I pointed out, the truly fascinating thing about Ruby is the community that has developed around it -- community which has gone to great lengths to integrate testing into their process (see autotest), to play with new ideas around testing (see rspec), to develop frameworks with testing baked in (see Rails), a community which does not hesitate to start anew if they feel something is getting too clever (see the motivations for the creation of merb). When you read books and blog posts (those of prominent bloggers, at least), you find pragmatism and maintainability is often at the core of their development. Ruby allows you to reach for readability and actually get close (not something specific to Ruby, mind you -- Python, amongst others, also does quite well in this domain).

The few posts I've made on my blog about Ruby have, amusingly enough, actually been about getting clever with the code. But I've tended to emphasize that my explorations were more for entertainment than for anything else.

Ruby can be dangerous, yes, but the community guides you towards avoiding most of the truly dangerous aspects, and it seems to be developing continuously away from the dangerous things.

I know very little about Ruby, having downloaded a PDF tutorial at one stage but having never had the time to peruse it... but what I would say is that aliasing commands etc. doesn't necessarily make things harder or less intuitive: it's all about ensuring that there's adequate documentation.

Those who've used Oracle's PL/SQL may have heard of an industry "guru" called Steven Feuerstein... I went to one of his seminars many years ago which advocated hiding the actual database design behind functions, enabling you to change the entire database design whilst leaving the application itself alone.

Steven's typical PL/SQL code might, therefore, be something akin to...

Code:

IF customerVerified AND ageAcceptable AND noPreviousClaims
THEN
      issuePolicy;
ELSE
      declinePolicy;
END IF;

His argument was also that any PL/SQL developer could be taken on and become productive straight away because they didn't need to know anything about the database design, simply the business rules which could be in a reference manual.

Sean

I think the tool, in this case the language of ruby, is irrelevant. Its possible to write bad code in any language, it's also easy to pick holes in any language given some knowledge.

Sure some languages may make it easier to write bad code but I don't see that as a fault of the language, its a fault of the bad programmer who doesn't know when they are writing bad code. Its the job of the programmer to understand the language they are using and know how to use it well while avoiding any of the pitfalls of the language.

The thing about ruby is that it's much more like free-form poetry. There's few rules, endless options and relies on the creativity and intelligence of the author. Much of what makes ruby an amazing language is the ease of creating DSLs and the ease of metaprogramming. RSpec (a testing framework) is a great example of how the language can be transformed to your needs:

Code:

describe User do
  define_models

  it "should disable an account" do
    users(:default).disable!
    users(:default).reload.should be_disabled
  end
  
  it "should enable an account" do
    users(:disabled).enable!
    users(:disabled).reload.should_not be_disabled
  end

end

I've worked with a lot of development teams using .NET, J2EE, ColdFusion, PHP, and Ruby. From my experience, Ruby is a horrible choice for firms that hire less-than-the-best programmers. Mostly because it's so easy to go sour. J2EE and .NET are far better choices for this since it forces you to do things very explicitly (at the cost of productivity & creativity). However, in the hands of talented programmers, Ruby is like gold. Beautiful code can be written quickly and practically bug-free in comparison to "average" development teams using other langauges.

Also... Rails is not ruby. Not at all

Rails!...what a f**king JOKE!

I wholeheartedly agree with the original post.
Rails has got to be one of the STUPIDIST frameworks I have ever encountered all of in my 20 yrs of being programmer! The framework syntax is so F'n lame.

But if the syntax in Rails isn't bad enough, try piling on even more to the already stenchy sh*t pile with freaking Hobo! Are you F'n serious!? Like the piece of sh*t framework wasn't already stupid/cryptic enough? No!!! Now we're going to make it even LESS readable with the use of the Hobo syntax and that absolutely HIDEOUS excuse for a markup language they call F'n DRYML!

I'm honestly convinced that those that call themselves developers and actually cling to the fat rolls around the already bloated waistline known as Rails needs a serious lesson in what programming REALLY is!

I can't rant enough about how much I find this Rails to be the most ridiculous excuse for a framework in the history of programming! Absolutely F'n bullsh*t! And I will gladly & proudly tell that lame a** author of Rails, David Heiny-lick Hans-full-of-sh*t-son, straight to his equally bloated egotistical face!

I couldn't agree more with this remark. Ruby is a language. Rails is a lame a** FRAMEWORK! Get it straight people!

As much as I find Rails to be a total waste of time, Ruby is a great language.

I am just wondering if you wanted a serious discussion or just wanted a rant full of cussing.

Rails is far from cryptic as it's one of the easiest frameworks I've ever used. I have a feeling that you looked a one quick video tutorial, and made some bad conclusions. That 15 minute blog screencast is not the best resource out there, and severely outdated.

I have doubts that you been programming for 20 years, because I have seen real messy code, and rails is very clean compare to a great deal of code I had to sniff through. jQuery has some of the messy code I seen, especially the code you will have to type to use it. However, it's a necessary evil because typing out normal javascript is hell.

Who knows. I was more responding to the comment about being "cryptic." I brought up jQuery because I had write code that made no sense at all and had to intentionally break parts of code in unnatural ways. And trust me, I looked for ways to type cleaner code without just not using jQuery at all.

Besides, those original comments was during Rails 1.x which is extremely different from 2.x, which is also extremely different from rails 3.0. Hell, Rails 3.1 was a rather big jump from 3.0, especially when it comes to organization with the new assets pipeline.

I was just making a comment towards Rik Davis because he made a recent post. Otherwise, arguing in this thread would be pointless due to being extremely outdated.

I have some news for you. I work at an agency where at least 30-50% of or web clients have Rails apps. So, be careful about your "assumptions" before you put your foot in your mouth like you just did.

Secondly, don't even think about trying to downplay my 20 years of experience in favor of your obvious favoritism of Rails. I have had to spend far too much time trying to debug Rails code and trying to fix these ridiculous applications to have some fly-by-night comment like yours come along and try to make my claims out to be based on some screencasts or tutorials.

First of all, any framework that locks a developer into very rigid coding "conventions" (as Rails claims so ridiculously to be bound to), is already a step in the wrong direction. A framework should allow a developer to be able to work at very atomic levels if they desire.

Next, is the fact that Rails really shines at being one of the most hideous frameworks out there in that just when you learn one version of it, they create a new version that pretty much kicks the developer into a new learning curve. Sound familiar? It should, Microsh*t has been guilty of this since day one with their stinking .NET framework.

Finally, there's the wonderful issue of the fact that if you need to get a development environment built to try to work on a client's application, there's the totally wonderful balancing act and countless hours one has to spend trying to make endless gems all play nice together. And you call this framework, "EASY"?! Really?! When a framework causes a developer to waste more time trying to set up a dev environment because the framework is so freaking fragile that it will break just because some stinking gem blows everything to hell, then it's time that you re-examine the definition of the word "easy".

I'm sorry if I sound harsh, but if you think Rails is the "easiest frameworks I've ever used", then I'll make the unfounded "assumption" that you're obviously a newb programmer that's latched onto the new Rails fad only because you probably subscribe to the "you're not a programmer if you're not using Rails" mentality.

Doesn't feel very pleasant when someone bashes you with absolutely nothing to back it up with, does it?

And something else I'll add for the sake of proving that my biased opinion isn't just limited to Rails. Equally, a framework that I find just as hideous as Rails is PHPCake. Yet another fine example of a framework that I give just as much negative opinion about as Rails.

I love Ruby...despise Rails. I love PHP...hate PHPCake. Love perl...not fond of Catalyst.

Well, my initial doubt about your 20 years of experience was party because of your language from the first post. It reminds me of all the 15 year olds from the days I use to surf through gaming forums.

As for "you're not a programmer if you're not using Rails" I have never heard this saying myself. I would join you, and say that statement is absurdly ridiculousness. I would also admit that Rails does kick the developers the curve with each major release. No way in hell I could make an app in Rails 1.x, and I already forgotten much of Rails 2.x. But it seems like that jump isn't going to be as dramatic with Rails 4.0 compare to previous versions.

I still stand by that Rails is one of the easier frameworks, but it's not a one size fits all framework. It's ideology of convention over conversion is the main reason for this. It's a framework that handholds you through out development, but as soon as you step out, hell could break loose depending on which area you want to step out.

If you are building a blog website, with maybe a video upload feature and some forums, I think Rails would be just fine. An Amazon type website could also nicely fit. But if you are working on a website outside of conventions, such as Google Maps, Google Docs and Facebook to some degree, you should be using a different platform. I am middle of learning Sinatra right now because of this.

I never worked on someone else's rails app, so I can't comment in that area at all.

Maybe I am just didn't try the best frameworks out there, because you downplay all the other fameworks I tried out, such as Cakephp and Catalyst. I guess you would also hate Django.

Just curious, what are your favourite frameworks?

And well addressed too, thanks. You make it sound as if I might even understand RoR... given time.