Introduction to POE

by Sungo

Initially adapted from a POE training course I did for work.

What is POE?

POE is a giant ball of kinetic energy and Computer Science buzzwords wrapped in a very strange and wonderful culture. Ok. That doesn't mean anything to anyone. Maybe I should start on a much simpler level, eh?

POE is:

Modules are good. OOP is good.

Will most likely run on whatever annoying web hosting service you're forced to use at work.

Huh? The short version is that perl programs can pretend to be threaded on a non-threaded perl with POE. POE is essentially a cooperative task scheduler at heart. Tasks are bundles of event handlers that look a lot like state machines. Several of these carefully constructed state machines can be running all at once.

POE's task scheduler is basically an event loop. (We'll be talking about event-driven systems here in a bit.) Various event loops usually don't play nice with each other. POE, however, is designed to play nicely with such event loops as, GTK, or Tk.

To quote the author of POE: POE's methods are designed from the user's standpoint. More people will be using them than writing them, so they should be a lot easier to use than implement. This should reduce the authors' workload over time, since they'll be using POE more than writing it.

POE lends itself quite well to network applications. Some folks would say this is what it's best at.

POE can track state for procedural code. In single-tasking programs, there's no real requirement for states to return right away. State transitions act more like

POE can be used as a framework for portable high-level components. Components may be event-driven, class hierarchies, or simple functions. Many such components already exist and more are in development every day.

Why are we using POE?

POE is very easy to use once one understands the concepts behind the system. Its modularity and flexibility allow for code and concept reuse. This ease of use translates into ease of maintenence, a much sought after commodity.

POE runs almost everywhere on any decent perl. Perl 5.004_05 and up all run POE (tho earlier perl's may sacrifice some of newer features due to strangeness in that perl). POE runs on NT, believe it or not. There are even rumors of it running on Mac OS Classic.

Thanks to POE's ease of use, the concept-to-code cycle is very rapid. To make things even better, Richard Soderberg (coral) and Rocco Caputo (dngor) have been working on a system by which flow charts can be run as POE programs. Isn't that scary? The other really scary thing is how often pseudocode works well as a first pass POE program. Tiny states can be written to encapsulate algorithms and then tied together with a Session.

POE won Best New Module at TPC3 in 1999. Mark Jason Dominus called POE the last really interesting Perl development (speaking about the Perl5 universe). Since 2000, POE has been used in the core operations of the Stockholm SBI Exchange. While not quite strewn across billboards, POE suffers from a huge and fanatical underground following, almost a revolution some days.

General Concepts

POE is a completely new way of looking at perl for most folks. It destroys the minds of the feeble and empowers the minds of the great. There is a sense in which POE is like learning a new programming language. Say goodbye to Kansas, Dorothy, because here we go...


POE is event driven. Wait. What does that mean? To draw a somewhat relevant analogy... For most geeks, life is event driven. Most of the day is spent waiting for something interesting to happen.

Ponder a friday evening. We're talking about a geek here so not much is going on. Just bad american tv. (is there any other kind of american tv?) Delivery Pizza arrives. This causes the geek to scramble for cash, pay the delivery man, and then hungrily devour pizza. When the pizza is gone, the geek resumes watching tv.

The arrival of the pizza is an event. This causes a Pizza Arrival state, the collection of actions including paying for the pizza and eating it. When the Pizza Arrival state ends, the geek goes back to a passive wait state, waiting for the next event in his/her life.

POE spends most of its time waiting. For what you ask? Well, for any number of things. Incoming socket connections, console input, and internal timers can all trigger events. POE::Wheel's also trigger events from various input sources.


States are a collection of actions which will be "fired" when an event happens. These can be customized for the given parameters of the event. For instance, it is not always appropriate to scream and run when the Pizza Delivery Person speaks. The Pizza Delivery Person may be an attractive member of the Appropriate Gender. In light of these parameters, an appropriate interface can be defined.

POE states are plain ol' perl. Standard perl rules apply. Anything you do in perl, you can do in a state.


All events/states happen in a Session.

The Heap

POErl (Syntax)

Session Creation

State Parameters