It seems to me a philosophy of code that begins at the "low" level of binary and machine instructions, would ultimately reduce to a contemporary British/American Analytic style of philosophy to the exclusion of all else, seeing as how the core level of communication is binary -- logic, to the exclusion of rhetoric, in the classical sense of both of those disciplines.
If you take a logic class at a basic level in both a Philosophy and CS context (as I did), you'll be struck by the massive overlap -- DeMorgan's theorem, modus ponens, et. al.
Setting aside for the moment the possibility of alternate CS architectures (neural nets, quantum computing and so forth), this would seem at first blush to limit the relationship of all computer languages to a 1:1 relationship with logic.
However this "reductionist" (foundationalist?) approach to finding a true semiotics of CS may not tell the whole story. As we move from the "low" level to the "high", say from the domain of machine code all the way up to, for instance, a rich, expressive Ruby DSL, the question arises, as it does for all language: have we acquired a surplus of content that cannot be simply reduced to core rules? At this point things get less Wittgensteinian and a little more late-Heideggerian, i.e., less analytic and more eidetic/phenomenological.
To remove the fuzziness from this notion, think of how, for instance, a first-person shooter creates the illusion of a smooth, analog reality from a rigid, frame-by-frame progression (as cinema does as well -- and this question has been explored at length in that world). As humans interacting with the result of the code, we infer content between the frames -- we make up the difference and experience the virtual world presented to our senses as continuous analogical rather than chopped-up and merely logical. Code never exists in a vacuum -- it is experienced by humans and humans bring meaning to it, as much as it brings meaning to them.
There's a similar phenomena in OOP, where the meaning of the code is not merely the sum of its final binary product ("true" or "false") in the world of machine instructions, but in the metaphor it presents as a model of an object or event in the world. This code is constantly changing (literally) as it intends towards richer analogies with the world, and we as coders (and users) make up the difference by bringing real-world experience to it when we "read" the code. In other words, code is never "true" or "false" as a function of its binary reduction, but is a constantly-changing artifact of some human being's attempt to analogize the world, read by other human beings attempting to understand and refine that analogy.
In this sense the general problem is, as another poster phrased it so well, semiotic rather than epistemic or even logical. But I'm not sure a "closing over" or reducing towards core CS mathematics helps us understand the ontological status of code, any more than Wittgenstein or the Vienna School has given us a salutary reform of philosophical discourse with pure analytical techniques in search of a perfect, ambiguity-free symbolic language.
Language of any kind acquires a surplus of meaning as human beings interact with it and bring their own analogies to the experience, and I think this applies to code as well. So it may be that it's OK to move towards a philosophy of code that takes a phenomenological approach to the final product -- the code itself -- rather than (or probably in addition to) looking for meaning in the binary rules that compose machine instructions.
OP writes:
>> With this in place we can make certain classifications (in a quais-aristotelian manner): functional languages, object-oriented languages, etc. And perhaps be radically more precise and classificatory than this with key properties serving to increase resolution (run-time-modification of objects, “RMO”: javascript, OO-RMO-HOF-…).
The problem I see with this is that most of these languages are hybrids -- I can do OOP in Clojure and functional in Ruby and prototypal-fuctional-oop in JavaScript, etc. So, to me, again, as in language itself, I prefer an ontology rooted in immediate experience of particular code. Categorization of an Aristotelian type can be very helpful, but like all reductions, it can hide as much as it reveals.
What I would advocate in a philosophy of code is multiple starting places moving towards each other: acknowledging and exploring the rigorous logic implied by the core rules of logic gates (flip-flops made of silicon and so forth), the richer semantics of language structures (the Aristotelian categories of Functional, OOP, Structured, Prototypal), and a Phenomenological approach to particular code (what does this class/method/function suggest as an analogy to the real world?).