11 ms·

A Philosophy of Programming Languages

29 points by mjburgess 14y ago

mjburgess 14y ago
I accidentally deleted the original submission.
brudgers 14y ago
If one wished to pursue this project with systematic diligence, the ontological questions would necessarily begin with, "What is a programming language?" and "How do we distinguish programming languages from natural languages?" -- particularly natural languages such as Wittgenstein describes as consisting only of "slab" and similar terms. I fear that such an investigation would not get around to closures for a really long time if at all, and that OOP and PHP as objects of study would be so far in the future as to be archaic. The ontological (and taxonomic) problem can be illustrated with a simple hello world written in Java running in the JVM running on a 2011 Macbook Air under OSX. What language is used to write the characters to the screen? A case can be made for JVM bytecode. A case can be made for C used to write the hardware's microcode. There's only a better case for one rather than the other when we have closed over a lot of assumed values. The general problem of programming language is semiotic, not epistemic. They consist of symbols and meanings, and while these my glob together here and there - FORTRAN in any language is still possible.
- mjburgess 14y ago
  Yes, that's the standard compusci response, and that's why debates in this area are presently fruitless. I dont really care to know to what extent PHP can be written in first order logic, nor does that help anyone decide between PHP and Javascript (via Node), for example. With any philosophical project there are assumptions that you hold fixed and work that you assume "has been done" (or could be). Either way, I think there is substantive and helpful contributions to be made by forgetting where programming languges come from, by ignoring their syntax and by treating their standard implementations as worlds-to-be-explored. And if you like, the above statement is my starting point, and implicit rejection of the compusci approach which is to ask all the questions im ignoring.
  - brudgers 14y ago
    That's a philosophical response, for that is my background. On the other hand, my general reaction is that the essay lacks rigor. Kant's Prolegama to Any Future Metaphysics may not set an obtainable standard for this sort of thing, but it may prove to be a useful guide. Perhaps we are always required to make assumptions in order to act philosophically - even if I am inclined toward the belief that though we start somewhere, starting to do philosophy comes earlier in the day than any decision to assume. In other words, we don't assume our starting point or arrive at it after packing our bag - once we start packing our bag, we are well into the act. I think the study of computer languages can tell us interesting things of the sort which philosophers - and particularly natural language philosophers - have found interesting over the more recent past. But I find a great-chain-of-being approach dubious in regard to generating epistemic epiphany.
    - mjburgess 14y ago
      Oh it certainly lacks rigour. I was just outlining "an intention to be rigorous" to see what the response would be. There seems to be, so far, quite a lot of interest in this kind of project.
      - brudgers 14y ago
        But alas the taxonomy of programming languages is a solved problem. There is Lisp. And there is Blub. Or less t-rolled: McCarthy and Von Neuman. Or more poetic: Dionysian and Saturnial. Rigor comes in many flavors. The starting point for all of them is rigorous thinking. One of the signs that my thinking is not rigorous is that I wind up proving the point I set out to prove. Then again, setting out to prove a point ought to be a warning flag. Even if it is inevitable that I do so. The key to rigor is recognizing that I am doing it. Lisp and Blub was where I wanted to go. My dissatisfaction led me to McCarthy and Von Neuman and that to another metaphorical connection between programming languages and literary criticism. And that fits with my larger interests; those being the ones which dispose me toward writing about software.
        14y ago
kruhft 14y ago
> We are currently in a state of paralysis with respect to educating decision-makers within applied software development because the arguments made for one language or another are small incomparable islands that admit only buzzwords. In my experience, decision makers don't want to be educated about the benfits of your favorite language. They want to use a 'full stack' supported solution that has corporate backup and industry acceptance. They want to be able to hire someone to take over your code when you leave. In the end, you can compute anything compuatble with any Turning complete programming language, although some are more elegant than others at certain problems. Human psychology will lead you to desire what you don't have, which in this case is your ideal niche language for solving your current problem at your shitty job. In the end languages are just tools and decision makers are providing you with the tools you are to use to do the job which minimizes their risk and maximizes their return. And if your language is so great and will solve all your problems in an elegant and productive way, then make something with it and start a successful company. Then, if you make it for 20 years, wait for the articles saying how 'uneducated' you are having used it and you should be using some university ressearch language based on n-th level hyper-metalogics because you can write fib in 21 symbols.
- mjburgess 14y ago
  >In the end, you can compute anything compuatble with any Turning complete programming language Well it's this defeatist position i'm arguing against. > you should be using some university ressearch language I'm largely a PHP developer / "architect" by trade; I'm not in the business of pushing Haskell onto CMS developers. I am interested in the programming language debate, and I'm not convinced "the market" is the best judge of what the most useful language is. That it happened to be, for example, the internet was coming of age during PHP's invention which gave us a generation of script-kiddes (98 - 06) seems to me an accident of history. This accident is being corrected by Zend Framework and corresponding language changes (06 - 13), so by today PHP is a language which resembles a pythonized java, rather than a javascripty perl. The market in this instance is doing precisely what has been recomended by the leading theoretical voices in this area: coming from Zend, Sympfony, etc. My intended contribution is to provide a conceptual framework in which to make sense of these changes, to advocate for these changes, and to compare potential changes. Mailing lists are abound with favorite features, I've yet to see a feature suggestion with a complete argument of the kind I would advocate. Though some of the very best do actually get 95% of the way there (ontology: showing the new feature in other languages to "get a sense of what it is"; epistemology: showing how to reason about it in different areas; abduction: showing how it represents problems better than current technologies): if you look at a modern high quality PHP-RFC today you're getting very close to what i'm proposing. The open source market of merit is putting these individuals in positions of power over the evolution of languages, it would be useful - i suggest - if we could have a standard which provides the means for establishing good arguments from bad arguments in this area.
davesims 14y ago
I've been thinking about this quite a bit myself lately (mostly due to the excellent ongoing discussion Steve Klabnik started here https://groups.google.com/forum/?fromgroups#!forum/philosophy-in-a-time-of-software https://groups.google.com/forum/?fromgroups#!forum/philosoph...). 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?).
michaelochurch 14y ago
This is something I'm attacking right now. I'm undecided how far I want to take the series, but this is Post #1: http://michaelochurch.wordpress.com/2013/05/06/constructing-computation-1-symbols-nonsymbols-and-equality/ http://michaelochurch.wordpress.com/2013/05/06/constructing-... The starting point of this computation model is: 1. There are symbols and nonsymbols. 2. Symbols can be equality-compared (eq'd). 3. Nonsymbols can be observed for behavior (in symbols returned) but not eq'd. The set of symbols is countable and includes: 1. Natural numbers. 2. Unique symbols for arbitrary "dictionary words", e.g. _error. Nonsymbols represent mappings that take nonsymbols or symbols and input and return nonsymbols or symbols. That's not well-defined (and it's not even a set) but we are only concerned with those that return symbols (i.e. can be observed) after certain input patterns. For example, A : {_ => A} and B : {_ => B} are both nonterminating but behave identically based on what we can actually observe; it's meaningless to argue about whether they are "the same" and since nonsymbols can't be eq'd, also unanswerable. Code (as in source) is essentially a process that takes a natural number (viewed as an array of bounded natural numbers) and converts it into something that behaves as a nonsymbol, at least over inputs we care about. Of course, there are many nonsymbols that we can't represent in code, such as one corresponding to the Halting Problem, {$sym => 0, $nsym => 0 if exists k s.t. apply^k($nsym, 0) is a symbol, 1 otherwise.} Maps, vectors, and sets give us tools for describing extremely well-behaved (finite support; returning _error on the not-found case) nonsymbols in code; functions give us a language to describe well-behaved infinite-support nonsymbols. The neat thing about traditional functional programming is that it carries an implicit will to focus on well-behaved nonsymbols. Object-oriented programming hasn't stepped away from the full space of nonsymbolness-- and that's a big part of why it's so damn hard to reason about it.
- davesims 14y ago
  I like this as a more systematic starting point, with more direct application than the high-level conceptual approach I gravitate towards. One quibble -- I would prefer non-negative(!) terminology, i.e., what is a "nonsymbol"? A collection? A monad? A duration? An event? A process? A closure? Some category that encompasses all of these? If so, can we find a positive semantic rather than negative? >> Object-oriented programming hasn't stepped away from the full space of nonsymbolness-- and that's a big part of why it's so damn hard to reason about it. Well, this gets back to the ancient problem of "The Third Man" and categories in general, right? One must categorize and "contain" meaning, trap it in language a moment in order for it to remain meaningful, but paradoxically the external thing that it symbolizes is always changing, so it's always escaping any semantic trap we set for it. This of course has practical (concurrent) implications in software as well as the high-falutin metaphysical stuff Plato was talking about. These days I'm starting to wonder more about how we may not be using state-machines quite as effectively, or as often, as we might -- changing functionality more aggressively as the data changes, in order to move towards a better analogy with the ever-changing "real world" that software is trying to model. Might this be more self-aware starting place to integrate functional and object concerns -- both of which are necessary?
mjburgess 14y ago
A Follow Up: http://blog.mjburgess.co.uk/2013/05/notes-on-systematic-argument-for.html http://blog.mjburgess.co.uk/2013/05/notes-on-systematic-argu...

29 points by mjburgess 14y ago

I accidentally deleted the original submission.

If one wished to pursue this project with systematic diligence, the ontological questions would necessarily begin with, "What is a programming language?" and "How do we distinguish programming languages from natural languages?" -- particularly natural languages such as Wittgenstein describes as consisting only of "slab" and similar terms. I fear that such an investigation would not get around to closures for a really long time if at all, and that OOP and PHP as objects of study would be so far in the future as to be archaic. The ontological (and taxonomic) problem can be illustrated with a simple hello world written in Java running in the JVM running on a 2011 Macbook Air under OSX. What language is used to write the characters to the screen? A case can be made for JVM bytecode. A case can be made for C used to write the hardware's microcode. There's only a better case for one rather than the other when we have closed over a lot of assumed values. The general problem of programming language is semiotic, not epistemic. They consist of symbols and meanings, and while these my glob together here and there - FORTRAN in any language is still possible.

mjburgess 14y ago
Yes, that's the standard compusci response, and that's why debates in this area are presently fruitless. I dont really care to know to what extent PHP can be written in first order logic, nor does that help anyone decide between PHP and Javascript (via Node), for example. With any philosophical project there are assumptions that you hold fixed and work that you assume "has been done" (or could be). Either way, I think there is substantive and helpful contributions to be made by forgetting where programming languges come from, by ignoring their syntax and by treating their standard implementations as worlds-to-be-explored. And if you like, the above statement is my starting point, and implicit rejection of the compusci approach which is to ask all the questions im ignoring.
- brudgers 14y ago
  That's a philosophical response, for that is my background. On the other hand, my general reaction is that the essay lacks rigor. Kant's Prolegama to Any Future Metaphysics may not set an obtainable standard for this sort of thing, but it may prove to be a useful guide. Perhaps we are always required to make assumptions in order to act philosophically - even if I am inclined toward the belief that though we start somewhere, starting to do philosophy comes earlier in the day than any decision to assume. In other words, we don't assume our starting point or arrive at it after packing our bag - once we start packing our bag, we are well into the act. I think the study of computer languages can tell us interesting things of the sort which philosophers - and particularly natural language philosophers - have found interesting over the more recent past. But I find a great-chain-of-being approach dubious in regard to generating epistemic epiphany.
  - mjburgess 14y ago
    Oh it certainly lacks rigour. I was just outlining "an intention to be rigorous" to see what the response would be. There seems to be, so far, quite a lot of interest in this kind of project.
    - brudgers 14y ago
      But alas the taxonomy of programming languages is a solved problem. There is Lisp. And there is Blub. Or less t-rolled: McCarthy and Von Neuman. Or more poetic: Dionysian and Saturnial. Rigor comes in many flavors. The starting point for all of them is rigorous thinking. One of the signs that my thinking is not rigorous is that I wind up proving the point I set out to prove. Then again, setting out to prove a point ought to be a warning flag. Even if it is inevitable that I do so. The key to rigor is recognizing that I am doing it. Lisp and Blub was where I wanted to go. My dissatisfaction led me to McCarthy and Von Neuman and that to another metaphorical connection between programming languages and literary criticism. And that fits with my larger interests; those being the ones which dispose me toward writing about software.
      - 14y ago

kruhft 14y ago

> We are currently in a state of paralysis with respect to educating decision-makers within applied software development because the arguments made for one language or another are small incomparable islands that admit only buzzwords. In my experience, decision makers don't want to be educated about the benfits of your favorite language. They want to use a 'full stack' supported solution that has corporate backup and industry acceptance. They want to be able to hire someone to take over your code when you leave. In the end, you can compute anything compuatble with any Turning complete programming language, although some are more elegant than others at certain problems. Human psychology will lead you to desire what you don't have, which in this case is your ideal niche language for solving your current problem at your shitty job. In the end languages are just tools and decision makers are providing you with the tools you are to use to do the job which minimizes their risk and maximizes their return. And if your language is so great and will solve all your problems in an elegant and productive way, then make something with it and start a successful company. Then, if you make it for 20 years, wait for the articles saying how 'uneducated' you are having used it and you should be using some university ressearch language based on n-th level hyper-metalogics because you can write fib in 21 symbols.

mjburgess 14y ago
>In the end, you can compute anything compuatble with any Turning complete programming language Well it's this defeatist position i'm arguing against. > you should be using some university ressearch language I'm largely a PHP developer / "architect" by trade; I'm not in the business of pushing Haskell onto CMS developers. I am interested in the programming language debate, and I'm not convinced "the market" is the best judge of what the most useful language is. That it happened to be, for example, the internet was coming of age during PHP's invention which gave us a generation of script-kiddes (98 - 06) seems to me an accident of history. This accident is being corrected by Zend Framework and corresponding language changes (06 - 13), so by today PHP is a language which resembles a pythonized java, rather than a javascripty perl. The market in this instance is doing precisely what has been recomended by the leading theoretical voices in this area: coming from Zend, Sympfony, etc. My intended contribution is to provide a conceptual framework in which to make sense of these changes, to advocate for these changes, and to compare potential changes. Mailing lists are abound with favorite features, I've yet to see a feature suggestion with a complete argument of the kind I would advocate. Though some of the very best do actually get 95% of the way there (ontology: showing the new feature in other languages to "get a sense of what it is"; epistemology: showing how to reason about it in different areas; abduction: showing how it represents problems better than current technologies): if you look at a modern high quality PHP-RFC today you're getting very close to what i'm proposing. The open source market of merit is putting these individuals in positions of power over the evolution of languages, it would be useful - i suggest - if we could have a standard which provides the means for establishing good arguments from bad arguments in this area.

davesims 14y ago

I've been thinking about this quite a bit myself lately (mostly due to the excellent ongoing discussion Steve Klabnik started here https://groups.google.com/forum/?fromgroups#!forum/philosophy-in-a-time-of-software https://groups.google.com/forum/?fromgroups#!forum/philosoph...). 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?).

michaelochurch 14y ago

This is something I'm attacking right now. I'm undecided how far I want to take the series, but this is Post #1: http://michaelochurch.wordpress.com/2013/05/06/constructing-computation-1-symbols-nonsymbols-and-equality/ http://michaelochurch.wordpress.com/2013/05/06/constructing-... The starting point of this computation model is: 1. There are symbols and nonsymbols. 2. Symbols can be equality-compared (eq'd). 3. Nonsymbols can be observed for behavior (in symbols returned) but not eq'd. The set of symbols is countable and includes: 1. Natural numbers. 2. Unique symbols for arbitrary "dictionary words", e.g. _error. Nonsymbols represent mappings that take nonsymbols or symbols and input and return nonsymbols or symbols. That's not well-defined (and it's not even a set) but we are only concerned with those that return symbols (i.e. can be observed) after certain input patterns. For example, A : {_ => A} and B : {_ => B} are both nonterminating but behave identically based on what we can actually observe; it's meaningless to argue about whether they are "the same" and since nonsymbols can't be eq'd, also unanswerable. Code (as in source) is essentially a process that takes a natural number (viewed as an array of bounded natural numbers) and converts it into something that behaves as a nonsymbol, at least over inputs we care about. Of course, there are many nonsymbols that we can't represent in code, such as one corresponding to the Halting Problem, {$sym => 0, $nsym => 0 if exists k s.t. apply^k($nsym, 0) is a symbol, 1 otherwise.} Maps, vectors, and sets give us tools for describing extremely well-behaved (finite support; returning _error on the not-found case) nonsymbols in code; functions give us a language to describe well-behaved infinite-support nonsymbols. The neat thing about traditional functional programming is that it carries an implicit will to focus on well-behaved nonsymbols. Object-oriented programming hasn't stepped away from the full space of nonsymbolness-- and that's a big part of why it's so damn hard to reason about it.

davesims 14y ago
I like this as a more systematic starting point, with more direct application than the high-level conceptual approach I gravitate towards. One quibble -- I would prefer non-negative(!) terminology, i.e., what is a "nonsymbol"? A collection? A monad? A duration? An event? A process? A closure? Some category that encompasses all of these? If so, can we find a positive semantic rather than negative? >> Object-oriented programming hasn't stepped away from the full space of nonsymbolness-- and that's a big part of why it's so damn hard to reason about it. Well, this gets back to the ancient problem of "The Third Man" and categories in general, right? One must categorize and "contain" meaning, trap it in language a moment in order for it to remain meaningful, but paradoxically the external thing that it symbolizes is always changing, so it's always escaping any semantic trap we set for it. This of course has practical (concurrent) implications in software as well as the high-falutin metaphysical stuff Plato was talking about. These days I'm starting to wonder more about how we may not be using state-machines quite as effectively, or as often, as we might -- changing functionality more aggressively as the data changes, in order to move towards a better analogy with the ever-changing "real world" that software is trying to model. Might this be more self-aware starting place to integrate functional and object concerns -- both of which are necessary?

mjburgess 14y ago

A Follow Up: http://blog.mjburgess.co.uk/2013/05/notes-on-systematic-argument-for.html http://blog.mjburgess.co.uk/2013/05/notes-on-systematic-argu...