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

Diogo Leal diogo at diogoleal.com
Tue Jun 14 17:30:12 PDT 2011


2011/6/14 Blabos de Blebe <blabos at gmail.com>

>
> 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.
>
>
Isso parece aquelas coisas de Vim X Emacs,, Slackware X Debian, Windows X
Linux, Vasco X Urubuzada.




> Que thread mais sem noção...
>
> Vocês estão sem nada melhor pra fazer é?
>


Depois ainda perguntam porque que eu achava que o Blabos era um cara com
mais de 50 anos =p

>
>
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20110614/36ad7c4e/attachment-0001.html>


More information about the SaoPaulo-pm mailing list