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

[Tiago Peczenyj]

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 <blabos at gmail.com>:
> 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 <wallace at reis.org.br>:
>> 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
>> wallace at reis.me
>> 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: SaoPaulo-pm at 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 at pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>



-- 
Tiago B. Peczenyj
Linux User #405772

http://pacman.blog.br