Hacker News Reader

Comment by orangethirty | Hacker News Reader

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.

View on HN

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.

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.

Well, that's the point. We're talking about rails 4 here. It's a mature framework at this point, and yet apparently here is the DFL saying that people who historically have had no problems running Rails are now - without warning - deemed to have made a mistake.

    Thats why Im always wary of programmers who join into a framework too quickly.

How long should a framework be given, then? Or is your point that anyone who picked Rails made a mistake precisely because it's an opinionated framework, and they aren't a DHH/37S clone?

Rails culture has always been about change. There is focus on backwards compatibility but its not job #1. If you can't change along with Rails, then you should not use it. DHH can do as he pleases because thats his framework. It powers his business. If he needs to change anything to fit his needs, then he will do so. Thats the culture of Rails.

I use Rails, and its a nice framework. But I'm not a fanboy. Its just another tool for the job. Just like Django, Symfony, Flask, Sinatra, Laravel, Slim, etc.

Now, I'm not getting into a pissing match with you. We are arguiing the same point, just from two different perspectives. I do agree that Rails 4 is mature enough. But the culture is not. And that's what keeps Rails from replacing shitty Enterprise frameworks. A shame because Ruby is fun to write and very powerful.

It's ruby. Just change your load path. The beauty of that language is that almost no one can really force you to do anything you don't want to do.

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).

Not necessarily. Padrino [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.

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.

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.

Changing the defaults takes 2 minutes in Rails. What's the problem? Besides, there are gems like Rails Composer [1], which allow you to create new projects based on a template.

[1] - https://github.com/RailsApps/rails-composer/#your-options

Nobody ever said it's a problem. It's a different view of the world, that's all.

And what is the fundamental difference?

You can tell Padrino what you want during the creation of a new project.

You can tell Rails what you want immediately after the creation of a new project. Rails simply saves you time by having sane defaults. Convention over configuration at its best.

Padrinos fundamental philosophy is to be a framework built up of independent components and with limited opinions. Rails is by default opinionated: You can swap out certain components but all in all you're expected to do stuff "The Rails Way". That's the difference. It may or may not matter to you and in many ways produce the same end results, but the approach still differs.

Padrino is excellent and does not get enough coverage.

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.

> that a few borderline whiners will catch a clue

Just so you know, those 'borderline whiners' are mostly other members of the core team.

Clearly this post is not primarily aimed at the core team, but the random people harassing him on Twitter and elsewhere.

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.

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.

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.

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.

Reply on news.ycombinator.com