Dawn of kitchen sink libraries in Ruby | Hacker News Reader

Dawn of kitchen sink libraries in Ruby

codemancers.com

10 pointsgnufied9 comments

Now at its core, handling file uploads is very simple and straightforward affair

I understand the concerns the author is raising and having a single responsibility for a library is definitely ideal. But as far as I have experienced, file uploads are never as trivial as author is pointing them out to be.

Most of the times you need some kind of post processing for the files, sometimes you need multiple file uploads, sometimes you want to do it asynchronously. It just never ends up trivial.

Thats true, but often times a complicated library that makes these choices for you gets in your way, rather than helping the case.

Which is exactly why I'd rather use a library that doesn't make the choice of Rails and ActiveRecord for me.

Well, I tend to take a pragmatic approach about this. The question is, how much you want to deviate from convention of underlying framework when developing? 90% of Web applications out there, can reliably stick to rails conventions and they will be well served by it. But from my personal experience - handling file uploads, processing them is often very different from app to app. What we need is composaple modules not a single monolithic library that does everything and there lies my gripe.

While I haven't been doing much Ruby for a while, I agree somewhat with the article. Personally, I think it boils down to composability. Building simple, modular functionality with clearly defined borders should enable both a larger library composing these modules together and offering a unified interface towards them as well as a developer hand-picking and using these modules by hand as he/she needs them. The Prismatic blog published a good post recently where the problem with libraries vs frameworks was highlighted, and I agree with that post. I'm not saying it's easy, and it's certainly easier in some languages than others, but most of us could probably agree that it's the way we would like it to be done, no?

Talking about 'libraries vs frameworks', tenderlove spoke about frameworks providing bare-metal interfaces for libraries and let libraries implement those interfaces in whichever way they want. but its still not sure to what extent that would solve the problem. Recently, bare-metal queue implementation in Rails https://github.com/rails/rails/commit/adff4a706a5d7ad18ef053... has been discussed 'for and against' extensively.

I'm not quite sure I understand. Speaking of the generic case, the (quite broad, I admit) statement that modular and composable functionality should enable both the unified-libraries-approach (or frameworks) and pick-and-choose-approach should (when applied) solve the OPs problem of not wanting to use what he/she doesn't need, shouldn't it?

I support the idea of a framework essentially being a light-weight layer on top of libraries, but if the framework just uses a single monolithic library then little (but something!) is gained. If it uses one or more libraries that are all properly composed of smaller modules, etc, etc, then a lot of flexibility is gained.

I'm not very familiar with Rails - especially its internals - so it's hard to comment on this particular case. However, making job queueing modular seems to have found the approval of most people in the commit comment thread you linked.

But I agree that the distinction is never clear cut, and everything needs a discussion on a case-by-case basis...

I personally liked the days where the libs did one thing best. Probably that was why even the gem management was supported from a very long time in the past.

in relation to rails, i feel like it's tending towards perl.

gems are becoming cpan...

Reply on news.ycombinator.com