4 ms·

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 c

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.
  - mattmcknight 16y ago
    I know the fans will vote me down for saying this, but Github has greatly increased the level of fragmentation. With the exception of the core projects, people seem to fork more than they join forces to build a better gem. It's a very easy problem to solve though- build fewer dependencies on thinly supported libraries. That applies to all languages.
  - lg 16y ago
    sounds like cliki.
mechanical_fish 16y ago
How this article makes it clear that objective-c, java, or ... is more maintainable or easier to work with, is beyond me. They offer a perfectly good hypothesis, actually: Obj-C and Java are older and more mature. That has obvious drawbacks: It would be impossible to redesign Java, now, to the extent that Rails 3 just got redesigned. But, though certain Java libraries may suck, you can rest assured that they will suck in exactly the same way in five years. Not so with Rails. The platform moves, and you have to move as well. Another obvious point is that Rails (a) just went through a big version change, which just happens to coincide with a push toward Ruby 1.9; that double-whammy is bound to produce some yelps of pain; and (b) Rails is slowly maturing as well. Sooner or later Rails will be as mature as Java is today. How will we know when that has happened? When occasional gentle rants like this one turn into numerous, big, influential rants about the prospect of breaking backward compatibility; that will be a sign that the cost of change outweighs the benefit. And then it will be time for a new framework to inherit the role of young upstart...
- mrinterweb 16y ago
  At my work, I noticed a very similar issue to your point (a) when our iPhone app started to show a decent number of bugs when iOS4 dropped. 3rd party libraries may or may not be future proof and their support may or may not be available in the future.

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.
- mattmcknight 16y ago
  I know the fans will vote me down for saying this, but Github has greatly increased the level of fragmentation. With the exception of the core projects, people seem to fork more than they join forces to build a better gem. It's a very easy problem to solve though- build fewer dependencies on thinly supported libraries. That applies to all languages.
- lg 16y ago
  sounds like cliki.

mechanical_fish 16y ago

How this article makes it clear that objective-c, java, or ... is more maintainable or easier to work with, is beyond me. They offer a perfectly good hypothesis, actually: Obj-C and Java are older and more mature. That has obvious drawbacks: It would be impossible to redesign Java, now, to the extent that Rails 3 just got redesigned. But, though certain Java libraries may suck, you can rest assured that they will suck in exactly the same way in five years. Not so with Rails. The platform moves, and you have to move as well. Another obvious point is that Rails (a) just went through a big version change, which just happens to coincide with a push toward Ruby 1.9; that double-whammy is bound to produce some yelps of pain; and (b) Rails is slowly maturing as well. Sooner or later Rails will be as mature as Java is today. How will we know when that has happened? When occasional gentle rants like this one turn into numerous, big, influential rants about the prospect of breaking backward compatibility; that will be a sign that the cost of change outweighs the benefit. And then it will be time for a new framework to inherit the role of young upstart...

mrinterweb 16y ago
At my work, I noticed a very similar issue to your point (a) when our iPhone app started to show a decent number of bugs when iOS4 dropped. 3rd party libraries may or may not be future proof and their support may or may not be available in the future.