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

Wed Jun 15 07:44:26 PDT 2011

Solli, pode tirar o 'Caro' apesar de já ser tiozinho de 50 que programa e toca empresa.
O lado programador sempre tenta não deixar o empresário cada vez mais tiozinho...

From: Solli Honorio 
  To: saopaulo-pm at mail.pm.org 
  Sent: Wednesday, June 15, 2011 11:07 AM
  Subject: Re: [SP-pm] Teen sells Perl cloud startup to ActiveState

  Caro Ulisses,

  Concordo contigo, temos orgulho da alta qualidade técnica da lista e este é um assunto (ou vários para ser preciso) muito interessante e que está em pauta. De tudo que eu lí e da minha experiência, eu gostaria de dividir isto em alguns tópicos.

  *** WARNING = email longo ****

  Mojolicious(?:\::Lite) x Catalyst

  Bom esta comparação é inevitável (e ocorrerá com mais frequência), já que o Catalyst é o único framework de peso na comunidade. Se é justo ou não é outra coisa, mas é inevitável. Assim como foi no passado comparar Catalyst com Maypole. Temos outros frameworks (baseado no Plack, por exemplo) com a mesma filosofia do Mojolicious mas que não está em no hype, porquê será ? Leia o próximo parágrafo :D 

  Sebastian

  O outro motivo desta comparação é o fato do Sebastian ser o criador de todos estes frameworks. Então se já não fosse inevitável a comparação de tecnologia, temos também a comparação da visão do Sebastian ao longo do tempo sobre um mesmo assunto (framework de desenvolvimento). Quem já acompanha o Sebastian ao longo deste tempo também sabe o comportamento padrão dele, que normalmente significa a saída de um projeto quando ele (o Sebastian) fica entediado.

  Facilidade

  Não sou especialista em linguística, portanto não consigo explicar as coisas em termos técnicos, mas é uma percepção geral de que escrever alguma coisa em Mojolicious é mais atrativo/amigável do que no Catalyst. O Eden disse '... o problema é a forma. O Pessoal do Catalyst ensina a forma correta e não a mais fácil ...', e isto me fez pensar que ele tem razão. Tanto é que quando a gente fala de Catalyst é impossível não pensar em SER OBRIGADO a aprender TT, DBIx::Class. Talvez não seja necessário, mas esta associação é muito forte. 

  Quem conhece as pessoas que estão cuidando do Catalyst, entende esta preocupação em transmitir a mensagem da '... forma correta ...', pois eles tem experiências em grandes projetos no dia-a-dia, e sabem que estes conhecimentos completo e concreto de MVC (melhor escrevendo, em Engenharia de Software) será importante para qualquer coisa que ele for fazer.

  O Mojolicious tem uma apresentação mais despojada (atenção, não estou falando de quantidade de linha de código e ou dependência), mas intuitiva e mais atrativa. Para começar, não sou obrigado a ser um hacker em outras coisas. Se eu quero misturar o View no Controle, tudo bem, depois eu separo isto. A proposta do View já está mais próximo do cara que conhece HTML e Perl (eu não gosto disto, mas tenho que admitir que me ajudou no inicio). 

  Influência 

  É óbvio também a influência do Rail no Mojolicious, ou pelo menos em parte do Mojolicious. Se você pensar numa aplicação Mojolicious + Mongoose então, o negócio transmite uma sensação de facilidade de leitura incrível. Mas, mesmo sem ser especialista, me parece que o Mojolicious está quebrando algumas regras do MVC, ou pelo menos flexibilizando as regras.

  E a influência não é apenas estética, é também comportamental com relação a retro-compatibilidade. Somente depois de começar a estudar o Rail (por curiosidade pessoal) eu entendi porquê o pessoal de Ruby é louco por TESTE. Porquê uma versão do Rail não é necessariamente compatível com a versão anterior (e não é mesmo, eu estou me cansando de pegar um documento que não funciona na versão do Rail que eu tenho instalado, e quando vou ver é que estou com a versão mais recente). O pessoal mais novo (principalmente o do Rail) acha isto normal, tanto é que eles 'inventaram' o homebrew justamente para ter várias versões do ruby/rail numa mesma máquina.

  O Mojolicious caminha nesta mesma estrada, quer um exemplo ? Tente seguir de cabo-a-rabo o artigo http://sao-paulo.pm.org/artigo/2010/Mojolicious, ele não vai funcionar na versão corrente do Mojo. E como o Eden bem lembrou, o Sebastian não mantem o histórico das versão no CPAN, então você terá que manter contigo a versão do Mojo que está funcionando e escrever muuuuiiiittttooooo teste na tua aplicação para saber o que está quebrado na nova atualização.

  Isto não é um problema para um early adopter, e precisamos de early adopter.

  O pessoal do Catalyst tem preocupação com estabilidade neste momento, mais do que novas features. Apesar que não sei quais novas features já não estão implementada no Catalyst. No Catalyst temos implementação de serviços baseado em JSON, XMLRPC antes dos frameworks 'corporativos' por exemplo, e alterando apenas uma linha no código (ok, duas ... contanto a chamado do módulo). 

  Dependência

  Visão do Militante Perl : Sempre que falamos de Perl, invariavelmente falamos no CPAN. Qual é o nosso mantra ? 90% do teu programa está no CPAN ! Se eu acho que dependência é um problema, então vamos queimar o CPAN e jogar fora a nossa real diferença em relação as outras linguagem.

  Visão do Desenvolvedor : Sou um péssimo programador e muito limitado. Estou muito longe da genialidade do Matt, do Miyagawa, do Eden e de outros. Sendo assim eu prefiro confiar no código destes caras do que do meu. Além do mais, mesmo um programador limitado como eu, sabemos que reutilizar código é uma boa prática em engenharia de software.

  Visão do Sysadmin : O Eden comentou estes dias que o problema da dependência é um problema de distribuição e não de desenvolvimento de software, e ele tem razão. Sysadmin é um bicho limitado (eu falo pq sou um programador limitar e um sysadmin experto - mesmo assim limitado) e muito acomodado. A pior sub-raça dos sysadmin é os de Windows, que prefere baixar 1 giga de um executável (lá vão algumas horas) e clicar em 20 telas e pronto, do que ficar  baixando diversos pequenos pacotes. Mas seja sincero, quem gosta de ficar pesquisando dependências. Se isto não fosse verdade, as distribuições de linux não teriam inventadas os sistemas de empacotamento e viciado os sysadmin com simples apt-get install. Precisamos explorar mais a questão da distribuição, este sim é o problema.

   Resposta da equipe do Catalyst

  A tempo, o Eden está trabalhoando no Catalyst::Lite (https://github.com/edenc/Catalyst-Lite), que como ele mesmo disse '... ficou igual ao Mojolicious::Lite sem precisar escrever 23 mil linhas de códigos e já tem tudos os plugins do Catalyst funcionando ...'

  Em 15 de junho de 2011 09:31, Ulisses-IBIZ <ulisses at ibiz.com.br> escreveu:

    por mim, podem continuar com essas discussoes saudaveis; sempre serve para avaliar os pontos de vista de cada um; seus pros e contras.

    lista sem 'discussao' (no bom sentido) eh lista de publicacao de anivers, ES, troca de elogios de la e ca;

    ao meu ver isso traz 'sustancia' e explica o motivo das listas existirem.

    'na minha humilde opiniao' !
    (expressao de eufemismo a la politicamente correto que me desagrada): ela ou esconde uma 'pre-desculpa' por dar uma opiniao (o q é absurdo!) ou
    camufla uma certa arrogancia... [dispensavel em ambos os casos]).

    moçada, por mim, manda ver; quero aprender com as experiências dos outros! e suas opiniões!

    grato!

    Ulisses Gomes Tecnologia da Informação IBIZ Tecnologia +55 11 5579-3178 r. 226 ulisses at ibiz.com.br www.ibiz.com.br
    ----- Original Message ----- From: "Thiago Rondon" <thiago at aware.com.br>
    To: <saopaulo-pm at mail.pm.org>
    Sent: Tuesday, June 14, 2011 10:24 PM
    Subject: Re: [SP-pm] Teen sells Perl cloud startup to ActiveState

    On Wed, Jun 15, 2011 at 01:47:18AM +0200, Wallace Reis wrote:

      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).

    É verdade. Estratégias de escolha de dependencia pode tornar o assunto bem extenso,
    este paper é bem interessante sobre o assunto, e cita outros cenários como o que
    você colocou.

    http://www.ics.uci.edu/~redmiles/inf233-FQ07/newestpapers/icse08-ariadne-v14.pdf

    Abs,
    -Thiago Rondon

    =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

  -- 
  "o animal satisfeito dorme". - Guimarães Rosa

------------------------------------------------------------------------------

  =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/20110615/677b25e6/attachment-0001.html>