[SP-pm] O Futuro do Perl/CPAN

breno breno em rio.pm.org
Domingo Maio 18 22:58:16 PDT 2008


Opa, peraí! Deixa eu defender meu argumento, ele é um pouco mais
complexo que isso... (xiii, lá vem os emails enormes do breno :-P)

Não sou contra diversidade. TIMTOWTDI é uma das mais interessantes e
únicas características do Perl. O que me incomoda é que sinto haver
muita individualidade na comunidade Perl, que aproveita essa
característica e parece (meu ponto de vista) trocar de módulo como
quem troca de roupa, sem oferecer um mínimo de continuidade, suporte
ou evolução ao que apresenta aos desenvolvedores.

Claro que há excessões, mas um exemplo típico é o Sebastian Reidel,
que começou no Maypole e, por não gostar da direção que o projeto
estava tomando, criou o Catalyst, e agora parece estar abandonando o
Catalyst para fazer um novo (?!) framework. Posso estar redondamente
enganado, mas a sensação que isso passa (pelo menos para mim) é de
fuga. E vejo isso constantemente no CPAN: um módulo X faz A,B e C mas
eu preciso de D então, ao invés de colaborar com o projeto original
deixando ele robusto e até personalizável através de subclassing ou
contribuições diretas, eu vou lá e faço um outro do zero, que faz A,
B, C e D. Aí outra pessoa quer A, B e Z, então ela escreve outra coisa
completamente diferente também. O resultado disso é um monte de
implementações diferentes de A e B com praticamente a mesma estrutura
e API, mas em estágios de maturidade completamente desconhecidos, sem
um "core" comum.

Eu mesmo vi na documentação da API de plugins do Catalyst que ele pede
"POR FAVOR" para as pessoas não criarem plugins que fazem o que outros
módulos já implementam (e muito bem, diga-se de passagem), "estamos
falando de Perl! Vcs podem simplesmente usar o módulo - ele não
precisa ser um plugin ou estar no namespace do Catalyst para fazer
parte de sua aplicação ou interagir com o framework". E EMHO eles
estão certíssimos.

Como disse, o que sinto falta é na colaboratividade (essa palavra
existe?) entre desenvolvedores, é pegar um módulo que faz quase o que
vc quer e melhorá-lo, extendê-lo, criar subcomponentes, enfim, e não
fazer um fork dele. Para não ficarmos em A,B e C vejamos um exemplo
claro disso: o Net::SMTP. Quem não conhece o Net::SMTP? É um ótimo
módulo para envio de email. Mas o Net::SMTP só faz autenticação por
SASL. E se vc quiser autenticar por TLS (como o gmail)? Ah, uma alma
caridosa fez o Net::SMTP::TLS, que suporta autenticação por TLS e
AUTH. Só que, apesar de estar no mesmo namespace, ter praticamente a
mesma API e constantemente ao longo da documentação apontar para o
Net::SMTP, ele não é uma subclasse de fato, e implementa tudo do
zero!!! Resultado: pequenas nuâncias de sintaxe te obrigam a fazer
malabarismo se quiser que sua aplicação suporte ambas as formas de
autenticação, quando uma boa subclasse deixaria o processo
completamente transparente (ou, se não fosse realmente possível, ele
poderia implementar diretamente no Net::SMTP). Fora que atualizações
de implementação do Net::SMTP não se propagam para o N::S::TLS. Vcs me
desculpem, mas eu não acho isso absolutamente interessante.

Uma coisa é não gostar de uma API para fazer X e desenhar sua própria,
que é o princípio do TIMTOWTDI e de alguns frameworks diferentes.
Outra é reescrever a roda a cada turno, só pq algo não faz exatamente
o que vc quer. O que houve com o RT?! O que houve com o
cvs/svn/git/etc?! O que houve com a colaboração entre
desenvolvedores?! Com subclassing?! Essa é a minha constante crítica.
Algo não faz o que vc quer, ou não faz direito? Vai lá e conserta!
Aponta o problema! Sugira! Participe! E não sente e faça seu próprio
de novo do zero. Não vejo sentido nisso, a não ser auto-aprendizado ou
auto-martírio.

Dar diversidade ao desenvolvedor é ótimo. Mas ele tem que, no mínimo,
ser orientado quanto a quais as características de cada opção para
escolher a melhor para si. E se o módulo não fizer tudo que ele quer,
ele deve ser estimulado a colaborar com o projeto, e não criar (mais
um) fork.

Acredito piamente que se os desenvolvedores Perl tivessem essa
mentalidade de extensão e colaboração ("não faz tudo que vc quer?
colabore, extenda e seja feliz!") em vez de o que me parece vigente
hoje ("não faz tudo que vc quer? faz o seu próprio e seja feliz!"),
ainda teríamos 2/3 do CPAN, todas as vantagens do Perl e do TIMTOWDTI
e ao mesmo tempo muito mais estabilidade, escalabilidade, evolução,
estrutura e orientação no desenvolvimento de aplicações, sem que o
desenvolvedor se perca no mar de 15000+ distribuições.

Isso, e um mapa de desenvolvimento de aplicações no CPAN, seria ótimo
(hmmm...idéias....acho que já sei do que vou falar no próximo YAPC::SA
:-)


[]s

-b


On Mon, May 19, 2008 at 12:50 AM, Eden Cardim <edencardim em gmail.com> wrote:
> On Mon, May 19, 2008 at 12:20 AM, Lorn <lorn.br em gmail.com> wrote:
>> Ops, falha minha :) foi mal.
>> Mas continuo achando que ainda falta um "ponteiro" para essas coisas novas,
>> tipo ao acessar o manual do CGI.pm ter um apontamento para o Catalyst/Jifty
>> e afins.
>
> Interagir com a comunidade é a melhor forma de ficar por dentro das novidades.
>
> --
> edenc.vox.com
> _______________________________________________
> SaoPaulo-pm mailing list
> SaoPaulo-pm em pm.org
> http://mail.pm.org/mailman/listinfo/saopaulo-pm
>


Mais detalhes sobre a lista de discussão SaoPaulo-pm