Wizards of Smart

If you have tried any of Erlang, Axum, or even F#, you’ll be familiar with the Actor model and coordinated, concurrent programming using channels. While looking through the Reactive Extensions, released during PDC 2009, I was intrigued by the ISubject<T> and ISubject<T1, T2> interfaces that implement both IObservable<T> and IObserver<T>. I asked whether this could be used as an Actor and received a response from none other than Erik himself that it was possible. Here’s the simple Ping Pong example, similar to those for Erlang, Axum, and F#. The good news is that this same approach will be available in all of the .NET languages, including F#. I wonder what the preferred F# approach will be.

I presented this at Houston Tech Fest 2009 back in September.

Humor me a moment. I know I’ve promised a series on REST/HTTP/HTML that will likely drive everyone nuts, but I had a thought this morning that is probably more bizarre than many others I’ve had. I have really enjoyed building and using fluent interfaces for tools I’m using. I think they can make the code both more readable and maintainable, though the approach differs from more traditional approaches. I’ve recently been working on a fluent interface for creating Atom items and feeds using the System.ServiceModel.Syndication namespace, and that has been both frustrating and fun.

This morning, however, I had the thought of creating a fluent interface for one of the most simple of concepts used in .NET: collections. What’s wrong with collections you ask? Nothing really. But what if instead of reading

collection.Add(item)

you could read

Add.the(item).to(collection)

? Which is more readable? In the end, that’s similar to what I’m doing with the System.ServiceModel.Syndication bit, except that you don’t generally just add one or a few things to the collection in the syndication example. We could create something similar to add and remove events, all using a single static Add/Remove class with various, overloaded methods for the common identification operations.

Is this overkill? As JB mentioned to me over IM, it’s relative. For some, I’m sure you will think I’m nuts. Others may think I am on to something. I don’t think I would go and do it for no reason at all, but if I ended up with some crazy list creation or end-user-wants-to-read-my-code scenarios, I might consider something like that. What do you think?

I’ve been spending some time lately reading and listening to talks on Framework Design and Language Design. In particular, I’ve found Krzysztof Cwalina’s blog and PDC talk very enlightening. I also rather enjoyed the PDC panel discussion on the Future of Programming Languages. I find this all very fascinating, but in a recent desire to apply pragmatism, I wondered how any of this could really help me in my day-to-day development tasks. Except to program to the framework’s design for efficiency and consistency, I had a hard time with that question.

However, with regard to my new hobby of extracting reusable patterns from apps I’m building, I really appreciate the idea of extracting these patterns into small, reusable and interoperable parts. In the Future of Programming panel, Jeremy Siek noted the importance of libraries working with other libraries (e.g., ASP.NET with ASP.NET MVC or ASP.NET AJAX with many Javascript libraries). Some libraries, however, implement their patterns too tightly around certain patterns to the exclusion of others. This can increase speed—Ruby on Rails comes to mind—but removes the ability to use other patterns or pluggable libraries–such as with Merb or Ramaze–to keep to the Ruby frameworks.

JB and I are attempting to extract patterns from our current project to enable faster development in future WPF/Silverlight projects. The current plan is to build our library around Composite WPF, an excellent library from Microsoft’s Patterns and Practices group for building rich client applications in WPF, and soon in Silverlight. We’re planning to build a business layer framework with service interfaces to the Composite WPF library and use the Repository pattern to allow for various data access methodologies.

That’s a loose description of our plan. What do you think? Do you see any flaws? For instance, we are currently not thinking about interchangeable UI libraries, even though a few, such as Silverlight.FX, have started to appear. Are we missing any existing business layer libraries? (I am not familiar with any myself, but I imagine someone has created one somewhere.) We are interested in your thoughts!

In case you are missing PDC like me, you can find some great videos of the sessions on Channel 9. I found Anders’ comments on the future of C# to be incredibly exciting. You can watch it here. I’d love to hear feedback on whether you to are excited about the new features he points out for C# 4.0:

• Dynamically Typed Objects
• Optional and Named Parameters
• Improved COM Interoperability
• Co- and Contra-variance

Update: You can now download and try out the CTP for Visual Studio 2010 and the .NET Framework 4.0 from Microsoft Connect!