[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