Tuesday, January 5, 2016

Is naming everything in programs an evolutionary dead end?

We program largely by using systems whose discrete components are bound by naming conventions.

Living systems don't use names much, at the scale of cellular biology anyway. Names are an affect of emergent brain behavior - the assignment of symbolic communicative phonemes to what a brain experiences, and their serialization as text, vocalizations, and actions.

Cellular biology has interfaces. But those constructions don't act like the interfaces we use in programming. The code interfaces we use are defined on the basis of symbolic names and structural signatures, and they are forced to bind deterministically rather than probabilistically. Out code signatures also largely conflate the  structure with the payload (eg the argument parameters). Cell biology may make packages in which the payload acts as the signature, but often uses complexes whereby the key signature is distinct from the payload: the interface acts as a carrier or wrapper or adjunct whose role diminishes once binding is accomplished.  That is, they often use monads.

Our code comprises a living system, for no other reason than it is an extension of us. No, it is not quite the same thing as dead skin cells, hair, or fingernails. Code is more akin to the living arrangement of dendrites in our brains, or the skeletal muscle... it can be remodeled, sometimes merely by existing.

Brains and musculoskeletal structures have been around for a very long time by comparison to code. Brains and skeletons scale as solutions, both in terms of performance and numbers of applications. Yet neither system architecture makes use of names as a principal organizing device. Names are created by brains, for the brain to recursively model, and muscles don't use naming systems at all. Molecular biology also makes do without the use of names, even though quite a lot of activity in that realm appears to be discrete - even tokenized.

Somehow these systems are able to perpetuate, grow, search solution spaces and address novel problem domains in ways that make our computational machinations look like toddler's toys. We know why we follow the use of currently popular programming language models - there exist effective processes for expressing solutions and analyzing them under these models - but it begs an important strategic question. If evolutionary pressures push our software systems toward closer and closer approximations of the real world, the designs will necessarily mean explicit names become secondary or disappear entirely from the architectural approach.

No comments: