Linq and the cost of additional language complexity
Uwe Keim posted a thought provoking comment in response to my entry about Linq. Here is an excerpt:
I do see the benefits, but I also have a big déjà vû: The C#-language seems to go the C++-way, where I, even after 10 years of programming, don't know all of the features and sometimes still wonder "why does this thing behave this way?". So the complexity is raised from version to version. Does everyone think, this is a good way? I think it would be better to NOT enhance the language/compiler from version to version, but to enhance functionality by enhancing the library instead.
I think the added complexity concern is a valid one which deserves careful analysis. I'll just touch on my thoughts here.
One important difference between C++ and C#/VB is that C++ is designed by committee, where C# and VB each have a chief architect (Anders Hejlsberg and Paul Vick respectively) who doesn't have to try and satisfy everyone's favorite language request. I know the complexity concern is something Anders and his team have taken very seriously (as have the VB folks). I've heard Anders talk about the fact that they have to be extremely careful about this, and that he'd rather err on the side of caution. The C# team has rejected several of my favorite language features (such as generic variance, C++ style const, etc.) because they felt the benefits for the average user didn't significantly outweigh the extra complexity (even through there were compelling benefits for SOME users). This is where a lot of the "art" of language design comes into play. Personally I have a lot of respect for Anders and Paul and trust their judgment and the customer research their teams have done which concluded that in this case the extra complexity was justified. As much as I'd like to believe otherwise, there is probably a good reason here why Anders is the chief C# architect and you and I are not <grin>.
Of course they could be wrong, and it's important that Microsoft and our customers evaluate this risk seriously. Uwe suggested a compiler plug-in model where you could enable different features on demand. I'd love a public compiler plug-in model - there are so many cool features I'd like to add and use in my code. I've even asked Anders about this (in the context of the fact that expression trees means that some errors that could normally be detected a compile time now become run-time errors), and he indicated that to maintain simplicity and comprehensibility they are avoiding any such dynamic / customizable compiler behavior. I think Anders has a point here. In this case, just using the v1.1 or v2.0 compiler to target the latest CLR has similar benefits except that the possible feature combinations are fixed to well known sets, which avoids the confusion and complexity of the plug-in or optional feature model.
The other thing to keep in mind is that a lot of effort went into reducing complexity by adding a few powerful general language concepts, instead of many feature-specific concepts. I think Linq did even better than Cω in this respect. For example, unlike the Cω compiler, the C# 3.0 compiler has no knowledge of databases, SQL or XML, it's all in the DLinq and XLinq libraries. Personally, I find the new language features in the C# 3.0 spec to be quite simple and elegant, but then I'm a (functional) programming languages nerd so I'm not exactly the target audience.
Ultimately it will be up to our customers. If, after seriously experimenting and evaluating Linq, you think the extra complexity isn't worth the benefit, then it's important that you give us your feedback (we're getting better and better at listening to this sort of thing). On the other hand, the response from the PDC was overwhelmingly positive, so it would be likely to be an uphill battle <grin>.
Comments
- Anonymous
September 25, 2005
While C# does have a chief architect, he's a chief architect at microsoft.
C# is ECMA standardized, and in the end, the members of the working groups makes the call.
That said, it seems so far its only microsoft submitting proposals for enhancements and then refine em in the working groups.. At least to my knowledge. Maybe you can shed some light on this?
On that note, what would happen if ECMA rejected one of microsofts proposals? Would they then just ignore the ECMA standardization and do it anyway?
- Thomas - Anonymous
September 25, 2005
<a href="http://blogs.borland.com/dcc/archive/2005/09/15/21195.aspx" target="_blank">Here</a> is Borland's Chief Scientist on the topic of adding LINQ to the Delphi language. Scan down to the "LINQ for Delphi?" header. Seems that other .NET language vendors are going to pick up LINQ. - Anonymous
September 25, 2005
One might also imagine a plan to mitigate this linguistic complexity with additional IDE support; one might imagine something like the present visual database canvasses being used to visually edit "code-behind" type linq files, which are then exposed in a simplified view to the "typical" programmer. - Anonymous
September 25, 2005
Wow, thanks for your long reply to my comment :-)
Great explanaition of Microsoft's view. Thank you! - Anonymous
September 26, 2005
Thomas,
The Microsoft<->ECMA interaction question is an interesting one, but unfortunately one I have very little visibility into.
However, by reading the ECMA specs you can see that they allow quite a bit of flexibility and room for extensions. The CLR for example has many features that are not specified by ECMA. In some cases, there may even be some small CLR behavior/extension that is technically in violation of the ECMA specs. I suspect it's the same with C#.
As for the question of disagreements, Microsoft has obviously comitted to shipping generics support in C# and CLR 2.0, and that's not going to change. As far as I know, the ECMA commitee hasn't voted on the 2.0 extensions yet, so if they did decide to reject it, it seems like we'd have no choice but to ship as-is anyway. Of course we'd want to work pretty closely with them to address any concerns they had and iron out the problems. - Anonymous
October 18, 2005
Funny to just read this: :-)
http://msdn.microsoft.com/msdnmag/issues/05/11/EndBracket/ - Anonymous
December 16, 2005
The comment has been removed - Anonymous
March 28, 2006
I think all the concepts behind C# 3.0, and more specifically c-omega are valid. Its not a question of increased complexity but evolution.