Hands on: A programming revolution

Dynamic languages are in. For programmers who have kicked around a bit, this comes as a shock.

The accepted wisdom was that static typing and early binding were good, resulting in more robust code and leaner, better-performing executables.

Static typing means declaring the type of all the variables you use. Visual Basic has Option Explicit, which requires all variables to be declared, but still lets you get away without mentioning a type.

The following runs fine:

Dim myvar
myvar = 1234
myvar = “a string”
Me.Caption = myvar

Behind the scenes, Visual Basic declares myvar as a Variant, which can represent any kind of type. Variants are slow. A quick test with a loop that tests whether numbers are prime is around three times faster when the variables are declared as integer.

In Visual Basic 6, many developers learned to be disciplined, not only using Option Explicit but also remembering to use Dim with a type, even if it happens to be Variant.

In VB.Net you can go further and enforce this with the Option Strict statement, making Visual Basic more like C or C#.

Doing this enables the compiler to catch certain kinds of error, such as misspelt variables and illegal assignments, as well as helping the compiler to optimise performance. Programmers assumed strong typing was good.

So what changed? The answer is, several things.

First, today’s computers are faster, making performance less critical in many scenarios.

Furthermore, there is more to performance than compiler efficiency. Most applications can be speeded up by making the algorithms smarter.

If the language you use is more productive, you have more time to spend on optimisation, which is a non-technical reason a slower, easier language might end up performing better than a faster, more difficult language.

The second change is an increasing awareness of the cost of static typing. For one thing, it means more typing. That might seem a trivial point, but it is not. More concise code is usually easier to understand as well as quicker to type.

Dynamic typing also spares you the cost of trying to figure out in advance whether you need an Integer or a Long, a Single or a Double. If the compiler will just do the right thing, you can get more work done.

It is not just a matter of concise code. In some circumstances, static typing makes you jump through hoops. For example, imagine you have a couple of classes in your application, both of which need to support printing.

Maybe one represents an address, and the other an order. Therefore you add Print methods to both classes. It might be convenient to have some code that can print both address and order objects, simply by calling Print as in this VB method:

Public Sub PrintIt(ByVal obj As Object)
obj.Print()
End Sub

In a language such as C# or Java, you cannot do that directly. There are a host of workarounds. You can define an IPrintable interface and have both classes implement it.

You can create a CPrintableObject class and have both the other classes inherit from it.

You can use Reflection to look up the method at runtime. You can have some conditional code that checks the object type, casts to the appropriate object and calls its Print method, which is fine until you create a third class with a Print method.

Whichever way you do it, you have to add a chunk of code. By contrast, this is easy in a dynamic language, where you simply call Print and let the runtime work out how to execute it.

This is called ‘duck typing’ – if the object walks like a duck and talks like a duck, it might as well be a duck.

The trade-off is that you might get a runtime error if the method does not exist, or if it returns an unexpected type, whereas the stricter languages would catch this at compile time. The point is that static typing also has a cost, adding verbosity and complexity to the code.

Certain other things are harder to work around in non-dynamic languages. One is adding or removing methods at runtime. Another example, which will be familiar to many developers, is evaluation.

This is where you take a string at runtime and execute it as code. Evaluation is very useful in certain applications, but it is absent from Java, C# and Visual Basic.

To get round this, you need to write your own parser, or compile code at runtime, or get some help from a different language. Microsoft’s script control is one possible solution.