Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Rails May Not Suck

timothy posted more than 6 years ago | from the isn't-the-question-whether-rails-suck dept.

Programming 160

KDan writes "With astonishing regularity, articles or posts come out claiming that the popular Ruby on Rails framework sucks in some way or another. People complain that Rails isn't as easy to deploy as PHP, that Rails just didn't do it for project XYZ. They range from the articulate and well thought out to the frankly inane and stupid (and wrong). Recently, there's also of course been the spectacular nuclear rant by Zed Shaw, which was more a rant against random elements of the community than against Rails, but was still presented as a rant against Rails. Here's an article that tries to put some perspective on why these opinions are irrelevant to whether or not Rails sucks."

cancel ×

160 comments

Sorry! There are no comments related to the filter you selected.

This just seems like nonsense. (4, Insightful)

morbiuswilters (604447) | more than 6 years ago | (#21991144)

I am not a RoR developer, but I don't think the language or framework sucks. I've actually adopted a few ideas from it, but I still work much more efficiently in PHP as that is what I am familiar with. I have lots of respect for the guys at 37 Signals and the Ruby developers and I imagine it must be tiresome hearing about how much your language sucks. Still, this article is just worthless. The first two points seem to be saying "Rails isn't really unsuitable for your project because it is free and nothing is really perfect anyway." Then there's the logical fallacy embedded in the statement "If Rails isn't right for your project, that doesn't mean that Rails sucks. It just means that your project isn't right for Rails." Sorry, if Rails isn't right for my project, then that means Rails isn't right for my project. It's like trying to shift the blame for inadequacy from the tool to the task. I'm not buying it. The author then goes on to state that Rails is only for "smart people" and then makes the baseless claim like "It's much harder to fake being a good Rails developer than it is to fake being a good PHP developer." At this point, he's lost me. Listen, folks, Rails is the right answer some of the time and it's the wrong answer some of the time. Just like any language. SQL, Javascript, PHP, Rails, C, Java: they all have things they are good at and things they are bad at. The author at least gets that part right, but then goes on to undermine it repeatedly. At the end of the day, articles like this only encourage the detractors and scare away the uninformed.

Re:This just seems like nonsense. (5, Informative)

nschubach (922175) | more than 6 years ago | (#21991254)

Let me summarize the wall of text ;)

Use the right tool, for the right job.

Re:This just seems like nonsense. (0, Redundant)

morbiuswilters (604447) | more than 6 years ago | (#21991354)

The 'Preview' button is sometimes the right tool and sometimes I even use it.

Re:This just seems like nonsense. (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#21992142)

You actually don't need a comma.

Re:This just seems like nonsense. (1)

Karl Harbour (1217102) | more than 6 years ago | (#21993304)

Use the right tool, for the right job.
Of course that's right, but it doesn't mean a given language/platform shouldn't learn lessons from others. In my opinion, PHP has been successful because of the ease of integration with Apache. If the same was true for Rails, it would become the right tool for a lot more jobs, I think.

Re:This just seems like nonsense. (2, Interesting)

abigor (540274) | more than 6 years ago | (#21993388)

Very true. Rails has deployment issues. See here, and especially read the comments: http://www.rubyinside.com/no-true-mod_ruby-is-damaging-rubys-viability-on-the-web-693.html [rubyinside.com]

Re:This just seems like nonsense. (1)

tcopeland (32225) | more than 6 years ago | (#21993504)

> Very true. Rails has deployment issues. See here,
> and especially read the comments:
> http://www.rubyinside.com/no-true-mod_ruby-is-damaging-rubys-viability-on-the-web-693.html [rubyinside.com] [rubyinside.com]

That was a good read, thanks for the pointer. Though as one fellow pointed out, Java seems to have survived the lack of a mod_java. And mod_proxy_balancer + mongrel seems to be doing the trick for most folks. You're right, good comment thread on that one... thanks.

Re:This just seems like nonsense. (1)

LizardKing (5245) | more than 6 years ago | (#21993652)

Java seems to have survived the lack of a mod_java

That's because Java web apps are typically deployed on a app container behind either Apache using mod_jk, or a firewall using port forwarding rules. Both methods allow the graceful restart of a web app the app. The first scenario avoids the need for a "mod_java", as Apache is just proxying requests. In the second scenario, you typically run the app container on Unix using an unprivileged port such as 8080, and use port forwarding from port 80.

Re:This just seems like nonsense. (2, Interesting)

CastrTroy (595695) | more than 6 years ago | (#21993770)

Has it really? I don't think that Java has survived the lack of mod_java. There are very few webhosts that offer Java. And when they do, it's usually quite more cumbersome to use than PHP, because in certain configurations it requires reboots of the server to get it to reload the code. I would love use Java over PHP for my web page, because the API is just so much more organized, and I prefer compiled languages. Also the Netbeans IDE (or even eclipse) is much better than anything I've found for PHP (yes I'm aware that PHP can be done in Eclipse, but the feature set sucks).

Re:This just seems like nonsense. (1)

tcopeland (32225) | more than 6 years ago | (#21994422)

> Has it really? I don't think that Java has survived the
> lack of mod_java. There are very few webhosts that
> offer Java. And when they do, it's usually quite more cumbersome to use than PHP

Hm, yup, very true, Java's not a really player in the shared hosting space. I guess I meant that there still seem to be plenty of web apps written in Java... just not in the DreamHost-type environment.

Re:This just seems like nonsense. (1)

CastrTroy (595695) | more than 6 years ago | (#21994782)

Yeah, it works better in the enterprise situation, because you are more likely to have your own server, or at least your own virtual server. However, I think that Java suffers a lot, because people can't use it for their little hobby projects. PHP is only so widespread because it's so easy for everyone to just tinker with. If PHP didn't have that, I don't think it would have gotten anywhere.

Rails Running On My Cellphone!!!! (1)

remitaylor (884490) | more than 6 years ago | (#21996082)

I tried running Ruby on Rails on my cellphone and, let me tell you ... it truly sucks monkey balls.

On the other hand ... I've been coding my latest web app in Assembly for *some time now*
It's taking a little longer than I (or the client) had initially anticipated, but it's very stable.

( If only I could figure out why I can't get AppleScript running on my Xbox!! )

Re:This just seems like nonsense. (0)

Anonymous Coward | more than 6 years ago | (#21991380)

I don't think the author is trying to shift the blame from the tool to the task, but rather enforce the point that developers approach this from one of two standpoints. Either they have a tool in mind they wish to use already (and often will try in vain to squeeze an inappropriate task into it), or they are pragmatic and framework agnostic and will choose the tools that are right for the job. It *does* work both ways. Hence, your task may not be suitable for rails, and/or rails may not be suitable for your task.

As for the comments about the 'smart' programmers. It's true that in order to full take advantage of Rails, you need to be pragmatic. Being pragmatic comes with experience, and learned knowledge (hence, smart). I believe this is a counter argument against comments that have been made on several blogs that blame Rails for making them write spaghetti code.

Re:This just seems like nonsense. (2, Informative)

morbiuswilters (604447) | more than 6 years ago | (#21991568)

I agree that developers often try to use the wrong tool for the job. However, I think statements like "your task may not be suitable for Rails" only reinforce that. It's implying that Rails is the goal and that kind of thinking contributes to so many awful technical decisions, for any language.

You need to be pragmatic and smart to get the most out of any language, framework or tool. Rails can't make you write spaghetti code and I'm sure many people who bash Rails didn't take the time to learn how to properly use the tool, but that still doesn't mean that Rails protects against stupidity any more than PHP does.

Re:This just seems like nonsense. (0)

Anonymous Coward | more than 6 years ago | (#21991978)

But that was my point; for many developers IS their goal. Reading through many blogs, a great deal of the people posting anti-rails troll material are doing exactly that - making Rails the goal, attempting to produce a predetermined task from it without first evaluating Rails (and technology x, technology y, etc) and then blaming Rails for their fruitless efforts. In this instance, "your task may not be suitable for Rails" is both accurate and fair.

Of course it's true that to get the best out of any tool you need to be pragmatic, however some tools are more forgiving than others. Rails is opinionated, and as such there are 'Rails ways' of doing things. Rails will not protect against stupidity, and in fact it's quite the opposite. If you ignore the 'Rails way' (for example if you manage associations and validations in your controllers), you will inevitably end up with spaghetti - but who's fault is that? Ruby/Rails is a mindset that differs from PHP, and those coming from PHP to Rails attempting to emulate their existing workflow will not enjoy the experience - flaming Rails in response is not entirely fair :-)

Re:This just seems like nonsense. (0)

Anonymous Coward | more than 6 years ago | (#21993516)

You know nothing! I hear Linus is going to rewrite the kernel using RoR. Ruby on Rails works for everything!!!

yes I am kidding

Why so defensive? Oh right, because it does suck (0)

Anonymous Coward | more than 6 years ago | (#21991170)

what does it matter what other think anyway, if rails works for you, keep using it, otherwise there's something else that will work. Thats whats so great about choices and having opinions.

Basically... (1)

snoyberg (787126) | more than 6 years ago | (#21991222)

Rails doesn't suck because {insert boiler plate reasons of why rants against any language/framework are wrong}. I think he's right, but there's not much really Rails-specific in the article. In fact, there's hardly even anything countering the criticisms he points out.

Submission may not suck. (2, Funny)

Aladrin (926209) | more than 6 years ago | (#21991240)

May not suck... Wow, such strong verbiage. How can you possibly defend such a rigid stance?

Next time you're trying to defend something, don't start from 'may not suck'. Try something a little more positive.

Re:Submission may not suck. (1)

KDan (90353) | more than 6 years ago | (#21991306)

Actually the submission had the title of the article, "Rails sucks?", which I thought was a bit more catching, but oh well.

Re:Submission may not suck. (1)

theNeophile (238938) | more than 6 years ago | (#21992748)

May not suck... Wow, such strong verbiage. How can you possibly defend such a rigid stance?

Next time you're trying to defend something, don't start from 'may not suck'. Try something a little more positive.
It's humorous understatement, which may not be all that horrible.

I don't get it (1)

corychristison (951993) | more than 6 years ago | (#21991244)

Yes, people need to stop complaining that it doesn't conform to their ideas and values and it's "different".

I don't know how many times it has to be reiterated: use the tool that suits your needs.

To the author of the article, live and let live. If you enjoy Rails, use it. If you want to experiment with other languages, go for it! Nobody is going to cast you out because you crave knowledge.

I use what I feel comfortable. I build do web design & development for a living. I feel comfortable in PHP as I can start from 0bytes to a full project with all of the problem solving logics coming from my own brain in PHP. I certainly don't rule other languages out, but I certainly am not as strong in them as in PHP.

No... I don't remember the point of this post. If you can figure it out, would you let me know?

Too Generic (5, Insightful)

roadkill_cr (1155149) | more than 6 years ago | (#21991250)

This guy's arguments are too generic for me. I don't personally use RoR, nor do I do web development, but I do program, and it seems to me that this guy's arguments can just as easily be applied to any free programming language:

1. (Programming language) owes you nothing
2. (Programming language) isn't perfect
3. (Programming language) isn't suited for all applications
4. (Programming language) isn't suited for all people

The only point he has that doesn't necessarily apply to all languages is:

5. Rails is extremely flexible

I take the first four points as being self-evident for any programming language. It's actually a good list for explaining why there are tons of different languages out there. The reasons stated in the article explain *how* Rails matches with the first four points, but don't really explain why that makes it objectively *does not suck*.

The fifth is the only one that seems to have any sort of Rails-specific content to it; and like I said before, I'm not a web dev so I can't comment on it's validity.

Ultimately, I think the message that can be gleaned is this: that like every other programming language in existence, it is good for some and bad for others.

Re:Too Generic (3, Interesting)

WaZiX (766733) | more than 6 years ago | (#21991404)

you got much further then me... I abandoned this passage;

In fact, there's no such thing as a perfect anything - whether in the world of computers or outside of it. Everything is imperfect. If you want perfect, then die. If the Christians are right, you might go to heaven and witness perfection. I wouldn't bet my life on it though.
How can anyone be taken seriously after such a remark?

Re:Too Generic (1)

Bluesman (104513) | more than 6 years ago | (#21991594)

I know! He oh so conveniently leaves out the part about Hell and how committing suicide is a sure way to get you there.

Fucker, I hope nobody listens to him and commits suicide, unless they're Styx fans.

Re:Too Generic (0)

Anonymous Coward | more than 6 years ago | (#21991962)

Yeah, I don't take people who claim you might go to a perfect heaven very seriously, either.

Re:Too Generic (2, Insightful)

n dot l (1099033) | more than 6 years ago | (#21992168)

Meh. I once saw a man state that the Christians are right and that they (and only they) will go to heaven and witness perfection. He said this several times, in fact. And more than a hundred people, all congregated around him, continued taking him seriously without any difficulty at all.

The fact that bullshit "arguments" like this pass in religious settings is to be expected. The fact that they pass in political settings is to be lamented.

People that think this crap will fly with a technical audience are to be ridiculed, mercilessly, until they either get a clue or fade away.

Re:Too Generic (0)

Anonymous Coward | more than 6 years ago | (#21992726)

why does it have to fly , get a grip and lighten up technical audience my a** superior people what nonsense intolerant antireligious bigotry

Re:Too Generic (1)

n dot l (1099033) | more than 6 years ago | (#21993190)

The parent said "How can anyone be taken seriously after such a remark?" I answered that question with a legitimate case where people are taken seriously after making far more extreme statements. I hope you didn't confuse a mildly sarcastic tone with, well, all the things you wrote.

The rest of my post attacks the use of emotion-based statements, as a substitute for arguments, in what should be logic-based debates. If you think I'm wrong and that tangential, irrational, and overly-emotional attacks do belong in political and technical discourse then say so clearly and back it up with some reasoning.

Bah, who am I kidding, you're just here to call me names. Tolerance indeed.

Re:Too Generic (1)

The One and Only (691315) | more than 6 years ago | (#21993636)

I think that was a joke. I think his point was that perfection is unattainable in the real world of computers and networking and Ruby on Rails.

Re:Too Generic (0)

Anonymous Coward | more than 6 years ago | (#21993910)

I think that was a joke.

Yep. Unfortunately, when the average Slashdotter reads anything about religion, the red mist comes down and he loses any capacity for humour, rational thought, tolerance of other people, etc, that he may have had.

Re:Too Generic (1)

OakDragon (885217) | more than 6 years ago | (#21994750)

Meh. I once saw a man state that the Christians are right and that they (and only they) will go to heaven and witness perfection. He said this several times, in fact. And more than a hundred people, all congregated around him, continued taking him seriously without any difficulty at all.

Was it Jesus?

Re:Too Generic (0)

Anonymous Coward | more than 6 years ago | (#21993238)

Tetris is perfect. I have witnessed Tetris. Does that mean I've died and am posting from Christian heaven?

Re:Too Generic (1)

Karl Harbour (1217102) | more than 6 years ago | (#21993198)

5. Rails is extremely flexible
That may or may not be true, what I do know though is that Rails does like to impose its way of doing things on you. Isn't one of their mantras, configuration by exception, or words to that effect? Comparing ActiveRecord to Hibernate, for example: ActiveRecord effectively mandates your primary keys, Hibernate is surely more flexible, albeit with a lot more XML/annotations...

Re:Too Generic (1)

VultureMN (116540) | more than 6 years ago | (#21993976)

It's Configuration by Convention; it makes certain assumptions.

And ActiveRecord does not mandate your primary key. If you don't like the default, you can easily change it.

The point of configuration by convention is that you don't have to manage a boatload of config files if you don't want to; all you need to do is follow the standard conventions. Again, however, you're not forced to do it that way if you don't want to.

I've used Hibernate in the past, and am using ActiveRecord now, so I've got a pretty good basis for comparison. ActiveRecord also requires some annoying configuration if you have to use an existing schema, but I've got the luxury of working on a Brand New Project right now. Wee!

(FWIW, the thing I don't like about AR is the lack of built-in support for foreign keys, but at least some clever folks have made plugins to support'em.)

Re:Too Generic (4, Insightful)

arevos (659374) | more than 6 years ago | (#21993836)

5. Rails is extremely flexible
I'm a Rails developer, and I have to say I disagree with this. When you work within Rail's comfort zone, it's a joy to develop in. But start to edge outside those boundaries, and suddenly everything starts to fall apart. A lot of things that could be made modular are currently hard coded, especially in the monolithic and huge ActiveRecord. Rails is designed to work well given certain conditions, but try to do anything clever or unusual, and it's a toss up whether you'll get away with it without running into problems.

Rails may be a nice framework, but flexible it ain't.

Re:Too Generic (1)

OakDragon (885217) | more than 6 years ago | (#21994774)

5. Rails is extremely flexible

The fifth is the only one that seems to have any sort of Rails-specific content to it...

And it's too general, still. It's like saying, "The Honda Element is a versatile automobile." Really? Maybe it is - what do you mean by versatile? Would you happen to know if there are some other automobiles that are versatile?

He convinced me that it does suck. (0)

Anonymous Coward | more than 6 years ago | (#21991346)

So to sum up: "yes, rails does suck in many ways, but if you are only interested in low use crud apps and static sites generated using rails, then its ok". Gee, how insightful, that's kinda what all the "rails sucks" people were saying in the first place isn't it?

Well... what definitely sucks is (-1, Troll)

Anonymous Coward | more than 6 years ago | (#21991492)

niggers

Ruby (4, Insightful)

Fallingcow (213461) | more than 6 years ago | (#21991578)

I'd never used RoR or even Ruby, but I was hearing a lot about it and I had a hobby project that I wanted to start on, so I bought an RoR book, and spent HOURS working on it. Then I gave up, having accomplished nothing, switched to Django (mind you, I'd never used Python before, either) and started getting stuff done.

(Well, a more full story is: I started with Ruby, switched to Django, realized my host doesn't support it, tried Ruby again [now I understood the framework better, from using Django, but the language still looked like Swahili], then moved to CakePHP which IS supported by my host, realized how much easier and less-fussy Django was, decided "to hell with my host, I'll get a new one if I ever decide to take this code live" and finally went with that.)

My hang up with RoR is the Ruby part. It's completely unreadable to me. Python, I could understand reasonably well before I even started reading any "learn Pythong" material. Same with most other languages. Any Ruby code beyond "hello world" and simple arithmetic looks like gibberish to me.

However! My first language was Perl. People often complain about how hard it is to read, and I instinctively bristle a bit when they do, because to me, it's the easiest language to read. The reason? Perl code tells a skilled Perl coder TONS about what it's doing and how, but confuses newbies like crazy. Ruby strikes me as being much the same way.

So, I understand why people who have taken the time to really learn it enjoy it so much, but for me it's so much easier to choose a framework that uses a "pick up and go" language like Python and be done with it. It does the same stuff, and I can get right to learning and working with the framework rather than dicking around with the underlying language.

I'm really not trying to pick on the RoR people, nor being petty (really!). I know it's a good framework, and I know that if I took the time to learn it I would like it just fine. Just getting a perspective out there that's not "rah rah, RoR is the best thing ever!" or "boo, RoR ran over my puppy!"

Re:Ruby (2, Funny)

Takichi (1053302) | more than 6 years ago | (#21991788)

Man, all these crazy names are hard to keep track of. At first I thought you tried and failed at Ruby, said "screw it" to the coding, and switched to spaghetti westerns. [wikipedia.org]

Re:Ruby (1)

bcdm (1031268) | more than 6 years ago | (#21994296)

And here was me thinking he had switched to jazz guitar. [wikipedia.org]

Re:Ruby (2, Interesting)

MenTaLguY (5483) | more than 6 years ago | (#21991914)

The Ruby versus Python thing has puzzled me for a while: most people who prefer Python over Ruby seem to find Ruby unreadable, whereas most people who prefer Ruby over Python can read Python okay but don't enjoy programming in it. Both camps seem to disagree about significant whitespace, but it doesn't really seem to be the fundamental issue.

Part of it may be Ruby's heavy reliance on higher-order functions. For a programmer with established habits it can be a problem in terms of the way you're accustomed to thinking about code. Imagine if Perl had special syntax for passing anonymous subs as arguments, and idiomatic Perl code used them for everything all the way down to most looping constructs...

Do you think that's the issue, or something else?

Re:Ruby (2, Insightful)

Just Some Guy (3352) | more than 6 years ago | (#21992422)

Do you think that's the issue, or something else?

OK, I'm not going to list ever language I've ever used or otherwise enter a bragging contest, but please just take me at face value when I say I've been around the block a few times. To me, Ruby "feels" like it's trying to be clever. I hate clever, not at first - no, it's fun when you're writing it! - but a year later when I have to maintain something.

Put another way: my wife isn't a programmer but she can read a lot of my Python code. I'm perfectly at home with C, Perl, and various assemblers but I can't make heads or tails of Ruby. Yeah, I know that familiarity and experience goes a long way toward fixing that ill, but since I already have Python, I just haven't felt the need to make the effort to learn Ruby.

Blame the programmer not the language (3, Insightful)

Unoti (731964) | more than 6 years ago | (#21993420)

A lot of Ruby tutorials do try to be overly clever. But really, quite a bit of C code was/is overly clever, also. People cramming so much stuff onto a single line that the code is unreadable and difficult to support.

But that's not really a problem in the language. That's a style thing. I very frequently when coding in C, Java, or C# split things onto multiple lines that could be expressed in a single line. I often take intermediate values and put them into variables with good names, instead of ramming the values all together.

I remember when I was a wee lad, learning C, and being utterly baffled by a lot of the code I read. Casting pointers to other things, doing math, switching to array notation, then suddenly treating the whole expression as a function pointer, and feeding a stream of other things as arguments into the function... That kind of thing is amusing, but has no place in typical production applications code. Something far more common is huge expressions with the ternary operator that are just one element in a more complex expression. I saw this kind of thing in most of the C code I read, and felt like I must be a noob if I didn't do that. Then one day I decided I just would write code that was simple and made sense, and that's what I do-- it's a style choice.

The point is, writing code that's easy to understand is up to the programmer, and less to the language. People used to defend COBOL because it was more readable. But one huge problem with COBOL is you've gotta write a lot of lines of drivel to get anything done, compared to say C. The price we pay for the comparative expressiveness of C is we have to be more careful with the code to keep it understandable. From C to Ruby is a similar jump in expressiveness, with a commensurate risk of it being less understandable. But it's possible to write difficult to understand code in any language.

Ruby does have some things in it that make it quite different from other languages, most notably closures and metaprogramming. But honest, you do get used to it. You can even avoid the elements you're not comfortable with, and ease into them later.

But over time you start to find there's quick and dirty ways of doing things in very few lines of code in Ruby. And things like testing kits and the way Rails helps you structure your code make it so that your code is spread out nicely, and it's easy to isolate bugs quickly, even if some of your code is a little overly terse.

I recommend not starting with Rails. Spend a few hours alone with Ruby before trying to wrap your head around the way Rails works. Write a tic tac toe program on the console, or something. Get to where you've made peace with Ruby before you get into rails.

Because starting off directly with Rails and Ruby, not understanding either one can be very difficult. They are both such different approaches from what many developers are used to that it's a bit like learning Pig Latin and Chinese at the same time.

Re:Ruby (1, Informative)

I Like Pudding (323363) | more than 6 years ago | (#21993482)

Imagine if Perl had special syntax for passing anonymous subs as arguments, and idiomatic Perl code used them for everything all the way down to most looping constructs...

HMMMMMM...

@sorted = map { $_->[0] }
          sort { $a->[1] cmp $b->[1] }
          map { [$_, foo($_)] }
          @unsorted;
Now back to work with you! I want a ruby runtime that doesn't suck already.

Re:Ruby (1)

MenTaLguY (5483) | more than 6 years ago | (#21993608)

That doesn't count because the syntax is a special case just for those functions. :)

But ... yes ... back to the Ruby hacking...

Re:Ruby (1)

LWATCDR (28044) | more than 6 years ago | (#21991974)

Well I think it goes a lot like this.
1. Rails doesn't scale for me.
2. Rails didn't make me a great programmer.
3. Rails didn't make my hard task easy.
A lot of it seems like they are upset that Rails wasn't magic.
The problem with Rails is that I don't think it can live up to the hype. It sounds like a very good framework but people seem to think it is little short of magic. Kind of like XML , OOP, and 4GLs. They are not they are just tools and like every tool they have their good and bad points.
Not everybody likes every tool. I have written Perl but I don't like it. I have written PHP and I don't like it a lot. I have written in Java and I do kind of like it. I have written in c++ and it was okay.
How you feel about a language all depends on where you are at that time and what you are using it for. The same goes with frameworks.

Re:Ruby (0)

Anonymous Coward | more than 6 years ago | (#21992324)

dude.

Ruby looks like gibberish..?? You've just told the world that you've never looked at it.

Diagnostic messages.. well yes.. totally different story there.

Re:Ruby (1)

Unoti (731964) | more than 6 years ago | (#21993518)

Ruby looks like gibberish..?? You've just told the world that you've never looked at it.
Here's some Ruby code.

def self.style(*args)
[self::WidgetClassName, *(args.map!{|a| _get_eval_string(a)})].join('.')
end

Looks a little jibberishy, honestly. But as I ranted about elsewhere, it's up to the programmer to make the code clear when it needs to be. It depends on who your audience is for reading the code. If they can handle stuff like that above, then great. But if it's gonna baffle them, then consider making it easier to understand.

It's up for argument, perhaps, but I wouldn't dismiss GP's claim that Ruby can look like jibberish. Much of the Ruby code people wave about in Ruby is overly black magick-y for my taste.

Re:Ruby (4, Insightful)

Fweeky (41046) | more than 6 years ago | (#21993776)

Ruby code beyond "hello world" and simple arithmetic looks like gibberish to me.
Ruby looked like gibberish to me, too. Coming from ARexx (heh) and PHP, with a bit of C etc, seeing:

%w{foo bar}.map {|e| e.upcase }
Simply didn't mean anything to me; map? What are those {}'s doing? What's |e|? What the fuck's %w{}?! It's bit of a triple-whammy really; first you've got a bit of perlish shorthand (%w{foo bar} == ['foo', 'bar']; make an array containing these words), second you've got a code block with slightly Smalltalkish parameter syntax, and third you've got an unfamiliar verb "map".

But you're right, once you actually grasp some of the concepts (and if you don't know about things like map/select/reject/inject (reduce), you really fucking should, I don't care what language you use) and the basics of the syntax, it all just flows; make an array, make a new array from it by running the upcase method on each element, just like:

array_map('strtoupper', array('foo','bar'));
Only it doesn't fall to bits when you want to do non-trivial things to the elements. After that, it's mostly getting familiar with what the other methods do and getting used to using/chaining them. If it doesn't go from confusing to obvious or even useful outside Ruby in an hour or two, you're probably doing it wrong.

Similarly when it comes to things like metaprogramming; it starts off confusing and ends up being a force multiplier for your work. The confusion hopefully means you're learning something new, and you don't become a better programmer by running away from that.

Re:Ruby (1)

bockelboy (824282) | more than 6 years ago | (#21994886)

I don't claim to read Ruby, but are you saying that it's just running uppercase on each element of the array? A = ['a', 'b', 'c'] B = [entry.upper() for entry in A] Ta-Da!

Re:Ruby (1)

Fweeky (41046) | more than 6 years ago | (#21995400)

Yes, pretty much, but the general idiom is the ability to easily pass blocks of code to methods; the common use of map/select/reduce-style transformations on enumerations is just one of the results. e.g. you could write map like so:

module Enumerable # included in most things that respond to each()
  def mymap
    raise ArgumentError, "No block given" unless block_given?
    a = []
    for item in self # equivilent to self.each do |item|
      a << yield(item)
    end
    return a
  end
end
Obviously the general ability shown here allows for a lot more than just operations on lists; they're used for event handlers, resource management (e.g. open a file at the top of the method, pass it to the block, ensure you close it afterwards), logging, exception handling, etc. You can do much the same in many other languages, but you end up writing "lambda" everywhere and it's not considered very idiomatic.

Smalltalk goes one step further with this concept: even "if" is just a method on a Boolean object, with blocks passed as named arguments ifTrue and ifFalse.

Re:Ruby (1)

Fallingcow (213461) | more than 6 years ago | (#21995440)

I'm pretty sure that my problem was trying primarily to learn the framework, and to learn the language only as necessary. Similar strategies taught me PHP to a fairly high level of proficiency, and it really worked with Django/Python (at this point, in fact, I'd say that I know more Django than I do Python, if that makes sense, but my lack of Python knowledge has only rarely hindered my use of Django)

With RoR, though, all I accomplished was to confuse myself on what should have been an easy-to-grasp topic (Rails) and to fail miserably to learn any Ruby at all. I'm thinking that this will be one of those languages where I'll actually have to buy a book or two on the basics, and really read them (there's my one real, actual complaint about the language: there's a lot of "how-to" material online, but its coverage of the topic is spotty, and 90% of it is "how to write Hello World", so you have to wade through a bunch of shit so that you can maybe, maybe find something sort of like what you actually wanted to know. PHP, Python, Perl, etc., all wipe the floor with it in terms of online documentation and support)

Re:Ruby (1)

Cthefuture (665326) | more than 6 years ago | (#21995040)

Python, I could understand reasonably well before I even started reading any "learn Pythong" material.
Just a quick observation. I have noticed lots of people mistype Python as Pythong. I do it nearly every single time I type out the whole name. Why is that? It must be something about the pattern of letters or something. Anyone have any ideas?

Re:Ruby (1)

Fallingcow (213461) | more than 6 years ago | (#21996276)

Yeah, I caught that AFTER I previewed.

I think it's a combination of:

several other common words with that combo ending in "g" (long, wrong, song, thong, bong, etc.)

and, if you type the way I do, the left index finger naturally hangs between the "t" and "g" after hitting the "t" in "Python", so it's poised to make that stroke.

Re:Ruby (1)

bitingduck (810730) | more than 6 years ago | (#21995724)

I came to RoR relatively from scratch-- there was some web stuff with a database backend that I wanted to do and I hadn't done much programming in a while, and no web programming at all. I've done a *lot* of C and Pascal (and even a little Forth. ick) for data acquisition and analysis, but hadn't done any web stuff. I looked at a bunch of different things and went through some decent books to learn various new things. Coming at it almost completely from scratch I ended up liking RoR quite a lot and found it very easy to figure out how to do what I needed to do and have the development be manageable, since it was all in my spare time.

A summary of my probably poorly informed opinions in sort of chronological order:
C++: I took a look at it years ago but didn't have much I needed to do with it, and felt like it made it easy to obscure Really Bad Things (TM) so I didn't really consider it for this project.

Java: initially seemed to be a likely choice, since I wanted to do a database backed web app that was fed by a bit of spidering. I went through the better part of what seemed like a decent book (with K&R being my reference standard for excellent book to learn from), and decided that a) Java was a little annoying because it took a ton of files to get to "Hello, World" (I may be totally wrong about that) but it did improve a lot on the things I didn't like about C++. It also didn't make my problems obviously more tractable, since I didn't immediately see useful libraries to help reduce the amount I would have to do from scratch.

Using a CMS as a base, and writing my own module: Took a look at a few PHP based ones, went through a PHP/MySQL book. PHP4 is easy, but feels too much like BASIC. PHP5 might be better, but I didn't get there, and I started getting the impression that OOP added onto procedural languages leads to clumsiness. PHP also ends up mixing code and display a lot, which also bothered me.

Perl: Seemed at first like the last language I would ever have to learn. You really can write any language in Perl. CPAN has a lot of nice modules, but I did start running into situations where new versions of one module would break another in a way that was getting frustrating for a relative beginner. Some modules are quite good, though, and it was very promising. Found a good book on Perl and MySQL development for the web that addressed most of what I wanted to do pretty well. Poked a little further and found Catalyst, and thought it would be really useful-- I had used frameworks before (including an OO one written in ANSI C, which was confusing the first read through, but eventually made a lot of sense), and thought it would be great to have all the mundane stuff taken care of by the framework. I got really frustrated installing it though, because there was always some bunch of tests failing, sending me back to try to fix things. Argh. Almost there.

Rails: Almost on a whim I decided to try Rails. I could do what I wanted in Perl, but some of the tools were clumsy, or I'd have to code a lot from scratch. I went through one of the web tutorials using Locomotive, and it actually seemed to work, behave, and do what I wanted without a lot of fuss. It looked a little funny. I got a little more into it and shelled out for the Agile Book-- it seemed too good to be true. I started actually working on the thing I wanted to do and made a lot of progress fast. Then I discovered things that were either a little awkward to do, or seemed a little clumsy either in how I had understood how to do things or how it would behave. And I discovered that I had learned enough in getting to each sticky point that I could rework things quickly to be better behaved. The main things I like about rails are that the MVC structure is strongly reinforced by the language and framework so it makes it easy to keep things where they should be and it's relatively easy to rework even something quickly (even major changes in the models and database) without breaking a bunch of things. I find that I use very little of the scaffolding anymore, and when I run into things that annoy me about it, I've learned enough it getting there that I can work around it. the web app is going to be in RoR for now, with the robots written in Perl.

So now I'm pretty far along and I have to agree that deployment is a major pain. I've done a practice one on a local machine and found it to be kind of a pain, but doable. Perl and PHP are both much easier to deploy, even if I'm recompiling my Apache because the mod_perl dynamic library is unstable. Fortunately the hosting that I'm using is virtual servers, rather than virtual hosts, so I can pretty much control my whole environment. But it also means that I pretty much have to do it myself, or pay $$$.

Even with the deployment hassle, RoR has been great for developing-- the syntax doesn't have a lot of extraneous typing, the MVC structure and Ruby help keep methods small and readable, things are pretty well documented, Rails is pretty stable (I'm not using Edge, but did upgrade to 2.0) and pretty much acts like it says it will.

"[Open-source project] owes you nothing" arguments (4, Insightful)

julesh (229690) | more than 6 years ago | (#21991750)

Why does this argument, or something like it, always get repeated when somebody criticises an open-source project?

The Rails core team also doesn't owe you anything. They are all volunteers who work on it for free. You owe them.

So stop thinking that Rails owes you something. Rails owes you nothing. You owe Rails.


In what way does criticising something suggest I think its authors owe me something? I mean, I'm highly critical of the GIMP at times, particular its Windows "port" which fails to adhere to anything remotely resembling platform standards, but does that mean I think the GIMP's authors _owe_ me something? No. If anything, it means I _hope_ to be able to _give something back to them_ by making criticisms that they could take and use to _improve their software_, which presumably they do care about. It means I don't recommend people try it unless they're willing to accept software that behaves in odd ways.

Re:"[Open-source project] owes you nothing" argume (3, Insightful)

Deadbolt (102078) | more than 6 years ago | (#21993218)

You should think of the "X owes you nothing" argument as a response to certain not-named-here jackoffs who have some sort of trouble with an OS project, get pissed off, and post indignant messages to mailing lists or forums. "I can't figure out X! You guys suck for not making X more clear! Fix it now or my company will never use X!"

The only proper response to this is that X owes you nothing.

So if someone says "Rails doesn't scale/Rails is too slow/Rails isn't easy enough for me, fix it right now!" then the response is clear.

In your case, filing a bug against windows GIMP and calmly explaining why you think it's broken is much more likely to get a serious appraisal at some point -- while some asshole (not you) who just complains about it feels an unearned sense of entitlement and should simply be ignored.

Re:"[Open-source project] owes you nothing" argume (0)

Anonymous Coward | more than 6 years ago | (#21994020)

The proper response to a jack-off is to ignore him.

That being said, said jack-off actually *tried out your stuff*, didn't like it and *said so*. "You should lick my boots for getting that much" is not an appropriate answer, ever, even though I understand why one might feel like saying it. At what point do you start considering what jack-offs said? If a thousand jack-offs post the same complaint, does it become data? It should.

Re:"[Open-source project] owes you nothing" argume (0)

Anonymous Coward | more than 6 years ago | (#21993884)

Amen.

I never used Rails, I don't write web apps and, frankly, I have no interest in it. So I've been following all this by curiosity, because I might have to or want to later, and just for the amusement. I tried reading the other guys' (Zed) rant and stopped a third through because I felt he was just flaming everyone and not saying anything interesting (read: technical). His main critic seemed to be that the RoR guys are arrogant. Like he wasn't.

Now I get his point about arrogance.

This "rebuttal", which I read in its entirety, is *dripping* it.

First there's this point you mention. I could never understand this attitude from some open source developer, or sometimes projects, that users should be happy enough with what they have, and if they got problems, too bad. How difficult is it to say "Very sorry, this will not be addressed in the 2.x versions as it would require too many changes, but we'll take it into consideration when we start working on 3.0. Thanks for your input. BTW, you could mitigate the issue by doing xyz...". Instead it's like "You sucker believed the hype and now you're up shit creek? Tough luck! We know where we're going, we've got a *vision*, you see, and we don't care about mere users problems. But you should thank me for getting you halfway there." Arrogance. Abysmal. "You can rip out the bits you like and discard the rest." says he. I'm glad to submit bug fixes or new functionality to an open source project I use, but if I have to tear it apart to get something useful, it's shit, end of story.

Then there's the "Rail isn't perfect" thing, with the thinly veiled ad-hominem on "immature" people. Guess what? Nobody's looking for perfect. They're looking for the best, or at least the better. What kind of person answers "that's not so good" by "nothing's perfect"? Arrogants, that's who. I already *know* nothing's perfect, what I need to know is how your is stuff *better*!

Third is the one size doesn't fits all argument. When somebody doesn't address criticisms such as "it doesn't scale", "it uses up loads of ram" and "it's not thread-safe", explains that "[if you have SQL bottlenecks you can] bypass it with some inline SQL or even memcache" and "Rails code [...] is so clean and easy to work with that locating and optimising bottlenecks is a breeze", and *then* claim that "Rails is extremely good for [medium to large web applications] of applications", I know one thing: he doesn't have the faintest clue having anything large in IT. All he knows is performance hacks. Which is good, mind you, but not enough when you're dealing with large apps. He's talking about profiling. I'm impressed, that's been around for, what, 20 years? The problem is not optimising the app, the problem is what you do after you've done that and you still have a performance barrier. Oh, yeah, and "If Rails isn't right for your project, that doesn't mean that Rails sucks. It just means that your project isn't right for Rails." Is that so? I'm doing it wrong I guess then! It means Rails isn't right for my project, and that's *it*! Arrogance again...

I won't dwelve into the "Smart people might not like rails, but rails is only for them. Idiots stay away." As far as I know, the hallmark of a good library or framework is to be able to make the difficult easy and the impossible possible. Apparently rails doesn't cut it.

And finally "rails is teh most flexible". Well for all I know, it is. Any facts to back that up? Cuz the examples didn't exactly convince me. For one thing every single OR mapping I've used allows custom tables and custom SQL queries. I got news for him: "most other frameworks" have thought of bypass and override...

In conclusion: like I said, I don't use Rails and I don't do webapps, but "If you decide Rails isn't for [your project, not "you", but presumably it implies that you're not smart enough to get it], *do* post a rant about how it sucks". You may make yourself look bad (maybe even "dumb"), but the better of those rants will end up being linked to the top of google, so the people who have not tried it yet will have a way to form an opinion. Thanks.

Re:"[Open-source project] owes you nothing" argume (1)

An Onerous Coward (222037) | more than 6 years ago | (#21995030)

Absolutely correct. You can criticize an open source program all you want, and good criticism can be a boon to a project. But there are some lines that you don't have a right to cross. One is when you say, "so hurry up and fix it!" Unless you're willing to front the money or do the coding, you're not in a position to make demands.

Another line is the thin line that separates constructive criticism from mere douchebaggery. It's easy for frustration with a framework to bleed over into personal attacks against its authors or its fans.

Lastly, the article is right to point out that a lot of criticisms about any project are simply false as a matter of fact. Those can be especially frustrating for the people working on a project.

Just expect people to be emotionally invested in their favorite projects, and to know it too well to see your objections as major obstacles. So they may not take your complaints as seriously as you'd like.

Sucks is a bit hard... (0)

Anonymous Coward | more than 6 years ago | (#21991904)

...but exactly why is the namespace within the controller so polluted?

Why can't I name a instance variable @template? (Just an example among others.)

There is no magic bullet. (1)

Richard Steiner (1585) | more than 6 years ago | (#21992002)

Every programming language/framework has its own set of advantages and disadvantages. The trick is determining if a given language and/or framework does what you want in the way you want it done.

There are reasons my employer doesn't use Java everywhere, for example, and reasons why C or C++ is preferred in some contexts at my workplace while other languages are preferred in others.

In other words, it's quite possible that a given solution works very well for some people and can't cut it at all for others. One size of development tool does NOT fit all.

Like I always say (4, Interesting)

hey! (33014) | more than 6 years ago | (#21992006)

You never really know a system until you hate it.

Of course, hating a system doesn't mean you know it. You can hate a system in a completely uninformed way.

Now back when I got involved with computers, in the 70s, it wasn't like this. We didn't have frameworks, we had libraries. Either a library met you needs and you used it, blessing its authors, or it didn't and you didn't use it. Of course people didn't expect much from applications back then, either. Programs by in large just started up, did something useful, then went away. There was a whole "software tools" philosophy built around this very idea: write programs that do one thing (usually some kind of filtering task), then go away.

By contrast all but the meanest programs today look like operating systems. They're supposed to run forever an take god knows what input from god knows where and do precisely what the designer wanted them to do, plus whatever he would have wanted them to do if he had had the foresight, but nothing else.

And you've got to choose a framework. It's not just diving into a program and deciding you need something that's in a library somewhere. It's not just choosing a framework before you really know what your application has to do. You've got to choose the framework before you interview for the job. So really, life as a programmer involves relatively less solving of real problems and relatively more finding ways to hammer square pegs into round holes.

It's not that writing software is any less fun than they were back in the day. It's that on top of being fun its goddamned annoying.

Re:Like I always say (1)

I Like Pudding (323363) | more than 6 years ago | (#21993686)

Now back when I got involved with computers, in the 70s, it wasn't like this. We didn't have frameworks, we had libraries. Either a library met you needs and you used it, blessing its authors, or it didn't and you didn't use it. Of course people didn't expect much from applications back then, either. Programs by in large just started up, did something useful, then went away. There was a whole "software tools" philosophy built around this very idea: write programs that do one thing (usually some kind of filtering task), then go away.

Sounds like vi.

By contrast all but the meanest programs today look like operating systems. They're supposed to run forever an take god knows what input from god knows where and do precisely what the designer wanted them to do, plus whatever he would have wanted them to do if he had had the foresight, but nothing else.

Sounds like Emacs.

The only measure I know of by which Rails sucks... (0)

Qbertino (265505) | more than 6 years ago | (#21992008)

... is the "Hype vs. Mature Usable Open Source Projects Built With It (TM)" Ratio.

By that Rails sucks, Ruby sucks even more, Django and Zope suck a little, TurboGears, etc. suck, Python itself fares quite well and PHP kicks everybody elses ass, Java included.

That aside it's pretty much a matter of taste and how well the core community is willing to push their product. Rails practically lifted open source project marketing to a whole new level - they deserve the attention they get. It's up to the ones using these webkits to seperate hype from reality.

Re:The only measure I know of by which Rails sucks (1)

nonsequitor (893813) | more than 6 years ago | (#21992950)

That's a good measure for those who have no intention of developing with the technology. However when I evalute something's technical merits, I actually try to make something with it.

If it handles certain tasks better than other methods I know, it's useful.

If it assumes too much about how I'm supposed to use it, its much less useful. Not being thread-safe, not having both blocking and non-blocking versions of certain API calls, etc are all points against a product. I also grade on elegance of design. There's an old saying, what do you get when you mix 100 gallons of ice cream and a teaspoon of shit. 100 gallons of shit. If the layer below the one you're writing is poorly designed, the design flaws will invariably propogate upward.

One last point about these "easy to use" frameworks geared towards the average folk. The more complex details you hide trying to make it simple to use, the easier it becomes to use it wrong unknowingly. There is no silver bullet to get around algorithm efficiency, and a properly ingrained understanding of how computers solve problems and how to classify various problem types. Teaching someone to use an over-powered IDE and giving them a certificate which says that they know how to make programs that run, is no assurance that those programs will run well.

The author of the opinion piece said Rails helps smart people write a certain type of program faster. That is an arrogant statement, there are plenty of smart people without the formal training the author has had which probably use Rails poorly. It would have been more accurate to say, "Rails helps people who think a certain way accomplish a limited subset of tasks faster."

The more I read, the more both sides of this drama sound like elitist pricks, which can be an epidemic among web communities. Some very smart people over compensate for not having been popular in High School and create exclusive online communities rather than inclusive ones, these people tend to handle any criticism very poorly. Of course these people get worn down by people demanding so much from them without ever offering any compensation for their time.

If you want a good measure of what sort of people are in a given community, go to their IRC channel and ask a question from their FAQ.

(Disclaimer: not a web developer, never used Rails, no plans to in the near future)

Re:The only measure I know of by which Rails sucks (1)

Chandon Seldon (43083) | more than 6 years ago | (#21995094)

If you want a good measure of what sort of people are in a given community, go to their IRC channel and ask a question from their FAQ.

True enough, but remember: The set of communities with assholes in them and the set of communities that produce useful software tools overlap almost entirely.

Re:The only measure I know of by which Rails sucks (1)

KDan (90353) | more than 6 years ago | (#21995922)

Just for the record, the author did a physics degree with no IT component (a great many years ago), and taught himself Rails in a few weeks over the summer. No formal training.

Re:The only measure I know of by which Rails sucks (1)

nonsequitor (893813) | more than 6 years ago | (#21996094)

I don't know the people involved, but most people I do know that are involved in the open source community like the CCC guys have pretty amazing stories too. There are a LOT of good people out there, unfortunately the idiots are the loudest and this guy decided to feed the troll, which means he's not part of the solution if you get my drift.

Re:The only measure I know of by which Rails sucks (1)

Chandon Seldon (43083) | more than 6 years ago | (#21995058)

PHP kicks everybody elses ass

Have you heard of Perl?

Now, it's possible that you're defining "Usable" as "Not in Perl", but Perl has more mature, high quality code available in it than any other "web language".

Usual OSS criticism argument... (1)

Bri3D (584578) | more than 6 years ago | (#21992052)

This is 100% exactly the same argument presented whenever an Open Source app is criticized.
Shut up about it!
How about instead of whining about people whining about their software, Rails advocates fix some of the issues causing arguments against their framework? Most of the people whining aren't capable of writing their own code to fix their problems with Rails, but their rants should be taken as SUGGESTIONS by the developers, not railed (no pun intended, seriously) against by a community full of zealots.
The same applies to all of the OSS fanatics who make this argument about *every* *single* *piece* of software, ever.
Yeah, sure, people should be a little more grateful.
But does the project being free protect it from criticism? It shouldn't.

Re:Usual OSS criticism argument... (0, Flamebait)

Chandon Seldon (43083) | more than 6 years ago | (#21994942)

How about instead of whining about people whining about their software, Rails advocates fix some of the issues causing arguments against their framework?

How about not.

I'm developing an app in Rails right now, and it's meeting my needs perfectly. If I have problems with it, I'll fix them. If you have problems with it, you fix them.

Re:Usual OSS criticism argument... (1)

An Onerous Coward (222037) | more than 6 years ago | (#21995486)

To the extent that it's their project and their time, they aren't obligated to listen to your complaints, much less fix them.

To the extent that the creators claim that other people should use their project for some purpose, then their reputation ought to be influenced by how well it lives up to those claims. But they're still not under any obligation to fix your issues or add missing features.

To the extent that criticisms are made in abusive, insulting ways, then the developers are big damned heroes if they can sift through it for any kernels of truth.

Nobody is saying that we can't criticize, but your criticism should be tempered by the fact that it's not your project, and the developers might not share your vision or care about your opinion.

this article is useless (4, Funny)

Some_Llama (763766) | more than 6 years ago | (#21992174)

unless i get a description of the author's prowess in martial arts and ability to kick my ass in a general time frame (10 seconds? 2 minutes?).

still waiting to use it... (1)

abes (82351) | more than 6 years ago | (#21993056)

I've mostly liked RoR, from the small amount I've used it. I'd use it more, only I keep starting projects with it, realize it's probably not the right tool, and then switch to something else.

Part of the problem might very well come from the fact that I have very little experience with it (catch-22?). The thing is, from what I can tell, it's really specialized. I never had this problem with PHP or ModPython.

The article itself is a bit annoying, as it's about as vague as one can get. For us unenlightened, *when* is the proper time to use RoR? I get it's DB driven. So if you have to write a store, library, or /., you're good. But how does it fair for more general apps?

One of the big things that worries me is that there are a lot of files generated. That scares me. What if I made a mistake at the beginning? Is it easy to go back? Do I need to start from scratch?

I'm sure there is documentation somewhere that mentions that, only I haven't found it yet. I've come across plenty of 'how to start' articles, but not many that really get at the architecture design as a whole. Though, this seems fairly status quo for web-development.

As other posters have noted, many of these complaints/thoughts come from RoR being a framework. I wonder if it would be possible to re-create RoR, but in a more library-form. User has to do more work (no generated files), but more flexibility in the long run?

Re:still waiting to use it... (1)

tcopeland (32225) | more than 6 years ago | (#21993438)

> One of the big things that worries me is that there are a lot of
> files generated. That scares me. What if I made a mistake at
> the beginning? Is it easy to go back? Do I need to start from scratch?

Yup. Most of the files that are generated are just enough to get you started. For example, generating a simple "person" model class gets you this:

$ ruby script/generate model person name:string birthday:date
[... some output ... ]
$ cat app/models/person.rb
class Person < ActiveRecord::Base
end
You can add methods to this file as you see fit. And the outline of a test class - a fine practice to get into - is generated as well:

require File.dirname(__FILE__) + '/../test_helper'
class PersonTest < ActiveSupport::TestCase
  # Replace this with your real tests.
  def test_truth
    assert true
  end
end
They're just scaffolding to eliminate some unnecessary typing. Enjoy!

Re:still waiting to use it... (2, Interesting)

abes (82351) | more than 6 years ago | (#21993644)

As long as you don't change the DB too much. Obviously since you are creating a class representation of the database, how much gets altered will certainly muck things up.

It seems that RoR makes heavy reliance on this relationship, which is where it gets it power, has a literalism that disallows abstraction to easily take place. I might be able to abstract the data well enough that it doesn't matter how its held in the SQL DB in a different language/framework/library. However, I'm going to assume that RoR isn't meant for that type of coding.

I've just started to read up on Cocoa's Core Data, which has some similarities. Though it has a GUI in order to map the relationships. There's definitely power in relationship mapping for data. Going back to abstractions, it would be interesting to see a more general approach taken with Ruby that would do more than just SQL databases (unless it does, and I'm just missing something).

Re:still waiting to use it... (1)

tcopeland (32225) | more than 6 years ago | (#21994398)

> Obviously since you are creating a class representation
> of the database, how much gets altered will certainly muck things up.

Definitely, yup, when you change the data you'll need to adjust the code as well.

Re:still waiting to use it... (1)

Fweeky (41046) | more than 6 years ago | (#21993984)

The thing is, from what I can tell, it's really specialized. I never had this problem with PHP or ModPython.
Stop comparing Rails to languages, you fucking morons *headbutts wall until you all stop*

Of course it's specialized, it's an opinionated web framework for writing web applications in a certain style; on "rails", if you will. If it doesn't suit you, use a different framework, or no framework like you'd do with PHP or Python. Why is that so difficult to grasp when it comes to Ruby?

But how does it fair for more general apps?
You mean, without a database? Stateless, or what? Chances are you have data; you can just disable/not use ActiveRecord and have your models for the data do other things, with a similar interface to keep validation, creation, searching etc easy.

One of the big things that worries me is that there are a lot of files generated. That scares me. What if I made a mistake at the beginning? Is it easy to go back?
Going back is what revision control is for; if you're not using it, sucks to be you, though the boilerplate's trivial enough to regenerate/update if necessary. If your application is dwarfed by the boilerplate it might signify Rails is overkill for your application; you don't need a 60kLOC framework for Hello World or exporting a single database table to the web.

See, e.g, Ramaze [ramaze.net] , or Nitro [nitroproject.org] , or Sinatra [rubyforge.org] , or Iowa [enigo.com] , or (...), or write your own 100-line nanoframework using Rack [rubyforge.org] . Stop obsessing over Rails! This should answer your final question too ;)

Re:still waiting to use it... (1)

abes (82351) | more than 6 years ago | (#21994126)

Yes, but as far as I know, RoR is the main package people use for Ruby, versus Python which has 5-6 packages that I know of. Part of the reason for this is that Ruby's language has some unique features that make it favorable to RoR's style (though projects like Django seem to pull it off okay..?). Not to mention PHP has Cake, which is also supposed to model itself after RoR. So, I was assuming that most readers would be smart enough to figure out I meant the standard way you do things in PHP or Python, or whatever language (you may also note ModPython is not a language, it's a library, though it doesn't actually do much for HTML generation). There's really no reason to be rude, and it makes you look a bit stupid and a bit of an ass. As for the general apps, that's the info I'd like to know, but haven't been able to find much info on. Almost all demos I've seen build off of a database. There's plenty of sites I'm interested in making that actually have no database whatsoever. Because that's RoR's, I would assume it's not going to help me much. By going back, I didn't mean revision control. I meant changes in the structure of the code (you might have heard of refactoring?) or even the database. Previous experience with generated code (thank you Visual-C++) has made me weary about the initial parameters set when creating a project/object/etc. that results in code. I've actually done a minimal amount of obsessing over rails. I've most just ignored it, but in part because besides wrapping a DB nicely in an interface, I'm not entirely sure what it does well. Not that wrapping DB isn't important for web pages, it's just there's a lot more to programming than that.

Re:still waiting to use it... (1)

Marcion (876801) | more than 6 years ago | (#21994708)

Linebreaks in Ruby are '\n'. In Slashdot you need to press Enter sometimes...

Re:still waiting to use it... (1)

Fweeky (41046) | more than 6 years ago | (#21995164)

Yes, but as far as I know, RoR is the main package people use for Ruby, versus Python which has 5-6 packages that I know of.
I suggested at least that many alternatives for Ruby, and there are more. You don't base all your decisions on how popular or well marketed something is, do you?

Part of the reason for this is that Ruby's language has some unique features that make it favorable to RoR's style
Perhaps, but it's also perfectly favourable to various other "styles". Metaprogramming is quite a general tool, as you might have guessed ;)

I was assuming that most readers would be smart enough to figure out I meant the standard way you do things in PHP or Python
It's akin to calling PHP development Cake. Names of frameworks are not interchangable with generic terms for web development in a language, and I assumed you'd be smart enough to recognise that. I've used Ruby for 8 years, and I certainly don't equate Rails with the One True Way of doing web development in it. I might end at it for some things, but I certainly don't start there.

There's plenty of sites I'm interested in making that actually have no database whatsoever. Because that's RoR's, I would assume it's not going to help me much.
Like I said; you may not have a database, but you probbaly have data you want to serve dynamically in some way? Much of the advantage Rails provides is a convention for how to interact with that data, with ActiveRecord being the de-facto example, but, for example there's also ActiveResource which talks to web services instead of directly to a database; if you don't want a database, you just fill in the "M" part of MVC with a layer that talks to something else, and try to stick with the conventions to keep the interface Rails-alike. Maybe you'll make find() work off flat files, and put more complex queries through Ferret [davebalmain.com] . Maybe you'll just store it in an object temporarily and use validations [rubyonrails.org] to help sanitize your data and drive your forms.

Or, again, if that's all a bit overkill or otherwise a poor fit for your applications, use a different framework, or none at all.

By going back, I didn't mean revision control. I meant changes in the structure of the code (you might have heard of refactoring?) or even the database.
The structure's defined by things like your class definition and routing configuration: generating a controller or model basically makes "class FooController < ApplicationController;end" in the right place, plus helpers for your views and templates for testing. You're generally not generating scary big fragile chunks of code; if you want to rename something, do so, it's not magic. The point of metaprogramming is that you can be agile with these changes without you having to generate and maintain reams of static code.

Database wise, the models are mostly driven by what the database looks like; you add a column to the database (probably using a migration [rubyonrails.org] ) and your models automagically notice. Renaming a model can be done without renaming the table, and vice versa, and you can make renames less painful by mapping old names to new trivially. Either way, the code generation helps you because it's mostly done dynamically via metaprogramming based on the code you wrote, not statically based on your script/generate commands like, e.g. the C++ GUI generators you might be familiar with.

But again, even that level of code generation might be overkill, and if having lots of files dotted about feels wrong when you really just want one or two modest .rb's for a small application, something like Ramaze [ramaze.net] , Rack [rubyforge.org] or even Camping [rubyforge.org] , might be more suitable. They'll probably be faster, less memory hungry, more concurrent and need less maintainence to keep up with future releases too.

Re:still waiting to use it... (1)

smellotron (1039250) | more than 6 years ago | (#21994858)

Stop comparing Rails to languages, you fucking morons... Why is that so difficult to grasp when it comes to Ruby?

Based on your words, it looks like you're having trouble distinguishing between the framework and the language as well. Given that may would-be RoR users have never seen Ruby before, they tend to go together, and thus will always be compared to other languages. That's the price that DHH and his followers have to pay for using a (previously) obscure language to implement a web platform.

Re:still waiting to use it... (1)

Fweeky (41046) | more than 6 years ago | (#21995236)

Based on your words, it looks like you're having trouble distinguishing between the framework and the language as well
In what way? People compare Rails to languages. People often don't look at alternatives to Rails when they do web development in Ruby but do look at multiple frameworks in other languages. The words would appear to fit fine.

Re:still waiting to use it... (1)

smellotron (1039250) | more than 6 years ago | (#21996214)

My point was that you began the rant referring to Rails, and it just morphed into a referral to Ruby, suggesting that even you (intentionally or not) blurred the lines between the framework and the language. After all, one of the other parents pointed out that ModPython is a library, and PHP itself generally refers to the interpreter plus the standard set of functions available in it, so any conversation about languages will naturally include related tools (including libraries/frameworks). For another example, look at Perl and CPAN, or C++ and the STL (or maybe Boost).

Mind you, I think comparisons between PHP and RoR are perfectly valid in their own right, which is different from most people's opinions. PHP is just much more low-level (which happens to be helpful when it comes to deployment, I suppose).

Re:still waiting to use it... (1)

Chandon Seldon (43083) | more than 6 years ago | (#21994982)

One of the big things that worries me is that there are a lot of files generated. That scares me. What if I made a mistake at the beginning? Is it easy to go back? Do I need to start from scratch?

The generation script doesn't actually generate anything especially complex - it's literally like 10 or 12 lines of code. Further, the framework doesn't remember what it's generated, so you can rename / delete stuff to your heart's content without causing any problems.

For us unenlightened, *when* is the proper time to use RoR? I get it's DB driven. So if you have to write a store, library, or /., you're good. But how does it fair for more general apps?

For any database-driven web application (which ends up being most non-trivial web applications). If your website has user accounts or otherwise needs to remember things, it can probably be written with a database backend.

The book I used to get started is "Agile Web Development with Rails", which covers enough to figure things out.

Wow (1)

gbelteshazzar (1214658) | more than 6 years ago | (#21993068)

So RoR can't be used to solve every problem on the planet?

People get to hung up on a platform or tool. The worst thing anyone could do is to blindly give a project to a dedicated RoR or PHP or Java developer. It should be given to a developer who may enlist an implementation technology expert to implement it.

Software projects fail because they get hung up on implementation, don't have enough design or don't have correctly formatted requirements. if projects fail in implementation its being done by a group of idiots and deserved to fail.

Just how slow is "slow"? (1)

Cultural Sublimation (884893) | more than 6 years ago | (#21993352)

I've asked the question below in other fora, but could never find a conclusive answer; here's hoping that /. wisdom will change that...

So, when people complain about Rails being slow, just how slow are we talking about? Are we talking in the range of 10s, 100s, or 1000s of requests per second? And how does it compare to PHP, the Python-based frameworks, etc?

Imagine I created a simple "hello world" dynamic page: something that when given a number as parameter, would return "the double of $num is $double". Imagine you would call it with http://whatever/get_double?num=10 [whatever] . How many req/sec would you expect on a decent machine with your favourite CGI language or web framework?

(And yes, I realise just how awfully simplistic this example is, but I would like to get a ballpark figure). Thanks!

Re:Just how slow is "slow"? (2, Informative)

Unoti (731964) | more than 6 years ago | (#21993778)

There's 3 aspects to the slowness, IMHO:

1. The language. Ruby tends to be slower. Something like this programming language shootout [dada.perl.it] will give you details. But this isn't the whole story.

2. Enough rope to hang you. Rails gives you a lot of ways to easily define dynamic classes, where the class is being generated dynamically on the fly. It can make the code lovely and small to use, but can make it slower than hammering it out in a lower level language. This and other techniques can lead to higher memory consumption, too. But I don't fault the language here. I see it as a powerful tool that must be wielded carefully sometimes.

3. Active record. A lot of the slowness that people see can come from automagic that's happening in the background. If you're not careful with active record, for example, it pulls in every last field from table you're looking for, along with the relatives. I just needed the customer's name, and ended up with 8 kilobytes of data because I wasn't careful with what I was doing.

Speed and Protection (3, Interesting)

Unoti (731964) | more than 6 years ago | (#21993688)

Ruby and Rails are delicious, but there's 2 things I need that I can't get from Ruby on Rails right now. Because of these 2 things, I am using C# under Mono, but I'd far rather use Ruby on Rails if I could:

1. Protect the code. I need to be able to deploy it without the code being easily copied and reviewed. I know, I've seen it all on this topic: I don't really need to protect it, whatever I'm doing isn't that hard to figure out, etc. Trust me, I really need to protect the code. I write products for a living, and my customers will unfairly pirate/sell/give my code away, and it will cut into my income if I can't keep control of who gets my code. This is why I'm using C# and Mono. And yes, I realize that can easily be decompiled. But it's still more than adequate protection in my business space.

2. Make it faster. Ruby is too slow for what I need to do. My customers can only afford around $100 USD/mo for hosting my special purpose application, and for the number of people they get hitting the site, Ruby doesn't cut it. I know, I know, do more caching do more magic, get more computers, build a server farm, etc. Whatever. I just rewrote the thing in C# and I could support way more users per $100 of server. It made me cry to have to do it.

Please, if there's ways to do better on those 2 areas, let me know! But trust me, I really do need to protect the code.

I'm thinking I might be able to solve both of these problems using JRuby some day, but I'm not sure yet.

Re:Speed and Protection (1)

Unoti (731964) | more than 6 years ago | (#21993706)

Regarding copying the code, I don't currently prevent copying exactly. I just have it locked to particular domains.

Re:Speed and Protection (1)

Marcion (876801) | more than 6 years ago | (#21994802)

I suppose most people in rails are making websites which are more one off things, most of everything repeated is in rails.

However, locking code down is an interesting problem in that a lot of the more modern high-level languages have no way to really lock down the code.

Your approach is just security through obscurity, but as you say, it may be enough to stop lazy ignorant people. I would be interested in people's experiences with this.

I program in Python, and there is also no real way to lock down the code, you can give the compiled files which with a bit of Python knowledge can be decompiled, at least to some degree.

Another way to bundle things inside an exe or rpm and hope they are not smart enough to pull the code out. However both of these steps are really just security through obscurity.

Re:Speed and Protection (1)

Unoti (731964) | more than 6 years ago | (#21995064)

However, locking code down is an interesting problem in that a lot of the more modern high-level languages have no way to really lock down the code.
I agree, and I was kind of surprised about this. At first I thought that surely I must be missing something. Near as I can tell your options for writing Web code without releasing the source are Java, .NET, or CGI-bin using C++ or another compiled language. I actually seriously considered using FastCGI with D, and then I snapped out of my reverie and got to work in C#. Anyway the whole experience kind of made me feel a little surprised about the way the languages are going. As you say, it could just be that most web apps are one-offs. Actually the Python installer approach would be adequate for my problem. I chose C# because I was in a hurry and already knew C#.

Re:Speed and Protection (1)

smellotron (1039250) | more than 6 years ago | (#21994904)

Ruby is too slow for what I need to do... I know, I know, do more caching do more magic, get more computers, build a server farm, etc.

Or, you could keep your C#, do more caching magic, get more computers, build a server farm, and still win the speed game. Besides, adding an object cache is generally trivial in any language, if you have access to something like memcached [danga.com] , and adding an HTTP cache (sending 304 Not Modified) is as simple as checking a few timestamps.

Re:Speed and Protection (1)

An Onerous Coward (222037) | more than 6 years ago | (#21995384)

Re: speed. Rails is slowly being rewritten in Ruby 1.9, which will make it several times faster. 1.9 integrates a new virtual machine called YARV. It won't magically solve everything, but it will help some.

A lot also depends on your deployment setup, which is one of the trickier things about Rails in my mind.

My experience with RoR (1)

Henry V .009 (518000) | more than 6 years ago | (#21994738)

I've done a lot of C++ coding. Designed several PHP websites. I've had to maintain a good amount of Perl code. My Ruby experience is mainly just playing around.

Recently, my girlfriend got me started on writing a book recommendation website for her. I had heard a lot of things about Ruby on Rails, so I decided to buy a book and give it a try. I like the AJAX integration. I've never used javascript, and it was easy to jump right into that. The database integration is also neat -- it handles a lot of the grunt work for me.

More than anything I'm worried about speed. Like I said at the beginning, I come from a strong C++ background. The philosophy there is basically do things at a high level, but the speed should be there if you need it. And yes, I've needed it at various, often unexpected, times in my career.

I'm also a little worried about reliable APIs. The RoR team seems to have a habit of breaking things with new releases. Since web security depends on updates, leaving things unpatched doesn't strike me as a wonderful solution. But hey, this is just a play website I'm building. I'm having fun, and I guess I'll find out whether the framework lives up to expectations or is more trouble than it's worth.

Re:My experience with RoR (3, Informative)

Chandon Seldon (43083) | more than 6 years ago | (#21995024)

More than anything I'm worried about speed.

The standard story for dynamic language development applies:

  • Optimizing before you have a problem is a waste of time.
  • There are lots of ways to optimize, up to and including re-writing the bottlenecks in C/C++.

The most common optimization that's used with Rails is it's built-in support for caching, which can speed things up by quite a bit. You can get the same sort of results with a hand-optimized memcached setup any other dynamic language - but Rails gives it to you almost for free.

Re:My experience with RoR (1)

KDan (90353) | more than 6 years ago | (#21996012)

Yep, there's an article about that too on that site. It's called Premature Optimisation [inter-sections.net] .
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>