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).

Friday 10 May 2013

How to engineer an Artificial Intelligence

Intelligence is a defining human characteristic, so it is somewhat doubtful that we would ever be able to pin down what it is precisely enough to make an artificial version of it ... we will always try to define and redefine the term "intelligence" in such a manner that humans remain separated and protected as a separate and distinct class of entities ... our collective ego demands no less.

However, if we put our collective ego to one side, we can surmise that intelligent behaviour consists of some general purpose learning and behaviour-directing mechanisms sitting on top of a whole heap of special-purpose sensorimotor mechanisms.

Engineering an artificial system to emulate some or all of that behaviour is a monumental engineering task. Irrespective of the fundamental breakthroughs in learning, generalisation and planning that may or may not be required, we are still left with an exceedingly large and complex software engineering challenge.

In my mind, this represents the primary obstacle to the development of a true Artificial Intelligence: Not better science, but better software engineering practices and (particularly) better software engineering tools to help manage, visualise, understand and communicate complicated software systems.

Now, this is an interesting problem, because software engineering at a large scale is much less concerned with hard technical challenges and much more concerned with "soft" human challenges of communication and politics. The same can be said for any engineering challenge where the complexity of the subject matter, combined with it's lack of visibility makes communication and documentation a key technical challenge.

Let us look at the communication challenge first: One thing that is becoming more apparent in our increasingly information-rich environment is that communication is constrained much more by the time-management and motivation-management of the reader than by the availability of the information.

In other words, it is not enough just to make information available, you have to manage the relationship between the reader and the information as well; so that information is not just dropped in front of the reader, but the relationship between the reader and the information is managed to support learning and effective decision making also.

How might one achieve this?