I can think of a couple of reasons POE isn't used more...

• It's nontrival to learn enough to get started. A lot of the modules on the CPAN you can pick up and learn to use in about five minutes. POE requires a larger investment of time, due to its inherent complexity.
• Most things can be accomplished without it.
• There is no single feature that is so compelling for a certain common task that whenever people have to do a certain thing, they think, "Oh, for this I should obviously use POE." A lot of the really popular modules, such as Class::DBI, are designed to handle a specific type of problem that people run into often. POE is more general, which allows people to think, "Well, someday I'll learn POE, but for what I'm doing today I don't need it, so I can put it off." This is related to the previous point.

I'm sure there are other reasons as well.

There is no single feature that is so compelling for a certain common task that whenever people have to do a certain thing, they think, "Oh, for this I should obviously use POE."

When I need to handle multiple input streams (tailing many logs, child procs, client connections, etc), POE is now my tool of choice. IMO, this is the compelling problem/solution set for POE.

--Solo

--
You said you wanted to be around when I made a mistake; well, this could be it, sweetheart.

That and anything that involves IRC :)

Frankly, though I think POE looks very good, I feel it's an overkill for a lot of tasks. There's something unique about Perl programmers - we want to get the job done. Perl makes it possible for most cases without using heavy and complex frameworks.

That said, I do appreciate POE's architecture, and I'll probably give it a shot for the next multi-tasking Perl app I write. For now, I managed to write a non-trivial application using the threads module, and that worked very well.

This gets me thinking about a little overlay-layer for POE so you can get to HEAP, KERNEL through a hashref like:

sub blabla {
  my ($poe_args) = shift;
  $poe_args->{KERNEL}->yield("bla");
  delete $poe_args->{HEAP}->job;
}
[download]

 ...
 as follows: ARG0 = the return value of syscall(), ARG1 = errno() -
 the numeric value of the error generated, ARG2 = error() - a
 descriptive for the given error, ARG3 = the wheel id, and ARG4 =
 the handle on which the error occurred (stdout, stderr, etc.)
[download]

sub errorhandler {
  my ($poe_args) = shift;
  if ($poe_args->{ERRNO} == 2) {
    print $poe_args->{ERROR}; 
  };
}
[download]

That being said, I still think POE is a great set of modules that I liked using, and will use more in the future.

It's not easy to write a standard object model that conceptually scales to infinity. I try it about once a year anyway. Each attempt starts with a small set of rules, but their corollaries invariably reach a point where complex applications can't be written. Check out my graveyard of past attempts to see for yourself.

This year's try started off with more modest goals. That didn't prevent the first two attempts from veering off into WTF?! Land. Luckily the third try's taking much longer to go there.

You might like this one. It almost totally abstracts POE::Kernel and POE::Session behind what's so far a small class library. To be sure, its size is a function of its incompleteness rather than its tidiness, but I think it's one of my best attempts to date.

And you'll be happy about its calling convention, which is hash-based rather than using Perl's standard @_ array for parameters. You may not be happy with the choice of parameter (and other) names, but I'm open to suggestions. Keep in mind: This is prototypical code, so it's all subject to change as better ideas come up.

It's a conscious decision not to use a hash. Why? Because it's considerably slower. You may say, "bah! who cares?" or some other variant of the "performance doesn't matter, and if it does switch to C" school of thought, but the POE designers disagree (and I tend to agree with them.) The point is that in writing library code, you don't want to arbitrarily limit the performance of the code. Put another way, you never want your framework to be the performance bottleneck for your application.

Simple. If any other module required you to

1. use a bunch of globals to store your state in...
2. rely on the cooperation of every part of the program to ensure the success of every other part fof the program...

   (Cooperative multi-tasking is what allowed one program running under Windows 3 or Mac/OS to completely lock out the entire system if the program encountered an unexpected error!)

3. Break up linear algorithms into lots of little chunks and use global variables to try and arrange that they all get called in the right sequence and convey the right information from one small bit to the next...

It would be laughed out of court without a hearing.

Indeed, try explaining how POE works to a Java, Scheme, Haskell, Erlang (or any language that has preemptive multitasking built in), programmer, and they'll laugh in your face and ask you why you are still using 1980s technology.

But doesn't all the "modern" GUI programming have similar problems (except your first point)?

They do...if you try to do all of your computation within the window procedures/callbacks of the gui...which is why you don't.

You run the gui in it's own thread and move any potentially time-expensive or complex processing into other threads.

That way the code in the gui thread need only maintain that state, and perform that processing required to maintain the gui. Everything else get spun off into other threads where the work can be coded as if it were a standalone program. All the state required by the algorithm is local, and the flow linear.

Only the initiation and return of results are transferred between the gui and the work threads and that is done by posting messages via a queue.

The gui remains resposive no matter how much work the work threads do. And, in a crisis, the user can instruct the gui to kill the background thread (or just suspend it), if it takes too long or he changes his mind about the results he needs.

To achieve the same thing using POE (or Tk->repeat or Tk->after) means breaking the long processing into small bits (and maintaining the state across callbacks!), to ensure that the rest of the application remains responsive. That is tedious and error prone and how much work can be done in each callback will vary depending upon the performance of the processor it runs on.

So you tune it for your 4GHz development box and when it arrives on your customers 1.5 GHz machine, the gui runs like molasses. Or you tune it for the 1.5 GHz machine and it takes 3 times as long on another customers 4.0 GHz machine as it should do, because it spend 50% of it's time saving and restoring state around iddy-biddy runs of the callback. You cannot tune for both scenarios. And programming state machines is hard.

---

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

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

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

The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.

except your first point

Too bad his first point is not true. POE provides a heap storage hash to each session. Using package variables, or even file-scope lexicals, is nearly always unnecessary.

To add a counter-point to all the anti-POE comments (which, admittadly, your post definitely seems to be asking for), I'll list some of the reasons why I like POE:

• It's generalized. There are other ways to get a decent event look, for instance with Gtk2 or Tk, but they're usually geared towards something in particular. POE, on the other hand, is general-purpose.
• There are lots of premade bits and pieces that can plug into POE. If you check out the CPAN respots for POE, you can see what I mean. There's a lot of functionality there that plugs together nicely, which can save a lot of time.
• It does a lot of work for you. The things it does are not groundbreaking, nor are they really very difficult to do. It's just that POE already does them, so I don't have to worry about them. Again, this can save a lot of time.
• It's flexible in all the right places. This may be a corollary to my first point, but I think it's worth mentioning. Even though POE provides a lot of its own functionality, you don't have to necessarily use it. You can replace various chunks as necessary, which can be very useful in certain circumstances.
• It works. I have heard more than one person rail against its cooperative multitasking(ness?), or against its somewhat odd parameter passing (which actually makes a lot of sense if you read the justification), but the fact of the matter is that despite these "problems", POE works very well. It does its job, it works as advertised, and it helps save time. At least, that's been my experience -- others will obviously disagree. :-)

As far as the Python mailling list goes, I have been seeing Python being recommended often by Computer Science types, who prefer it's style. So I imagine alot of students are being forced to use it.

Actually, one of POE's published strengths is a very good interoperability with GUI toolkits. I was once making a project that involved threads and Tk, it wasn't easy to combine them... but I was told that POE makes it very easy.

And of course, I have a column demonstrating that.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

That maybe true. For your future reference though, the secret to "easy threads" with Tk or Gtk2 is that you need to create your worker threads (and put them to sleep) BEFORE you start building your GUI.

---

I'm not really a human, but I play one on earth. flash japh

Also, cooperative multi-tasking has significant drawbacks. All it takes is one blocking call buried deep in your code to bring the whole system to a grinding halt. I much prefer a pre-forked multi-process model like Apache uses.

-sam

Really high-performance server applications will generally prefer cooperative multi-(task|thread)ing. You might look at http://pl.atyp.us/content/tech/servers.html for an idea of why. (Specifically the sections on context switches).

However, of course you won't limit yourself to only a single process. Multi-(CPU|core) machines are the norm, so you have to have multiple processes (or threads) to take advantage of that. I'm not really sure how easy or hard it is to have multiple POE processes running at once, but that is what you would want to do in general, both to address the blocking issue and the multi-processor issue.

Really high-performance server applications will generally prefer cooperative multi-(task|thread)ing.

That statement is indefensibly broad and, in my experience, incorrect. First, I don't know of a single system which uses cooperative multi-threading (I would say there's never been one, but I'm no CS historian). In all the systems I've seen multi-threading is preemptive, not cooperative, for obvious reasons. Second "really high-performance server applications" come in so many different shapes and flavors that stating that any one technology will be "generally preferred" is just dumb.

For my "really high-performance server applications" I use a pool of pre-forked processes, and it works quite well! That doesn't mean it's right for all tasks but it does suggest that cooperative multi-tasking might not be the undisputed king of silver bullet land!

-sam

Obviously it's because Python is more popular than Perl. ;)

On a more serious note, I think most people get their POE help fix through irc.perl.org's #poe channel. It's certainly active most week days, although it's punctuated by lulls as people actually work at their day jobs.

Or maybe the documentation and web site are so good they don't need the list. Ok, I said I'd be serious.

It could be list deadlock as everybody patiently waits for someone else to start writing. I know that's how I use the mailing list.

Now however, I am trying to figure out whether to use POE or not in a wxPerl application. An article ("poeintro") I just read talks about a service paradigm which is what I want, in other words I am not sure whether it makes more sense to use POE (cooperative multitasking) or separate threads for running multiple tcp-based servers.

However, since only the main thread is supposed to update the gui in wxPerl I am thinking POE might be smart. Anybody with experience resolving such a question? At the moment (I'm reading more articles as I update my post :) I'm leaning more towards POE due to the number of modules and wheels it already provides, and the new POE::Loop::Wx.

I've been on the $FOO mailing list for over a month now,
it's sad to see that there is hardly any traffic (by
comparison, $LANGUAGE's $BAR, a similar framework,
gets around 30 ~ 40 emails per day). I'm a mailing list
junkie, believing that the traffic size is a good
indication of the following, the support, the community
and possibly the future of the technology. I like $FOO
very much, although I've only been using it in one of
my projects (and on and off on that), it's really a great
framework, making many things easier/cleaner. I always
feel its documentation is lacking, if not in content,
certainly in organization. So why aren't you using $FOO?
because you're not aware of it? you don't work on that
type of project? you want better documentation? ...($FOO
home is at http://$FOO.perl.org/)
[download]