Tuesday, 28 May 2013

Types, Tensions and Risk.

The dichotomy between strongly typed languages (such as C) & dynamic scripting languages (such as Python) has already been debated & explored ad nauseam. This contribution, akin to flogging a horse long since dead and buried, will be of little interest to anybody, but it does help me clarify my own position on the matter, so here is my tuppence worth anyway:

Strong typing is supposed to buy you (the developer) a degree of protection from certain types of error. However, that protection comes at a significant cost, and really only provides a worthwhile benefit in a limited set of circumstances.

First of all you do not really reap the benefits of it *just* by using a strongly typed language. You really have to go out of your way to make use of the type system to get the benefits. You have to define your own types so that the system can enforce the non-convertibility of mutually incompatible data types. You also loose a helluva lot of flexibility, because every data item must be specifically typed.

Indeed, developers working with strongly typed languages waste a lot of time writing "generic" frameworks that do nothing else other than circumvent the type system; simultaneously losing the benefit of strong typing whilst also adding to the complexity and cognitive burden of others working on the same system.

Languages with weaker type constraints gain a *lot* of productivity simply by avoiding this whole "let's write something generic" song-and-dance routine. It also focuses the mind on alternative approaches to QA & testing. However, this additional flexibility & productivity often results in a *lot* more code being written (which must be maintained), a tendency which can quickly become self-defeating. (Sometimes what looks initially like exceptional productivity is just exceptional waste in disguise).

Strong typing, used properly, *does* provide value, under certain circumstances, in forcing decisions about data types to be made up-front, rather than deferred to a later stage. It also helps to document interfaces and to make them more specific.

It seems to me that weak typing & the generic interfaces that we end up with as a result result are most useful when we have to defer decisions about the specific data types travelling through those interfaces until later in the development process. Strong typing; leading to the development of specific interfaces are most useful when we are able to specify exactly what data types will be passing through our interfaces early on in the development process.

I.e. strong typing is more congruent with a predictive approach to risk-management, whereas weak typing is more congruent with a reactive / agile approach to risk-management. Of course, this is not a hard-and-fast rule, and successful adoption of either risk-management approach requires high levels of discipline.

Anyway, it is interesting to note the interplay between detailed technical decisions (Strong vs Weakly typed programming languages) and broader business decisions (Approach to risk management & decision scheduling).