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 :)

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.

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.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP an inspiration; A true Folk's Guy

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.

And that's exactly why I like Coro. The other choices for event-driven development take away extremely useful tools (catching exceptions, stack traces) and pollute every tiny bit of code with the need to write the code much differently. Coro only requires that the exact points where blocking might happen be tweaked to make Coro aware of the blocking and those changes are usually pretty easy to make. The rest of your code shows no evidence of Coro being used.

Yes, a single Coro instance won't use multiple cores. That has never been an issue in the projects I've considered Coro for because either they need to scale so I plan on running multiple instances anyway or they don't in which case one core is enough and the other core(s) get used by other stuff. Yes, there are cases where you don't want multiple instances and yet do want to use multiple cores but don't need more cores than are in the one computer you are using, and Coro would not be the best choice in such a constrained situation.

I find that threading can be very useful in the simplest of cases. But having spent years writing multi-threaded code with a group of people who were very good at it, I believe that scaling via threading is nearly a doomed endeavor. My experience is that the vast majority of programmers are quite bad at identifying race conditions. They are even worse at preventing race conditions. And they are worse still at both of those tasks when threads are involved. And even the best programmers can't keep a long-lived, significantly upgraded system free of serious problems associated with using threads.

IME, I'm pretty good at those tasks. And I'd still rather just avoid dealing with them as much as possible. Adding real threads (not what Perl 5 currently calls "threads") means that you have race conditions to consider all over the place. Perl's "threads" came to be because no Perl porter was able to remove the race conditions from trying to use real threads with Perl. So they switched to using threads to emulate fork() but much less efficiently in both memory and CPU required. So I prefer real fork over emulated fork. On Windows, I tend to either use cygwin or use spawn to emulate fork.

I've not used Perl "threads" under Windows even for simple tasks because every time I've tried I've found bugs almost immediately. Lots of people say that is no longer going to happen but then they said that lots of previous times when I still found bugs almost immediately.

I consider Perl "threads" under Windows for simple tasks and so will likely try again at some point. But I strongly avoid threads in a project that will need to scale either to running many instances or (more importantly) to having an extended lifespan of active development and enhancement.

And I've seen many projects start out just fine using threads and then have an ever-increasing set of problems with race conditions, deadlocks, and lack of concurrency. And those problems are rather fundamental.

I'd love to see a very general-purpose framework for preventing race conditions that also prevents deadlocks and reduced concurrency. I don't think one has been invented yet other than the very successful framework of a preemptive-multitasking operating system using processes with segregated resources. When the overhead per process becomes a problem (as can happen with Perl), I think coroutines present the best available long-term solution by allowing one process and one Perl interpreter to handle a large number of simultaneous tasks with only minimal coroutine-specific code. And it looks like Coro is a good implementation of coroutines for Perl.

- tye        

this is dejavu my little rant about PHP becoming so popular when PHP became loaded with properly unified frameworks as part of the standard stack. CPAN was great at the start to encourage experimentation and helping others, in the Open Source fashion. perhaps perl needs a similar thing to be revived. it's still a great language, but modules/frameworks and so many variants, are also detriments to mainstream takeup. Lately i'm seeing servers with perl 5.6, left un-upgraded, because there's too much effort needed in upgrading it and all the modules etc..and they still do their rudimentary perl tasks as quiet achievers.
the hardest line to type correctly is: stty erase ^H

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.

Let's be precise. If you just don't like some introduced frameworks then it makes sense to talk about those frameworks and not about frameworks in general. And really, frameworks don't force to do everything their way. After all, you have the full right to create the whole Xwindows from scratch using your own idea how it should work. But you don't, because in real life you can't. So the existing framework is GOOD thing. It saves you lots of work. As a payment for having good thing you should do much smaller work of adjusting your needs to that existing framework. And if you think a little, then usually you can find fairly easy way to join 2 different frameworks. For example, event driven application can nicely coexist with threads or other processes. They just should communicate using pipes.