Joel Pobar has posted an excellent start of what should be an interesting set of blog entries on how dynamic/scripting languages work on the CLR. When listing out the dynamic languages available on the CLR he includes among them VB, which may come as a surprise to some people. In many places the cult of Option Strict may have convinced people that VB is an entirely statically typed language like C# is, but they’d be wrong. In fact, a decent chunk of our Whidbey time was spent rewriting our late binder to handle all the new language features in this release: unsigned types, generics, overloaded operators. I’m not sure how much people realize that they can now, say, add two objects together and we’ll correctly figure out the right user-defined operator (and/or conversion operators) to call. It’s one of those less-heralded features.
The interesting thing, of course, is that because the CLR class libraries are much more statically typed than most COM libraries ever were, there are some ways in which dynamic typing has become much less important than it once was. If you were going to, say, work with the Office object model, late binding is pretty much a necessity in many instances. However, the .NET Framework has really gone out of its way to introduce strong typing wherever possible, partially because of general typing goodness and partially so that languages like C# don’t completely fall over in the face of too many things typed as Object. This has had the effect of really swinging the typing pendulum pretty far towards the strong typing side, so I’m really glad to see a lot of creative ferment in the scripting/dynamic typing space. Because, folks, let’s face it — strong typing can be a pain in the ass sometimes.
One of the places where this is most evident, I think, is in the data access space. As anyone who’s used a data-intensive application from Excel to Access to FoxPro to SQL Server can tell you, data is extremely flexible when it comes to typing. A lot of data out there is only semi-typed and as you work with data it frequently needs to change type (and shape, as you add and remove columns). Strongly typed systems often times have a hell of a time dealing with this flexibility, and so it comes as no surprise that pretty much every single application I listed above takes a weakly-typed approach (some more than others) when working with data.
As I’ve hinted at before, one of the major investments we’re going to be making in Visual Basic post-VB 2005 is in integrating data (both XML and relational) more deeply into the language than ever before. We’re planning on talking a lot more about specifics at the PDC, but this general topic definitely has a large impact on our thinking about data. It’s also been very interesting to watch as C# has also thought about data integration (as Brad also hints in his post) because they’re a much more statically typed language, which means there are some places where we may be going farther than they’re willing or able to…
Anyway, the benefits of dynamic typing are hardly limited to data access, and as we think beyond our current release we’re investigating ways in which we can take even more advantage of it in the future. In doing so, we’re really trying to straddle both sides of the religious war between the static typers and the dynamic typers. To paraphrase Erik Meijer (who we’ve been working a lot with lately) the ideal principle seems to be:
Static typing where possible, dynamic typing where needed.
This seems to be the sweet spot, the best of both worlds. Will we be able to achieve it? Well, we’re going to take our best whack at it…
Updated 07/08/05: Peter Drayton pointed out to me that he and Erik wrote a paper on their principle, so I added a link. Also fixed the link to Joel’s entry thanks to mikhar!