‘Code is data’ is a metaphor around which the Lisp communities (and REBOL, and others) have built programming languages. The metaphor is effective in these languages because code is presented and represented as a simple structure which may easily be manipulated and processed as data, or evaluated; this is leveraged for development of macros, fexprs, and DSLs. In context of other languages, e.g. C++ or Java, the ‘code is data’ metaphor is much less effective. Metaphors are useful insofar as they shape our tools, our intuitions, our communities.
‘Code is material’ is a similar metaphor, an alternative to ‘code is data’. I’m not aware of any community that consciously uses the ‘code is material’ metaphor, but it does seem applicable in retrospect to flow-based programming and some visual dataflow languages, and perhaps a few esoteric languages like Snusp. By ‘material’ I mean to invoke the intuitions surrounding physical substances used to build other products – e.g. wood, metal, glass, rope. We have many intuitions surrounding materials:
- materials are portable and fungible by nature (and often available in bulk)
- behavior of a material is intrinsic or based on universal physical laws
- materials can be composed or shaped into new materials (molecules, fabrics, bricks)
- materials vary widely in quality, robustness, ease of use, etc.
- we don’t ask whether materials are meaningful, only whether they are useful
Of course, code does have an advantage over physical materials: code can be cheaply and precisely replicated.
‘Code is data’ and ‘code is material’ stand in opposition with respect the presence of an ‘interpreter’. Data is interpreted. It is possible to have multiple interpretations of the same data. Materials aren’t interpreted. The behavior of materials is intrinsic or based on universal laws.
For distributed programming or mobile code systems, I like the idea that my code should have the same behavior everywhere. For reasoning, refactoring, and optimization purposes, I like the ability to transform code in systematic ways while preserving behavior. For modularity and security purposes, I like the possibility of hiding implementation details or information within code and closures. These desiderata are better supported if the behavior of code be universal, independent of interpreter.
I imagine, if we take the ‘code is material’ metaphor far enough, that we would be working with composable bricks or structures of code in a virtual reality or augmented reality programming environment, replicating them as needed. Occasionally we might disassemble and reshape a structure for use in a particular problem (perhaps manipulating embedded literal widgets). There would be very little need for a conventional programming language; programming could be approached more as mechanical tinkering. The resulting code-is-material structures may be given part numbers based on secure hash, or directly shared with friends and communities. Applications would consist of devices or tools, themselves constructed of code, of an appropriate type to be ‘installed’ or ‘equipped’ in the programmer’s environment.
Awelon project is aiming towards such a future. The Awelon Bytecode (ABC) is an excellent foundation for the ‘code is material’ metaphor. Awelon Object (AO) is a Forth-like language, allowing users to define words. But those words do not remain entangled with the environment: every AO word is compiled into a finite and environment-independent sequence of ABC, and thus is easily treated as a named ‘brick’ of material, readily ported to other programming environments.
ABC has many useful properties that make it especially suitable for the ‘code is material’ metaphor:
- ABC is highly compositional. Concatenation is sequential composition. Concurrent composition is possible due to the causal commutativity requirement. Composition of conditional behaviors is available because ABC favors sum types instead of closed if/then/else behaviors.
- ABC code interacts with its environment locally. Every operator manipulates a local value. ABC lacks the conventional heap, pointers, and remote references. Thus, ABC’s behavior is similar to interactions between physical materials.
- ABC has atomic and molecular structure: at the lowest level, there are about forty bytecodes that can be understood as atoms. A small, reusable sequence of bytecodes can be understood as a molecule.
- ABC’s molecular structure is very linear, similar to genetic code. It is quite feasible to search for new ABC materials by genetic programming, substituting and mixing reusable ‘genes’ (of appropriate type) in a larger program, which might then construct other objects. We can deeply leverage ABC with biological material metaphors (wood, thatch, etc.).
- ABC is streamable, i.e. instead of the common stored program concept. A streamable program cannot jump backwards. ABC cannot jump at all. (Loops are modeled using fixpoint combinators; no jumping required.) This allows ABC to model not just ‘solid’ materials such as bricks, but also unbounded ‘fluid’ materials, such as command streams or user input.
One of the underlying ideas for Awelon project is the ability to extract reusable code – e.g. user macros and tools – from the user input stream. This is a form of programming by example. And the envisioned Awelon project environment is certainly leaning towards the VR/AR system described earlier. I’m happy to have found a simple metaphor to describe almost every idea underlying Awelon project: code is material.
Aside: A related metaphor is that ‘programming languages are materials’, occasionally presented in opposition to ‘programming languages are tools’ . But I feel it isn’t just the language that is the material; it’s also the frameworks, the libraries… the code in general.