Are cells a good analogy for software?

I have some sympathy for Alan Kay’s “biological analogy” that software could be constructed to resemble biological cells, with each component having a clearly defined barrier (cell membrane) and ability to act autonomously as well as collaboratively. This is, after all, how agent-oriented languages should work too. However, the analogy can clearly only be taken so far. A human cell contains around 6 billion base pairs of DNA, each of which can store a maximum equivalent of 2 bits of information. This gives a total theoretical storage capacity of 12e9 bits or 1.5e9 bytes — roughly 1.4GB, or slightly less than an iPod shuffle. In computational terms, that’s quite a lot. Furthermore, this information is redundantly duplicated on a massive scale within every single cell of your body, and largely duplicated between individuals even of separate species. If this were a computer system, it would be a hugely inefficient and anti-modular one. By modern software engineering standards, a cellular organism is a jumble of duplicate components, each of which is a monolithic mess of spaghetti code!

Nevertheless, I do believe there is still much value in this analogy. After all, as Kay would point out, biological systems are much more sophisticated* than anything we can yet build, and generally much more resilient too. But we must be careful in pursuing such analogies, as the design goals of evolution are different to our own. While evolution can dispense with the intelligent designer, we cannot! And those intelligent designers have their limits. They need to be able to revisit design decisions and update running systems to correct flaws, optimise performance, adjust to new challenges, etc. Modularity is crucial to these tasks. If there is a God, He is not a software engineer.

PS – I recognise that Kay himself is well aware of these limitations of the analogy, as is abundantly evident in the wonderful design of Smalltalk.

* NB: I much prefer the term “sophisticated” to “complex”: the former is perhaps a goal worth pursuing, the latter should be minimised or eliminated.

First class and higher-order

The terms first-class and higher-order can be confusing to people first encountering them in relation to programming languages (usually through exposure to some functional programming language). At first glance it can seem that they mean sort-of the same thing, but this isn’t really the case. Both refer to the ability to pass functions around like other values, but they relate to different aspects. The term higher-order is a statement about the interface of a function. It means that the function is able to accept other functions as arguments (or even the same function) and/or return functions as its value. It originates in logic, where a first-order logic is able to make statements only about objects in the domain of discourse (e.g., “all men are tall”) , whereas a second-order logic is also able to make statements about first-order relations over those objects (e.g., “all properties of men are also properties of women”). A higher-order logic is then able to make statements about any lower-order relation. On the other hand, the term first-class is a statement about how a language handles certain kinds of values. In particular, it usually means that a certain kind of value (such as functions) can be treated on an equal level with all other kinds of value (such as strings or integers), and can be passed to/returned from functions, stored in data structures, and so on. These are distinct concepts: a language might permit higher-order functions that are not first-class, and vice-versa.

Hello world!

I thought I’d get myself a blog, separate from my university pages. Hopefully from now on I can use this as a place to put various essays and ideas that I have that are not directly relevant to my academic career. For now, I need to get ready for my trip to Toulouse on Monday, so not much will appear here for a little while.