Posted: 06 Apr 2014 03:00 AM PDT
Abaixo,
a entrevista que fiz com Larry Wall, criador da linguagem Perl em sua
última passagem no Brasil, durante uma conferência de Perl. A tradução é
de Rina Noronha.
Lançada em 1987, Perl é uma linguagem que
tem como objetivo ser flexível e capaz de fazer códigos funcionais. Seu
criador, Larry Wall, fez praticamente todo o processamento de texto em
sistemas baseados em Unix, utilizando diversas ferramentas, como AWK,
‘sed’, C e linguagens shell script. A ideia era juntar as principais
vantagens de todas essas linguagens: expressões regulares do ‘sed’; a
identificação de padrões de AWK; a profundidade de C; além da sintaxe
baseada tanto em C quanto em Shell Script.
Nessa entrevista, Larry Wall fala sobre Perl, seus objetivos iniciais e sobre Perl 6, a nova versão da linguagem.
Qual é a sua formação, o que você estudou na faculdade?Eu
estudei muitas coisas, diversas, e quase não consegui concluir nada
porque não tinha créditos suficientes para nenhum curso. Mas, no final
das contas, consegui fazer com que a faculdade deixasse eu me formar.
Entre as coisas que estudei estão programação e linguística, dois
assuntos que foram primordiais para que eu chegasse ao Perl. Mas também
fui bem além disso, passando por química e música, por exemplo.
Por que você decidiu estudar computação? O que te chamava a atenção?Bom… você pode conseguir que os computadores façam coisas que as pessoas acham interessantes!
A
verdade é que eu provavelmente estou em algum lugar dentro do espectro
do autismo. Sendo assim, eu tenho uma enorme dificuldade em lidar com
pessoas. Eu consigo fazer isso, mas é um grande estresse para mim.
Então, poder se relacionar através de algo que eu faço e que os outros
vejam o que eu fiz, mas sem necessariamente ter que discutir com alguém
sobre o tempo ou outros assuntos assim, é uma forma de me tornar
social.
Meu pai é um pastor de igreja cristã e eu cresci nesse
ambiente. Como o “filho do pastor”, eu não podia ser tímido, mesmo
sendo assim naturalmente. Então, ao longo dos anos, eu aprendi a me
relacionar com as pessoas, mas foi algo que eu tive que aprender, que
desenvolver, e por isso às vezes não é fácil. Para alguém como eu, isso
não é fácil. Para mim, é mais gratificante fazer alguma coisa que as
pessoas vão achar útil. Por isso, eu tenho a tendência de medir o meu
próprio trabalho não pelo que eu vou conseguir com ele, mas pelo que eu
posso oferecer a partir dele. E eu entendo que isso é o que define uma
pessoa, não quanto dinheiro ela tem.
Foi por isso que o Perl entrou na sua vida?Foi
quase um acidente. Eu apenas queria oferecer uma coisa para os outros.
E isso era bem difícil porque não havia uma cultura desse tipo. Então
eu pensei em uma forma de oferecer coisas aos outros livremente. E
algumas dessas coisas, como o programa “patch”, acabaram por ajudar a
iniciar o movimento de software livre, porque muitas pessoas passaram a
trocar patches.
Há anos, no tempo em que as redes tinham uma largura
de banda muito pequena, as pessoas não podiam simplesmente enviar uma
nova cópia dos recursos. Mas se isso fosse um arquivo de patch, as
pessoas poderiam manter seus softwares sincronizados.
Eu
realmente não consegui fazer com que as pessoas aplicassem os patches
na primeira versão que eu enviei. Eu enviava os patches e as pessoas
não aplicavam um ou outro, porque não era necessário na máquina deles.
Mas aí um terceiro patch viria e bagunçaria tudo, porque ninguém tinha
aplicado o outro anterior. Então eu percebi que precisava achar uma
forma para encorajar as pessoas a manterem seus softwares
sincronizados, assim, quando um outro patch fosse enviado eles
aplicariam a mesma versão. Então, uma das coisas que foi internalizada
pelo programa de patch desde o início foi um pré-requisito que
determinava que uma certa versão do patch deveria estar instalada.
A
segunda versão foi muito mais fácil de manter porque que as pessoas já
estavam usando, ao menos até quando chegamos ao ponto delas começarem a
colocar repositórios na rede e a fazer isso de forma bastante
automática. E o programa Patch ajudou a fazer o bootstrap, mais ou
menos da mesma forma que o Perl ajudou a fazer o bootstrap na web do
início; hoje, mesmo que muitos sites não usem mais a linguagem, muitos
foram prototipados em Perl.
Acho que sou uma dessas pessoas que escrevem protótipos para depois jogá-los fora!
Por que você decidiu escrever o Perl?Para matar uma vontade! Na verdade, eu estava com um problema que precisava de processamento de texto para gerar relatórios.
Eu
estava em um projeto para a NSA (National Security Agency, a agência
de segurança do governo americano), a empresa tinha um contrato lá e eu
estava desenvolvendo uma “rede segura” por toda a costa entre Santa
Mônica, na Califórnia, e a Pensilvânia. Nós trocávamos informações por
meio de arquivos de texto sobre o projeto, mas eles queriam relatórios
sobre os arquivos de textos e o sistema Unix com o qual trabalhávamos
tinha uma versão muito antiga do awk.
A gente estava fazendo um
trabalho de processamento de textos e eu não conseguia fazer o que
queria nos relatórios. Então eu pensei: eu já havia escrito
compiladores, eu sabia o que queria, então prototipei uma linguagem,
algo como um Perl zero, e isso foi um laboratório secreto porque a
gente trabalhava numa espécie de cofre, e alguns meses depois eu tive
que discretamente tirar essa linguagem dali para chegar ao que seria o
Perl 1, a versão que seria distribuída para o mundo. Eu queria apenas
conseguir repassar alguns arquivos de texto e extrair algumas
informações de algumas expressões regulares em um formato de texto meio
aleatório e colocar no relatório e buscar por aquilo online.
Como isso se transformou no Perl que temos hoje?Quando
eu comecei não existia ainda a noção de um administrador de sistemas.
Havia o que a IBM chamava de Programador Chefe – o cara número um, que
sabia como tudo funcionava. E eu meio que já havia estado nessa posição
em meu trabalho na Seattle Pacific University e também quando
trabalhei em uma empresa de desenvolvimento de sistemas. Eu fui
contratado para essa posição, mas o ideal desse cargo é meio diferente
do que é um administrador de sistemas, quando você tem outras pessoas
fazendo a programação e gerenciar o sistema de um ponto de vista
operacional torna-se um trabalho de tempo integral. Nessa época meu
cunhado me falou “ah, você não quer se tornar um administrador de
sistemas, isso é um trabalho morto”.
Mas enquanto eu estava
fazendo isso, eu continuei desenvolvendo o Perl, então não era apenas
uma linguagem para fazer análise de texto, eu decidi que queria também
fazer uma parte de administração de sistema, como renomear arquivos e
todas as funções de um admin. Então eu tive isso bastante no Perl
também. E nas várias interfaces do sistema.
E aí as pessoas
começaram a adicionar interfaces aos bancos de dados, através de
versões especiais do Perl. Então havia o OraPerl, para o Oracle, o
SybPerl para Sybase. E foi então que eu percebi que havia um problema: o
que aconteceria se você quisesse usar Oracle e Sybase no mesmo
programa? Seria preciso ter extensões que ajudassem a colocá-los juntos
no mesmo programa.
Então, acho que o Perl mudou um pouco com essa
ideia de ter várias caras, o que o levou a ter extensões que
conversassem com vários backends de bancos de dados. A ideia de fazer
uma interface com objetos de forma que fosse possível falar mais
sensivelmente com pessoas.
Foi dessa noção que o Perl 5 nasceu,
com uma boa dose de extensibilidade. Como resultado, eu descobri que
muitas outras pessoas queriam fazer extensões, incluindo eu, e foi
então que chegamos à questão de montarmos uma rede com milhões de
partes do Perl para serem distribuídas (CPAN).
E isso tudo foi feito
no Perl 5. Você poderia adicionar texto como em um programa em C –
você até podia incluir texto em Perl 4, mas isso não funcionava direito
para modelos de interface, e isso a versão 5 tem. Não havia uma forma
de fazer uma interface para níveis mais baixos como códigos em C e C++,
então isso começou com Perl 5.
Enquanto você criava o Perl, que linguagens vocês tinha em mente?A
maioria delas. Basicamente as linguagens com as quais eu era
familiarizado – ou que eu pensava que fosse – foram as que me
influenciaram. Algumas pessoas pensam que havia influência de linguagens
como SmallTalk, mas não é verdade. Ao menos até o Perl 6 – agora, sim,
teremos alguma influência do SmallTalk.
SmallTalk foi a primeira linguagem orientada a objetos, não é?Bom,
você pode dizer que sim… Mas existiam outras antes. SmallTalk
realmente levou isso para um outro extremo, do ponto de vista que um
objeto é algo para o qual você envia uma mensagem, não apenas uma função
de call engraçadinha. Então, eles tinham uma visão mais global.
Mas não havia uma influência direta da SmallTalk, ao menos não até o Perl 6.
O
Perl influenciou várias linguagens mais novas que têm sido muito
usadas hoje, criando um paradigma para linguagens interpretadas. Como
você enxerga isso?Com certeza Ruby e Python tiveram uma influência inicial do Perl. Na verdade isso não foi planejado no Python.
O
Perl meio que estabeleceu, ao menos no mundo do Unix, esse gênero de
linguagens de script. Havia Shell – e você podia escrever em Shell
Script – mas na verdade isso sempre foi pensado como uma forma de unir
os programas em C. E porque elas eram construídas dessa forma? Era bem
difícil de fazer um programa decente com elas. Era difícil fazer com que
as coisas se relacionassem. E como todo mundo tinha um cliente Unix
diferente, era bem difícil escrever um Shell Script naquela época.
E por que escolher uma linguagem de script?Porque
é muito mais rápido em termos de tempo de programação. Pode não rodar
tão rapidamente, mas para operações de chamada, funciona rápido o
suficiente.
Em alguns benchmarks uma linguagem de script poderia
até bater um programa em C mais bobo porque você teria que trabalhar
muito para otimizá-lo e o Perl já tem isso, então pode fazer um array
associativo que provavelmente será mais eficiente que uma tabela feita
em C. Assim, em operações comuns, é possível otimizar o código em C
para o código em Perl.
O problema primordial que queríamos resolver
era a perda de tempo dos programadores em ter que manter anotações de
ponteiros, strings, arrays, gerenciamento de memória e tamanhos de
buffer; as ferramentas do Unix, na época, tinham limites muito
arbitrários.
Uma das maiores motivações para começar o Perl foi
“eu quero que as strings me digam o que elas são”. Não há limites
arbitrários aí. E nós levamos esse conceito para outras áreas também.
Para começar, nós queríamos tipos de string que você simplesmente não
precisasse se preocupar.
Quais são as maiores mudanças no Perl 6?Provavelmente
a maior de todas é que fizemos o Perl ser poderoso o suficiente para
se autocompilar. E eu espero que isso aconteça em qualquer VM. Já temos
compiladores de Perl 6 para Mono e .Net, estamos trabalhando no Java. E
existem algumas ideias para usar isso no LLVM.
Queremos que a
linguagem seja poderosa o suficiente para isso e o seja de forma
eficiente, para quebrar a si mesma, para que possa mudar a linguagem
quando decidirmos mudá-la, para ter novas versões de Perl e para ser
capaz de escrever em outras linguagens de domínio específico que sejam
melhores que o Perl.
As gramáticas inseridas no Perl 6 são
poderosas e muito expansíveis. Provavelmente se você tiver que colocar
uma única coisa no topo da lista, seria isso. Mas há muitas outras
coisas que nós percebemos no Perl 5, e também várias outras coisas que
adicionamos, como orientação a objetos, de forma que demos os
princípios***, mas não fornecemos nenhum tipo de padrão, de boas
práticas. Então as pessoas fizeram as suas próprias regras. Foi um
ótimo laboratório de testes, mas então existiam 30, 40 formas de
escrever objetos e eles não se comunicavam, não trabalhavam um com o
outro.
Gostamos da flexibilidade de ter esses laboratórios para
os princípios, mas no Perl 6, quando vemos que há muitas formas de se
fazer algo no Perl 5, decidimos que vamos escolher uma dessas formas
como padrão. Continuaremos com os princípios, mas eles ficarão por
baixo de uma camada de padrões, então teremos uma forma padrão de
declarar classes, de incorporar classes abstratas, que chamamos “roles”
genéricos, que são formas padrões de fazer várias cosias, que podem
ser modificadas se você realmente quiser ou precisar, mas esperamos que
os padrões ajudem as pessoas a escreverem códigos melhores quase que
por acidente.
Não vai ser preciso entender porquê aquele é o
padrão, mas quando as pessoas tentam fazer suas coisas, na metade do
tempo eles decidem pela forma errada… então não é que queremos chegar
ao nível do Python, dizendo que há apenas uma forma de fazer aquilo,
mas vamos tentar facilitar a forma correta, a melhor forma, para fazer
aquilo, meio que por acidente.
Bom, eu meio que estou levando o
processo do Python para o Perl 6. O modelo é realmente “pegar
emprestado” o novo modelo de objetos de várias fontes. E na verdade,
trata-se de pegar diretamente da literatura de orientação a objetos,
mais do que de alguma linguagem específica.
Você acha que seu background em linguística ajuda nisso?Acho
que sim, mas muito além disso é o sentimento de que uma linguagem de
programação deve refletir a forma como falamos sobre isso, então se
você quer falar que um objeto
está relacionado (has a relationship) a um determinado atributo, você deve realmente usar o termo “have” para declarar isso no Perl 6. Se ele
é um relacionamento (is a relationship) você usa o “is”.
É
uma questão de sensibilidade linguística, então, ao invés de chamar
coisas por outros nomes, usamos a construção que temos no Inglês. É
algo mais natural do que usar palavras funcionais, como acontece em
outras linguagens.
Mas isso muda muito a sintaxe da linguagem? O Perl 6 vai ser muito diferente? E como fica a retrocompatibilidade?Há
um grande número de diferenças. No geral, a sintaxe do Perl 6 é um
super set do Perl 5. Se você escreve em Perl 5 e isso não funciona
normalmente, vai estar bem perto de funcionar, porque você pode escrever
em Perl 6 dentro do sub set que é muito parecido com Perl 5.
Não
é exatamente a mesma coisa, mas o que fizemos no Perl 6 foi
intencionalmente quebrar a retrocompatibilidade. Queremos quebrar tudo o
que for possível, essa foi a ideia inicial. Então, vamos precisar de
alguma estratégia de migração, uma combinação de emulação, interpretação
cooperativa ou tradução, por exemplo. Existem várias formas de fazer
com que os códigos das versões 5 e 6 da linguagem interajam. Teremos aí
um caminho.
Mas quando você começar a ver as novidades que o
Perl 5 não suporta diretamente, então vai começar a usar a sintaxe, mas
nós tentamos adicionar as novidades de uma maneira bem sistemática, de
forma que todas as declarações sejam similares.
O Perl 6 tem
muito mais sintaxe a ser declarada que o Perl 5, mas funciona de uma
forma bem diferente. Na versão 5, você pode declarar as classes, mas
tem que usar a palavra
package. Você pode dizer que classes são pacotes, então usa a palavra
package. Isso também acontece no Perl 6, uma classe é um pacote, mas você usa
class.
Então, em vez de ir para a palavra-chave do princípio, tendemos a
distinguir a palavra-chave e então falar que uma classe é um tipo. Isso
torna as coisas mais claras.
Ao mesmo tempo, muitas coisas que
você faz ao executar código no Perl 5 parecem declarações no 6, mas na
verdade não está rodando um código por baixo, então quando você roda
uma declaração de classe, está na verdade fazendo uma chamada do
protocolo do meta objeto enquanto compila, e pode até fazer um hook se
quiser.
Portanto, você ainda tem toda a flexibilidade, mas nós a
escondemos sob um nível de declaração. Assim, há um mapeamento mais
natural entre o que as pessoas pensam e o que a sintaxe se parece.
Nesse
nível, é uma linguagem mais complicada, sintaticamente, mas em termos
de conceito não é, porque exitem os mesmos conceitos.
Então, o
estado da arte da programação em Perl 5 tem um conjunto de conceitos
que se encontram muito bem no Perl 6, mas na nova versão eles estão
mais bem elaborados, como em “aqui temos um padrão que você deve usar, a
não ser que você realmente saiba o que está fazendo”.
Qual a importância de Perl hoje, e como você espera que a linguagem esteja no futuro?Bom,
é claro que eu quero que Perl domine o mundo! Eu adoraria ver Perl 6
se tornar poderoso o suficiente de forma que o Google algum dia
dissesse “ah, nós não precisamos mais de Python ou algo assim”. Mas é
claro que isso é um objetivo a longo prazo. E provavelmente nunca
chegaremos lá, mas, ainda assim, é bom ter objetivos impossíveis
contanto você entenda que eles são impossíveis. Eu quero continuar
trabalhando neles de qualquer forma. Mesmo que você saiba que o que está
fazendo irá, de alguma forma, falhar, você deve fazer tudo o que puder
para isso. O mundo está cheio de coisas uteis que tiveram grandes
falhas e eu acho que Perl 6 vai ser muito útil!
Mas estamos
realmente pensando no longo prazo. Desde que começamos, pensamos em
fazer parte do progresso no início. Mas o Perl 5 estava
reconhecidamente estável e tinha muito apoio da comunidade, o que nos
permitiu gastar um bom tempo no redesenho.
Como é o relacionamento da comunidade de desenvolvedores brasileiros com Perl?Os
brasileiros são envolvidos com Perl há bastante tempo. Temos muita
gente contribuindo com Perl 5 e 6 no Brasil. E os brasileiros têm a
grande vantagem do fuso horário: vocês estão entre EUA e Europa, o que
facilita muito o trabalho!
Texto de minha autoria, publicado no portal iMasters:
http://imasters.com.br/linguagens/perl/entrevista-larry-wall/
