Slashdot Mirror
Rails May Not Suck
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."
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.
I have come here to chew memory and kick ass... and malloc() is returning a null pointer.
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.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
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.
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!"
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.
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.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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?).
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.
"Honey, it's not working out; I think we should make our relationship open-source."
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.
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).
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.
1. The language. Ruby tends to be slower. Something like this programming language shootout 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.
The standard story for dynamic language development applies:
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.
-- The act of censorship is always worse than whatever is being censored. Always.
I disagree. I'm a supporter of multi-paradigm programming ("the right tool for the right job") and consider functional programming approaches the most important of all. I find Python very comfortable to work with, and much conceptually cleaner than Ruby.
While Ruby has one advantage or two over Python, such as multi-expression lambdas and Python's statements turned to expressions (statements are a common root of evil and an unnecessary procedural concept), the main problems I see in Ruby as a language, leaving libraries aside, are that it has several different implementations of the same concept of function - blocks, procs and methods, having mediocre first-class function support due to keeping that silly value vs. function value behaviour inherited from the equivalent Common Lisp misfeature, completely misunderstanding properties (partly as a result of the former: a method should really be just a property which happens to be a function, or an object that can be used with the (...) operator), and having unnecessary complexity and irregularity in the syntax which is good for nothing and bad for everything. I suppose people who enjoy Perl may enjoy Ruby in the sense that it feels like you're writing some kind of "seekret haxxor code", but all you're really doing is spend about the same time writing a much less readable and maintainable program that looks like ass.
I'd like to post quote from the first words of R6RS, the Scheme standard, which I consider to be the ultimate design criteria, not only for programming languages, but for software in general, and perhaps things beyond software:
"Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary."
I was about to say 13256278887989457651018865901401704640, but it appears this number is private property.