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

Segunda Maio 19 12:47:39 PDT 2008

Reforçando...

Que o primeiro byte aquele que nunca fez algo, só pra ver como seria a
sua versão...

Desenvolver a propria versão é muito bom, para aprendizado, mas postar
isto no CPAN é que eu acho errado...

Sds,
Marco Antonio

2008/5/19 breno <breno em rio.pm.org>:
> Foi o que eu quis dizer com "não vejo sentido nisso, a não ser
> auto-aprendizado ou auto-martírio". No caso do Fernando, seria
> auto-aprendizado (espero!) :-P
>
> []s
>
> -b
>
> 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
>>
> _______________________________________________
> Cascavel-pm mailing list
> Cascavel-pm em pm.org
> http://mail.pm.org/mailman/listinfo/cascavel-pm
>