A Short History of Dynamic Typing in Visual Basic
Visual Basic has always been on the fence between static and dynamic typing. In the beginning VB supported late binding, which is known today as “duck typing”. Explicitly declaring variable types, or even local variables at all, was considered optional. But if you did declare the variable types, it would operate in early binding mode with runtime type checking and better performance.
With the introduction of COM in Visual Basic 4, VB got some interesting features not seen in most languages. When declaring variable types, the compiler would implicitly refer to interfaces rather than concrete classes. This wasn’t always obvious, as every class implicitly defined an interface with the same name. The net effect was that under this scheme any class could explicitly implement any other class’s interface, though no class could directly inherit from another. While VB developers generally hated the lack of inheritance, Google’s recently announced Go programming language has a similar design.
With Visual Basic 7, also known as VB.NET, the language dropped its unlimited interface style polymorphism. In its place we find the combination of implementation inheritance and explicitly defined interfaces that Java made popular. VB also gained the Option Strict directive which causes the compiler to require explicit type declarations and casts.
While VB was marching towards a more statically typed paradigm, the rest of the world was increasing turning to dynamically typed languages such as Python and Ruby. It would take two more versions for Visual Basic to take notice and start swinging back the other way.
VB 9 proposed several interesting features in the realm of dynamic typing. The first is the incredibly successful XML Literals and XML Comprehension. This syntax was proposed for the Haskell programming language and prototyped in a variant of C#, Visual Basic is the second language to see this syntax make it to production use. The first appears to be ECMAScript for XML, first standardized in 2004.
On a side note, XML Comprehension isn’t the first time VB added special syntax for a narrow set of types. VB also has the bang operator (!) which was used in versions 3 thru 6 for database access. Though still supported for any dictionary style lookup, it has fallen out of favor. An example follows.
firstName = recordset!FirstName lastName = recordset!LastName
Some Visual Basic 9 features didn’t make the final cut. These features would have allowed developers to create objects and access properties by name at runtime without explicitly using the reflection API. For example:
className = “Customer” memberName = “FirstName” x = New (className) x.(memberName) = “Fred”
Looking to the future, Lucian Wischik of Microsoft, has mentioned that they are looking into making the XML Comprehension syntax extensible. Currently they are considering support for XAML and, when inside Silverlight, the HTML DOM. However, it can also be applicable to any other tree-style data structure.
It should be noted that Visual Basic’s younger sibling VBScript has its own features. Like most interpreted languages VBScript has functions for executing arbitrary code stored in strings. These functions, Eval and Execute, were often leveraged by VB 6 applications when additional dynamic capabilities such as end-user scripting is needed. In the future we expect IronPython or IronRuby to serve that role.
...the rest of the world was increasing turning to dynamically typed languages such as Python and Ruby.
Just in the blogosphere, not in reality.
Late Binding is not Duck Typing
VB supported late binding, which is known today as “duck typing”.
Late Binding is for static and dynamic languages, duck typing is for dymanic languages.
Java has late binding but it is not dynamic.
Ruby has late binding and duck typing.
Re: Late Binding is not Duck Typing
Andrea Del Bene
Re: static/dynamic reality
Re: Late Binding is not Duck Typing
Visual Basic, and C# 4+, supports true late binding where in only the method's name is known as compile time and the variable is untyped. I think you will agree that this matches your definition of duck typing.