Most imperative languages are designed to express control flow explicitly. Unfortunately, this makes it difficult to program in a more reactive style. Proposed are two constructs, Generators and Grammars to help ease the burden.
The public review of the Streaming API for XML (StAX) has been released. This is the standardization of a new kind of way of interacting with XML. The current ways are based on DOM and SAX. DOM based api's tend to be more flexible however at the cost of creating the entire document tree. SAX is extremely efficient however it tends to be more difficult to program in a event driven style. The name chosen in not entirely accurate since SAX is also a streaming API. StaX is a "pull" based streaming API as opposed to the the "push" that you find in SAX.
StAX and SAX performance I would expect should be roughly equivalent as evidenced by these benchmarks. The claimed advantages of a "pull" form is that it is easier to program in. However, I do find it very interesting that imperative languages make it difficult to write programs using "push" based or event driven programs.
The answer is that imperative languages are designed to express control flow explicitly. On the othe hand, for event driven API's the control flow is in a large part controlled by the event processor and the programmer is required to write code that's more reactive. Writing reactive code is definitely more difficult because you can never assume what will happen next. Though, I'm going to go out on a limb to say that reactive code is actually more scalable and flexible.
I have two ideas on how to make programming to Event Driven API's easier. One is to make the specification of state machines much easier. The way to do this with a programming language is to introduce what is called Generators. Generators were popularized in the programming language Icon. It allows the definition of functions that can be called multiple times but return multiple results.
A second approach is to make the specification of grammars much easier. If you've taken Automata Theory in college you know that state machines are equivalent to regular expressions, and regular expressions is a language that is weaker than context free grammars. The approach then is to define state machines in terms of context free grammars. This is exactly what a tool like Joost is doing. Joost is an implementation of the Streaming Transformations for XML (STX).
STX is should not be confused with StAX. They both are designed to tackle the streaming xml problem however STX tackles it in a much high level way. STX however doesn't need to use a "pull" API. It leverages SAX and makes developing XML transformations as easy as XSLT. Actually, I like it better, since it gives an imperative flavor as opposed to the functional flavor demanded by XSLT. Matter of fact, if you're thinking about scalability, this is possibly the best way to fly. I had it crunch through a 29 mb file without the VM going over 8 mb, such a task will put a DOM based XSLT processor to its knees!
Event Driven API's also tend to be more loosely coupled. If you consult this table you realize that it supports two properties. That is asychronous and lazy evaluation. So even amidst the call away from "pull" driven API's as shown by (StAX), "push" driven API's will continue to become more prevalent.
In summary, Event Driven API's are more difficult to program in simply because imperative languages were not designed for them. The use of both Generators and Grammar based approaches should make it much easier. The main benefit of an event driven style is better scalability and a loosely coupled approach.
> In summary, Event Driven API's are more difficult to > program in simply because imperative languages were not > designed for them. The use of both Generators and Grammar > based approaches should make it much easier. The main > benefit of an event driven style is better scalability and > a loosely coupled approach.
I'm not sure I agree with that. I think you were more correct in your earlier assertion that Writing reactive code is definitely more difficult because you can never assume what will happen next.
In other words, with traditional linear process-oriented logic, the programmer is in control of the program state when interactions take place. This is a paradign my brother refers to as We Ask the Questions. In event-driven programs the program must respond to whatever the current state is when an event occurs. So event-driven APIs are more difficult because the event-driven environment is more complex.
Will generators help you in your desire to simplfy state-driven machines? I'm a long-time Icon hacker, but although state machines are equivalent to regular expressions, one is prescriptive and the other is analytic, so it may prove difficult to reconcile the two. In any case, perhaps the equivalence is one of the reasons why regular expressions are traditionally the most error-prone part of the Python language for newcomers?