Re: Your main event may be another's side-show.

[aquarium]

surely there are forking frameworks that are much smaller and easier to use than their big brothers. the reason why the bigger and more complex frameworks exist is because they do a whole lot more than a simple fork, typically allowing all sorts of scheduling and queueing. forking is their primary mechanism, but not their central goal.

[BrowserUk]

surely there are forking frameworks that are much smaller and easier to use than their big brothers. the reason why the bigger and more complex frameworks exist is because they do a whole lot more than a simple fork, typically allowing all sorts of scheduling and queueing. forking is their primary mechanism, but not their central goal.

That fine if you want everything they do; and if they do everything you want.

But if the former is not true, you have to carry its costs. And if the latter is not true, you are into the game of either waiting for them to provide it, or trying to understand enough of their internals to allow you to wrap over the modules--CPAN or your own--in such a way to make them compatible with the framework.

It all comes down to: Do I call them if and when I need them?

Or: Do I have to try and arrange for them to call me sufficiently frequent that if there is a possibility of there being something to do, I can poll around and see what, if anything, that might be?

(Oh. And then remember to store enough information about what I was currently doing before they interrupted me that I can pick it up when I get back to doing it.)

(Oh. And oh. And not forgetting that if I do find something to do, I'll need to retrieve whatever information I stored last time I was doing it. And then remember to store the modified state once I finished doing what ever it is that I found to do.)

(Always assuming that I succeed in finishing it and don't get interrupted again before then.)

(That's assuming that there was actually something else to do when I got interrupted.)

In a nutshell. Frameworks suck because they force me to work their way for everything. Even when most of the things I need to do aren't a natural fit to that way of working.

On the other hand, the nitty-gritty of forking and IPC can be encapsulated in a way that allows it to be used intuitively and without the need to invert the flow of control, or requiring bending the entire application to the will of the encapsulating module.

[andal]

In a nutshell. Frameworks suck because they force me to work their way for everything. Even when most of the things I need to do aren't a natural fit to that way of working.

Your arguments are too abstract. The framework introduced by certain library is intended to save the time of developing your own framework. So in real life you have the choice of doing everything yourself, or adjusting your work to the ready framework. According to your statement, you just dislike forcing yourself into the ways proposed by others. This is fine, because tastes differ. But in the real life the frameworks created by others can be very helpful. So it is incorrect to simply say "they shouldn't be because I don't like them". There's a saying (at least in Russian) don't spit in the well, one day you may drink water from it :)

[Corion]

The problems with frameworks start once you need to combine two frameworks. The C++ world suffers greatly from this because every framework implements their own String type for example, and they are all incompatible. In Perl, once you move your application to POE (for example), you'll find you have big problems adding Tk (or even threads).

There don't even need to be two frameworks. If you have existing code, you likely have to rewrite it to fit the framework you choose, because the target framework wants to call your routines in a specific order (Maypole as an example), or wants a different partition of the program flow (POE as an example). Using threads or Coro can migitate the problem of competition for flow of control by giving the framework its own flow and communicating through messages, but you trade that for a new set of problems.

The fact that any framework prescribes how to approach a problem is why I prefer libraries (which my code calls) over frameworks (which call my code). I found that in the long run, I'll always end up in corners where I'm working more against the (limitations of the) framework than using it to its advantages.

[BrowserUk]

See Re^5: Doing an Input->process->Output cycle with AnyEvent? (was: error: "recursive blocking wait detected") for something a little less abstract.

This really has nothing to do with not wanting to work someone else's way. It's about not wanting to be forced to do everything just one way, because the framework is incompatible with any other way of working. It's about not wanting to give up half the tools in my toolbox in favour of just one. Not being forced to use that hammer to try and saw, plane and drill, as well as drive nails.

[aquarium]

don't get me wrong. i agree that some (maybe most) have a lot of bloat etc. in the end it's up to you to decide if/when/how to use a fork framework. i guess a lot of typical problems involve pre-forking daemon process(es) with a central queue mechanism and such. and hence these more complicated frameworks proliferate. it certainly would be nice to have a very minimal forking wrapper, with a nice fork function that takes care of the tiny details (handling process initiation and termination, and which signals to use etc), and nothing else.