layer 1 vs layer 2 programming

Jan 04, 2019

this is a weird idea that i think is worth exploring in how we thing about computer programming. i typically program with two primary tools, vim and the bash shell, with vim kind of being nested inside of bash. the vim tool is used to edit plaintext program files and the bash tool is used to do larger operations such as compile or run individual code files. more significantly, bash is used to do “scripting” operations that call individual program files (or binaries compiled from them). both the operations specified in text files with vim, as well as the operations specified on the terminal with bash, are part of programming but are generally treated somewhat differently. directly editing text files that describe computations to be compiled and/or run later represents something of a “layer 1” programming, while the process of using these layer 1 programs or doing general operations (as enabled by the larger operating system) serves as an encapsulating “layer 2”.

the Unix philosophy of programming is somewhere where this contrast is best illustrated, and generally serves as an inspiration for my thinking of this. but other programming systems and models, in more specific domains show how this principle manifests. a good example of this is ML programming workflows which usually consist of the distinct layer 1 process of specifying model architecture in tensorflow/pytorch or something and the wider layer 2 process of actually training the models or deploying/running them in different environments.

additional note as at Feb 04, 2019: i was reading about Ivan Sutherland’s work with sketchpad and the field of constraint-based programming as a whole and it feels like there’s some interesting mappings between this and the layer 1 - layer 2 metaphor i’m trying to develop here. constraint-based environments involve the two distinct processes of defining constraints on the behavior of a dynamic system and then creating and experimenting within this constrained environment. perhaps thinking of regular coding as setting constraints and scripting as the experimentation aspect, gives more solidity to this metaphor and shows more parallels in how dual-layer programming processes can be used for a more powerful experience. for instance, the direct visual manipulation presentation of sketchpad gives us something of a hint as to how to build a more intuitive programming experiences.

this constraints idea is pretty vast in how it applies to creative processes. abstractions are fundamentally constraints we apply in programming. different paradigm such as object or function orientation; static or dynamic typing are constraints that give us mroe accidental successes (see: https://vimeo.com/242081961). will maybe talk more about this stuff. constraints often imply learning/setup curves, but they’re often very useful. indeed, what is a system but the constraints in which it exists and operates