A Philosophy of Programming Languages

http://blog.mjburgess.co.uk/2013/05/a-philosophy-of-programing-languages.html

by mjburgess • 13 years ago

29 35 13 years ago

blog.mjburgess.co.uk

mjburgess10• 13 years ago

I accidentally deleted the original submission.

brudgers3• 13 years 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.

mjburgess10• 13 years 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.

brudgers3• 13 years 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.

kruhft9• 13 years 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.

mjburgess10• 13 years 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.

kruhft9• 13 years ago

The market will never be the best judge of what the most useful language is, but it is a correct judge. 'Best', being a relative term, takes an idividual's ideals into account, 'correct' being what is actual in practice.

The Best is chosen by the market that which is used to create the most successful product. By that measure, PHP is the best because Facebook is written in it. Best to the individual is much more complicated. The two will rarely coincide due to the uniqueness of the individual and the typical rejection of authority by intelligencia.

I would never say that PHP is the 'best' language for doing high abstraction, but it can be done. I also would not use it for such things, but you said you have (if you are the author of the article).

The 'Best' language is what you do your best work in, whether paid or not. Just don't expect to use it at work, and if you could, you would think something else would is best and pine for that.

It's the job, not the tools.

davesims9• 13 years 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/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?).

mjburgess10• 13 years ago

I agree 100%. I think however that there are two projects: the "phenomenalist" and the "instrumentalist". In the former part it's a group of polygot philosopher-developers waxing philosophic about the nature of programs and in the latter it's "briefs for lead developers".

Whilst my inclination in being a Husserlian first-and-foremost is to engage in the former, I think the latter is definitely of interest.

The third choice, and this is i think what you mistake my current project to be, is this "binary reductionism" or "symbolic reductionism" where DSLs are either 0/1s or predictate-object statements. I disagree with this entirely, and i think it leads to the current "chose what you like" defeatism.

I would like to explore the middle ground for awhile, an "early heidegger" if you like. I think that's going to get a lot more traction in the implementation community. There is definitely a lot of space at this moment in time for some real substantive work in all non-reductionist areas.

NB. i think my use of "metalogic" has confused at least a couple of people into thinking im talking about something CSy. Logic in the sense a continental philosopher would use it: a mechanism of reasoning. As I say in my "notes on terminology" i mean to include things like the domain/business logic. I think that, for example, that "a car shouldnt start with no fuel" is part of the program (the metalogic of the program, not the logic itself: it is part of what we need to consider to fully understand the progran). Perhaps i shouldve used "meta-rationale" or something.

davesims9• 13 years ago

Excellent! Agreed completely. Steve mentioned state machines off-hand on the list a while back, and that stayed with me, as someone with a disposition towards Husserl and Bergson and Whitehead and a general Process approach -- that state machines, in the broadest sense, might provide a practical, code-level starting point to focus attention on the "flow" of objects, interfaces that adapt to context and communicate that context to one another. This, combined with more focus on a functional approach and reducing state to manage concurrent issues (where the most practical "ontological" concerns seem to erupt!), might move a "philosophy of code" towards something practical -- if nothing else with a deeper awareness of the general "incompleteness" of all languages and their necessary analogical nature. This at least might mitigate "language wars" and the search for the "one best way" of coding.

EDIT: A minor quibble: maybe "phenomenalist" isn't the best term to use in close proximity to Husserl. He used the idea of "phenomenalism" in contradistinction to "phenomenology" -- the former being a kind of reductionist approach to seeing essences as merely the "contents of consciousness", and the latter -- which is to say the general Husserlian approach -- sees essences, or "eidetic objects" as phenomena that intend towards the external world, at least external to subjectivity.

kruhft9• 13 years ago

> 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?

No, not if it's still executing on a physical computer.

mjburgess10• 13 years ago

The surplus he's talking about is in the structure of the program: why is it that way rather than any other? Because of some meaning attached to the program, some "metalogic" (my terminology): a logic about the program which is not formally in the program but which nevertheless has significantly affected it.

davesims9• 13 years ago

But the computer and its physical state has no meaning unless the output is perceived (paging Berkeley). That meaning to the user or coder is more than a function of the position of electrons in silicon, but also, and I would argue primarily, in the meaning conveyed to the subject/user/coder. Certainly there is no meaning without physicality, but physicality without subjectivity is literally meaningless, and that subjectivity brings with it analogies and more content than can possibly be found in a pure reduction to electrons.

I think if we look hard at the structure of CPU instruction sets, GPUs, math coprocessors and the like, we'll see even at the lowest level attempts to present analogies and manage the limits of pure logic as presented to a human consciousness. So even at the lowest level of CPUs, the language of analogy is present, and that implies that a human subject is going to supply the content "between the electrons" as it were.

michaelochurch3• 13 years 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-...

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.

davesims9• 13 years 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?

michaelochurch3• 13 years ago

Good question. I tend to think of it as a stateless (I haven't added state to the model yet, and there are myriad ways of doing it so I'm debating how to do it) object. To apply it to something (symbol or nonsymbol) is like sending a message, and the result of the apply is what it returns.

Nonsymbol is deliberately vague, meaning "we don't know what this is". We need a context to make sense of it (e.g. observe _size, then if that's a natural k, observe 0, ..., k-1; it it's not, it's not in the Vector context) and if it doesn't play by the rules of a known context, we're screwed. We continue to need context when we "array-ize" nonsymbols into natural numbers.

Nonsymbols are like functions; however, a function has a well-defined domain and non-symbols don't. However, the only useful nonsymbols are "function-like" in that some sequence of symbols and known nonsymbols will produce an observable (symbol).

zohebv• 13 years ago

Interesting, this seems very similar to Haskell at a very basic level.

A Haskell program consists of declarations of functions and constants. Constants belong to the class Eq

http://www.haskell.org/ghc/docs/latest/html/libraries/base/D...

Functions do not.

How is your notion of nonsymbol/symbol different from function/constant?

michaelochurch3• 13 years ago

They're very similar. I would say the only difference is that I intend on using function for a specific subset of nonsymbols, and also that I intend for it to be a code construct (nonsymbols are not code; in fact, it's impossible to capture most nonsymbols in code). Pathological nonsymbols do not really feel like functions. However, one could construe nonsymbols as being HOFs (the worst of which would be ill-typed in any sane type system, such as Haskell's).

mjburgess10• 13 years ago

A Follow Up:

http://blog.mjburgess.co.uk/2013/05/notes-on-systematic-argu...

A Philosophy of Programming Languages

Related Stories