Some notes on this podcast that I think are of importance...

Ted states that event based programming differs from event driven systems.  An example of an event driven app is a windows GUI.  These event driven programs do nothing until receiving event and then handle it internally.  Event-based applications, on the other hand, basically operate upon upon internal communications between different parts of the application that are hooked together to provide functionality through event based communications. 

Dynamic Routing is stated as being one of the important things about this type of programming.  Dynamic routing is where handlers for events can be changed at run-time.  In event based systems this is fixed at runtime.  Event-based applications can change the configuration on the fly.  To do this, several constructs are used:

• Builders - instantiate all the objects in the system
• Binders - provide communications channels between systems
• Coordinators - provide orchestration between objects through binders

The key point is that binders preserve the decoupling of sources of events from their listeners.  This is important to be able to ensure flexibility, independent development, and independent testing of the components.  A builder puts together all entities that will be wired, and then passes control to a binder which wires the individual components.  Binders then wire up all the observers to subjects. 

description of switch statements being used as a means for demultiplexing data moved over a single communications channel.  At some point some data is created, then through one code path (the communications channel) a decision is made to go different ways.  This inherently bad for concurrency and scalability, and handling through bindings is much more scalable.

Also raised was a concern about the .NET/WPF model of events and passing argugments to the event through classes as a parameter.  To create your own events, you must necessarily then create an event arguments class.  This therefore causes class explosion as you need to make a new class for every event just to pass the arguments.  I totally agree with this as I think its a total pain to have to go through this.

Ted has a book on this topic.  I have not read it yet: Event-Based Programming: Taking Events to the Limit.

I'm curious to see if he gets into topics of Invasive Software Composition.  I recommend the book on this by Uwe Assmann.  This book discusses a number of topics, but which I would describe as mostly discussing AoP and connection of software components through connectors, ports and adapters.  It's also a good read if you are into SOA and BPEL, as (at least to me) it gave good clarification on the use of communications channels (SOAP/REST) between components (Web Services) and transformation (XSLT) of data (XML) across the channel.

Where this ties into the discussion that Ted had is that Assmann (boy that's a bad name in the US) would do the "binding" with AoP constructs, basically injecting the bindings between the components at runtime through dependency injection (DI).  I would also tend to say that the bindings could not also be done this way, but also through generic programming using policy classes, as well as havnig routes between objects be able to be modified dynamically through having the injected policies either change or make decisions on the data.

This last point gets into another SOA tennant (a reason I brought it up earlier)  which is know as content based routing.  Typically, this is done on an enterprise service bus through logic attached to the bus, but within an application, a very flexible model of routing of data as well as code flow could be set up with a good combination of AoP, DI and event based architecture.

A few days ago I was doing some searching around the net to try and find if there was any information I hadn't previously found on doing force directed graph layout.  This came up as someone had noticed here on the blog that I had a control that did that.  Unfortunately I don't consider that code to be very robust, so I was looking around to see if I could find a library or some sample code to do it better.

Well, what I came across was a C++ library called Boost (you can find it here).  It's a generic programming library, and consists of quite a few components, but one of them is a graph library that does have classes for force directed graph layout.  So, I downloaded it with hopes of being able to learn some more about how to generate these types of graphs.

Now, I used to be quite the C++ programmer, but have done almost 100% C# since 2000, but I figured I could just jump right back into it.  Well, apparantly not.  Seems the world of C++ has really moved forward into a concept known as generic programming through the use of C++ templates.  This technique goes well beyond what I used to use templates for in C++, and currently use Generics for in C#.  Generic programming as being currently used utilizes a metaprogramming facility from within the host language to generate new semantics into the language.  In a way, this kind of aligns with research I've been doing lately into domain specific languages (specifically DSLs in Ruby).

Don't get me wrong here, as I really love C# (particulary the stuff in 3.0/3.5), and think it has been pushing the model for programming ahead better than anything else, but I had been feeling that it wasn't moving fast enough.  Dynamic languages is one place where I was seeing usefulness (Ruby/IronRuby specifically), also with Domain Specific Lanaguages (both with Ruby, as well as with the Microsoft DSL tools), and now with generic programming, and most importantly with C++.

It really seems to me that C++ is a toolset that must be put back into any programming gods toolset.  I've always missed several features in the C++ language in C#, particularly the ability to pattern match through automatically promote object creation through a chain of constructors (a technique I used a lot to reduce code).  Now with generic programming, combined with libraries such as Boost and the STL, this really may be one of the best ways of getting particular tasks completed the most effectively.

BTW, on the concept of the STL, I've never understood Microsoft's position on container classes.  I was one of the first adopters of using the STL when it came out, but Microsoft's support for it in their C++ compiler was always buggy, so it was always difficult to use in that environment.  But the design of the classes really are the best.  I mean, every time I still code a dictionary in C#, I still mentally think of the much more flexible stl::map class.  C# containers always just felt incomplete compared to the STL.

One thing that I was really surprised at was that the Boost library actually compiled and ran without problems in VS.NET 2008.  Previous experience has shown that this would not be the case (as with the STL).  Kudos to the C++ team for keeping up.

Now this C++ generic programming thing seems to be quite the adventure to learn.  I can tell that there is something very important there, but its quite a mental shift to pick up.  I'm looking into some resources about it and I'll write about my experiences.

Additionally, the integration of C++ in to C#, through one weekend of effort, has been quite challenging (as well as interesting).  It's not possible to use a library like Boost directly in your C# apps (which I have to keep doing), but it is usable in unmanaged C++ within managed C++ (an interesting topic itself), which is then used as components in a C# application.  This involves several interop techniques, but appears to work quite well.  I'll drop some notes on that too as I move forward on this adventure.