Forgot your password?
typodupeerror
Programming IT

Rails May Not Suck 160

Posted by timothy
from the isn't-the-question-whether-rails-suck dept.
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 discussion has been archived. No new comments can be posted.

Rails May Not Suck

Comments Filter:
  • Re:Too Generic (Score:4, Interesting)

    by WaZiX (766733) on Thursday January 10, 2008 @06:11PM (#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:Ruby (Score:3, Interesting)

    by MenTaLguY (5483) on Thursday January 10, 2008 @06:44PM (#21991914) Homepage
    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?
  • Like I always say (Score:5, Interesting)

    by hey! (33014) on Thursday January 10, 2008 @06:51PM (#21992006) Homepage Journal
    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.
  • by abigor (540274) on Thursday January 10, 2008 @08:40PM (#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]

  • by abes (82351) on Thursday January 10, 2008 @09:04PM (#21993644) Homepage
    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).
  • Speed and Protection (Score:4, Interesting)

    by Unoti (731964) on Thursday January 10, 2008 @09:07PM (#21993688) Journal
    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.

  • by CastrTroy (595695) on Thursday January 10, 2008 @09:16PM (#21993770) Homepage
    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).
  • Ruby vs Python (Score:2, Interesting)

    by Wiseman1024 (993899) on Friday January 11, 2008 @04:40AM (#21996468)
    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."
  • by Karl Harbour (1217102) on Friday January 11, 2008 @03:24PM (#22003134)

    Has it really? I don't think that Java has survived the lack of mod_java.

    Quite. Apart from the lack of Java in the hosting space, let's be honest, the whole Apache->Tomcat connector story has been a sorry one indeed. mod_jk, mod_jk2 etc has been a real mess over the years.

    Where does this stem from? I think it is a case of the wrong tool for the job again in a way, this time by Sun.

    Originally Oak (Java) was designed to run on set-top boxes, where it made sense to have a long-running virtual machine. The web took off just as Java 1.0.2 was launched with a whole 6 packages. Not long after, Apache was the prevalent web server, and worked well for static content. Dynamic content was served by CGI, and that didn't work too well because every request required launching a separate process.

    So PHP comes along and quite nicely solves this problem by running in an Apache module, with the requests handled in forked Apache child processes (pre-fork MPM).

    This model doesn't fit with the virtual machine architecture of Java - you can't have multiple copies of the VM in each of Apache's children. So we end up with the mod_jk architecture.

    I used to think that the PHP MPM Apache children approach was a bad thing, compared to the ability to create threads, caches of shared data, database connection pools etc in Java. But the PHP shared-nothing architecture has definite benefits.

    For one thing, it gives you isolation. If one child fails, other children are unaffected. In my experience, the PHP architecture is more robust, for example, in the case of recovery from database failure. I've seen Java web apps where if the database is restarted, invalid connections stay in the connection pool and you have to restart Tomcat.

    Also, horizontal scalability is so much easier. Java has solutions to this, but it's a bit of a mess in some ways. Of course I don't think PHP is a better *language*, but the reason HTTP itself has been successful is because of its statelessness. The PHP shared-nothing architecture respects that, Java goes against it.

    That, in my opinion, is why PHP rules the roost on the public internet.

  • by tkdtaylor (1039822) on Friday January 11, 2008 @03:55PM (#22003722)
    Have you tried VS.PHP?
    VS.PHP IDE [jcxsoftware.com]

    I'm pretty happy with it although I'm a .Net developer by day so I'm used to the IDE already.

"Hello again, Peabody here..." -- Mister Peabody

Working...