Latour's Anti-Abstractionism

[Greg Borenstein]

So, since Steve and I (at least) are both reading Latour's Reassembling the Social, I thought I'd write a little bit about one of the main aspects of Latour's thought I find super-fascinating: his attitude towards abstraction. I think these ideas are also part of why Latour is the patron saint of Object Oriented Ontology. Further, abstraction is also such an important concept in software that I've been really fascinated by how our use of the term overlaps (and doesn't) with it in this philosophical discourse.

Hopefully, this email will act as a little bit of an intro to some of these ideas for others just tuning in. If that's you, I highly recommend Latour's Reassembling the Social as well as Graham Harman's book about Latour, Prince of Networks. Everyone else who's read it -- or is reading it or has questions or opinions -- feel free to jump in, correct me, refine me, etc. This is me trying to summarize the parts of Latour's technique I've locked onto so far, but there's lots missing and lots of other directions to take it. I'm sorry it's long -- I don't understand this stuff expertly enough to write a short summary. :)

So, Bruno Latour is a French sociologist. He started out best known for his early work in the sociology of science (see his early book Laboratory Life) and technology (Aramis, or the Love of Technology, a book I super recommend especially for technologists -- it's about a proposed mass transit system for the city of Paris that was never built; it's structured as a murder mystery answering the question: Who killed Aramis?).

Reassembling the Social is the book where Latour describes the method of his type of sociology. Latour names his style of sociology "the sociology of associations" and contrasts it against most (all other?) sociology which he terms "the sociology of the social". In this latter, more standard, version of the discipline, sociologists study how aspects of "society" affect people. How "social conventions" or "capitalism" or "the social order" explain or modify various parts of human behavior. For sociologist of the social, "although it is recognized that law has its own strength, some aspects of it would be better understood if a 'social dimension' were added t o it; although economic forces unfold under their own logic, there also exists social elements which could explain the somewhat erratic behavior of calculative agents." (p.3)

Latour rejects the existence of "society" as an established entity that can have causal effects. Instead, he says, "society" is exactly that which needs to be explained. For him the job of the sociologist is to trace and catalog all the work that individual "actors" (this word is going to become important in a minute) constantly perform in order to maintain their associations with all the other actors around them. There are "no groups, only group formation" constantly ongoing and constantly controversial. This is what he calls the "sociology of associations". Another term for Latour's method is "Actor Network Theory" (ANT).

Now here's where things start getting interesting. First of all, actors do not possess agency wholly in themselves. They seem to be driven -- or, in Latour's term -- "overtaken" by other things (people, ideas, materials) that are uncannily present around and inside of them. Here I'll quote Latour a bit at length because I think it's a great vivid passage:

"Villages appear to dot the landscape haphazardly until an archaeologist excavates the ancient road networks and realizes that all the settlements align perfectly on some ancient causeways, simply separated by the mean day march of the Roman legions. Who has created the settlement there? What force has been exerted? How could Caesar still be acting through the present landscape? Is there some other alien agency endowed with the long-lasting subterranean power to make settlers 'freely choose' the very place it has allotted them? Here again you wonder, and you wonder even more when you realize, watching the stock exchange one morning, that tens million of your fellow shareholders have sold the same stocks that day, as if your collective mind had been solidly swayed by the hand of some invisible giant. At the school's open-house party, you wonder why all the parents look eerily familiar: same clothes, same jewels, same way of articulating words, same ambitions for their kids. What makes all of us do the same thing at the same time?" (p. 44)

This is where we start to see the real texture of the "sociology of associations". When you start to look closely at abstractions like "geography" or "market forces" or "class identity" you find that a ton of things fall out, both human and non-human. Instead of "the french countryside" or "rural life" you have a whole assemblage that includes average Roman march distances and Julius Caesar, as well as commute times, modern road systems, automobile gas mileage, mass transit systems, home sizes, discourses about nature, urban pollution, attitudes about the French social welfare system, class aspirations tied up with homeownership, etc. etc.

(By the way, these endless lists of things at all kinds of different levels of abstraction were coined "Latour Litanies" by Ian Bogost: http://doctorzamalek2.wordpress.com/2009/12/15/latour-litanies-and-gibbon/)

One interesting thing about Latour's actors is that they can be people or physical objects or intellectual concepts. For Latour, society is created by individual actors in all of these categories vigorously forming and breaking associations between each other as they form and dissolve groups. Physical objects have affordances -- physical properties that limit and constrain how they can be used and how they use and affect other actors -- and they form associations

(This is where the Object-Oriented Ontologists take off from, focusing on the existence of all of these different kinds of actors, in reaction to a long history of western metaphysics, which has mainly defined things as real only insofar as they related to humans.)

So, what about abstraction? I described how Latour opposes abstractions like "the social" as an explanatory force. However, does he then expect us to spend all of the time down at the level of these endless lists of actors? Every time we want to account for some aspect of the world, do we need to take into account every single actor in the network?

Though Latour does advocate strongly for a "slow" approach: one that begins with the voices of the individual actors, he also gives us a technique for talking about larger systems, and it's one that will be extremely familiar to programmers: "black boxing" (originally introduced in Science in Action and further spelled out in Pandora's Hope). In Pandora's Hope, talking about the development of scientific ideas, he writes "the way scientific and technical work is made invisible by its own success. When a machine runs efficiently, when a matter of fact is settled, one need focus only on its inputs and outputs and not on its internal complexity. Thus, paradoxically, the more science and technology succeed, the more opaque and obscure they become."

Before, we saw Latour focusing on the violent dynamics by which actors form groups. There he emphasized the struggles and controversies that resisted abstraction. Here, he points to what happens once those groups are formed, the controversies die down, and the groups become naturalized. A black box forms: an abstraction that we only understand by its name and what we might think of as its API: it's "inputs and outputs". These black boxes only hold as long as the network of actors inside of them are getting along happily and we don't need to look inside. If the controversies flare up again, the black box dissolves and we are forced to look at the individual actors in order to understand what is happening. Also, at any point, with some effort to break the seemingly natural surface of the box we can open even a functioning black box and examine the actors inside to see how it works. (I actually think there's some possibilities to draw some interesting connections to Deconstruction here, that science of box opening.)

Graham Harman uses this concept of black boxes as well in his construction of Object-Oriented Ontology, even though he denies anything other than a superficial connection between his philosophy and object-oriented programming, about which he doesn't know much. I actually think that there are a lot of interesting parallels between the two worth exploring -- however OOO philosophers are gun shy of exploring the concept because they already get accused of being promoters of the world of commerce and capitalism because of their focus on "objects" (a claim I think is unfair, but that's a topic for another time).

In addition to its philosophical implications, I think Latour's method is really interesting for understanding the world around us, especially where it intersects technology. For example, I've been working on an ANT-style analysis of a Facebook "like": tracing all the associations from the user's ties with their friends and families through their fingers, to the screens of their physical devices, through the layers of agreement between operating systems, apps, and hardware, the open source software projects, the physical and electro-magnetic layers of the network, Facebook's distributed computing architecture, the hierarchical organization of their company, the structure of its financial setup, the design of its database system, etc., etc. I think ANT offers the promise of opening up an analysis of something like a Like that considers the material existence of all of the actors involved while also building up some explanatory power that might allow us, as actors in our own rights, to forge new associations and rework our relations to these kinds of systems.

Ok. Whew. That was probably way too long, but I hope it wasn't boring!

-- Greg

[Steve Klabnik]

I haven't finished the book yet, so I don't have too much comment on
this so far, but what I will say is that I also noticed this thought
about abstraction at the beginning of the book, too. And, as you say,
it's a programmer's primary tool, so I took great interest in it as
well.

I don't have fully-formed thoughts on this yet, but I do see
programmers over-abstracting as a social phenomenon, especially when
it comes to getting non-programmers to enter their social bubble. "If
I can RTFM, anyone can," for example. Gender abolition is another area
where I think over-abstraction hurts...

I think that as programmers we need to pick the _appropriate_ level of
abstraction, but often that's hard, and we tend to use too much rather
than too little.

[blambeau]

I think that as programmers we need to pick the _appropriate_ level of
abstraction, but often that's hard, and we tend to use too much rather
than too little.

Could you elaborate a bit more here? I've always been convinced that it was the other way round. Academics in general tend to consider that abstraction is the key to computer science. See http://www.cin.ufpe.br/~redis/intranet/bibliography/middleware/kramer-abstraction07.pdf for instance (a must read in the academics world).

So are we using the term "abstraction" for completely different things here? Or is there **good/bad** abstractions in contrast to **too much / too little**?

[Steve Klabnik]

> So are we using the term "abstraction" for completely different things here?
> Or is there **good/bad** abstractions in contrast to **too much / too
> little**?

This is where I put on my engineer hat and say "it depends."

Of course, abstraction is the key to computer science. As I said
above, it's the primary tool of the computer scientist. To move this
discussion from the virtual to the actual (well, as much as we can ;)
) let's talk specific code:

class BlogPost
def publish
update_attributes(published_at: Time.now)
end
end

vs

class BlogPost
def publish(time)
update_attributes(published_at: time)
end
end

Those of you on the RubyParley list may recognize this recent debate.
This Ruby code (which I hope is simple enough for everyone to
understand, regardless of language) shows two BlogPost classes, both
of which know how to publish themselves. However, time has been
represented differently in each one: in the first, we presume that
another class exists, Time, and that it has some sort of 'now' method
that returns the current time. In the second, we presume that the
calling code will give us some sort of representation of time. As long
as we want to publish our BlogPosts at the current time, these two
pieces of code are identical functionally, but the second introduces a
burden on the calling code. That's the price we pay for a more
abstract notion of time.

Now, that abstraction also gives us a benefit: we can publish at times
that are not Time.now, it's easier to test this class, and we can
reduce the burden on the calling code through a default parameter. But
it's important to recognize that we _do_ have a choice here, and that
each choice has different costs and benefits. I'd like to leave the
elaboration of those details to Parley, if you all wouldn't mind.

This is a situation in which the abstraction is probably good, but we
can also pick one in which it's bad: CVE-2013-0156[1]. This recent
security vulnerability in Rails allowed remote code execution through
embedding shell code in Ruby in YAML in XML. The abstraction here is
that parameters in a certain format were automatically transformed
into Ruby objects if they fit a certain format. Because this is an
abstraction, the details were handled for you, and so you did not even
need to be using XML serialization in your application to be
vulnerable.

There is some continuum here, but angst over abstractions has always
been fruitful for those trying to do philosophical work around
programming. Yegge[2], Shaw[3] and Spolsky[4] all come to mind.

In fact, I think that Deleuze, via Shaw, can bring us back to Latour
on this topic. ;) I swear, sometime I'll write about someone who's not
Deleuze. Anyway, it's about 'tracings' vs. 'maps'. There's an
isomorphism between Shaw's "indirection vs. abstraction" and D&G's
"tracing vs. map". From page 13 of Thousand Plateaus:

On tracings:

> like a photograph or X ray that begins by selecting or isolating, by artificial means such as colorations or other restrictive procedures, what it intends to reproduce.

and

> All tree logic is a logic of tracing and reproduction.

On maps:

> What distinguishes the map from the tracing is that it is entirely oriented toward an experimentation in contact with the real. The map does not reproduce an unconscious closed in upon itself; it constructs the unconscious.... The map is open and connectable in all of its dimensions; it is detachable, reversible, susceptible to constant modification....A map has multiple entryways, as opposed to the tracing, which always comes back "to the same."

and

> The map is open and connectable in all of its dimensions; it is detachable, reversible, susceptible to constant modification. It can be torn, reversed, adapted, to any kind of mounting, reworked by an individual, group, or social formation.

A tracing is an indirection. It's an exact replica, that points
directly at its original. A map, on the other hand, is an abstraction:
it may not be 100% representative of the terrain.[5] That's what makes
it useful: it adds, removes, and alters the terrain to help us
accomplish some task.

To bring it back around to Latour, he asserts that sociology is
obsessed with maps, but it really should be constructing tracings,
because of that obscuring nature of abstraction.

1: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0156
2: http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html
3: http://zedshaw.com/essays/indirection_is_not_abstraction.html
4: http://www.joelonsoftware.com/articles/LeakyAbstractions.html
5: http://en.wikipedia.org/wiki/Trap_street

[Greg Borenstein]

"To bring it back around to Latour, he asserts that sociology is
obsessed with maps, but it really should be constructing tracings,
because of that obscuring nature of abstraction."

To expand on this, one concept I really like from Latour is his idea of "empirical metaphysics": the idea that each actor in the network has their own ideas about the fundamental nature of the world. He says "actors incessantly engage in the most abstruse metaphysical constructions redefining all the elements of the world" (p. 51). He worries that traditional sociologists have pre-decided the metaphysical issues at stake and have done so in a way that reduces the number of agencies that are "really acting". They've done this, he says, "in order to prepare the ground for social engineering on a grand scale and smooth the path towards modernization."

So this is exactly what is being obscured by the "map": the "metaphysical innovations proposed by ordinary actors". By instead following the tracings, we can reveal a wealth of maps, one for each actor in the network.

To bring it back around to software, another thing we know is that all abstractions leak. Latour would council us that this is not some unfortunate quality of reality that disappointingly foils our plans as engineers. Instead, he says that "controversies" like these leaks are opportunities: they are an instance where the black box of some assumed collective opens and the previously invisible actors of which it is constructed become visible, with all of their rich metaphysical innovations: their own diverse ideas about what the system is.

Rather than repressing these and reclosing the black box as soon as possible we should learn from these actors (which, remember can be anything from individual API calls, to a particular user role, to one of the layers of network agreement, to the social conditions in the open source project behind one of the frameworks, ete etc). If the system is in the process of changing (which it always is) then it is likely that one or more of these newly visible actors is in the process of gaining a more prominent place in the network, of building up more alliances with other actors. The only way we can hope to adapt to this change is to carefully observe the metaphysics each of these actors proposes: what system do they seem to imagine they're part of?

[Peat Bakke]

Skipping back to the Object Oriented Ontology -- it almost seems to miss the point that the actors in-and-of themselves are uninteresting; it's their interactions that define them.

I'm not well versed in Latour, so I may be misunderstanding ... But I think it's very important to draw distinctions between behavior and identity.

One of the problems we get into when pursuing a Aristotlian classification of things is that it always breaks down when you look deep enough. In software this leads to the occasional horror show of OO inheritance, interfaces, and traits. In philosophy this leads to the indeterminable questions of "who am I" and "what is art."

But, back to behavior vs identity. If one changes their perspective from attempting to identify and isolate things, to attempting to describe interactions ... You can reach some fun conclusions.

Instead of looking for the atomic thing that defines Peat, you look for a collection of interactions over time that share a high degree of commonality -- but not perfect. Or for a tree, it's the interaction with air, sunlight, soil, water, etc. Calling something Peat or a tree is a convenient abstraction for communication, but it's an awful description of reality.

Applying this to software -- it seems that the object oriented approach is oriented towards identity, whereas functional languages seem oriented towards behaviors.

(Fans flames, drinks another beer)

[Ed Summers]

On Fri, Feb 22, 2013 at 1:48 AM, Peat Bakke <pe...@peat.org> wrote:
> Applying this to software -- it seems that the object oriented approach is oriented towards identity, whereas functional languages seem oriented towards behaviors.

I haven't finished the Latour yet, but I just wanted to say I
completely agree. After years of trying to model objects *just right*
in OOP, I found the focus of functional programming on activities,
data flow, etc instead of on class hierarchies helped me to love
programming again. It's not like I don't use objects, I do, but I've
found focusing on the functions, getting their input and output just
right, minimizing coupling and side effects, make me much more
confident in the software I write, and it is easier to test and evolve
it over time. Maybe that just means I am terrible at OOP, but I
suspect I'm not alone.

You also reminded me of the effect that reading Richard Rorty had on
my software development practices. Rorty is often labelled a
neopragmatist, but he was the gateway drug for Pragmatism (Peirce,
James, Dewey, Quine, later Wittgenstein, Davidson) in general.
Pragmatism was like a mental salve for me after getting in deep
(perhaps over my head) in the Whiteheadian Semantic Web and Linked
Data space where the expectation is that if you get your ontologies
and your data models just right, you can inference on it, and build
killer apps. Instead of focusing on identity and the essential
qualities of things, pragmatism encourages you to flip that around by
valuing what is useful (the functions), instead of "truth" (the
ontology) and letting things flow from there.

Sorry if this all seems random, and not at all related to Latour. I
mainly just wanted to say Hi, and thank the list creators for creating
this (awesome) discussion list, and to Mark Matienzo for letting me
know about it.

//Ed

[Steve Klabnik]

> (Fans flames, drinks another beer)

I think you're _really_ going to like some of my conference talks this
spring. ;) It's really great to see someone else have that same idea I
did, right down to FP vs. OOP.

[Steve Klabnik]

> Sorry if this all seems random,

It does not seem random at all. Thanks for being here! :D

[Ed Summers]

I'm a slow reader, so I imagine all of you have moved on from Reassembling the Social, but I finally finished it and wrote up a light review:

    http://inkdroid.org/journal/2013/05/02/everything-is-data/

Thanks for the recommendation! I am thinking of going a bit deeper with Latour, Prince of Networks ... but I'm also curious to hear what others in the group are reading.

//Ed

[Darius Kazemi]

Prince of Networks is great. If you do read it, check out this thing I made inspired by it.

//Ed

--
You received this message because you are subscribed to the Google Groups "Philosophy in a time of Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to philosophy-in-a-time-o...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Steve Klabnik]

I'm currently still trying to finish Empire, and I brought my copy of
Badious "Number and Numbers" on this trip, though I haven't cracked it
yet.

I recently finished Hardt's book on Deleuze, "Alien Phenomenology",
and "Lean in."

[Darius Kazemi]

Steve, what did you think of Alien Phenomenology? I wrote up some stuff here:

http://tinysubversions.com/2012/04/notes-on-ian-bogosts-alien-phenomenology/

http://tinysubversions.com/2012/05/more-on-alien-phenomenology/

http://tinysubversions.com/2012/06/petunias-and-skittering-lasers/

http://tinysubversions.com/2012/07/alien-phenomenology-pobc-discussion-chapter-1/

http://tinysubversions.com/2012/07/alien-phenomenology-pobc-discussion-chapters-2-and-3/

It is personally the most important book I've read in years, in that carpentry informs a huge chunk of my life now.

[Steve Klabnik]

I'll be writing up a real review at some point, but TL;DR:

The carpentry concept is great, but the rest of the book solidified my
rough feeling that I'm anti-OOO into "Yes, I am absolutely 100%
anti-OOO."

[Darius Kazemi]

Heh, your Deleuze posts are doing the same for me -- /s/OOO/Deleuze :)

[David Nolen]

On Fri, Feb 22, 2013 at 1:48 AM, Peat Bakke <pe...@peat.org> wrote:

Applying this to software -- it seems that the object oriented approach is oriented towards identity, whereas functional languages seem oriented towards behaviors.

(Fans flames, drinks another beer)

I think the OO obsession with identity is really a part of mainstream OO culture and not an important element of the original OO vision. Alan Kay's points on OO:

http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html

David

[Stefano Zanella]

I totally second that. Probably the difficulties a lot of people face when designing OO software come just from this misconception. There are some progress toward changing the direction of this orientation, though, one of these being the movement built around the ideas of Steve Freeman and Nat Pryce in their "Growing Object-Oriented Software, Guided by Tests" book. Personally, I experienced on my skin what this change in focus can lead to: the only things I could build focusing on identity and classes were unmantainable and quite disgusting to me to work on. Now that I'm trying to master the focus on behavior in terms of messaging between objects, things are becoming clearer and reasoning process more natural (even in a not-so-strict language like Ruby).

I'm not sure if there's a lesson to be learned here. For me, probably, it's that the more something brings dichotomous views (fans vs haters), the more critical my eye has to be when looking at the subject.

My 2 cents,

    Stefano

[Ed Summers]

Interesting, I'd never really made that connection before: BDD and
unit testing in general definitely help flip your brain around from
getting your class hierarchy just right (ontology), to (the much more
satisfying) modeling of behavior.

Thanks for the book recommendations, I'm going to give Alien
Phenomenology a read so I can have an opinion about it :-D

//Ed