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

Solli Honorio shonorio at gmail.com
Wed Jun 15 09:47:24 PDT 2011


Em 15 de junho de 2011 13:08, Eden Cardim <edencardim em gmail.com> escreveu:

> >>>>> "Solli" == Solli Honorio <shonorio em gmail.com> 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: SaoPaulo-pm em pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>



-- 
"o animal satisfeito dorme". - Guimarães Rosa
-------------- Pr?xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20110615/c3ec997e/attachment-0001.html>


More information about the SaoPaulo-pm mailing list