[Tradução] – WENDY CHUN, “SOFTWARE: A PERSISTÊNCIA DO CONHECIMENTO VISUAL” (2005)

tradução

Voltar – Sumáriovoltar


SOFTWARE: A PERSISTÊNCIA DO CONHECIMENTO VISUAL

WENDY HUI KYONG CHUN

Originalmente publicado em:  Grey Room 18, Winter 2005, pp. 26–51

Tradução: Ednei de Genaro

* *

image001

Fig.1 – Flip-flop de um master-slave clocked RS

          “Quando dados aparentemente insignificantes são analisados em relação a bilhões de elementos de dados, o invisível torna-se visível” – Seisint.

Em O Êxtase da Comunicação, Jean Baudrillard argumenta que “não mais fazemos parte do drama da alienação, mas do êxtase da comunicação. E este êxtase é obsceno” porque, “na bruta e inexorável luz da informação”, tudo é “imediatamente transparente, visível, exposto” [1]. Embora extrema, a associação entre informação – e, logo, computação – e transparência encontra-se amplamente disseminada tanto entre o público em geral quanto nos meios acadêmicos, diante do medo e da propaganda em torno dos bancos de dados nacionais, examinados pela noção de “sociedade de vigilância”. Tal associação está em evidente desacordo com as operações reais da computação: para que os computadores se tornem máquinas transparentes, é preciso esquecer o fato de que computam – isto é, que geram textos e imagens, em vez de meramente representar ou reproduzir aquilo que existe em outro lugar. Mesmo quando conectados a tubos de vidro, os computadores não permitiam simplesmente ver o que estava do outro lado; antes, utilizavam os tubos para enviar e receber os pulsos de luz necessários para recriar o referente (caso ele exista). A atual proeminência da transparência no design de produtos e nos discursos políticos e acadêmicos constitui um gesto compensatório. À medida que nossas máquinas leem e escrevem crescentemente sem nós, tornando-se cada vez mais ilegíveis, de modo que o ato de ver já não garante o saber (se é que algum dia garantiu), a nós, os chamados usuários, é oferecida cada vez mais a possibilidade de ver, de ler; ao computador – o dispositivo mais não visual e não transparente – fomenta-se, paradoxalmente, mais “cultura visual” e “transparência”. O software – ou, mais precisamente, a curiosa separação entre software e hardware – impulsiona esse gesto compensatório. Ele perpetua certas noções de ver como conhecer, de leitura e legibilidade, que deveriam ter desaparecido com o declínio da indexicalidade. Isso ocorre porque ele mimetiza simultaneamente a ideologia e a crítica da ideologia, confundindo executável com execução, programa com processo, ordem com ação [2]. O software, por meio de linguagens de programação oriundas de um sistema de comando e controle generificado, disciplina programadores e usuários, criando um sistema invisível de visibilidade. O conhecimento do software é, ao mesmo tempo, ofuscante e revelador. Assim, tal como adverte Lev Manovich em The Language of New Media, os estudos de novas mídias precisam abarcar o software, não apenas adotar a linguagem do software, mas examinar criticamente as limitações da “transcodificação” e o novo estatuto do software como senso comum [3].

Materializando o imaterial

O software é, ou deveria ser, um conceito notoriamente difícil. Atualmente, o senso comum da ciência da computação define o software como “um conjunto de instruções que direciona um computador a realizar uma tarefa específica”. Enquanto um conjunto de instruções, seu status material é instável; de fato, quanto mais você disseca o software, mais ele se esvanece. O historiador Paul Ceruzzi compara-o a uma cebola, “com muitas camadas distintas de software sobre um núcleo de hardware” [4]. Esta estrutura acebolada, no entanto, é em si mesma um efeito de programação: codifica-se usando outro programa de software; software e hardware (como genes e DNA) não podem ser fisicamente separados. O cientista da computação Manfred Broy descreve o software como “quase intangível, geralmente invisível, complexo, vasto e difícil de compreender”. Uma vez que o software é “complexo, propenso a erros e difícil de visualizar”, Broy argumenta que muitos dos “pioneiros” procuraram tornar o “software mais fácil de visualizar e compreender, para representar os fenômenos encontrados no desenvolvimento de software a partir de modelos que explicitem as tarefas frequentemente implícitas e intangíveis da engenharia de software” [5]. Friedrich Kittler argumentou de forma mais contundente que “não existe software”, uma vez que tudo se reduz a diferenças de tensão como significantes [6]. Na década de 1940, o software não existia: literalmente não havia software [7]. “Programação” envolvia a tarefa humana de realizar conexões, ajustar chaves e inserir valores (“programação direta”), bem como a tarefa humana e mecânica de coordenar as variadas partes do computador. Em 1946, o programador mestre do ENIAC (o primeiro computador digital eletrônico de uso geral a ser projetado, construído e usado com sucesso) controlava a sequência de ações necessárias para solucionar um problema numérico [8]. Inicialmente, o ENIAC era reconectado por fiação a cada novo problema, de modo que, essencialmente, um novo ENIAC era criado toda vez que era usado. Sua conversão em um computador de programa armazenado, em 1947 (em parte devido a uma sugestão de John von Neumann), significou que os programas poderiam ser codificados configurando-se chaves, as quais corresponderiam a sessenta instruções armazenadas, em vez de conectar cabos. Esta mudança, compreendida como uma forma de abrir a programação para cientistas comuns, diminuiu drasticamente o tempo necessário para a programação, enquanto aumentou o tempo para a computação. Hoje, tais configurações intercambiáveis seriam chamadas de software, porque, com as linguagens simbólicas de programação, as configurações físicas (que, por exemplo, permitiam que um valor X fosse movido da posição de memória Y para o acumulador) tornaram-se traduzíveis para uma sequência de números lidos na memória do computador. Atualmente, as “operadoras” clericais que planejavam a fiação e conectavam o ENIAC (Kathleen McNulty, Frances Bilas, Betty Jean Jennings, Elizabeth Snyder, Ruth Lichterman e Marlyn Wescoff) são reivindicadas como algumas das primeiras programadoras. Linguagens simbólicas de programação e, portanto, o software, como Ceruzzi e Wolfgang Hagen têm argumentado, não foram previstos. A emergência da linguagem simbólica de programação dependeu da percepção de que o computador poderia armazenar instruções numéricas tão facilmente quanto dados, e de que o próprio computador poderia ser usado para a tradução entre notações simbólicas e numéricas. Os programadores do EDSAC, um computador pioneiro (1949) de Cambridge, Inglaterra, foram os primeiros a usar o computador para a tradução entre um código de montagem (assembly) mais humanamente legível (por exemplo, “A100” para “adicione o conteúdo da posição 100 ao registrador de adição”) e o que desde então é chamado de linguagem de máquina (em vez de um código lógico). O armazenamento foi a chave para a emergência das linguagens de programação; contudo, como o estudo de John von Neumann revelou, o armazenamento não era suficiente: von Neumann, cujo nome se tornou o descritor para todos os computadores modernos de programa armazenado, também idealizou uma notação semelhante à do EDSAC com Herman Goldstine, mas assumiu que escriturários fariam a tradução [9]. Além disso, a linguagem assembly não é uma linguagem de programação de alto nível; um computador não é automaticamente uma máquina midiática. De acordo com Hagen, “por décadas, a arqueo-estrutura da máquina de von Neumann não revelou que essa máquina seria mais do que uma nova calculadora, mais do que uma ferramenta poderosa para o trabalho mental, a saber, um novo meio de comunicação”. A mudança da calculadora para o meio de comunicação, Hagen assevera, decorreu em si mesma de um “imperativo de comunicação” que:

cresceu na Guerra Fria, fora do econômico, fora da organização de trabalho, talvez fora da sedução numérica primitiva que as máquinas exercem, fora dos jogos numéricos, fora dos jogos com dígitos, dos espaços reservados, dos mecanismos, e de todo quid pro quo quase-linguístico da estrutura interior de todas estas origens [10].

image002
Fig.2 – Capitan Grace M. Hopper, 1976. U.S. Navy Photo (número NH 96945), Naval Historical Center, Washington, D.C.
image003
Fig. 3 – “Bug”, o primeiro computador, 1945. U.S. Navy Photo (número NH 96566-KN), Naval Historical Center, Washington, D.C.
 

Programação automática

Programação automática, o que chamamos hoje de programação, emergiu do desejo de reutilizar o código e integrar o computador em sua própria operação – isto é, de transformar instruções singulares em uma linguagem na qual o computador pode escrever. Tal como Mildred Koss, uma antiga programadora do UNIVAC, explica:

Escrever códigos de máquina envolveu passos rígidos e tediosos, desmembrando processos em instruções discretas, atribuindo locais específicos de memória para todos os comandos e gerenciando os buffers de E/S. Depois de seguir esses passos de implementação de rotinas matemáticas, de bibliotecas de sub-rotinas e de classificação de programas, nossa tarefa foi examinar o processo mais amplo de programação. Nós precisávamos entender como poderíamos reutilizar o código testado e fazer a máquina auxiliar na programação. Enquanto programávamos, examinamos o processo e tentamos pensar em modos de abstrair essas etapas, incorporando-as na linguagem de alto nível. Isto nos levou a desenvolver interpretadores, montadores (assemblers), compiladores e geradores – programas planejados para operar ou produzir outros programas, isto é, programação automática [11].

Programação automática é uma abstração que permite a produção de código legível por humanos, ativado por computador – chave para a comodificação e a materialização do software, e para a emergência da linguagem de programação de alto nível. A automação da programação – em particular, as linguagens de programação – faz com que o problema da programação deixe de ser orientado ao hardware e passe a ser orientado textualmente. Linguagens de programação de alto nível, a despeito do agenciamento da linguagem, disparam uma instrução, permitindo esquecer a máquina; permitem focar mais no programa do que na máquina. A “programação direta” permitia uma configuração única de cabos; as primeiras linguagens de máquina podiam ser iteráveis, mas somente em uma mesma máquina – assumindo, é claro, que não houvesse erro ou defeito na engenharia. De modo a constituir-se como linguagem ou texto, o software e as “linguagens” nas quais se baseiam devem se tornar iteráveis. Com as linguagens de programação, o produto programado não é mais uma máquina em execução, mas sim essa coisa chamada software – algo teoricamente (se não praticamente) iterável, repetível, reutilizável, não importando quem o escreveu ou a qual máquina foi destinado. As linguagens de programação denotam a ausência do programador e da máquina naquilo que se chama escrita [12]. As linguagens de programação permitiram a separação entre instrução e máquina, entre imperativo e ação.

A partir da sabedoria adquirida, as referidas primeiras tentativas de automatizar a programação foram ineficientes e combatidas por programadores “reais”. John Backus, desenvolvedor do FORTRAN, afirma que os primeiros programadores de linguagem de máquina estavam envolvidos em uma “magia negra”; eles tinham um “orgulho chauvinista de suas fronteiras de exploração e um correspondente conservadorismo; muitos programadores da década de 1950 começaram a se considerar membros de um sacerdócio que guardava habilidades e mistérios muito complexos para os meros mortais” [13]. Koss argumenta ainda que, “sem essas linguagens e processos de níveis superiores […], que democratizaram a solução de problemas com o computador, acredito que a programação teria permanecido nas mãos de um número relativamente pequeno de criadores de software de orientação técnica, usando código de máquina, sendo então essencialmente os altos sacerdotes da computação” [14].

A resistência à programação automática também parece ter sido engendrada pelos clientes corporativos e acadêmicos, para os quais os programadores eram ordens de magnitude mais baratos que os computadores. Jean Sammet, programadora precursora, em sua influente obra Programming Languages: History and Fundamentals, relata que:

…os clientes levantaram muitas objeções, a principal delas foi que provavelmente o compilador não poderia produzir um código-objeto tão bom quanto seus melhores programadores. Uma significativa campanha de marketing para promover as vantagens de tais sistemas estava em andamento naquele momento, com a ponta de lança sendo realizada para as linguagens numéricas científicas (ou seja, FORTRAN) da IBM e para as linguagens de processamento de dados comerciais na linguagem “de tipo inglês” da Remington Rand (e da Dra. Grace Hopper, especialmente) [15].

Tal campanha de marketing não apenas incrementou as linguagens de alto nível (desvalorizando os processos humanos de produção), mas também alavancou novos hardwares: para rodar estes programas, precisavam de máquinas mais poderosas. A insistência do governo na padronização, de forma mais evidente no desenvolvimento e disseminação do COBOL, também influenciou fortemente a aceitação de linguagens de alto nível, as quais eram, de novo, teoricamente, se não sempre praticamente, independentes de máquina e iteráveis. O ciclo de atualização do hardware era normalmente resultado do acúmulo do tempo de programação.

A “campanha de marketing” levou ao que muitos expressaram como a democratização da programação. Na visão de Sammet, essa era uma revolução parcial,

…uma vez que instalações de computadores operavam, não somente se tornou, mas também ficou bastante prático ter engenheiros, cientistas e outras pessoas realmente programando seus próprios problemas sem o intermédio de um programador profissional. De tal modo, a discussão entre a política de laboratório aberto (open shop) e laboratório fechado (closed shop) tornou-se muito forte, muitas vezes centrando-se no uso do FORTRAN como figura-chave para os dois lados. Tal fato não deve ser interpretado como uma afirmação de que todas as pessoas com problemas numéricos-científicos a serem resolvidos dispuseram-se prontamente a aprender FORTRAN. Isso realmente não é verdade. Mas um número significativo de pessoas dispôs-se, e tal fato causou um grande impacto em toda a indústria de computadores. Um dos efeitos colaterais subsidiários do FORTRAN foi a introdução do FORTRAN Monitor System [IB60], tornando a operação do computador muito mais eficiente, e exigindo menos intervenção do operador para a execução do grande número de programas FORTRAN (assim como da linguagem de máquina) [16].

A “abertura” da computação, por meio da qual se produziu uma ressonância distinta do termo open em “open source”, teria denotado tanto um alento à disseminação da computação entre aqueles com problemas numérico-científicos a resolver como um declínio das operações realizadas por humanos frente aos sistemas operacionais. Contudo, cientistas sempre estiveram envolvidos em computação, ainda que a computação nem sempre fosse considerada uma carreira cientificamente digna e, como referido anteriormente, a maior introdução de chaves (dials) do que de fios (wires) foi vista como favorecimento de cientistas comuns. A história da computação é cheia de momentos de “libertação dos computadores” [17].

Tal narrativa de “abertura” da computação através de linguagens de alto nível pressupõe que os programadores naturalmente gostavam de tarefas numéricas tediosas e repetitivas, desenvolvendo soluções singulares para seus clientes. O “domínio” da computação pode ser facilmente percebido como “sofrimento”. Harry Reed, um dos primeiros programadores do ENIAC, argumenta:

Toda a ideia de computação com o ENIAC era uma espécie de camisa de força. Programar para o computador, o que quer que isso significasse, era uma experiência penitencial – sofria-se para tanto. E foi somente na década de 1970 que finalmente conseguimos convencer as pessoas de que elas não precisariam de programadores continuamente escrevendo pequenos programas para elas. Na verdade, eu tive que pegar meu Departamento e colocar sentado todo mundo que não tinha ainda feito um curso de FORTRAN, porque, meu Deus, eles escreveriam seus próprios programas agora. Não íamos pedir aos especialistas em computação que escrevessem os programas pequenos e simples que eles mesmos deveriam estar escrevendo [18].

image004
Fig. 4 – Duas mulheres conectando um novo programa no lado direito do ENIAC, final da década de 1940. U.S. Army Photo, Army Research Laboratory Technical Library, Aberdeen Proving Ground, Aberdeen, Maryland.

A narrativa da democratização da programação revela a tensão no centro dos sistemas de programação e controle: eles são sistemas de comando ou servomecanismos (nome inicialmente dado por Norbert Wiener)? Programação é uma atividade clerical ou um ato de comando? Dado que a máquina lida com a “programação propriamente dita” [programming proper] – a sequência de eventos durante a execução –, a programação da programação constitui alguma coisa? O que está subsumido na mudança linguística de “operador” para “programador”? A noção de um “sacerdócio” de programadores oblitera essa tensão, fazendo parecer que a programação sempre foi objeto de uma tutela zelosa, esquecendo suas origens clericais. Na década de 1950, a programação não parece ter sido nem divertida nem equilibrada em termos de gênero, em parte porque era uma invenção muito recente e também porque não era lucrativa em comparação com o projeto e a venda de hardware [19]. As “garotas do ENIAC” foram inicialmente contratadas como subprofissionais, e algumas precisavam adquirir mais qualificações para se firmarem em suas posições. À medida que muitas mulheres programadoras se retiravam para ter filhos ou se casavam, os homens assumiam seus postos de trabalho cada vez mais lucrativos. As bases auxiliares e eminentemente femininas da programação – tanto em termos de pessoal quanto de estrutura de comando – foram obscurecidas quando a programação começou a se tornar, ao mesmo tempo, um campo acadêmico e de engenharia. Tal supressão foi fundamental para a profissionalização da programação – um domínio compensatório edificado sob a ocultação da máquina. A democratização não substituiu os programadores profissionais, mas reforçou suas posições como profissionais, diminuindo paradoxalmente seu poder real sobre suas máquinas e generalizando o conceito de engenharia da informação.

 

Sim, Senhor

A presunção de que os programadores realizam facilmente tarefas tediosas aponta para a história humana e de gênero da programação e da computação. Durante a Segunda Guerra Mundial, quase todos os computadores humanos eram mulheres jovens com alguma formação em matemática. As mulheres não estavam apenas disponíveis para o trabalho, como também eram consideradas melhores e mais conscienciosas computadoras, provavelmente porque eram tidas como mais adequadas para tarefas repetitivas e clericais. As programadoras eram antigas computadoras, sendo consideradas mais aptas para preparar suas sucessoras mecânicas: elas pensavam como os computadores.

image005
Fig. 5 – Programadores do ENIAC, final da década de 1940. U.S. Military Photo, Redstone Arsenal Archives, Huntsville, Alabama.

Alguém pode afirmar que a programação tornou-se programação e o software tornou-se software quando os comandos mudaram do comando da “garota” para o comando da máquina. A imagem acima (fig. 5) revela o sonho de uma “programação adequada” – um homem sentado à mesa dando comandos para uma mulher “operadora” [20]. As linguagens de software são baseadas em uma série de imperativos derivados da estrutura de comando e controle da Segunda Guerra Mundial. A automação do comando e controle, que Paul Edwards identificou como um desvio das tradições militares, de “liderança pessoal, de comando descentralizado no campo de batalha e de autoridade baseada na experiência”, provavelmente começou como computação mecânica durante a Segunda Guerra Mundial. Isso é intimamente exemplificado pelo relacionamento entre os Wrens, os membros voluntários do Women’s Royal Naval Service, e seus oficiais comandantes em Bletchley Park. Os Wrens, também chamados de escravos por Alan Turing (um termo agora incorporado nos sistemas de computadores), eram funcionários responsáveis pela operação mecânica das máquinas de análise criptográfica (o Bombe e o Colossus), embora pelo menos uma das funcionárias, Joan Clarke, tenha se tornado analista. Reveladoramente, I. J. Good, um analista, descreve o Colossus como permitindo, somente no final da década de 1970, uma sinergia de máquinas duplicadas por máquinas modernas: “o analista sentava-se à máquina de escrever e atribuía instruções para um Wren fazer alterações nos programas. Algumas outras instruções eram reduzidas a árvores de decisão e entregues aos operadores de máquinas (Wrens)” [21]. Esta sinergia homem-máquina, ou processo de interação em tempo real (mais do que por processamento em lotes), tornou indistinguíveis os Wrens e as máquinas, enquanto, simultaneamente, contava com a habilidade dos Wrens em responder a ordens matemáticas.

A história do encontro inicial entre Grace Hopper (uma das primeiras e mais importantes programadoras) e Howard Aiken apoia a narrativa acima. Hopper, doutora em matemática por Yale University e anteriormente professora de matemática de Vassar College, foi contratada pela Marinha Americana para programar o Mark I, um computador digital eletromecânico que fazia um som parecido com o de uma sala cheia de agulhas de tricô. De acordo com Hopper, Aiken mostrou para ela: um objeto largo com três listras… Acenou com a mão e disse: “Isto é uma máquina computacional”. Eu disse, “Sim, Senhor”. O que mais eu poderia dizer? Ele disse que gostaria que eu fizesse os cálculos dos coeficientes das séries de tangentes, para quinta-feira. De novo, o que eu poderia dizer: “Sim, Senhor”. Eu não sabia absolutamente o que estava acontecendo, mas foi assim meu encontro com o Howard Hathway Aiken [22].

A computação dependia do “sim, senhor” nas respostas às sentenças declarativas curtas e imperativas, que eram a essência dos comandos. Ao contrário do que dizia Neal Stephenson, no começo era o comando em vez da linha de comando. A linha de comando é uma mera simulação de sistema operacional (OS). Os comandos permitiriam a oscilação entre programação e ação, algo que faz do software um sistema de comunicação tão persuasivo, mas logicamente “trivial”. As lembranças de I. J. Good e Hopper também revelam a rotinização no centro da programação: o analista de Bletchley Park logo foi substituído por árvores de decisão. Hopper, a programadora, tornou-se uma defensora da programação automática. Assim, a rotinização ou a automação esteve no centro de uma profissão que julgou ter automatizado com sucesso todas as profissões, exceto a sua [23].

Contudo, pensar as mulheres e a computação mecânica como algo intercambiável é reescrever a história. De acordo com Sadie Plant, a programação é essencialmente feminina – não simplesmente porque as mulheres, de Ada Lovelace até Grace Hopper, foram as primeiras programadoras, mas por conta dos laços históricos e teóricos entre programação e o que Sigmund Freud chamou de invenção fundamentalmente feminina da tecelagem; entre a sexualidade feminina como imitação e a imitação que alicerçou a visão de Alan Turing dos computadores enquanto máquinas universais. (Ademais, tanto o software como a sexualidade feminina revelam o poder contido naquilo que não se pode ver) [24]. Mulheres, Plant assevera,

não tinham apenas parte menor para executar durante a emergência das máquinas digitais… Sobre elas, não é um papel secundário que precisa ser resgatado para a posteridade, ou um pequeno complemento a ser incluído nos registros existentes… Hardware, software, wetware – antes e depois, dos inícios aos fins, as mulheres têm sido simuladoras, montadoras e programadoras de máquinas digitais [25].

A fotografia anterior (fig. 5) não é representativa – a programadora do ENIAC trabalha em dupla, e a máquina não poderia fazer o que Hopper fazia – pelo menos não naquele momento. (E, novamente, Hopper teria sido a chave para habilitar os computadores: a redução da distância entre Hopper e os computadores teria sido a chave para os comandos e controles automáticos). A dificuldade encarada pelos programadores era clara: computadores não eram computadoras. A passagem entre comandar uma garota e comandar um autômato era difícil porque os autômatos decifram em vez de interpretar ou inferir, e eles não aprendem com a experiência. Tal como notam Martin Campbell-Kelly e William Aspray, “a principal dificuldade da escrita de software era que, até a vinda dos computadores, os seres humanos nunca antes tinham preparado instruções detalhadas para um autômato – uma máquina que obedecia infalivelmente aos comandos que lhe eram dados e para a qual todos os resultados possíveis tinham que ser previstos pelo programador” [26]. Campbell-Kelly e Aspray superestimam, em suas avaliações, a confiabilidade das máquinas, especialmente em relação às primeiras. Conforme relatam os primeiros programadores do ENIAC, parte da depuração consistia em descobrir quais erros surgiam da programação e quais surgiam dos tubos de vácuo defeituosos, dos religamentos acidentais ou das falhas de arquitetura da máquina – uma tarefa facilitada pelas lâmpadas de neon conectadas a vários contadores.

Ao contrário das máquinas, as programadoras não seguiam simplesmente as instruções. Hopper foi descrita como “uma mulher de personalidade forte, bastante persuasiva e líder. Ela mostrou parte de seu treinamento na Marinha na forma como dava comandos” [27]. Além disso, como explica Koss, a programação não consistia apenas em implementar instruções, mas em “projetar uma estratégia e preparar instruções para fazer com que o computador fizesse aquilo que você gostaria que ele fizesse para resolver um problema” [28]. As programadoras cumpriram um papel importante na conversão do ENIAC em um computador de armazenamento programado e na determinação do equilíbrio entre armazenar valores e instruções. Betty Holberton, descrita por Hopper como a melhor programadora que ela conheceu, não apenas depurou o programa de trajetória balística em um sonho (o primeiro programa a ser executado no ENIAC, embora tenha sido tarde demais para ser usado na Segunda Guerra Mundial), mas também desenvolveu um influente algoritmo de classificação para o UNIVAC [29].

A extensão do esquecimento de tais mulheres na habitual história da computação pode ser medida implicitamente em Paul Edwards, no gênero a priori da “força de trabalho”, enquanto uma análise da perspicácia da relação entre masculinidade e programação. Ele escreve:

Cientistas da computação adoram a mística do hard mastery de forma comparável ao culto dos físicos no pós-guerra. Computadores fornecem precisão espantosa, poder de cálculo, e habilidade para síntese de uma montanha de dados… Não há nada inerentemente masculino nas tecnologias computacionais. De outro modo, as mulheres não poderiam ter tido tão rápido sucesso em se juntar à força de trabalho com o computador. Valores de gênero seguem largamente livres das máquinas em si mesmas e são expressas e reforçadas por relações de poder entre homens e mulheres. Computadores não são simplesmente incorporações de masculinidades; eles são construídos culturalmente enquanto objetos mentais masculinos [30].

Bem longe do juízo de J. Chuan Chu, do qual o software seria filha do Frankenstein (hardware sendo o filho), a posição de Paul Edwards esquece a presença das mulheres no nascimento da computação – enquanto aquele reduz a tecnologia da computação ao software. Na combinação de um humano servil e um humano computador, o computador moderno encapsula as relações de poder entre homens e mulheres na década de 1940, procurando ajustar-se às mulheres: seus dedos ágeis, suas habilidades numéricas, suas discrições, seus “olhares inquietos” – um deslocamento que Vannevar Bush via como desejável [31]. A transição de humanos para computadores mecânicos automatizou as relações diferenciais de poder.

O reconhecimento de tais mulheres enquanto programadoras – não apenas seguindo, mas também organizando instruções – é importante, mas não suficiente, uma vez que mantém a narrativa da programação como “masterful” *. Qual é o significado de seguir e implementar instruções? Talvez a “automação” do controle e comando seja menos um desvio da tradição militar e mais uma representação dela, na qual a responsabilidade foi passada àqueles (agora máquinas) que implementam comandos. A relação entre senhores e escravos é sempre ambígua. Essa passagem de poder foi ocultada por linguagens de programação que obscureciam a máquina e destacavam a programação (em vez da execução) como a fonte de ação. A abolição da distinção entre programação e execução, evidenciada na ambiguidade do objeto do verbo “programar”, foi facilitada pela disciplina e profissionalização das programadoras, através da “programação estruturada”.

image006
Fig. 6 – As Primeiras Quatro, 1950s. U.S. Army Photo (número 163-12-62)
 

Ocultando a máquina

Durante a exaustivamente discutida “crise do software” no fim da década de 1960, determinada por desastres espetaculares, como o do OS/360 da IBM, muitos (especialmente cientistas da computação europeus, tais como Friedrich Bauer e Peter Naur) viram a “engenharia de software”, ou a programação estruturada, como um caminho para transformar a programação de uma atividade artesanal em uma prática de padrão industrial, bem como uma maneira de criar programadores disciplinados que lidariam com abstrações em vez de processos numéricos [32]. Como argumentou Michael Mahoney, a programação estruturada apareceu como um “meio tanto de controle de qualidade quanto de disciplina dos programadores; tanto de método de controle e estimativa de custo como de método de verificação e validação, técnicas de garantia de qualidade” [33].

“Programação estruturada” (conhecida comumente como “boa programação”) oculta e, portanto, protege a máquina. Não é surpresa que, tendo pouco ou nenhum contato com a máquina real, ela venha a favorecer mais o pensamento abstrato do que o numérico. Edsger Dijkstra, aquele cuja famosa condenação da declaração go to encapsulou tantos fundamentos da programação estruturada, acreditava ser capaz de ser um pioneiro de tal programação precisamente porque começou sua carreira de programador codificando para máquinas que ainda não existiam [34]. Em “Go To Statement Considered Harmful”, Dijkstra expõe que: a qualidade de um programador é uma função decrescente da densidade de declarações go to nos programas por ele produzidos. Isso ocorre porque as declarações go to contrariam o princípio fundamental da boa programação – a necessidade de “diminuir a lacuna conceitual entre o programa estático e o processo dinâmico, tornando a correspondência entre o programa (espalhado no espaço do texto) e o processo (espalhado no tempo) o mais trivial possível” [35]. Mais especificamente, se um programa é interrompido, os go to tornam difícil encontrar o ponto no texto do programa que corresponde ao processo interrompido – isto faz com que seja “terrivelmente difícil encontrar um conjunto de coordenadas conceituais a fim de descrever o progresso do processo”. Isto é, os go to tornam difícil a junção entre instrução e comando, que fundamenta a “programação” [36].

As linguagens de programação estruturada “salvam” os programadores deles mesmos, impondo tipos de dados e caminhos de execução estritos [37], nos quais a programação, como uma questão de fluxo de controle, é em si mesma uma forma de fornecer abstração de dados; enquanto questão de encapsulamento e ocultação de informação, a programação é concebida para além da máquina. A abstração de dados depende da ocultação de informações (information hiding), do obscurecimento intencional de fatos no software. Tal como explica John Guttag, um dos pioneiros no tema, a abstração de dados trata fundamentalmente do esquecimento [38]. Em vez de “poluir” um programa ao permitir caminhos invisíveis de comunicação entre módulos supostamente independentes, a abstração de dados apresenta uma interface limpa ou “bela”, ao confinar especificidades e ao reduzir o poder e o conhecimento do programador. O conhecimento, Guttag insiste, é perigoso: “Beba profundamente, ou não prove a Fonte de Pieria”*, não é necessariamente um bom conselho. Conhecer demais não é melhor, e às vezes é pior, do que conhecer de menos. Os seres humanos não conseguem absorver muita informação. Qualquer método ou abordagem de programação que pressupõe que as pessoas compreenderão muita coisa é altamente arriscado [39].

De tal modo, a abstração tanto empodera o programador quanto insiste em sua ignorância. Isto porque a abstração fornece aos programadores uma nova habilidade criativa. O cientista da computação David Eck argumenta: toda linguagem de programação define uma máquina virtual, para a qual ela é a linguagem de máquina. Os projetistas de linguagens de programação estão criando máquinas de computar tanto quanto os engenheiros que trabalham com silício e cobre; contudo, sem as limitações impostas pelos materiais físicos e pelas tecnologias de fabricação [40]. Tal abstração – de afastamento das especificidades da máquina – garante, na separação da máquina em hardware e software, o ato de programar a máquina em si. Koss ironizou a antiga noção de computadores como cérebros eletrônicos, porque “eles não podem pensar da forma como os seres humanos pensam, mas precisam receber um conjunto de instruções passo a passo antes que possam fornecer respostas a um problema específico” – naquela época, o software não era considerado um objeto independente [41]. O atual status do software como mercadoria, apesar do fato de suas instruções serem imateriais e infinitamente replicáveis, indica o triunfo da indústria de software, uma indústria que primeiro se assegurou não somente financeiramente, mas também na definição conceitual de seu produto. A ascensão do software dependeu tanto de um movimento histórico, expressivamente na separação entre serviços e produtos da IBM (unbundling), como da viabilização de abstrações por linguagens de alto nível. A insistência de Guttag na falta de confiabilidade e na limitação de compreensão dos seres humanos justifica os custos dessas abstrações. A abstração é um truque computacional, tal como é a programação, no sentido estrito da palavra.

Importa que os programadores sejam usuários: eles criam programas usando editores de texto, que são eles mesmos softwares. A distinção entre programadores e usuários é gradativamente erodida, não somente porque os usuários se tornam programadores (na prática, os programadores não mais constroem computadores; eles apenas codificam), mas também porque, com as linguagens de alto nível, os programadores agem mais como meros usuários. A diferença entre usuários e programadores é, ela mesma, um efeito do software.

Prazer causal

O gradual descrédito dos programadores foi sendo compensado pelo poder e prazer de programar. Como Paul Edwards assevera, a “programação pode produzir uma forte sensação de poder e controle”, porque o computador produz um microcosmo consistente e externamente incompleto.

Um mundo simulado, inteiramente dentro da própria máquina ou de sua eficácia instrumental. Ou seja, enquanto a maioria das ferramentas produz efeitos em um mundo mais extenso do qual elas são apenas uma parte, o computador contém seu próprio mundo em miniatura… No seu microcosmo, assim como no faz de conta das crianças, o poder de programar é absoluto [42].

Tal prazer é em si mesmo um efeito das linguagens de programação, que oferecem a sedução da visibilidade, da legibilidade, da causa e efeito. Considere o onipresente programa “hello world”, escrito em C++ (“hello world” é geralmente considerado o primeiro programa escrito por uma pessoa):

// this program spits out “hello world” #include <iostream.h> int main () { cout << “Hello World!”; return 0; }

A primeira linha é uma linha de comentário, explicando ao leitor humano que este programa imprime “hello world”. A próxima linha direciona o pré-processador do compilador a incluir “iostream.h”, um arquivo de cabeçalho padrão que lida com entrada e saída. A terceira linha, “int main ()”, inicia a função principal do programa; “cout << “Hello World!”;” imprime “Hello World” na tela (“cout” é definido em iostream.h); “return 0” finaliza a função principal e faz com que o programa retorne 0 se tudo correu bem. Mesmo que não seja imediatamente compreensível para alguém não versado em C++, este programa, de qualquer modo, parece fazer algum sentido. Ele resume uma série de imperativos e declarações que o computador presumivelmente entende e obedece. Quando executado, ele segue os comandos e exibe “Hello World”. Importa que tal mensagem, que afirma a agência do programador, também desvele uma questão: quem ou o que, afinal de contas, está dizendo “Hello World”? Para apreciar este poder absoluto, o programador precisa seguir as regras da linguagem de programação. Independentemente disso, ver o código, visível e amplamente previsível, gera prazer nele ou nela [43]. O código faz com que uma ação aconteça: causa e efeito ficam claros, mesmo se o resultado é inteiramente previsível. Tal poder absoluto, habilitado por meio da agência de um programa, revela o contraditório estado da agência, sobretudo pelo fato de que a agência refere-se tanto à capacidade de ação de alguém como à capacidade de alguém agir em nome de outrem.

No entanto, no microcosmo da simulação computacional, não é somente o programador que tem o poder aperfeiçoado e absoluto – as simulações interativas, fundamentais para o conceito de computadores como transparentes, aumentam o poder do usuário (de novo, estes termos não são absolutos, mas dependem do software que está sendo usado e do poder produtivo de suas ações). Como ressalta Paul Edwards, a interatividade está intimamente ligada à inteligência artificial, gestada pela admissão da falibilidade humana e das limitações das linguagens de programação procedurais [44]. Na década de 1960, a ingenuidade por trás da afirmação de John von Neumann de que “qualquer coisa que pode ser exaustiva e inequivocamente descrita, qualquer coisa que pode ser completa e inequivocamente disposta em palavras, é ipso facto realizável por uma adequada rede neural finita” estava tornando-se cada vez mais manifesta [45]. Uma vez que era complicado, senão impossível, uma descrição exaustiva e inequívoca, a chave para resolver os problemas era trabalhar “interativamente” com o computador. A interatividade mais tarde tornou-se associada à liberdade do usuário, ao controle da GUI (Graphical User Interface) e à interface WYSIWYG (What You See Is What You Get), vistas como suplementos aos comandos baseados em linguagens de programação. Diferentemente das interfaces de linha de comando, as GUIs habilitavam a “manipulação direta”, na qual o comando estava intimamente ligado à visibilidade simulada. De acordo com Ben Shneiderman:

Certos sistemas interativos geram intenso entusiasmo entre os usuários – em marcante contraste com a reação mais comum de aceitação relutante ou de hostilidade total. Os relatos entusiasmados dos usuários são preenchidos com sentimentos positivos, ressaltando:

  • domínio do sistema;
  • competência no desempenho de sua tarefa;
  • facilidade em aprender o sistema originalmente e em assimilar recursos avançados;
  • confiança em sua capacidade de manter o domínio ao longo do tempo;
  • prazer em usar o sistema;
  • vontade de mostrá-lo aos novatos; e
  • desejo de explorar aspectos mais poderosos do sistema

Tais sentimentos não são, é claro, universais, mas o amálgama expõe uma imagem de real prazer do usuário… As ideias centrais parecem ser a visibilidade do objeto de interesse; de ações rápidas, reversíveis e incrementais, substituindo uma complexa sintaxe de linguagem de comando pela manipulação direta de objetos de interesse – daí o termo “manipulação direta” [46].

Como Brenda Laurel argumentou, em sua comparação de interfaces de computador e teatro, a manipulação direta (que é tudo menos direta), para ser bem-sucedida, deve ser complementada por engajamento direto. O engajamento direto, argumenta Laurel,

muda o foco da representação da manipulação de objetos para o ideal de permitir que as pessoas se engajem diretamente na atividade de escolha, seja manipulando ferramentas simbólicas no desempenho de algumas tarefas instrumentais ou perambulando pelo mundo imaginário de um jogo de computador. O engajamento direto enfatiza valores emocionais e cognitivos. Concebe, pois, a atividade humano-computador como uma experiência projetada [47].

A ênfase de Laurel na ação ressalta a crucial diferença entre a representação de ferramentas e as ferramentas em si mesmas: ela argumenta que o que as pessoas percebem quando clicam duas vezes em uma pasta não é realmente uma pasta; e fazer com que uma pasta seja mais “realista” não ajuda. O que ajuda, expressa Laurel, é uma causalidade clara: eventos precisam de um padrão para que o usuário possa aceitá-los como prováveis, reduzindo a probabilidade à certeza. A causalidade, ela afirma, garante a universalidade; garante que o usuário suspenda voluntariamente sua descrença. Para os usuários, assim como para os esquizofrênicos paranoicos (aqui minha observação, não a de Laurel), tudo tem sentido: não há coincidência, somente prazer causal.

O prazer causal não é simplesmente uma representação das ações de um usuário; é também uma “amplificação do usuário”. Lev Manovich explica a “amplificação do usuário” a partir do Super Mario:

quando você pede, movendo o joystick, que o Mario dê um passo à esquerda, isto dá largada a uma pequena e deliciosa narrativa: Mario encontra-se diante de uma colina; ele começa a subir a colina; a colina acaba sendo muito alta; Mario volta ao chão; Mario levanta-se, todo tremendo. Nenhuma dessas ações requer algo de nós; tudo o que temos de fazer é mover uma vez o joystick. O programa de computador amplifica nossas ações singulares, expandindo-as em uma sequência narrativa [48].

Tal ampliação do usuário mimetiza a “explosão de instruções” que levou às linguagens de alto nível (uma linha de código de alto nível corresponde a mais de uma linha de código de máquina); a amplificação do usuário não é somente produto de softwares de jogos ou de arte, mas central para o poder de programação.

A dupla ampliação provavelmente impulsiona a romantização da programação e, mais recentemente, a emergência do software de arte, ou Generation Flash. De acordo com Manovich, a Generation Flash é um novo grupo artístico (“novos românticos”) que cria códigos originais em vez de participar do círculo infinito de citações pós-modernas. Enquanto programadores, os artistas da Generation Flash produzem:

o novo modernismo de visualização de dados, de redes vetoriais, de pixels precisos, setas, grades: o design da Bauhaus a serviço do design da informação. Em vez do assalto barroco à mídia comercial, a Generation Flash serve-nos com a estética modernista e a racionalidade do software. O design da informação é usado como ferramenta para fazer sentido da realidade, enquanto a programação se torna uma ferramenta de empoderamento [49].

Para dar sentido à realidade, tais artistas e designers empregam a ampliação do usuário; para eles, a estética modernista e a racionalidade baseada em software ampliam e simplificam causa e efeito. De maneira geral, o software desvela – torna as coisas visíveis. Esse desvelamento depende de certa “esperteza” da parte do usuário. Descrevendo o projeto Futurefarm do theyrule.net, que oferece um modo de mapear as relações entre os membros conselheiros das corporações mais poderosas, Manovich assevera:

Em vez de apresentar uma mensagem política empacotada, ele nos dá dados e ferramentas para análise. Sabe que somos suficientemente inteligentes para tirarmos a conclusão certa. Esta é a nova retórica da interatividade: nós ficamos convencidos não por escutar/assistir a uma mensagem arranjada, mas por trabalhar ativamente com os dados: reorganizando-os, descobrindo conexões, tomando ciência das correlações [50].

De acordo com Manovich, esta nova retórica da interatividade é ainda mais explorada em UTOPIA:

A cosmogonia deste mundo reflete nosso novo entendimento do próprio planeta – pós-Guerra Fria, Internet, ecologia, Gaia e globalização. Observe as linhas finas, quase invisíveis, que conectam os atores e os blocos. (É o mesmo dispositivo usado em theyrule.net). No universo de UTOPIA, tudo é interconectado, e cada ação de um ator individual afeta todo o sistema. Intelectualmente, nós sabemos que é assim que nossa Terra funciona ecológica e economicamente – porém, UTOPIA representa isso numa escala que podemos apreender perceptivamente [51].

UTOPIA permite aquilo que Fredric Jameson chamou de “mapeamento cognitivo”:

uma representação situacional da parte do sujeito individual em relação a essa totalidade vastíssima e irrepresentável que é a estrutura da sociedade como um todo [52].

Se o mapeamento cognitivo é tanto difícil quanto necessário, isto se deve às redes invisíveis do capital; esses artistas produzem um mapeamento cognitivo via exploração da invisibilidade da informação. O funcionamento do software de arte, como pensa Manovich, é paralelo à crítica marxista da ideologia. O véu da ideologia é arrancado ao revelar as relações entre a ação individual dos atores e o sistema como um todo. O software permite tal crítica pela representação em uma escala – microcósmica – da qual podemos dar sentido. O desvelamento depende de nossas próprias ações, de manipularmos objetos de forma a ver; de pensarmos como programadores orientados a objetos.

Em lugar de depender de mapas cognitivos, nós os produzimos o tempo todo por meio de um meio que simula a crítica da ideologia e, na sua ausência, a ideologia também. É realmente notável que o software – projetado para ofuscar a máquina e criar comandos virtuais e ocultos – tenha chegado a uma impressionante noção de computação como transparente. Esta noção de transparência tem menos a ver com operações tecnológicas do que com o “microcosmo” estabelecido pela computação.

Software como ideologia

Como afirmei em outro lugar, o software é um análogo funcional da ideologia [53]. Em sentido formal, os computadores, compreendendo hardware e software, são máquinas ideológicas. Eles cumprem quase todas as definições formais de ideologia que temos, desde a ideologia como falsa consciência (como retratada em The Matrix) até a definição de Louis Althusser de ideologia como “a ‘representação’ da relação imaginária dos indivíduos com as suas condições reais de existência” [54]. O software, ou talvez, mais precisamente, os sistemas operacionais, oferecem-nos uma relação imaginária com o nosso hardware: eles não representam transistores, mas sim áreas de trabalho [desktops] e lixeiras. Os softwares produzem usuários. Sem um sistema operacional, não haveria acesso ao hardware; sem um sistema operacional, não haveria ações, práticas e, portanto, também não haveria usuários. Cada sistema operacional, a partir de seus anúncios, interpela o “usuário”: designa ou oferece um nome ou uma imagem com a qual ele se identifica. Assim, os usuários de Mac “pensam diferente” [think different] e se identificam com Martin Luther King Jr. e Albert Einstein; os usuários de Linux são os nerds do código aberto, atraídos pela imagem de um gordo e saciado pinguim; e os usuários de Windows são tipos padrão e funcionalistas, seguramente acomodados, como Eben Moglen argumenta, com seus computadores travando constantemente. Importa que as “escolhas” de sistemas operacionais oferecem limites para o visível e o invisível, o imaginável e o inimaginável. Contudo, você não fica consciente da interpelação e da constrição do software (também conhecida por sua “facilidade de uso”), a não ser que se sinta frustrado com seus padrões (notadamente referidos como suas “preferências”) ou use múltiplos sistemas operacionais ou pacotes de software concorrentes.

O software também produz usuários por meio de interações benéficas, a partir de sons tranquilizadores, a fim de indicar que um arquivo foi salvo em uma pasta chamada “Meus Documentos”, enfatizando assim a propriedade do computador pessoal. Os programas de computador usam descaradamente shifters — pronomes como “meu” e “você” —, endereçando-se a você e a todos como sujeitos. O software faz você ler, oferecendo-lhe mais relações e ainda mais visualidades. O software gera leituras que vão além da leitura de letras, desandando em práticas não literárias e arcaicas de predizer, interpretar, contar e repetir. O software é fundado em uma lógica fetichista [55]. Os usuários sabem muito bem que as pastas e as áreas de trabalho não são realmente pastas e áreas de trabalho, mas eles as tratam como se fossem — referindo-se a elas como pastas e áreas de trabalho. Essa lógica é, para Slavoj Žižek, crucial na ideologia. Žižek (por meio de Peter Sloterdijk) argumenta que a ideologia persiste nas ações de alguém, mais do que nas suas próprias crenças. A ilusão da ideologia existe não no nível do conhecimento, mas no nível do fazer: essa ilusão, mantida através do imaginário “sentido da lei” (causalidade), oculta o fato de que a autoridade não coincide com a verdade — alguém obedece à lei na medida em que ela é incompreensível. Não seria isso a computação? Por meio da ilusão de sentido e causalidade, nós não encobrimos o fato de que não podemos compreender nem controlar totalmente a computação? Que os computadores são crescentemente projetados por si mesmos e que nosso uso é — de certa maneira — uma súplica, uma fé cega? A nova retórica da “interatividade” ofusca mais do que revela.

Os sistemas operacionais também criam usuários de forma literal, pois os usuários são uma construção do sistema operacional. Os logins dos usuários emergem com os sistemas operacionais de tempo compartilhado [time-sharing], como o UNIX, que encorajou os usuários a acreditar que as máquinas com as quais trabalhavam eram suas próprias máquinas (antes disso, os computadores eram usados principalmente em processamento por lotes [batch processing]; antes disso, era literalmente necessário operar um computador, não sendo necessário um sistema operacional — um ser humano era o operador). Como vários historiadores escreveram, os sistemas operacionais de tempo compartilhado da década de 1970 geraram o “computador pessoal” [56].

O software e a ideologia se combinam perfeitamente porque ambos tentam mapear os efeitos materiais do imaterial e posicionar o imaterial em termos de sinais visíveis. Por meio deste processo, o imaterial emerge como uma mercadoria, como algo próprio. Assim, a descrição de Manfred Broy dos pioneiros como tentando realizar softwares mais fáceis de visualizar é curiosamente paralela à do software em si mesmo; afinal, o que é o software senão um esforço para tornar explícito — tornar o intangível visível — enquanto, ao mesmo tempo, torna o visível (isto é, a máquina) invisível? Embora o paralelo entre software e ideologia seja convincente, é importante não se dar aqui por satisfeito, uma vez que reduzir a ideologia ao software esvazia a ideologia de sua crítica ao poder — algo absolutamente essencial para qualquer teoria da ideologia [57]. O fato de que o software, enquanto estrutura acebolada , age como ideologia e como crítica da ideologia — enquanto ocultação e meio de revelação — também quebra a analogia entre software e ideologia. O poder do software encontra-se nessa dupla ação e no visível que se desdobra no invisível, um efeito da linguagem de programação transformado em transparência linguística.

Vendo por meio da transparência

O referido ato de revelar impetra a “transparência” aos bancos de dados e outras estruturas-chave ou, como Baudrillard designou, impetra a “obscenidade” da comunicação. Embora a imagem digital certamente tenha um papel na noção de redes de computadores como transparentes, isto não é suficiente nem fundamental. Considere, por exemplo, o The Matrix [Matrix], um programa multitarefa que varre ostensivamente bancos de dados públicos e privados para tentar encontrar criminosos e terroristas. Este programa trabalha integrando:

informações de diferentes origens, tais como registros de carros, licenças para condução, histórico criminal e registros imobiliários, analisando-os em busca de padrões de atividades que possam ajudar nas investigações policiais. Os materiais promocionais da empresa expressam que: “Quando dados seemingly insignificantes são analisados contra bilhões de outros elementos, o invisível se torna visível” [59].

Ainda que os apoiadores afirmem que o The Matrix [Matrix] simplesmente reúne informações já disponíveis de forma legal:

oponentes do programa dizem que a habilidade da rede de computadores em combinar e varrer uma montanha de dados amplifica enormemente o poder de vigilância policial, colocando pessoas inocentes em risco ao serem apanhadas em um arrastão de dados [data dragnet]. O problema é agravado, dizem, num mundo em que muitos aspectos do cotidiano deixam traços online [60].

Em 15 de março de 2004, mais de dois terços dos estados americanos retiraram seu apoio ao The Matrix [Matrix], citando preocupações orçamentárias e de privacidade. O The Matrix [Matrix] foi considerado uma violação de privacidade porque tornava o invisível visível (novamente, o ato do software em si mesmo), não porque o computador reproduzia imagens indexadas; ampliava o poder policial, permitindo que fossem realizadas conexões simplórias. O Total Information Awareness, um plano do governo dos EUA de reunir variados bancos de dados eletrônicos, foi igualmente criticado e praticamente extinto pelo Congresso Americano em 2003.

De modo particular, a computação habilita conexões por meio da renderização do invisível em visível nas movimentações pessoais a partir de interfaces computacionais. Digitando no Word, as letras aparecem na tela, representando o que está armazenado invisivelmente no computador. Minha digitação e meu clique parecem ter correspondência com as ações na tela. Abrindo um arquivo, eu o torno visível. De todo modo, o software parece tornar o invisível visível – transparecendo a leitura de código computacional e a leitura de linguagem humana. Manovich, autor de The Language of New Media, equaciona tal transdução nomeando-a “transcodificação” [transcoding] – a tradução de arquivos de um formato para outro. Em seu quinto e último princípio da nova mídia, exacerba o assunto, fazendo relações entre as camadas cultural e computacional. Manovich afirma que, para compreender a nova mídia, precisamos abranger as duas camadas, pois, embora a camada aparente possa parecer igual às outras mídias, a camada oculta, computacional, é onde mora a verdadeira diferença entre a nova e a velha mídia – a programabilidade. Ele então argumenta que nós precisamos nos deslocar dos estudos de mídia para os estudos de software, e o princípio da transcodificação é o caminho para começar a pensar sobre os estudos de software [61].

O problema com a noção de transcodificação de Manovich é que ela foca dados estáticos e trata a computação como mera tradução. Programabilidade não significa apenas que as imagens são manipuladas em novos modos, mas sim que um computador age de maneira fora do controle. Analisar o software meramente como “transcodificação” esquece a computação necessária para rodar um computador. A dupla leitura computacional não meramente traduz ou transcodifica código em texto, imagem ou som ou vice-versa; sua leitura – que combina leitura e escrita (para um computador, ler é escrever em outro lugar) – também partilha de outras leituras invisíveis.

Por exemplo, quando o Windows Media Player da Microsoft toca um CD, ele envia informações à Microsoft Corporation sobre aquele CD. Quando toca um arquivo RealMedia, como um videoclipe da CNN, envia à CNN seu “identificador exclusivo”. Você pode escolher trabalhar offline quando estiver tocando um CD e pedir para que o tocador de mídia não transmita seu “identificador exclusivo” quando online, porém esta escolha requer duas mudanças na configuração padrão. Instalando o Media Player, você também concorda em permitir que a Microsoft “forneça atualizações de segurança relativas aos componentes do sistema operacional [OS Components] que farão automaticamente download para o seu computador. Estas atualizações de segurança podem desabilitar sua permissão de copiar e/ou tocar conteúdo protegido [Secure Content] e outros softwares em seu computador” [62].

Basicamente, a Microsoft pode mudar os componentes de seu sistema operacional sem notificação ou consentimento explícito. Assim, de modo a criar um computador mais “seguro” – seguro no sentido de segurança contra o usuário – a Microsoft pode desabilitar arquivos piratas e aplicativos e reportar a presença disso ao seu banco de dados central [63]. É claro que os anúncios da Microsoft não enfatizam os mecanismos de rastreamento do Media Player, mas sim vendem isso como um sistema versátil e amigável ao usuário. Agora você pode ouvir tanto seu CD como sua estação de rádio na Internet com um clique do mouse: é exatamente como seu aparelho de som, porém melhor. Agora você pode automaticamente receber atualizações e otimizar suas conexões com sites remotos.

Para ser claro: este artigo não é um pedido de retorno a uma época em que se podia ver aquilo que se fazia. Esta época acabou. Como Kittler argumenta, em essência, nós não mais escrevemos – por meio dos nossos processadores de texto, nós atribuímos a tarefa de escrita aos computadores [64]. Isto não vem a ser uma acusação ao software ou à programação (eu também sou influenciada pelo prazer causal do software). Isto vem a ser, contudo, um argumento contra o senso comum a respeito das noções de software, precisamente por conta de seu status de senso comum (e, neste caso, cumprindo totalmente a noção gramsciana de ideologia como senso comum hegemônico); por conta das histórias e perspectivas que tais noções apagam; e por conta do futuro que indicam. O software tornou-se a súmula do senso comum para a cultura e o hardware, uma súmula para a natureza. (No debate atual sobre as pesquisas com células-tronco, estas foram chamadas de “hardware”. Historicamente, o software também facilitou a separação entre modelo e matéria, imprescindível para a separação dos genes do DNA [65] ). Em nossa sociedade pós-ideológica, o software sustenta e despolitiza as noções de ideologia e de crítica da ideologia. As pessoas podem negar a ideologia, mas não negam o software – e atribuem ao software, metaforicamente, poderes superiores aos atribuídos à ideologia. Nossas interações com o software disciplinaram-nos, criaram certas expectativas de causa e efeito, ofereceram-nos prazer e poder que acreditamos serem transferíveis para outro lugar. A noção de software invadiu nosso vocabulário crítico de forma amplamente inquestionada [66]. Interrogando o software e o conhecimento visual que ele cristaliza, nós podemos ir para além da chamada crise da indexicalidade , compreendendo os novos caminhos pelos quais o conhecimento visual vem sendo transformado e cristalizado, não simplesmente desarticulado ou tornado obsoleto.

NOTAS:

[1] Baudrillard, Jean. The Ecstasy of Communication. Trad. Bernard Schutze e Caroline Schutze. Brooklyn: Semiotext(e), 1988, p. 21–22; grifos no original.

[2] O que é, por exemplo, o Microsoft Word? É o programa executável criptografado, localizado em um CD ou em um disco rígido (ou mesmo em um código-fonte) ou é a sua execução? Os dois, apesar de não serem os mesmos, são ambos chamados de Word: eles se encontram em localizações diferentes; um é o programa e o outro é o processo. Programação estruturada, como discutiremos depois, tem sido a chave para unir programa e processo.

[3] Ver: Manovich, Lev. The Language of New Media. Cambridge: MIT Press, 2001, p. 48.

[4] Ceruzzi, Paul. A History of Modern Computing. 2nd ed. Cambridge: MIT Press, 2003, p. 80.

[5] Broy, Manfred. “Software Engineering—From Auxiliary to Key Technology”. In: Broy, M.; Denert, Ernst (org.). Software Pioneers: Contributions to Software Engineering. Berlin: Springer, 2002, p. 11–12.

[6] Kittler, Friedrich. “There Is No Software”. In: CTheory.net, 18 Oct. 1995. http://www.ctheory.net/text_file.asp?pick=74.

[7] Na década de 1950, o termo software era utilizado com pouca frequência e se referia a qualquer coisa que complementava o hardware, tal como o plug de configuração dos cabos. Na década de 1960, software fica mais próximo daquilo que chamamos hoje de sistema de softwares; e mais amplamente entendido “como combinação de ferramentas, aplicativos e serviços adquiridos por um vendedor externo”. Haigh, Thomas. “Application Software in the 1960s as Concept, Product, and Service”. IEEE Annals of the History of Computing, vol. 24, no. 1, January–March 2002, p. 6. Para mais a respeito, consulte: Hagen, Wolfgang. “The Style of Source Codes”. In: Chun, Wendy Hui; Keenan, Thomas (org.). New Media, Old Media: A History and Theory Reader. New York: Routledge, 2005.

[8] Ver: Goldstine, Herman; Goldstine, Adele. “The Electronic Numerical Integrator and Computer (ENIAC)”. IEEE Annals of the History of Computing, vol. 18, no. 1, Spring 1996, p. 10–16. As duas atividades foram distintas por Arthur Burks como “programação numérica” (implementada por operadores) e “programação adequada” [programming proper] (projetada por engenheiros e implementada por unidade de programação central). Burks, Arthur. “From ENIAC to the Stored-Program Computer: Two Revolutions in Computers”. In: Metropolis, Nicholas (org.). A History of Computing in the Twentieth Century. New York: Academic Press / Harcourt Brace Jovanovich, 1980, p. 311–344.

[9] Ver: Campbell-Kelly, Martin; Aspray, William. Computer: A History of the Information Machine. New York: Basic Books, 1996, p. 184.

[10] Ver: Hagen, Wolfgang. “The Style of Source Codes”. In: Chun, Wendy Hui; Keenan, Thomas (org.). New Media, Old Media. New York: Routledge, 2005.

[11] Koss, Adele Mildred. “Programming on the Univac 1: A Woman’s Account”. IEEE Annals of the History of Computing, vol. 25, no. 1, January–March 2003, p. 56.

[12] Ver: Derrida, Jacques. “Signature Event Context”. In: Limited Inc. Trad. Samuel Weber e Jeffrey Mehlman. Evanston: Northwestern University Press, 1988, p. 1–23.

[13] Backus, John. “Programming in America in the 1950s: Some Personal Impressions”. In: Metropolis, Nicholas et al. (org.). A History of Computing in the Twentieth Century. New York: Academic Press / Harcourt Brace Jovanovich, 1980, p. 127.

[14] Koss, p. 58.

[15] Sammett, Jean. Programming Languages: History and Fundamentals. Englewood Cliffs: Prentice-Hall, 1969, p. 144.

[16] Sammett, p. 148.

[17] Ver, por exemplo: Nelson, Theodor. Computer Lib. Richmond, WA: Tempus Books of Microsoft Press, 1987.

[18] Reed, Harry. “My Life with the ENIAC: A Worm’s Eye View”. Army Research Laboratory. Fifty Years of Army Computing from ENIAC to MSRC, 2000, p. 158. Disponível em: http://ftp.arl.mil/~mike/comphist/harry_reed.pdf.

[19] Ver: “Anecdotes: How Did You First Get into Computing?”. IEEE Annals of the History of Computing, vol. 25, no. 4, October–December 2003, p. 48–59.

[20] Edwards, Paul N. The Closed World: Computers and the Politics of Discourse in Cold War America. Cambridge: MIT Press, 1996, p. 71.

[21] Good, I. J. “Pioneering Work on Computers at Bletchley”. In: Metropolis et al. (org.). A History of Computing in the Twentieth Century, p. 31–46.

[22] Citado por: Ceruzzi, p. 82.

[23] Mahoney, Michael S. “Finding a History for Software Engineering”. IEEE Annals of the History of Computing, vol. 27, no. 1, January–March 2004, p. 8–19.

[24] Irigaray, Luce. This Sex Which Is Not One. Trad. Catherine Porter. Ithaca, NY: Cornell UP, 1985, p. 26.

[25] Plant, Sadie. Zeros + Ones: Digital Women and the New Technoculture. New York: Doubleday, 1997, p. 37.

[26] Campbell-Kelly; Aspray, p. 181.

[27] Koss, p. 51.

[28] Koss, p. 49.

[29] Fitz, p. 21.

[30] Edwards, Paul. “The Army and the Microworld: Computers and the Politics of Gender Identity”. Signs, vol. 16, no. 1, 1990, p. 105, 125; grifos nossos.

[31] Bush, Vannevar. “As We May Think”. The Atlantic Monthly, July 1945, repr. 1994. http://www.ps.unisb.de/~duchier/pub/vbush/vbush.txt.

[32] Campbell-Kelly; Aspray, p. 196–203; Ceruzzi, p. 105; Brooks, Frederick P. The Mythical Man-Month. 20th Anniversary ed. Boston: Addison-Wesley, 1995.

[33] Mahoney, p. 15.

[34] Dijkstra, Edsger W. “EWD 1308: What Led to ‘Notes on Structured Programming’”. In: Broy; Denert (org.). Software Pioneers, p. 342.

[35] Dijkstra, Edsger W. “Go To Statement Considered Harmful”. In: Broy; Denert (org.). Software Pioneers, p. 352, 354.

[36] Dijkstra, p. 352.

[37] Guttag, John V. “Abstract Data Types, Then and Now”. In: Broy; Denert (org.). Software Pioneers, p. 444.

[38] Guttag, p. 444.

[39] Guttag, p. 445.

[40] Eck, David. The Most Complex Machine: A Survey of Computers and Computing. Natick, MA: A. K. Peters, 2000, p. 329, 238.

[41] Koss, p. 49.

[42] Edwards, Paul. “The Army and the Microworld”. p. 108–109.

[43] Torvalds, Linus. Just for Fun: The Story of an Accidental Revolutionary. New York: HarperBusiness, 2001; Moglen, Eben. “Anarchism Triumphant: Free Software and the Death of Copyright”. First Monday, vol. 4, no. 8, 2 Aug. 1999.

[44] Edwards, Paul. The Closed World, p. 258.

[45] Aspray, William; Burks, Arthur (org.). Papers of John von Neumann on Computing and Computer Theory. Cambridge: MIT Press, 1987, p. 413.

[46] Schneiderman, Ben. “Direct Manipulation: A Step Beyond Programming Languages”. In: Wardrip-Fruin; Montfort (org.). The New Media Reader. Cambridge: MIT Press, 2003, p. 486.

[47] Laurel, Brenda. Computers as Theatre. Reading, MA: Addison-Wesley, 1991, p. xviii.

[48] Manovich, Lev. “Generation Flash”, 2002. http://www.manovich.net/DOCS/generation_flash.doc.

[49] Manovich, “Generation Flash”.

[50] Manovich, “Generation Flash”.

[51] Manovich, “Generation Flash”.

[52] Jameson, Frederic. Postmodernism, or The Cultural Logic of Late Capitalism. Durham: Duke University Press, 1991, p. 51.

[53] Chun, Wendy Hui Kyong. Control and Freedom. Cambridge: MIT Press, 2005.

[54] Althusser, Louis. “Ideology and Ideological State Apparatuses”. In: Lenin and Philosophy and Other Essays. New York: Monthly Review Press, 2001, p. 109.

[55] Žižek, Slavoj. The Sublime Object of Ideology. London: Verso, 1989, p. 11–53.

[56] Ceruzzi, p. 208–209; Campbell-Kelly, p. 207–229.

[57] —

[58] Lacan, Jacques. The Seminar of Jacques Lacan, Book II. New York: Norton, 1991, p. 81.

[59] Schwartz, C1.

[60] Schwartz, p. C1.

[61] Manovich, Lev. The Language of New Media. Cambridge: MIT Press, 2001, p. 48.

[62] Microsoft Media Player Licensing Agreement.

[63] Olsen, Florence. “Control Issues: Microsoft’s plan…”. Chronicle of Higher Education, 21 Feb. 2003. http://chronicle.com/free/v49/i24/24a02701.htm.

[64] Kittler, Friedrich. “There Is No Software”.

[65] Jacob, François. The Logic of Life. New York: Pantheon, 1973, p. 247–298.

[66] Doyle, Richard. On Beyond Living: Rhetorical Transformations of the Life Sciences. Stanford: Stanford University Press, 1997.

Discover more from MAELSTRÖM LIFE - Ednei de Genaro

Subscribe now to keep reading and get access to the full archive.

Continue reading