We've been loyal Verizon Wireless customers for many years. We were GTE Wireless customers back in the day before the name change. But my wife has been wanting an iPhone for many months. She's enamored with the tight integration of the applications and the hardware. She's also a Mac user for the same reason. She finds the huge variety of vendors and configuration options on the PC overwhelming. The Mac simplifies things by limiting the choices. I can understand how she feels. I've been doing Windows development on a MacBook Pro for a few months and I have to say that the OS X experience is comfortable to me now. I still love Windows but running it in a virtual machine on my Mac gives me the best of both worlds.

My wife's business is doing well so she decided to get an iPhone today and make it a pure business expense going forward. She's in love with her iPhone and I'm happy for her. But it irks me that she had to choose AT&T Wireless to be able to switch over to the platform she really wanted. Verizon Wireless has great customer service and their network coverage is just phenomenal. We live in the wilderness between Richmond and Charlottesville, Virginia and wireless Internet service is all we can get out here. Even in the boondocks Verizon's coverage is rock solid: five bars. AT&T Wireless's coverage is OK where we live but not nearly as strong. I like to reward those companies that earn my trust and respect by remaining loyal to them. Just tonight I was trying to solve an issue with an EVDO card that I purchased on EBay and the Verizon Wireless support team was nothing short of amazing in their response to help me. A few months ago something weird happened with the wireless tower near my home and the I got routed to engineers in Dallas who were diagnosing the problem live while I listened. Within an hour a Verizon Wireless truck was on the scene at the local tower. And when they had fixed the problem the engineers in Dallas called me back and had me test the fixes before the workers were allowed to leave the tower. I was simply blown away by the quality of the response. You just don't get that kind of customer service from most companies these days. So you can imagine that I'd have been much happier if we could have added my wife's iPhone to our Verizon Wireless account. AT&T Wireless's service and support may also be wonderful. But Verizon Wireless has earned my respect and I like to be loyal to their brand.

The same goes for Google's Android-based G1 phone operating only on the T-Mobile network. I'd love to try the G1 but the T-Mobile signal where I live is just awful. Until the G1 is available on a more functional network, it's just unavailable to me. Are we so primitive in our networking prowess in 2009 that we have to restrict devices to specific carrier networks? A TCP stack is a TCP stack, right? Building a TCP stack that can use EVDO or EDGE interchangeably shouldn't be a big deal. So is it just that by limiting the carrier choices Apple and Google can better drive consumers through the channels where they can exert more control over features and configuration? The latter is the real driver behind the limitations, I'm sure. Apple is the master of limiting choices to limit complexity after all. I'm also sure that by single sourcing a device as sexy as the iPhone through one carrier, Apple has sweetened it's margins nicely, too.

I shouldn't be complaining, I suppose. I'm all for the freedom of businesses to make the choices that make them as successful as they can be. If it helps AT&T Wireless's, Apple's, T-Mobile's and Google's bottom lines to be proprietary then I honor their proprietary-ness. But consumers like me also place a high value on choice, too. I'm looking forward to the day when any computing or telephony device purchased anywhere in the world will work on any network, anywhere in the world. One network for all. Is my dream fallacious? Perhaps. What's your techno dream?

I attended the Richmond .NET User Group meeting tonight and listened to Jon Pryor talk about The Mono Project. He did a great job and answered some of the questions I have had for a while about how to get started with Mono. Feeling a bit saucy from the ALT-ness of the experience, my friend Harper Trow said he was going to run over to IronWorks to attend the second half of the CocoaHeads User Group meeting. Sixto Saez, Harper and I found our way into the fairly crowded small conference room where a group of twenty and early thirty-somethings were discussing Cocoa Bindings. I am not a Mac OS X developer. But I am curious about other platforms and OS X has some compelling concepts.

The Richmond CocoaHeads are an interesting group of folks who are clearly committed to their framework and platform. I am a Microsoft guy to the core but it's really good to be among any group of technologists who so visibly love what they do. Having never seen Cocoa and the Xcode development environment before, I had to draw on prototypes from my C++, Java and .NET experience for figuring out how Xcode works in principle. It felt a lot like Visual Studio done Apple style: prettier and maybe a bit more attention to the details.

The one thing I saw in Cocoa that was quite interesting was how Cocoa Bindings implements the Observer Pattern for notifying user interface elements of property changes. Whenever some client code registers for change notifications on a property, the Cocoa Bindings code inserts a proxy at runtime that fires the pre and post events before and after the state change. Pretty cool stuff. This trick is essentially applying the Interceptor or Composition Filter pattern that I've been using in AOP for years but performing it dynamically at runtime. On the one hand, it's pretty cool to see these patterns applied in such a dynamic way. But it seems to tie Cocoa Bindings to Objective-C's object model so tightly that I can't imagine being able to use anything else to do OS X development in the future. It would be hard to introduce another dynamic language, for example, that didn't conform to Objective-C's runtime model for proxying the observed properties. I could be wrong on this but it was my first impression. And my first impressions are usually pretty accurate. What are your thoughts? Can you offer more insight?

The more I study the Dynamic Language Runtime (DLR), the more I am convinced that it deserves to be the centerpiece of Microsoft's .NET 4.0 strategy. I am a statically typed languages guy. Or at least I have been. I love the robustness that the compiler applies to certain preconditions for using objects. Type safety is great but I don't think that statically typed languages go far enough to be honest. I am excited about Spec# because of its supports for invariants, pre and post conditions, static program verification, etc. Will Spec# ever go mainstream? It doesn't appear to have the momentum that F# or IronPython have, to be frank about it. But maybe we'll see some ideas creep into C# from the Spec# research that Microsoft is doing. I have my fingers crossed.

On the other end of the spectrum is IronPython 2.0, Microsoft's first DLR-based implementation of the Python programming language. I just love Python. It's so clean and simple that almost anyone can learn and use it effectively after studying it for an hour or two. If I could send a note to myself in the past to change one thing about my career (besides the winning lottery numbers for the past decade) it would be to encourage my younger self to learn Python back in the mid-1990s. I knew about the language back then but I was a C++ bigot. I wish I had been more open minded. So much of my approach to software development would have been better if I had learned Python back then. I was working in the Intel Architecture Labs and had the perfect opportunity to do so, too. We were helping a very young company named Yahoo.com to evaluate e-mail providers to purchase. We ended up recommending RocketMail technology which was based almost entirely on server-side Python scripting. I had the perfect opportunity to learn Python from real experts right there in front of me and I let it slip right by me.

Well, no sense living in the past, right? I know Python really well now and it has changed the way I think about software development. Learning Python made me fall in love with Ruby and LISP and F#, too. I'm a real polyglot now and being able to understand how these other languages solve problems helps me design better in the language I use every day: C#. By the way, the term polyglot from its Greek roots literally means many tongues. I'm excited about the DLR because it's enabling Python and Ruby on my favorite platform. But the DLR is so much more important than that. It's the Language of Languages. The DLR defines the primitives that must exist on the boundaries of our languages to make them interoperate. In the same way that COM unified the dispatch model in the 1990s through IUnknown and IDispatch, the DLR will define the call semantics and dispatch models for the .NET Framework for the 2010s through IDynamicObject and DynamicMetaObject.

Pretty soon, we'll see a flurry of languages appear on top of the DLR. A bunch of them are already in development. But we'll also see a wave of DLR object binders appear that have no significant language support on the platform, too. The effects will be profound. Imagine a Java RMI bridge written as a DLR object binder. Using the dynamic type in C# 4.0, you could make calls to remote Java objects from .NET as if they were just part of the framework. Or imagine a type binder that exposes RESTful services as a dynamic object model. There's really no end to the possibilities here. The key to all of these scenarios is the enablement of dynamic services and that sounds a lot like what Web 2.0 was supposed to be.

Returning void (or Nothing in VB.NET) from a method is best the way to say, "I don't care about you, caller." Consider this silly C# code:

This code could be a lot more fluid but the ScriptScope.SetVariable method returns void. If the method returned a reference to its Engine property, the code could have been written more succinctly as:

Wouldn't that be nice? So don't return void (or Nothing in VB.NET). When you have nothing else you can return from an instance method, return the this pointer (or Me in VB.NET).