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