Today I visited MDCC (Microsoft Development Center Copenhagen) to attend a TechTalk named Dynamic languages for statically typed minds.

The lecture was given by Niclas Nilsson and his main goal was to convince us, the developers used mainly to static-typed languages, that dynamic languages have some advantages too. Niclas didn’t go into any theory, he immediately got to dispute typical arguments against dynamically typed languages and to code examples, mostly in Ruby. I don’t want to try to repeat everything what was told at TechTalk, I want rather to point out few thought and add some my own ones.

I really liked the example that Niclas used as a reaction to the lack of type safety. Look at the following C# code:

int x = 100000000;
Console.WriteLine(x*x);

The result is 1874919424, due to integer overflow. Thanks to type safety, we know the type of result in advance – but the result is wrong. Is this safety so great?

Let’s look at what’s going to happen in a dynamic language. (Because I’ve never written a single line of code in Ruby, I’ll resort to another dynamic language, which is mentioned quite often in this blog – PowerShell).

[int]$x = 100000000
$x*$x #Result: 1E+16
($x*$x).GetType().Name #Double

PowerShell decided to use another type to be able to process the result correctly. That’s great news, the bad one is that we don’t know in advance which type will we get from the operation. And if we find out the type only at runtime, it means that we are not able to perform type checks at compile time.

Niclas had an interesting answer to the lack of these checks – Test-Driven Development. Because he is able to check everything dynamically, he doesn’t need static checks too much.

Then he showed few interesting things in Ruby, I was very attracted by one of them. I’m familiar with things like dynamically created types, runtime changes of existing types etc., but I expect that if I call a non-existing method, an error occurs. But objects in Ruby can process even calls of methods which don’t exist in the object – it simply gets a message “somebody tries to call a method X with parameters Y on you” and the object can react somehow. Niclas showed this on the object that processed all calls of (non-existing) methods with names starting with find_by_ and tried to search its data. For example, in case of find_by_name it looked to name property and compared its value with the argument.

In TechTalk discussion, opinions like “This can be done in C# too” were often heard. That’s true indeed, however the point (as I see it) is not about whether it can be done, but how easily can some sorts of problems be solved in some language (language family, paradigm…). If something enables me to do the same work more quickly, more readable, with less code or to more easily maintain the whole solution, I should think about that.

By the way, if statically typed object languages were the best all the time, why would we add functional elements (e.g. Lambda expressions in C#), declarative programming (XAML) or dynamic types (dynamic keyword) to them?

I became acquainted with dynamic languages in PHP, currently I meet mainly PowerShell, but even in C# I sometimes encounter dynamic types (e.g. in UI Automation). Simply said, dynamically typed languages are not a toy for those who haven’t yet discovered “proper” type checking – it’s just another approach to problems.

I’m convinced that good programmers must have broad knowledge – it helps to choose the right way of implementation, to see one thing from different angles and often also to learn a new technology more easily. I see every day developers who tries to deal with those weird events in Dynamics AX 2012 – even though C# (for instance) has them already ten years. Or I would gained insight into LINQ more easily if I knew more about functional programming by then.

What I expect from conferences or such meetings like TechTalk is not to learn something concrete, but to get something to think about and what I might to study by myself. And Niclasovi succeeded in this today. Thanks.