Slackjeff Forum

Estava hoje lendo um texto (na realidade, a transcrição de uma apresentação) de Larry Wall, autor da linguagem Perl. O texto foi escrito em 1999, e portanto expressa um sentimento que existia na pré-virada do milênio.

Perl, the first postmodern computer language

É um texto longo e tortuoso, então se for uma pessoa impaciente e que não gosta desse tipo de leitura, contente-se com o que direi a seguir.

Esse texto me ajudou a entender o que me incomoda no termo "moderno", especialmente quando usado no contexto da computação.

O moderno é aquilo que se recusa a ser considerado "do passado", aquilo que se recusa a morrer ou ser substituído, ainda que por uma versão aprimorada. O moderno é aquilo que julgamos ser o de agora, o mais recente, o que está valendo.

O problema é que o tempo passa, e o moderno fica velho, possivelmente antiquado. Faria sentido continuar usando o termo moderno? De acordo com a linha de raciocínio exposta no texto, sim, pois é sobre o modo de pensar a modernidade: aquilo que não morrerá nem será substituído.

Ironicamente, o pós-moderno aceita essa condição e surge não para matar ou substituir a modernidade, mas sim para aprender com ela e de certo modo, retocá-la.

Mas retocar o moderno é para os modernistas um insulto. Se o moderno é insubstituível, então ele é "irretocável", não pode ser questionado, ele é em muitos sentidos um modo dogmático de pensar e agir.

Aí está meu incômodo com esse conceito de moderno. Uma arrogância, uma não aceitação de que possa haver outras formas de existir e pensar. Para mim, a pluralidade é enriquecedora, e com ela podemos aprender muito mais do que em uma cultura uniformizada.

Portanto a programação moderna é aquela na qual só há um modo de fazer as coisas. Ao menos, só um modo esperado de fazer, e se você propõe alternativas pode se tornar mal quisto em grupos que aderem a essa forma de pensar.

É por isso que de certa maneira eu tenho a percepção de Perl como uma linguagem humanista, uma linguagem que te permite se expressar artisticamente, ainda que o resultado não seja o que os outros esperam.

Como diz Wall no texto, o foco da pós-modernidade está no autor, não na obra, o que não quer dizer que a obra não seja importante. Apenas quer dizer que o valor da obra está no modo como o autor escolhe se expressar.

Eu costumava dizer que a escolha de uma linguagem de programação para uso em algum projeto deveria ser guiada pelo tipo de problema a ser resolvido. Ainda acredito nesse fator, mas hoje penso haver um segundo fator até mais importante: a relação que você enquanto programador desenvolve com a linguagem.

Ou seja, mais importante que a tecnologia em si, que é igual para todos, é o modo como você percebe essa tecnologia e pensa o que pode fazer dela. Isso é único e pessoal, e é o ponto de partida para a escolha a ser feita.

Em resumo, vivemos um período curioso no qual temos um embate entre as duas formas de pensar, e isto é paradoxal pois uma se coloca como "a única que pode existir" e outra como a que pode coexistir até mesmo com a única que pode existir.

Pensando um pouco mais sobre essa questão percebi que alguns pontos podem ter ficado em aberto. Recapitulando, eu disse que:

O moderno é [...] aquilo que se recusa a morrer ou ser substituído

E também que:

O problema é que o tempo passa, e o moderno fica velho, possivelmente antiquado.

E isso pode levar a crer que estou fazendo uma defesa de que as coisas mudem o tempo todo, apenas por mudar. E não se trata disso. O fato de algo não mudar em muito tempo não necessariamente quer dizer que algo que ficou velho e antiquado. As coisas podem ter ritmos diferentes de mudança e necessidade de atualização, e podem, em muitos casos atingir uma certa estabilidade.

Mudar apenas por mudar não é um pensamento pós-moderno. Vemos hoje muitas ferramentas sendo criadas com a proposta de ser "a melhor de todos os tempos" apenas porque não é uma ferramenta velha. Isso na realidade está muito mais para um pensamento modernista, porque tem como premissa o "tudo ou nada", ou seja, se está velho, está velho e nada se aproveita, temos que fazer algo novo do zero. Isso é puro modernismo.

O pós-modernismo, pelo contrário, aproveita aquilo que está "velho" mas que continua fazendo sentido hoje.

Outra fala anterior que pode dar margem a uma interpretação equivocada está no trecho:

Portanto a programação moderna é aquela na qual só há um modo de fazer as coisas.

Quando digo isso, não estou defendendo que as coisas sejam feitas de qualquer maneira. Não quer dizer que então vale fazer as coisas de modo desleixado porque "tudo deve ser aceito como um método válido". Eu pelo menos não penso que tudo deve ser aceito.

Ser pós-moderno não é ser irresponsável. Se por um lado a programação é uma arte, por outro ela é uma resolução de problemas, e não podemos nem deixar de resolver o problema e nem criar mais problemas do que resolvemos. Lamentavelmente isso me parece acontecer com bastante frequência, inclusive.

Em outras palavras, o fato de existir várias maneiras de resolver um problema, não quer dizer que qualquer coisa que você fizer vai resolver aquele problema.

Adentrando ainda mais nessa linha de raciocínio, acho que é perfeitamente válido dizer que o UNIX é um sistema pós-moderno. Talvez a primeira vista não pareça, pelo fato de ele ter uma filosofia própria, que pode parecer dogmática. Mas veja, o UNIX não é hostil a ferramentas não aderentes a sua filosofia. O emacs é prova disso. Você pode tranquilamente usar o emacs dentro do UNIX. Você pode misturar coisas do próprio UNIX com coisas de fora e inclusive integrá-las.

O UNIX expõe suas internalidades, como os UNIX pipes, para conectar programas diferentes (incluindo aqueles que não são do próprio sistema), os scripts de manutenção do sistema, os arquivos de configuração que podem ser manipulados diretamente, sem ter que passar por uma espécie de catraca (aqui me refiro a alguma interface dedicada para configurar o sistema).

E aliás, como sistema que surgiu no fim do século XX, faz total sentido que o UNIX seja pós-moderno. Nessa época o pensamento pós-modernista já estava em alta, e a cultura hacker, vamos lembrar, é um movimento de contracultura, questionador, no qual se desconstroem as estruturas dadas para reconstuí-las de outras formas. O modo como o UNIX surge é resultado dessa forma de pensar.

Se não acredita, este documento, redigido por Dennis Ritchie (co-autor do UNIX) explica como se deu esse processo:

The Evolution of the Unix Time-sharing System*

Em resumo, o sistema MULTICS foi um projeto muito ambicioso, mas que foi abandonado, e com ele muitas boas ideias morreriam. Inconformados, alguns dos especialistas que trabalharam no projeto resolveram reaproveitar algumas das ideias que fariam parte do sistema, na criação de um projeto mais simples e menos ambicioso, o UNIX.

Sem suporte do laboratório (Bell Labs), Ritchie e Thompson trabalharam com o que tiveram e reaproveitaram uma máquina PDP-7 que estava "encostada" no laboratório, para dar vida ao projeto (que mais tarde viria a dar bastante notoriedade ao laboratório e à AT&T).

Não apenas o UNIX nasce nesse contexto, como depois surge o BSD, na Universidade de Berkeley, com modificações próprias e várias melhorias (ou seja, o sistema foi retocado). E daí surge uma árvore de sistemas que vemos até hoje (NetBSD, FreeBSD, e derivações destes, como OpenBSD e DragonflyBSD, dentre outros).

A História nos mostra que a AT&T não viu com bons olhos o modo como o BSD se desenvolveu, e dali surgiu um conflito entre ela e a Universidade de Berkeley. Mas isso já entra em outra discussão, para saber mais dê uma conferida na Wikipédia:

Guerras do UNIX

Voltando ao ponto principal: o emacs foi uma das primeiras ferramentas a retocar o UNIX. Ou seja, uma ferramenta que muitos usuários do UNIX aderiram, e não há motivo para isso virar uma guerra (embora alguns usuários insistam nisso).

Pessoalmente prefiro o ed e o vi, mas respeito os aderentes do emacs, é uma opção totalmente válida. Novamente, no pensamento pós-moderno, valorizamos a pluralidade e a troca de ideias. Mesmo não sendo aderente ao emacs, reconheço seus pontos fortes. A noção de estensibilidade via LISP, por exemplo, é algo que acho genial nesse programa.

Perl foi outra ferramenta que retocou o UNIX. Ele se integra ao sistema de arquivos e à árvore de processos do sistema, mas possui outras funcionalidades próprias. Ou seja, ele reaproveita partes do sistema, e mistura com conceitos externos.

A própria noção de UNIX-like ou POSIX-like indica que existem sistemas que aproveitam aquilo que faz sentido nos padrões estabelecidos, mas não tudo. E além de não aproveitar tudo, elementos de fora do UNIX estão muitas vezes presentes nos BSDs e distribuições de Linux, tais como o servidor gráfico Xorg, o próprio interpretador Perl e diversos outros programas.