http://electronicbookreview.

com/thread/firstperson/recoded

Critical Code Studies Conference - Week Two Discussion

by
Jeremy Douglass
2011-04-14
In the second installment of a six-week discussion, contributors search for examples of Critical
Code Studies “in the wild.” Instead of asking how code can be read critically, they examine how
code is already being created and disputed by lawyers, programmers, and the general public.
Editor’s Note:
In the second installment of the discussion that took place in the summer of 2010, Jeremy Douglass
leads the Critical Code Studies Working Group in exploring the practical challenges and constraints
of reading code critically, with an emphasis on real-world examples. An introduction and overview
for this week by Mark Marino and Max Feinstein is available here. -Ed Finn

Reading Reading Code

________________________________________
How should we read code?
In crafting my contribution to our shared conversation, this question has been my starting point,
both because and despite the fact that it is (in many ways) simple, obvious, and the wrong question.
First, I’ll spend a short time framing one aspect of the enterprise of Critical Code Studies as I see it,
then draw out some of the implications for concrete ways in which code becomes an object of
criticism and then circulates in a critical discourse. How do operations like citation, paraphrase, and
especially quotation function in code criticism, and how do we constitute and circulate those
primary sources that secondary readings then rely upon? Next, I would like to perform a
substitution:
"How should we read code?" ->
"How do we read code?"

“How do we read code?” is the more generative and productive question in many respects. It brings
into focus our own diverse code reading practices, and asks us to explore the complexity that
actually underlies a “two cultures” stereotype of ur-programmer and ur-critic literacies. It also
invites us to go further: “How does everyone already read code?” suggests we look to the myriad
ways in which code criticism already exists “in the wild,” far outside disciplinary categories.
Let me begin at the beginning.
Code, but Critically
Week 1 briefly situated Critical Code Studies in relation to the recent emergence of a set of
overlapping interdisciplinary areas of inquiry, including Software Studies, Platform Studies,
Hardware Studies and, of course, Critical Code Studies. But what is our more general situation?
Why “Critical Code Studies”, as opposed to “Code Studies”? Is it just a marker of difference,
distinguishing an open field of new interdisciplinary exploration, where “Code Studies” could be
confused with the established paradigms of software engineering and computer science?
Yet the term “critical” suggests its own established paradigm. Critical * Studies is a popular phrasal
template (or perhaps snowclone) in academia, particularly in the creation of new cultural studies
subfields. So for example in the case of Critical Disability Studies or Critical Terrorism Studies, the
critic (who apparently does not merely study, but does so critically) is distinguished from the
presumed inner-standing point of a default domain professional: the medical expert on disability,
the government agent on terrorism, the programmer on code and so forth. Read in this light,
“Critical Code Studies” suggests a great mapping of one culture of knowledge onto another: some
practices of hermeneutic textual commentary, perhaps taken directly from the humanities or arts,
and then mapped onto the domain of programming in software engineering and computer science.
Conferencia sobre Estudios de Código Críticos - Segunda semana de debate
por
Jeremy Douglass
2011-04-14
En la segunda entrega de un debate de seis semanas, los colaboradores buscan ejemplos de Critical
Code Studies "en la naturaleza". En lugar de preguntar cómo se puede leer el código críticamente,
examinan cómo el código ya está siendo creado y disputado por abogados, programadores, y el
público en general.
Nota del editor:
En la segunda entrega de la discusión que tuvo lugar en el verano de 2010, Jeremy Douglass lidera
el Grupo de Trabajo de Estudios de Código Crítico al explorar los desafíos prácticos y las
limitaciones de la lectura crítica del código, con énfasis en ejemplos del mundo real. Una
introducción y una descripción general para esta semana de Mark Marino y Max Feinstein está
disponible aquí. -Ed Finn
Leyendo el código de lectura
________________________________________
¿Cómo deberíamos leer el código?
Al elaborar mi contribución a nuestra conversación compartida, esta pregunta ha sido mi punto de
partida, tanto porque a pesar de que es (en muchos aspectos) simple, obvia y la pregunta
equivocada. En primer lugar, dedicaré un breve espacio de tiempo a encuadrar un aspecto de la
empresa de Estudios de Código Críticos tal como lo veo, y luego extraeré algunas de las
implicaciones de las formas concretas en que el código se convierte en objeto de crítica y luego
circula en un discurso crítico. ¿Cómo funcionan las operaciones como la cita, la paráfrasis, y
especialmente la cita, en la crítica del código, y cómo constituimos y circulamos esas fuentes
primarias de las que dependen las lecturas secundarias? A continuación, me gustaría realizar una
sustitución:
"¿Cómo deberíamos leer el código?" ->
"¿Cómo leemos el código?"
"¿Cómo leemos el código?" Es la pregunta más generadora y productiva en muchos aspectos. Pone
de relieve nuestras propias prácticas diversas de lectura de códigos, y nos pide que exploremos la
complejidad que en realidad subyace en un estereotipo de "dos culturas" de ur-programmer y ur-
critic alfabetizaciones. También nos invita a ir más allá: "¿Cómo todo el mundo lee el código?",
Sugiere que analicemos la miríada de formas en que la crítica del código ya existe "en la
naturaleza", fuera de las categorías disciplinarias.
Déjame comenzar desde el principio.
Código, pero Críticamente
La Semana 1 se ubicó brevemente en Critical Code Studies en relación con la reciente aparición de
un conjunto de áreas interdisciplinarias de investigación superpuestas, que incluyen estudios de
software, estudios de plataforma, estudios de hardware y, por supuesto, estudios de código crítico.
Pero, ¿cuál es nuestra situación más general?
¿Por qué "Estudios de Código Críticos", a diferencia de "Estudios de Código"? ¿Es solo un
marcador de diferencia, que distingue un campo abierto de nueva exploración interdisciplinaria,
donde los "Estudios de código" podrían confundirse con los paradigmas establecidos de la
ingeniería de software y la informática?
Sin embargo, el término "crítico" sugiere su propio paradigma establecido. Critical * Studies es una
plantilla phrasal popular (o tal vez snowclone) en la academia, particularmente en la creación de
nuevos subcampos de estudios culturales. Entonces, por ejemplo, en el caso de los Estudios de
Discapacidad Crítica o Estudios Críticos de Terrorismo, el crítico (que aparentemente no solo
estudia, pero lo hace críticamente) se distingue del presunto punto interno de un profesional de
dominio predeterminado: el experto médico en discapacidad , el agente del gobierno en el
terrorismo, el programador en el código y así sucesivamente. Leído en esta luz, "Critical Code
Studies" sugiere un gran mapeo de una cultura del conocimiento en otra: algunas prácticas de
comentario textual hermenéutico, quizás tomadas directamente de las humanidades o las artes, y
luego mapeadas en el dominio de la programación en ingeniería de software y Ciencias de la
Computación.

Code for Two Cultures?

Of course, my invoking the metaphor of “mapping” hugely oversimplifies the CCS project and its
participants - and also does so in a way that implies a kind of territorial violence. Is code a territory
at all? I don’t choose to believe so, but I’m drawing out the idea because it seems to be implied in
several debates that already recur regularly around CCS, many framed in terms of cultures of
disciplinary power:

 If code is territory, does the philosophy of mathematics hold dominion over it, while the
huddled hermeneutic masses yearn to breathe free? Conversely, does the imperialist culture
of continental philosophers seek to invade and colonize code’s virgin soil, displacing its
native culture?
 What counts as a productive relationship to code, or to reading in general? What constitutes
a dangerous relationship? Who is qualified to be productive? …and why must all you people
from [$OpposingSide] insist on devaluing my modes of literacy, especially when you
haven’t even tried to understand them?
In my own background, I’m reminded in many ways of the recent emergence of the “Narratology
vs. Ludology” debates in Game Studies. These debates were sometimes productive conversations
about the key terms of a new endeavor. Yet, at their most heated, they tended to obscure the diverse
and subtle positions of participants. The problem with a “two cultures” frame is that the insertion of
a “versus” hides the rich interdisciplinarity of a community by posing a false choice: which of two
sides will emerge victorious and thereafter be allowed to speak?
Literacy -> Literacies
My original draft preparation for this assembly traced connecting lines from scholarly publishing
culture towards software engineering culture, undertaking a set of heuristic or syllogistic
explorations to imagine what a productive code criticism culture might look like, moving from the
big issues down to the nuts-and-bolts level of the code snippet:

 Reference: What are the paratextual and intertextual conventions or archival infrastructures
needed to support code availability that might keep a critical work comprehensible over
time? What are the contextual and intertextual demands of that fact that code meaning is
increasingly situated within complex and rapidly evolving platform ecosystems, whether
across the operating system or the network? For example, is a complete emulation image of
an appropriate configured Windows machine circa 2001 necessary to truly understand the
AnnaKournikova worm? Is a complete copy of the Google PageRank algorithm (or indeed
Google’s data cloud) necessary to understand a search engine artwork which makes use of
Google APIs?
 Citation: How and what do we cite when we use code (as opposed to or in addition to
software) as a primary source in a publication? What are the issues specific to code about
versions and their production and reception that should be reflected in citation style?
 Quotation: What are the basic principles of significance and selection? What are useful
strategies and conventions for excerpting (e.g. ellipses, explicit substitution, editorial
comment, etc.)? What are the forms of paraphrase, through pseudocode, documentation,
description, or otherwise? Where are they appropriate and how should they be signaled? Is
Text : Quotation :: Code : Snippet? How?
 Illustration: When does illustration become necessary, in response to code environment
paradigms (e.g. patch programming or weird languages) or affordances (e.g. syntax
highlighting, folding, search, or visualization)? What are the forms of illustration useful for
code, whether screenshots, video clip, executable applets, emulation snapshot etc.?
This a priori exploration can of course be performed in the opposite direction as well, a posteriori.
We could start with the conventions of speaking about code that already circulate in global
discourse that both is code and is about code - the history and culture of the documentation, diffs,
snippets, pseudocode, proofs, and paraphrase that already make up part of the evolving literacies of
programming textbooks, computer science articles, and code forums. Just as humanists are not
inventing the idea of reading code critically, scholars are not inventing the idea of a textual
apparatus around code - but everyone has much they could gain from and contribute to
understanding code.
The act of imagining multiple reading communities and concerns in relationship to code is
beneficial to all. Insisting on the power and importance of practical fluency in programming does
not disenfranchise the cultural critic. Similarly, evocative readings of keywords and their poetics or
cultural overdeterminations do not displace the authority of the pragmatic programmer. Finally,
there is not a spectrum of two literacies - there are myriad literacies that are not mutually exclusive.
Código para dos culturas?
Por supuesto, mi invocación de la metáfora del "mapeo" simplifica enormemente el proyecto de
CCS y sus participantes, y también lo hace de una manera que implica un tipo de violencia
territorial. ¿El código es un territorio en absoluto? No elijo creerlo, pero estoy sacando la idea
porque parece estar implícita en varios debates que ya se repiten regularmente en torno a CCS,
muchos enmarcados en términos de culturas de poder disciplinario:
Si el código es territorio, ¿la filosofía de las matemáticas tiene dominio sobre él, mientras que las
masas herméticas acumuladas anhelan respirar libremente? Por el contrario, ¿la cultura imperialista
de los filósofos continentales busca invadir y colonizar el suelo virgen del código, desplazando a su
cultura nativa?
¿Qué cuenta como una relación productiva con el código, o con la lectura en general? ¿Qué
constituye una relación peligrosa? ¿Quién está calificado para ser productivo? ... y ¿por qué toda la
gente de [$ OpposingSide] insiste en devaluar mis modos de alfabetización, especialmente cuando
ni siquiera has intentado comprenderlos?
En mi propio contexto, recuerdo de muchas maneras la reciente aparición de los debates sobre
"Narratología vs. Ludología" en Game Studies. Estos debates a veces fueron conversaciones
productivas sobre los términos clave de un nuevo esfuerzo. Sin embargo, en su forma más
acalorada, tendían a oscurecer las posiciones diversas y sutiles de los participantes. El problema con
un marco de "dos culturas" es que la inserción de un "versus" oculta la rica interdisciplinariedad de
una comunidad al plantear una elección falsa: ¿cuál de los dos bandos saldrá victorioso y luego se le
permitirá hablar?
Alfabetización -> Alfabetizaciones
Mi borrador original de preparación para esta asamblea trazó líneas de conexión entre la cultura
editorial erudita y la cultura de la ingeniería de software, emprendiendo un conjunto de
exploraciones heurísticas o silogísticas para imaginar cómo podría ser una cultura de crítica de
código productiva, pasando de los grandes temas a las nueces. -bolts nivel del fragmento de código:
Referencia: ¿Cuáles son las convenciones paratextuales e intertextuales o las infraestructuras de
archivo necesarias para soportar la disponibilidad del código que podría mantener un trabajo crítico
comprensible a lo largo del tiempo? ¿Cuáles son las demandas contextuales e intertextuales de ese
hecho de que el significado del código se encuentra cada vez más dentro de ecosistemas de
plataforma complejos y en rápida evolución, ya sea a través del sistema operativo o la red? Por
ejemplo, ¿es necesaria una imagen de emulación completa de una máquina Windows configurada
adecuada alrededor del año 2001 para comprender realmente el gusano AnnaKournikova? ¿Es
necesaria una copia completa del algoritmo del PageRank de Google (o de la nube de datos de
Google) para comprender una obra de arte del motor de búsqueda que hace uso de las API de
Google?
Citación: ¿Cómo y qué citamos cuando utilizamos el código (en oposición o además del software)
como fuente principal en una publicación? ¿Cuáles son los problemas específicos del código sobre
las versiones y su producción y recepción que deberían reflejarse en el estilo de las citas?
Cita: ¿Cuáles son los principios básicos de significación y selección? ¿Cuáles son las estrategias y
convenciones útiles para el fragmento (por ejemplo, elipsis, sustitución explícita, comentario
editorial, etc.)? ¿Cuáles son las formas de paráfrasis, a través de pseudocódigo, documentación,
descripción u otras? ¿Dónde son apropiados y cómo deben ser señalados? Es texto: Cotización ::
Código: ¿fragmento? ¿Cómo?
Ilustración: ¿Cuándo se vuelve necesaria la ilustración en respuesta a los paradigmas del entorno de
código (por ejemplo, programación de parches o idiomas extraños) o permitidos (por ejemplo,
resaltado de sintaxis, plegado, búsqueda o visualización)? ¿Cuáles son las formas de ilustración
útiles para el código, ya sean capturas de pantalla, videoclip, applets ejecutables, instantáneas de
emulación, etc.?
Esta exploración a priori también puede realizarse en la dirección opuesta, a posteriori. Podríamos
comenzar con las convenciones de hablar sobre el código que ya circula en el discurso global, que
es tanto código como código. La historia y la cultura de la documentación, diffs, snippets,
pseudocode, pruebas y paráfrasis que ya forman parte del alfabetización en evolución de libros de
texto de programación, artículos de informática y foros de códigos. Así como los humanistas no
están inventando la idea de leer el código de manera crítica, los estudiosos no están inventando la
idea de un aparato textual alrededor del código, pero todos tienen mucho de lo que podrían
beneficiarse y contribuir a la comprensión del código.
El acto de imaginar comunidades de lectura múltiple y las preocupaciones en relación con el código
es beneficioso para todos. Insistir en el poder y la importancia de la fluidez práctica en la
programación no priva de derechos a la crítica cultural. De manera similar, las lecturas evocadoras
de palabras clave y sus poéticas o sobredeterminaciones culturales no desplazan la autoridad del
programador pragmático. Finalmente, no hay un espectro de dos alfabetizaciones: hay innumerables
alfabetizaciones que no son mutuamente excluyentes.

How I’ve Read Code

After a week of this workshop, I’ve come to the conclusion that Mark Marino’s admonition to
show-not-tell has been incredibly productive. Big meditations on our models and frameworks for
code citation aren’t the spirit of the day - the thing to spur on the conversation is a little less
taxonomy and a little more bestiary.
In ending on a specific note, one strategy I considered was to follow the AnnaKournikova example
from Week 1, taking a code snippet that has appeared in my own previous critical writing and
presenting it for group discussion. This would probably have been either:
1. Andrew Plotkin’s interactive fiction Shade, the Inform 6 source code of which is discussed in
some detail in my dissertation Command Lines and in a chapter of Harrigan and Noah Wardrip-
Fruin’s Second Person. This is in many ways my favorite personal code reading, as it tries to
explore the aesthetic meaning of the code from the point of view of the user, the interpreter, and the
programmer in terms of the history of both a single play session and evolution of the programming
language.
2. Basic Screen Effects by Emily Short, an Inform 7 library. I briefly highlighted this in my
“”#include Genre” pecha kucha presentation at SoftWhere 2008, in which I sketched out how
libraries and header files function in source code, the way that they are inherited, and how they can
become vectors for unintended aesthetic effects. Short’s library code here is particularly interesting
in that she has been deeply involved in the evolution of the language specification, compiler, IDE,
documentation, demo code, and award-winning works that make up the total code ecosystem of
Inform.
3. Beep.path, the “hello world” program of the PATH Interpreter (and, with quine-like simultaneity,
the logo as well). PATH is an esoteric / weird language that I’ve presented on at Electronic
Literature Organization and Digital Humanities talks that discussed the rhetorics of patch-based and
visual flow programming. In “What Counts as Code to Criticize? Interpreting flow control and
natural language programming” [video] at the Software / Code Studies panel of Digital Humanities
2009, I tried to begin with our default assumptions about what code is (e.g. imperative
programming languages such as C) and explore the implications of code criticism within other
paradigms. Part of this grew out of my earlier thinking on visual code at Electronic Literature
Organization 2008: “Flowchart Art: Programming Literary Flow.”
Who Reads Code?
My challenge to the workshop for this week is to find concrete examples of actual code reading that
enrich our idea of who reads code, and how - particularly examples that refine, complicate, or move
beyond “two cultures” stereotypes of the code programmer with a mind of winter and the code poet
with a heart too easily made glad. Code has many real and ideal readers, with many goals. One of
these (and an important one) is the ideal programmer. Another is the ideal machine - a compiler,
VM, or scripting engine. In one particular story about these ideal readers, the ideal programmer is
purely motivated by functionalism, while the ideal machine engages in an interpretive procedure
untroubled by ambiguity. Rather than detail this ideal, I propose a dose of the real. Real code
readers also include:

 mathematicians reading for beauty

 craftsman reading for elegance
 customers reading to make a purchase decision
 managers reading for quarterly job evaluations
 hackers reading for exploits
 tricksters reading for obfuscations
 amateurs and hobbyists and students
 …making their first web page
 …copying some other script kiddy
 …or just trying to learn to think differently
 lawyers and expert witnesses
 …looking for a DUI acquittal in a breathalyzer
 …impugning the code or security of a voting machine in a recount
 …trying to define an intellectual property violation in an open source OS
 easter-egg hunters
 …collecting trivia from code
 …harvesting data and media assets from code
 …indexing business contacts from code
 …participating in ARGs and viral marketing campaigns in code
Cómo he leído el código
Después de una semana de este taller, llegué a la conclusión de que la advertencia de Mark Marino
de mostrar-no-decir ha sido increíblemente productiva. Las grandes meditaciones sobre nuestros
modelos y marcos para la cita del código no son el espíritu del día; lo que debe estimular la
conversación es un poco menos de taxonomía y un poco más de bestiario.
Al finalizar con una nota específica, una de las estrategias que consideré fue seguir el ejemplo de
AnnaKournikova de la Semana 1, tomar un fragmento de código que apareció en mi crítica crítica
anterior y presentarlo para discusión grupal. Esto probablemente habría sido:
1. La ficción interactiva de Andrew Plotkin, Shade, cuyo código fuente Inform 6 se trata con cierto
detalle en mi disertación Command Lines y en un capítulo de Harrigan y Noah Wardrip-Fruin's
Second Person. Esta es de muchas maneras mi lectura de código personal favorita, ya que trata de
explorar el significado estético del código desde el punto de vista del usuario, el intérprete y el
programador en términos de la historia de una sesión de juego único y la evolución del lenguaje de
programación.
2. Efectos de pantalla básicos por Emily Short, una biblioteca de Inform 7. Brevemente destaqué
esto en mi presentación de pecha kucha "#include Genre" en SoftWhere 2008, en la que esbocé
cómo funcionan las bibliotecas y los archivos de cabecera en el código fuente, la forma en que se
heredan y cómo pueden convertirse en vectores para la estética involuntaria efectos. El código de la
biblioteca de Short aquí es particularmente interesante porque ha estado profundamente involucrada
en la evolución de la especificación del lenguaje, el compilador, el IDE, la documentación, el
código de demostración y los trabajos galardonados que conforman el ecosistema de código total de
Inform.
3. Beep.path, el programa "hello world" del intérprete PATH (y, con simultaneidad similar a quine,
el logo también). PATH es un lenguaje esotérico / extraño que he presentado en las charlas de
Electronic Literature Organization y Digital Humanities que discutieron la retórica de la
programación basada en parches y flujo visual. En "¿Qué cuenta como código para criticar?
Interpretando el control de flujo y la programación del lenguaje natural "[video] en el panel de
Software / Code Studies de Digital Humanities 2009, traté de comenzar con nuestras suposiciones
predeterminadas sobre qué código es (por ejemplo, lenguajes de programación imperativos como C)
y explorar las implicaciones del código crítica dentro de otros paradigmas. Parte de esto surgió de
mi pensamiento anterior sobre el código visual en Electronic Literature Organization 2008:
"Flowchart Art: Programming Literary Flow".
¿Quién lee el código?
Mi desafío al taller de esta semana es encontrar ejemplos concretos de lectura de códigos que
enriquezcan nuestra idea de quién lee el código y cómo, en particular ejemplos que refinan,
complican o superan los estereotipos de "dos culturas" del programador de códigos con una mente
del invierno y el poeta del código con un corazón demasiado fácil de alegrarse. Code tiene muchos
lectores reales e ideales, con muchos objetivos. Uno de estos (y uno importante) es el programador
ideal. Otra es la máquina ideal: un compilador, VM o motor de scripting. En una historia particular
sobre estos lectores ideales, el programador ideal está puramente motivado por el funcionalismo,
mientras que la máquina ideal se involucra en un procedimiento interpretativo que no se ve afectado
por la ambigüedad. En lugar de detallar este ideal, propongo una dosis de lo real. Los lectores de
códigos reales también incluyen:
matemáticos leyendo por belleza
artesano leyendo por elegancia
clientes leyendo para tomar una decisión de compra
gerentes leyendo para evaluaciones de trabajo trimestrales
hackers leyendo por exploits
embaucadores leyendo por ofuscaciones
aficionados y aficionados y estudiantes
... haciendo su primera página web
... copiando a otro script kiddy
... o simplemente tratando de aprender a pensar de manera diferente
abogados y testigos expertos
... buscando una absolución de DUI en un alcoholímetro
... impugnando el código o la seguridad de una máquina de votación en un recuento
... tratando de definir una violación a la propiedad intelectual en un SO de código abierto
cazadores de huevos de Pascua
... recopilando datos triviales del código
... recolección de datos y activos multimedia del código
... indización de contactos comerciales del código
... participando en ARG y campañas de marketing viral en código

Make no mistake - people (and not just professional programmers or techno-critics or industry
gurus) already read code critically. They argue about whether the code is functional, but also
whether the code is virtuous or deceitful, conscientious or negligent, egalitarian or discriminatory.
People debate whether a single piece of code represents either a global warming hoax conspiracy or
the messy work of legitimate science. They treat code archives as business-lead opportunities, and
post online shopping-cart exploit code as a way of fighting the man. They claim that code legibility
is akin to a fundamental human right - or they claim that the act of changing code itself is akin to a
mortal sin against the almighty creator. People bring audiences together around performances that
dip in and out of reading code. These discourses don’t represent an illiterate or vulgar culture at the
periphery of core programming culture, either - they are the very heart of literate programming.
Groklaw began as way for programmers and legal experts to combine expertise in the history of
UNIX source code with a partisan intervention in a contentious lawsuit - an expertise
crowdsourcing in response to the massive exhibition of code as evidence. “Forks” are often code
civil wars, in which a code writing community splits along lines of functionality, but also aesthetics,
personality, and working culture.
What can we learn from these readings? What techniques and perspectives can we offer that would
best serve both ourselves and our home disciplines, and also these communities?

Example: The Climate Research Unit Climategate Code

These are two example videos in which different arguments are made about the same source - one
argues that the leaked source code is a “smoking gun” that reveals a climate change hoax, while the
other argues that it does not. The arguments on both sides are made based on a huge mix of
rhetorical appeals.
Video 1: CRU Source Code Explained (a Climategate exposé)
Michael Suede performs a selection of readings from source code that was part of the information
exposed by the 2009 Climate Research Unit hacking incident. The presentation includes reading
aloud from code comments, displaying code and comment screenshots, and discussing the snippets
in the context of relevant algorithms and practices.
I discuss the actual source code that was released in the recent hack of the CRU. The source code
confirms the manipulation of climate data by climate scientists…
Suede states that this reading is part of a larger project to challenge climate change evidence - not
just from the CRU, or papers that cited CRU, but from any other climate research source that agreed
with CRU in its findings. That challenge hinges on code snippets and their comments.
Video 2: Debunking Climategate: The Source Code A
Video 2: Debunking Climategate: The Source Code B
Conversely, the second video argues for a different interpretation of the Climategate source code
based on a critique of interpretive rhetoric (e.g. ad hominem interpretation), an appeal to
understanding of the culture of personality among software engineers, and the contextually specific
meaning of the word “integrity” and what it signifies in the context of “data integrity” about the
software and data.
One of the bigger points I hear in the arguments about Climategate is that the emails, while
interesting, aren’t considered the “true smoking gun” in the scandal. Rather, the real meat is inside a
package of source code and programmer’s notes that was included along with the emails.
The skeptics say that in [the code] is evidence of tampering with data and other bad behavior - and
since this is source code (i.e. logic and mathematics) it is not something that can be taken out of
context like a person’s words in an email can.
I feel, though, that there is a fair amount of reasonable doubt that can be thrown the source code’s
way, and that a lot of the more serious claims that skeptics make about the code and what it means
for Climategate, really aren’t so.
How is this code being read, by whom? How could it be read differently?
Reply by Sheldon Brown on February 8, 2010 at 5:24pm
No se equivoquen: las personas (y no solo los programadores profesionales o los tecnocríticos o los
gurús de la industria) ya leen el código críticamente. Discuten si el código es funcional, pero
también si el código es virtuoso o engañoso, concienzudo o negligente, igualitario o discriminatorio.
La gente debate si una sola pieza de código representa una conspiración de engaño sobre el
calentamiento global o el desordenado trabajo de la ciencia legítima. Tratan los archivos de códigos
como oportunidades de negocio y publican un código de explotación de compras en línea como una
forma de luchar contra el hombre. Afirman que la legibilidad del código es similar a un derecho
humano fundamental, o afirman que el acto de cambiar el código en sí es similar a un pecado mortal
contra el creador todopoderoso. Las personas reúnen al público en torno a actuaciones que entran y
salen del código de lectura. Estos discursos tampoco representan una cultura analfabeta o vulgar en
la periferia de la cultura central de programación, son el corazón de la programación alfabetizada.
Groklaw comenzó como un camino para que los programadores y expertos legales combinen la
experiencia en la historia del código fuente de UNIX con una intervención partidista en una
demanda contenciosa: un crowdsourcing de experiencia en respuesta a la exhibición masiva de
código como evidencia. "Forks" a menudo son guerras civiles codificadas, en las que una
comunidad de escritura de códigos se divide en líneas de funcionalidad, pero también en estética,
personalidad y cultura de trabajo.
¿Qué podemos aprender de estas lecturas? ¿Qué técnicas y perspectivas podemos ofrecer que nos
sirvan tanto a nosotros mismos como a nuestras disciplinas domésticas, y también a estas
comunidades?
Ejemplo: El Código Climático de la Unidad de Investigación Climática
Estos son dos videos de ejemplo en los que se hacen diferentes argumentos sobre la misma fuente:
uno argumenta que el código fuente filtrado es una "pistola humeante" que revela un engaño sobre
el cambio climático, mientras que el otro argumenta que no es así. Los argumentos en ambos lados
se basan en una gran mezcla de recursos retóricos.
Video 1: Explicación del código fuente de CRU (una exposición de Climategate)
Michael Suede realiza una selección de lecturas del código fuente que fue parte de la información
expuesta por el incidente de piratería de la Unidad de Investigación Climática 2009. La
presentación incluye la lectura en voz alta de los comentarios del código, la visualización de
capturas de pantalla de código y comentario, y la discusión de los fragmentos en el contexto de los
algoritmos y prácticas relevantes.
Discuto el código fuente real que se lanzó en el reciente corte de la CRU. El código fuente confirma
la manipulación de los datos climáticos por científicos climáticos ...
Suede afirma que esta lectura es parte de un proyecto más amplio para desafiar la evidencia del
cambio climático, no solo de la CRU, o los documentos que citaron CRU, sino de cualquier otra
fuente de investigación climática que estuvo de acuerdo con CRU en sus hallazgos. Ese desafío
depende de los fragmentos de código y sus comentarios.
Video 2: Desenmascarando Climategate: el código fuente A
Video 2: Desenmascarando el Climategate: el código fuente B
Por el contrario, el segundo video aboga por una interpretación diferente del código fuente de
Climategate basada en una crítica de la retórica interpretativa (por ejemplo, interpretación ad
hominem), una apelación a la comprensión de la cultura de la personalidad entre los ingenieros de
software y el significado contextual específico de la palabra "Integridad" y lo que significa en el
contexto de "integridad de datos" sobre el software y los datos.
Uno de los puntos más importantes que escucho en los argumentos sobre Climategate es que los
correos electrónicos, aunque son interesantes, no son considerados la "verdadera pistola humeante"
en el escándalo. Más bien, la verdadera carne está dentro de un paquete de código fuente y notas del
programador que se incluyó junto con los correos electrónicos.
Los escépticos dicen que en [el código] hay evidencia de manipulación de datos y otros malos
comportamientos, y dado que este es el código fuente (lógica y matemática), no es algo que pueda
sacarse de contexto como las palabras de una persona en un correo electrónico. poder.
Siento, sin embargo, que hay una buena cantidad de dudas razonables que pueden ser arrojadas por
el código fuente, y que muchas de las afirmaciones más serias que hacen los escépticos sobre el
código y lo que significa para Climategate, realmente no son tan .
¿Cómo se lee este código? ¿Por quién? ¿Cómo podría leerse de manera diferente?
Respuesta de Sheldon Brown el 8 de febrero de 2010 a las 5:24 p.m.

One category of people that read from a critical insider position are collaborators. Working with
others on developing large-scale software projects supposes that there are readers who will be
looking at the code with intense and complicated personal interests including livelihood and
professional status. Coding ethos is often directed towards these collaborations, such that the style
of variable names, the size of functions or the granularity of objects are all subjects of critique and
the means by which underlying thoughts are expressed - the subtext of the code. The grammar of
code can be structured by external authorities - a senior project programmer - or the conventions of
the company. Eccentric coding, which might provide more meaningful cultural readings, is often
expunged from the code by the collaborative processes. While there is personal code, much of what
is running reality is authored by a corporate body. The social schemes by which these bodies are
organized around the development of the immaterial code, including the diversity of physical
presence relationships between authors, would seem to be important.
Reply by Jeremy Douglass on February 8, 2010 at 6:24pm
Your distinction between eccentric “personal” code and collective / corporate “impersonal” code
resonates well with the Debunking Climategate video claim that the idiosyncratic and
unprofessional naming, formatting, and documentation of the code should be considered differently
because it was an individual effort that was never meant to be read outside a very small group.
I like how your suggestion points us towards many other ways of talking about interpersonal code -
for example, the code that results from Pair Programming methodologies, or the code culture that
arises from a collective writing code that will be read or reviewed either by or in light of the views
of one dominant personality - e.g. a high-ranking member of the Linux kernel team, or Steve Jobs.
Reply by Angela Ferraiolo on February 9, 2010 at 8:28am
While there is personal code, much of what is running reality is authored by a corporate body.
This is an interesting point. The corporate body is likely to have a profound effect on code style. For
example: What is the effect of adopting best practices? How are those practices decided and agreed
upon, by whom, and in what ways are they ‘best’? Who is privileged? Who is disadvantaged? What
do nondisclosure agreements do to code styles? How do corporate cultures give rise to the private
languages of proprietary code? (Actually, the rationales programmers give for resisting or accepting
work in proprietary languages is sort of illuminating, isn’t it?) What can we deduce about a culture
from the code it favors and the code styles it creates? For instance, what was happening in our
society at the time programmers began to see object-oriented programming as desirable? What kind
of a society and production environment would favor object-oriented programming over other
approaches or paradigms? How are people who can’t or don’t move on to the new paradigm treated
within the community?
Reply by Evan Buswell on February 9, 2010 at 9:08am
How do corporate cultures give rise to the private languages of proprietary code?
I’m not sure if this is what you meant, but actually “private language” is exactly what I’m thinking
of regarding the “best practices” and other constraints that programmers have from corporate
bodies. Writing within such an environment is like writing with a private language; sure, deviation
would compile, but it’s still ungrammatical. Like to it your ability to parse this sentence. These
traditions are usually bound to particular languages as well, e.g. you would name an object in Java
as “theObject,” but in Perl it would probably be called “the_object.”
In some sense, though, coding is *always* the creation of private languages, insofar as the majority
of function calls, variables, etc. in a large program are going to be things you’ve named yourself. I
think that’s a big reason for open source; a programmer spends all this time making a language and
then they want to talk with other people using that language. They want to build a community that
can read and write in their language.
Una categoría de personas que leen desde una posición privilegiada crítica son colaboradores.
Trabajar con otros en el desarrollo de proyectos de software a gran escala supone que habrá lectores
que mirarán el código con intereses personales intensos y complicados, incluidos los medios de
subsistencia y el estado profesional. El ethos de codificación a menudo se dirige hacia estas
colaboraciones, de modo que el estilo de los nombres variables, el tamaño de las funciones o la
granularidad de los objetos son todos temas de crítica y los medios por los cuales se expresan los
pensamientos subyacentes: el subtexto del código. La gramática del código puede ser estructurada
por autoridades externas, un programador senior de proyectos, o las convenciones de la empresa. La
codificación excéntrica, que podría proporcionar lecturas culturales más significativas, a menudo se
borra del código mediante los procesos de colaboración. Si bien existe un código personal, gran
parte de lo que se está ejecutando en la realidad está escrito por un cuerpo corporativo. Los
esquemas sociales por los cuales estos cuerpos están organizados en torno al desarrollo del código
inmaterial, incluyendo la diversidad de las relaciones de presencia física entre los autores, parecen
ser importantes.
Respuesta de Jeremy Douglass el 8 de febrero de 2010 a las 6:24 p.m.
Su distinción entre el código "personal" excéntrico y el código "impersonal" colectivo / corporativo
resuena bien con el reclamo del video Debunking Climategate de que el nombramiento
idiosincrásico y no profesional, el formateo y la documentación del código deben considerarse de
manera diferente porque fue un esfuerzo individual que fue nunca fue para ser leído fuera de un
grupo muy pequeño.
Me gusta cómo su sugerencia nos señala hacia muchas otras formas de hablar del código
interpersonal, por ejemplo, el código que resulta de las metodologías de programación en pares, o la
cultura del código que surge de un código de escritura colectiva que será leído o revisado por o en
luz de los puntos de vista de una personalidad dominante, por ejemplo un miembro de alto rango del
equipo kernel de Linux, o Steve Jobs.
Respuesta de Angela Ferraiolo el 9 de febrero de 2010 a las 8:28 a.m.
Si bien existe un código personal, gran parte de lo que se está ejecutando en la realidad está escrito
por un cuerpo corporativo.
Este es un punto interesante. Es probable que el cuerpo corporativo tenga un efecto profundo en el
estilo del código. Por ejemplo: ¿Cuál es el efecto de adoptar las mejores prácticas? ¿Cómo se
deciden y acuerdan esas prácticas, por quién y de qué manera son 'las mejores'? ¿Quién es
privilegiado? ¿Quién está en desventaja? ¿Qué hacen los acuerdos de no divulgación para codificar
los estilos? ¿Cómo las culturas corporativas dan lugar a los idiomas privados del código
propietario? (En realidad, los programadores razonantes que dan resistencia o aceptan el trabajo en
lenguajes propietarios es algo esclarecedor, ¿no?) ¿Qué podemos deducir sobre una cultura del
código que favorece y los estilos de código que crea? Por ejemplo, ¿qué estaba pasando en nuestra
sociedad cuando los programadores comenzaron a ver la programación orientada a objetos como
deseable? ¿Qué tipo de sociedad y entorno de producción favorecerían la programación orientada a
objetos sobre otros enfoques o paradigmas? ¿Cómo son las personas que no pueden o no pasan al
nuevo paradigma tratado dentro de la comunidad?
Respuesta de Evan Buswell el 9 de febrero de 2010 a las 9:08 a.m.
¿Cómo las culturas corporativas dan lugar a los idiomas privados del código propietario?
No estoy seguro de si esto es lo que quiso decir, pero en realidad el "lenguaje privado" es
exactamente lo que estoy pensando respecto de las "mejores prácticas" y otras restricciones que los
programadores tienen de los órganos corporativos. Escribir en un entorno así es como escribir con
un lenguaje privado; seguro, la desviación se compilaría, pero aún no es gramatical. Guste su
habilidad para analizar esta oración. Estas tradiciones generalmente también están ligadas a idiomas
particulares, p. nombrarías un objeto en Java como "theObject", pero en Perl probablemente se
llamaría "the_object".
Sin embargo, en cierto sentido, la codificación es * siempre * la creación de lenguajes privados, en
la medida en que la mayoría de las llamadas a funciones, variables, etc. en un programa grande
serán cosas que usted mismo ha nombrado. Creo que esa es una gran razón para el código abierto;
un programador pasa todo este tiempo haciendo un lenguaje y luego quiere hablar con otras
personas que usan ese idioma. Quieren construir una comunidad que pueda leer y escribir en su
idioma.

Also, regarding object-oriented programming, I know that the questions you’re asking have fairly
well-documented answers insofar as the designers of these languages had certain goals in mind, and
they wrote extensively about the social ills that would be cured by OOP. I don’t know too much
about it, but my limited understanding is that the creation of object-oriented languages was a
response to the professionalization of programming. Suddenly, there were really bad programmers
working alongside really good ones, and modularity and encapsulation were needed so that the lead
programmers could tell the poorly-trained programmers: “You go work on this, and I’m not going
to think about how badly coded it is. I know you can’t mess with my code.” Of course, the
genealogy and the present rationale are two different things.
Reply by Jeremy Douglass on February 9, 2010 at 9:47am
On the topic of the difference between the code being legible, idiomatic, or in the house style vs. the
code that compiles and functions but is unconventional or almost illegible - obfuscated
programming contests such as Obfuscated C are one extreme example of this difference. Another
example is the output of decompilers. If you have used a good decompiler, you know that what you
get back is usually functionally similar or identical to the source code that produced the program.
Yet much of the higher level order, structure, and of course the logical connections and emphasis
connoted by naming are stripped away and replaced with a kind of foo bar baz gumbo. Really good
decompilers use a variety of techniques to try to add context and meaning back in, but without
properly named parts and a narrative of functionality, decompiled code often looks like the
machine’s own private language - or just a bag of full of gears.
Reply by David Shepard on February 10, 2010 at 6:00pm
To add to your point, Evan, I think that the audience of code changes because what we think of as
the “progressive” path of programming paradigm production (that alliteration was intentional) isn’t
as linear as we think. What I think of as the major programming paradigms, structured
programming and object-oriented programming, were technologically feasible long before they
were widely adopted. For example, we attribute the invention of structured programming to Edsger
Dijkstra in the mid-1960s, but the language constructs that enable it (like defining functions with
specific input and one exit point, and only access to local variables) were available in the second
draft of the FORTRAN language specification from the mid-1950s, which apparently Dijkstra had
nothing to do with. Object-oriented programming was invented by Alan Kay in the mid-1960s (or
so the story goes), but was not widely adopted until the 1990s, and even the first version of the
MOSAIC web browser was written in non-OOP C. It seems to me that OOP as a house style didn’t
really become that until Java.
The reasons I’ve heard proposed for the rise of OOP is that businesses adopted it to manage
workflow (and thus smooth out the idiosyncrasies of managing large teams of programmers); it was
a tool of management against labor. This is a thesis I’ve partially synthesized from Maurice J.
Black’s Art of Code and Ziv Neeman’s Building Profit-Power into this Electronic Brain, and Linux
devotees who praise structured programming over OOP. One example the devotees’ point to is that
the UNIX/Linux X windows windowing system wasn’t originally object-oriented. Oddly, though,
the Windows 95 API was not object-oriented, nor were later versions until at least 2002. For
example, to create a new window, the programmer calls the CreateWindow() function rather than,
say, instantiating a new WinAPIWindow object. The programmer also must define WinMain() and
WindowProcedure functions in the global namespace, rather than, say, extending a hypothetical
WinApplication class and extending the member WinMain and WindowProcedure methods (I’m
getting this from the following tutorial: http://www.relisoft.com/win32/winnie.html). So suggesting
that it’s a matter of trying to isolate coders from sensitive system functions doesn’t seem like the
real purpose when the company largely blamed for enforcing this separation seems not to have been
particularly keen to enforce the OOP paradigm on application developers.
The technological problem OOP seems to have been most successful in solving is abstraction from
hardware, which is a corporate problem of market reach - that is, having to develop software for
multiple platforms costs more than developing a single version. OOP seems to have reached its
apex with Java, in which programs themselves are classes instantiated by the JVM when it loads.
Java itself was created to free the programmer from having to negotiate the differences between
Windows and Macs, or Sony and RCA DVD players. Microsoft .NET is designed to do the same,
and in .NET, Windows applications do use an OOP API.
Además, con respecto a la programación orientada a objetos, sé que las preguntas que hace tienen
respuestas bastante bien documentadas en la medida en que los diseñadores de estos lenguajes
tenían ciertos objetivos en mente, y escribieron extensamente sobre los males sociales que serían
curados por OOP . No sé demasiado al respecto, pero mi entendimiento limitado es que la creación
de lenguajes orientados a objetos fue una respuesta a la profesionalización de la programación. De
repente, había programadores realmente malos trabajando junto a los realmente buenos, y se
necesitaban modularidad y encapsulamiento para que los programadores principales pudieran
contarles a los programadores mal entrenados: "Van a trabajar en esto, y no voy a pensar en qué tan
mal codificado es. Sé que no puedes meterme con mi código ". Por supuesto, la genealogía y el
razonamiento actual son dos cosas diferentes.
Respuesta de Jeremy Douglass el 9 de febrero de 2010 a las 9:47 a.m.
Sobre el tema de la diferencia entre el código que es legible, idiomático o en el estilo de la casa
versus el código que compila y funciona, pero que es poco convencional o casi ilegible, los
concursos de programación ofuscados como C ofuscado son un ejemplo extremo de esta diferencia.
Otro ejemplo es la salida de descompiladores. Si ha utilizado un descompilador bueno, sabrá que lo
que obtiene generalmente es funcionalmente similar o idéntico al código fuente que produjo el
programa. Sin embargo, gran parte del orden, la estructura y, por supuesto, las conexiones y el
énfasis lógicos connotados por el nombramiento son eliminados y reemplazados por una especie de
foo bar baz gumbo. Los descompiladores realmente buenos usan una variedad de técnicas para
intentar agregar contexto y significado, pero sin las partes apropiadamente nombradas y una
narrativa de funcionalidad, el código decompilado a menudo se parece al lenguaje privado propio
de la máquina, o simplemente una bolsa llena de engranajes.
Respuesta de David Shepard el 10 de febrero de 2010 a las 6:00 p. M.
Para agregar a su punto, Evan, creo que la audiencia de código cambia porque lo que consideramos
como el camino "progresivo" de programación de la producción de paradigmas (que la aliteración
fue intencional) no es tan lineal como creemos. Lo que considero como los principales paradigmas
de programación, programación estructurada y programación orientada a objetos, fueron
tecnológicamente factibles mucho antes de que fueran ampliamente adoptados. Por ejemplo,
atribuimos la invención de la programación estructurada a Edsger Dijkstra a mediados de la década
de 1960, pero las construcciones de lenguaje que lo permiten (como definir funciones con entrada
específica y un punto de salida, y solo acceso a variables locales) estaban disponibles en la segunda
borrador de la especificación del lenguaje FORTRAN de mediados de la década de 1950, que
aparentemente Dijkstra no tuvo nada que ver. La programación orientada a objetos fue inventada
por Alan Kay a mediados de la década de 1960 (o eso dice la historia), pero no fue ampliamente
adoptada hasta la década de 1990, e incluso la primera versión del navegador web MOSAIC fue
escrita en un PC no O. me parece que OOP como un estilo de casa realmente no se convirtió en eso
hasta Java.
Las razones que he escuchado proponer para el aumento de OOP es que las empresas lo adoptaron
para administrar el flujo de trabajo (y así suavizar la idiosincrasia de administrar grandes equipos de
programadores); era una herramienta de gestión contra el trabajo. Esta es una tesis que he
sintetizado en parte de Art of Code de Maurice J. Black y Building Profit-Power de Ziv Neeman en
este Electronic Brain, y devotos de Linux que elogian la programación estructurada sobre OOP. Un
ejemplo que los devotos señalan es que el sistema de ventanas de Windows X de UNIX / Linux no
estaba orientado originalmente a objetos. Curiosamente, sin embargo, la API de Windows 95 no
estaba orientada a objetos, ni tampoco versiones posteriores hasta al menos 2002. Por ejemplo, para
crear una nueva ventana, el programador llama a la función CreateWindow () en lugar de, por
ejemplo, instanciar un nuevo objeto WinAPIWindow . El programador también debe definir las
funciones WinMain () y WindowProcedure en el espacio de nombres global, en lugar de, por
ejemplo, extender una clase WinApplication hipotética y extender los métodos miembros WinMain
y WindowProcedure (obtengo esto del siguiente tutorial: http: // www .relisoft.com / win32 /
winnie.html). Por lo tanto, sugerir que se trata de aislar a los programadores de las funciones del
sistema no parece ser el verdadero propósito cuando la empresa en gran parte culpable por imponer
esta separación parece no haber sido especialmente entusiasta para aplicar el paradigma de OOP en
los desarrolladores de aplicaciones.
El problema tecnológico que OOP parece haber tenido más éxito en resolver es la abstracción del
hardware, que es un problema corporativo de alcance de mercado, es decir, tener que desarrollar
software para plataformas múltiples cuesta más que desarrollar una sola versión. OOP parece haber
llegado a su ápice con Java, en el que los propios programas son clases creadas por la JVM cuando
se carga. La propia Java se creó para liberar al programador de tener que negociar las diferencias
entre Windows y Mac, o los reproductores de DVD Sony y RCA. Microsoft .NET está diseñado
para hacer lo mismo, y en .NET, las aplicaciones de Windows sí usan una API OOP.

But, just because we think of OOP as the dominant programming paradigm now, the creation of a
dominant paradigm generally seems to lead to the rebirth of simpler programming paradigms.
Structured programming was adopted on the System 360 project in the 1960s and 1970s, but most
early PCs came with a BASIC interpreter on a chip, which on IBM clones was later folded into the
software level in MS-DOS. These versions of BASIC, as anyone with affectionate memories of
programming Apple II computers will remember, did not allow structured programming. Structured
BASIC really didn’t become popular until QBasic and Visual Basic, which later came with DOS.
PC applications were written mostly in C, BASIC, or Assembler.
Additionally, Java was supposed to be the major web language, but has lost ground to PHP. PHP’s
innovation (some would say its greatest annoyance) is its ease of use and its reversion to relatively
unstructured programming, which seems technologically regressive. Writing a Java web app
requires extending a base HTTPServlet class at the minimum and enforces strict separation of code,
content, and data, while PHP allows web app development to be done with function calls inlined in
HTML. Up until PHP 5, PHP’s OOP had been fairly weak, and it continues to be much less
developed than Java’s. PHP has become probably the dominant web language because of its
simplicity, and because the alternatives (Java, .NET, Python, and PERL) generally require
significantly more work for even simple apps. Thus, Wordpress, Joomla, Moodle, and most web
software (maybe even Ning?) use PHP. So we have a programming language that is technologically
regressive (a vague concept perhaps, but one that seems useful against the many “evolutionary”
accounts of technology) that wins out because of its simplicity. While OOP is the dominant
paradigm on desktop applications and in some web applications, a language intended to free the
programmer from having to think in those paradigms became popular.
I’m beginning to theorize that programmers seem to envy unstructured programming and therefore
create tools that allow them to write less structured code, like PHP or LINQ. Languages that
simplify a common task by integrating previously-separated concerns (as PHP simplifies web
programming by mixing presentation, logic, and data access) inevitably adopt more complex
features because their simplicity makes more complex tasks possible. Programming language
development seems like an ouroboros: adding more features to manage more complexity eventually
creates a language so unmanageable that an additional layer of abstraction is added which allows
this complexity to be managed more easily.
Reply by Jeremy Douglass on February 11, 2010 at 2:20pm
David,
Thanks for these observations on object-oriented programming. From what little I know about how
various partisans narrate the history of programming languages differently (including contested
origin dates, different generational schemes and family trees, etc.) I’m a bit nervous about broad
claims on programming evolution, for the same reason I’m initially nervous about broad
explanations of, for example, German vs. French aesthetics. I’m not saying such things can never be
useful, I just feel more comfortable when they proceed carefully, driven by specifics.
But to be more specific to your thoughts on OOP: if evolution is a biological metaphor about
fitness, it isn’t clear to me how a web scripting language like PHP could be said to exhibit
evolutionary regression unless it lost OOP features that it once had. Whose regression is also
important. If we are talking about a few internal developers and the languages they had used in their
lives, we might get one story, but if we are talking about public release to a development
community, another. For example, Sun Java was publicly released in May 1995, PHP was released
in June 1995, and many developers in their initial surges were coming to them from all over the
map, including cutting their teeth on programming / scripting for the very first time with them.
A more general idea I take from your points is that we should look to historians of computer
languages to see what useful economic, cultural, political and ethnographic work they have done (or
haven’t done) that connects to the language itself, and how it might be used from or inform a CCS
perspective.
Reply by Max Feinstein on February 11, 2010 at 12:29pm
We have a programming language [PHP] that is technologically regressive (a vague concept
perhaps, but one that seems useful against the many ‘evolutionary’ accounts of technology) that
wins out because of its simplicity.
Pero, solo porque ahora pensamos en OOP como el paradigma de programación dominante, la
creación de un paradigma dominante generalmente parece conducir al renacimiento de paradigmas
de programación más simples. La programación estructurada se adoptó en el proyecto System 360
en las décadas de 1960 y 1970, pero la mayoría de las PC iniciales incluían un intérprete BASIC en
un chip, que en clones de IBM se dobló posteriormente al nivel de software en MS-DOS. Estas
versiones de BASIC, como recordará cualquier persona con recuerdos afectivos de la programación
de las computadoras Apple II, no permitieron la programación estructurada. El BASIC estructurado
realmente no se hizo popular hasta QBasic y Visual Basic, que luego vino con DOS. Las
aplicaciones para PC se escribieron principalmente en C, BASIC o Assembler.
Además, se suponía que Java era el principal lenguaje web, pero ha perdido terreno ante PHP. La
innovación de PHP (algunos dirían que es su mayor molestia) es su facilidad de uso y su reversión a
una programación relativamente desestructurada, que parece tecnológicamente regresiva. Escribir
una aplicación web Java requiere extender al mínimo una clase HTTPServlet base e impone
estrictas separaciones de código, contenido y datos, mientras que PHP permite que el desarrollo de
la aplicación web se realice con llamadas a funciones inlineadas en HTML. Hasta PHP 5, el OOP de
PHP había sido bastante débil, y continúa siendo mucho menos desarrollado que el de Java. PHP se
ha convertido probablemente en el lenguaje web dominante por su simplicidad, y porque las
alternativas (Java, .NET, Python y PERL) generalmente requieren mucho más trabajo incluso para
aplicaciones simples. Por lo tanto, Wordpress, Joomla, Moodle y la mayoría del software web (¿tal
vez incluso Ning?) Usan PHP. Entonces, tenemos un lenguaje de programación que es
tecnológicamente regresivo (un concepto vago tal vez, pero que parece útil en comparación con los
muchos recuentos "evolutivos" de la tecnología) que gana debido a su simplicidad. Mientras que
OOP es el paradigma dominante en aplicaciones de escritorio y en algunas aplicaciones web, un
lenguaje destinado a liberar al programador de tener que pensar en esos paradigmas se hizo popular.
Estoy empezando a teorizar que los programadores parecen envidiar la programación no
estructurada y, por lo tanto, crean herramientas que les permiten escribir código menos estructurado,
como PHP o LINQ. Los lenguajes que simplifican una tarea común al integrar preocupaciones
previamente separadas (ya que PHP simplifica la programación web al mezclar la presentación, la
lógica y el acceso a los datos) inevitablemente adoptan características más complejas porque su
simplicidad posibilita tareas más complejas. El desarrollo del lenguaje de programación parece un
ouroboros: agregar más funciones para administrar más complejidad finalmente crea un lenguaje
tan inmanejable que se agrega una capa adicional de abstracción que permite administrar esta
complejidad más fácilmente.
Respuesta de Jeremy Douglass el 11 de febrero de 2010 a las 2:20 p.m.
David,
Gracias por estas observaciones sobre la programación orientada a objetos. De lo poco que sé sobre
cómo varios partidarios narran la historia de los lenguajes de programación de manera diferente
(incluyendo fechas de origen impugnadas, diferentes esquemas generacionales y árboles
genealógicos, etc.) estoy un poco nervioso acerca de las afirmaciones amplias sobre la evolución de
la programación, por la misma razón Al principio estoy nervioso por las amplias explicaciones de,
por ejemplo, la estética alemana vs. la francesa. No digo que tales cosas nunca puedan ser útiles,
solo me siento más cómodo cuando proceden con cuidado, guiados por detalles.
Pero para ser más específico a sus pensamientos sobre POO: si la evolución es una metáfora
biológica sobre la aptitud, no me queda claro cómo podría decirse que un lenguaje de scripting web
como PHP exhibe regresión evolutiva a menos que pierda las características de OOP que una vez
tuvo . Cuya regresión también es importante. Si hablamos de unos pocos desarrolladores internos y
los idiomas que han utilizado en sus vidas, podríamos obtener una historia, pero si hablamos de
publicación pública para una comunidad de desarrollo, otra. Por ejemplo, Sun Java fue lanzado al
público en mayo de 1995, PHP fue lanzado en junio de 1995, y muchos desarrolladores en sus
oleadas iniciales llegaron a ellos de todo el mapa, incluyendo por primera vez con la programación /
scripting ellos.
Una idea más general que tomo de sus puntos es que debemos mirar a los historiadores de los
lenguajes de computadora para ver qué trabajo económico, cultural, político y etnográfico útil han
realizado (o no han hecho) que se conecta al lenguaje en sí, y cómo se puede usar desde o informar
una perspectiva de CCS.
Respuesta de Max Feinstein el 11 de febrero de 2010 a las 12:29 p.m.
Tenemos un lenguaje de programación [PHP] que es tecnológicamente regresivo (quizás un
concepto vago, pero que parece útil en comparación con los muchos recuentos "evolutivos" de la
tecnología) que gana por su simplicidad.

Perhaps the prevalence of PHP re-writes the definition of technological progress, so the term not
only considers how powerful a language may be (e.g., the presence or absence of comprehensive
OOP support) but also measures its accessibility and easy of use. Instead of using functionality as
the primary gauge for a language’s technological power, we might equally consider the benefits
ushered in by a language’s ability to mix previously independent entities, as you’ve shown that PHP
does with presentation, logic, and data access. Framing languages in this light could add yet another
dimension to CCS by providing new ways to think about programs, or in this case, programming
languages, and how they evolve over time according to the needs and desires of those who work
with code. You’ve already alluded to this idea with the suggestive term “evolutionary accounts,” so
maybe we can expand on it by enumerating the accounts other than technological progress. Such an
exercise might be beneficial for the CCSWG, especially in the context of code critiques.
I’d also like to shed some more light on the distinction between personal and corporate code.
Sheldon brought up this topic when he said “eccentric coding, which might provide more
meaningful cultural readings, is often expunged from the code by the collaborative processes. While
there is personal code, much of what is running reality is authored by a corporate body.” I suggest
that the distinction between eccentric and corporate is less clear than what has been noted already.
For example, in my list of candidates for code critiques, I’ve included a portion of the Windows NT
source code, which was leaked from Microsoft in 2004. The leak gained notoriety not only because
of the proprietary nature of Microsoft code (and most other corporate code), but also because of the
eccentric commentary woven throughout the entire piece of software. Take a peak at this kuro5hin
article that critically reads segments of the leaked code. It’d be great to get our hands on more
corporate code, but that seems to be a practically unattainable ideal.
Reply by Andrew Davis on February 23, 2010 at 3:17pm
It is rarely true that a corporate dialect is somehow a community wisdom or summation of best
practices within a corporation. Dialects rarely evolve within a corporation in my experience. The
ever-present risk factor for a change of dialect inserting bugs or the additional work for already late
software developers just doesn’t let large dialect changes make it over the code critic hill.
In a meager sampling of 6 corporations, all corporate dialects were the work of one or two members
of the first team of engineers in the first month of a corporation or major new project. I was ‘that
guy’ at 3 of those 6 corporations. I write down a list of best practices, garnered from the previous N-
1 corporations and that becomes the corporate standard. Sure, if it had been garbage, the
engineering code critics would have done their job and buried the initiative. But the critics rarely
added content to the dialect themselves.
Although this fiat style might be assumed, it rarely works out as the reason code in a corporation
looks homogeneous. Very few engineers look at a coding guide, style guide, or dialect direction at
any point in their first 6 months of a new job. Generally code is stolen, borrowed, referenced, lib-
ified, etc. So, the coding style of the most prolific programmer quickly becomes the de facto
standard. So, the first set of engineers on a project ‘win’ and get to lay down fresh tracks of code in
once empty files as well as setting the standard for a corporate dialect.
Reply by Mark Marino on February 12, 2010 at 11:44am
David,
Have you read Wolfgang Hagen’s “The Style of Sources,” from Wendy Chun and Thomas Keenan’s
edited volume, old media, new media? It seems like a text that would provide some fodder for this
line of argument. Hagen (as translated by Peter Krapp) sums up his thesis as:
for decades, the arche-structure of the von Neumann machine did not reveal that this machine
would be more than a new calculator, more than a mighty tool for mental labor, namely a new
communications medium [which I believe Lev picks up in his new manuscript]. The development
of FORTRAN demonstrates all too clearly how the communication-imperative was called on the
machine from all sides. The imperative call obviously could not be detected in the arche-structure of
the machine itself. It grew out of the Cold War, out of the economy, out of the organization of labor,
perhaps out of the primitive numeric seduction the machines exerted, out of the numbers game, out
of a game with digits, placeholders, fort/da mechanisms, and the whole quasi-linguistic quid pro
quo of the interior surface of all these source. (173)
Tal vez la prevalencia de PHP vuelve a escribir la definición de progreso tecnológico, por lo que el
término no solo considera qué tan poderoso puede ser un lenguaje (por ejemplo, la presencia o
ausencia de soporte OOP integral), sino que también mide su accesibilidad y facilidad de uso. En
lugar de utilizar la funcionalidad como indicador principal del poder tecnológico de un idioma,
también podríamos considerar los beneficios que la habilidad de un idioma tiene para mezclar
entidades previamente independientes, como lo ha demostrado con la presentación, la lógica y el
acceso a los datos. Enmarcar los lenguajes desde esta perspectiva podría agregar una nueva
dimensión a CCS al proporcionar nuevas formas de pensar acerca de los programas, o en este caso,
los lenguajes de programación, y cómo evolucionan con el tiempo según las necesidades y deseos
de quienes trabajan con el código. Ya ha aludido a esta idea con el sugerente término "cuentas
evolutivas", por lo que tal vez podamos ampliarlo enumerando las cuentas distintas del progreso
tecnológico. Tal ejercicio podría ser beneficioso para el CCSWG, especialmente en el contexto de
las críticas del código.
También me gustaría arrojar más luz sobre la distinción entre el código personal y corporativo.
Sheldon sacó a relucir este tema cuando dijo que "la codificación excéntrica, que podría
proporcionar lecturas culturales más significativas, a menudo es borrada del código por los procesos
de colaboración. Si bien existe un código personal, gran parte de lo que está sucediendo en la
realidad está escrito por un cuerpo corporativo. "Sugiero que la distinción entre excéntrico y
corporativo es menos clara que lo que ya se ha señalado. Por ejemplo, en mi lista de candidatos para
críticas de código, he incluido una parte del código fuente de Windows NT, que se filtró de
Microsoft en 2004. La filtración ganó notoriedad no solo debido a la naturaleza patentada del
código de Microsoft (y la mayoría otro código corporativo), pero también debido a los comentarios
excéntricos tejidos en toda la pieza de software. Haga un pico en este artículo kuro5hin que lee
críticamente segmentos del código filtrado. Sería genial tener en nuestras manos más código
corporativo, pero parece ser un ideal prácticamente inalcanzable.
Respuesta de Andrew Davis el 23 de febrero de 2010 a las 3:17 p.m.
Rara vez es cierto que un dialecto corporativo sea de alguna manera una sabiduría de la comunidad
o una suma de las mejores prácticas dentro de una corporación. Los dialectos raramente
evolucionan dentro de una corporación en mi experiencia. El factor de riesgo omnipresente para un
cambio de dialecto que inserta errores o el trabajo adicional para desarrolladores de software que ya
están avanzados no permite que los grandes cambios dialectales superen el límite crítico del código.
En una muestra exigua de 6 corporaciones, todos los dialectos corporativos fueron obra de uno o
dos miembros del primer equipo de ingenieros en el primer mes de una corporación o un nuevo
proyecto importante. Yo era 'ese tipo' en 3 de esas 6 corporaciones. Escribo una lista de mejores
prácticas, obtenida de las anteriores corporaciones N-1 y que se convierte en el estándar
corporativo. Claro, si hubiera sido basura, los críticos del código de ingeniería habrían hecho su
trabajo y enterrado la iniciativa. Pero los críticos rara vez agregaron contenido al dialecto en sí
mismos.
Aunque este estilo fiduciario podría suponerse, rara vez funciona ya que el código de razón en una
corporación parece homogéneo. Muy pocos ingenieros miran una guía de codificación, una guía de
estilo o una dirección dialectal en cualquier momento de los primeros 6 meses de un nuevo trabajo.
En general, el código es robado, prestado, referenciado, libido, etc. Por lo tanto, el estilo de
programación del programador más prolífico se convierte rápidamente en el estándar de facto. Por
lo tanto, el primer grupo de ingenieros en un proyecto 'gana' y consigue establecer nuevas pistas de
código en archivos una vez vacíos, además de establecer el estándar para un dialecto corporativo.
Respuesta de Mark Marino el 12 de febrero de 2010 a las 11:44 a.m.
David,
¿Has leído "El estilo de las fuentes" de Wolfgang Hagen, del volumen editado de Wendy Chun y
Thomas Keenan, viejos medios, nuevos medios? Parece un texto que proporcionaría algo de forraje
para esta línea argumental. Hagen (traducido por Peter Krapp) resume su tesis como:
durante décadas, la arche-estructura de la máquina de von Neumann no reveló que esta máquina
sería más que una nueva calculadora, más que una poderosa herramienta para el trabajo mental, es
decir, un nuevo medio de comunicación [que creo que Lev recoge en su nuevo manuscrito]. El
desarrollo de FORTRAN demuestra con demasiada claridad cómo se invocó el imperativo de
comunicación en la máquina desde todos los lados. La llamada imperativa obviamente no pudo
detectarse en la arche-estructura de la máquina misma. Surgió de la Guerra Fría, fuera de la
economía, fuera de la organización del trabajo, quizás fuera de la seducción numérica primitiva que
las máquinas ejercían, fuera del juego de los números, de un juego con dígitos, marcadores de
posición, mecanismos fort / da , y todo el quid pro quo cuasi-lingüístico de la superficie interior de
todas estas fuentes. (173)

Reply by Julie Meloni on February 14, 2010 at 10:44am

Framing languages in this light could add yet another dimension to CCS by providing new ways to
think about programs, or in this case, programming languages, and how they evolve over time
according to the needs and desires of those who work with code.
I like this possible dimension of study, and to support that I offer some information about the
development climate specific to PHP and its use in industry from its early years. Bear in mind that
these are generalizations based on a) my involvement (mostly as a lurker) on the PHP-related
mailing lists from 1999 until about 2003, and then b) my experiences as a consultant in enterprise
product development from 2002 through the present.
As Jeremy notes below, Java was released in 1995 and PHP also in 1995. But it would be a good
few years before PHP really gained any traction - 1998 or so. Classic ASP was released in 1996, had
a revision in 1997, and settled/stagnated in 2000. JSP popped on the scene in 1999, specifically as
an answer to PHP and ASP, which even in their nascent stages were seen as game-changers.
But what was the question? The question, I believe, was how best to leverage people who were
“coming to them from all over the map, including cutting their teeth on programming / scripting for
the very first time with them” - as Jeremy noted below. I completely agree with this statement. The
cultural context for the development of these programming languages - or, more specifically, the
acceptance of “technologically regressive” languages (as one could easily argue PHP, ASP, and JSP
were, to varying degrees and for different reasons) - had everything to do with the rush to put in
place anything vaguely resembling a dynamic interface through which users could do…
something…(generate content, etc) and the corporation behind the interface could collect…
something (data, data, and more data).
For example, when responding to a RFP, my company would often produce two: the way we would
create a product in a perfect world (full of OO goodness) and the way we would create the product
in fairly procedural, loose, easily remixed code - not buggy, and certainly fast & secure, but not “the
best” textbook way to produce software. It was rare indeed that the former won out over the latter.
That is not to say that you can’t create a lovely, flexible, OO application quickly. Of course you can,
with the right resources. But a lot of the available resources (e.g. new hires filling the ranks) were
just cutting teeth on any sort of programming, and the natural move was to procedural programming
and scaffolding knowledge before being able to conceptualize and produce OO code. But, then,
many corporate cultures allowed them to stay in the procedural/loose comfort zone, and so this type
of application development was perpetuated.
Reply by Andrew Davis on February 23, 2010 at 3:53pm
http://www.joelonsoftware.com/articles/LeakyAbstractions.html
What if language lifetime were about the leaks in the abstraction a language creates? How many
leaks and how to learn them, code around them, or code through them?
For instance, Java has JNI as a kind of a “oops we forgot about that” way of dropping the developer
out of OO mode into a raw, underbelly of Java way of adding functionality when the Java OO
abstraction leaks. Now, the problem with JNI is that it isn’t write-once-run-anywhere; it isn’t cross
JVM compatible, etc. So it so totally breaks your Java app that you have to give up the very things
you picked the language for in the first place!
Now, PHP…can you use it like OO, yeah. Can you get at the underbelly and code around it if the
abstraction fails, definitely.
So if language acquisition is viewed as the sum of the language and the abstraction failures, perhaps
Java is actually significantly more complex than PHP to acquire and thus the long term trend toward
PHP?
Nothing more than economic opportunity cost. At first glance.
Reply by Gregory Bringman on February 8, 2010 at 7:04pm
In regard to the need to move beyond “The Two Cultures” with the examples you give of code
reading in everyday life, if I remember C.P. Snow correctly, it seems he calls (in The Two Cultures)
for literary artists and scientists to unite to solve common problems of the industrial revolution,
what some now consider as the information “revolution”. So in the inaugural moment of his Rede
lecture and of the so-called “Third Culture” (if we link directly back to Snow), technology is the site
for this problem solving/collaboration. So I wonder then, from Snow, if working with artifacts of
code or solving any technical problem does not obligate us to reach a level of “third culture”
interdisciplinarity in which we indeed move beyond “The Two Cultures”. That is, contemporary
technological conditions strictly imply this discursive position (as your examples attest…)
Respuesta de Julie Meloni el 14 de febrero de 2010 a las 10:44 a.m.
Enmarcar los lenguajes desde esta perspectiva podría agregar una nueva dimensión a CCS al
proporcionar nuevas formas de pensar acerca de los programas, o en este caso, los lenguajes de
programación, y cómo evolucionan con el tiempo según las necesidades y deseos de quienes
trabajan con el código.
Me gusta esta posible dimensión de estudio, y para apoyarlo ofrezco información sobre el clima de
desarrollo específico de PHP y su uso en la industria desde sus primeros años. Tenga en cuenta que
estas son generalizaciones basadas en a) mi participación (principalmente como lurker) en las listas
de correo relacionadas con PHP desde 1999 hasta alrededor de 2003, y luego b) mis experiencias
como consultor en el desarrollo de productos empresariales desde 2002 hasta el presente .
Como Jeremy señala a continuación, Java se lanzó en 1995 y PHP también en 1995. Pero pasarían
algunos años antes de que PHP realmente ganara algo de tracción: 1998 más o menos. ASP clásico
fue lanzado en 1996, tuvo una revisión en 1997, y se asentó / se estancó en 2000. JSP apareció en la
escena en 1999, específicamente como una respuesta a PHP y ASP, que incluso en sus etapas
iniciales fueron vistos como cambiadores de juego.
Pero, ¿cuál fue la pregunta? La pregunta, creo, fue cuál era la mejor forma de aprovechar a las
personas que "acudían a ellos de todo el mapa, incluyendo por primera vez aprender a programar /
escribir guiones", como lo señaló Jeremy a continuación. Estoy completamente de acuerdo con esta
afirmación. El contexto cultural para el desarrollo de estos lenguajes de programación, o más
específicamente, la aceptación de lenguajes "tecnológicamente regresivos" (como se podría
argumentar fácilmente que PHP, ASP y JSP eran, en diversos grados y por diferentes razones) tenían
todo para hacer con el apuro de poner en su lugar algo que se asemeja vagamente a una interfaz
dinámica a través del cual los usuarios podrían hacer ... algo ... (generar contenido, etc.) y la
corporación detrás de la interfaz podría recoger ... algo (datos, datos y más datos).
Por ejemplo, cuando respondía a una RFP, mi empresa a menudo producía dos: la forma en que
creábamos un producto en un mundo perfecto (lleno de bondad OO) y la forma en que creábamos el
producto en un código bastante sencillo, fácil de mezclar y de nuevo procedimiento - No es fallado,
y ciertamente es rápido y seguro, pero no es la "mejor" forma de libros de texto para producir
software. De hecho, era raro que el primero ganara sobre el segundo.
Eso no quiere decir que no pueda crear una aplicación OO adorable y flexible rápidamente. Por
supuesto que puedes, con los recursos adecuados. Pero muchos de los recursos disponibles (por
ejemplo, nuevas contrataciones que llenan los rangos) acababan de cortar los dientes en cualquier
tipo de programación, y el movimiento natural era la programación de procedimientos y el
conocimiento de andamios antes de poder conceptualizar y producir código OO. Pero, entonces,
muchas culturas corporativas les permitieron permanecer en la zona de comodidad procedimental /
suelta, y así este tipo de desarrollo de aplicaciones se perpetúa.
Respuesta de Andrew Davis el 23 de febrero de 2010 a las 3:53 p.m.
http://www.joelonsoftware.com/articles/LeakyAbstractions.html
¿Y si la vida del lenguaje fuera sobre las filtraciones en la abstracción que crea un lenguaje?
¿Cuántas filtraciones y cómo aprenderlas, codificarlas o codificarlas?
Por ejemplo, Java tiene JNI como una especie de "oops que nos olvidamos de eso", que consiste en
dejar al desarrollador fuera del modo OO en una forma cruda y vulnerable de Java para agregar
funcionalidad cuando se pierde la abstracción de Java OO. Ahora, el problema con JNI es que no es
write-once-run-anywhere; no es compatible con JVM cruzado, etc. ¡De modo que rompe tu
aplicación Java de forma tan absoluta que tienes que renunciar a las mismas cosas para las que
elegiste el idioma!
Ahora, PHP ... puedes usarlo como OO, sí. ¿Puedes obtener información sobre el vientre y el código
a su alrededor si la abstracción falla, definitivamente?
Entonces, si la adquisición del lenguaje se ve como la suma del lenguaje y las fallas de abstracción,
¿tal vez Java es mucho más compleja que PHP para adquirir y, por lo tanto, la tendencia a largo
plazo hacia PHP?
Nada más que un costo de oportunidad económico. A primera vista.
Respuesta de Gregory Bringman el 8 de febrero de 2010 a las 7:04 p. M.
En lo que respecta a la necesidad de ir más allá de "Las dos culturas" con los ejemplos que das de la
lectura de códigos en la vida cotidiana, si recuerdo C.P. Snow correctamente, parece que él llama
(en The Two Cultures) para que los artistas literarios y científicos se unan para resolver problemas
comunes de la revolución industrial, lo que algunos consideran ahora como la información
"revolución". Entonces, en el momento inaugural de su conferencia Rede y de la llamada "Tercera
Cultura" (si vinculamos directamente a Snow), la tecnología es el sitio para esta solución de
problemas / colaboración. Así que me pregunto entonces, desde Snow, si trabajar con artefactos de
código o resolver cualquier problema técnico no nos obliga a alcanzar un nivel de
interdisciplinariedad de "tercera cultura" en el que realmente vamos más allá de "Las dos culturas".
Es decir, las condiciones tecnológicas contemporáneas implican estrictamente esta posición
discursiva (como lo atestiguan sus ejemplos ...)

Reply by Jeremy Douglass on February 9, 2010 at 8:46am

I believe (but haven’t yet checked) that Snow introduced the Third Culture concept after his 1959
lecture - in the 1964 second edition of his book, The Two Cultures and a Second Look. There is a
variety of Third Culture literature out there that might be relevant to that, as well as some two-
culture-reconciliation literature, like Gould’s The Hedgehog, The Fox, and the Magister’s Pox.
Various parties weighing in on the debate have either claimed the two-culture distinction was a)
fundamental, b) overblown, or c) fundamental and overblown.
I very much like your point that we are both part of and beyond this conversation by necessity, due
to the way we are technically and historically situated. My own hope in mentioning “two cultures”
at all was not to start a pitched battle, but to signal the way we could be mindful of past Us vs.
Them narratives and so move beyond them. Personally, I’d rather not call it a Third Culture - I’m
more of the mindset that there are a multitude of cultures at the outset.
One final point I should make regarding Snow is that I tried to sneak it in without really taking the
time to talk about the way that the ideal programmer and ideal cultural critic that I see as CCS straw
men both do and don‘t map against the ideal scientist and ideal humanist that Snow and others have
discussed. To my mind, some of this has to do with the difference between science culture,
(software) engineering culture, and craft culture. Other differences relate to the huge changes in the
methods of criticism from the 1930s stereotype of high criticism that Snow sees as the dominant
paradigm in the late 1950s - looking at the recent emergence (for example) of Media Specific
Analysis and then Digital Forensics, it isn’t clear to me that a distinction between hermeneutics and
the scientific method is actually a useful way of describing what people are doing.
Reply by Mark Marino on February 8, 2010 at 11:38pm
Jeremy,
What a wonderful piece to bridge the gaps that I opened, unintentionally, in Week 1. Certainly a
provocative and prodigious post, as only you can generate.
Well, let me dive right in. I love this idea of code reading “in the wild.” While folks dig through
their bookmarks for examples…
Following your lead with Climate Gate and thinking of related -gates, let me offer this little
flashback to #amazonfail. This was the moment when GLBT books seemed to be mysteriously
slipping in their sales rank on the online booksales giant, where “location, location, location” is
everything. In this post from Avi Rappoport, “Amazonfail: How Metadata and Sex Broke the
Amazon Book Search,” he tries to reconstruct the organization of the database. In one passage, he
offers,
From this and other evidence, I believe there is a flag on each category, defining whether it is adult
or nonadult. When a category is flagged adult, the system automatically suppresses the sales rank
and the main search results for all items in that category. This is supported by the observation that
many Kindle editions have a separate listing (under the Kindle category) and so some books
delisted in book format were still available in Kindle format, and vice versa.
Later he writes:
“In this day and age of Cloud Computing, SaaS, and web applications, data is becoming
increasingly just as critical as code.”
This is a valuable example of someone trying to discern the operations of the code upon its data, or
rather how that data is organized. (I don’t think we need to develop critical database studies to
include such reflections.)
More importantly, I think this question speaks to one concern brought up in the CCSWG “code
critiques” forum by Aymeric Mansoux 1asking,
* Should critical code study limits itself to FLOSS, one-liners, abandoned material, public domain
or fair-use resources?
* What kind of strategies can we come up with to provide a critical code study … without any
code?
Sometimes, when we don’t have the smoking or abstaining-from-smoking gun, we spend our time
trying to derive the operation of the code, reading it from its effects. I believe you yourself have
somewhere referred to this as the “implied code.” In any event, #amazonfail represents a moment
when the twitterati and blogging circles began to spiral around questions about how information
was being processed by a particular piece of softwhere, speculating critically on how it might be
negatively impacting real-world conditions.
Again, no real code here, but does this relate to what you are describing?
Respuesta de Jeremy Douglass el 9 de febrero de 2010 a las 8:46 a.m.
Creo (pero aún no lo he comprobado) que Snow introdujo el concepto de la Tercera Cultura después
de su conferencia de 1959 - en la segunda edición de 1964 de su libro, Las dos culturas y una
segunda mirada. Existe una gran variedad de literatura de la Tercera Cultura que podría ser
relevante para eso, así como también literatura de reconciliación de dos culturas, como The
Hedgehog, The Fox y Magister's Pox de Gould. Varias partes que intervienen en el debate han
afirmado que la distinción entre dos culturas era a) fundamental, b) exagerada, o c) fundamental y
exagerada.
Me gusta mucho su punto de que ambos somos parte y más allá de esta conversación por necesidad,
debido a la forma en que estamos histórica y técnicamente situados. Mi propia esperanza al
mencionar "dos culturas" en absoluto fue no comenzar una batalla campal, sino señalar la forma en
que podríamos ser conscientes de las narrativas pasadas de Us vs. Them y así ir más allá de ellas.
Personalmente, prefiero no llamarlo una Tercera Cultura. Tengo más la mentalidad de que hay una
multitud de culturas desde el principio.
Un punto final que debo hacer con respecto a Snow es que intenté colarlo sin tomarme el tiempo
para hablar sobre la forma en que el programador ideal y el crítico cultural ideal que veo como
pajilleros CCS hacen y no mapean contra el científico ideal y humanista ideal que Snow y otros han
discutido. En mi opinión, parte de esto tiene que ver con la diferencia entre la cultura de la ciencia,
la cultura de la ingeniería (de software) y la cultura artesanal. Otras diferencias se relacionan con
los enormes cambios en los métodos de crítica del estereotipo de alta crítica de 1930 que Snow ve
como el paradigma dominante a fines de la década de 1950, mirando la reciente aparición (por
ejemplo) de Análisis Específico de Medios y luego Digital Forensics, No tengo claro que una
distinción entre la hermenéutica y el método científico es en realidad una forma útil de describir lo
que las personas están haciendo.
Respuesta de Mark Marino el 8 de febrero de 2010 a las 11:38 p.m.
Jeremy,
Qué pieza tan maravillosa para cerrar las brechas que abrí, involuntariamente, en la Semana 1.
Ciertamente una publicación provocadora y prodigiosa, como solo tú puedes generar.
Bueno, permítanme profundizar. Me encanta esta idea de leer códigos "en la naturaleza". Mientras
que la gente hojea sus marcadores para ver ejemplos ...
Siguiendo su ejemplo con Climate Gate y pensando en las puertas relacionadas, permítanme ofrecer
este pequeño flashback a #amazonfail. Este fue el momento en que los libros GLBT parecían
deslizarse misteriosamente en su rango de ventas en el gigante de ventas de libros en línea, donde
"ubicación, ubicación, ubicación" es todo. En esta publicación de Avi Rappoport, "Amazonfail:
Cómo Metadata y Sex Broke the Amazon Book Search", intenta reconstruir la organización de la
base de datos. En un pasaje, él ofrece,
A partir de esta y otras pruebas, creo que hay una bandera en cada categoría, que define si es adulta
o no adulta. Cuando una categoría se marca como adulta, el sistema suprime automáticamente el
rango de ventas y los principales resultados de búsqueda para todos los artículos en esa categoría.
Esto es respaldado por la observación de que muchas ediciones de Kindle tienen una lista separada
(en la categoría de Kindle), por lo que algunos libros de la lista del libro en formato de libro todavía
estaban disponibles en formato Kindle, y viceversa.
Más tarde él escribe:
"En esta era de Cloud Computing, SaaS y aplicaciones web, los datos se vuelven cada vez más tan
críticos como el código".
Este es un valioso ejemplo de alguien que intenta discernir las operaciones del código sobre sus
datos, o más bien cómo se organizan esos datos. (No creo que necesitemos desarrollar estudios
críticos de bases de datos para incluir tales reflexiones).
Más importante aún, creo que esta pregunta se refiere a una preocupación planteada en el foro de
"críticas del código" del CCSWG por Aymeric Mansoux, preguntando:
* ¿Debería el estudio del código crítico limitarse a FLOSS, líneas simples, material abandonado,
dominio público o recursos de uso justo?
* ¿Qué tipo de estrategias podemos idear para proporcionar un estudio de código crítico ... sin
ningún código?
A veces, cuando no tenemos el arma para fumar o abstenernos de fumar, nos tomamos nuestro
tiempo tratando de deducir el funcionamiento del código, leyéndolo de sus efectos. Creo que usted
mismo ha referido a esto como el "código implícito". En cualquier caso, #amazonfail representa un
momento en que los círculos de twitterati y blogging comenzaron a girar en torno a preguntas sobre
cómo la información estaba siendo procesada por una pieza particular de softwhere, especulando
críticamente sobre cómo podría tener un impacto negativo en las condiciones del mundo real.
Nuevamente, no hay un código real aquí, pero, ¿se relaciona esto con lo que está describiendo?

Reply by Jeremy Douglass on February 9, 2010 at 10:43am

Mark,
I certainly find the “#amazonfail” incident to be relevant as an example of public collective
interpretation, and I find it relevant not least because I have very little invested in policing the
border between Software Studies and Code Studies.
Thanks for pointing out Aymeric Mansoux’s “Critical Black Box Code Study” provocation, and for
making the connection to the concept of “implied code,” which I originally defined as “an
interactor’s mental model of the operational logic of the interactive work.”
The emergent understanding of any “black box” software process is about constructing and then
critiquing a hypothetical or implied code, rather than dealing with the code itself. In the case of
#amazonfail, constructing an implied code (along with implied programmers and management) is
certainly what people did. Importantly, they did this in a variety of ways: through attempts at
applying the scientific method, contextual inference, and wild speculation.
Of course, this performance of public software studies in #amazonfail was different from the CRU
Climategate debate of public code studies precisely because there was no code. Database
architecture is code, as are views and server side scripts. If we had a snapshot of these things, the
data, and the internal editorial culture, we could really do code studies.
It is my belief that authors on blacklisted gender and sexuality topics were correct to react with
#bugmyass and with more general paranoia. Without knowing how they were marked by the system
before, or how that has changed, there was no concrete vocabulary to engage Amazon on reform. At
the same time, I think people pointing to “there is no perfect cataloging” or “corporations are cussed
about PR” misunderstand that there was probably also a fundamental technosocial conflict here. I’d
venture that, as with Google’s PageRank, Amazon’s Sales Rank developers are working partly in an
antagonistic relationship with the many cultural constituents who seek to exploit and manipulate the
algorithm for their own benefit. If that is the case, our preferred stance for Amazon (perfect
transparency) isn’t possible - or at least they believe it isn’t possible, and there are complex internal
and external reasons for that belief that could be the subject of another critique in relationship to the
Sales Rank algorithm itself.
So, to sum up:
- Yes, I find #amazonfail an extremely relevant example of feral software studies.
- No, I don’t think it is code studies.
- But, I hope it becomes code studies someday - if anyone can ever get access, that would be a great
article.
Reply by Max Feinstein on February 12, 2010 at 1:28pm
I’ve been searching for computer science publications that are concerned with the philosophical
aspects of programming. I found a number of interesting topics, and while they might not be good
candidates for bibliographic entries, I think they’re good leads and could help us find CCS-
appropriate texts for analysis:
Basics of Unix Philosophy
The introduction offers a brief overview of Unix philosophy:
The Unix philosophy (like successful folk traditions in other engineering disciplines) is bottom-up,
not top-down. It is pragmatic and grounded in experience. It is not to be found in official methods
and standards, but rather in the implicit half-reflexive knowledge, the expertise that the Unix culture
transmits. It encourages a sense of proportion and skepticism - and shows both by having a sense of
(often subversive) humor.
Such topics as these are covered in the article:
Rule of Clarity: Clarity is better than cleverness.
Rule of Simplicity: Design for simplicity; add complexity only where you must.
Rule of Transparency: Design for visibility to make inspection and debugging easier.
Rule of Least Surprise: In interface design, always do the least surprising thing.
This article links to an extensive collection of lessons on Unix philosophy. In that collection is a
page on the history of Unix + OOP, which has particular relevance to this discussion in the Week 2
thread.
Another notable page from the lessons on philosophy is The Importance of Being Textual, which
contains language reminiscent of some discussions on the CCSWG:
Pipes and sockets will pass binary data as well as text. But there are good reasons the examples
we’ll see in Chapter 7 are textual: reasons that hark back to Doug McIlroy’s advice quoted in
Chapter 1. Text streams are a valuable universal format because they’re easy for human beings to
read, write, and edit without specialized tools. These formats are (or can be designed to be)
transparent. (Emphasis mine)
Respuesta de Jeremy Douglass el 9 de febrero de 2010 a las 10:43 a.m.
Marca,
Ciertamente encuentro que el incidente "#amazonfail" es relevante como un ejemplo de
interpretación colectiva pública, y me parece relevante, no menos importante, porque he invertido
muy poco en vigilar el límite entre los estudios de software y los estudios de código.
Gracias por señalar la provocación de "Critical Black Code Code Study" de Aymeric Mansoux, y
por hacer la conexión con el concepto de "código implícito", que originalmente definí como "el
modelo mental de un interactor de la lógica operativa del trabajo interactivo".
La comprensión emergente de cualquier proceso de software de "caja negra" consiste en construir y
luego criticar un código hipotético o implícito, en lugar de tratar con el código en sí mismo. En el
caso de #amazonfail, la construcción de un código implícito (junto con los programadores y la
administración implícitos) es ciertamente lo que hicieron las personas. Es importante destacar que
lo hicieron de diversas maneras: mediante intentos de aplicar el método científico, la inferencia
contextual y la especulación salvaje.
Por supuesto, este rendimiento de los estudios de software público en #amazonfail fue diferente del
debate CRU Climategate sobre los estudios de código público, precisamente porque no había
código. La arquitectura de la base de datos es código, al igual que las vistas y los scripts del lado del
servidor. Si tuviéramos una instantánea de estas cosas, los datos y la cultura editorial interna,
podríamos hacer estudios de código.
Es mi creencia que los autores en los temas de género y sexualidad incluidos en la lista negra
reaccionaron correctamente con #bugmyass y con una paranoia más general. Sin saber cómo
estaban marcados por el sistema antes, o cómo ha cambiado eso, no había un vocabulario concreto
para involucrar a Amazon en la reforma. Al mismo tiempo, creo que las personas que señalan que
"no existe una catalogación perfecta" o que "las corporaciones son maldecidas por las relaciones
públicas" malinterpretan que probablemente haya también un conflicto tecnosocial fundamental
aquí. Me atrevería a decir que, al igual que con el PageRank de Google, los desarrolladores de
rangos de ventas de Amazon están trabajando en parte en una relación antagónica con los
numerosos componentes culturales que buscan explotar y manipular el algoritmo para su propio
beneficio. Si ese es el caso, nuestra posición preferida para Amazon (transparencia perfecta) no es
posible, o al menos ellos creen que no es posible, y existen razones internas y externas complejas
para esa creencia que podrían ser el tema de otra crítica. en relación con el algoritmo de rango de
ventas en sí.
Así que para resumir:
- Sí, creo que #amazonfail es un ejemplo extremadamente relevante de estudios de software salvaje.
- No, no creo que sean estudios de código.
- Pero, espero que algún día se convierta en estudios de código. Si alguien puede acceder, sería un
gran artículo.
Respuesta de Max Feinstein el 12 de febrero de 2010 a la 1:28 p. M.
He estado buscando publicaciones de informática relacionadas con los aspectos filosóficos de la
programación. Encontré una serie de temas interesantes, y aunque podrían no ser buenos candidatos
para las entradas bibliográficas, creo que son buenas pistas y podrían ayudarnos a encontrar textos
apropiados para el CCS para el análisis:
Conceptos básicos de la filosofía de Unix
La introducción ofrece una breve descripción de la filosofía de Unix:
La filosofía de Unix (como las tradiciones populares exitosas en otras disciplinas de ingeniería) es
de abajo arriba, no de arriba hacia abajo. Es pragmático y está basado en la experiencia. No se
encuentra en los métodos y estándares oficiales, sino más bien en el conocimiento semirreflexivo
implícito, la experiencia que transmite la cultura de Unix. Alienta un sentido de proporción y
escepticismo, y muestra ambos al tener un sentido del humor (a menudo subversivo).
Tales temas como estos están cubiertos en el artículo:
Regla de claridad: la claridad es mejor que la inteligencia.
Rule of Simplicity: diseño para simplicidad; agregue complejidad solo donde debe.
Regla de transparencia: Diseñe para la visibilidad para facilitar la inspección y la eliminación de
fallas.
Regla de la menor sorpresa: en el diseño de la interfaz, siempre haz lo menos sorprendente.
Este artículo enlaza con una extensa colección de lecciones sobre la filosofía de Unix. En esa
colección hay una página sobre la historia de Unix + OOP, que tiene una relevancia particular para
esta discusión en el hilo de la Semana 2.
Otra página notable de las lecciones sobre filosofía es La importancia de ser textual, que contiene
un lenguaje que recuerda algunas discusiones sobre el CCSWG:
Las tuberías y los zócalos pasarán datos binarios y texto. Pero hay buenas razones para que los
ejemplos que veamos en el Capítulo 7 sean textuales: razones que hacen referencia al consejo de
Doug McIlroy citado en el Capítulo 1. Las transmisiones de texto son un formato universal valioso
porque a los seres humanos les resulta fácil leer, escribir, y editar sin herramientas especializadas.
Estos formatos son (o pueden diseñarse para ser) transparentes. (Énfasis mío)

Another search I’ve been trying is “computer code” in various news archives. I didn’t have much
luck in historical databases on Proquest or JSTOR, but Google’s news archive has yielded some
promising results. The search term I started with is “computer code.” The search even provides a
graphical analysis of the distribution of articles over time:

(This graph represents nearly 14,000 news articles.)

A 1991 New York Magazine article about “the many tongues of computer code” reminds me of the
discussion on a random maze program that’s currently taking place in code critiques.
A 2004 Herald Tribune article reports on how computer code led authorities to a suspect in a murder
case in Kansas City.
Has any1 considered the possibility of looking @ shorthand txt as computer code? This 1999
Chicago Sun-Times article describes shorthand as a language developed by kids using instant
messenger programs, email, and cell phones. I’m not sure if this is an appropriate route for CCS,
but there’s some good discussion about language and computers.
I think these news reports provide a number of avenues for our studies, but the real challenge will
be to find code contained within them.
Reply by Mark Marino on February 10, 2010 at 11:06am
In answer to your original call for code in the wild, I was searching through some legal rulings and I
came across the case of Snuffle, in Bernstein vs. United States Dept. of State.
Now in this ruling, as taken from another source:
The court began by stating what its view of source code is; namely, that source code is the text of a
program written in a “high-level” programming language, such as “PASCAL” or “C.” n216 A
critical factual determination by the panel decision included that a distinguishing feature of source
code is that it is “meant to be read and understood by humans and that it can be used to express an
idea or a method.”
The court recognized that since source code is destined for the “maw of an automated, ruthlessly
literal translator”-the compiler-a programmer must follow stringent grammatical, syntactical,
formatting, and punctuation conventions. As a result, only those trained in programming can easily
understand source code. n218
For example, the following is an excerpt from Bernstein’s Snuffle source code written in the
programming language C: n219
for (; ;)
(
uch = gtchr();
if (!(n & 31))
(
for (i = 0; i64; i++)
1 [ctr[i] = k[i] + h[n - 64 + i]
Hash512 (wm, wl, level, 8);
)

I found this section quoted in this article: “When Efforts To Conceal May Actually Reveal: Whether
First Amendment Protection Of Encryption Source Code and the Open Source Movement Support
Re-Drawing The Constitutional Line Between the First Amendment and Copyright ” by Rod Dixon
in the Columbia Science and Technology Law Review.
The article begins, provocatively enough:
Computer source code is speech-that is the argument advanced by privacy advocates and
cryptographers, who recently obtained the support of the Ninth Circuit in Bernstein vs. United
States.
No doubt, such a claim raises the ears of critics in the room, and this article and this case fall
squarely in the domain of the copyleft debate, though I believe they are instructional here as well.
Obviously, arguments about the nature of code go far beyond the academy, yet what has been
happening in the courts seems to call for the analytic tools we are developing.
The Snuffle case is one we should discuss further, perhaps in code critiques.
Now, originally I planned to call this code in the wild, but it’s not any more. Among the articles
written about this case include one by CCSWG Member: Gabriella Coleman. Her article “Code is
Speech” should definitely be added to our reading list.
Gabriella, do you want to comment a bit about this “code in the wild”?
Are there others who look at legal rulings on code? Do you find much code in it? Recently, an
attorney friend of mine, Sal Kaihani, explained to me that courts like to describe code rather than
read it.
What other examples of code in the wild turn up in legal rulings?
Reply by Gabriella “Biella” Coleman on February 11, 2010 at 7:59pm
The code referred to above may no longer be “in the wild” and we might even say that in some
cases and circumstances code has “gone wild,” exploding beyond its initial public into other
domains, even traveling via the bodies of programmers on their shirts as was the case with DeCSS
and previously chunks of the PGP code.
In terms of other legal arenas where code might appear, something that comes to mind is patent
dispute cases where some company (who is accused of infringing the patent) is ordered to pony up
some code (the software patent, however has no source code, just a general description of process).
I have not followed any of these cases but there must be a number of them. How and in what
capacity do the courts read vs. describe the code to determine infringement would be interesting to
further explore and compare to copyright/free speech cases that deal with code.
Otra búsqueda que he estado tratando es "código de computadora" en varios archivos de noticias.
No tuve mucha suerte en las bases de datos históricas de Proquest o JSTOR, pero el archivo de
noticias de Google ha arrojado algunos resultados prometedores. El término de búsqueda con el que
comencé es "código de computadora". La búsqueda incluso proporciona un análisis gráfico de la
distribución de artículos a lo largo del tiempo:

(Este gráfico representa casi 14,000 artículos de noticias).

Un artículo de la revista New York Magazine de 1991 sobre "las muchas lenguas del código
informático" me recuerda la discusión sobre un programa de laberintos al azar que se está llevando
a cabo actualmente en las críticas de los códigos.
Un artículo de 2004 del Herald Tribune informa sobre cómo el código informático llevó a las
autoridades a un sospechoso en un caso de asesinato en Kansas City.
¿Ha considerado any1 la posibilidad de buscar @ shorthand txt como código de computadora? Este
artículo del Chicago Sun-Times de 1999 describe la taquigrafía como un lenguaje desarrollado por
niños que usan programas de mensajería instantánea, correo electrónico y teléfonos celulares. No
estoy seguro de si esta es una ruta apropiada para CCS, pero hay una buena discusión sobre el
lenguaje y las computadoras.
Creo que estos informes de noticias proporcionan una serie de avenidas para nuestros estudios, pero
el verdadero desafío será encontrar el código que contienen.
Respuesta de Mark Marino el 10 de febrero de 2010 a las 11:06 a.m.
En respuesta a su llamada original al código en libertad, estaba buscando algunas sentencias legales
y me encontré con el caso de Snuffle, en Bernstein vs. Departamento de Estado de los Estados
Unidos.
Ahora en este fallo, como tomado de otra fuente:
La corte comenzó diciendo cuál es su punto de vista del código fuente; a saber, ese código fuente es
el texto de un programa escrito en un lenguaje de programación de "alto nivel", como "PASCAL" o
"C". n216 Una determinación crítica de hechos realizada por la decisión del panel incluía que una
característica distintiva del código fuente es que "debe ser leído y entendido por los humanos y que
puede usarse para expresar una idea o un método".
El tribunal reconoció que, dado que el código fuente está destinado a las "fauces de un traductor
automatizado y despiadadamente literal", el compilador, un programador debe seguir estrictas
convenciones gramaticales, sintácticas, de formato y de puntuación. Como resultado, solo aquellos
entrenados en programación pueden entender fácilmente el código fuente. n218
Por ejemplo, el siguiente es un extracto del código fuente de Snuffle de Bernstein escrito en el
lenguaje de programación C: n219
para (; ;)
(
uch = gtchr ();
if (! (n & 31))
(
para (i = 0; i64; i ++)
1 [ctr [i] = k [i] + h [n - 64 + i]
Hash512 (wm, wl, nivel, 8);
)
Encontré esta sección citada en este artículo: "Cuando los esfuerzos para ocultar realmente revelan:
si la Primera Enmienda protege el código fuente de encriptación y el Movimiento de código abierto
respalda el rediseño de la línea constitucional entre la primera enmienda y el copyright" por Rod
Dixon en el Revisión de la Ley de Ciencia y Tecnología de Columbia.
El artículo comienza, provocativamente:
El código fuente de la computadora es el habla: ese es el argumento presentado por defensores de la
privacidad y criptógrafos, que recientemente obtuvieron el apoyo del Noveno Circuito en Bernstein
vs. Estados Unidos.
Sin duda, tal afirmación levanta los oídos de los críticos en la sala, y este artículo y este caso caen
directamente en el dominio del debate copyleft, aunque creo que también son instructivos aquí.
Obviamente, los argumentos sobre la naturaleza del código van más allá de la academia, sin
embargo, lo que ha estado sucediendo en los tribunales parece exigir las herramientas analíticas que
estamos desarrollando.
El caso Snuffle es uno que deberíamos analizar más a fondo, tal vez en las críticas del código.
Ahora, originalmente planeé llamar a este código salvajemente, pero ya no es así. Entre los artículos
escritos sobre este caso se incluyen uno por miembro de CCSWG: Gabriella Coleman. Su artículo
"Code is Speech" definitivamente debe agregarse a nuestra lista de lectura.
Gabriella, ¿quieres comentar un poco sobre este "código en la naturaleza"?
¿Hay otros que miren los reglamentos legales sobre el código? ¿Encuentras mucho código?
Recientemente, un abogado amigo mío, Sal Kaihani, me explicó que a los tribunales les gusta
describir el código en lugar de leerlo.
¿Qué otros ejemplos de código en la vida silvestre aparecen en los fallos legales?
Respuesta de Gabriella "Biella" Coleman el 11 de febrero de 2010 a las 7:59 p. M.
El código referido anteriormente ya no puede estar "en la naturaleza" e incluso podríamos decir que
en algunos casos y circunstancias el código se ha "vuelto loco", explotando más allá de su público
inicial en otros dominios, incluso viajando a través de los cuerpos de los programadores en su
camisas como en el caso de DeCSS y anteriormente trozos del código PGP.
En términos de otras arenas legales donde podría aparecer el código, algo que viene a la mente son
los casos de disputas de patentes donde una compañía (que está acusada de infringir la patente)
recibe un código (la patente del software, sin embargo no tiene código fuente, solo una descripción
general del proceso). No he seguido ninguno de estos casos, pero debe haber algunos. Cómo y en
qué capacidad leen los tribunales y describen el código para determinar la infracción sería
interesante explorar más a fondo y comparar los casos de derecho de autor / libertad de expresión
que se refieren al código.

Reply by Jeremy Douglass on February 12, 2010 at 11:06am

Gabriella,
For some reason I’m reminded of Jill Walker’s “Feral hypertext: when hypertext literature escapes
control”.
This paper presents a historical view of hypertext looking at pre-web hypertext as a domesticated
species bred in captivity, and arguing that on the web, some breeds of hypertext have gone feral.
Feral hypertext is no longer tame and domesticated, but is fundamentally out of our control.
Without going too far down the rabbit-hole of naturalism and evolutionary metaphors, I wonder if it
is useful for us to think about feral computer languages, code bases, and discourses about code -
often bred in captivity, but now out of control.
Perhaps in that light, aspects of CCS itself are a species of feral computer science? Although
according to whose nature, whose control?
As to court documents. One of the amazing things about court documents is that many of them
contain statements from judges in which they define a) what software is and b) what code is for the
purposes of the trail. These are often articulate, reasoned philosophical stances, and quite
interesting. Another thing to collect for the bibliography….
Reply by Gabriella “Biella” Coleman on February 14, 2010 at 12:13pm
Another important program/code that circulated pretty globally (and in tension with its legal status)
was the Unix source code, and in specific Lion’s Commentary on Unix, a textbook that helped to
secure UNIX as a beloved OS among many technologists. I love the cover of the book as it refers
back to its history of circulating photocopies:
http://ecx.images-amazon.com/images/I/51ESMPKM6ML.jpg
The story of UNIX’s promiscuous circulation and its importance for Free Software is told in Chris
Kelty’s Two Bits in chapter 5: http://twobits.net/
There is another chapter (6) where Kelty looks at how a controversy over a small bit of code led
RMS to establish the GNU General Public License. I will add these to our bibliography as well.
Reply by Jessica Pressman on February 11, 2010 at 8:56am
I am finding myself drawn to the performative aspect of CSS as it emerges in both Jeremy and
Mark’s presentations. As I only just recently posted to Mark’s presentation from last week, I was
struck by his oral reading of code and his provocative call for the value of this practice. In Jeremy’s
presentation, I am again interested in the different ways in which code is represented - visually,
aurally, and in embodied performances. Contained within Jeremy’s post are video clips that contain
code displayed on computer screens as well people describing code across various affective
registers. I am curious to see how this CSS discussion group proceeds to present code and also pays
attention to the representation of code as a practice that itself can take on aesthetic, political, and
critical valences.
Reply by Mark Sample on February 11, 2010 at 9:00pm
Your highlighting of the performative aspects of reading code reminded me of this TED talk by
Rives, in which he tells a story about a string of emoticons (which surely counts as code):
http://www.ted.com/talks/view/id/383.
Reply by Jeremy Douglass on February 12, 2010 at 12:01pm
Mark,
In addition to examples like the Rives talk, I’d suggest another approach to the question of visual
interpretation.

Reply by Jeremy Douglass on February 12, 2010 at 11:37am

Jessica,
Yes - how does code get presented and performed, audibly-or visually for that matter? These
Youtube-readings and showings (for example, the one with code set to a sound track with lyrics)
very much connect back to Mark's performance last week and how you are discussing it there.
To me, the idea of reading code with aesthetic emphasis, paraphrase and quotation, etc., is not just
an issue of speculative aesthetics. For example, auditory interfaces for blind programmers are a real
software engineering problem. Code-out-loud isn't just the domain of poets and interloping
humanists. But the second you imagine or recognize any utilitarian context for code-out-loud, you
realize there is also a significant aesthetic dimension to the voice even if you try to treat it strictly as
a utilitarian user interface problem - whose voice? What are the speech conventions that make the
practice concise and fluid - surely not just reading one character at a time? Does tone separate data
from process? Are code comments whispered or shouted? And if this is done through speech
synthesis, what is it synthetically referring to? How in practice do we map functionality viscerally
against what Pinsky terms the medium of the human body, "the column of air inside the chest"?
Respuesta de Jeremy Douglass el 12 de febrero de 2010 a las 11:06 a.m.
Gabriella,
Por alguna razón, recuerdo el "hipertexto feral" de Jill Walker: cuando la literatura hipertextual
escapa al control.
Este documento presenta una visión histórica del hipertexto que considera el hipertexto pre-web
como una especie domesticada criada en cautiverio, y argumenta que en la web, algunas razas de
hipertexto se han vuelto salvajes. El hipertexto feral ya no es domesticado y domesticado, pero está
fundamentalmente fuera de nuestro control.
Sin ir muy lejos en el agujero del conejo del naturalismo y las metáforas evolutivas, me pregunto si
es útil para nosotros pensar en lenguajes informáticos salvajes, bases de códigos y discursos sobre el
código, a menudo criados en cautividad, pero ahora fuera de control.
Tal vez desde ese punto de vista, los aspectos de CCS en sí son una especie de ciencia informática
salvaje? Aunque según su naturaleza, ¿de quién control?
En cuanto a los documentos judiciales. Una de las cosas sorprendentes de los documentos judiciales
es que muchos de ellos contienen declaraciones de los jueces en las que definen a) qué es el
software yb) qué código es para los fines del camino. Estas son a menudo posturas filosóficas
fundadas y razonadas, y bastante interesantes. Otra cosa para recoger para la bibliografía ...
Respuesta de Gabriella "Biella" Coleman el 14 de febrero de 2010 a las 12:13 p.m.
Otro programa / código importante que circuló bastante globalmente (y en tensión con su estado
legal) fue el código fuente de Unix, y en el Comentario del León específico en Unix, un libro de
texto que ayudó a asegurar UNIX como un sistema operativo querido entre muchos tecnólogos. Me
encanta la portada del libro ya que se refiere a su historia de fotocopias circulantes:
http://ecx.images-amazon.com/images/I/51ESMPKM6ML.jpg
La historia de la circulación promiscua de UNIX y su importancia para el Software Libre se narra
en Two Bits de Chris Kelty en el capítulo 5: http://twobits.net/
Hay otro capítulo (6) donde Kelty observa cómo una controversia sobre un pequeño código llevó a
RMS a establecer la Licencia Pública General de GNU. Agregaré esto a nuestra bibliografía
también.
Respuesta de Jessica Pressman el 11 de febrero de 2010 a las 8:56 a.m.
Me encuentro atraído por el aspecto performativo de CSS, tal como aparece en las presentaciones
de Jeremy y Mark. Como acabo de publicar recientemente en la presentación de Mark de la semana
pasada, me sorprendió su lectura oral del código y su provocadora llamada al valor de esta práctica.
En la presentación de Jeremy, estoy nuevamente interesado en las diferentes formas en que se
representa el código: visualmente, auditivamente y en interpretaciones encarnadas. Dentro de la
publicación de Jeremy, se incluyen videoclips que contienen el código que se muestra en las
pantallas de la computadora y personas que describen el código en varios registros afectivos. Tengo
curiosidad por ver cómo este grupo de discusión de CSS procede a presentar el código y también
presta atención a la representación del código como una práctica que en sí misma puede tomar
valencias estéticas, políticas y críticas.
Respuesta de Mark Sample el 11 de febrero de 2010 a las 9:00 p. M.
Su destaque de los aspectos performativos del código de lectura me recordó a esta charla TED de
Rives, en la que cuenta una historia sobre una serie de emoticones (que seguramente cuenta como
código): http://www.ted.com/talks/view / id / 383.
Respuesta de Jeremy Douglass el 12 de febrero de 2010 a las 12:01 p.m.
Marca,
Además de ejemplos como la charla de Rives, sugeriría otro enfoque a la cuestión de la
interpretación visual.

Respuesta de Jeremy Douglass el 12 de febrero de 2010 a las 11:37 a.m.

Jessica,
Sí, ¿cómo se presenta y ejecuta el código, de forma audible o visual para ese caso? Estas lecturas y
proyecciones de Youtube (por ejemplo, la que tiene un código configurado para una pista de sonido
con letra) se relacionan mucho con la actuación de Mark la semana pasada y cómo se está
discutiendo allí.
Para mí, la idea de leer código con énfasis estético, paráfrasis y cita, etc., no es solo una cuestión de
estética especulativa. Por ejemplo, las interfaces auditivas para programadores ciegos son un
problema real de ingeniería de software. Code-out-loud no es solo el dominio de los poetas y
humanistas intrincados. Pero en el momento en que imagina o reconoce cualquier contexto utilitario
para codificar en voz alta, se da cuenta de que también hay una dimensión estética importante para
la voz, incluso si trata de tratarla estrictamente como un problema utilitario de interfaz de usuario,
¿de quién es esa voz? ¿Cuáles son las convenciones del habla que hacen que la práctica sea concisa
y fluida, seguramente no solo leyendo un personaje a la vez? ¿El tono separa los datos del proceso?
¿Los comentarios del código son susurrados o gritados? Y si esto se hace a través de síntesis de voz,
¿a qué se refiere sintéticamente? ¿Cómo en la práctica correlacionamos la funcionalidad
visceralmente con lo que Pinsky denomina el medio del cuerpo humano, "la columna de aire dentro
del cofre"?

Reply by Hugh Cayless on February 11, 2010 at 10:31am

Hi Jeremy,
You asked me what my take on the CRU code (and your approach to it) was, given my critical
evaluation of the annakournikova code Mark posted as "inept" and my conclusion that the most
interesting thing about it was the social context. I'm not prepared to say that the CRU code is inept
(not having spent much time reviewing it). It certainly isn't at the same level of incompetence.
I think code almost has to be read in context. It is very hard to properly appreciate code without an
understanding of what it is trying to accomplish, for example, so the motivation(s) of the
programmer(s) are often important. In my coding experience, a lot of time ends up being spent on
trying to figure out the goals of the creators of legacy code. Sometimes these are made clear in the
comments, but more often not.
But there are many contexts here. I see the programmer, in a secure enough space that he/she (do
we know the programmer's gender? Would it matter?) felt comfortable expressing dismay at the
complexities of the data and his/her ability to handle them. Then we have the political context in
which the scientists knew they were operating, and which invaded the programmer's secure space
with the exposure of the files. And then there are the various analyses which Jeremy has given us:
conspiracy theorist, "corporate gaze" (to borrow a nice term from Evan Buswell), and sympathetic
fellow-coder.
So as with the annakournikova code, the context is very powerful, and interesting. Is it more
interesting than the code? Do we risk letting the layers of context obscure our view of the code? I
suspect this code is worthy of more attention than the virus was.
Reply by Jeremy Douglass on February 13, 2010 at 1:17pm
Hugh,
Very interesting point about contexts. In response to your question about the gender of the actual
programmer, I'll add some more context - although "does it matter?" is a very good follow-up
question. I'm positive that it doesn't matter to the issue of whether a particular set of functions
correspond (or not) to a predictive model of current global temperature trends and their
consequences. I strongly suspect however that the identity of the programmer matters in the public
debate - either as an imagined construct, or as a real (although still imagined) person.
In talking about the CRU programmer, the second Debunking videos show (00:50) a cartoon of a
harried male programmer as a stand-in, and I suspect that the cartoon probably corresponds to the
mental image for many followers the debate.
The identity of the actual programmer(s) is simpler but muddier than in most cases, where an open
source or corporate codebase may have hundreds or thousands of authors, but the changes may be
checked in with an identities registered against every change. With CRU, the programmer gaining
the most attention was the author of HARRY_READ_ME, who was likely Ian 'Harry' Harris.

Of course, Harris was "the programmer" at the time of the leak, but wasn't in fact the author of
much of the code - he was maintaining and attempting to iterate a complex, poorly documented
code base that was written earlier, apparently by Tim Mitchell and/or Mark New. This leads into the
some of the issues about authorship that are so interesting in code - in theory, code development as
practiced in a versioning system affords the opportunity to talk about the collective production of an
idea in a very concrete and fine-grained way. In practice, however, we are often left reading tea-
leaves, even when in the midst of conversations that require algorithmic literacy or programmacy to
navigate them.
Reply by Mark Sample on February 11, 2010 at 8:55pm
Jeremy, thanks for this enormously productive inquiry. Your list of "real code readers" was
especially valuable - it's a reminder that code (like science in general) needn't be left to the coders
(or scientists). As someone who's only dabbled in code, tweaking some PHP here, cursing some ill-
fated Inform attempts there, I can easily find myself out of my depth among the more accomplished
programmers here.
One aspect of your opening lines - when you run through reference, citation, quotation, and
illustration - reminded me (though there was no clear logical reason why it should have done so) of
the four modes of exegesis developed informally by medieval church scholars to read the Bible:
historia (a literal interpretation); allegoria (the allegorical meaning); tropologia (a moral
interpretation); and anagoge (the eschatological interpretation). It's probably the wannabe
medievalist in me, but I wonder if we might borrow from this four-fold sense of exegesis as we read
and teach code. I've always found this rubric of four senses to be quaint at best (in a Northrop Frye
kind of way) and misguided and dangerous at worst. But now I'm thinking there might be
something here we can salvage, even if tangentially or reactionarily.
Respuesta de Hugh Cayless el 11 de febrero de 2010 a las 10:31 a.m.
Hola Jeremy,
Usted me preguntó cuál era mi opinión sobre el código CRU (y su enfoque al respecto), dada mi
evaluación crítica del código annakournikova que Mark publicó como "inepto" y mi conclusión de
que lo más interesante era el contexto social. No estoy preparado para decir que el código CRU es
inepto (no habiendo pasado mucho tiempo revisándolo). Ciertamente no está en el mismo nivel de
incompetencia.
Creo que el código casi debe leerse en contexto. Es muy difícil apreciar correctamente el código sin
una comprensión de lo que está tratando de lograr, por ejemplo, por lo que la (s) motivación (es) del
programador (es) a menudo son importantes. En mi experiencia de codificación, se pierde mucho
tiempo tratando de descubrir los objetivos de los creadores del código heredado. Algunas veces
estos se aclaran en los comentarios, pero más a menudo no.
Pero hay muchos contextos aquí. Veo al programador, en un espacio lo suficientemente seguro que
él / ella (¿conocemos el género del programador? ¿Importa?) Se sintió cómodo expresando
consternación por la complejidad de los datos y su capacidad para manejarlos. Luego tenemos el
contexto político en el que los científicos sabían que estaban operando, y que invadía el espacio
seguro del programador con la exposición de los archivos. Y luego están los diversos análisis que
Jeremy nos ha dado: teórico de la conspiración, "mirada corporativa" (por tomar un buen término de
Evan Buswell) y simpatizante codificador.
Entonces, como con el código annakournikova, el contexto es muy poderoso e interesante. ¿Es más
interesante que el código? ¿Nos arriesgamos a dejar que las capas de contexto oscurezcan nuestra
visión del código? Sospecho que este código merece más atención que el virus.
Respuesta de Jeremy Douglass el 13 de febrero de 2010 a la 1:17 p. M.
Hugh,
Punto muy interesante sobre contextos. En respuesta a su pregunta sobre el género del programador
real, agregaré un poco más de contexto, aunque "¿Importa?" es una muy buena pregunta de
seguimiento. Estoy seguro de que no importa la cuestión de si un conjunto particular de funciones
corresponde (o no) a un modelo predictivo de las tendencias actuales de la temperatura global y sus
consecuencias. Sin embargo, sospecho fuertemente que la identidad del programador importa en el
debate público, ya sea como una construcción imaginada, o como una persona real (aunque todavía
imaginada).
Al hablar sobre el programador CRU, los segundos videos Debunking muestran (00:50) una
caricatura de un acosado programador masculino como suplente, y sospecho que la caricatura
probablemente corresponde a la imagen mental de muchos seguidores del debate.

La identidad de los programadores reales es más simple pero más turbia que en la mayoría de los
casos, donde una base de código fuente abierto o corporativo puede tener cientos o miles de autores,
pero los cambios pueden registrarse con una identidad registrada contra cada cambio. Con CRU, el
programador que obtuvo la mayor atención fue el autor de HARRY_READ_ME, que
probablemente era Ian 'Harry' Harris.

Por supuesto, Harris era "el programador" en el momento de la fuga, pero en realidad no era el autor
de gran parte del código: mantenía e intentaba iterar una base de código compleja y mal
documentada que se escribió anteriormente, aparentemente por Tim Mitchell y / o Mark New. Esto
conduce a algunos de los temas sobre la autoría que son tan interesantes en el código: en teoría, el
desarrollo del código tal como se practica en un sistema de control de versiones ofrece la
oportunidad de hablar sobre la producción colectiva de una idea de una manera muy concreta y
precisa. En la práctica, sin embargo, con frecuencia nos queda leer hojas de té, incluso cuando
estamos en medio de conversaciones que requieren alfabetización algorítmica o programación para
navegar por ellas.
Respuesta de Mark Sample el 11 de febrero de 2010 a las 8:55 p. M.
Jeremy, gracias por esta investigación enormemente productiva. Su lista de "lectores de códigos
reales" fue especialmente valiosa; es un recordatorio de que el código (como la ciencia en general)
no necesita dejarse en manos de los codificadores (o científicos). Como alguien que solo ha
incursionado en el código, modificando algunos PHP aquí, maldiciendo algunos desafortunados
intentos de Inform allí, puedo encontrarme fácilmente fuera de mi profundidad entre los
programadores más logrados aquí.
Un aspecto de tus líneas iniciales, cuando recorres la referencia, cita, cita e ilustración, me recordó
(aunque no había una razón lógica clara por la que debería haberlo hecho) los cuatro modos de
exégesis desarrollados informalmente por los eruditos de la iglesia medieval. lee la Biblia: historia
(una interpretación literal); allegoria (el significado alegórico); tropologia (una interpretación
moral); y anagoge (la interpretación escatológica). Probablemente es el aspirante medievalista en
mí, pero me pregunto si podríamos tomar prestado de este sentido cuádruple de la exégesis a
medida que leemos y enseñamos el código. Siempre he encontrado que esta rúbrica de los cuatro
sentidos es pintoresca en el mejor de los casos (al estilo de Northrop Frye) y equivocada y peligrosa
en el peor. Pero ahora estoy pensando que podría haber algo aquí que podamos salvar, aunque sea
de manera tangencial o reaccionaria.

Reply by Jeremy Douglass on February 12, 2010 at 12:31pm

Mark, I agree that typologies of exegetical modes for code would be good vocabulary to have at
hand. Frye is a good reference point, in some ways, because his holistic description of "centripetal"
and "centrifugal" criticism captures some of the tensions within the CCS group itself around how to
read code.
I wouldn't be surprised if narrative theory in general (and perhaps New Criticism in particular) turns
out to provide a lot of useful vocabulary and rhetorical moves for thinking about code. I'm thinking
about work like Cleanth Brooks in "Irony as a Principle of Structure," and what analogous kite-tails
help code fly under the fingers and the through the mind of the programmer. I'm also thinking very
specifically about of Empson's "Seven Types of Ambiguity." The belief that code is unambiguous
(to the compiler and to the programmer) seems particularly pernicious to me, and we could use a
good authoritative exploration of code ambiguity as one foundation stone for larger projects.
Reply by John Bell on February 12, 2010 at 4:07pm
Code has many real and ideal readers, with many goals. One of these (and an important one) is the
ideal programmer. Another is the ideal machine - a compile, VM, or scripting engine. In one
particular story about these ideal readers, the ideal programmer is purely motivated by
functionalism, while the ideal compiler engages in an interpretive procedure untroubled by
ambiguity. Rather than detail this ideal, I propose a dose of the real.
I'd actually like to pursue that ideal for a moment, just because I think the pursuit-if not the actual
definition-might lead me back around to looking at the real in a slightly different way.
While I know you were trying not to go into detail, I think there is a very significant piece of the
story that needs to be included: how, in the frame of ideal programmers or machines reading code,
would we define the ideal user? Easy jokes aside, it seems like the ideal user has a wider range of
possible traits than the programmer or compiler. For one thing, they don't even read code per se.
Their role in the system could be to define or evaluate the functionality that the programmer
implements, or to execute the program the compiler generates, or even just to call up the help desk
to let the programmer know that their code isn't ideal.
I think that including that first role, where the user-specifically, the user's needs-helps to define the
functionality of the code, changes the narrative of this story of ideals significantly. The ideal
programmer is not usually creating a program ex nihilo (well, unless they are), they are finding the
ideal path to implement functionality that is defined outside of the context of writing code
altogether. Even after the code is written, the user is constantly redefining the functionality of code
by applying it in ways that the programmer may not have expected/intended (Twitter is a great
example). Separating these two roles changes how code should be read.
In the case of the climate change videos, the point of vulnerability that is being used to attack the
code is that the user role and the programmer role are filled by the same people. All of the questions
about code formatting and professional presentation are at best secondary concerns, and at worst
straw men. The base claim that's being made is that the user influenced the programmer to produce
a piece of code that functions in one way while stating that it functions in a different way. If the user
and programmer had been different people or organizations then it would be easier to interrogate
that claim, but here (and in many cases) they aren't and so opposing sides are left to extrapolate
intention from function.
To bring this back around to the discussion about corporate code vs. personal code, I might suggest
that one of the fundamental lines between the two is that corporate code does separate the user and
programmer roles while personal code does not. This is one of the stumbling blocks that open
source has been trying to get beyond for years: how should we resolve the difference between
"scratching a developer's personal itch" (TM ESR) and writing software that is relevant and useful
for the non-developer? One requires a user/programmer while the other requires the perspective of
separation; it seems that only the most talented programmers are really good at being both at once
(ideal programmer++?).
So what happens if we treat all the real code readers on your list as users, only without the extra
abstraction level of actually executing the code? All of the [$user_class] reading for [$goal] readers
are really attempting to define the functionality of the code they're reading by inflecting it with
[$goal]. That might be a bit of an obvious statement, but the problem is when a reader then
attributes the influence of a previous user to the programmer.
Respuesta de Jeremy Douglass el 12 de febrero de 2010 a las 12:31 p.m.
Mark, estoy de acuerdo en que las tipologías de modos exegéticos para el código serían un buen
vocabulario para tener a mano. Frye es un buen punto de referencia, de alguna manera, porque su
descripción holística de la crítica "centrípeta" y "centrífuga" capta algunas de las tensiones dentro
del propio grupo CCS sobre cómo leer el código.
No me sorprendería si la teoría narrativa en general (y tal vez la Nueva crítica en particular)
resultara proporcionar mucho vocabulario útil y movimientos retóricos para pensar en el código.
Estoy pensando en trabajos como Cleanth Brooks en "La ironía como principio de la estructura", y
qué cola de cometa análoga ayuda a codificar para volar bajo los dedos y a través de la mente del
programador. También estoy pensando específicamente en los "Siete tipos de ambigüedad" de
Empson. La creencia de que el código no es ambiguo (para el compilador y para el programador)
me parece particularmente perniciosa, y podríamos usar una buena exploración autorizada de la
ambigüedad del código como una piedra angular para proyectos más grandes.
Respuesta de John Bell el 12 de febrero de 2010 a las 4:07 p.m.
Code tiene muchos lectores reales e ideales, con muchos objetivos. Uno de estos (y uno importante)
es el programador ideal. Otra es la máquina ideal: un motor de compilación, VM o scripting. En una
historia particular sobre estos lectores ideales, el programador ideal está puramente motivado por el
funcionalismo, mientras que el compilador ideal se involucra en un procedimiento interpretativo
que no se ve afectado por la ambigüedad. En lugar de detallar este ideal, propongo una dosis de lo
real.
De hecho, me gustaría perseguir ese ideal por un momento, solo porque creo que la búsqueda -si no
la definición real- podría llevarme a mirar el real de una manera ligeramente diferente.
Aunque sé que trataste de no entrar en detalles, creo que hay una parte muy importante de la
historia que debe incluirse: ¿cómo podríamos definir al usuario ideal en el marco de programadores
ideales o máquinas que leen el código? Bromas fáciles de lado, parece que el usuario ideal tiene una
gama más amplia de características posibles que el programador o el compilador. Por un lado, ni
siquiera leen el código per se. Su rol en el sistema podría ser definir o evaluar la funcionalidad que
el programador implementa, o ejecutar el programa que el compilador genera, o incluso
simplemente llamar al servicio de ayuda para que el programador sepa que su código no es ideal.
Creo que incluir esa primera función, donde el usuario -específicamente, las necesidades del
usuario- ayuda a definir la funcionalidad del código, cambia significativamente la narración de esta
historia de ideales. El programador ideal no suele crear un programa ex nihilo (bueno, a menos que
lo sean), sino que están encontrando la ruta ideal para implementar la funcionalidad que se define
fuera del contexto de escritura del código. Incluso después de que se escribe el código, el usuario
redefine constantemente la funcionalidad del código aplicándolo de formas que el programador
puede no haber esperado / previsto (Twitter es un gran ejemplo). La separación de estos dos roles
cambia la forma en que se debe leer el código.
En el caso de los videos sobre el cambio climático, el punto de vulnerabilidad que se usa para atacar
el código es que el rol del usuario y el rol del programador son ocupados por las mismas personas.
Todas las preguntas sobre el formato del código y la presentación profesional son, en el mejor de los
casos, preocupaciones secundarias y, en el peor de los casos, de hombres de paja. La afirmación
básica que se hace es que el usuario influyó en el programador para producir una pieza de código
que funciona de una manera, mientras que indica que funciona de una manera diferente. Si el
usuario y el programador hubiesen sido personas u organizaciones diferentes, entonces sería más
fácil interrogar esa afirmación, pero aquí (y en muchos casos) no lo están, por lo que los lados
opuestos deben extrapolar la intención de la función.
Para traer esto de vuelta a la discusión sobre el código corporativo frente al código personal, podría
sugerir que una de las líneas fundamentales entre los dos es que el código corporativo separa las
funciones del usuario y del programador, mientras que el código personal no. Este es uno de los
escollos que Open Source ha estado tratando de superar durante años: cómo deberíamos resolver la
diferencia entre "rayar el picor personal de un desarrollador" (TM ESR) y escribir un software que
sea relevante y útil para los no desarrolladores. ? Uno requiere un usuario / programador, mientras
que el otro requiere la perspectiva de la separación; parece que solo los programadores más
talentosos son realmente buenos para ser ambos a la vez (programador ideal ¿++?).
Entonces, ¿qué sucede si tratamos a todos los lectores de códigos reales en su lista como usuarios,
solo sin el nivel de abstracción extra de realmente ejecutar el código? Todas las lecturas [$
user_class] para los lectores [$ goal] realmente intentan definir la funcionalidad del código que
están leyendo al inflarlo con [$ goal]. Esa podría ser una afirmación obvia, pero el problema es
cuando un lector atribuye la influencia de un usuario anterior al programador.

I certainly don’t mean this to imply that code should only be read reductively. I mostly mean to say
that there is a line between a critical reading of programmer-implementation-functionality and a
critical reading of user-program-functionality that should be acknowledged, even when the
programmer and user are the same person. There is still a vast amount of room for play, creativity,
and genius (or not) within both of those spaces, and readings of the code should recognize that.
However, there is a danger-particularly in corporate code-of mixing the two during interpretation
when the reality is that they are two separate things, and the first CRU video seems to demonstrate
that conflating them can lead to bad results.
Reply by Jeremy Douglass on February 13, 2010 at 8:00pm
John, I’m still thinking through your proposed “ideal user” (of the software) and trying to come to
grips with how and to what extent it connects with my list of various reading roles for code.
Looking at my own use of “ideal programmer / compiler” I’m also thinking about the parallels with
the “implied reader / author” from literary theory. Perhaps the use of the “implied” (an imagined
role that is actively constructed while reading the code) is helpful for what you are talking about
here.
While reading the CRU code, we construct an implied programmer (or more than one) from what
we read, and this programmer (but ideal, but probably no) may or may not have any relationship to
the real programmer(s). Some readers construct an implied CRU programmer who is deceitful but
incompetent, while others construct one who is earnest but beleaguered. Readers of just the logs or
comments will construct this person differently from readers with procedural literacy.
Now, the code itself implies these things to a reader - we might learn in the news for example that
Harris was hampered in his duties due to drug addiction (he wasn’t), but this new view on Harris
isn’t reflected in the Harry that the code itself implies. Code may likewise indicate or just imply a
compiler, software environment, expected data, and set of use cases to varying degrees of
specificity (or not at all). So, it is a very interesting observation that code has an ideal user that is a
part of the ethos of the code. Is this a user function, in the sense of an author function? A user story
in the mind of the programmer, perhaps one commissioned and then passed down from
management?
In the case of the CRU, the users are not entirely the programmer, although the programmer is
certainly one of the users (but isn’t the programmer almost always one of the users?). Instead, the
CRU users may have been working in offices 10 feet away from the programmer, and were not
abstract at all. They were real scientists in all their messiness and imperfections, and the program
was haltingly revised for them in reaction to their crises and shifting daily concerns, when perhaps
it should have been written for the ideal user, which (we might claim) should have been Science.
At least, that is what I read in the code. But then, what I’m doing is constructing the programmer’s
implied user from the code and context.
Finally, to connect this back to my list of Who Reads Code:
I’m not sure that all of my examples connect directly to use - for example, the lawyer reading
breathalyzer code may not be planning to use a breathalyzer, but is intensely interested in how its
functions interacted with his DUI defense case clients. Similarly, most of my Easter-egg hunters by
definition are uninterested in the functionality of the code, and instead simply want to suck the
marrow from it.
Still, in many examples this user idea makes sense to me. One of the items I listed was “hackers
reading for exploits” - an interesting case of a code reader, as the hacker is also often a user of the
code/software as well. Now, I think you could argue that this hacker is almost never the ideal user
for whom a web application programmer develops her pages. In very few cases will programmers
actually focus on this hacker as their development user story - especially in the specific case of the
code the hacker happens to be reading. And yet, while this hacker is almost never an ideal user, you
might easily say that they are often an implied user. Reading a contemporary PHP web application,
the code repeatedly addresses this user - the buffer overflow, URL-munging, SQL-injecting script
kiddie who is not the core ethos of the feature set, but whom the code constantly addresses and
implies in such a way that we who read the code come to know what this hacker is like (or is
expected and believed to be like).
Ciertamente, no me refiero a que esto implique que el código solo debe leerse de manera reductiva.
Principalmente quiero decir que hay una línea entre una lectura crítica de la funcionalidad de
implementación del programador y una lectura crítica de la funcionalidad del programa del usuario
que debe reconocerse, incluso cuando el programador y el usuario son la misma persona. Todavía
hay una gran cantidad de espacio para el juego, la creatividad y el genio (o no) dentro de ambos
espacios, y las lecturas del código deberían reconocerlo. Sin embargo, existe un peligro,
especialmente en el código corporativo, de mezclar los dos durante la interpretación, cuando la
realidad es que son dos cosas separadas, y el primer video de la CRU parece demostrar que
combinarlos puede generar malos resultados.
Respuesta de Jeremy Douglass el 13 de febrero de 2010 a las 8:00 p. M.
John, todavía estoy pensando en tu "usuario ideal" propuesto (del software) y tratando de entender
cómo y en qué medida se conecta con mi lista de varios roles de lectura para el código. Al analizar
mi propio uso del "programador / compilador ideal", también estoy pensando en los paralelos con el
"lector / autor implícito" de la teoría literaria. Tal vez el uso del "implícito" (un rol imaginario que
se construye activamente al leer el código) sea útil para lo que está hablando aquí.
Mientras leemos el código CRU, construimos un programador implícito (o más de uno) a partir de
lo que leemos, y este programador (pero ideal, pero probablemente no) puede o no tener alguna
relación con el programador real. Algunos lectores construyen un programador de CRU implicado
que es engañoso pero incompetente, mientras que otros construyen uno que es serio pero acosado.
Los lectores de solo los registros o comentarios construirán a esta persona de manera diferente a los
lectores con conocimiento de procedimiento.
Ahora, el código en sí mismo implica estas cosas para un lector; podríamos aprender en las noticias,
por ejemplo, que Harris se vio obstaculizado en sus obligaciones debido a la adicción a las drogas
(no lo era), pero esta nueva visión de Harris no se refleja en Harry que el código mismo implica. El
código también puede indicar o simplemente implicar un compilador, entorno de software, datos
esperados y un conjunto de casos de uso con distintos grados de especificidad (o no tenerlos).
Entonces, es una observación muy interesante que el código tiene un usuario ideal que es parte del
ethos del código. ¿Es esta una función de usuario, en el sentido de una función de autor? ¿Una
historia de usuario en la mente del programador, tal vez una encargada y luego transmitida por la
gerencia?
En el caso de la CRU, los usuarios no son enteramente programadores, aunque el programador es
ciertamente uno de los usuarios (¿pero el programador no es casi siempre uno de los usuarios?). En
cambio, los usuarios de CRU pueden haber estado trabajando en oficinas a 10 pies de distancia del
programador, y no eran en absoluto abstractos. Eran verdaderos científicos en todo su desorden e
imperfecciones, y el programa fue revisado vacilantemente para ellos en reacción a sus crisis y
preocupaciones cotidianas, cuando tal vez debería haber sido escrito para el usuario ideal, que
(podríamos decir) debería haber sido Ciencia.
Al menos, eso es lo que leo en el código. Pero entonces, lo que estoy haciendo es construir el
usuario implícito del programador desde el código y el contexto.
Finalmente, para conectar esto a mi lista de Who Reads Code:
No estoy seguro de que todos mis ejemplos se conecten directamente con el uso; por ejemplo, el
abogado que lee el código del alcoholímetro podría no estar planeando usar un alcoholímetro, pero
está muy interesado en cómo interactúan sus funciones con sus clientes de casos de defensa de DUI.
Del mismo modo, la mayoría de mis cazadores de huevos de Pascua, por definición, no están
interesados en la funcionalidad del código y, en cambio, simplemente quieren chupar el tuétano de
él.
Aún así, en muchos ejemplos, esta idea de usuario tiene sentido para mí. Uno de los elementos que
enumeré fue "hackers que leen para exploits", un caso interesante de lector de código, ya que el
hacker también suele ser usuario del código / software. Ahora, creo que podría argumentar que este
hacker casi nunca es el usuario ideal para quien un programador de aplicaciones web desarrolla sus
páginas. En muy pocos casos, los programadores realmente se enfocarán en este hacker como su
historia de usuario de desarrollo, especialmente en el caso específico del código que el hacker está
leyendo. Y, sin embargo, aunque este pirata informático casi nunca es un usuario ideal, puede decir
fácilmente que a menudo es un usuario implícito. Al leer una aplicación web PHP contemporánea,
el código se dirige repetidamente a este usuario: el desbordamiento de búfer, el uso de URL, el
script de inyección de SQL kiddie que no es el núcleo del conjunto de características, pero que el
código trata e implica constantemente de esa manera que nosotros que leímos el código llegamos a
saber cómo es este hacker (o se espera y se cree que es así).

Reply by John Bell on February 14, 2010 at 9:35am

Jeremy, yes, I think that adding in implied programmers/users helps clarify what I was getting after
with adding an ideal user to the code creation system. To go a bit further down the rabbit hole:
I was thinking of the execution part of the ideal user not as a role where someone fulfills the stated
purpose of a piece of software, but as a role where all uses of a piece of software are carried out.
More specifically, the ideal user is responsible for defining what the functionality of a piece of
software should be and determining how well it meets that goal. As part of that evaluation the ideal
user discovers not only where the software meets or falls short of the functional goal, but also where
it exceeds it and does something unexpected. The DUI lawyer is evaluating the code against a
functional standard regardless of whether or not he or she ever tries to execute it.
Under that definition the hacker reading for exploits is still within the ideal user space because they
are using the software’s functionality (or lack thereof) against it. For me an interesting question here
is whether or not the ideal programmer is aware of and responsible for all the possible uses of the
code they create. The tension in the system is between the programmer, who knows everything the
code should do, and the user, who knows everything the code actually does. While it’s tempting to
say that an ideal programmer only writes code that does what is intended, I’m not sure that’s true;
it’s the question of whether or not an ideal toolmaker only makes hammers that can’t be used to hit
somebody in the head.
Back in the real, constructing implied users during a reading of code would seem to be a good way
to get to the heart of that programmer/user tension. If there is code that implies a certain use, then
clearly the programmer has anticipated it. If there is functionality that is not implied-good or bad-it
is the result of a user going beyond the implied programmer’s vision. And of course, you pointed
out several other (more) useful things an implied user can add to a reading of code as well as just
probing this little theoretical model.
In the case of the CRU code, as you say, different readers will construct different implied
programmers. My question was whether the difference between those programmers-deceitful vs.
earnest-is a result of misattributing a user role to a programmer. For some, CRU is a black box that
is both user and programmer (regardless of the individual people that make up CRU) and mixing
the two results in code that was influenced by an agenda. For others, the programmer and the user
are kept separate, and the programmer just had a bad day or left a few ambiguous comments. For
readers who have constructed those implied programmers it may not be relevant as they’ve already
built in those implications, it’s just in retrospect that I wonder about their origins.
Reply by Elizabeth Swanstrom (Lisa) on February 12, 2010 at 6:51pm
My challenge to the workshop for this week is to find concrete examples of actual code reading that
enrich our idea of who reads code…I propose a dose of the real.
In response to Jeremy’s challenge, both to find a concrete example of “actual code” and bring “a
dose of the real” to the discussion, I’m interested in code that feeds people. On Daniel
Folkinshteyn’s web site, a link named “RiceMaker” will take the curious reader to a wiki page that
describes how to install and run a piece of code on one’s computer. This piece of code is a specific
type of webbot, one used to interact with the UN Worldfood Program’s FreeRice website.
According to the author of the bot, “Ricemaker is a python script that automates the vocabulary
game on FreeRice to generate rice donations. In other words, it is a FreeRice bot…if you run
RiceMaker 24/7, and don’t change the loop delay settings from the default of [a] 3 second average,
you can feed about…8.1 people per day” (http://wiki.df.dreamhosters.com/wiki/RiceMaker).
Respuesta de John Bell el 14 de febrero de 2010 a las 9:35 a.m.
Jeremy, sí, creo que agregar programadores / usuarios implícitos ayuda a aclarar lo que obtengo
luego de agregar un usuario ideal al sistema de creación de códigos. Para ir un poco más abajo en el
agujero del conejo:
Estaba pensando en la parte de ejecución del usuario ideal no como un rol en el que alguien cumple
el propósito declarado de un software, sino como un rol en el que se llevan a cabo todos los usos de
un software. Más específicamente, el usuario ideal es responsable de definir cuál debe ser la
funcionalidad de un software y determinar qué tan bien cumple con ese objetivo. Como parte de esa
evaluación, el usuario ideal descubre no solo dónde se encuentra el software o qué cumple con el
objetivo funcional, sino también dónde lo supera y hace algo inesperado. El abogado de DUI está
evaluando el código contra un estándar funcional, independientemente de si él o ella alguna vez
intenta ejecutarlo.
Según esa definición, el pirata informático que lee los exploits aún se encuentra dentro del espacio
de usuario ideal porque está utilizando la funcionalidad del software (o la falta de ella) en su contra.
Para mí, una pregunta interesante aquí es si el programador ideal conoce y es responsable de todos
los posibles usos del código que crean. La tensión en el sistema es entre el programador, que sabe
todo lo que debe hacer el código, y el usuario, que sabe todo lo que el código realmente hace. Si
bien es tentador decir que un programador ideal solo escribe código que hace lo que se pretende, no
estoy seguro de que sea cierto; es la cuestión de si un fabricante de herramientas ideal solo fabrica
martillos que no pueden usarse para golpear a alguien en la cabeza.
De vuelta en lo real, construir usuarios implícitos durante la lectura del código parecería ser una
buena forma de llegar al corazón de la tensión del programador / usuario. Si hay un código que
implica cierto uso, entonces claramente el programador lo anticipó. Si hay una funcionalidad que no
está implícita, buena o mala, es el resultado de un usuario que va más allá de la visión implícita del
programador. Y, por supuesto, señaló varias otras (más) cosas útiles que un usuario implícito puede
agregar a una lectura de código, así como también solo sondear este pequeño modelo teórico.
En el caso del código CRU, como dices, diferentes lectores construirán diferentes programadores
implicados. Mi pregunta era si la diferencia entre esos programadores, engañosa y seria, es el
resultado de atribuir erróneamente una función de usuario a un programador. Para algunos, CRU es
una caja negra que es a la vez usuario y programador (independientemente de las personas que
componen la CRU) y mezcla los dos resultados en un código que fue influenciado por una agenda.
Para otros, el programador y el usuario se mantienen separados, y el programador simplemente tuvo
un mal día o dejó algunos comentarios ambiguos. Para los lectores que han construido esos
programadores implícitos, puede no ser relevante ya que ya han incorporado esas implicaciones, es
solo en retrospectiva que me pregunto sobre sus orígenes.
Respuesta de Elizabeth Swanstrom (Lisa) el 12 de febrero de 2010 a las 6:51 p.m.
Mi reto al taller de esta semana es encontrar ejemplos concretos de lectura de código real que
enriquezcan nuestra idea de quién lee el código ... Propongo una dosis de lo real.
En respuesta al desafío de Jeremy, tanto para encontrar un ejemplo concreto de "código real" como
para traer "una dosis de lo real" a la discusión, me interesa el código que alimenta a las personas. En
el sitio web de Daniel Folkinshteyn, un enlace llamado "RiceMaker" llevará al lector curioso a una
página wiki que describe cómo instalar y ejecutar un código en la computadora. Esta pieza de
código es un tipo específico de webbot, que se usa para interactuar con el sitio web FreeRice del
Programa Mundial de las Naciones Unidas. Según el autor del bot, "Ricemaker es un script de
Python que automatiza el juego de vocabulario en FreeRice para generar donaciones de arroz. En
otras palabras, es un bot de FreeRice ... si ejecuta RiceMaker 24/7, y no cambia la configuración de
retardo de bucle del promedio predeterminado de [a] 3 segundos, puede alimentar a
aproximadamente ... 8.1 personas por día "(http : //wiki.df.dreamhosters.com/wiki/RiceMaker).

I very much appreciate Jeremy’s desire to move from how we “should” read code to how we “do”
read code, and in the spirit of this ambition, I’ll offer up an issue that this work has raised for me. In
addition to questions about the ethics of such a script (the FreeRice program has initiated an
unambiguous “no bots” policy), one of the largest questions I have in looking at this code - and I
hesitate to say “reading,” because my knowledge is so provisional - has to deal with the way I came
to it, which is to say as embedded within other variously coded textual environments (on the web,
on a wiki, in English, in a text editor, etc.). While reading these different layers is of course relevant
to my specific project, my question here is scalable: given that it’s useful to read code both closely
and contextually, i.e., within/against/among/over/under (pick your favorite preposition) other types
of codes, what points of intersection have proven particularly fruitful?
Here is an excerpt from ricemaker.py:
self.starttime = time.time() #our start time - will use this to
figure out rice per second stats

try:
self.iterator = 0
while 1:
self.iterator += 1
try:
self.queueitem = self.queue.get(block=True, timeout=10)
self.ricecounter += int(self.queueitem['rice'])
print "iteration:", self.iterator
print "thread number:", self.queueitem['print']['threadnumber']
print "targetword:", self.queueitem['print']['targetword']
print "answer:", self.queueitem['print']['answer']
print "correct?", self.queueitem['print']['correct']
print "vocab level:", self.queueitem['print']['vocablevel']
print "total rice this session:", self.ricecounter
print "total rice all recorded sessions:", self.running_rice_total + self.ricecounter
print "percent correct this session:", str(round(self.ricecounter/self.answer_value/self.iterator*100.0,
2))+"%"
print "iterations per second", str(self.iterator/(time.time()-self.starttime)), ";", "rice per second",
str(self.ricecounter/(time.time() - self.starttime))
print "******************************************"
Reply by Jeremy Douglass on February 14, 2010 at 12:34am
Lisa,
Thanks for this excellent example - I wasn’t familiar with RiceMaker and FreeRice. I have a
number of reactions to this, some of which started with the narratives that get wrapped around the
RiceMaker script (especially their section: “Ethical Considerations”) and the FreeRice webservice
(e.g. the defense offered in “FreeRice a scam? Ask the beneficiaries”).
I’m not sure that I’m ready to say anything interesting about the code above yet that would go
beyond what it says it does on the wrapper, but I have the beginning of an idea of how I would head
into the code. Essentially, there are several competing descriptions of what “FreeRice” is. One is the
actual set of financial arrangements backing the site. Another is the public description (or
approximation) of these business processes as a proxy-donation arrangement (with its implicit
dependency on ad-driven corporate volunteers). A third description is the actual software driving the
FreeRice service (which makes this relationship automatic and procedural), and the way it gets
wrapped in a web interface that moves the proxy-sponsor into the footer, and tells the user that they
are literally creating grains of rice with each interaction. Finally, the RiceMaker code is a kind of
“reductio ad absurdum” / “modest proposal” - it responds to the mild white lie of the web service by
taking it completely seriously, as if an internet signal could (ex nihilo) “make” grains of rice.
So one way I might approach the RiceMaker source code is, how do the bot code procedures
imagine the UN partner program, and how is this description mirrored / contested by other
descriptions? I’m not sure if the code will be interesting or surprising yet, but I can already imagine
other ways that might be interesting to approach it even if it is quite straightforward in structure -
for example, if that straightforward structure id similar to other types of code (like CAPTCHA-
cracking spam-bots, or evidence-pooling SETI@Home clients) that we don’t usually talk about in
the same registers.
Reply by Evan Buswell on February 13, 2010 at 8:17pm
So, I’ve been thinking about the Climategate videos all week, and I finally figured out what’s been
bugging me. I went to the website for the CRU’s temperature data sets and then skimmed through
each of the published papers they listed there. The software is hardly even mentioned.
Reciprocal to this week’s question is the question: How is code not being read, where we might
expect it to be read?
Aprecio mucho el deseo de Jeremy de pasar de la forma en que "deberíamos" leer el código a la
forma en que "leemos" el código de lectura, y en el espíritu de esta ambición, ofreceré un tema que
este trabajo me ha planteado. Además de las preguntas sobre la ética de dicho guión (el programa
FreeRice ha iniciado una política inequívoca de "no bots"), una de las preguntas más importantes
que tengo al mirar este código, y dudo en decir "leer", porque mi el conocimiento es tan
provisional: tiene que ver con la forma en que llegué a él, es decir, como incrustado dentro de otros
entornos textuales diversamente codificados (en la web, en una wiki, en inglés, en un editor de
texto, etc.). Si bien leer estas diferentes capas es por supuesto relevante para mi proyecto específico,
mi pregunta aquí es escalable: dado que es útil para leer el código tanto de cerca como
contextualmente, es decir, dentro / contra / entre / sobre / debajo (elija su preposición favorita) tipos
de códigos, ¿qué puntos de intersección han demostrado ser particularmente fructíferos?
Aquí hay un extracto de ricemaker.py:
self.starttime = time.time () #our start time - usará esto para descubrir arroz por segundo stats
tratar:
self.iterator = 0
mientras que 1:
self.iterator + = 1
tratar:
self.queueitem = self.queue.get (bloque = True, tiempo de espera = 10)
self.ricecounter + = int (self.queueitem ['rice'])
print "iteration:", self.iterator
imprimir "número de hilo:", self.queueitem ['print'] ['threadnumber']
imprimir "targetword:", self.queueitem ['print'] ['targetword']
print "answer:", self.queueitem ['print'] ['answer']
imprimir "¿correcto?", self.queueitem ['print'] ['correct']
print "nivel de vocabulario:", self.queueitem ['print'] ['vocablevel']
imprime "arroz total esta sesión", self.ricecounter
imprime "arroz total todas las sesiones grabadas:", self.running_rice_total + self.ricecounter
print "porcentaje correcto esta sesión:", str (round (self.ricecounter / self.answer_value / self.iterator
* 100.0, 2)) + "%"
imprimir "iteraciones por segundo", str (self.iterator / (time.time () - self.starttime)), ";", "arroz por
segundo", str (self.ricecounter / (time.time () - self .hora de inicio))
impresión "******************************************"
Respuesta de Jeremy Douglass el 14 de febrero de 2010 a las 12:34 a.m.
Lisa,
Gracias por este excelente ejemplo: no estaba familiarizado con RiceMaker y FreeRice. Tengo
varias reacciones al respecto, algunas de las cuales comenzaron con las narraciones que se
relacionan con el guión de RiceMaker (especialmente su sección: "Consideraciones éticas") y el
servicio web FreeRice (por ejemplo, la defensa ofrecida en "FreeRice, una estafa"). beneficiarios ").
No estoy seguro de que esté listo para decir algo interesante sobre el código anterior que vaya más
allá de lo que dice sobre el envoltorio, pero tengo una idea de cómo abordaría el código.
Esencialmente, hay varias descripciones competitivas de lo que es "FreeRice". Uno es el conjunto
real de arreglos financieros que respaldan el sitio. Otra es la descripción pública (o aproximación)
de estos procesos de negocios como un arreglo de donación de proxy (con su dependencia implícita
de voluntarios corporativos impulsados por anuncios). Una tercera descripción es el software real
que maneja el servicio FreeRice (que hace que esta relación sea automática y de procedimiento), y
la forma en que se envuelve en una interfaz web que mueve al proxy-patrocinador al pie de página,
y le dice al usuario que están literalmente creando granos de arroz con cada interacción. Finalmente,
el código de RiceMaker es una especie de "reductio ad absurdum" / "propuesta modesta": responde
a la leve mentira blanca del servicio web al tomarlo completamente en serio, como si una señal de
Internet pudiera (ex nihilo) "hacer" granos de arroz.
Entonces, una forma en que podría abordar el código fuente de RiceMaker es: ¿cómo se imaginan
los procedimientos del código bot el programa de socios de las Naciones Unidas y cómo otras
descripciones duplican / impugnan esta descripción? No estoy seguro de si el código será
interesante o sorprendente aún, pero ya puedo imaginar otras formas en las que podría ser
interesante abordarlo, incluso si es bastante sencillo en cuanto a estructura, por ejemplo, si esa
estructura directa id similar a otros tipos de código (como CAPTCHA-cracking de spam-bots, o
evidencia conjunta de clientes de SETI @ Home) de los que no solemos hablar en los mismos
registros.
Respuesta de Evan Buswell el 13 de febrero de 2010 a las 8:17 p. M.
Entonces, he estado pensando en los videos de Climategate toda la semana, y finalmente descubrí lo
que me ha estado molestando. Fui al sitio web para los conjuntos de datos de temperatura de la
CRU y luego revisé cada uno de los documentos publicados que allí figuraban. El software apenas
se menciona.
Recíproco a la pregunta de esta semana es la pregunta: ¿Cómo no se lee el código, donde podemos
esperar que se lea?
In the case of “Climategate,” I see in the scientific research this overwhelming assumption that the
code is wholly secondary, that it is completely transparent insofar as any truth claims are concerned-
though I don’t know much about the climate research discourse, so correct me if I’m wrong. For
example, in the paper, “Uncertainty estimates in regional and global observed temperature
changes,” the computer and its programmer do creep in under the headings “Homogenization
Adjustment Error” and “Calculation and Reporting Error,” but the first error is treated as essentially
equivalent to choosing correct mathematical adjustment models, and the second is treated as
equivalent to correct calculation procedures on the part of the scientist. That is, as far as truth value
is concerned, the design (architecture) of the computer program is assumed to be epistemologically
equivalent to the use of the appropriate mathematical models, and the implementation of the
computer program is assumed to be epistemologically equivalent to the hand calculations of the
scientists.
Similarly, the pro-warming video ends by accusing the sceptics of “assuming far too much about the
scientists.” Not to read too much into that statement, but even after a thoughtful analysis of the
possible interpretations and contexts of the code, this video ends by emphasizing the value of what’s
not code: the scientists, as people.
As I’ve wrote and deleted several poorly-thought-out versions of this next paragraph, I’ll just post it
as a question. Here’s what I’m thinking about: is this emphasis on the scientists, this emphasis on
what’s not code, just a symptom of a culture that hasn’t caught up with code’s existence yet? Or is
there some vested interest-other than the obvious intellectual property interest-that wants the code
to be hidden or ignored?
Reply by David Shepard on February 14, 2010 at 6:12pm
Is this emphasis on the scientists, this emphasis on what’s not code, just a symptom of a culture that
hasn’t caught up with code’s existence yet? Or is there some vested interest-other than the obvious
intellectual property interest-that wants the code to be hidden or ignored?
I really like this question. I think the under-emphasis on code is a symptom of a larger under-
appreciation of, or lack of knowledge about, code. This is something I’m looking at in my
dissertation: fictional computer programmers tend to be evil sociopaths (e.g. The Net, Virtuosity),
freelancers who aren’t in charge of the schemes they implement (Swordfish, Live Free or Die Hard,
Firewall), or Frankenstein-like scientists who get trapped in their own machines (Colussus: the
Forbin Project, Terminator 2, Pi, and The Matrix). Technical knowledge rarely makes someone
heroic. To me, this illustrates a hope that even as computers endow us with greater power, they
don’t fundamentally change us because they only do what their programmers tell them. This trope is
generally associated with formal simplicity: stories that are themselves straightforward Hollywood
films or something we might write off as pulp fiction.
Some postmodern fiction exemplifies a counter-trope by mapping structuralist theories about
language onto code: language is a closed system that helps to structure thought, so if our brains are
cybernetic symbol-processing systems, they can be “reprogrammed” by reading the right sequences
of words. Language and code affect or create the ideas that can be expressed. The difficulty of
coding shows us that computers aren’t as powerful or easy to use as we would like, and that they
shape human existence significantly so as to undercut the idea of a stable core to human experience.
Some examples would be Burroughs’ novels (since Burroughs apparently thinks textual cut-ups can
help “deprogram” readers by showing them possibilities they wouldn’t otherwise see) or Don
DeLillo’s Ratner’s Star, about scientists creating a robot that speaks a programming language free
from ambiguity.
The response to the CRU code seems to show us that we want to believe that the code could only
show the intent of the scientists, even though it could deviate from this because of typos or language
strictures unknown to the programmer. Computing seems to be a bastion of representationalism;
even though we no longer trust the transparency of language, we want to believe in the transparency
of code, perhaps because the specialized knowledge required to write it. David Porush puts forth the
theory that cybernetics emerged to compensate for the uncertainty of quantum physics, and the
same desire - that we can represent processes or objects transparently through computing if not
through language or writing any more - persists in our understanding of code.
En el caso de "Climategate", veo en la investigación científica esta abrumadora suposición de que el
código es completamente secundario, que es completamente transparente en lo que respecta a
cualquier afirmación de verdad, aunque no sé mucho sobre el discurso de la investigación del clima,
así que corrígeme si me equivoco. Por ejemplo, en el documento, "Estimaciones de incertidumbre
en los cambios de temperatura observados regionales y globales", la computadora y su programador
se deslizan bajo los encabezados "Error de ajuste de homogeneización" y "Error de cálculo e
informe", pero el primer error se trata como esencialmente equivalente a elegir modelos correctos
de ajuste matemático, y el segundo es tratado como equivalente a los procedimientos correctos de
cálculo por parte del científico. Es decir, en lo que se refiere al valor de verdad, se supone que el
diseño (arquitectura) del programa de computadora es epistemológicamente equivalente al uso de
los modelos matemáticos apropiados, y se supone que la implementación del programa de
computadora es equivalente epistemológicamente al cálculos a mano de los científicos.
Del mismo modo, el video favorable al calentamiento finaliza acusando a los escépticos de "asumir
demasiado sobre los científicos". No leer demasiado en esa declaración, pero incluso después de un
análisis reflexivo de las posibles interpretaciones y contextos del código, este video Termina
enfatizando el valor de lo que no es código: los científicos, como personas.
Como escribí y borré varias versiones mal pensadas de este próximo párrafo, solo lo publicaré como
una pregunta. Esto es lo que estoy pensando: ¿es este énfasis en los científicos, este énfasis en lo
que no es código, solo un síntoma de una cultura que aún no ha alcanzado la existencia del código?
¿O existe algún interés creado -excepto el obvio interés de la propiedad intelectual- que quiere que
el código se oculte o se ignore?
Respuesta de David Shepard el 14 de febrero de 2010 a las 6:12 p.m.
¿Es este énfasis en los científicos, este énfasis en lo que no es código, simplemente un síntoma de
una cultura que aún no se ha puesto al día con la existencia del código? ¿O existe algún interés
creado -excepto el obvio interés de la propiedad intelectual- que quiere que el código se oculte o se
ignore?
Me gusta mucho esta pregunta Creo que el bajo énfasis en el código es un síntoma de un mayor
subestimación o falta de conocimiento sobre el código. Esto es algo que estoy viendo en mi
disertación: programadores informáticos ficticios tienden a ser sociópatas malvados (por ejemplo,
The Net, Virtuosity), trabajadores independientes que no están a cargo de los esquemas que
implementan (Swordfish, Live Free or Die Hard, Firewall ), o científicos parecidos a Frankenstein
que quedan atrapados en sus propias máquinas (Colussus: el Proyecto Forbin, Terminator 2, Pi y
The Matrix). El conocimiento técnico raramente hace a alguien heroico. Para mí, esto ilustra la
esperanza de que incluso cuando las computadoras nos dotan de mayor poder, no nos cambien
fundamentalmente porque solo hacen lo que les dicen sus programadores. Este tropo se asocia
generalmente con la simplicidad formal: historias que son en sí mismas películas de Hollywood o
algo que podríamos descartar como ficción pulp.
Parte de la ficción posmoderna ejemplifica una contratropa mapeando teorías estructuralistas sobre
el lenguaje en el código: el lenguaje es un sistema cerrado que ayuda a estructurar el pensamiento,
por lo que si nuestros cerebros son sistemas de procesamiento de símbolos cibernéticos, pueden
"reprogramarse" leyendo las secuencias correctas de palabras. El lenguaje y el código afectan o
crean las ideas que se pueden expresar. La dificultad de la codificación nos muestra que las
computadoras no son tan poderosas o fáciles de usar como quisiéramos, y que dan forma a la
existencia humana significativamente para socavar la idea de un núcleo estable para la experiencia
humana. Algunos ejemplos serían las novelas de Burroughs (ya que Burroughs aparentemente cree
que los cortes de texto pueden ayudar a "desprogramar" a los lectores mostrándoles posibilidades
que de otro modo no verían) o Ratner's Star de Don DeLillo, sobre científicos que crean un robot
que habla un lenguaje de programación gratuito de la ambigüedad
La respuesta al código CRU parece mostrarnos que queremos creer que el código solo podría
mostrar la intención de los científicos, aunque podría desviarse de esto debido a errores tipográficos
o de lenguaje desconocidos para el programador. La computación parece ser un bastión del
representacionalismo; aunque ya no confiemos en la transparencia del lenguaje, queremos creer en
la transparencia del código, tal vez porque el conocimiento especializado requerido para escribirlo.
David Porush plantea la teoría de que la cibernética surgió para compensar la incertidumbre de la
física cuántica, y persiste el deseo de que podamos representar procesos u objetos de forma
transparente a través de la informática si no a través del lenguaje o la escritura.

David Noble argues in Forces of Production that computerization doesn’t make workers more
efficient (and he’s not alone). However, the perception of the CRU code as epistemologically
equivalent to the scientists’ calculations suggests to me the persistence of the perception that
computers can be transparent machines - that they can simplify tasks without necessarily altering
the questions that can be asked.
Reply by Jeremy Douglass on February 15, 2010 at 12:35pm
Evan, very interesting observation on the presence or invisibility of code in the literature. If code is
the complex set of contingency strategies where the messy business of science is being effected,
then perhaps that mess is always effaced in the literature, which doesn’t enumerate the many
exceptions thrown, or who (if anyone) will catch them.
As to emphasizing people, not code, I see how you can feel that the second “Debunking” video falls
into this line of argument, and it may, although my sense was that this was not the author’s
intention. On the one hand, the video creator constructs an implied programmer, and makes
arguments about that programmer’s character and intention - and perhaps this is an over-
engagement with the tar-baby of intentionality. Yet this discussion seems to me to be by the wayside
of the debunker’s quite formalist stance, arguing that the code itself will tell us what it does. I see
this formalism signaled early in the objection that critics are relying on an “ad hominem” fallacy:
the programmer’s low opinion of his own work (which extends to logs, comments, etc.) is not proof
that the work itself functions poorly. This is strikingly similar to a New Critical position like
Wimsatt and Beardsley’s “intentional fallacy”, which dismisses the opinion of the author (and
indeed almost banishes the person of the author entirely) as irrelevant distraction from a discussion
of the work itself. Such moves are generally intended to focus attention on formal textual analysis.
Reply by José Carlos Silvestre on February 14, 2010 at 2:45pm
Technical evolution: What’s technical evolution here is sort of ill-defined. I like some theories of
technical evolution - Leroi-Gourhan, and especially Simondon - but I find it non-trivial to apply
them to software. Simondon speaks of a process of concretization: that the technical object starts as
an “abstract” machine (with independent, single-function parts easily reducible to boxes and arrows
on a black board) and then advances to a “concrete” form - in which all parts are interdependent and
cannot be thought of in isolation (so, for example, a component of an engine that had a single
function will also participate later, due to its placement and so forth, in heat dissipation: “In the
modern engine, each critical piece is so connected with the rest by reciprocal exchanges of energy
that it cannot be other than it is.”) According to Simondon, this is not a matter of economic
pressures or some such, but a process intrinsic to technics (“It is not the production-line which
produces standardization; rather it is intrinsic standardization which makes the production line
possible.”) At the same time that the concrete machine is fully integrated, Simondon also argues
that its perfection lies on “concealed margins of indetermination” and its capacity to adapt to and
engage with the environment: not “function by function,” but “synergy by synergy.”
So, as the assembly line is concrete and the artisan’s work is abstract, we could think that the
organization of OOP is more concrete in that everything has to be in its right place and this plays a
certain role, whereas in a language like PHP the single elements can be connected arbitrarily. Also,
high-level languages produce machine code (which is the closest to a “technical object” here) that is
optimized in its arrangement and thus more “concrete.” But then there are the margins of
indetermination and, as it was pointed out, OOP did not interact very well with the demands of the
environment that is the web. I am trying to put the points that were made here regarding technical
evolution in the terms we might inherit from the philosophy of technics.
David Noble argumenta en Forces of Production que la informatización no hace que los
trabajadores sean más eficientes (y no está solo). Sin embargo, la percepción del código CRU como
epistemológicamente equivalente a los cálculos de los científicos me sugiere la persistencia de la
percepción de que las computadoras pueden ser máquinas transparentes, que pueden simplificar las
tareas sin necesariamente alterar las preguntas que pueden hacerse.
Respuesta de Jeremy Douglass el 15 de febrero de 2010 a las 12:35 p.m.
Evan, observación muy interesante sobre la presencia o invisibilidad del código en la literatura. Si
el código es el conjunto complejo de estrategias de contingencia donde se está llevando a cabo el
desordenado negocio de la ciencia, tal vez ese desastre siempre se borre en la literatura, que no
enumera las muchas excepciones arrojadas, o quién (si alguien) las atrapará.
En cuanto a enfatizar a las personas, no al código, veo cómo se puede sentir que el segundo video
de "Desprestigio" cae en esta línea de argumentación, y puede, aunque tengo la sensación de que no
era la intención del autor. Por un lado, el creador de video construye un programador implícito, y
hace argumentos sobre el carácter e intención del programador, y tal vez esto es un exceso de
compromiso con el tar-baby de la intencionalidad. Sin embargo, esta discusión me parece estar al
borde de la postura bastante formalista del detractor, argumentando que el código mismo nos dirá
qué hace. Veo este formalismo señalado al principio de la objeción de que los críticos se basan en
una falacia "ad hominem": la baja opinión del programador sobre su propio trabajo (que se extiende
a registros, comentarios, etc.) no es prueba de que el trabajo funcione mal. Esto es
sorprendentemente similar a una posición Nueva Crítica como la "falacia intencional" de Wimsatt y
Beardsley, que descarta la opinión del autor (y de hecho casi destierra a la persona del autor por
completo) como una distracción irrelevante de una discusión sobre el trabajo en sí. Tales
movimientos generalmente tienen la intención de enfocar la atención en el análisis textual formal.
Respuesta de José Carlos Silvestre el 14 de febrero de 2010 a las 2:45 p.m.
Evolución técnica: la evolución técnica aquí está algo mal definida. Me gustan algunas teorías de la
evolución técnica, Leroi-Gourhan, y especialmente Simondon, pero considero que no es trivial
aplicarlas al software. Simondon habla de un proceso de concretización: que el objeto técnico
comienza como una máquina "abstracta" (con piezas independientes de una sola función, fácilmente
reducibles a cajas y flechas en una pizarra negra) y luego avanza a una forma "concreta", en la cual
todas las partes son interdependientes y no se puede pensar en forma aislada (por lo que, por
ejemplo, un componente de un motor que tenía una sola función también participará más tarde,
debido a su ubicación y demás, en la disipación de calor: "En el motor moderno, cada pieza crítica
está tan conectada con el resto mediante intercambios recíprocos de energía que no puede ser más
de lo que es ".) Según Simondon, esto no es una cuestión de presiones económicas o algo así, sino
un proceso intrínseco a la técnica (" no es la línea de producción que produce la estandarización,
sino que es la estandarización intrínseca la que hace posible la línea de producción. ") Al mismo
tiempo que la máquina concreta está completamente integrada, Simondon también argumenta que
su perfecti sobre las mentiras sobre "márgenes ocultos de indeterminación" y su capacidad para
adaptarse e interactuar con el entorno: no "función por función", sino "sinergia por sinergia".
Entonces, como la línea de montaje es concreta y el trabajo del artesano es abstracto, podríamos
pensar que la organización de OOP es más concreta en cuanto a que todo debe estar en su lugar
correcto y esto juega un cierto papel, mientras que en un lenguaje como PHP el los elementos
individuales se pueden conectar arbitrariamente. Además, los lenguajes de alto nivel producen
código de máquina (que es el más cercano a un "objeto técnico") optimizado en su disposición y,
por lo tanto, más "concreto". Pero luego están los márgenes de la indeterminación y, como se señaló
, OOP no interactuó muy bien con las demandas del entorno que es la web. Estoy tratando de poner
los puntos que se hicieron aquí con respecto a la evolución técnica en los términos que podríamos
heredar de la filosofía de la técnica.

Reply by Jeff Nyhoff on February 14, 2010 at 4:36pm

Implicit in the question “Who reads code?” there is also the question: “Who
doesn’t/shouldn’t/mustn’t read code?”
In the pre-GUI era of personal computing, the “user” identity was one that allowed for a user to at
least be aware of code, perhaps also examine and read code, perhaps also modify code, perhaps also
compose original code.
However, since 1984, the “user” identity was re-manufactured and installed as the “end user” - who,
by definition, doesn’t/shouldn’t/mustn’t read (let alone write) code.
Accordingly, I would suggest also that “code” has become, first and foremost, “something that the
end user doesn’t/shouldn’t/mustn’t see.”
Indeed, I think it might be said that “code” has come to be “ANYTHING that the end user
doesn’t/shouldn’t/mustn’t see.”
Can any conception of “code” in this era responsibly sidestep this implicit “hiddenness” - and, more
specifically, the “hidden-from-end-users-ness” of code, which constrains and interpellates the end
user to the performance of the role of “ideal non-reader” of code?
Reply by Micha Cárdenas / Azdel Slade on February 15, 2010 at 8:35pm
Jeremy, I love your intervention about moving from two types of readers to a multiplicity of
readers. It’s a fundamental part of queer theory, rejecting binary thinking, and it’s been a major part
of my own work, to explore ways of developing new genders outside of make and female. I also
tried to do this a bit last week, but thanks for bringing some more focus to it. Of course, we could
also see a lot of post-structuralism, like Deleuze and Guattari’s rejection of teleology (we’re tired of
trees!) as a way of moving away from a system of thought based on two endpoints and towards a
rhizomatic system branching out in all directions.
But to join in on the project of finding code snippets and code readers that broaden our notions of
who’s reading code, I have two examples.
The first one is in the Second Life Viewer’s open source project’s bug database. The important part
of this snippet and the long discussion surrounding it is the requested function, LLGetGender, and
the many fears this proposed function created among the many different users of Second Life,
including repercussions for social structure, sexual interactions and economic impacts.
The second example I want to share is these two images:
http://vimeo.com/9184862

which show our pure data patch projected onto our bodies before our performances. Its interesting
because before almost every single of our performances of technésexual, we’ve ended up showing
the patch onscreen because we’re trying to get all the parts of the technology to talk to each other.
Many times people ask us if it’s part of the performance or say that they felt like it was part of the
performance. So, that opens up a larger audience of people seeing our code and discussing it with us
as well.
Reply by Andrew Davis on February 23, 2010 at 4:48pm
We take quotes out of context in literature when they represent valuable complete thoughts.
Why isn’t code the same way? There are certainly well-known cases where the context is irrelevant
to understanding the complete thought and value of that thought in a snippet of code. Search for
‘Duff’s Device’ or go directly to http://en.wikipedia.org/wiki/Duff
%27s_devicehttp://en.wikipedia.org/wiki/Duff%27s_device.
It was profound not only because of its innate value in solving one particular problem, but because
it is the equivalent of a Japanese Koan to a professional programmer. It shocks the programmer so
thoroughly they must re-evaluate their understanding of the language it is implemented in. In fact it
was so shocking a juxtaposition of different constructs that several compilers failed to compile it
correctly. It was later added to the test suite of C standards for compliance.
Here is an entire collection of similar ‘valuable’ snippets of code without context
http://graphics.stanford.edu/~seander/bithacks.html. Specifically look for “Counting bits set, in
parallel.”
Every programmer I know learns new things when reading these code snippets. The sudden change
from ‘writing code’ to ‘crafting code’ occurs as they search out ways to apply the new knowledge…
or craft their own to share.
Surely the art or craft of a Koan is not limited to literature. Are there other forms or structural
dialects that repeat à la iambic pentameter, sure. How does one search for the form of code, rather
than the substance of it?
Respuesta de Jeff Nyhoff el 14 de febrero de 2010 a las 4:36 p.m.
Implícito en la pregunta "¿Quién lee el código?", También está la pregunta: "¿Quién no / no
debería / no debe leer el código?"
En la era previa a la interfaz gráfica de usuario de informática personal, la identidad de "usuario"
era aquella que permitía a un usuario conocer al menos el código, tal vez también examinar y leer el
código, quizás también modificar el código, quizás también componer el código original.
Sin embargo, desde 1984, la identidad del "usuario" se volvió a fabricar e instaló como el "usuario
final", que, por definición, no debe / no debe / no debe leer (y mucho menos escribir) el código.
En consecuencia, sugeriría también que el "código" se ha convertido, ante todo, en "algo que el
usuario final no / no debería / no debe ver".
De hecho, creo que podría decirse que el "código" se ha convertido en "CUALQUIER COSA que el
usuario final no / no debería / no debe ver".
¿Puede cualquier concepción de "código" en esta época soslayar de manera responsable este
"ocultamiento" implícito y, más específicamente, el "oculto-de-los-usuarios-finales" del código, que
restringe e interpela al usuario final para el rendimiento del papel de "ideal no lector" de código?
Respuesta de Micha Cárdenas / Azdel Slade el 15 de febrero de 2010 a las 8:35 p. M.
Jeremy, me encanta tu intervención sobre pasar de dos tipos de lectores a una multiplicidad de
lectores. Es una parte fundamental de la teoría queer, que rechaza el pensamiento binario, y ha sido
una parte importante de mi propio trabajo, explorar formas de desarrollar nuevos géneros fuera de la
marca y el sexo femenino. También traté de hacer esto un poco la semana pasada, pero gracias por
traer un poco más de atención. Por supuesto, también podríamos ver un montón de post-
estructuralismo, como el rechazo de Deleuze y Guattari a la teleología (¡estamos cansados de los
árboles!) Como una forma de alejarse de un sistema de pensamiento basado en dos puntos finales y
hacia un sistema rizomático ramificando en todas las direcciones.
Pero para unirme al proyecto de encontrar fragmentos de código y lectores de código que amplíen
nuestras nociones de quién está leyendo el código, tengo dos ejemplos.
El primero se encuentra en la base de datos de errores del proyecto de código abierto de Second
Life Viewer. La parte importante de este fragmento y la larga discusión que lo rodea es la función
solicitada, LLGetGender, y los muchos temores que esta función propuesta creó entre los diferentes
usuarios de Second Life, incluidas las repercusiones para la estructura social, las interacciones
sexuales y los impactos económicos.
El segundo ejemplo que quiero compartir es estas dos imágenes:
http://vimeo.com/9184862

que muestran nuestro parche de datos puro proyectado en nuestros cuerpos antes de nuestras
actuaciones. Es interesante porque antes de cada una de nuestras presentaciones de tecnésexual,
hemos terminado mostrando el parche en la pantalla porque estamos tratando de obtener todas las
partes de la tecnología para que hablen entre sí. Muchas veces las personas nos preguntan si es parte
del rendimiento o dicen que sintieron que era parte del desempeño. Entonces, eso abre una
audiencia más grande de personas que ven nuestro código y lo discuten con nosotros también.
Respuesta de Andrew Davis el 23 de febrero de 2010 a las 4:48 p. M.
Tomamos citas fuera de contexto en la literatura cuando representan pensamientos completos
valiosos.
¿Por qué no es el código de la misma manera? Ciertamente, hay casos bien conocidos en los que el
contexto es irrelevante para comprender el pensamiento completo y el valor de ese pensamiento en
un fragmento de código. Busque "Dispositivo de Duff" o vaya directamente a
http://en.wikipedia.org/wiki/Duff%27s_devicehttp://en.wikipedia.org/wiki/Duff%27s_device.
Fue profundo no solo por su valor innato para resolver un problema en particular, sino porque es el
equivalente de un Koan japonés a un programador profesional. Sorprende al programador tan
profundamente que debe reevaluar su comprensión del lenguaje en el que se implementa. De hecho,
fue tan impactante la yuxtaposición de diferentes constructos que varios compiladores no pudieron
compilarlo correctamente. Más tarde se agregó al conjunto de pruebas de estándares C para el
cumplimiento.
Aquí hay una colección completa de fragmentos de código "valiosos" similares sin contexto
http://graphics.stanford.edu/~seander/bithacks.html. Busque específicamente "Contar los bits
establecidos, en paralelo".
Cada programador que conozco aprende cosas nuevas cuando lee estos fragmentos de código. El
cambio repentino de "escribir código" a "crear código" ocurre cuando buscan formas de aplicar el
nuevo conocimiento ... o crean el suyo propio para compartir.
Sin duda, el arte o la artesanía de un Koan no se limita a la literatura. ¿Hay otras formas o dialectos
estructurales que repiten el pentámetro a layambico, claro? ¿Cómo se busca la forma de código, en
lugar de la sustancia del mismo?

Reply by Jeremy Douglass on March 11, 2010 at 11:21am

Andrew, you ask some challenging questions - and point towards some interesting debates.
Earlier, you mentioned Joel Spolsky’s “The Law of Leaky Abstractions.” That essay argues that
there is an increasing need / obligation / burden for the programmer to understand higher level
languages in terms of how the lower layers actual work - I might paraphrase it as a strong form of
the agurment that code understanding has to happen in context, and that context goes all the way
down (to TCP/IP, the file system, the hard disk platter). Of course, Spolsky doesn’t say you always
need to use this understanding, just that context is crucial at the moments when things “leak.”
Likewise, your example of Duff’s device was (for me) embedded in some very particular contexts -
how certain processes are traditionally handled in assembly, of how they can be optimized for speed
in the context of specific hardware / software performance costs, and how some surprising and for
many unforeseen consequences of the C language specification can address this. I wasn’t familiar
with loop unwinding / loop-unrolling, but even once I understood that I’m not completely confident
I understand that crazy case block.
I’m a big believer in contextual reading and in the power of excerpt and abstraction - that’s why I’m
interested in whether these things are opposites or complements. Sometimes I’ve actually seen the
argument for clear lucid code excerpts presented as a kind of “against code koans”
counterargument. For example, in “Aiming for Cartoon Code First,” Russell Miles proposes such an
opposition - code-as-art is dense, opaque, challenging, rewarding, but most of all just hard to
understand. “Cartoon Code,” on the other hand, is light, transparent, and easy to understand -
although Joel Spolsky might retort that this ease only lasts until the simplicity “leaks.”
What I’m trying to get a handle on is the difference between quotation / excerpting as “out of
context” (I felt I needed a lot of context to understand Duff’s device) and the more general question
you suggest at the end: “How does one search for the form of code, rather than the substance of it?”
Is this form an excerpt, or an abstraction, or something else? When I read this question, my first
association is with “pattern,” specifically as used in books and essays I’ve read on design patterns.
This may be a higher level of abstraction than you were thinking of, but that is my first stab at the
search for form: one design pattern is like a description of the haiku form, while a particular snippet
is like an individual haiku (if it has a form - it may be free verse).
Reply by Andrew Davis on March 11, 2010 at 3:16pm
The competition of in/out of context viewing models is false. When I saw2 Duff’s device for the
first time I had probably already authored 100k LOC and read 1M. So for me, the initial non-
sensical syntax of it was a shock to the system. Then, perhaps after understanding the code flow
through the loop, and it is most definitely a loop first, you start to ask questions about why this was
needed. But the power of this syntax was, in my experience, the thing that started my thinking about
how code is a language and about expression as much as it is a set of instructions for a computer to
execute.
Respuesta de Jeremy Douglass el 11 de marzo de 2010 a las 11:21 a.m.
Andrew, haces algunas preguntas desafiantes y señalas algunos debates interesantes.
Anteriormente, mencionaste "La ley de las abstracciones agujereadas" de Joel Spolsky. Ese ensayo
argumenta que existe una necesidad / obligación / carga creciente para que el programador
comprenda los lenguajes de nivel superior en términos de cómo funcionan las capas más bajas,
podría parafrasearlo como una forma fuerte del agurment de que la comprensión del código tiene
que ocurrir en el contexto, y ese contexto va hasta el fondo (a TCP / IP, el sistema de archivos, el
disco duro). Por supuesto, Spolsky no dice que siempre necesites usar esta comprensión, solo que el
contexto es crucial en los momentos en que las cosas "se filtran".
Del mismo modo, tu ejemplo del dispositivo de Duff estaba (para mí) integrado en algunos
contextos muy particulares: cómo ciertos procesos se manejan tradicionalmente en ensamblaje,
cómo se pueden optimizar para la velocidad en el contexto de costos específicos de rendimiento de
hardware / software y cómo algunos sorprendente y para muchas consecuencias imprevistas de la
especificación de lenguaje C puede abordar esto. No estaba familiarizado con el desenrollado de
bucles / desenrollado de bucles, pero incluso una vez que entendí que no estoy completamente
seguro de que entiendo ese bloque de caso loco.
Soy un gran creyente en la lectura contextual y en el poder del extracto y la abstracción, por eso
estoy interesado en si estas cosas son opuestas o complementarias. A veces he visto el argumento de
extractos de código lúcido claro presentado como una especie de contraargumento "contra códigos
koans". Por ejemplo, en "Aiming for Cartoon Code First", Russell Miles propone una oposición tal:
el código como arte es denso, opaco, desafiante, gratificante, pero sobre todo, es difícil de entender.
El "Código de dibujos animados", por otro lado, es ligero, transparente y fácil de entender, aunque
Joel Spolsky podría replicar que esta facilidad solo dura hasta que la simplicidad "gotee".
Lo que trato de entender es la diferencia entre cita / fragmento como "fuera de contexto" (sentí que
necesitaba mucho contexto para entender el dispositivo de Duff) y la pregunta más general que
sugieres al final: "Cómo ¿Busca uno la forma de código, en lugar de la sustancia de ella? "¿Es esta
forma un extracto, una abstracción o algo más? Cuando leo esta pregunta, mi primera asociación es
con "patrón", específicamente como se usa en los libros y ensayos que he leído sobre los patrones
de diseño. Este puede ser un nivel de abstracción más alto de lo que pensabas, pero esa es mi
primera puñalada en la búsqueda de formas: un patrón de diseño es como una descripción de la
forma de haiku, mientras que un fragmento en particular es como un haiku individual (si tiene una
forma, puede ser un verso libre).
Respuesta de Andrew Davis el 11 de marzo de 2010 a las 3:16 p. M.
La competencia de modelos de visualización dentro / fuera de contexto es falsa. Cuando vi el
dispositivo de 2 Duff por primera vez, probablemente ya había escrito 100k LOC y leí 1M.
Entonces, para mí, la sintaxis inicial no sensorial fue un shock para el sistema. Entonces, quizás
después de comprender el flujo de código a través del ciclo, y definitivamente es un ciclo primero,
comienzas a hacer preguntas sobre por qué fue necesario. Pero el poder de esta sintaxis fue, en mi
experiencia, lo que comenzó mi pensamiento sobre cómo el código es un lenguaje y sobre la
expresión tanto como lo es un conjunto de instrucciones para que una computadora lo ejecute.