Computadores deveriam ser “bicicletas para a mente“, máquinas que operam mais rápido que o pensamento. E se o computador era uma bicicleta para a mente, então a forma plural do computador, a Internet, seria “um novo lar da Mente“. A Internet era uma coleção fantástica de todo o conhecimento do mundo, e era um bastião de liberdade que tornaria tempo, espaço e geopolítica irrelevantes. Ignorância, autoritarismo e escassez seriam lembranças do passado não-virtual.
As coisas não aconteceram bem dessa forma. A mágica desapareceu e nosso otimismo se foi. Nossos sites são lerdos e inseguros; nossas startups são esquisitas e não-lucrativas; nosso presidente tweeta discurso de ódio; não confiamos em nossos apps de mídia social, nossas webcams, ou mesmo em nossas urnas eletrônicas. E nessa era de quarentena do coronavírus, estamos percebendo quão inadequada a Internet se tornou como o lar da Mente. Onde que tudo isso deu errado?
centenas de bicicletas quebradas em varias filas
Software é para pessoas
O software (programa de computador) é ao mesmo tempo um campo de estudo, uma indústria, uma carreira, um processo de produção e um processo de consumo — e só então um conjunto de linhas de código de computador. É impossível separar o software do contexto humano e histórico no qual ele se situa. O código sempre é feito para alguém. Como colocado em Estrutura e Interpretação de Programas de Computador, “programas devem ser escritos para serem lidos por pessoas, e apenas incidentalmente para serem executados por máquinas” (Abelson et al. 1996). Nós não escrevemos código para nossos computadores, pelo contrário, escrevemos para pessoas lerem e usarem. Mesmo a pesquisa de ciência de computação mais pura, mais teórica e mais imprática tem como objetivo provocar novos padrões de pensamento em leitores e acadêmicos humanos — e elas são formuladas usando ferramentas criadas por pessoas: a matemática, a linguagem e o código.
Como engenheiros de software, temos orgulho de escrever código que é “legível” ou “limpo”, ou código que “resolve problemas de negócios” — todos sinônimos dessa propriedade de “ser feito para alguém” (“endereçamento”?) que softwares parecem ter. Talvez o criador de malware seja quem melhor conhece essa propriedade. Assim como qualquer software, o malware é direcionado a pessoas, e apenas incidentalmente para execução por máquinas. Se um código rouba dinheiro, sequestra contas de mídia social ou desestabiliza governos, ele opera no domínio humano. O computador não se importa com dinheiro, contas em mídias sociais ou governos, os humanos sim. E quando o autor do malware ofusca seu código, ele o faz pensando no leitor. O computador não se importa se o código que ele executa é ofuscado, ele só entende de códigos de máquina, relógios e interrupções, e os executa fielmente. Portanto, até o malware — especialmente o malware — cujo código é deliberadamente feito para ser ilegível, é escrito com a intenção de leitura em mente.
Exemplo de código Javascript ofuscado
O código tem muitas vozes
O filósofo soviético Mikhail Bakhtin escreveu que “uma frase simples, com toda sua individualidade e criatividade, não pode ser considerada como uma combinação completamente livre de formas de linguagem (…) uma palavra numa linguagem pertence metade a outrem” (Wertsch 1991, 58-59). Qualquer código que vamos escrever, não importa o quão experimental ou novo, deve parte de sua existência a mais alguém, e participa como um elo em uma cadeia de diálogo, um em resposta ao outro. O código do autor do malware está em diálogo com o analista de malware. O engenheiro de software está em diálogo com seus colegas de trabalho. O usuário de um software está em diálogo com seu criador. Uma aplicação web está em diálogo com a linguagem e o framework no qual foi escrita, e sua estrutura é mediada pelas características do TCP/IP e HTTP. E no ato físico de escrever código, estamos em diálogo com nosso computador e nosso ambiente de desenvolvimento.
gif de um código sendo escrito
Wertsch formulou a noção de diálogos de Bakhtin em termos de vozes: “Quem está falando? Pelo menos duas vozes.” (1991, 63). Enquanto Wertsch e Bakhtin estavam preocupados com a linguagem humana, podemos também prontamente aplicar essa ideia a softwares: “a ambiguidade da linguagem humana está presente no código, que nunca escapa por completo de seu status de escrita humana, mesmo quando gerado por máquinas. Nós trazemos ao código nossos excessos de linguagem e ambiguidades semânticas conforme discernidos pelo leitor humano” (Temkin 2017). Quais vozes ouvimos quando vivenciamos código?
No nível sintático, cada palavra-chave e cada aspecto da linguagem que usamos é pego emprestado dos criadores da linguagem. Essas palavras-chave e gramáticas, por sua vez, são pegas de uma língua humana como o inglês, e essas vozes também estão presentes em nosso código. O “if” do JavaScript pega emprestado o significado do “if” do inglês, que por sua vez pega do alemão, e de qualquer forma a palavra não nos pertence, não completamente — uma palavra numa linguagem pertence metade a outrem. Quando chamamos uma linguagem de programação, uma biblioteca ou um framework de “tendencioso”* ou de “poço de desespero/sucesso” nós na verdade queremos dizer “quão alto grita a voz da linguagem em nosso código?” Um comentário sobre a linguagem de programação Go por matt_wulfeck no Hacker News ilumina o desequilíbrio intencional entre a voz do programador e a voz da linguagem:
“Go tira tanto da “individualidade” do código. Na maioria das equipes com Python e Java de que participei eu consigo abrir um arquivo e imediatamente dizer quem escreveu a biblioteca baseado em vários detalhes de estilo e coisas do tipo. É muito mais difícil de fazer isso em Go, o que é uma coisa muito boa.”
Aqui podemos ver de que forma as vozes mediam nossas ações — como é que a linguagem Go media a forma como escrevemos e pensamos sobre código? Jussi Pakkanen, que criou o sistema de build Meson, chamou o ato de mediar aspectos da voz de pastoreio: “Não é o que a linguagem de programação faz, é para onde elas te pastoreiam.” Pastoreio, ou formas de mediação, são “uma propriedade invisível da linguagem de programação e de seu ecossistema que direciona as pessoas a resolverem os problemas de formas que sejam naturais para a linguagem de programação em si em vez de de formas consideradas ‘melhores’ de um certo ponto de vista” (Pakkanen 2020). Nós internalizamos as vozes de nossas relações sociais, e essas vozes mediam ou pastoreiam nossas ações. Toda vez que a gente mergulha num código, conversa com um mentor, faz um curso, ou assiste a uma conferência, nós estamos deliberadamente adicionando novas vozes ao saquinho de vozes em nossa cabeça. Isso não é um processo puramente de consumo: ao internalizar vozes, formamos contra-argumentos, mentalmente discutimos com elas, e as ventriloquizamos através de nosso próprio trabalho — isto é, nos engajamos em diálogo.
Da próxima vez que você se sentar para ler um código, ouça com atenção as vozes que nele habitam e as vozes em sua cabeça, por mais fraquinhas que estejam. Eu consigo ouvir a voz de um engenheiro sênior do meu último emprego toda vez que escrevo uma definição de tipo.
Abstração e trabalho
Num nível mais alto, os padrões e estratégias que usamos para estruturar nosso código, aqueles que pensamos ser independente de linguagens de programação, como algoritmos, design patterns, arquiteturas e paradigmas, também são “alugados”. Alguns algoritmos recebem seu nome em homenagem a famosos cientistas de comutação, como Dijkstra, Kruskal e Prim, e estes também nós mostram o conjunto de vozes que falam em nosso código. Mas ao mesmo tempo, o processo de nomenclatura obscura a multidão de outras vozes falando por esses algoritmos. O algoritmo de Dijkstra é uma busca em largura ponderada que usa uma fila de prioridade-mas o nome sozinho não lhe diria isso, de fato, os nomes “busca de largura” e “fila de prioridade” obscura ainda mais vozes. Ao atribuir a história inteira, as cadeias de diálogo, e o coral de vozes que falam no algoritmo, nomeado no singular Dijkstra-vendo um onde há muitos-todos eles são mortos, e o significante Dijkstra toma seus lugares. Esse é o processo de abstração.
Essas cadeias de diálogo que se tornaram obscuras estão presentes em tudo, de cadeias de fornecimentos, para APIs, códigos fonte e gerenciadores de pacotes. Rode git log em alguma repositório no seu trabalho, ou pesquise os commits de um projeto de código aberto- tenta Postgres se você não tiver um projeto em mãos. Leia as mensagens dos commits, confunda-se com os difs e se maravilhe as camadas de história sedimentada. Postgres tem quase 50.000 commits, um em resposta a outro, cada um representando horas ou dias de trabalho, e vidas inteiras de conhecimento e experiência acumulada. É um meio de gravação para esses diálogos, onde cada commit é inscrito; e está no nível de commits, listas de mudanças e releases que nós tornamos manso o fluxo de desenvolvimento cortando, segmentando e abstraindo em unidades que possamos compreender. Uma voz de cada vez por favor. Um porta-voz de Dijkstra, um mascote Postgres, para esconder a complexidade.
Todo programa de software que interagimos, toda empresa, todo projeto, todo produto- do seu sistema operacional, ao SaaS que sua firma depende, as bibliotecas que você, e até as rotinas que rodam no microcontrolador da sua geladeira – todos escondem uma história deliciosamente complicada de produção, e é isso que trás todo o desenvolvimento de software junto. Marx descreveu essa substância comum como “uma simples geleia [Gallerte] de trabalho humano indiferenciado, i.e., de dispêndio de força de trabalho humana, sem consideração pela forma de seu dispêndio. Essas coisas representam apenas o fato de que em sua produção foi despendida força de trabalho humana, foi acumulado trabalho humano. Como cristais dessa substância social que lhes é comum, elas são valores – valores de mercadorias” (1867, 48)
NPM não é o problema
Em 2016, um pacote de JavaScript chamado ‘left-pad’ quebrou a Internet por um dia. O pacote tinha onze linhas de código que colocava caracteres no início de uma string para um comprimento específico, fazendo “5” virar “005”. Por causa de uma disputa de marca comercial, o criador do left-pad Azer Koçulu deletou do registro do NPM como forma de protesto, causando estragos em todo um ecossistema de pacotes que dependiam dele, seja de forma indireta ou direta, por meio de dependências interconectadas até o enésimo grau – e essas dependências por sua vez, alimentavam sites em todo o mundo (Williams 2016)?.
Uma visualização do gráfico de dependências para o pacote NPM react-scripts. Cada ponto representa um pacote e as linhas ligam pacotes que dependem um do outro. Um dos pontos é o ‘left-pad’ – eu não sei qual
De acordo com as conversas da época, isso foi uma lição sobre a fragilidade das redes de dependências e abstrações que havíamos criado, e era um sinal que o ecossistema do NPM estava fundamentalmente quebrado. Construímos um castelo de cartas – longas cadeias de diálogo cujos elos podiam simplesmente desaparecer – foi necessário um único desenvolvedor e suas onze linhas de código para derrubá-los. David Haney, sobre o incidente do left-pad, perguntou em um post do blog.
Será que esquecemos como programar? […] Tenho a impressão que os participantes do ecossistema NPM criaram um hábito de micro-pacotes. Em vez de escrever qualquer função ou código, parece que preferem depender em algo que outra pessoa escreveu. (2016).
Mas agora sabemos que não esquecemos como programar: foi sempre assim que programamos. Tudo que escrevemos é algo que alguém já escreveu; nada nos pertence; todo código é multi-vocal. Essas teias de dependências sempre existiram, mas nenhum sistema deixou esse fato tão óbvio como NPM fez. Onde vemos um, seja um app, um script, um pacote- a quebradeira do NPM nos lembra que existem muitos.
Software não é criativo
Video do Gooble DeepMind Deep Q-aprendendo a jogar Breakout no Atari
Observe uma rede neural, inicializada do caos aleatório, treina a si mesma como jogar Atari Breakout. Observe as pequenas máquinas-os nós de uma rede, suas conexões e suas conjunções, seus fluxos de ruptura e suas propagação traseiras, e veja como convergem: inicialmente contingências aleatórias, num ciclo de ressonância, cristaliza em estrutura. São máquinas reproduzindo máquinas. São pequenos capitalistas. “a história universal é a das contingências, e não a da necessidade; é a dos cortes e dos limites, e não a da continuidade.” (Deleuze & Guattari 1983, 140).
Mas redes neurais, e software em geral, não criam uma nova realidade-apenas digerem dados e refletem uma realidade que é a regurgitação e a reconfiguração do que aquilo que já fora consumido. E essa realidade que essas máquinas refletem é ligeiramente errada. Lembre-se do aforismo dos estatísticos “todos os modelos estão errados, mas alguns são úteis”. O que acontece quando dependemos desse modelos para produzir novas realidades, e alimentamos essas novas realidades ligeiramente erradas de novo para essas máquinas novamente? O que acontece quando escutamos as descobertas da semana do Spotify semana após semana, damos “like” nos posts que o Facebook nos recomenda e rolamos através de TikToks? Eu sou culpado de todos esses, e não estaria errado em dizer que meu gosto musical e meu senso de humor são mediados por essa recursão mutual entre algoritmos e o mundo real.
Em nosso mundo moderno, nossas interações sociais, nossos aparelhos, governos e mercados, são circulações e fluem das mesmas realidades sob as mesmas regras. Nosso software cria novos problemas-que nunca tivemos antes, como fake news, cyberbullying, e vulnerabilidades de segurança-que depois nos corrigimos com mais camadas de código. Software se torna a quase-causa do software. São ecos das mesmas vozes numa ressonância, tornando-se mais barulhentos e menos coerentes com cada ciclo, onde se joga lixo se tira mais lixo, um milhão de vezes.
A quem o software beneficia?
Para muitos de nós, com a sorte de ficar em casa durante o surto de coronavírus, nossa única interface com o mundo lá fora, de nossas famílias e lares – os relés de conexão entre nós, nossas famílias, comunidades e sociedades – foram filtrados através de nossas telas e fones de ouvido. Agora está aparente mais do que nunca exatamente o que o software faz por nós e que tipo de desigualdade ele reforça.
Através do Instacart, Amazon Fresh, e outros serviços de entregas de mercado, podemos usar um app para comprar o corpo de um entregador por uma hora, de forma que ele se exponha ao vírus em nosso lugar. Alguns desenvolvedores, insatisfeitos com isso, escreveram scripts para reservar instantaneamente os poucos pedidos de entrega desses serviços.
Um desenvolvedor escreveu na Motherboard da Vice “Eu desenvolvi esse robô para aqueles que acham extremamente inconveniente sair de casa nesses tempos, ou para aqueles que descobrem não ser seguros para si mesmos estar lá fora. É a minha contribuição para achatar a curva, eu realmente espero que isso possa ajudar a reduzir o número de pessoas saindo” (Cox 2020). Sério? Um robô consegue reduzir o número de pessoas saindo de casa ou apenas mudar a demografia de quem pode ficar em casa, favorecendo aqueles com recursos e habilidades para rodar um script de Python e um Selenium WebDriver? Com uma constante e limitada número de vagas para entregas, Joseph Cox aponta que esses bots criam “uma divisão entre aqueles que podem usar um robô para pedir comida e aqueles que apenas precisam ficar tentando durante a pandemia” (2020).
Bots do Instacart são apenas a reencarnação mais recente de uma antiga tradição que utiliza a velocidade do software para ganhar uma margem contra humanos. Nos anos 2000, quando as vendas de ingressos para shows começaram a serem feitas pela internet, cambistas criaram bot para comprar esses ingressos e revendê-los a um preço mais alto. O capitalismo, em sua infinita flexibilidade, adaptou e acolheu esse desenvolvimentos com braços abertos e mãos invisíveis, gerando empresas como a TicketMaster, que institucionalizou e legitimou a prática. Mas Instacar e Ticketmaster são meros sintomas de um problema. Os mesmo padrões foram vistos na corrida de armas de trading de alta frequência. No começo, os robôs ganhavam dos humanos. Depois os robôs se tornaram parte do jogo, e os robôs jogam entre si. Os lucros do trading de alta frequência secaram, e também se tornou uma necessidade apenas para acompanhar.
Esses exemplos mostram pra que o software é bom, eles nos dão uma idéia geral disso. Por si só, software não autoriza nada verdadeiramente novo, apenas muda os fatores constantes de velocidade e custo marginal, e muda a barreira de participação para um patamar arbitrariamente alto. Assim que o trëm do software começa a sair da estação, temos nenhuma opção do que pular e se segurar, tomando cuidado para não sermos atropelados ou esquecidos para trás- não sabemos o que é pior. Max Weber, ao estudar o desenvolvimento do capitalismo, identifica esse efeito secularizado espiral:
“O puritano queria ser um profissional – nós devemos sê-lo. Pois a ascese, ao se transferir das celas dos mosteiros para a vida profissional, passou a dominar a moralidade intramundana e assim contribuiu [com sua parte] para edificar esse poderoso cosmos da ordem econômica moderna ligado aos pressupostos técnicos e econômicos da produção pela máquina.” (Weber 1920)
Um começo falso: start-ups
Startups adoram salvar o mundo, mas olhe o estado do mundo agora-é assim que queremos ser salvos? O mundo está -mesmo que só um pouco- melhor por causa de startups como Instagram, Uber e iFood? Startups são espaços de inovação notáveis, e eles são experts quando o assunto é canalizar a multi-voz do código-basta olhar para a rede de vozes que GitLab canaliza (visualização abaixo). Mas sob capitalismo, essas vozes são distorcidas e restringidas, e elas gritam “cresça, cresça!“ enquanto capitalistas de riscos e fundadores demandam mais usuários, pedaços do mercado e rendimento-em uma palavra, eles demandam acesso a acumulação capitalista.
Diagramas de sistemas publicado pelo Gitlab
O fundador da startup, por mais que ele diga que ele ama código, ama humanidade ou ama a emoção do jogo (e eles até podem acreditar quando falam isso), esse fundador ama mais o crescimento do capital. O fundador é um genuíno capitalista, mas o capital não ama ele de volta, capital não pode amar, e as chances estão sempre contra nosso herói capitalista.
“O capitalista maior ganha do menor… Sempre termina em ruína para muitos pequenos capitalistas, os quais o capital passa parcialmente para as mão de seus conquistadores, e parcialmente desaparece” (Marx 1867, 621).
Capital acumula e concentra, e é no meio de competição fútil que a startup morre ou é comprada pelo Facebook ou Google, deixando nada para trás do que uma nota no Linkedin e um post falando uma viagem incrível. Se esqueceram de salvar o mundo…
O que deve ser feito?
Para revisitar a ambiciosa pergunta que queremos responder, onde que deu tudo errado? O que nos jogou nessa bagunça, nessa corrida, assistida por ferramentas, de acumulação e explotação? O truque é que nós não estamos estudando software sozinho- estabelecemos que computadores e código são bem saturados com toque, voz e pensamento humano. Software não pode ser divorciado das estruturas humanas que o criam, e para nós, essa estrutura é o capitalismo. Citando Godfrey Reggio, diretor de Koyaanisqatsi (1982), “não é o efeito de, mas é tudo que existe dentro de si. Não é que usamos a tecnologia, vivemos tecnologia. Tecnologia se tornou tão presente quanto o ar que respiramos de forma que não temos mais consciência de sua presença.” (Essense of Life 2002).
Onde que tudo deu errado? Em algum ponto, capital se tornou a única resposta para todas as perguntas-o que produzir, como produzir, para quem produzir e seu porquê. Quando software, aquela solução final em procura de um problema, encontrou as perguntas que são apenas respondidas pelo capital, nos perdemos nosso caminho, fomos pegos na armadilha do capital.
Q: O que o software faz?
A: Produz e reproduz capital.
Q: Para quem o software trás beneficios?
A: Pessoas que controlam capital
Q: O que é software?
A: Capital.
A: Capital.
A: Capital.
A: Capital.
Mas nós podemos quebrar esse padrão; podemos encontrar nossas próprias respostas para essas perguntas, e se depender de nós, a pergunta não necessariamente precisa ser a resposta que fomos ensinados, capital. Software é uma ferramenta com potencial revolucionário, mas isso é a extensão do que nos pode dar. “A ciência demonstra pelo seu próprio método que os meios que constantemente elabora não fazem mais do que reproduzir, por fora, uma interação de forças por si mesmas sem objetivo ou fim cujas combinações obtêm tal e tal resultado.” (Deleuze & Guattari 1983, 368).
Então, quais são os objetivos e os finais que devemos direcionar nosso software? Quais são as respostas para aquelas perguntas econômicas, senão capital-ou melhor ainda, quais perguntas devemos estar perguntando, se não econômicas?
Não sei 🙂
Referências:
Abelson, Harold, Gerald Jay. Sussman, and Julie Sussman. Structure and Interpretation of Computer Programs. Cambridge, MA: MIT Press, 1996. Sem tradução para o português
Cox, Joseph. “People Are Making Bots to Snatch Whole Foods Delivery Order Time Slots.” Vice. Vice Media Group, April 21, 2020. https://www.vice.com/en_us/article/n7jaw7/amazon-fresh-whole-foods-delivery-time-slot-bots.
Deleuze, Gilles, e Félix Guattari. O ANTI-ÉDIPO: Capitalismo e esquizofrenia 1. Traduzido por Luiz B. L. Orlandi, 1983.
Essence of Life. MGM Home Entertainment Inc., 2002. https://www.youtube.com/watch?v=8oiK4vPLtVw&t=581.
Haney, David. “NPM & Left-Pad: Have We Forgotten How To Program?” David Haney, March 23, 2016. https://www.davidhaney.io/npm-left-pad-have-we-forgotten-how-to-program/.
Marx, Karl. O Capital. 1867. Traduzido por Rubens Enderle,
Pakkanen, Jussi. “It’s Not What Programming Languages Do, It’s What They Shepherd You To.” Nibble Stew, March 6, 2020. https://nibblestew.blogspot.com/2020/03/its-not-what-programming-languages-do.html.
Temkin, Daniel. “Sentences on Code Art.” esoteric.codes, December 27, 2017. https://esoteric.codes/blog/sentences-on-code-art.
Weber, Max. A Ética Protestante e o “Espírito” do Capitalismo. Tradução José Marcos Mariani de Macedo, 1920.
Wertsch, James V. Voices of the Mind: A Sociocultural Approach to Mediated Action. Cambridge University Press, 1991. Sem tradução para o português
Williams, Chris. “How One Developer Just Broke Node, Babel and Thousands of Projects in 11 Lines of JavaScript.” The Register. Situation Publishing, March 23, 2016. https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/.
Artigo originalmente escrito por Jesse Li para seu blog, disponível aqui.
Tradução por Dione.
TraduAgindo 