Stormbrew said pretty much everything I would (https://news.ycombinator.com/item?id=5370718), but the one thing I would add is that most people are not going to keep their requires up-to-date for all but the most stable projects. Once your requires start to get stale/incomplete, they can easily become more of a liability than a benefit.
Again, I tend to agree with you more than I disagree. I think were I disagree is in making it a recommendation -- if someone is on point enough to effectively use Bundler.setup, I don't know that they need to have it recommended to them; they just need to know the difference between Bundler.setup and Bundler.require. On the other hand, if someone does need a recommendation and not a description, I'm not sure that either is the appropriate response.
I guess at the end of the day, I'm just not looking forward to the change-sets this might generate ;)
Interesting. Why would the requires go stale? And how would you use a dependency you don't require? It wouldn't be possible to use it unless you required it. This of course assumes you're testing your classes in isolation.
I think that isolation testing files is considerably harder than isolation testing classes. You can't force isolation of one by using isolation of the other.
For requires going stale, I mean when a file originally depends on something but no longer does. The require is likely to linger, especially if the dependency is removed without knowing that it was the entirety or the last of the dependency. This file now has stale dependencies.
Then something requiring that file will have that dependency in place and possibly use it without requiring it because of that. This file now has incorrect dependencies.
Expand the above across a more complex project and it becomes virtually impossible to verify the correctness of your requires, so you probably just stop trying and require things as needed, which makes it worse.
When you finally discover it your changes (in your version control) become less isolated as random requires start popping in and out.
This is not a new or unique problem to Ruby, obviously. C/C++ headers have a very similar problem.
Ah, well, nothing is foolproof. Yes, if you don't update your dependency list when dependencies are removed, they might get stale. But I keep up on that stuff and haven't ran into that problem yet. Even if I did, I'd rather have that problem than an app where all the dependencies are global.
Sure. I guess what I'm trying to get at here is that, while I'm not fond of the Everything Is Magic approach rails often takes, I actually think this is one case where it was an entirely pragmatic effort to work around a poorly developed area of the ruby language when a program gets large (in terms of files, lines, or both). And Bundler.require is an evolution of that practice.
I think a lot of this unfortunately comes from Rails. Rails hides a lot of complexity which creates "magic". And since most Rubyists come to Ruby from Rails, a lot of Rubyists have the bad habit of hiding complexity wherever possible. I was guilty of that myself. But I've noticed it slowly starting to change.
Actually, the entire reason I made this site was because I thought the way MacRumors visualized the data wasn't very good. If they had done a better job, I wouldn't have needed to make this.
As for credit... what should I be crediting them for? I'm just collecting a list of dates and then visualizing the data.
A simple link at the bottom saying, "inspired by macrumors.com buyers guide" would go a long way towards giving credit to the original concept. You can even even embed the url, so it's just a small font, "inspired by" to keep the page clean.
I guess it depends on how you quantify usefulness. There's less info, but I think I visualized the information that I do show much better than MacRumors.
They probably meant whether or not I "took" the information from somewhere else. But yeah, actually scraping the information would have been ridiculous. It's all just in a static YAML file.
