VB as a dynamic language

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!

15 thoughts on “VB as a dynamic language

  1. Eric Mutta

    One of the things I really love about VB is how it lets *me* be the judge of whether to use dynamic or static typing.

    In all my project I have Option Strict On in all files except the "main" one where Sub Main is found. Even Option Explicit is Off in that main file and this is where I do quick and dirty code to try out algorithms before they become official and end up in another file. With the return of Edit-n-Continue the bliss can only increase :-)

    Oh, and congrats on the work you and your team have done with VB 2005 – it’s the language I’ve been waiting for ever since I learned to both love and hate C++. Now that it does generics and unsigned types, only doing the dishes remains :-)

    Reply
  2. Pingback: Lorenzo Barbieri @ UGIblogs!

  3. Mike Gale

    Thanks for this article. It lifted my spirits.

    I hadn’t seen this article by Eric Meijer. It’s good to people getting beyond the sterile and unhelpful debates about languages and getting to the underlying needs.

    After VB gets the things expressed in C-Omega there are further areas where the language needs to go. I hope you get there while I’m still programming!!

    Reply
  4. Pingback: VS Data Team's WebLog

  5. Pingback: VS Data Team's WebLog

  6. wOOdy

    It’s really funny to watch you guys, as you realize that it all boils down to "gee, we already had this stuff ten years ago, when we created VISUAL FOXPRO, but let’s reinvent the wheel anyway"….

    Reply
  7. Pingback: @ Head

  8. Pingback: Panopticon Central

  9. Pingback: Panopticon Central

  10. Martin Lercher

    I don’t think that dynamic typing has any benefit (besides the mighty Office DOM ;-). All you will get is program that compiles, nothing else. You have to check all the tiny fuzzy things by yourself by your brain and by your time, that otherwise the compiler could easyly check in the fraction of a second. If you run your program, you’ll get a lot of hard to track run time errors in each execution path you could never ever test completely. Where did my spare time go? Fixing bugs a strict type system would not permit. No, I don’t have the _time_ for this.

    Martin

    Reply
  11. Pingback: Erwyn van der Meer

  12. Pingback: @ Head

  13. Pingback: Panopticon Central

Leave a Reply