Rails May Not Suck 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."
This just seems like nonsense. (Score:4, Insightful)
Too Generic (Score:5, Insightful)
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.
Ruby (Score:5, Insightful)
(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!"
"[Open-source project] owes you nothing" arguments (Score:5, Insightful)
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:Too Generic (Score:3, Insightful)
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:Ruby (Score:3, Insightful)
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.
Re:"[Open-source project] owes you nothing" argume (Score:4, Insightful)
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.
Blame the programmer not the language (Score:4, Insightful)
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 (Score:5, Insightful)
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: 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:Too Generic (Score:5, Insightful)
Rails may be a nice framework, but flexible it ain't.