unfold

Wednesday, April 13, 2011

Impressions of MIX 2011

Bing sent me to MIX as an attendee this year and so far it has been a blast.  It’s great to be able to listen to customer concerns and take the temperature of a technology by checking out how many people show up to a talk.  Most of all it’s fun to talk to the people who own the technologies I care about (especially the developers).  It’s also nice to occasionally get props for my contributions to Silverlight even though I’ve since left the team. Smile

The feedback from customers continues to be concern about the future of Silverlight and all I can do is reference the blog post “Standards-based web, plugins, and Silverlight.”  It also appears that many developers are somewhat wary of exploring HTML5.  It’s my feeling they might be more enthusiastic if the toolset were comparable to what Microsoft currently offers to Silverlight developers.  In a perfect world the release of IE9 would be accompanied by a Javascript unit testing framework built into Visual Studio, comprehensive Blend support for HTML5, SVG, and jQuery templates, a Visual Studio update providing ES5 intellisense support, a jQuery plug-in for data-binding, and support for writing server-side code using the IE9 Javascript engine.  Instead web developers got yet another templating engine for ASP.NET MVC (Razor) which - although very nice – doesn’t really solve any new problems.

One of the key reasons our developers are so loyal is that we provide them with such excellent tooling for our platforms.  IE9 has some great debugging and diagnostic tools but that’s not enough.  Developers need development tools and libraries that will fill the gaps they’ll encounter when they leave the warm embrace of the CLR and enter the realm of the browser.  The Javascript version of Reactive Extensions is a good start.

I know the transition from Silverlight to HTML5 can be painful as I made the switch myself when I joined the Bing team.  The good news - and it’s something I think we can do a better job of emphasizing - is that by cobbling together frameworks like jQuery, jQuery templates, and Knockout.js it’s possible to follow a development model similar to Silverlight and consequently achieve similar levels of productivity. 

Looking forward to tomorrow’s talks!

Thursday, May 27, 2010

Crockford on Javascript

The web would be a better place if everyone watched “Douglas Crockford on Javascript”, a highly entertaining and informative series of lectures on the state of Javascript and the web.  With wit and refreshing candor he catalogs what is right and wrong with Javascript and provides the historical context to help viewers understand (where possible) how we got here.  You’ll almost certainly want to buy his book “Javascript: The Good Parts.”  The title alone is a nice taste of Crockford’s plain-spoken style. :-)

Sunday, April 4, 2010

I’ve left the Silverlight team

I recently left the Silverlight team.  Silverlight is a great team to work for and I have tremendous confidence in the continued success of the product.  However at this point in my career platform development doesn’t appeal to me very much. I’d rather be much higher up in the stack working on user-facing technology.  To that end I’ve joined a research team that’s developing semantic web technology for Bing (among other things).

Unfortunately this will mean that I won’t be able to blog as much about what I’m doing because most of my work will be under NDA.  I can say that it is very exciting though!  If there’s one thing Microsoft does better than anyone it’s funding and productizing research (although there’s still room for improvement).

Working for the Silverlight team has been a real thrill.  It was great to be able to fight for and contribute features to the platform that I cared about. I’m proud to have been a part of Silverlight 4 and I can’t wait to use it on my new team.

Friday, April 2, 2010

A Modest Proposal: Pretty XSL

I’ve got a question for the authors of the popular MVC frameworks: What’s with all the custom view languages?  ASP.NET MVC uses ASPX files for their views.  Rails uses Ruby of course.  MonoRail has its own NVelocityViewEngine which has a python-like syntax.  Of course these frameworks allow you swap out these view engines.  However in my experience developers tend to default to using the one that ships with the framework.

Why not use XSL? 

The technical benefits of using XSL are compelling:

1. Use Less Bandwidth

Every major browser is capable of XSL transformations on the client.  After the XSL and CSS files have been cached by the browser an application server becomes responsible only for sending data and managing any application state.  This translates to massive bandwidth savings.

2. Enforce Model/View Separation

When it comes to view languages smarter is not better.  The more powerful a view language, the easier it is to inadvertently blend concerns.  XSL is a dumb language that is pure by design.  It’s like a technical straightjacket, sending a clear message to current and future developers about exactly what type of tasks are allowed to be performed.

3. W3C Standard

‘Nuff said.

4. Great tooling.

Some .NET developers may be unaware that it’s possible to step through XSL transformations in Visual Studio.  The experience is roughly on par with stepping through C# code in an ASPX.

Syntax Matters

Given all these benefits why do so many developers choose a different view language?  Here’s my theory: XSLT is ugly.  Anyone who has used XSL knows that its signal-to-noise ratio is abysmal.  Therefore propose a solution: The W3C should create PXSL (“Pretty Extensible Stylesheet Language”).  PXSL is a hypothetical non-XML language that compiles into XSL.  A stripped down version of Windsor’s NVelocityEngine or something similar could easily be compiled into XSL.

#foreach($person in $people)
#beforeall
       <table>
               <tr>
               <th>Name</th>
               <th>Age</th>
               </tr>
#before
                  <tr
#odd
                       Style='color:gray'>
#even
                       Style='color:white'>

#each
                       <td>$person.Name</td>
                       <td>$person.Age</td>

#after
                  </tr>

#between
                  <tr><td colspan='2'>$person.bio</td></tr>
#afterall
       </table>
#nodata
       Sorry No Person Found
#end

Some might think such an endeavor trivial or misguided.  I disagree.  There’s a relevant precedent to consider here.  Turtle (Terse RDF Triple Language) is a non-XML language for describing XML RDF graphs that has been submitted to the W3C.  Although it hasn’t yet been accepted as a standard it enjoys great tooling support and is widely used.  Although it is no more or less expressive than RDF it’s practical syntax is so compelling that it has found a foothold in the industry.

Use XML Where it Makes Sense

Whenever a new technology is introduced we hear a lot about its supposed benefits.  Some of these benefits pan out and some don’t.  One of the touted benefits of XML was that it was supposed to be human-readable.   While definitely an improvement on binary, many XML formats (ex. SOAP) are so complex that sifting through them in a text editor is very difficult in practice.  To increase productivity we are increasingly hiding XML from developers with designers, code generators, and configuration utilities. XML is a very mature data interchange language but there’s no reason to force developers to work with it directly.  A little syntax goes a long way.

Wednesday, March 3, 2010

Why We Still Rely on Dynamic Casts

*I recently updated this post as it was rather unclear.  By instance members I meant fields and properties, but it was pointed out that MTC was already supported on instance methods which are of course instance members.

The year is 2010.  I program in C#, a modern and (ostensibly) strongly-typed programming language with generics.  So why do I find it so difficult to write a program that doesn’t rely on dynamic casts?

Conventional wisdom is that reliance on dynamic casting is usually the sign of a poorly-designed framework.  While this is true very often the root cause of suboptimal framework design is the inability of the programming language to express certain concepts.  Its my aim to show you that with a simple programming language feature we can largely free our programs of dynamic casts.  In the process I also intend to challenge conventional notions about good interface design.

Why We Need Dynamic Casts: A Typical Example

Let’s take a look at a class that must rely on dynamic casts to do its job.

public class CollectionSynchronizer<T>
{
    public ICollection<T> SourceCollection { get; set; }     
    public ICollection<T> TargetCollection { get; set; }
    
    // Implementation omitted
}

This CollectionSynchronizer listens to changes in a source collection and synchronizes its contents with a target collection.  Over the classes lifetime its SourceCollection property might be set to a variety of different concrete collection classes that implement ICollection and INotifyCollectionChanged.  The CollectionSynchronizer class has to rely on a dynamic cast because it must cast its source collection from an ICollection to an INotifyCollectionChanged interface in order to detect any changes to it.

public class CollectionSynchronizer<T>
{
    private ICollection<T> sourceCollection;
    
    public ICollection<T> SourceCollection
    {
        get 
        {
            return sourceCollection;
        }
        set
        {
            sourceCollection = value;
            INotifyCollectionChanged notifyCollectionChanged = sourceCollection as INotifyCollectionChanged;
            if (notifyCollectionChanged != null)
            {
                notifyCollectionChanged += SourceCollectionChanged;
            }
        }
    }
    
    private void SourceCollectionChanged(object source, NotifyCollectionChangedEventArgs args)
    {
        // synchronize changes with target collection.
    }
    // snip...
}

The SourceCollection property cannot be strongly-typed as INotifyCollectionChanged because INCC contains no members for retrieving the objects already present in the collection (INCC doesn’t inherit from IEnumerable).  As a result of being weakly-typed this API is not discoverable to the class consumer - who might inadvertently assign a regular collection to the SourceCollection property and then wonder why the target collection was not getting updated.

“Isn’t INCC just a poorly designed interface?  Shouldn’t it derive from IEnumerable.”

No.  The architects made the right decision when they decided not to derive INCC from IEnumerable.  I’ll explain why later.  First I’ll demonstrate how we can get rid of this dynamic cast using a hypothetical language feature that is more flexible than interface inheritance and has fewer drawbacks.

Multiple Type Constraints

Ask yourself this question: Why can’t properties and fields be more than one type?  At first this question might seem heretical at best and nonsensical at worst.  Is such a thing even possible?  Well it turns out that this feature - which I’ll refer to as Multiple Type Constraints (MTC) - is not only possible to implement, but very useful. 

Let’s take a look at a revised version of our CollectionSynchronizer class that uses MTC (WARNING: the following code does NOT compile)...

public class CollectionSynchronizer // No generic type but...
{
    // ...we're using a generic type in a property definition
    public TCollection SourceCollection { get; set; } 
        where TCollection : ICollection, INotifyCollectionChanged
        
    public ICollection TargetCollection { get; set; }
    
    // Implementation omitted
}

Now objects assigned to the SourceCollection property are not restricted to being a single type but are instead constrained to be multiple types.  If C# were capable of compiling the code above we could write code like this*:

var sourceCollection = new ObservableCollection<Customer>();

// No generic type needed on the class
var synchronizer = new CollectionSynchronizer();

synchronizer.SourceCollection = sourceCollection;
synchronizer.TargetCollection = myListBox.Items;

// Adding an item to the source collection,
// and consequently the ListBox items
sourceCollection.Add(new Customer());

// Now we can change the type of SourceCollection
// to another collection that implements 
// ICollection and INotifyCollectionChanged.
sourceCollection.SourceCollection = new MyCustomCustomerCollection();

*Some folks pointed out in the comments that you could use a generic method setter with type constraints to write the same code as I’ve written above.  While this is true it would mean that I couldn’t set this property via XAML.

The point I’m trying to make is that if a programming language supports multiple inheritance it should support multiple type constraints.  C# does support MTC today, but not on properties and fields.  This causes problems.  I’ll explain further but first a small tangent…

Interface Inheritance is Harmful

I submit that the ability to inherit one interface from another has no place in a programming language.  Now I suspect you’d probably like some sort of justification for cutting a feature that pretty much every modern statically-typed, object-oriented programming language supports. 

Tough.  You’ve got it backwards.  Language features are expensive and risky propositions and therefore it’s the advocate’s responsibility to justify their inclusion - not the other way around.  So let’s ask the question…

Why Inherit?

There are two reasons to use inheritance:

  1. Share implementation
  2. Polymorphism

Obviously we can’t share implementation code by inheriting one interface from another because interfaces don’t contain any implementation code.  That only leaves polymorphism.

Polymorphism seems like a good reason to enable interface inheritance.  After all we can use interface inheritance to create a version of the CollectionSynchronizer class that doesn’t require a dynamic cast.

// Create new interface that inherits from two others
interface IObservableCollection: ICollection, INotifyCollectionChanged
{
}

public class CollectionSynchronizer // No generic type but...
{
    // Now we don't need generic constraints!
    public IObservableCollection SourceCollection { get; set; }         
    public ICollection TargetCollection { get; set; }
    
    // Implementation omitted
}

There’s just one problem with this approach: There aren’t any collections that implement IObservableCollection because we just invented it.  There’s no way of getting existing classes you don’t own to retroactively implement an interface. Even though the set of types in System.Collections.ObjectModel.ObservableCollection’s type hierarchy are a superset of the types in our IObservableCollection interface we can’t polymorph over both types.  Your IObservableCollection interface also won’t be compatible with semantically identical interfaces distributed by third parties.  This example demonstrates the inflexibility of interface inheritance.

The key takeaway here is that if a language supports MTC then interface inheritance is useless because MTC is a more flexible mechanism for achieving polymorphism.  In this context it makes sense to do away with interface inheritance because this feature encourages developers to build bigger, more coupled interfaces.

The Case For Small Interfaces

The larger an interface the more likely it is to be broken.  A broken interface is a big problem because interfaces don’t version.  It’s impossible to add, remove, or otherwise change members of an interface without breaking existing code.

One strategy for avoiding the embarrassment and pain of deprecation is to design many, small interfaces.  If we design interfaces that do one thing and do it well as well as avoid creating large interfaces indirectly via inheritance we  minimize the damage caused by deprecation.

The strategy of designing many small interfaces is only viable with MTC.  The fact that MTC is missing from properties and fields is a blind spot.  Nowadays systems are increasingly being built with declarative languages like XAML which are oriented around property getters and setters.

An Ideal Candidate for Language Inclusion

Property type constraints are an evolutionary concept, not a revolutionary one.  Its already possible to build  methods that specify multiple type constraints (via generics constraints).  MTC could be added to properties and fields by reusing the existing generic constraint syntax used for methods.

Tools/Designers would also benefit from multiple-type constraints on properties.  For example if a method was constrained to be both INotifyCollectionChanged and ICollection then the intellisense listing could include types that implement both.

Under the hood things get a little more complicated.  Just like generics, MTC is an ideal candidate for inclusion in IL.  Any approach that reduces MTC types to  object types or uses some other form of erasure would share the same drawbacks as generic type erasure.  I don’t pretend making the necessary changes to the platform will be easy, but I think it is worth the effort.*

*Update: Someone pointed out to me that this may actually be supported already because properties are just get/set method pairs under the hood.  Haven’t tried to write the IL myself.  Anyone know for sure?

The Way Forward

Multiple inheritance creates a combinatorial explosion of potential new types (ex. IObservableCollection, IObservableStack, IObservableEnumerableQueue, etc). MTC is an important tool for managing this complexity.   Programming languages that provide multiple inheritance without also allowing for multiple type constraints are not strongly-typed in practice.  Not allowing for constraints on properties and fields is an oversight that should be rectified.

About Me

My photo
I'm a software developer who started programming at age 16 and never saw any reason to stop. I'm working on the Presentation Platform Controls team at Microsoft. My primary interests are functional programming, and Rich Internet Applications.