[SP-pm] Teen sells Perl cloud startup to ActiveState

Wed Jun 15 07:07:09 PDT 2011

Caro Ulisses,

Concordo contigo, temos orgulho da alta qualidade técnica da lista e este é
um assunto (ou vários para ser preciso) muito interessante e que está em
pauta. De tudo que eu lí e da minha experiência, eu gostaria de dividir isto
em alguns tópicos.

*** WARNING = email longo ****

*Mojolicious(?:\::Lite) x Catalyst*

Bom esta comparação é inevitável (e ocorrerá com mais frequência), já que o
Catalyst é o único framework de peso na comunidade. Se é justo ou não é
outra coisa, mas é inevitável. Assim como foi no passado comparar Catalyst
com Maypole. Temos outros frameworks (baseado no Plack, por exemplo) com a
mesma filosofia do Mojolicious mas que não está em no hype, porquê será ?
Leia o próximo parágrafo :D

*Sebastian*

O outro motivo desta comparação é o fato do Sebastian ser o criador de todos
estes frameworks. Então se já não fosse inevitável a comparação de
tecnologia, temos também a comparação da visão do Sebastian ao longo do
tempo sobre um mesmo assunto (framework de desenvolvimento). Quem já
acompanha o Sebastian ao longo deste tempo também sabe o comportamento
padrão dele, que normalmente significa a saída de um projeto quando ele (o
Sebastian) fica entediado.

*Facilidade*

Não sou especialista em linguística, portanto não consigo explicar as coisas
em termos técnicos, mas é uma percepção geral de que escrever alguma coisa
em Mojolicious é mais atrativo/amigável do que no Catalyst. O Eden disse
'... o problema é a forma. O Pessoal do Catalyst ensina a forma correta e
não a mais fácil ...', e isto me fez pensar que ele tem razão. Tanto é que
quando a gente fala de Catalyst é impossível não pensar em SER OBRIGADO a
aprender TT, DBIx::Class. Talvez não seja necessário, mas esta associação é
muito forte.

Quem conhece as pessoas que estão cuidando do Catalyst, entende esta
preocupação em transmitir a mensagem da '... forma correta ...', pois eles
tem experiências em grandes projetos no dia-a-dia, e sabem que estes
conhecimentos completo e concreto de MVC (melhor escrevendo, em Engenharia
de Software) será importante para qualquer coisa que ele for fazer.

O Mojolicious tem uma apresentação mais despojada (atenção, não estou
falando de quantidade de linha de código e ou dependência), mas intuitiva e
mais atrativa. Para começar, não sou obrigado a ser um hacker em outras
coisas. Se eu quero misturar o View no Controle, tudo bem, depois eu separo
isto. A proposta do View já está mais próximo do cara que conhece HTML e
Perl (eu não gosto disto, mas tenho que admitir que me ajudou no inicio).

*Influência *

É óbvio também a influência do Rail no Mojolicious, ou pelo menos em parte
do Mojolicious. Se você pensar numa aplicação Mojolicious + Mongoose então,
o negócio transmite uma sensação de facilidade de leitura incrível. Mas,
mesmo sem ser especialista, me parece que o Mojolicious está quebrando
algumas regras do MVC, ou pelo menos flexibilizando as regras.

E a influência não é apenas estética, é também comportamental com relação a
retro-compatibilidade. Somente depois de começar a estudar o Rail (por
curiosidade pessoal) eu entendi porquê o pessoal de Ruby é louco por TESTE.
Porquê uma versão do Rail não é necessariamente compatível com a versão
anterior (e não é mesmo, eu estou me cansando de pegar um documento que não
funciona na versão do Rail que eu tenho instalado, e quando vou ver é que
estou com a versão mais recente). O pessoal mais novo (principalmente o do
Rail) acha isto normal, tanto é que eles 'inventaram' o homebrew justamente
para ter várias versões do ruby/rail numa mesma máquina.

O Mojolicious caminha nesta mesma estrada, quer um exemplo ? Tente seguir de
cabo-a-rabo o artigo http://sao-paulo.pm.org/artigo/2010/Mojolicious, ele
não vai funcionar na versão corrente do Mojo. E como o Eden bem lembrou, o
Sebastian não mantem o histórico das versão no CPAN, então você terá que
manter contigo a versão do Mojo que está funcionando e escrever
muuuuiiiittttooooo teste na tua aplicação para saber o que está quebrado na
nova atualização.

Isto não é um problema para um early adopter, e precisamos de early adopter.

O pessoal do Catalyst tem preocupação com estabilidade neste momento, mais
do que novas features. Apesar que não sei quais novas features já não estão
implementada no Catalyst. No Catalyst temos implementação de serviços
baseado em JSON, XMLRPC antes dos frameworks 'corporativos' por exemplo, e
alterando apenas uma linha no código (ok, duas ... contanto a chamado do
módulo).

*Dependência*

Visão do Militante Perl : Sempre que falamos de
Perl, invariavelmente falamos no CPAN. Qual é o nosso mantra ? 90% do teu
programa está no CPAN ! Se eu acho que dependência é um problema, então
vamos queimar o CPAN e jogar fora a nossa real diferença em relação as
outras linguagem.

Visão do Desenvolvedor : Sou um péssimo programador e muito limitado. Estou
muito longe da genialidade do Matt, do Miyagawa, do Eden e de outros. Sendo
assim eu prefiro confiar no código destes caras do que do meu. Além do mais,
mesmo um programador limitado como eu, sabemos que reutilizar código é uma
boa prática em engenharia de software.

Visão do Sysadmin : O Eden comentou estes dias que o problema da dependência
é um problema de distribuição e não de desenvolvimento de software, e ele
tem razão. Sysadmin é um bicho limitado (eu falo pq sou um programador
limitar e um sysadmin experto - mesmo assim limitado) e muito acomodado. A
pior sub-raça dos sysadmin é os de Windows, que prefere baixar 1 giga de um
executável (lá vão algumas horas) e clicar em 20 telas e pronto, do que
ficar  baixando diversos pequenos pacotes. Mas seja sincero, quem gosta de
ficar pesquisando dependências. Se isto não fosse verdade, as distribuições
de linux não teriam inventadas os sistemas de empacotamento e viciado os
sysadmin com simples apt-get install. Precisamos explorar mais a questão da
distribuição, este sim é o problema.

* Resposta da equipe do Catalyst*

A tempo, o Eden está trabalhoando no Catalyst::Lite (
https://github.com/edenc/Catalyst-Lite), que como ele mesmo disse '... ficou
igual ao Mojolicious::Lite sem precisar escrever 23 mil linhas de códigos e
já tem tudos os plugins do Catalyst funcionando ...'

Em 15 de junho de 2011 09:31, Ulisses-IBIZ <ulisses em ibiz.com.br> escreveu:

> por mim, podem continuar com essas discussoes saudaveis; sempre serve para
> avaliar os pontos de vista de cada um; seus pros e contras.
>
> lista sem 'discussao' (no bom sentido) eh lista de publicacao de anivers,
> ES, troca de elogios de la e ca;
>
> ao meu ver isso traz 'sustancia' e explica o motivo das listas existirem.
>
> 'na minha humilde opiniao' !
> (expressao de eufemismo a la politicamente correto que me desagrada): ela
> ou esconde uma 'pre-desculpa' por dar uma opiniao (o q é absurdo!) ou
> camufla uma certa arrogancia... [dispensavel em ambos os casos]).
>
> moçada, por mim, manda ver; quero aprender com as experiências dos outros!
> e suas opiniões!
>
> grato!
>
> Ulisses Gomes Tecnologia da Informação IBIZ Tecnologia +55 11 5579-3178 r.
> 226 ulisses em ibiz.com.br www.ibiz.com.br
> ----- Original Message ----- From: "Thiago Rondon" <thiago em aware.com.br>
> To: <saopaulo-pm em mail.pm.org>
> Sent: Tuesday, June 14, 2011 10:24 PM
> Subject: Re: [SP-pm] Teen sells Perl cloud startup to ActiveState
>
>
>
> On Wed, Jun 15, 2011 at 01:47:18AM +0200, Wallace Reis wrote:
>
>  IMO, não é tão lindo assim, especialmente se você tem um sistema bem
>> complexo
>> com um grande número (5K+) de dependências e então surge uma bugfix
>> necessária pra alguma(s)
>> desta(s) dependência(s) e que pode causar incompatibilidade com alguma(s)
>> outra(s) e
>> que não se resolve com um simples upgrade, (guarda e repete). Pronto, você
>> tem um completo
>> PITA aqui. Não é impossível de se resolver, porém é uma situação que muita
>> gente foge
>> (vide uma longa thread que teve a pouco tempo na london-pm).
>>
>>
> É verdade. Estratégias de escolha de dependencia pode tornar o assunto bem
> extenso,
> este paper é bem interessante sobre o assunto, e cita outros cenários como
> o que
> você colocou.
>
>
> http://www.ics.uci.edu/~redmiles/inf233-FQ07/newestpapers/icse08-ariadne-v14.pdf
>
> Abs,
> -Thiago Rondon
>
> =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
>
>
>
> =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
>

-- 
"o animal satisfeito dorme". - Guimarães Rosa
-------------- Pr?xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20110615/5a04276a/attachment.html>