3 ms·

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, modula

by parley 14y 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 14y 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/adff4a706a5d7ad18ef05303461e1a0d848bd662 https://github.com/rails/rails/commit/adff4a706a5d7ad18ef053... has been discussed 'for and against' extensively.
- parley 14y 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...

by parley 14y ago

iffyuva 14y 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/adff4a706a5d7ad18ef05303461e1a0d848bd662 https://github.com/rails/rails/commit/adff4a706a5d7ad18ef053... has been discussed 'for and against' extensively.

parley 14y 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...