The Map Is The Territory

Where representation is reality, TheMapIsTheTerritory.

DataManipulation is used (about equally) for both reflective systems (that attempt to describe something that has reality external to them) and projective systems (that create a reality internal to the system). For reflective systems, TheMapIsNotTheTerritory. For projective systems, TheMapIsTheTerritory.

In software systems in general, it is very often the case that TheMapIsTheTerritory. This is true for simulations, formal language interpreters, codecs, value-descriptions, communications protocols, messages, concurrency management, calculations, evaluations, software patterns, etc.

In hardware systems, it might be more accurate to say that TheMapBecomesTheTerritory. This creates some rather unique properties, since we can know everything about the territory if we can assume it was manufactured correctly.

Gee, doesn't this remind you of TheSourceCodeIsTheDesign? [snicker]

If you write your requirements in executable specification languages (Maude, Coq, Agda, OBJ-3, etc.) then it would not be unreasonable to claim that TheSourceCodeIsTheDesign. But TheMapIsTheTerritory applies more broadly. For example, in a massive multi-player video game, the game world is exactly what the map says it is: the 'model' of the world is the 'physics and reality' of that world.

No. The map is the code - an abstraction waiting to be realized in a computer. That realization - electrons flowing through a specific bit of hardware - is the territory, and the map is not the territory. The code describes system behaviour; the description is not the behaviour. What distinguishes software is that (1) the map to territory relation is many to many instead of many to one, and (2) the map precedes the territory. -- MarcThibault

Of what, precisely, is the code a map?

Of the system behavior. -- mt

See: TheMapIsNotTheTerritory, TheMapBecomesTheTerritory