3 ms·

Unfortunately, the "vegetarian" option was written by someone who eats bacon every day, and it's really buggy. Since it's wired into the framework, though, fig

Unfortunately, the "vegetarian" option was written by someone who eats bacon every day, and it's really buggy. Since it's wired into the framework, though, figuring out why it's serving chicken nuggets to the vegetarian is difficult. The facility for including a child at the dinner just says //TODO.

Silhouette 17y ago
I appreciate the joke, but you can have software that sucks whether it's a framework or a less structured library. In a decent framework, there are usually hooks for lots of stuff, but much of the time you don't use any particular hook because the default behaviour is what you want. In your case, it ought to have been possible to override the vegetarian dish preparation with a version completely of your own creation if you wanted to. But in any case, there's not that much difference between this and building a project around a specialised library that doesn't have a whole framework: you're still screwed if you discover late in the proceedings that it's got nasty bugs and whoever produces it isn't willing or able to fix them. (If you get to invent another library that conveniently provides the same interfaces and has no bugs to use as a drop-in replacement, I get to pull an interchangeable and bug-free framework out of the same magic hat.)
- cousin_it 17y ago
  Having not enough hooks != having bugs. Library authors have to worry about being bug-free; framework authors have to worry about being hook-complete AND bug-free. The effort of replacing a library should not involve restructuring all your code as if you were replacing a framework. If you find yourself restructuring your whole code to accommodate changes in the library, maybe it was a poor library, too framework-like. :-)
  - Silhouette 17y ago
    Sure, libraries don't need to worry about hooks, but they do need to worry about providing sufficiently flexible APIs for use in different contexts instead. Sooner or later, you've got to connect up your custom logic to the library/framework's general logic. I guess the distinction just seems rather artificial to me. It may theoretically be riskier to use a framework, in the sense that working around its limitations may be harder to do in the worst case. However, if you're working with bad interfaces and reluctant support, and the library is of any significant size and complexity such that you couldn't just reimplement it yourself in a worst case scenario, then you're basically screwed either way. Being only 75% screwed instead of 85% still doesn't ship your product. :-)

Silhouette 17y ago

I appreciate the joke, but you can have software that sucks whether it's a framework or a less structured library. In a decent framework, there are usually hooks for lots of stuff, but much of the time you don't use any particular hook because the default behaviour is what you want. In your case, it ought to have been possible to override the vegetarian dish preparation with a version completely of your own creation if you wanted to. But in any case, there's not that much difference between this and building a project around a specialised library that doesn't have a whole framework: you're still screwed if you discover late in the proceedings that it's got nasty bugs and whoever produces it isn't willing or able to fix them. (If you get to invent another library that conveniently provides the same interfaces and has no bugs to use as a drop-in replacement, I get to pull an interchangeable and bug-free framework out of the same magic hat.)

cousin_it 17y ago
Having not enough hooks != having bugs. Library authors have to worry about being bug-free; framework authors have to worry about being hook-complete AND bug-free. The effort of replacing a library should not involve restructuring all your code as if you were replacing a framework. If you find yourself restructuring your whole code to accommodate changes in the library, maybe it was a poor library, too framework-like. :-)
- Silhouette 17y ago
  Sure, libraries don't need to worry about hooks, but they do need to worry about providing sufficiently flexible APIs for use in different contexts instead. Sooner or later, you've got to connect up your custom logic to the library/framework's general logic. I guess the distinction just seems rather artificial to me. It may theoretically be riskier to use a framework, in the sense that working around its limitations may be harder to do in the worst case. However, if you're working with bad interfaces and reluctant support, and the library is of any significant size and complexity such that you couldn't just reimplement it yourself in a worst case scenario, then you're basically screwed either way. Being only 75% screwed instead of 85% still doesn't ship your product. :-)