Lambda the Ultimate

When Hayles writes that "code is the unconscious of language" or even that

Code in this view acts as the conduit through which traumatic experience can pass from its repressed position in the traumatic aconscious to conscious expression.

she thinks, at least, that she's helping people who work with code to understand it more deeply. I doubt, however, that she'd claim that this sentence could help engineers "improve the analysis of computer software" in any literal sense.

Marino offers a "note of caution" to "computer scientists who discover this project and view it with skepticism and bemusement": he says they should be careful

not to regard the humanists and posthumanists as either infadels or kooks — but rather collaborators whose articulations enrich the discussions of code.

So yes, I think the CCS folks do see their work as having relevance outside of the humanities, for people who write code or think about programming languages. The implicit model is probably something like film theory, which has had an influence on the way films are made.

Bad analogy.

Film is an art, film theory attempts to deconstruct this art in order to understand films' relationship with reality.

Programming is not an art. Programming theory does not attempt to deconstruct programs to understand their relationship with reality.

While I tend to agree with you, the assertion that "programming is not an art" seems at odds with all of the people that claim that "programming is more like writing an essay than engineering a bridge", that hackers and painters have much in common, or that programming is not a science but a liberal art.

I agree that CCS and film theory aren't really analogous—I was just speculating about how CCS practitioners imagine the relationship between their work and the stuff they're theorizing about.

Programming theory does not attempt to deconstruct programs to understand their relationship with reality.

I actually think this is exactly what they claim to be doing, except that they've replaced the rusty deconstruct with the much shinier unpack.

The thread on "On the (Alleged) Value of Proof for Assurance", in regards to the usability of Z (~mathematical notation) seems to support the investigation of semiotics.

I second this assessment. There is a fairly active cottage industry in the semiotics and cognitive science of mathematics, particularly as it relates to math. education, so an investigation of PL pragmatics and the psychology and semiotics of programming should provide a much needed contrast. In addition, a number of philosophical issues have been raised about computer science (see this review article in the Stanford Encyclopedia of Philosophy), some of which could well be of interest to scholars in the humanities.

Lastly, there are some niches where code is considered an art form--such as the demoscene and the "hacker" cultures which arose in academia during the 1960s and 1970s. There are even uncanny resemblances between the style of demoscene animations and the most experimental kind of video art.

Given the context, I think this is probably an unreasonably charitable reading of Marino's argument.

Marino characterizes computer science as having efficiency in terms of "processing cycles" as its "fetish" or "ultimate standard". Your examples highlight the fact that this characterization isn't entirely accurate in the first place. Marino also doesn't define "do a better job" to mean anything so specific as "be more legible" or "have fewer bugs".

More broadly I think the kind of enterprise you're describing presupposes a level of training in CS/formal logic that the current crop of CCS folks don't seem very keen on acquiring.

After all, why bother with maths when you can just riff on the "heteronormative superstructure" implicit in the code of the AnnaKournikova worm?

I found the presentation style unsuitable for consumption by scientists and engineers and agree that domain knowledge helps when examining a domain. However, that does not mean CCS has nothing to offer and optimization as a fetish does sound somewhat right. I think most here agree that the current approach -- both for confirming their theories (e.g., not doing so) and the presentation style -- limits their impact. My assessment can be way off base as I couldn't really motivate myself to get through the writing and the intros didn't do anything to help.

Well, I don't know the context either, but the first time I read it I interpreted it as "sometimes an algorithm is better because it uses more CPU cycles", which of course is nonsense.

Even in cryptography, where people attempt to devise algorithms that must use a certain amount of CPU time, an implementation that can perform the same computation using less resources is still better. (and more to the point, you generally want to assume your adversary has access to that better, faster implementation anyway.)

Of course, an implementation that uses more resources can still be better, if it's more reliable, more maintainable, simpler code, etc.

If "sometimes an an algorithm is better because it uses more CPU cycles" is nonsense....

then why is there a saying, among computing professionals, that "premature optimization is the root of all evil"?

Sometimes an algorithm is better despite using more CPU cycles. The general reason is not that the algorithm is better suited to the problem, or a more elegant expression of it, but rather the programmer's time was better used in finding a worse approximation that is good enough.

Well put, although even if you spend time and effort finding a better approximation that's a bit faster, you might do well to stick with what you had before.

Sometimes an algorithm is better despite using more CPU cycles.

What this comes down to is contention about the definition of "better" as it pertains to an algorithm.

Leaving aside "the programmer's time", for many problems there are a variety of algorithms available which make different trade-offs of space vs. time.

For example, consider regular expression pattern matching for a pre-specified regular expression. That is, a hard-coded matcher for that one pattern. If the pattern is length N and the string we are to match is length X then we have a choice that includes an O(N*X) solution and an O(X) solution.

Which is the "better" algorithm?

In some cases the O(N*X) solution is certainly the better choice "because" it uses less memory. Only, it is the essential nature of regular expression pattern matching that it can not use less memory unless it also uses more cycles. So, we might not say "O(N*X) is the better choice *only* because it uses more CPU cycles" but we could say "because it chooses to trade time for space". Using more CPU cycles is a virtue of the algorithm that makes it a better choice in this territory.

Is either the O(N*X) or O(X) algorithm "better" in any absolute sense?

Space and time are not even the only considerations. Nor are space, time, and programmer time.

The linguistic subtlety of when to and when not to use the term "better" is arguably important depending on how, in fact, it fits into the surrounding discourse. When the algorithmic complexity expert says that "The O(X) algorithm is better," other experts might have the presence of mind to read that strictly as "... is faster" but the discourse of practicing programmers, their bosses, their customers, and so forth is not always so careful and not always so easy to correct.

Even when everyone involved is speaking carefully, the decision making process about which is the better choice of algorithm in a given circumstance often depends on a number of factors which are not objectively in sight, but which are governed by the discourse surrounding the question.

In a post-mortem we might say "They chose a bad algorithm by spending too much trying to minimize CPU cycles. They would have chosen better by picking an algorithm that used more CPU cycles." In cases like regular expressions, choosing the less speedy algorithm would then not be choosing the "better" algorithm in spite of its using more CPU cycles, but because that is what the nature of the problem required of a good choice.

The word "better" does have many subtleties associated with it. Perhaps this is because in common (non-technical) usage it is usually making a comparison between two things in a total order. As you point out there are several possible axes on which we can compare algorithms; one reason to avoid "better" as a comparison is that each context will imply a different importance of the various axes and so in many cases the comparison is over a partial ordering.

Nice choice of example, it certainly didn't spring to (my) mind as a domain where using more cycles is an improvement. In a general setting it seems that you would need to know more than one algorithm is O(N*X) and the other is O(X). In particular lower-bounds would be useful to ensure that you are not trading too much time in exchange for the space. In general if there are external constraints on the axes being measured then it would be nice to know if there is a Pareto Front and where the algorithms lie relative to it - but that suggests an entirely different usage of "better" that is getting further from its common meaning.

Same impression here. When Sokal wrote his hoax for "Social Text" poststructuralism ( and Derrida ) was still alive. Don't see the point of this one.

I'd rather like to read why Curry-Howard prevents Armageddon or how capabilities are the new utopia and will form the next society. Return of the great tales, religions, ideologies. Maybe I have to write it myself.

BTW I've seen some philosophers recently jumping on the term "object oriented" for a set of realist ontologies. Not sure this will be a fad that infects academia or even the feuilleton but lots of popular science is to be expected and people shall not say they were not warned.

Indeed.

Though, it would be fun to read about how waterfall design is really a patriarchal response to chaos, or of the mercantile colonialism imposed by industrial Java's ManagerFactoryFactories.

It would only be too easy for a newcomer to take on the trappings of some programming noun kingdoms (there: hierarchy, domination), and pronounce with all the meaninglessness of some current practitioners...

it would be fun to read about how waterfall design is really a patriarchal response to chaos

Then you need to watch this YouTube: The Rise and Fall of Waterfall

This gives me an idea: I'll invent a new field called Critical Critical Code Studies Studies that will be devoted to constructing interpretations that make cryptic CCS pronouncements make sense. Now I just need to decide whether the acronym should be "CCCSS" or "C3S2".

Thank you for this response, Mark.

My training has also been in the humanities, and I'm only at the beginning of my studies in PLT and functional programming, but I'm interested in both disciplines, and want to see bridges being built between them.

There's a long tradition in the humanities of "cross-disciplinary" projects that aren't much more than academic land grabs, by scholars who aren't particularly interested in dialog with or feedback from the sciences whose terminology / etc. they're appropriating. I think there are signs of this tendency in some of the materials I linked. I posted the links because I thought there might be interest here in this new body of work, but I wanted to make my reservations clear up front.

I'd love to see a CCS that doesn't make these mistakes, and my apologies if I've been too hasty in my criticism. I'll contact you personally off-forum to follow up.

When theorists describe a new abstract approach to a given problem domain, they usually provide...or otherwise are asked to provide...an example where their new approach can be seen to work well and deliver new insights for that problem domain.

What concrete examples of problem domain and interpretation would you like to hold out as successful applications of CSS that have yielded new insights?

[...] Believe me, I know works of critical theory can be hard to read and hard
to grasp. Stuart Hall who founded Cultural Studies was himself [...]

Believe me, I know LtU readers are used to grasp difficult to read theories. I wouldn't
blame LtU readers for not being able to "grasp" whatever those works have to say.

[...] apparently suspicious of convoluted theoretical language. But if your
critique of my work is that it is insufficiently informed in the domain of
computer science, I would hope that you would respect the theoretical concepts and
constructs of my area, or rather in our area. Respect is certainly missing from
[...]

With all respect to the theoretical concepts and constructs of your area: yes,
you are insufficiently informed in the domain of Computer Science, as some other
readers have already pointed out.

To begin with: "code" can be a byproduct of a software design. "Code" can be
automagically generated from a formal model, for instance, so there're no
"socio-historical context" to study there.

"Code" can also be created by hundredths of different people, from all around
the world, from tenths of different cultures, during a very long period of
time.

And can then be maintained (manipulated, changed, rewritten) by hundredths of
different people, from all around the world, from tenths of different cultures,
during an even longer period of time.

You may or may not be able to track the people, their culture, their location
or their "socio-historical" context when looking at a single piece of code.
That single piece of code may have been written by tenths of people, during
tenths of years.

So I'd say that yes, whatever theory that is to "study code" and derive any
result from those studies (wheter "socio-historical" or whatever) is plain
wrong. Simply because you won't have all variables and boundary conditions
needed to study the problem.

[...] perhaps all sides of this conversation. (And I will try to write more clearly
and in more conversational diction now that I see my audience is much broader
than I anticipated.)[...]

Clarity would indeed help those of us in "the broader audience". After all, and
as you may know, clarity is one of the ways to measure the quality of code.

Clarity is also one of the the qualities of good english writing, as avoiding fancy words and being clear are two of the rules in "The Elements of Style".

[...] Lately, I have been thinking that the larger field of studies is perhaps
"code studies," one that can more easily bridge or too disciplines. The work
that involves critical theory (of the literary and cultural tradition) could be
called critical code studies. [...]

Instead of changing the name I'd suggest you changing the target: Maybe you
want to study the content of the mailing lists (and other communication
channels) people use to build software.

The way people organize to build software (both inside companies and in open
source projects) is probably a great area of interest. Success of software
projects is usually due to its internal human organization, the way they
communicate and the way the project community is governed. And that's an area
that has not been studied in depth, as far as I know. All I can remember now
is this this article by Eric S. Raymond.

For an interesting working case you may consider studying the ongoing process of
standardization of the Scheme programming language, where political and organizational issues seem to have entered the game.

So I'd say that yes, whatever theory that is to "study code" and derive any
result from those studies (wheter "socio-historical" or whatever) is plain
wrong. Simply because you won't have all variables and boundary conditions
needed to study the problem.

Historical linguistics has a rich understanding of how natural languages change based on analyzing usage. I would assume similar (but obviously different) technique are applicable to PLs, though I'm still thinking about what the benefits would be of that particular angle.

I would caution those remarking on this thread to reread their messages in regards to civility -- a lot can be unintentionally misinterpreted. This is an interesting discussion, and, while out of the mainstream, I think data driven / HCI (psychology) / sociological approaches to looking at end-to-end systems will only become more important. When analyzing adoption barriers of many PL domains like FP, type theory, logic, or verification, and designing GPLs, hopefully it's apparent that there's something missing. I don't see how alienating someone interested in helping is a net win. So, for an example of dealing with the community gap, constructive criticism helps (as in the above post, though I suspect Elements of Style is well-known to the literary community).

I would caution those remarking on this thread to reread their messages in regards to civility -- a lot can be unintentionally misinterpreted. This is an interesting discussion [...]

Agreed, and agreed, though it is very possible to err on the side of excess seriousness: a code reading could hardly be complete without an appreciation of the mischief with which many hackers hack. If code is play, then commentary too.

Historical linguistics has a rich understanding of how natural languages change based on analyzing usage. I would assume similar (but obviously different) technique are applicable to PLs, though I'm still thinking about what the benefits would be of that particular angle.

The forces under PL evolution are possibly completely different from those causing natural language evolution. Programming languages usually evolve to improve on clarity, conciseness, brevity, accuracy or to improve other qualities of service (such as security, portability or backwards compatibility). I don't think historical linguistics has nothing to say about security or backwards compatibility, for instance, so I'm not sure if the techniques in historical linguistics are of any use here.

[...]So, for an example of dealing with the community gap, constructive criticism helps (as in the above post, though I suspect Elements of Style is well-known to the literary community).

I mentioned Elements of Style because those of us in the scientific community appreciate clarity and accuracy in the language. In whatever language we use (programming, mathematical or natural language). The shorter and the more accurate the better.

So, for a start, I think we'd appreciate a short and concise definition of "critical code studies". Why "critical"? What is to be understood by "code"? What aspects of "code" are to be "studied" and how?

Those are questions whose (short and concise) answers would dramatically reduce the community gap. I haven't found the answers in the pointers above, though.

Here's my take:

"Critical" here just means "coming out of the tradition of critical theory": i.e., based on some idea of dialectical critique.

For "code", the OED definition seems as good as any:

Any system of symbols and rules for expressing information or instructions in a form usable by a computer or other machine for processing or transmitting information.

Mark goes into more detail about what kinds of "code" are meant in this essay linked in the original post.

"What aspects" and "how" are obviously more complicated, in part because the field is so young. I tried to select links that give some indication of possible directions. I'd recommend in particular looking at Mark's "codology" essay—I probably should have highlighted it more explicitly in my original post.

But those definitions are too vague for me to understand. The definition of code you suggest fits both the UTF-8 specification, the firmware of a washing machine and the bits of the AVI Video format, for instance.

You can study the internals of the AVI Video format in full detail, understand its source code representation in Haskell (or Scheme, or C, understanding why "Hello world" is in there), and learn about the benefits of portability and bandwidth consumption, if any. All that study won't give you a single clue on why this video format is not under consideration for HTML 5.

What I mean is that the "sociological" aspects of "code" are not in the code itself, they're elsewhere. Studying them is not different of studying the sociological aspects of any other field.

I understand that "what aspects" and "how" are more complex to define. What about defining "what objectives" CCS is trying to achieve? Is that easier?

What I mean is that the "sociological" aspects of "code" are not in the code itself, they're elsewhere.

Are you sure about this? In every case? I'm not sure at all.

are something of a social construct, not a completely infallible and solely logical thing.

Yes, and the reasons why spacecraft crash are also mostly social. I'm not saying that studying this is worthless. On the contrary, programming languages should be designed from the start from the human point of view instead of as often happens now from the theoretical point of view.

BUT I don't think that taking your existing lit-crit skills and applying them to code results in anything. For example take this on quicksort:

One of my early experiences with CCS may serve as a cautionary tale. When I proposed an earlier version of CCS to a group of programmers, one of them asked if I could prove CCS by applying these methodologies to a program with low natural language content, even in terms of input and output. The reviewer suggested Quicksort, an algorithm used for quickly ordering groups of numbers through a "divide and conquer" approach. In my early attempts at what Wardrip-Fruin would equate to interpreting a stop sign, I suggested Quicksort as a metaphor for social organization in communities, drawing out an analogy for the way a neighborhood street or even highway may serve to divide and conquer a demographic. However, though my analysis said something about neighborhood hierarchies, it offered little insight on Quicksort itself, nor did it draw from Quicksort a lesson about the society from which it came. My main error was analyzing Quicksort aside from its historical, material, social context. For an algorithm such as Quicksort, the code meets the social realm at the site of its implementation and in the context of the application in which it is used. I was not engaging the cultural origins of Quicksort within the history of computation or even a particular incarnation of Quicksort in a language (I was using pseudocode). Without discussing the human context of the Quicksort code in terms of authorship, use, development, circulation, or operations, I was left with little more than a process

I doubt that you'd be able to learn anything interesting about quicksort by approaching it this way. Sure, the history of quicksort is interesting. But trying to understand an implementation of quicksort by exploring its historical context like you would do with a piece of natural language is not useful. You have the code and the math and the reasoning behind the code, and you have the history. Both are interesting but should be treated separately.

Actually I would be surprised if you could find a programmer who wouldn't find that paragraph ridiculous, in a similar way that humanities people would probably find it ridiculous to apply methods to analyze algorithms to natural language (like applying Hoare logic to a poem, or asymptotic complexity analysis to a book).

i'm overall not sure what you are saying since you say the study is not worthless but then you seem to say it is.

presumably it depends on what is defined as the point of it all. you say applying lit-crit can't result in anything. yet it apparently doesn't result in nothing, since somebody wrote that, and other people read it, and now some people are even discussing it right here. what it results in is something. then each individual will have a response as to how valuable that result is. and even /what/ the result "is".

some folks have applied algorithmic type study to lit; the various codified meters used in poetry are an old, small, but real example of that. (i'll ignore e.g. biblical numeric study as silly.)

some folks have applied algorithmic type study to lit; the various codified meters used in poetry are an old, small, but real example of that.

Montague grammar can describe the semantics of natural language using the formalisms which are commonly used in PLT. This approach is severely limited due to the inherent "fuzziness" and context dependence of natural language, and it clearly cannot address extra-linguistic "meaning" and interpretation at all. Nonetheless, it's viable enough to make formal domains such as programming, proof and specification a primary target for natural language generation. Here is a natural language framework for formal proof and the kind of text it can generate. There is much scope for improvement, and obviously this is not suitable as the primary or exclusive representation of a program, but having a plugin which could accurately translate the semantics of complex expressions into natural language might be helpful as part of a broader structure-oriented approach.

I agree with some of this, e.g.,

For an algorithm such as Quicksort, the code meets the social realm at the site of its implementation and in the context of the application in which it is used. I was not engaging the cultural origins of Quicksort within the history of computation ... Without discussing the human context of the Quicksort code in terms of authorship, use, development, circulation... I was left with little more than a process

But other parts still make no sense to me -- lack of research or practitioner level knowledge (as opposed to artist/dabbler) throw in some red herrings:

or even a particular incarnation of Quicksort in a language (I was using pseudocode)... or operations

where the latter might only matter in a teaching context (e.g., comparing languages / programming models) and thus I doubt is what was meant.

I had an interesting discussion last night where semiotics came up with a somewhat analogous example: indentation. When reading code, badly indented code raises alarm bells. Either the programmer is not aware of coding conventions and thus is somewhat of a dangerously unpredictable party or is aware and the code is fresh and likely buggy (where the debugging process would involve cleaning up the code syntactically to ease legibility). Likewise, when writing code, I may be 'sloppy' syntactically (naming, spacing, etc.) to reflect that it is fresh and untrusted. Performing a checkin or a release entails cleanup. A technical solution is automatic formatting, but that misses the whole point.

In the case of quicksort, it is significant in 1) if a hand-written sort used and 2) is it a canonical. The analogy might be with Virginia Woolf: we expect Hemingway in his seeming simplicity, so such surprising code is either the work of an idiot or a master (e.g., tuning).

However, again, I found the cited work to be illegible and lacking of rigor (irrespective of using appropriate terminology). Ideas are easy; distilling reliable (experimentally verified) and pertinent knowledge seems like the most reasonable way to engage the science (and applied science / engineering) community. Unfortunately, it's a pain, especially when unnecessary for the goal's for your home community, but there it is.

Spaceship do in fact crash for mostly social reasons! The challenger disaster was because upper level managers did not want to hear "bad news" from the engineers. I heard some guru (don't remember his name) say that he never saw a software project fail for technical reasons. I agree with this, usually failure is social/economical. Of course, I'm not justifying CCS, but it has sparked an entertaining thread! Unfortunately Marks getting insulted kind of weakens his case. Even the most shallow cultural examination of this forum (or almost any CS forum) should have told him what kind of reaction to expect...

Actually when I wrote that first comment I really thought it was a joke. But with the sheer amount of pages dedicated to the subject it's too elaborate to be a joke.

I'm not being sarcastic. Spaceships and software projects do fail for social reasons. However, you can't fix this by studying the equations or the code as you would study literature. You have to study the people and the incentives and the processes. OR if you want to solve a specific problem then you study the code in conventional CS ways.

They do seem to think that they can help programmers. I couldn't find how they think that they can help programmers, or how they are going to evaluate its effectiveness, though. Perhaps somebody can step in and maybe even give an example of how it helped.

Just a random thought: sometimes technical advances can solve social problems. For example if you are building a product with 100 people you are going to need an elaborate management structure. If you could improve individual programmer productivity 3 times you could perhaps reduce that to 10 people, because team productivity doesn't scale linearly with the number of people. If you are building a small product for a client on your own and you could improve productivity 3 times you could perhaps sit down with a client and build a rough version live. This would reduce communication problems tremendously, because he can immediately see whether what you are building is what he had in mind. I think programming tools are getting close to good enough to be able to do this in specific areas (e.g. web programming with Hobo).

Actually when I wrote that first comment I really thought it was a joke. But with the sheer amount of pages dedicated to the subject it's too elaborate to be a joke.

I don't think "joke" is the right word here. Despite its well-appreciated attention to clarity and constructive discussion, the author's reply sounded distinctively trollish; I don't see this as a negative thing, since such rethorical devices can be useful to stimulate respectful and productive discussion, especially about hidden, non-trivial issues such as the cultural and socio-political aspects of "code" and PL's.

Moreover, critical studies seems to be focused on speculative "deconstruction" meant to expose hidden patterns of power, authority, institutions etc., so it seems that some amount of institutionalized trollishness would come with the territory. However much effort may have been placed into this subject, it's not clear that the results should be taken at face value.

It seems obvious to me that the "meaning" of the equations have no emotional aspect, because the meaning was specifically designed to exclude such content, however, the specific symbols chosen, conventionally, to represent the relationships pointed at (the meaning) may have emotional/cultural/mythic resonances that influence the direction, style and creativity of future research and discourse. There could even be cultural significance in that the symbol sets and language chosen to communicate the relationships are more accessible to people from one culture (or gender) than another. Damn, I'm starting to sound like deconstructionist! Look at programming paradigms for children, maybe there are programming/math symbol/language sets that would go over better in the Congo that others? I'm not sure Mark understands the distinction between meaning (or execution) and symbolic systems used to express that meaning, but I'm not sure he doesn't either.

I'm not sure Mark understands the distinction between meaning (or execution) and symbolic systems used to express that meaning, but I'm not sure he doesn't either.

He does. There is an essay on his website that devotes considerable space to discussing the relative merits of analyses that have something to do with the functionality of some given code and analyses that don't relate to that functionality and might apply more or less as well to stuff that only looks like working code.

Why do I have the feeling "The Emotional Aspects of Laplace Equations" will become an LtU inside joke for years to come?

Perhaps Wadler will write a paper with this as the title!

I think that your "elliptical" writing style is an obstacle. It's not my place to give you advice. But my advice is: talk normal.

I was the one what brought up Sokal, though not by name. Others caught my drift. I've long thought that the most interesting aspect of the paper is the over-reaching nasty responses and rumors it provoked. He sure as heck did expose some intellectual dishonesty there - and I don't mean anything about Social Text.

Here in programming language theory land, we often talk about the meaning of programs. Often enough, we mean "meaning" in fairly precise, technical ways. (You have an interest in Scheme. See the appendices of R5RS and R6RS for two distinct approaches to ascribing meaning to a class of programs.)

And, here in programming language theory land, we also use other ordinary language words in strange ways. We talk about correctness, expressiveness, abstraction, objects, composition, correctness, and so forth.

Now, if those are all just "terms of art" that's one thing. For example, we could take the literature, look for all occurrences of a phrase like "denotational semantics" (which pertains to meaning), replace those with the word "snickerdoodle" - and the math would still check out. Fine.

Yet, in the discourse around programs and programming languages, we manage to not confine our use of those terms to their strict technical sense. Two anecdotes to illustrate:

(1) I've fairly recently been "shouted at" (in the email sense of shouting) for proposing programming language features that would rob programs of "meaning". I was accused of suggesting a language design for "meaningless" programs. I had done no such thing, of course. Reading between the lines I figured out that I had proposed features that were not well modeled by my critic's favorite mathematical model of the meaning of programs. His theory of "meaning" of programs was incomplete and he dubbed programs unaccounted for by this theory "meaningless". Only, he did not come and say "there is no meaning assigned to such and such a program in my favorite mathematical model of meaning" -- in the rowdy debate and in the reception he got, he conflated his technical word "meaning" with the common language meaning (and got away with it).

(2) For an interesting source of "talking about programming and programs" you might want to examine the past few months of archives from the "Scheme standardization Working Group 1 (WG1)" mailing list. There is much banality, of course, but there are actually some debates there that are quite heated. The more heated debates concern concepts like modularity, safety, and barriers of protection. For example, one issue is whether or not when two programmers contribute code to a single program, one of the programmers ought to be able to prevent the other programmer from certain actions. (Technically: should a library be able to create values of novel type that code outside of the library can not dissect? Or should any part of the program be able to dissect the values it encounters, even if it didn't create them?)

What I think these kinds of debate have in common, and where I think CCS can possibly help, is in the area that joins programming language design and programming practices to human relations and power structures. Both anecdotes are examples of contention over authority. Who can and who can not write code that dissects a particular data structure in a particular program? Who is and who is not the Humpty Dumpty who gets to define "meaning"? And, though my anecdotes don't give a clear example, how do our discourses within the field relate to the significance of programs for the larger society of people who use computers?

The field is lousy with such debates and, for the most part, is unconscious to the point of zombie-hood in relating those debates to the socio-economic positioning of programmers and computer users.

Foucault, if he could be resurrected and dragged out of the library and away from his mostly historic studies - would have a field day.

My (again, presumed slightly rude, entirely inappropriate, not my place) advice: go look around over there.

And talk normal...

I suspect (but can't prove) that the discourses about "software engineering", "enterprise architectures", "programming in the large" and the like are tightly linked to unexplored and hard-to-characterize issues of power and authority. PLT researchers and the hacker community[1] seem to both be thoroughly skeptical about the merit of these technical discourses, although the stated rationales obviously differ, and both communities seem unable to describe its hidden assumptions and desiderata in any rigorous fashion. This is one area where CCS might be able to help.

[1] The hacker community adopts a distinctive approach to software development, authority in technical disputes and the authorship of source code. Eric S. Raymond's work has given a comprehensive description of their ethics and principles, and his The Art of Unix Programming surveys the 'hackish' approach to issues which might otherwise fall under "programming in the large".

Eric S. Raymond's work has given a comprehensive description of their ethics and principles

I rather strongly disagree. Too off topic to debate it here? But, I at least wanted to share that there is strong dissent on the validity of ESR's narrative.

Ignoring any controversy around your note 1, this is spot on:

I suspect (but can't prove) that the discourses about "software engineering", "enterprise architectures", "programming in the large" and the like are tightly linked to unexplored and hard-to-characterize issues of power and authority. PLT researchers and the hacker community[1] seem to both be thoroughly skeptical about the merit of these technical discourses, although the stated rationales obviously differ, and both communities seem unable to describe its hidden assumptions and desiderata in any rigorous fashion. This is one area where CCS might be able to help.

There are many strands of political, oppressive/repressive/transgressive, insider/outsider, cultural and counter-cultural conversation woven through and around source code. Of course this should come as no surprise. What is it about enterprise Java that marks it so clearly as "corporate" discourse? How do counter-cultural practitioners and self-appointed elites use markers in their code to identify and distinguish themselves, find one another in the night? Is writing shit spaghetti-code web sites in PHP a self-conscious expression of defiance rather than "mere incompetence"? (Absolutely yes, in some cases.) Is it outsider art? (Also yes, in some cases.) Is there a "high culture" and a "low culture" of programming? (Have you ever talked to a "real programmer" about the hodge-podge of perl scripts and hacked-up C programs that so many of their machine learning colleagues are so fond of?)

I'm strongly in favor of opening an area of study which attempts to address these issues and bring them into the light. We could certainly call it CCS, although this may not be what is currently meant by that term. I'm strongly in favor of this despite (or perhaps because of) the fact that so many programmers will undoubtedly have strong a strong negative reaction to any discussion of these issues, and even deny the existence of any issues to discuss.

Of course programs are both mathematical artifacts and social creations situated in a particular context. By asking about PHP, for example, I'm not arguing that it doesn't suck, perhaps even in objective, quantitative ways. Shantytowns suck, too, in a lot of very objective ways, and so do lots of romance novels, but nonetheless they are worth discussing and have much to teach us.

However, I doubt there are many people in the world able to do this work well.

I'm strongly in favor of opening an area of study which attempts to address these issues and bring them into the light.

Do you think there are any general insights which can be distilled about Enterprise Java which poor Rubyists have overlooked in their secession wars?

The problem with CCS in the form it is presented here is not so much that there is a sociology and a culture of programming which has been ignored but it is already a matter of self-reflection, though not a systematic one and I wonder if there is an urgent need for this.

One thing which has to be understood by any serious researcher in the field: there is a desire and drive to encode political issues back into technical ones and there is no social dispute which can be isolated from that of its possible technological fixes. Or fixes of the kind of ergonomic UI design which leads to the most recent debates about Apple. So not only has technology a political dimension but it is also the other way round in a quite manifest way. I hoped that became clear during all the interpretative efforts to understand what "Web 2.0" means despite being a self referential slogan which was meant to initialize and focus this process of interpretation ( one of the best answers I heard was: "more bandwidth" which nailed it in a good old materialist fashion ).

This changes everything including what criticism means. I'd recommend reading the discussion threads again on LtU regarding the SEC proposal to use Python. It is a bit of a microscopic drama which illustrates a lot. Dürrematt would have enjoyed it.

Take this Usenet exchange: link.

There's enough raw sociological material in there to choke an entire humanities seminar including the culture of Usenet and electronic communities in general; a community's boundary between "tough love" vs "just plain mean"; the "meet you half way" theory of education; the "show love for something by parodying" it concept of obfuscated code; the relationship between code obfuscation and other forms of post-modern art including "found art"; showing off for the sake of peer recognition; newbies vs old-guard; "insider" jokes as a way to enforce cultural boundaries; and probably plenty more.

The question is this: can't most of that stuff be found from a more sociological and anthropological point of view? Does literary criticism for code really help? The email linked is about 60% code by line count, but with the right background the sociological stuff can be inferred with only a glance at the code. The code itself, taken entirely out of context, is just bad ascii art.

You can find this "more sociological and anthropological point of view" in studies like Two Bits and Adrian Mackenzie's Cutting Code (and of course ESR's stuff, &c.). As I understand it, CCS is trying to do something slightly different.

My impression is that most people here agree that there's a clear value in the Two Bits approach, even if specific examples of it get some details wrong. I'm personally more curious about perspectives on the value of CCS, which seems to be an open question.

You can find this "more sociological and anthropological point of view" in studies like Two Bits and Adrian Mackenzie's Cutting Code (and of course ESR's stuff, &c.). As I understand it, CCS is trying to do something slightly different.

Seems that way to me too. But perhaps somewhere in the anti-matter universe, someone is posting to a blog right now about how his software for detecting race conditions in multi-threaded applications might have a lot of applicability to gaining a deeper understanding of Shakespeare, and a bunch of other people are responding "Right on! Using that technology stuff for creating databases of Shakespeare's complete works that can be indexed by prosody at the sentence level might be really useful!"

Indeed, you'd think he'd at least have the decency to line up all the diamonds with the center axis of the Christmas tree...

Perhaps you could give a compelling example of a critical code study?