Hands on: A programming revolution

Staying safe

The classic criticism of dynamic coding is that it is not safe. The compiler will not catch as many errors, so problems will emerge at runtime.

There could also be subtle bugs, such as when different classes have the same method name but with a different purpose in mind. Duck typing could fall flat on its face.

Dynamic language advocates respond by saying they have something better, which is test-driven development. This is a facet of the Extreme Programming movement, which argues that developers should write tests as they code, to verify that it runs correctly.

‘Testing is as important as programming,’ said Kent Beck in his book Extreme Programming Explained, adding more controversially that: ‘beta testing is a symptom of weak testing practices and poor communication with customers’.

Unit test frameworks such as JUnit for Java and NUnit for .Net make test-driven development feasible; testing is also built into Microsoft’s new Team System edition of Visual Studio.

Testing catches any kind of error, whereas static typing only catches type errors. A dynamic language accompanied by strong testing practice is likely to create more reliable applications than a non-dynamic language without testing.

Of course, you can do testing with any kind of language, not just a dynamic language. Arguably, that makes test-driven development with a non-dynamic language even safer.

That may be true, but it is all a matter of context. Test-driven development is a big deal, a revolution in programming that delivers significantly more reliable code. In the context of a test-driven development project, any loss of safety from use of dynamic versus non-dynamic language is relatively minor.

Which dynamic language?

The momentum behind dynamic languages is largely driven by Internet programming. Javascript is a dynamic language, complete with an eval function, and so are PHP, Python and Ruby.

The creator of the popular Rails web framework, David Heinemeier Hansson, told me in a recent interview that the dynamic typing in Ruby was a key factor in the success of Rails.

‘The static typing of Java is a big part of what’s holding it down,’ he explained. ‘In a world where testing is considered good, I think static typing is like a ball and chain.’

Javascript is also on the rise, partly because of the trend toward Ajax applications, which make heavy use of client-side Javascript running in the browser, and partly because of initiatives such as Abobe Flex, formerly from Macromedia, which uses Javascript as the language for rich Internet-connected applications.

The Java and .Net camps are not quite ignoring this movement. Both Java and .Net meet the first requirement of dynamic languages, which is the need for a runtime engine.

The next version of Java has its own dynamic scripting language, called Groovy, and there are also versions of Ruby and Python that run on the JVM (Java Virtual Machine).

Microsoft also has several dynamic language projects. One is the widely ignored JScript, which is part of the Framework and compiles to .Net intermediate language code.

Another is Iron Python, currently in beta but nearing full release, which brings Python to the .Net Framework. Although Microsoft has these projects, it does seem unable to make much of them.

All the marketing and examples from Microsoft focus on C# or Visual Basic. Given the general trend towards dynamic languages, that is surprising, though as noted below VB actually has some dynamic credentials.

Ruby is a great language to try in order to get the flavour of dynamic programming. It is not hard to install. There is a Windows installer, along with a plug-in for Eclipse IDE. 

Go dynamic with Visual Basic

In the days of Visual Basic 6 and earlier, there were clear limitations to the language. Nobody doubted that C++ was more powerful, and while Visual Basic justified itself in terms of productivity, it always felt like the second citizen.

In the .Net era, Visual Basic has close parity with C#, gaining features such as full inheritance and using the same Framework class library. Even so, C# is the shiny new language, most of Microsoft’s Framework code is written in C#, and Visual Basic is the one that has to justify its existence.

Until no. It is already recognised that Visual Basic is easier to use than C# for things such as automating Microsoft Office, with features such as optional and named parameters to simplify the code.

Visual Basic .Net is closer to a dynamic language than C#, especially if you do the unthinkable and turn off both Option Explicit and Option Strict. When Option Strict is off, Visual Basic supports duck typing.

In practice, working without strong typing in VB.Net is painful, because you lose intellisense code completion, the pop-up help that appears when you type the dot in the editor, but you can mix and match to some extent.

You should also consider getting hold of NUnit, which is free, or Team System, and writing tests for your Visual Basic code. Perhaps the assumption that Visual Basic should be used with all the type safety of C# and C++ will prove to be unfounded.