Entrevista com Larry Wall, criador do Perl
Autor: Kemel Zaidan | Publicado: 2014-04-06T07:00:00-03:00

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.



Fonte: http://bit.ly/11jS26r 


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.&nbsp; 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.&nbsp; 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.



Fonte: http://bit.ly/1e6kJWY

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.&nbsp; 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.
&nbsp; 
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!
&nbsp; 
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.

&nbsp;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/