Eu também "aprendi" Mojolicious mais rapido, mas pq conhecida Rails e Sinatra e vc percebe uma influência de ambas no Mojo.
Um dia vou aprender Catalyst de verdade... 2011/6/14 Blabos de Blebe <[email protected]>: > Eu gosto de Mojoliciuos porque a curva de aprendizado é mais suave. > Ok, no nosso caso isso não faz diferença. > > Eu levei menos tempo pra aprender Mojolicious do que Catalyst, mas > será que não foi porque eu aprendi Catalyst primeiro? Blah, sei lá. > > Instalar dependências é algo que se faz uma vez. Ok, não faz > diferença. Mas é um saco. Mesmo que uma só vez. > > Eu não uso todas as features do Catalyst. Não uso todas as features do > Mojolicous, então, Mojolicious é mais adequado pra mim, que preciso > fazer coisas pequenas rapidamente. > > Se é bugado ou não, estatisticamente, quanto mais linhas de código, > maior a chance de encontrar bugs. Portanto, Se for analisar por esta > métrica, é provável que o Catalyst seja mais bugado. Por outro lado, > quanto mais maduro, maior o número de bugs descobertos e corrigidos. > Por esta métrica, é provável que o Mojolicious seja mais bugado. > > Enfim, não sei porque programadores tão experientes e carecas > (literalmente) de saber disso, ficam com essas briguinhas. Eu vou usar > Catalyst quando achar que devo e vou usar Mojolicious quando achar que > devo. Ambos se preciso for, ou nenhum se não precisar. > > Que thread mais sem noção... > > Vocês estão sem nada melhor pra fazer é? > > > > 2011/6/14 Wallace Reis <[email protected]>: >> On 15/06/2011, at 01:11, Thiago Rondon wrote: >>> Andre, >>> >>> Olha, este papo de depedencia é bem complicado de argumentar, vou >>> colocar aqui minha visão sobre isto e um exemplo com o próprio >>> Mojolicious. >>> >>> Mas, o simples fato de ter depedencia não é um problema, e porque não >>> é um problema ? >>> >>> 1 - Você esperar um pouco mais para instalar não é um problema. >>> 2 - Você só vai instalar uma vez, ou em algum deploy. >>> 3 - Você esta adquirindo um conhecimento e materia prima desenvolvida. >>> 4 - Você esta na maioria dos casos como 'deploy' usufruindo de testes novos. >>> 5 - Maturidade, código utilizado e compartilhado por mais ambientes. >>> 6 - (...) >>> >>> E quando pode ser um problema ter dependencias ? Na minha opinião, >>> apenas quando você esta utilizando um módulo mal escrito, >>> e para isto é importante que você saiba onde esta pisando, saber >>> da qualidade das dependencias é importante. >> >> 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). >> >>> https://github.com/kraih/mojo/commits/507ece232a8975d1626263cc4d875f13148fa1e7/lib/Mojo/JSON.pm >>> >>> Existem módulos de JSON que são utilizados por muitos outros módulos, >>> frameworks e etc... já prontos e com uma perfomace muito aceitavel >>> (JSON::XS). >>> >>> Porém, por algum motivo (alguém sabe pq ?) o pessoal do Mojolicious >>> resolveu escrever o seu próprio, veja a quantidade de bugs que eles >>> estão arrumando ainda. (vide histórico) >>> >>> Vale apena re-inventar a roda neste caso ? Para você não ter mais uma >>> dependencia (para o JSON neste caso), existe um módulo novo sendo utilizado >>> e com bugs "já velhos" sendo consertado o tempo todo ? >>> >>> Agora fica minha pergunta, neste caso dependencias é bom ou ruim ? >> >> >> Geralmente, eu prefiro usar algo pronto, a não ser que seja por alguma >> otimização bem >> justificada com benchmarks. >> >> -- >> Wallace Reis | wreis >> [email protected] >> http://www.about.me/wallacereis >> Senior Software Developer - http://123people.com >> =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 >> > =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 > -- Tiago B. Peczenyj Linux User #405772 http://pacman.blog.br =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
