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.

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        

I've not used Perl "threads" under Windows even for simple tasks because every time I've tried I've found bugs almost immediately.

Really? You've never asked for help. Which makes you a silly billy, because at a rough guess about 80% or more of the "threads bugs" posted here have been user errors. And of the rest, there is usually a relatively simple workaround.

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.

Then post the code and let me fix it for you.

I'd be fascinated, because as I said somewhere else here yesterday. In 8+ years I've never encountered a deadlock with ithreads.

Avoiding deadlocks is simple. You just don't write code that creates the situations where they can occur.

---

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

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

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

I'm very conflicted on this. As such, the following is not yet a completely coherent argument.

At least in part, the problem is: what is it that these days constitutes "mainstream take-up"?

In the quite recent past this was a fairly easy question to answer. Programming was pretty much exclusively the preserve of programmers. Whether they were college educated graduates, corporate professionals, or autodidactic enthusiastic amateurs--or some combination of the three--they had sufficient grounding in the subject that expecting them to either have a certain base of knowledge or to learn it tout de suite, was accepted as the norm.

This allowed certain assumptions to be made when it came to discussions or producing documentation that made life much simpler. It meant that there was a ground plain of concepts that could be assumed, and below which it was not necessary to explain further.

That time has come to an end--though I wonder if it should have?

Since the advent of mass participation in the web, more and more, the "mainstream" is becoming (by numbers at least), the owners of a billion "Mom&Pops Pot-pourri Emporium"s, who have an entrepreneurial idea and see the web as their route to fulfilling it. And there's nothing wrong in that.

Less desirable is that whilst those same people would never consider doing the wiring for their own offices; or laying the tarmac on the car-parks; or trying to deliver their goods country or world-wide; or any other form of support infrastructure, themselves. They frequently seem to think that they can write and/or maintain the own web-sites, accounts packages and other IT infrastructure themselves. Despite that they've no education, experience or particular aptitude for software.

In part, this has come about because of the very success of Perl--and its many imitators--to provide an 'easy in' to the world of programming. Few, if any non-enthusiasts would persist long enough using C or C++ or Java, to actually reach the point of getting something semi-usable working. And that's testimony to the power of the language(s) to map complex ideas to everyday, real-world concepts. But it is a double-edged sword. Both gift and curse.

Maybe, just maybe, we are in danger of trying to take it too far.

This is not 'programmer snobbery'; nor a wish for exclusivity. I hope it has become fairly clear that I have near infinite patience with newbies to the world of programming. Leastwise, newbies that want to learn. I'm far more likely to rail against the experienced than the newbie, and not just for altruistic reasons. It's simply that it is from them that I have most to gain. Ie. learn.

There is currently a prevalent movement to simplify programming by trying to encapsulate everything. To make programming an IKEA-style, stack'em high and sell'em cheap, mix'n'match, self-assembly process. To reduce programming to a blue-collar, teach-yourself-in-24-hours, anyone can do it, commodity occupation. Something that Mom&Pop can do between taking sales calls and tying bows around presentation packs of dried petals.

And I reject these moves entirely.

Not because I want to preserve the mystique of the white-coated God's of the machine room I encountered when I first started looking at programming with a view to a career in it. Nor because I have any need to try and artificially maintain my earning power--those days are pretty much over for me. Nor even because I think that non-enthusiastic amateurs have the potential to bring the profession into disrepute. Though they do, that isn't their exclusive preserve. Plenty of "professional programmers" are guilty of that also.

Mostly, it comes down to the fact that I believe that it doesn't achieve anything good--for them (inept prgrammers) or others.

I read somewhere recently that the British Medical Council had only struck off some tiny proportion of doctors over the past 100 or more years. And similarly, inept teachers are rarely removed from their profession. And of all the law students that matriculate each year, only a handful are ever failed before they complete their studies, or are struck off after they start working. This despite that law college professors almost universally say (off the record) that more half of their students show no particular aptitude for the subject; and far less than half are anything like competent in the courtroom. Hence the phenomena of celebrity lawyers.

That is lawyers who become celebrities in their own right rather than those who's clients are celebrities. Though there is often a wide overlap for obvious reasons.

So where does this all lead?

I think it leads me to the conclusion that there is a point below which it does no good to try and simplify programming any further. Nor seek to simplify the learning process (of programming, but also other subjects) further.

No one would tolerate it if their favourite sports team started to field truly incompetent players. Indeed, the very nature of the game (literally: games) is such that even the most aspiring of wannabes, would-like-to-bes and will-work-very-very-hard-to-bes simply doesn't make it beyond the feeder leagues. (Though if your team just lost you might contest this :)

In essence, I think programming is a complex and skilled craft, that is trying, but struggling to become a "profession". And some people are just not cut out for it. Just as I'm not cut out to be an artist, musician, ballet dancer, footballer or abstract mathematician. And it does no one any favours to try and lower the path of entry below a certain level.

To do so by trying to encapsulate everything to a higher and higher level, is like putting ever more powerful handguns in the hands of the untrained. Even if their intentions are all good, eventually they're going to let loose on a crowd of innocents.

The relevance of all this, to this thread, or your reply?

Quite possibly none :) You just caught me off the back of a long and deeply involved discussion elsewhere and this is the result.

For anyone who feels aggrieved by my use of the word 'amateur' above, don't be. You almost certainly fit under the heading 'autodidactic enthusiastic amateur' whom, in my experience, generally have far higher knowledge, skills, and experience base than many (if not most) purely professional programmers.

S'funny. I can't think of a single other profession where what you do at home is as strong, if not stronger indicator of your skills as it is in programming. Can you imagine a neuro-surgeon doing a bit(*) on the side at weekends :)

(*)of work!

---

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

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.

Xwindows? What is that? Some sort of GUI thingy? Didn't I specifically exclude GUIs?

You may have notice, but perhaps not, that this is a Perl website. By implication, we are discussing Perl frameworks here. So when you talk about "being precise", get your own house in order first.

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.

Okay. I'll play along. But words are cheap. *SHOW ME*.

Show me AnyEvent or Event or Coro, or POE or any other Perl event framework running succesfully within a ithreaded perl program. Betcha can't.

---

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