Dawn of kitchen sink libraries in Ruby

http://codemancers.com/blogs/2012/05/dawn-of-the-kitchen-sink.html

by gnufied • 14 years ago

10 9 14 years ago

govi• 14 years ago

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.

websymphony• 14 years ago

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.

gnufied2• 14 years ago

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

telent• 14 years ago

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

parley2• 14 years ago

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?

iffyuva• 14 years ago

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.

parley2• 14 years ago

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

netpenthe• 14 years ago

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

gems are becoming cpan...

Dawn of kitchen sink libraries in Ruby

Related Stories