[Cascavel-pm] [SP-pm] O Futuro do Perl/CPAN

Marco A P D'Andrade mdacwb em gmail.com
Segunda Maio 19 08:09:29 PDT 2008


A mentalidade da comunidade, ao meu ver, tem mudado, veja que hoje
temos até literatura formal defendendo as melhores praticas  (Best
Practicals)...

Eu li um artigo, que é claro, não lembro onde foi, de um defensor de
Ruby, que elogiava CGI::Application, Catalyst e Maypole, e se
vangloriava do fato de ter apenas o Rails para aprender, e conviver
com os problemas (que segundo ele não são poucos)...

Fork por questões técnicas, restrições de licença, ótimo... mas fork
por mero ego politico... acho pésssimo !

Eu tenho o hábito de produzir código que outro dará manutenção, ou ao
menos perseguir isto. Entendo que para módulos que serão continuados
por muito tempo, é de grande importância pensar em incorporar as
praticas de modelagem, já adotadas a muito tempo no cpan (com no
mínimo de documentação, testes, namespace, etc).

Confesso que não adotei todas as praticas ainda, mas reconheço esta
pendencia, e estou tentando corrigir, de forma que meus proprios
módulos e sistemas internos sejam instalados na base do "perl
Makefile.PL" ...

até porque... é muito mais simples assim ;)


Sds,
Marco Antonio


2008/5/19 breno <breno em rio.pm.org>:
> 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
>>
> _______________________________________________
> Cascavel-pm mailing list
> Cascavel-pm em pm.org
> http://mail.pm.org/mailman/listinfo/cascavel-pm
>


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