Follow Slashdot stories on Twitter

 


Forgot your password?
Close
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 More

Rails May Not Suck

Comments Filter:

  • This just seems like nonsense. (Score:4, Insightful)

    by morbiuswilters ( 604447 ) on Thursday January 10, 2008 @04:59PM (#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. (Score:5, Informative)

      by nschubach ( 922175 ) on Thursday January 10, 2008 @05:03PM (#21991254) Journal
      Let me summarize the wall of text ;)

      Use the right tool, for the right job.
  • 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. (Score:3, Funny)

    by Aladrin ( 926209 ) on Thursday January 10, 2008 @05:02PM (#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: (Score:2)

      by KDan ( 90353 )
      Actually the submission had the title of the article, "Rails sucks?", which I thought was a bit more catching, but oh well.
  • 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
    • Well, here's the issue:

      People have a project they think is suitable for use with Rails and then after spending a lot of time working on it, it turns out for some obscure minor reason, it just won't work. That's when reasonable people start saying "Rails sucks".

      Frankly, I won't even try Ruby of Rails, I've been down similar roads, and I don't feel the need to straitjacket myself into a self-limiting framework. Plus the only popular site I know that runs Ruby on Rails has a tendency to just break from time

  • Too Generic (Score:5, Insightful)

    by roadkill_cr ( 1155149 ) on Thursday January 10, 2008 @05:03PM (#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 (Score:4, Interesting)

      by WaZiX ( 766733 ) on Thursday January 10, 2008 @05: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?
      • 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: (Score:3, Insightful)

        by n dot l ( 1099033 )
        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
        • 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.

        • 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 (Score:5, Insightful)

      by arevos ( 659374 ) on Thursday January 10, 2008 @08:25PM (#21993836) Homepage

      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: (Score:2)

        by Tablizer ( 95088 )
        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. ... 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.

        This has been the case with *any* RAD (rapid app development) tool since the dawn of frameworks. Nobody has figured out how to solve this barrier. I've decided that the

        • Re: (Score:2)

          by arevos ( 659374 )

          This has been the case with *any* RAD (rapid app development) tool since the dawn of frameworks. Nobody has figured out how to solve this barrier.

          I don't believe this to be the case. Every problem I've found with Rails is conceivably fixable. A lot of it is just due to the Rails devs stuffing things into the bloated maw of ActiveRecord that really shouldn't be in there, and not separating out their methods properly. I have great hopes for some of the up and coming Ruby ORM libraries to replace AR with something rather leaner.

          Their dependencies between each other need to be fairly light so that that you don't have to buy the whole barn if you just want a cow. This generally requires a scriptish language that is not anal over types.

          Being anal over types isn't a bad thing, so long as you have a sophisticated enough type system to offer the developer. A goo

        • Re: (Score:2)

          by pavera ( 320634 )
          Ever worked with Django?

          I agree with the parent post, in my Rails days, every headache I ran into had to do with hard coded, poorly designed "features" in ActiveRecord.

          I've since moved on to Django, and yes, the framework doesn't do *everything* for you. But it is specifically designed not to. The project has made decisions about quite a few things along these lines "Well, that's just too hard to get right for everyone, so its not in the framework here's how you do this directly, don't use the framework f

    • 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?

  • Ruby (Score:5, Insightful)

    by Fallingcow ( 213461 ) on Thursday January 10, 2008 @05:21PM (#21991578) Homepage
    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: (Score:3, Funny)

      by Takichi ( 1053302 )
      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: (Score:3, Interesting)

      by MenTaLguY ( 5483 )
      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

      • Re: (Score:3, Insightful)

        by Just Some Guy ( 3352 )

        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

        • Blame the programmer not the language (Score:4, Insightful)

          by Unoti ( 731964 ) on Thursday January 10, 2008 @07:44PM (#21993420) Journal

          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: (Score:2, Informative)

        by I Like Pudding ( 323363 )

        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.

      • Ruby vs Python (Score:2, Interesting)

        by Wiseman1024 ( 993899 )
        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, leavi

        • Re: (Score:2)

          by MenTaLguY ( 5483 )
          A proc is just a reified block. However, I'm with you on the method thing. Aside from lambda issues, I do think Python does first-class functions (whether methods or anything else) more consistently, which I like about it.

          Multi-expression lambdas are a pretty big thing for me, though; I miss them a lot in Python and I think the workarounds for their absence usually result in extreme code uglification.

    • Re: (Score:2)

      by LWATCDR ( 28044 )
      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

    • Re:Ruby (Score:5, Insightful)

      by Fweeky ( 41046 ) on Thursday January 10, 2008 @08:17PM (#21993776) Homepage

      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.
      • 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: (Score:2)

          by Fweeky ( 41046 )
          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 << yi

      • 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

        • Re: (Score:2)

          by Fweeky ( 41046 )
          Well, Ruby introduces concepts you may be unfamiliar with, not just new syntax, but it shouldn't be that foreign once you have the basics down? I'd be interested in some examples of what sort of things confuse you, though; I probably take for granted many things now that confused the hell out of me when I started but don't remember :)

          I do think "learn the framework not the language" is a dubious strategy, though; I tend to learn by starting small, with code I can understand and keep in my head, and build u

        • 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

          If you are averse to buying a book, the first edition of the main Ruby language reference book (Programming Ruby, aka "the Pickaxe") is available online for free (a few things have changed since then, but unless you are using 1.9.0 you probably won't run into many of them).

          If your concern with learning Ruby is just for Rails (which sounds like it may be the case), you might

      • Re: (Score:2)

        by epine ( 68316 )
        The debate about surface syntax goes all the way back to the APL / COBOL schism.

        There is no question that APL code was *too* dense for comfort. On the flip side, it was impossible to program in APL seriously without improving your thinking skills. APL is like the monolith in 2001. Fall asleep beside it, you wake up with a headache, smarter than you were before, forever permeated by the orthogonal "om" of higher dimensionality.

        COBOL's major intellectual contribution to the world was selling a lot of IBM's

        • Re: (Score:2)

          by Coryoth ( 254751 )

          Dijkstra defined the best criteria I've ever seen for what makes it possible to reason about a chunk of code (embodying an algorithm) successfully: can you point to any execution point and write down a correct invariant expression of what must be true whenever that execution point is crossed? This is the reason why I adopted the practice of writing code like this...

          For me it makes a language like Eiffel, which actually lets me write down invariants (for loops, for functions, and for objects) as part of the code that will (1) get used in testing (2) properly get handled in inheritance cases etc. (3) get used automatically in the API documentation. It makes things nicer for all involved (your assumed invariants will get checked in testing, and anyone else using your code will get the benefits of your documented invariants both in the documentation and in testing.

    • 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?
      • 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.
    • 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
      • I'll still probably come back to Rails at some point. I'll just need a month or so alone and a couple of hobby projects that I want to start, and that'll do it. I really do know that I'd love it if I took the time to learn it.

        You might check out Python, if you haven't. IMO, it's a great "generic" language. Say, you want to learn to use the WXWindows GUI toolkit, but you don't know which language you might need to use it in in the future; grab the python packages for it and go to town. 99% of your code
    • Ugh, another sad person who's clearly never been introduced to Smalltalk. Please. If you want to be a programmer (and maybe you don't, but if you do), you'll do yourself a *huge* favour by learning at least two languages: Smalltalk and Lisp. From there (plus the C/Algol camp) all else flows.

  • "[Open-source project] owes you nothing" arguments (Score:5, Insightful)

    by julesh ( 229690 ) on Thursday January 10, 2008 @05:33PM (#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 (Score:4, Insightful)

      by Deadbolt ( 102078 ) on Thursday January 10, 2008 @07:22PM (#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.
    • 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 aga
  • 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.

  • Like I always say (Score:5, Interesting)

    by hey! ( 33014 ) on Thursday January 10, 2008 @05: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.

    • 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 filt

      • Re: (Score:2)

        by hey! ( 33014 )
        I use both. If vi had a macro system that was as easy to use and powerful as Emacs, I'd use vi exclusively. If I weren't an old dog reluctant to learn new tricks, I'd use vi and perl for the stuff I use Emacs for, I suppose.

        Back in the day before GUIs and IDEs, Emacs was a great choice for a programmer's shell. It gave you windows (well, buffers) , and a pretty good shell language.
    • Hey! that one should make a rather good signature ...
  • 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
    • 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 the

      • Re: (Score:2)

        by Bri3D ( 584578 )
        This is basically exactly what I was trying to say. Flaming projects is lame, but the projects' zealot following flaming back claiming that "you should fix it yourself" is just as lame. Many people can't fix it themselves: they are USERS. The project can not listen to their users if they want, but their rabid fanbase shouldn't flame the other users simply because they're pointing out a project's shortcomings.

  • this article is useless (Score:4, Funny)

    by Some_Llama ( 763766 ) on Thursday January 10, 2008 @06:03PM (#21992174) Homepage Journal
    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?).
  • 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, *wh
    • > 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

      • Re: (Score:3, Interesting)

        by abes ( 82351 )
        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 is
        • > 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: (Score:2)

      by Fweeky ( 41046 )

      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 h

      • Re: (Score:2)

        by abes ( 82351 )
        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

        • Re: (Score:2)

          by Marcion ( 876801 )
          Linebreaks in Ruby are '\n'. In Slashdot you need to press Enter sometimes...

        • Re: (Score:2)

          by Fweeky ( 41046 )

          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

        • Yes, but as far as I know, RoR is the main package people use for Ruby

          If by "package" you mean "web framework" ("web application development" and "programming" aren't the same thing), you are probably right that RoR is, if not the most frequently used, at least the most widely-talked-about Ruby "package".

          versus Python which has 5-6 packages that I know of.

          Assuming, again, you mean "web frameworks" when you say "packages" (Ruby and Python each have thousands of packages available, most of which are not web

    • 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 ti

    • 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?

      You don't have to use the rails generators (including the "rails project-name" command that sets up the initial files and directory structure) if you don't want to. ISTR seeing some tutorials on building rails apps that way (along with ones on doing the

  • Speed and Protection (Score:4, Interesting)

    by Unoti ( 731964 ) on Thursday January 10, 2008 @08: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.

    • Re: (Score:2)

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

    • Re: (Score:2)

      by Marcion ( 876801 )
      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,

      • Re: (Score:2)

        by Unoti ( 731964 )

        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

        • As you say, it could just be that most web apps are one-offs.

          That's probably a factor. I think also (and both of these are related to them being one-offs, to a degree) a lot are either:
          1) Works-for-hire where the customer is owns the code.
          2) Custom development provided by someone who also is paid to manage the application once it is deployed, and the customer doesn't control the servers.

          In either case, trying to obscure the code from the customer is unnecessary (also, some incorporate code that is released

    • 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.
  • 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 gru

    • Re:My experience with RoR (Score:4, Informative)

      by Chandon Seldon ( 43083 ) on Thursday January 10, 2008 @11:08PM (#21995024) Homepage

      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.

  • And PHP deserved it more at the time but look at it now.... RoR will continue to mature and improve and people will use it when it is appropriate

    I don't use it cause I don't have time to learn it but if I hired a new developer who knew it well I'd definitely consider it for some projects.

Slashdot Top Deals

"The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell

Close