7 ms·

Writing Rails code makes me miss writing in Objective-C. Or C. Or Java. Or...

59 points by kennethchu 16y ago

marknutter 16y ago
First posterous is claiming other publishing solutions are obsoleted by them. Then they trash on the framework that allowed them to build their supposedly superior solution. Maybe these guys should just keep their mouths shut and work in silence - PR doesn't seem to be their strong suit.
- jacquesm 16y ago
  Looking critical at your tools is the hallmark of a good craftsman, and improving upon them is even better. I have absolutely no problem with this post, and why should it be PR ? It's not like he's speaking on behalf of the marketing department, just another hacker that produces code for a living. It's interesting actually that you could probably replace 'rails' and 'gems' with 'drupal' and 'modules' and still end up with a valid piece.
  - marknutter 16y ago
    If you're blogging publicly about the company you work for, it's PR. It's not 1980, PR doesn't just happen in the "marketing department." I agree that you could replace rails with drupal. Either way you'd be comparing an open source solution with a corporate backed framework.
  - aaronblohowiak 16y ago
    One of my favorite interview questions is: "What don't you like about your favorite tools?"
- gexla 16y ago
  This post is a bit confusing. At first glance his post appears to be directed at the Rails framework itself. Reading further, he seems to be referring to the overall ecosystem rather than Rails itself. That seems about right to me. The trunk and the major branches of the tree are generally solid. Minor branches and the leaves of the tree, not so much. I think the pace of the community creates a lot of leaves and minor branches. Anything really important will mature into a major branch and become solid.
- a4agarwal 16y ago
  Mark, in no way did i trash on the Rails framework. I basically said that I find 3rd party frameworks to be less reliable than I have seen on other platforms. I also said that being on Rails has still helped Posterous tremendously and I'm appreciative of that. Seems like you're trying to pick a fight here.
  - marknutter 16y ago
    Ok, so maybe it came off a little harsh and I apologize for that. I'll try to address your points a little better: I think you're focusing too much on the negative aspects of there being a lot of plugins and gems out there that are maybe not maintained that well. I run into the same issues all the time, and a lot of times I end up having to patch other people's code or roll my own solutions. But I'd rather there be a lot of someone good choices out there that are written in ruby and save me a ton of time than relying on a company to provide perfect solutions when they feel like it. Your headline was also a little sensationalist and considering how us rubyists love to preach about the joy of coding in ruby, a little on the trollish side. You can't say that coding in objective-c is as enjoyable as coding in ruby. Anyways, I hope that explains my reaction a little better.
    - a4agarwal 16y ago
      "You can't say that coding in objective-c is as enjoyable as coding in ruby" Really? I thought I was allowed to voice my opinions on my blog. Can you call something "trolling" if it's on your own blog?
      - marknutter 16y ago
        Um.. are you blogging for your own health or so that people will read what you write?
    - deleted 16y ago
      [deleted]
msbarnett 16y ago
I don't know, I've worked with a lot of buggy, poorly and not-at-all maintained iPhone, Java, C, C#, Javascript, etc libraries in my day too.
- Lewisham 16y ago
  My experience has shown if I want something in Java, I can usually find it from a source I think is reputable for stability and serving large numbers of customers: Apache, Codehaus, JBoss etc. If I want something in Ruby, I throw my chips in with some guy on GitHub (who was nice enough to pack it as a gem), usually choose based on whether it was good enough to at least come with half-decent documentation. I wouldn't necessarily agree that JS or non-Apple Obj-C libraries are all that much better than the Rails community effort though.
  - yesimahuman 16y ago
    There is something to be said for the amazing contributions the Apache group has made to open source. I pick Java mainly to benefit from their brilliance (I suppose I could use Scala, Groovy, etc. instead though).
0bfusct3 16y ago
I recently ditched rails for sinatra / padrino (mostly sinatra) due to the fact that if you want to do something off the beaten path, even in rails 3 it's a complete crap shoot of trying to tie together different pieces since it seems people only work with rails specific active_* parts - You spend more time wrestling libraries in rails 2-3 than actually doing work.
- sleight42 16y ago
  Thank you. I investigated padrino because of your comment. For those of us who prefer to avoid thick APIs yet appreciate sinatra's dsl, padrino looks very promising.
- dublinclontarf 16y ago
  Yes I'm also using sinatra, I love how clean and simple it is. I was trying to decide which gem to use for authentication, but couldn't find one that was simple enough (I'm fairly stupid) so I rolled my own. Sorry this is more of a ramble, I just really like sinatra, no sinatra-language to learn as in rails. I first used rails very early on, late 2003 no... maybe it was early 2004. Anyway I didn't like it then but it did save my ass in getting my college project done.
- dasil003 16y ago
  Not to take anything away from those microframeworks (they are awesome), but are you sure you're giving Rails 3 a chance? After all, they brought the merb devs into Rails core and radically re-architected the whole framework to support modularity and customization down to a very low level. From the extraction of ActiveModel, to the inclusion of Thor for generators, the decoupling of Prototype and an ambitious attempt at unobtrustive javascript, and the declaration of a publicly support API upon which even the framework itself is built, Rails 3 the biggest overhaul Rails has ever had. Have they succeeded in making it truly modular? I dunno, it's not released yet for one thing, but to say it's a crap shoot is a bit premature IMO.
durbin 16y ago
you should have taken the FriendFeed route and written your own blazing fast http server and framework. but no, you had to do it the lazy way. :)
jgoewert 16y ago
As odd as it sounds, I actually enjoy being able to and sometimes having to dip into other people's code. For a bunch of jars that I had to use in Java (or C++ or VB even), there would be some feature missing and I was plum out of luck and had to write something completely around what they were doing to make special cases. Now, with Ruby(and Rails), 99% of the time, I just grab the latest off Github and roll with it. I need to get better at forking in my changes so that others can share, but that is a self esteem problem of a different kind. Some of the time, I have seen solutions that I would never have though of implemented more gracefully than the brute steel glove I was going for. As for sachin, to me it looks like now that he has hit success, he is no longer hungry, and just biting the hand that feeds him out of aimlessness... or would this be excentricism? Looks like he updated to say how Rails allowed him to deploy as fast as they did. But still, the post sounds a lot like a duke crossing a river by running atop the heads of his subjects and then complaining when his coat tail and shoes got wet when he gets to the other side.
- aaronblohowiak 16y ago
  getting patches rejected and revising them until they get accepted is a good way to improve. fear is the mind-killer!
pwim 16y ago
Comparing the officially supported iOS SDK to 3rd party open source libraries is more than a bit disingenuous. I wonder what 3rd party libraries they are using for the iPhone. We've had the same experience he had with ruby libraries with 3rd party iPhone libraries.
- mrinterweb 16y ago
  Exactly what I was thinking. He also mentioned that the code base "is littered with monkey patches". I suppose the author does not realize that monkey patches can be very costly for maintenance. Just because you can monkey patch something doesn't necessarily mean you should.
  - kevinelliott 16y ago
    His point is that he HAS to monkey patch, but it clearly saying that it shouldn't have to be that way, if the underlying frameworks, plugins, and gems simply worked the way they should from the beginning.
    - mrinterweb 16y ago
      Why would they not submit bug fixes instead of monkey patching everything? If the library is supposed to work a certain way, then it is a bug and should be fixed. Bug fixes that make their way back to the main repository have a much lower maintenance cost than monkey patches. Every time you want to write a monkey patch, you should really ask yourself if it is worth the likely future maintenance costs.
      - kevinelliott 16y ago
        Perhaps because so many small project owners don't accept and merge in patches after people kindly submit pull requests containing proper patches. Albeit I see this for many areas of open source, not just Rails, such as ObjectiveResource, Three20, and Moonshine. I've had to wait as long as 3 or 4 months before even getting some feedback from some project admins, and that's after an email or two. We shouldn't have to beg to get our patches committed. Some project owners are just lazy, or have a very narrow view of what they want to accept for patches. And that's fine, it's their project. But that's more the reason why people monkey patch and not continue to submit patches, of which they'd need to monkey patch anyway to have the change effective immediately. After all, the projects are often still active, and do update with bug fixes, etc. And if you've only modified the tree, then you need to reimplement after you update. A monkey patch avoids this requirement, letting you get on to more important work.
joegaudet 16y ago
The thing I love most about Java versus working in Ruby / JS / anything else, is the IDE (read: eclipse). Right now we are building an app in SproutCore and I find my life spent mostly in TextMate, which is quite nice and their JSLint integration makes me very very very happy (hunting down missing commas is much easier this way). IMHO there is nothing like the refactoring tools in eclipse, and the code completion. Say what you want about the verbosity of Java, man is it nice cranking out 200 lines of code in 2 minutes with eclipse. And extract method / variable are just fantastic. .joe
- randomtask 16y ago
  Having used Eclipse for 6 weeks now I still despise it. Give me Visual Studio any day.
  - melling 16y ago
    Switch to IntelliJ: http://www.jetbrains.com/idea/index.html http://www.jetbrains.com/idea/index.html I even prefer Netbeans to Eclipse. http://netbeans.org http://netbeans.org There are 3 fully featured Java IDE's. You have only tried one of them.
    - steverb 16y ago
      Coming from VS I love netbeans for writing Rails code in. I became very spoiled by Visual Studio's ability to let you explore libraries via intellisence. Netbeans is the only Ruby IDE I've found that comes close to letting you do that.
      - daveoflynn 16y ago
        IDEA does that rather nicely. Its maven support can reduce your box to a paperweight when it reindexes, but other than that, it's a very nice product indeed. If you're not working on a complex codebase, it is total overkill though.
    - randomtask 16y ago
erikpukinskis 16y ago
Ruby platform developers are much more likely to trade stability (edit: that's API stability) for API quality than the platform devs in other communities. If you're an active refactorer, that's a good thing. It means those crufty APIs that you had to hack around, they get better, and you can clean up your code. But if you're a "write it and forget about it" kind of person, that's going to sound like extra work to you.
- modoc 16y ago
  I'm not sure I'm a "write it and forget about it" kind of person, but I don't want to have to spend time going back over an ever-increasing amount of existing code to fix stuff rather than writing new features/integrations/etc...
  - jshen 16y ago
    There's an easy solution to this, use bundler. Make your dependency a specific version of whatever gem you're using. Then, you don't have to worry about it changing until you want to upgrade it.
grasshoper 16y ago
With Django, I've learned to avoid anything that tries to do too much. Small apps or collections of code that aim to solve very specific problems seem to work with the least hassle. With a carefully defined and limited scope, these apps have a much easier time integrating into existing projects. You want something that handles OAuth. You want something that handles Facebook Connect. You do not want something that handles "integration with social networks" or anything so grandiose.
- FlemishBeeCycle 16y ago
  There's definitely a tendency among library/framework writers (not just Django) to include the kitchen sink. Ultimately it becomes problematic for the end-user and maintainer because more time is spent trying to understand everything that is going on (and often times removing unwanted functionality). It's really hard to find functionality in the "hammer,screwdriver" size - more often than not I get a whole tool set with all sorts of things I'll never need, and end up having to devote more time figuring out how it all "hangs together" with the rest of the system. It becomes a matter of whether you end up piecing your system together block by block or chiseling away to your end product.
silvertab 16y ago
I don't think it is specific to Rails! I find myself thinking the same with Django and lately, with Node.js... I'm talking mostly about the abundance of 3rd party librairies, and not really knowing which one to pick, which ones are still maintained etc...
- ams6110 16y ago
  Agree, and I'd throw in the example of Drupal: the core and a set of well written contributed modules are pretty decent. The rest of the contributed modules are mostly hacked together, poorly documented, half-working garbage.
  - dasil003 16y ago
    Drupal is orders of magnitude worse owing to the fact that the design philosophy is to create a powerful CMS that works out of the box with infinite customizability for hardcore developers. The result of these assumptions is an architecture that has a certain elegance, but is impossibly complex, where writing good modules means having tons of domain knowledge of the framework itself which does not transfer to any other form of web development. This approach makes a viable framework for a lot of low-budget projects (ie. clients with $5000 and a ridiculous laundry-list of general components), but compared to Rails, Django or other frameworks that focus on the basic building blocks that apply to the majority of web applications the results are horribly baroque.
  - megaman821 16y ago
    Django has a nice little saying, "Django is Python", meaning most of what is done is just the natural way to do things in Python. Now there are some really smart people that have wrote excellent Drupal modules but the majority of the modules aren't very good. Drupal provides a lot of Drupal functions that you need to know about to write good modules but technically aren't required to hack together something that kinda works.
- deleted 16y ago
  [deleted]
- 16y ago
mrinterweb 16y ago
I completely disagree with this article. Rails and ruby have a great amount of emphasis on TDD and BDD. I would be surprised if there is another open source community that is as focused on writing tests as the ruby community. The fact that their code base is "littered with monkey patches" might have something to do with the maintenance problems they are facing. I also don't see how this problem is specific to rails. Any project where you choose a ton of 3rd party libraries can be riddled with complexity and upgrade costs. How this article makes it clear that objective-c, java, or ... is more maintainable or easier to work with, is beyond me. I might be making a bit of a stretch here, but it sounds like Posterous might be complex software. Maybe the iPhone project he was working on did not have as much business logic and 3rd party libraries involved.
- sigzero 16y ago
  Perl definitely focuses on tests. I can't say "more" because that is subjective (although "I" think so). I would say the testing mindset is huge in the Perl community.
- saurik 16y ago
  Tests don't make code work. The problem I've experienced with the Ruby commumity is a constant belief in "this can't be that hard, I'll just throw one together". One day I traced a major bug in a client's app to their Ruby webserver not handling HTTP 100 Continue correctly... that simply should not happen. Pulling apart the server I found that most of the behavior was hardcoded for common clients, and certainly no one had bothered to read the HTTP spec. That wasn't an isolated problem, either, but I feel like I need not go into every single library bug I've run into. I simply did not get that feeling from the large number of Java libraries I used to use, many of which were actually the official reference implementation for the specification. ;( Bugs, yes; completely misunderstanding the problem domain and thereby not really being worth using, no.
  - a4agarwal 16y ago
    Thank you, I agree 100% and this is basically the gist of my post. That's why there is so much fragmentation in ruby gems. When one gem fails to do something, a developer thinks, "well I can just do this myself and do it better!" And do you end up with 10 gems that all do roughly the same thing, but not perfectly, each designed by and for a different person.
ephramzerb 16y ago
The only way I see this as a Rails problem is that Rails makes it easy to get saddled with lots of external dependencies. Otherwise, it's a problem with how external dependencies are managed. If it's not the number and quality of dependencies then it's the wrong type. I usually stay away from gems that provide syntactic sugar or provide an alternative to ruby / rails defaults. If I'm using 5% of some library, I'd rather write it myself and only address the 5% that I need. If it's not maintained, I stay away. Etc. A little discipline on what gems get included would go a long way to solving the perceived problems. Gems are generally designed to solve a much more generic version of the problem you're trying to solve and maybe not even the exact same problem, if you're messing with the innards too much, that gem is probably not a good enough fit. Less is always better when it comes to dependencies.
- Goladus 16y ago
  Less is always better when it comes to dependencies. Yes but I think the point here is that the environment you choose can make it hard or easy to avoid dependencies. I totally agree on "less is better with dependencies" but there are clearly many programmers who don't want to "reinvent the wheel" and always use libraries first. And a lot of times, the programmers willing to piece together lots of different community libraries will be a lot faster initially. They're just incurring technical debt. If you're part of a team of these programmers, you might not actually be able to convince everyone that "less is always better" with dependencies.
  - mattmcknight 16y ago
    So, it's not Rails that's the problem, it's the post modern software developers that would rather use a buggy, thinly supported library than try to write their own code...
    - Goladus 16y ago
      I'm not saying rails is a problem, but that there's value in the large, stable and well-tested standard library.
  - 16y ago
a4agarwal 16y ago
Maybe there needs to be "Rails gems app store" where we only allow gems that have gone through an approval process :). (j/k :) )
mhd 16y ago
The big difference here isn't about the languages, it seems to be about the technologies. Comparing web libraries (esp. add-ons/plugins) with anything else in any language will have a pretty devastating result. I'm not entirely sure why. It can't be just the fact that nowadays web programming is often an entry-level job, so often you have to wade through the fallout of "My first Lightbox". Maybe it's the idea of packaging something you just whipped up for a project for public consumption.
dasil003 16y ago
The post-Rails Ruby ecosystem is definitely a high-energy place where stability is traded for rapid development. Like any community it has its idiosyncrasies. Rubyists compared to Pythonistas perhaps monkey patch a bit too much, are overly fond of novelty, and tend to have pretty strong yet sometimes objectively unsupportable ideas about the proper way to do testing. All of these things have annoyed me from time to time over the past 5 years of working almost exclusively with Ruby. However the community also has its strengths which are extremely appealing for passionate programmers. For one thing, the fact that Rails emphasizes improvement over maturity has made Rails 3 an amazingly modular framework, able to better fit enterprise requirements better than 2004's DHH ever would have wanted or acknowledged the need for. Also, consider the rise of the RSpec and Cucumber frameworks despite the fact that Test::Unit and Mocha already had the bases pretty well covered. In other communities, yes, you get better maintained libraries, but you also get stagnation from having too high a bar for new ideas. In Ruby you have to deal with constant deprecation, but at least you get better chances that your entire ecosystem won't be obsoleted by the next hot language or framework.
- Jd 16y ago
  Is a better fit a good fit?
  - dasil003 16y ago
    Well, if you're asking about the ability of a language to prevent the ability of a corporate army of 1000 developers to blow it's collective foot off, then no, Ruby and almost every other language will forever pale in comparison to Java. On the other hand, if you're talking about the ability to mix, match, configure and replace components of Rails in order to meet your particular requirements, then Rails 3 shows real promise, though it's not yet officially released and a lot of the modularity needs battle-testing.
    - jrockway 16y ago
      modularity needs battle-testing Don't worry, the Perl and Python web frameworks have been doing this for years, and it works great.
jcromartie 16y ago
I think "app store" is a bit of hyperbole. What Ruby needs is some curated Gem repositories. This would be more along the lines of Apache commons or the various centralized Maven repos, or the clojure-contrib project.
aaronblohowiak 16y ago
I think the attitude is different. Projects with a homepage outside of github I tend to treat as black boxes. Projects that are just up there with a README, I tend to take as someone saying "here's this thing I built, use the source if you'd like." The difference with the latter is that I do not expect support or a community. I consider the plugins and gems that are like that to be under my ownership, they are just saving me the time of writing the majority of the code. While I do have to fork and monkeypatch a lot, that is still faster than DIY. When effort to "make right" exceeds the effort to rewrite, I'll rewrite, simple as that. I think the "just put it out there" attitude is useful. We should also be better as a community when we give up on a project, though the metrics that gh provides give good ideas about the activity and life around something. If anything, reading through 10 implementations of slugs lets you know the pros and cons that you may not have considered before you go on and roll your own. In short: in ruby community, libraries are starting points, not black boxes.
jrockway 16y ago
Wait, what? This is what I have to do in any language. Writing Perl? Yup, have to read my libraries. Writing Haskell? Yup, source diving is helpful! Writing Java? I have to single-step into the internals to get my programs to work right! Understanding your libraries and their implementation is a great thing. Once you realize that library code is not a magical black box, and is instead very much like the code you are writing, you can really become a productive programmer. ("But what about abstraction! If I have to understand my libaries, they're not abstract enough!" Wrong. Abstraction prevents parts of your program from knowing about each other. You, the programmer, still have to know how each part works. Abstraction means you only have to actively think about once piece at a time -- nothing more.) The Posterous codebase is littered with monkey patches, modifying gems to work as we need them to. Yeah, you know that "fork me" button on Github? You click it, then you edit the code, then the bug is fixed for every single person on Earth. That's the point of free software; if there's a bug, you squish it and move on. (I do this all the time. Does it take time to fork someone's project, fix the code a bit, and send them a pull request? Yes. But it's worth it, because now you have a robust and permanent fix... and a community! Monkey patching is for monkeys. Collaborating is what humans do.)
- billmcneale 16y ago
  What you're describing with the 'fork' button is incorrect. When you fix something on your own branch, nobody on earth but yourself benefits from it. For this to work, you have to contribute your work back and (the hard part), the original owners have to accept it. And that's where open source usually breaks down. Another point of the original post is that monkey patching is the kiss of death of many Ruby and Ruby on Rails projects.
  - jrockway 16y ago
    "Usually"? I can't think of any change I've ever made to an open source project that hasn't been accepted. This ranges from random Perl modules to Emacs and the Linux kernel. Contributing is as easy as sending an email!
Groxx 16y ago
Given that the title of the post is: >Rails needs an approval process for Gems I have a solution: set up a gem repo that does just that, and see if people like it. Gems are distributed by nature, anyone can host a repository. Though I'd say the utter lack of such a repository's existence (as far as I'm aware) is a sign there's little demand for one.
xiaoma 16y ago
It's too bad posterous is blocked by the Chinese firewall.
ollysb 16y ago
The java ecosystem is optimised for maturity, ruby the cutting edge. That is to say that the cutting edge java libraries are considerably more painful to use than the cutting edge ruby libraries. If you're the kind of team that gravitates towards newer libraries than ruby is going to be a better experience. If you prefer to plod along with good ol' faithful than java is the way to go.
maheshs 16y ago
There are only two kinds of languages: the ones people complain about and the ones nobody uses - Bjarne Stroustrup

59 points by kennethchu 16y ago

First posterous is claiming other publishing solutions are obsoleted by them. Then they trash on the framework that allowed them to build their supposedly superior solution. Maybe these guys should just keep their mouths shut and work in silence - PR doesn't seem to be their strong suit.

jacquesm 16y ago
Looking critical at your tools is the hallmark of a good craftsman, and improving upon them is even better. I have absolutely no problem with this post, and why should it be PR ? It's not like he's speaking on behalf of the marketing department, just another hacker that produces code for a living. It's interesting actually that you could probably replace 'rails' and 'gems' with 'drupal' and 'modules' and still end up with a valid piece.
- marknutter 16y ago
  If you're blogging publicly about the company you work for, it's PR. It's not 1980, PR doesn't just happen in the "marketing department." I agree that you could replace rails with drupal. Either way you'd be comparing an open source solution with a corporate backed framework.
- aaronblohowiak 16y ago
  One of my favorite interview questions is: "What don't you like about your favorite tools?"
gexla 16y ago
This post is a bit confusing. At first glance his post appears to be directed at the Rails framework itself. Reading further, he seems to be referring to the overall ecosystem rather than Rails itself. That seems about right to me. The trunk and the major branches of the tree are generally solid. Minor branches and the leaves of the tree, not so much. I think the pace of the community creates a lot of leaves and minor branches. Anything really important will mature into a major branch and become solid.
a4agarwal 16y ago
Mark, in no way did i trash on the Rails framework. I basically said that I find 3rd party frameworks to be less reliable than I have seen on other platforms. I also said that being on Rails has still helped Posterous tremendously and I'm appreciative of that. Seems like you're trying to pick a fight here.
- marknutter 16y ago
  Ok, so maybe it came off a little harsh and I apologize for that. I'll try to address your points a little better: I think you're focusing too much on the negative aspects of there being a lot of plugins and gems out there that are maybe not maintained that well. I run into the same issues all the time, and a lot of times I end up having to patch other people's code or roll my own solutions. But I'd rather there be a lot of someone good choices out there that are written in ruby and save me a ton of time than relying on a company to provide perfect solutions when they feel like it. Your headline was also a little sensationalist and considering how us rubyists love to preach about the joy of coding in ruby, a little on the trollish side. You can't say that coding in objective-c is as enjoyable as coding in ruby. Anyways, I hope that explains my reaction a little better.
  - a4agarwal 16y ago
    "You can't say that coding in objective-c is as enjoyable as coding in ruby" Really? I thought I was allowed to voice my opinions on my blog. Can you call something "trolling" if it's on your own blog?
    - marknutter 16y ago
      Um.. are you blogging for your own health or so that people will read what you write?
  - deleted 16y ago
    [deleted]

msbarnett 16y ago

I don't know, I've worked with a lot of buggy, poorly and not-at-all maintained iPhone, Java, C, C#, Javascript, etc libraries in my day too.

Lewisham 16y ago
My experience has shown if I want something in Java, I can usually find it from a source I think is reputable for stability and serving large numbers of customers: Apache, Codehaus, JBoss etc. If I want something in Ruby, I throw my chips in with some guy on GitHub (who was nice enough to pack it as a gem), usually choose based on whether it was good enough to at least come with half-decent documentation. I wouldn't necessarily agree that JS or non-Apple Obj-C libraries are all that much better than the Rails community effort though.
- yesimahuman 16y ago
  There is something to be said for the amazing contributions the Apache group has made to open source. I pick Java mainly to benefit from their brilliance (I suppose I could use Scala, Groovy, etc. instead though).

0bfusct3 16y ago

I recently ditched rails for sinatra / padrino (mostly sinatra) due to the fact that if you want to do something off the beaten path, even in rails 3 it's a complete crap shoot of trying to tie together different pieces since it seems people only work with rails specific active_* parts - You spend more time wrestling libraries in rails 2-3 than actually doing work.

sleight42 16y ago
Thank you. I investigated padrino because of your comment. For those of us who prefer to avoid thick APIs yet appreciate sinatra's dsl, padrino looks very promising.
dublinclontarf 16y ago
Yes I'm also using sinatra, I love how clean and simple it is. I was trying to decide which gem to use for authentication, but couldn't find one that was simple enough (I'm fairly stupid) so I rolled my own. Sorry this is more of a ramble, I just really like sinatra, no sinatra-language to learn as in rails. I first used rails very early on, late 2003 no... maybe it was early 2004. Anyway I didn't like it then but it did save my ass in getting my college project done.
dasil003 16y ago
Not to take anything away from those microframeworks (they are awesome), but are you sure you're giving Rails 3 a chance? After all, they brought the merb devs into Rails core and radically re-architected the whole framework to support modularity and customization down to a very low level. From the extraction of ActiveModel, to the inclusion of Thor for generators, the decoupling of Prototype and an ambitious attempt at unobtrustive javascript, and the declaration of a publicly support API upon which even the framework itself is built, Rails 3 the biggest overhaul Rails has ever had. Have they succeeded in making it truly modular? I dunno, it's not released yet for one thing, but to say it's a crap shoot is a bit premature IMO.

durbin 16y ago

you should have taken the FriendFeed route and written your own blazing fast http server and framework. but no, you had to do it the lazy way. :)

jgoewert 16y ago

As odd as it sounds, I actually enjoy being able to and sometimes having to dip into other people's code. For a bunch of jars that I had to use in Java (or C++ or VB even), there would be some feature missing and I was plum out of luck and had to write something completely around what they were doing to make special cases. Now, with Ruby(and Rails), 99% of the time, I just grab the latest off Github and roll with it. I need to get better at forking in my changes so that others can share, but that is a self esteem problem of a different kind. Some of the time, I have seen solutions that I would never have though of implemented more gracefully than the brute steel glove I was going for. As for sachin, to me it looks like now that he has hit success, he is no longer hungry, and just biting the hand that feeds him out of aimlessness... or would this be excentricism? Looks like he updated to say how Rails allowed him to deploy as fast as they did. But still, the post sounds a lot like a duke crossing a river by running atop the heads of his subjects and then complaining when his coat tail and shoes got wet when he gets to the other side.

aaronblohowiak 16y ago
getting patches rejected and revising them until they get accepted is a good way to improve. fear is the mind-killer!

pwim 16y ago

Comparing the officially supported iOS SDK to 3rd party open source libraries is more than a bit disingenuous. I wonder what 3rd party libraries they are using for the iPhone. We've had the same experience he had with ruby libraries with 3rd party iPhone libraries.

mrinterweb 16y ago
Exactly what I was thinking. He also mentioned that the code base "is littered with monkey patches". I suppose the author does not realize that monkey patches can be very costly for maintenance. Just because you can monkey patch something doesn't necessarily mean you should.
- kevinelliott 16y ago
  His point is that he HAS to monkey patch, but it clearly saying that it shouldn't have to be that way, if the underlying frameworks, plugins, and gems simply worked the way they should from the beginning.
  - mrinterweb 16y ago
    Why would they not submit bug fixes instead of monkey patching everything? If the library is supposed to work a certain way, then it is a bug and should be fixed. Bug fixes that make their way back to the main repository have a much lower maintenance cost than monkey patches. Every time you want to write a monkey patch, you should really ask yourself if it is worth the likely future maintenance costs.
    - kevinelliott 16y ago
      Perhaps because so many small project owners don't accept and merge in patches after people kindly submit pull requests containing proper patches. Albeit I see this for many areas of open source, not just Rails, such as ObjectiveResource, Three20, and Moonshine. I've had to wait as long as 3 or 4 months before even getting some feedback from some project admins, and that's after an email or two. We shouldn't have to beg to get our patches committed. Some project owners are just lazy, or have a very narrow view of what they want to accept for patches. And that's fine, it's their project. But that's more the reason why people monkey patch and not continue to submit patches, of which they'd need to monkey patch anyway to have the change effective immediately. After all, the projects are often still active, and do update with bug fixes, etc. And if you've only modified the tree, then you need to reimplement after you update. A monkey patch avoids this requirement, letting you get on to more important work.

joegaudet 16y ago

The thing I love most about Java versus working in Ruby / JS / anything else, is the IDE (read: eclipse). Right now we are building an app in SproutCore and I find my life spent mostly in TextMate, which is quite nice and their JSLint integration makes me very very very happy (hunting down missing commas is much easier this way). IMHO there is nothing like the refactoring tools in eclipse, and the code completion. Say what you want about the verbosity of Java, man is it nice cranking out 200 lines of code in 2 minutes with eclipse. And extract method / variable are just fantastic. .joe

randomtask 16y ago
Having used Eclipse for 6 weeks now I still despise it. Give me Visual Studio any day.
- melling 16y ago
  Switch to IntelliJ: http://www.jetbrains.com/idea/index.html http://www.jetbrains.com/idea/index.html I even prefer Netbeans to Eclipse. http://netbeans.org http://netbeans.org There are 3 fully featured Java IDE's. You have only tried one of them.
  - steverb 16y ago
    Coming from VS I love netbeans for writing Rails code in. I became very spoiled by Visual Studio's ability to let you explore libraries via intellisence. Netbeans is the only Ruby IDE I've found that comes close to letting you do that.
    - daveoflynn 16y ago
      IDEA does that rather nicely. Its maven support can reduce your box to a paperweight when it reindexes, but other than that, it's a very nice product indeed. If you're not working on a complex codebase, it is total overkill though.
  - randomtask 16y ago

erikpukinskis 16y ago

Ruby platform developers are much more likely to trade stability (edit: that's API stability) for API quality than the platform devs in other communities. If you're an active refactorer, that's a good thing. It means those crufty APIs that you had to hack around, they get better, and you can clean up your code. But if you're a "write it and forget about it" kind of person, that's going to sound like extra work to you.

modoc 16y ago
I'm not sure I'm a "write it and forget about it" kind of person, but I don't want to have to spend time going back over an ever-increasing amount of existing code to fix stuff rather than writing new features/integrations/etc...
- jshen 16y ago
  There's an easy solution to this, use bundler. Make your dependency a specific version of whatever gem you're using. Then, you don't have to worry about it changing until you want to upgrade it.

grasshoper 16y ago

With Django, I've learned to avoid anything that tries to do too much. Small apps or collections of code that aim to solve very specific problems seem to work with the least hassle. With a carefully defined and limited scope, these apps have a much easier time integrating into existing projects. You want something that handles OAuth. You want something that handles Facebook Connect. You do not want something that handles "integration with social networks" or anything so grandiose.

FlemishBeeCycle 16y ago
There's definitely a tendency among library/framework writers (not just Django) to include the kitchen sink. Ultimately it becomes problematic for the end-user and maintainer because more time is spent trying to understand everything that is going on (and often times removing unwanted functionality). It's really hard to find functionality in the "hammer,screwdriver" size - more often than not I get a whole tool set with all sorts of things I'll never need, and end up having to devote more time figuring out how it all "hangs together" with the rest of the system. It becomes a matter of whether you end up piecing your system together block by block or chiseling away to your end product.

silvertab 16y ago

I don't think it is specific to Rails! I find myself thinking the same with Django and lately, with Node.js... I'm talking mostly about the abundance of 3rd party librairies, and not really knowing which one to pick, which ones are still maintained etc...

ams6110 16y ago
Agree, and I'd throw in the example of Drupal: the core and a set of well written contributed modules are pretty decent. The rest of the contributed modules are mostly hacked together, poorly documented, half-working garbage.
- dasil003 16y ago
  Drupal is orders of magnitude worse owing to the fact that the design philosophy is to create a powerful CMS that works out of the box with infinite customizability for hardcore developers. The result of these assumptions is an architecture that has a certain elegance, but is impossibly complex, where writing good modules means having tons of domain knowledge of the framework itself which does not transfer to any other form of web development. This approach makes a viable framework for a lot of low-budget projects (ie. clients with $5000 and a ridiculous laundry-list of general components), but compared to Rails, Django or other frameworks that focus on the basic building blocks that apply to the majority of web applications the results are horribly baroque.
- megaman821 16y ago
  Django has a nice little saying, "Django is Python", meaning most of what is done is just the natural way to do things in Python. Now there are some really smart people that have wrote excellent Drupal modules but the majority of the modules aren't very good. Drupal provides a lot of Drupal functions that you need to know about to write good modules but technically aren't required to hack together something that kinda works.
deleted 16y ago
[deleted]
16y ago

mrinterweb 16y ago

I completely disagree with this article. Rails and ruby have a great amount of emphasis on TDD and BDD. I would be surprised if there is another open source community that is as focused on writing tests as the ruby community. The fact that their code base is "littered with monkey patches" might have something to do with the maintenance problems they are facing. I also don't see how this problem is specific to rails. Any project where you choose a ton of 3rd party libraries can be riddled with complexity and upgrade costs. How this article makes it clear that objective-c, java, or ... is more maintainable or easier to work with, is beyond me. I might be making a bit of a stretch here, but it sounds like Posterous might be complex software. Maybe the iPhone project he was working on did not have as much business logic and 3rd party libraries involved.

sigzero 16y ago
Perl definitely focuses on tests. I can't say "more" because that is subjective (although "I" think so). I would say the testing mindset is huge in the Perl community.
saurik 16y ago
Tests don't make code work. The problem I've experienced with the Ruby commumity is a constant belief in "this can't be that hard, I'll just throw one together". One day I traced a major bug in a client's app to their Ruby webserver not handling HTTP 100 Continue correctly... that simply should not happen. Pulling apart the server I found that most of the behavior was hardcoded for common clients, and certainly no one had bothered to read the HTTP spec. That wasn't an isolated problem, either, but I feel like I need not go into every single library bug I've run into. I simply did not get that feeling from the large number of Java libraries I used to use, many of which were actually the official reference implementation for the specification. ;( Bugs, yes; completely misunderstanding the problem domain and thereby not really being worth using, no.
- a4agarwal 16y ago
  Thank you, I agree 100% and this is basically the gist of my post. That's why there is so much fragmentation in ruby gems. When one gem fails to do something, a developer thinks, "well I can just do this myself and do it better!" And do you end up with 10 gems that all do roughly the same thing, but not perfectly, each designed by and for a different person.

ephramzerb 16y ago

The only way I see this as a Rails problem is that Rails makes it easy to get saddled with lots of external dependencies. Otherwise, it's a problem with how external dependencies are managed. If it's not the number and quality of dependencies then it's the wrong type. I usually stay away from gems that provide syntactic sugar or provide an alternative to ruby / rails defaults. If I'm using 5% of some library, I'd rather write it myself and only address the 5% that I need. If it's not maintained, I stay away. Etc. A little discipline on what gems get included would go a long way to solving the perceived problems. Gems are generally designed to solve a much more generic version of the problem you're trying to solve and maybe not even the exact same problem, if you're messing with the innards too much, that gem is probably not a good enough fit. Less is always better when it comes to dependencies.

Goladus 16y ago
Less is always better when it comes to dependencies. Yes but I think the point here is that the environment you choose can make it hard or easy to avoid dependencies. I totally agree on "less is better with dependencies" but there are clearly many programmers who don't want to "reinvent the wheel" and always use libraries first. And a lot of times, the programmers willing to piece together lots of different community libraries will be a lot faster initially. They're just incurring technical debt. If you're part of a team of these programmers, you might not actually be able to convince everyone that "less is always better" with dependencies.
- mattmcknight 16y ago
  So, it's not Rails that's the problem, it's the post modern software developers that would rather use a buggy, thinly supported library than try to write their own code...
  - Goladus 16y ago
    I'm not saying rails is a problem, but that there's value in the large, stable and well-tested standard library.
- 16y ago

a4agarwal 16y ago

Maybe there needs to be "Rails gems app store" where we only allow gems that have gone through an approval process :). (j/k :) )

mhd 16y ago

The big difference here isn't about the languages, it seems to be about the technologies. Comparing web libraries (esp. add-ons/plugins) with anything else in any language will have a pretty devastating result. I'm not entirely sure why. It can't be just the fact that nowadays web programming is often an entry-level job, so often you have to wade through the fallout of "My first Lightbox". Maybe it's the idea of packaging something you just whipped up for a project for public consumption.

dasil003 16y ago

The post-Rails Ruby ecosystem is definitely a high-energy place where stability is traded for rapid development. Like any community it has its idiosyncrasies. Rubyists compared to Pythonistas perhaps monkey patch a bit too much, are overly fond of novelty, and tend to have pretty strong yet sometimes objectively unsupportable ideas about the proper way to do testing. All of these things have annoyed me from time to time over the past 5 years of working almost exclusively with Ruby. However the community also has its strengths which are extremely appealing for passionate programmers. For one thing, the fact that Rails emphasizes improvement over maturity has made Rails 3 an amazingly modular framework, able to better fit enterprise requirements better than 2004's DHH ever would have wanted or acknowledged the need for. Also, consider the rise of the RSpec and Cucumber frameworks despite the fact that Test::Unit and Mocha already had the bases pretty well covered. In other communities, yes, you get better maintained libraries, but you also get stagnation from having too high a bar for new ideas. In Ruby you have to deal with constant deprecation, but at least you get better chances that your entire ecosystem won't be obsoleted by the next hot language or framework.

Jd 16y ago
Is a better fit a good fit?
- dasil003 16y ago
  Well, if you're asking about the ability of a language to prevent the ability of a corporate army of 1000 developers to blow it's collective foot off, then no, Ruby and almost every other language will forever pale in comparison to Java. On the other hand, if you're talking about the ability to mix, match, configure and replace components of Rails in order to meet your particular requirements, then Rails 3 shows real promise, though it's not yet officially released and a lot of the modularity needs battle-testing.
  - jrockway 16y ago
    modularity needs battle-testing Don't worry, the Perl and Python web frameworks have been doing this for years, and it works great.

jcromartie 16y ago

I think "app store" is a bit of hyperbole. What Ruby needs is some curated Gem repositories. This would be more along the lines of Apache commons or the various centralized Maven repos, or the clojure-contrib project.

aaronblohowiak 16y ago

I think the attitude is different. Projects with a homepage outside of github I tend to treat as black boxes. Projects that are just up there with a README, I tend to take as someone saying "here's this thing I built, use the source if you'd like." The difference with the latter is that I do not expect support or a community. I consider the plugins and gems that are like that to be under my ownership, they are just saving me the time of writing the majority of the code. While I do have to fork and monkeypatch a lot, that is still faster than DIY. When effort to "make right" exceeds the effort to rewrite, I'll rewrite, simple as that. I think the "just put it out there" attitude is useful. We should also be better as a community when we give up on a project, though the metrics that gh provides give good ideas about the activity and life around something. If anything, reading through 10 implementations of slugs lets you know the pros and cons that you may not have considered before you go on and roll your own. In short: in ruby community, libraries are starting points, not black boxes.

jrockway 16y ago

Wait, what? This is what I have to do in any language. Writing Perl? Yup, have to read my libraries. Writing Haskell? Yup, source diving is helpful! Writing Java? I have to single-step into the internals to get my programs to work right! Understanding your libraries and their implementation is a great thing. Once you realize that library code is not a magical black box, and is instead very much like the code you are writing, you can really become a productive programmer. ("But what about abstraction! If I have to understand my libaries, they're not abstract enough!" Wrong. Abstraction prevents parts of your program from knowing about each other. You, the programmer, still have to know how each part works. Abstraction means you only have to actively think about once piece at a time -- nothing more.) The Posterous codebase is littered with monkey patches, modifying gems to work as we need them to. Yeah, you know that "fork me" button on Github? You click it, then you edit the code, then the bug is fixed for every single person on Earth. That's the point of free software; if there's a bug, you squish it and move on. (I do this all the time. Does it take time to fork someone's project, fix the code a bit, and send them a pull request? Yes. But it's worth it, because now you have a robust and permanent fix... and a community! Monkey patching is for monkeys. Collaborating is what humans do.)

billmcneale 16y ago
What you're describing with the 'fork' button is incorrect. When you fix something on your own branch, nobody on earth but yourself benefits from it. For this to work, you have to contribute your work back and (the hard part), the original owners have to accept it. And that's where open source usually breaks down. Another point of the original post is that monkey patching is the kiss of death of many Ruby and Ruby on Rails projects.
- jrockway 16y ago
  "Usually"? I can't think of any change I've ever made to an open source project that hasn't been accepted. This ranges from random Perl modules to Emacs and the Linux kernel. Contributing is as easy as sending an email!

Groxx 16y ago

Given that the title of the post is: >Rails needs an approval process for Gems I have a solution: set up a gem repo that does just that, and see if people like it. Gems are distributed by nature, anyone can host a repository. Though I'd say the utter lack of such a repository's existence (as far as I'm aware) is a sign there's little demand for one.

xiaoma 16y ago

It's too bad posterous is blocked by the Chinese firewall.

ollysb 16y ago

The java ecosystem is optimised for maturity, ruby the cutting edge. That is to say that the cutting edge java libraries are considerably more painful to use than the cutting edge ruby libraries. If you're the kind of team that gravitates towards newer libraries than ruby is going to be a better experience. If you prefer to plod along with good ol' faithful than java is the way to go.

maheshs 16y ago

There are only two kinds of languages: the ones people complain about and the ones nobody uses - Bjarne Stroustrup