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

Segunda Maio 19 09:29:56 PDT 2008

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
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://mail.pm.org/pipermail/cascavel-pm/attachments/20080519/d0a79429/attachment.html 