ActiveSupport Considered Harmful | Hacker News Reader

ActiveSupport Considered Harmful

hayesdavis.net

41 pointsbjhess18 comments

To summarize the argument: ActiveSupport is awesome because it has all kinds of fantastic features that Ruby lacks out of the box. But don't use ActiveSupport in your gems because it's going to cause all kinds of crazy dependency issues in folks' applications, whether or not they use Rails!

It strikes me that what's really harmful here is the glacial pace of change in the Ruby Standard Library. Of course, we shouldn't see untried and untested functionality shoved into the standard library willy-nilly: pollution of the standard library with ill-thought-out code is probably even worse.

But, that said, Rails 1.0 came out almost five years ago. In the same time span, we've seen the release of Ruby 1.8.4-7 and 1.9.0 and 1.9.1. It was big news in 2007 when Rails' Object#tap method made it into 1.8.7 and 1.9.

We should be seeing more of this functionality pulled out of ActiveSupport and pushed into the Ruby Standard Library.

It would be even better to see support for scoped namespaces in Ruby...

Part of the problem here is that in the ridiculously fast-moving Ruby and Rails world, you need <i>something</i> reasonably stable. The standard libraries could speed up, but would then need to worry more about bad ideas making it in with no way to take them out.

Backwards compatibility isn't optional here. Ruby could very, very quickly become a giant ball of hair if we're not careful what we put in, because nothing can come back out. Rails plays fast and loose with this, but having the language itself do so is really, really bad.

I agree completely with you. I want to see a middle ground between glacial and fast-and-loose.

Speed of progress wouldn't be a problem if people stuck to a sane and consistent version numbering system.

I'm new to Scala, but I love their alternative with the colorful name "Pimp My Library": http://scala.sygneca.com/patterns/pimp-my-library

In summary, you mark a method as "implicit" which constructors a decorator object with your extension methods. Implicits must be explicitly brought into scope and any ambiguities are a compile time error. This model is much more robust than Ruby's, but owes a lot of it's error-prevention to clever use of static typing.

Why not just ask the object for a proxy and then send it messages? Then you only add one method to the base object in question.

  [1, 2, 3].as.sum

> Why not

Ugliness.

Given a choice between "pretty and wrong" and "ugly and correct", I'll take "ugly and correct". The beauty that hides evil is not the true beauty.

This is the whole issue with open classes and many libraries (transitive dependencies make this issue exponentially more likely, on the number of libraries).

I have commented on this issue a while back (http://bit.ly/cNez8i), and some people were kind enough to fork ruby (http://gist.github.com/358467) and enable scoped Open Classes, like Scala, Groovy and C# have. This is great for dsls (many dsls that change base classes can happily live in the same project without conflicting with each other) and libraries (I can do whatever I want in my library, extending Object, Enumerable and Kernel, left and right, and the users will not be affected).

However, this very openness made the "moving to a newer and better version of ruby" movement harder. Just hope 2.0 will set things right.

Disclaimer: open classes are great. I think they should be allowed, only highly discouraged for libraries and frameworks, who should stick with scoped open classes for most of the time.

Title is a bit sensationalist, but he makes a great point. It's ok to be a little less DRY and implement your own helper methods in the namespace of your gem rather than include the whole low-level object invasion of active_support.

It seems crazy to me that someone would build a gem that expects the user to already have Rails installed. =:-o

Well, it expects the user to have the activesupport gem installed. Rails depends on it, not the other way around. But yeah, usually if you've installed one you've installed the whole rails bundle.

What is the scope of this issue? Most well-written Ruby code on github I see doesn't use ActiveSupport.

It's fairly rare, honestly. You see it occasionally, but it's often a pain when you do.

Interestingly, Facets (a non-Rails support library similar in scope to AR) has exactly the same problem. So mostly this is an argument against similar broad support libraries outside any specific scope.

That is, Facets would be pointless by this argument because it has no Rails-like environment to live in.

I agree that it's reasonably rare (though anecdotally I do feel like I'm running into it more often).

It's correct that I'm essentially arguing against requiring "invasive" support libraries that change the nature of ruby (admittedly, that's subjective) in gems. Gem authors should consider their dependencies on the basis of necessity, not convenience. Keep the scope low and compatibility high.

The nice thing about facets is that you can include just the items you're interested in. You don't need to pull in every method defined in the library.

Active Support 3 offers piece meal inclusion. You can grab it all at once or bit by bit as you please.

Reply on news.ycombinator.com