-
I Think Silverlight just ate WPF from the inside
-
That was a twitter comment I made this morning during the PDC keynote. A number of folks have reposted it.
Twitter’s character limit means I’ll elaborate here.
I don’t think this is a bad thing for WPF, or people that build WPF applications. Silverlight is gaining more and more features, and those features mean that over time, Silverlight will become a superset of WPF. That’s very different from the original vision where Silverlight was a subset of WPF.
I think over time, you’ll see one advanced graphics / UX framework for .NET development. I believe it’s name will be Silverlight.
I don’t know how long it will take, as there are still some gaps and differences. I also think there will be some continued enhancements to WPF in the short term. As time goes on, those enhancements will be smaller and smaller, and Silverlight will be the single framework.
Of course, I also think that any investment in WPF (now and in the future) will be extended to the Silverlight ecosystem.
In the end, I think this is branding. Silverlight has much more buzz than WPF. It’s clear that Microsoft should merge WPF and Silverlight into one framework. If there is going to be one UX framework, its name will be Silverlight.
-
A Discussion on Imperative vs. Declarative Programming
-
I received the following question (paraphrased) this week:
“You are an advocate of converting imperative style programming into re-usable frameworks as you did in your November VS Magazine column. I agree from a developer’s perspective. But, one thought that came to mind is the imperative style is quicker to grasp from a maintainer’s perspective because the code is in one place in contrast to several little functions that need to be pieced together. Is your thinking that once the framework of functions is setup and re-used, then a maintainer only has to learn it once and subsequently the idiom is quickly recognized? Effectively, there is a high cost the first time the idiom is encountered but then the future cost is lower?”
Actually, I think the imperative code seems easier to maintain because we’ve all seen so much more of it. That’s probably even more true case of maintenance developers. Only some of our universities discuss declarative programming languages. There’s even less declarative programming in products and enterprise projects these days. Declarative programming is unfamiliar to many of the professional developers writing code today.
In our regular day to day jobs, it’s not that what we do is incredibly hard. What makes some tasks feel hard is that we are unfamiliar with the tools or the task. Declarative program is one of possible tools that most developers are likely to avoid, because it is very unfamiliar. That’s a shame (in my opinion) because forcing yourself to think in different ways will make you a better software engineer. Furthermore, the problem you describe above will go away. The more exposure that developers have to declarative programming, the easier it will be to understand it and maintain it.
On your specific concern, I honestly think that the declarative style makes it clearer to see exactly what each function does. Those smaller, simpler functions are easier to understand. In my opinion, that makes it easier to understand larger algorithms composed of these smaller functions.
-
C# can now consume indexed properties
-
Kirill Osenkov provides some details on this feature that was added in Beta 2 of C#4.0. I must admit a certain ambivalence toward this feature. On the one hand, this feature will make working with Office COM APIs even easier (as Kirill shows). On the other hand, I fear a rising chorus asking to implement defining indexed properties in C#. That would be a mistake. It would end muddling the waters of what objects ‘owned’ other objects and properties.
foo.SomeProperty[3]
could represent two very different object models. Is SomeProperty a type that implements an indexer? Or is SomeProperty a property of foo that requires an index? That starts to matter quite a bit when you wonder about LINQ queries and other ways to access whatever data is behind SomeProperty.
I’m close to thinking that I’d have preferred this change wasn’t made. It’s a bit troubling to think that the language accepted changes solely to support interop with COM style APIs. But as long as the indexed properties remain in a box, and are only used for that particular scenario, it won’t be a serious concern.