5 ms·

Aren't all frameworks like this? The designer picks what he/she thinks is the best architecture and builds it around that idea. That's why there are a thousand

Aren't all frameworks like this? The designer picks what he/she thinks is the best architecture and builds it around that idea. That's why there are a thousand different frameworks. I think DHH is experiencing what I call "Linus Hell." Which is the hell Torvalds has to go through every n amount of time when dealing with obtuse programmers.

crusso 14y ago
I don't think that DHH is feeling that his experience is any different than other maintainers. He's just trying to explain it to the masses. Maybe he's hoping that a few borderline whiners will catch a clue and decide to put up or shut up... maybe he's just venting. Regardless, I sympathize with him. I love rails. I love where his leadership has taken the framework steadily over the years.
- orangethirty 14y ago
  Re: Whiners. They never shut up. :) Given the size and pop culture around Rails I think he gets to deal with more stuff than the usual maintainer. I mean, there are people who actively celebrate when there is a security issue in Rails. When github was hacked due to a foolish mistake people where celebrating! This is the sort of thing that keeps me from joining any Framework community. Fanboyism.
- steveklabnik 14y ago
  > that a few borderline whiners will catch a clue Just so you know, those 'borderline whiners' are mostly other members of the core team.
  - mattmcknight 14y ago
    Clearly this post is not primarily aimed at the core team, but the random people harassing him on Twitter and elsewhere.
fbuilesv 14y ago
Not necessarily. Some authors think that the best thing they can provide is a small framework that does the most basic stuff and then you plug-in the rest of the components you need. An example of this is Sinatra where you get a router, some helpers and not much more. You choose your ORM, testing library, etc. Others (like Rails) choose to include the 8 AA batteries. In general, this is aligned with the author way of thinking and it also applies to stuff like languages (think C vs. Java) or even window/desktop environments (Fluxbox vs. Gnome).
deleted 14y ago
[deleted]
Xylakant 14y ago
Not necessarily. Padrino [http://www.padrinorb.com/ http://www.padrinorb.com/] builds a rails-style framework from components which are exchangeable. You get to pick your testing library, the templating engine and the orm of your choice. If you don't like the router you can swap it out. It offer more flexibility and freedom of choice in that respect, but on the flip side doesn't achieve the same level of deep integration. It's more "a la carte" in DHH words.
- dphase 14y ago
  Padrino is excellent and does not get enough coverage.
- tomjakubowski 14y ago
  Rails allows you to choose your own testing framework [1][2][3] and plugins[4][5][6], templating engine[7][8][9], and ORM[10]. It's my understanding that before Rails 3, swapping out many default Rails was a bit hacky, but it's pretty standard now. [1]: https://github.com/rspec/rspec-rails https://github.com/rspec/rspec-rails [2]: https://github.com/cucumber/cucumber-rails https://github.com/cucumber/cucumber-rails [3]: https://github.com/thoughtbot/shoulda https://github.com/thoughtbot/shoulda [4]: https://github.com/thoughtbot/factory_girl https://github.com/thoughtbot/factory_girl [5]: https://github.com/nulldb/nulldb https://github.com/nulldb/nulldb [6]: https://github.com/notahat/machinist https://github.com/notahat/machinist [7]: https://github.com/haml/haml https://github.com/haml/haml [8]: https://github.com/josh/mustache-rails https://github.com/josh/mustache-rails [9]: https://github.com/stonean/slim https://github.com/stonean/slim [10]: https://github.com/brasten/sequel-rails https://github.com/brasten/sequel-rails [11]: https://github.com/datamapper/dm-rails https://github.com/datamapper/dm-rails [12]: http://mongomapper.com/documentation/getting-started/rails.html http://mongomapper.com/documentation/getting-started/rails.h...
  - Xylakant 14y ago
    I know that and it's been posted often enough. However, the rails approach is fundamentally different from the padrino approach: Rails is very opinionated about which component should be used - as DHH stresses in his blog post. Padrino asks you when you generate your project. Both approaches have their advantages and disadvantages.
regularfry 14y ago
From where I'm sitting, this isn't to do with the framework much. It's more that DHH has made a coding decision based on an assumption about how the organisation using the framework does its development: specifically in this case that it's forced all its developers to use the same ruby and gems provisioning system. That's valid for 37S, and completely wrong for a whole bunch of other places. DHH then says: It's imo an anti-pattern to have developers working on the same app use different tool chains like that. If your organization can't decide on rvm vs rbenv, then you have deeper problems than what binstubs are checked in to your repository. and Second, if you are unable to use the same Ruby manager in production and development, I feel bad for you. We rely on .rbenv-version to ensure that the same Ruby point release is used in both places. Now, say you don't force all your developers through the same toolchain, or you're not using the same Ruby manager in production and development. Given these opinions, how likely is it that at some point there's going to be a Rails design decision based on them which isn't so trivial, and which causes a lot of pain for anyone on the wrong side of them? The fear is that you could be organisationally barred from using Rails for reasons that have been totally irrelevant before now. These aren't the cut-and-dry truths that DHH is presenting, although I can see the logic in them, and I think this problem has only happened because of binstubs, which are a really bad idea.
- orangethirty 14y ago
  Hasn't Rails always been like that? The "Trust us, we know what's best for you" line of thinking. Its part of their marketing, because they sell the "magic" of Rails. It drives people to Rails and it drives people away from Rails. Plus, anyone who uses Rails in production and does not agree with the way the Rails people run things is just asking for trouble. When you choose a framework you dont do so because its popular or nice. You first check the culture behimd the development team and their credos. If they believe in backwards compatibility and you value that, then pick that one. But dont pick something becuase its cool and then argue when the people in charge make decisions that make no sense for you. Its your problem, not theirs. DHH can wake up one day and say that Rails will now be written in Algol. You either re-factor to Algol or jump ship. Either way, you were doomed from the start. Thats why Im always wary of programmers who join into a framework too quickly. Not aimed at anyone in particular.
mylittlepony 14y ago
This is where interfaces come in, in OOP. Too bad Ruby does not have interfaces, and more importantly, Ruby people don't really understand interfaces and say they don't need them. And then they dare mock PHP, lol.
cookiecaper 14y ago
No. Others have pointed out a few, but I can't let Pyramid go unmentioned. The ideal framework; gives you what you need to bind your code to the web, without being obtrusive. You write pure Python with whatever components you choose or with the sensible defaults provided and use Pyramid's config systems to bundle it all together into a cohesive "website". It's awesome, and the only framework I've used like that. Truly simple (not "simple" like Rails, Django, or other frameworks where simple means "a million abstractions, assumptions, and exclusive language expansions that practically turn it into a derived DSL"), fast, and smooth.
- sontek 14y ago
  I switched to Pyramid for this exact reason. Django and Rails were both getting in my way where as Pyramid is just as powerful but without getting in my way.

crusso 14y ago

I don't think that DHH is feeling that his experience is any different than other maintainers. He's just trying to explain it to the masses. Maybe he's hoping that a few borderline whiners will catch a clue and decide to put up or shut up... maybe he's just venting. Regardless, I sympathize with him. I love rails. I love where his leadership has taken the framework steadily over the years.

orangethirty 14y ago
Re: Whiners. They never shut up. :) Given the size and pop culture around Rails I think he gets to deal with more stuff than the usual maintainer. I mean, there are people who actively celebrate when there is a security issue in Rails. When github was hacked due to a foolish mistake people where celebrating! This is the sort of thing that keeps me from joining any Framework community. Fanboyism.
steveklabnik 14y ago
> that a few borderline whiners will catch a clue Just so you know, those 'borderline whiners' are mostly other members of the core team.
- mattmcknight 14y ago
  Clearly this post is not primarily aimed at the core team, but the random people harassing him on Twitter and elsewhere.

fbuilesv 14y ago

Not necessarily. Some authors think that the best thing they can provide is a small framework that does the most basic stuff and then you plug-in the rest of the components you need. An example of this is Sinatra where you get a router, some helpers and not much more. You choose your ORM, testing library, etc. Others (like Rails) choose to include the 8 AA batteries. In general, this is aligned with the author way of thinking and it also applies to stuff like languages (think C vs. Java) or even window/desktop environments (Fluxbox vs. Gnome).

deleted 14y ago

[deleted]

Xylakant 14y ago

Not necessarily. Padrino [http://www.padrinorb.com/ http://www.padrinorb.com/] builds a rails-style framework from components which are exchangeable. You get to pick your testing library, the templating engine and the orm of your choice. If you don't like the router you can swap it out. It offer more flexibility and freedom of choice in that respect, but on the flip side doesn't achieve the same level of deep integration. It's more "a la carte" in DHH words.

dphase 14y ago
Padrino is excellent and does not get enough coverage.
tomjakubowski 14y ago
Rails allows you to choose your own testing framework [1][2][3] and plugins[4][5][6], templating engine[7][8][9], and ORM[10]. It's my understanding that before Rails 3, swapping out many default Rails was a bit hacky, but it's pretty standard now. [1]: https://github.com/rspec/rspec-rails https://github.com/rspec/rspec-rails [2]: https://github.com/cucumber/cucumber-rails https://github.com/cucumber/cucumber-rails [3]: https://github.com/thoughtbot/shoulda https://github.com/thoughtbot/shoulda [4]: https://github.com/thoughtbot/factory_girl https://github.com/thoughtbot/factory_girl [5]: https://github.com/nulldb/nulldb https://github.com/nulldb/nulldb [6]: https://github.com/notahat/machinist https://github.com/notahat/machinist [7]: https://github.com/haml/haml https://github.com/haml/haml [8]: https://github.com/josh/mustache-rails https://github.com/josh/mustache-rails [9]: https://github.com/stonean/slim https://github.com/stonean/slim [10]: https://github.com/brasten/sequel-rails https://github.com/brasten/sequel-rails [11]: https://github.com/datamapper/dm-rails https://github.com/datamapper/dm-rails [12]: http://mongomapper.com/documentation/getting-started/rails.html http://mongomapper.com/documentation/getting-started/rails.h...
- Xylakant 14y ago
  I know that and it's been posted often enough. However, the rails approach is fundamentally different from the padrino approach: Rails is very opinionated about which component should be used - as DHH stresses in his blog post. Padrino asks you when you generate your project. Both approaches have their advantages and disadvantages.

regularfry 14y ago

From where I'm sitting, this isn't to do with the framework much. It's more that DHH has made a coding decision based on an assumption about how the organisation using the framework does its development: specifically in this case that it's forced all its developers to use the same ruby and gems provisioning system. That's valid for 37S, and completely wrong for a whole bunch of other places. DHH then says: It's imo an anti-pattern to have developers working on the same app use different tool chains like that. If your organization can't decide on rvm vs rbenv, then you have deeper problems than what binstubs are checked in to your repository. and Second, if you are unable to use the same Ruby manager in production and development, I feel bad for you. We rely on .rbenv-version to ensure that the same Ruby point release is used in both places. Now, say you don't force all your developers through the same toolchain, or you're not using the same Ruby manager in production and development. Given these opinions, how likely is it that at some point there's going to be a Rails design decision based on them which isn't so trivial, and which causes a lot of pain for anyone on the wrong side of them? The fear is that you could be organisationally barred from using Rails for reasons that have been totally irrelevant before now. These aren't the cut-and-dry truths that DHH is presenting, although I can see the logic in them, and I think this problem has only happened because of binstubs, which are a really bad idea.

orangethirty 14y ago
Hasn't Rails always been like that? The "Trust us, we know what's best for you" line of thinking. Its part of their marketing, because they sell the "magic" of Rails. It drives people to Rails and it drives people away from Rails. Plus, anyone who uses Rails in production and does not agree with the way the Rails people run things is just asking for trouble. When you choose a framework you dont do so because its popular or nice. You first check the culture behimd the development team and their credos. If they believe in backwards compatibility and you value that, then pick that one. But dont pick something becuase its cool and then argue when the people in charge make decisions that make no sense for you. Its your problem, not theirs. DHH can wake up one day and say that Rails will now be written in Algol. You either re-factor to Algol or jump ship. Either way, you were doomed from the start. Thats why Im always wary of programmers who join into a framework too quickly. Not aimed at anyone in particular.

mylittlepony 14y ago

This is where interfaces come in, in OOP. Too bad Ruby does not have interfaces, and more importantly, Ruby people don't really understand interfaces and say they don't need them. And then they dare mock PHP, lol.

cookiecaper 14y ago

No. Others have pointed out a few, but I can't let Pyramid go unmentioned. The ideal framework; gives you what you need to bind your code to the web, without being obtrusive. You write pure Python with whatever components you choose or with the sensible defaults provided and use Pyramid's config systems to bundle it all together into a cohesive "website". It's awesome, and the only framework I've used like that. Truly simple (not "simple" like Rails, Django, or other frameworks where simple means "a million abstractions, assumptions, and exclusive language expansions that practically turn it into a derived DSL"), fast, and smooth.

sontek 14y ago
I switched to Pyramid for this exact reason. Django and Rails were both getting in my way where as Pyramid is just as powerful but without getting in my way.