[SP-pm] Filosofias de Desenvolvimento [Was: flamewar mojo vscatalyst]

[ricardostock at bol.com.br]

Eden eu concordo exatamente com o que disse, principalmente nessa frase " 
prum iniciante isolado e mal-orientado é realmente mais difícil porque ele 
não tem conhecimento do eco-sistema. "

Pois eh exatamente assim que Eu e acredito que muitos dos inciantes em perl 
se sentiram ou se sentem ao abandonar um determinado conceito e partir para 
outro.

eu achei catalyst dificil, não experimentei ainda mojo.

eden ++

-----Mensagem Original----- 
From: Eden Cardim
Sent: Tuesday, July 23, 2013 11:02 AM
To: saopaulo-pm em mail.pm.org
Subject: [SP-pm] Filosofias de Desenvolvimento [Was: flamewar mojo 
vscatalyst]

>>>>> "Frederico" == Frederico Recsky <cartas em frederico.me> writes:
    Frederico> Otimo, então eu tenho um core gordo que ainda precisa
    Frederico> de plugins para fazer coisas "avançadas". O minimo que
    Frederico> eu espero de um programador também é que ele entenda o
    Frederico> conceito de plugins e acoplar as coisas.

Nem é tão gordo assim, na real, se você rodar o Perl::Metrics::Simple
no repositório de ambos, vai ver que de fato, o Mojo é mais gordo:

http://pastie.org/8167416
http://pastie.org/8167419

O mojo além de ter quase o dobro de código, o código existente é mais
complexo. Mas isso é porque ele oferece mais funcionalidades
out-of-the-box.

A questão que o Nelson está ressaltando é a natureza "caixa-preta" do
Mojo e ele está correto nesse aspecto. É um pacote de funcionalidade
consolidada que implica em não olhar ou conhecer os internals em
momento algum. Isso é uma característica do autor do framework, que é
um "lone wolf" e gosta de ter controle sobre o código. Pra esse tipo
de desenvolvedor (e existem muitos), essa abordagem realmente faz mais
sentido.

O Catalyst segue a filosofia contrária, a da caixa-branca. É uma
porção de módulos que foram se aglomerando em torno das 3 mil linhas
do core original (o que está dentro do Catalyst.pm) criados e
refinados por diversos autores que se preocupam em não pisar nos pés
uns dos outros. Esse core é estruturado de forma a facilitar a escrita
de módulos contribuídos/dependências e não a funcionalidade end-user.
Você precisa combinar os módulos desse eco-sistema para obter o
resultado desejado, coisa que prum iniciante isolado e mal-orientado é
realmente mais difícil porque ele não tem conhecimento do eco-sistema.
Porém, numa equipe cirúrgica ou ágil essa abordagem faz muito sentido.

-- 
Eden Cardim -- Insolide Soluções de TI Ltda.
+55 11 9644 8225
http://insoli.de
=begin disclaimer
   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
SaoPaulo-pm mailing list: SaoPaulo-pm em pm.org
L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
=end disclaimer