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

Marco A P D'Andrade mdacwb em gmail.com
Segunda Maio 19 11:07:45 PDT 2008


Em minha opinião...

Porque isto divide os esforços da comunidade... ao aprender e manter os módulos.

2008/5/19 Fernando Oliveira <fernandocorrea em gmail.com>:
> Na minha opinião, nem todos os forks tem motivos técnicos ou egocentricos.
> Existem pessoas que gostam de desafios e/ou de estudar... Eu mesmo de vez em
> quando me pergunto: "se eu fosse fazer [ponha aqui qq coisa complicada, sem
> solução instantanea, q já existe no CPAN], como eu faria?!". Eu não quero
> reinventar a roda, mostrar q o meu é melhor! sou movido pela pura
> curiosidade cientifica! Quero saber como EU faria! Quero passar por
> problemas q nunca passei. e tendo feito isso, estando pronto, porque não
> botar no CPAN?! Tudo bem, ele faz exatamente a mesma coisa q faz o [ponha
> aqui qq coisa complicada, sem solução instantanea, q já existe no CPAN] mas
> não é a mesma coisa! Isso q eu fiz pode ajudar outras pessoas... pq não
> botar no CPAN?!
>
> 2008/5/19 Marco A P D'Andrade <mdacwb em gmail.com>:
>>
>> 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
>> >
>> _______________________________________________
>> Cascavel-pm mailing list
>> Cascavel-pm em pm.org
>> http://mail.pm.org/mailman/listinfo/cascavel-pm
>
>
>
> --
> Just another Perl Hacker,
> Fernando (SmokeMachine)
> http://perl-e.org
> _______________________________________________
> 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