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.

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

You've never asked for help. Which makes you a silly billy, because [...] the rest, there is usually a relatively simple workaround.

Yeah, running into a "panic" at step one with trivial amounts of code makes me shy away from putting my full weight on something. A work-around can be a nice thing. Needing a work-around out of the gate when the code hasn't hardly even started being written is all I need to find a different solution. And you not having noticed me asking for help doesn't actually demonstrate much about how much help I have sought or not.

In 8+ years I've never encountered a deadlock with ithreads.

Yeah. iThreads emulate fork(). You don't get deadlocks with just fork() either. When you tie yourself to a framework like iThreads, that is one of the benefits. But since fork() is so much more efficient in memory and CPU than that emulation of it (and is better supported and less buggy), I use the real thing not the emulation.

- tye        

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

Very passionate writing :) And even though I agree with most of your points I feel like you are taking everything a bit too dramatic. Yes, all of those attempts to simplify writing new programs are of no use to those who can't program. But they can be of help to those who can and needs to write something quickly. And why should I care about those who can't if they shouldn't?

I dislike when someone sells his/her product as "life-simplifier". But I never will object to the libraries or frameworks positioned as "might be helpful". And the difference between the 2 is only the words that are used to present them. Nothing else.

As to those who try to program not knowing it. There are millions of people who do their job, not really knowing how to do it. Nobody finds it tragic. Only extra complexity in proving that you are better than others :)

Can you imagine a neuro-surgeon doing a bit(*) on the side at weekends :)

Someone has got to get those dogs to start clucking, and chickens to start barking

Even if their intentions are all good, eventually they're going to let loose on a crowd of innocents.

Don't you mean shoot themselves in the foot?

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

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

So after all, your complains are not about frameworks in general, but about those that are introduced in CPAN modules? Then should we also exclude the frameworks that are based on underlying C libraries (like glib)? :)

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.

I can't. I've never used any of those. I've created my own :) But it does not mean that it is not possible. It just means that I've never tried, neither those frameworks nor ithreaded perl. (But I've done this with C language programs). And of course it does not mean that those frameworks are BAD THING. They are only not suitable for you, but you don't have to use them. So they are forcing nothing on you.

As a side note. Even though I haven't tried it, I do believe that it shouldn't be hard as long as the socketpair (or pipe) command in perl works. Something like

sub event_handler
{
    if(time_taking_task())
    {
        #socketpair(MY, HIS)
        pipe(MYIN, THROUT);
        pipe(TRHIN, MYOUT);
        check_for_reading(MYIN, \&info_from_thead);
        launch_thread(\&my_thread);
    }

}

sub info_from_tread
{
    sysread(MYIN, $var);
}

sub my_thread
{
 # do some long work
 print THROUT "Give more data\n";
 sysread(THRIN, $data);
}
[download]