Object Mentor Blog: Protecting Developers from Powerful Languages

Protecting Developers from Powerful Languages

Dean Wampler — Mon, 15 Jan 2007 21:57:00 +0000

Microsoft’s forthcoming C# version 3 has some innovative features, as described in this blog. I give the C# team credit for pushing the boundaries of C#, in part because they have forced the Java community to follow suit. ;)

A common tension in many development shops is how far to trust the developers with languages and tools that are perceived to be “advanced”. It’s tempting to limit developers to “safe” languages and maybe not all the features of those languages. This can be misguided.

Java is usually considered safe, but Java Generics are suspect. Strong typing is safe, but dynamic typing isn’t controlled enough. Closures and continuations sound too advanced and technical to be trusted in the hands of “our team”.

To be fair, larger organizations have more at stake and caution is prudent. Regrettably, it is also true that many people in our profession are … hmm … not that well qualified.

However, I find that I’m far more productive and less likely to make mistakes using Ruby iterators with closures than writing more verbose and inelegant Java.

I used to be a strong believer in static typing, but it has become a distraction, as I have to worry more about the types of method parameters and return values, rather than just worrying about the values themselves. I realized that, on average in a typical section of code, the actual type of a variable is unimportant. The variable is just a “handle” being passed around. The name is always important, as it is a form of documentation. There are places where the type is important, of course, when the variable is read or written in some way.

Finally, static typing offers less security than at first appears. At best, it only confirms that variables of particular types are used consistently. Your unit tests also do this. However, static typing can’t confirm that the usage of the API is correct. This is analogous to testing the syntax but not the semantics of the program. In fact, only unit tests (or alternatives, like rspec ) are effective at testing both.

So, it’s prudent to be reticent about newer languages and features, but make sure the decisions you make about them are backed up by careful evaluation and don’t forget to train your team appropriately!

"Protecting Developers from Powerful Languages" by Ramon Leon

Tue, 23 Jan 2007 01:30:28 +0000

Smalltalk has intellisense, and refactoring browsers.

"Protecting Developers from Powerful Languages" by Dean Wampler

Fri, 19 Jan 2007 15:08:07 +0000

All – I agree that better statically-typed languages exist and I have a big TODO list to learn some of them! Of course, my arguments are based a lot on the practical situations I find myself in.

Jonathan – I guess I don’t find the time trade-off of making my unit tests a little better at “syntax” checking that bad. The “total cost of effort” seems to favor dynamic languages. Maybe it’s a personal preference.

"Protecting Developers from Powerful Languages" by David Chelimsky

Fri, 19 Jan 2007 12:07:58 +0000

Jeff – being committed to TDD, I find that intellisense gets in my way more often than it helps. Maybe that’s just me.

"Protecting Developers from Powerful Languages" by Jeff L.

Fri, 19 Jan 2007 11:51:22 +0000

What of tools that are more effective in statically typed languages? To some extent they’re not as important, but I’d certainly miss intellisense were I to go back to Smalltalk or dig deeper into Ruby.

"Protecting Developers from Powerful Languages" by Masklinn

Thu, 18 Jan 2007 03:54:11 +0000

Dean > I tend to agree with Greg here: I got on that road (of hating static typing and preferring dynamically typed languages if only because they weren’t statically typed) before I discovered that all the things I hated in static typing, and all the things you hate (verbosity, lack of flexibility, redundancy, lack of “real” security) were really failure of Java, not of static type systems in general.

Then I discovered Haskell, and it blew my mind what you could get done with a static type system.

Now don’t get me wrong, I still find static type systems annoying from time to time, and I still love dynamically typed languages (I’m very fond of Python, Ruby and Erlang, and intend to learn Smalltalk in the future), but static type systems do have their use, and static type systems done well don’t hinder flexibility much while generating wealth of expressive power and safety (yes, I said it, and I’m not talking about Java here).

"Protecting Developers from Powerful Languages" by Greg Buchholz

Wed, 17 Jan 2007 18:32:25 +0000

Maybe you’d like to try a language with a better, more modern type system. Something like…

"Protecting Developers from Powerful Languages" by Jonathan Allen

Wed, 17 Jan 2007 17:00:19 +0000

I agree with most of what you say, but this last bit rubs me the wrong way.

> Your unit tests also do this. However, static typing canâ€™t confirm that the usage of the API is correct. This is analogous to testing the syntax but not the semantics of the program. In fact, only unit tests (or alternatives, like rspec ) are effective at testing both.

I don’t belive that to be true. It seems to me that manually creating unit tests is a poor substitution for knowing that syntax is correct. The compiler is far less likely to remember to test a particular code path than you are.

Moreover, time for testing activities is always limited. Given the choice, I would rather spend all of my unit testing time on semantics than spend half of it on syntax when a good compiler can do for me.

So you know where I’m coming from, I am a long time VB programmer who has made the transition from loosely typed pre-.NET era to strictly typed systems of VB7+. I have noticed significant gains in both performance and correctness as a result of this change.

This is not to say I don’t see the benefits for a smarter type system that heavily relies on generics and type inferance to reduce the cost of static typing.