<br><br><div class="gmail_quote">Em 15 de junho de 2011 13:08, Eden Cardim <span dir="ltr"><<a href="mailto:edencardim@gmail.com">edencardim@gmail.com</a>></span> escreveu:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
>>>>> "Solli" == Solli Honorio <<a href="mailto:shonorio@gmail.com">shonorio@gmail.com</a>> writes:<br>
<br>
Solli> O outro motivo desta comparação é o fato do Sebastian ser o<br>
Solli> criador de todos estes frameworks. Então se já não fosse<br>
Solli> inevitável a comparação de tecnologia, temos também a<br>
Solli> comparação da visão do Sebastian ao longo do tempo sobre um<br>
Solli> mesmo assunto (framework de desenvolvimento). Quem já<br>
Solli> acompanha o Sebastian ao longo deste tempo também sabe o<br>
Solli> comportamento padrão dele, que normalmente significa a saída<br>
Solli> de um projeto quando ele (o Sebastian) fica entediado.<br>
<br>
Ele costuma ficar entediado quando a comunidade toma uma decisão<br>
diferente da dele. Observa que o problema não é introduzir um "framework<br>
concorrente", o problema é escrever um monte de código que faz quase a<br>
mesma coisa que um projeto existente já faz (vide Catalyst::Lite).<br>
<br>
Esse é o meu problema com o Mojolicious::Lite e o Dancer, não tem<br>
nenhuma novidade semântica. Com algumas linhas de Catalyst dá pra emular<br>
a semântica dos dois. Já a semântica do Web::Simple é muito mais<br>
sofisticada, não dá pra fazer com nada que já exista, e foi por isso que<br>
o Matt fez.<br>
<br>
E aí vem o corolário: a falta de justificativa técnica pra se criar um<br>
projeto desse nível de complexidade inteiramente do zero para apresentar<br>
uma divergência semântica/funcional mínima é uma coisa que me deixa sem<br>
reação racional, eu só posso presumir que seja alguma coisa humana.<br>
<br>
Solli> Não sou especialista em linguística, portanto não consigo<br>
Solli> explicar as coisas em termos técnicos, mas é uma percepção<br>
Solli> geral de que escrever alguma coisa em Mojolicious é mais<br>
Solli> atrativo/amigável do que no Catalyst. O Eden disse '... o<br>
Solli> problema é a forma. O Pessoal do Catalyst ensina a forma<br>
Solli> correta e não a mais fácil ...', e isto me fez pensar que ele<br>
Solli> tem razão. Tanto é que quando a gente fala de Catalyst é<br>
Solli> impossível não pensar em SER OBRIGADO a aprender TT,<br>
Solli> DBIx::Class. Talvez não seja necessário, mas esta associação<br>
Solli> é muito forte. <br>
<br>
Mas até aí é só escrever um manual e renovar o design da página do<br>
projeto, que certamente é mais fácil do que escrever um framework do<br>
zero.<br>
<br>
Solli> Quem conhece as pessoas que estão cuidando do Catalyst,<br>
Solli> entende esta preocupação em transmitir a mensagem da<br>
Solli> '... forma correta ...', pois eles tem experiências em<br>
Solli> grandes projetos no dia-a-dia, e sabem que estes<br>
Solli> conhecimentos completo e concreto de MVC (melhor escrevendo,<br>
Solli> em Engenharia de Software) será importante para qualquer<br>
Solli> coisa que ele for fazer.<br>
<br>
O problema é que todo projeto grande começa como um projeto pequeno, e<br>
depois o pessoal vem pedir suporte, se eles não tiverem um pensamento<br>
minimamente estruturado, não tem como ajudar. A filosofia da comunidade<br>
Catalyst (e das comunidades relacionadas, tipo Moose, DBIx::Class,<br>
KiokuDB e cia) é de tentar estabelecer o mínimo de compromisso com uma<br>
categoria específica de usuários em favor do grupo inteiro (de early<br>
adopter a guru).<br>
<br>
Solli> O Mojolicious tem uma apresentação mais despojada (atenção,<br>
Solli> não estou falando de quantidade de linha de código e ou<br>
Solli> dependência), mas intuitiva e mais atrativa. Para começar,<br>
Solli> não sou obrigado a ser um hacker em outras coisas. Se eu<br>
Solli> quero misturar o View no Controle, tudo bem, depois eu separo<br>
Solli> isto. A proposta do View já está mais próximo do cara que<br>
Solli> conhece HTML e Perl (eu não gosto disto, mas tenho que<br>
Solli> admitir que me ajudou no inicio). <br>
<br>
O problema é que nunca vão separar se não tiver suporte embutido no<br>
software. Daí esse usuário vai se frustrar quando os mantenedores não<br>
conseguirem adivinhar telepaticamente quais foram as gambiarras que ele<br>
montou "intuitivamente" e vai acabar indo pra outras soluções depois que<br>
o fascínio inicial com o framework passar, muitos desses vão pra outras<br>
linguagens, inclusive, e vão culpar a linguagem inteira por isso.<br>
<br>
Solli> É óbvio também a influência do Rail no Mojolicious, ou pelo<br>
Solli> menos em parte do Mojolicious. Se você pensar numa aplicação<br>
Solli> Mojolicious + Mongoose então, o negócio transmite uma<br>
Solli> sensação de facilidade de leitura incrível. Mas, mesmo sem<br>
Solli> ser especialista, me parece que o Mojolicious está quebrando<br>
Solli> algumas regras do MVC, ou pelo menos flexibilizando as<br>
Solli> regras.<br>
<br>
É igual à sensação de facilidade que o windows transmite em contraste ao<br>
linux ou bsd. Novamente, o problema é criar um core razoável, tendo<br>
isso, vestir uma roupa bonitinha é fácil (o ubuntu tá mostrando isso).<br>
<br>
Solli> E a influência não é apenas estética, é também comportamental<br>
Solli> com relação a retro-compatibilidade. Somente depois de<br>
Solli> começar a estudar o Rail (por curiosidade pessoal) eu entendi<br>
Solli> porquê o pessoal de Ruby é louco por TESTE. Porquê uma versão<br>
Solli> do Rail não é necessariamente compatível com a versão<br>
Solli> anterior (e não é mesmo, eu estou me cansando de pegar um<br>
Solli> documento que não funciona na versão do Rail que eu tenho<br>
Solli> instalado, e quando vou ver é que estou com a versão mais<br>
Solli> recente). O pessoal mais novo (principalmente o do Rail) acha<br>
Solli> isto normal, tanto é que eles 'inventaram' o homebrew<br>
Solli> justamente para ter várias versões do ruby/rail numa mesma<br>
Solli> máquina.<br>
<br>
Solli> O Mojolicious caminha nesta mesma estrada, quer um exemplo ?<br>
Solli> Tente seguir de cabo-a-rabo o artigo <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
Solli> artigo/2010/Mojolicious, ele não vai funcionar na versão<br>
Solli> corrente do Mojo. E como o Eden bem lembrou, o Sebastian não<br>
Solli> mantem o histórico das versão no CPAN, então você terá que<br>
Solli> manter contigo a versão do Mojo que está funcionando e<br>
Solli> escrever muuuuiiiittttooooo teste na tua aplicação para saber<br>
Solli> o que está quebrado na nova atualização.<br>
<br>
Solli> Isto não é um problema para um early adopter, e precisamos de<br>
Solli> early adopter.<br>
<br>
É mas um early adopter que chega por conta da conveniência, vai embora<br>
quando o sistema dele quebrar, pelo mesmo motivo.<br>
<br>
Solli> O pessoal do Catalyst tem preocupação com estabilidade neste<br>
Solli> momento, mais do que novas features. Apesar que não sei quais<br>
Solli> novas features já não estão implementada no Catalyst. No<br>
Solli> Catalyst temos implementação de serviços baseado em JSON,<br>
Solli> XMLRPC antes dos frameworks 'corporativos' por exemplo, e<br>
Solli> alterando apenas uma linha no código (ok, duas ... contanto a<br>
Solli> chamado do módulo).<br>
<br>
Olha, tem feature nova sim, mas o desenvolvimento das features não são<br>
centralizadas no core, é orgânico e ecológico. Tá sempre saindo um ou<br>
outro plugin/model/view/controller/engine. O trabalho do pessoal do core<br>
tem sido mais na direção de adubar o solo, regar as plantas e criar mais<br>
canteiros do que trazer novas sementes pro quintal. É a mesma receita da<br>
apple store, das facebook apps e cia.<br>
<br>
Solli> Visão do Militante Perl : Sempre que falamos de<br>
Solli> Perl, invariavelmente falamos no CPAN. Qual é o nosso mantra<br>
Solli> ? 90% do teu programa está no CPAN ! Se eu acho que<br>
Solli> dependência é um problema, então vamos queimar o CPAN e jogar<br>
Solli> fora a nossa real diferença em relação as outras linguagem.<br>
<br>
Solli> Visão do Desenvolvedor : Sou um péssimo programador e muito<br>
Solli> limitado. Estou muito longe da genialidade do Matt, do<br>
Solli> Miyagawa, do Eden e de outros. Sendo assim eu prefiro confiar<br>
Solli> no código destes caras do que do meu. Além do mais, mesmo um<br>
Solli> programador limitado como eu, sabemos que reutilizar código é<br>
Solli> uma boa prática em engenharia de software.<br>
<br>
A questão não é ser gênio ou não, é o princípio de crowdsourcing, também<br>
conhecida como a "Lei do Linus": "com uma quantidade suficiente de<br>
olhos, todos os problemas são simples". Agora, se a filosofia do teu<br>
projeto é baseada em evitar a agregação de mais olhos, teus problemas<br>
vão ser todos complicados.<br>
<br>
Solli> Visão do Sysadmin : O Eden comentou estes dias que o problema<br>
Solli> da dependência é um problema de distribuição e não de<br>
Solli> desenvolvimento de software, e ele tem razão. Sysadmin é um<br>
Solli> bicho limitado (eu falo pq sou um programador limitar e um<br>
Solli> sysadmin experto - mesmo assim limitado) e muito acomodado. A<br>
Solli> pior sub-raça dos sysadmin é os de Windows, que prefere<br>
Solli> baixar 1 giga de um executável (lá vão algumas horas) e<br>
Solli> clicar em 20 telas e pronto, do que ficar baixando diversos<br>
Solli> pequenos pacotes. Mas seja sincero, quem gosta de ficar<br>
Solli> pesquisando dependências.<br>
<br>
Cara, eu tenho uma opinião inconvencional sobre isso, mas vocês vão ter<br>
que ler no blog que o email tá ficando grande. :)<br></blockquote><div><br></div><div>neste blog <a href="http://blog.edencardim.com/">http://blog.edencardim.com/</a> ?</div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Solli> Se isto não fosse verdade, as<br>
Solli> distribuições de linux não teriam inventadas os sistemas de<br>
Solli> empacotamento e viciado os sysadmin com simples apt-get<br>
Solli> install. Precisamos explorar mais a questão da distribuição,<br>
Solli> este sim é o problema.<br>
<br>
Também acho, isso tudo tá igual o projeto de alfabetização de idosos no<br>
campo que tinha cerca de 90% de abandono escolar: o problema não era a<br>
técnica de ensino, era que os velhotes precisavam de óculos.<br>
<br>
Solli> Resposta da equipe do Catalyst<br>
<br>
Solli> A tempo, o Eden está trabalhoando no Catalyst::Lite<br>
Solli> (<a href="https://github.com/edenc/Catalyst-Lite" target="_blank">https://github.com/edenc/Catalyst-Lite</a>), que como ele mesmo<br>
Solli> disse '... ficou igual ao Mojolicious::Lite sem precisar<br>
Solli> escrever 23 mil linhas de códigos e já tem tudos os plugins<br>
Solli> do Catalyst funcionando ...' <br>
<br>
"A tempo", leia-se: "desde que essa thread começou" e escrevi mais<br>
português do que código :)<br>
<div class="im"><br>
--<br>
Eden Cardim Need help with your Catalyst or DBIx::Class project?<br>
Code Monkey <a href="http://www.shadowcat.co.uk/catalyst/" target="_blank">http://www.shadowcat.co.uk/catalyst/</a><br>
Shadowcat Systems Ltd. Want a managed development or deployment platform?<br>
</div><a href="http://blog.edencardim.com/" target="_blank">http://blog.edencardim.com/</a> <a href="http://www.shadowcat.co.uk/servers/" target="_blank">http://www.shadowcat.co.uk/servers/</a><br>
<a href="http://twitter.com/#!/edenc" target="_blank">http://twitter.com/#!/edenc</a><br>
<div><div></div><div class="h5">=begin disclaimer<br>
Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>"o animal satisfeito dorme". - Guimarães Rosa<br>