[SP-pm] Por que Perl não emplaca?
Eden Cardim
edencardim at gmail.com
Fri Dec 11 09:48:24 PST 2009
>>>>> "Otávio" == Otávio Fernandes <otaviof em gmail.com> writes:
Otávio> Outro fator é o efeito de "coletividade". Se muitas pessoas
Otávio> pularem pela janela, as outras pulam também (sem sombra de
Otávio> dúvidas).
Na economia, isso é chamado de "efeito manada".
Otávio> Porem, temos esta situação ruim mais acentuada aqui na
Otávio> América Latina, ao contrário acontece na Europa e EUA. Lá a
Otávio> linguagem é valorizada e largamente utilizada, e o mercado é
Otávio> mais maduro do que o nosso, não há como comparar.
>> Por que, que uma empresa escolhe ruby, sem saber o que é, mas não
>> escolhe Perl? Por que, que eu não recebo na minha caixa postal,
>> mais de 30 ofertas diárias de vagas, como acontece com .NET?
Otávio> Bom, neste caso eu acredito em dois motivos principais:
Otávio> 1) Marketing: Ruby ganhou muitos adeptos nos últimos anos, e
Otávio> é muito eficiente para resolver alguns problemas, Web entre
Otávio> eles, não é marketing vazio simplesmente. Porem, este é um
Otávio> grande "case" para nós, pois ela já tem mais de 15 anos de
Otávio> história e por quase todo o tempo ficou nas sombras;
Otávio> 2) Mundo corporativo (sic!): a maioria das empresas não está
Otávio> se importando com a tecnologia em si, nem tão pouco tentando
Otávio> inovar. Para estes, ter uma outra empresa grande, renomada,
Otávio> cuidado da linguagem/tecnologia é mais importante do que se
Otávio> esta é a melhor escolha, ou não. Afinal, eles não vão
Otávio> colocar a mão em código (claro!), e se existem centenas de
Otávio> pessoas para aquela vaga, acaba sendo mais barato/fácil
Otávio> contratar um programador de mainstream.
Eu acho que o buraco ainda é mais em baixo. A cultura corporativa
brasileira valoriza muito mais os elementos sociais do que os elementos
técnicos. Pode ser que a minha amostragem tenha sido ruim, mas todas as
empresas das quais eu conheço detalhes internos, dão preferência ao
profissional "de confiança" que trabalha lá há 5 anos do que um cara
novo mas que tem um currículo/portfolio visivelmente melhor, aliás,
nunca vão pensar em contratar alguém com habilidade técnica superior
para um cargo de liderança e tomada de decisões. Aí o que acontece é que
o corpo administrativo acaba ficando mal-acessorado e acaba só
enxergando as soluções que são bem marketeadas, e o profissional com
qualificação técnica superior nunca escala a escada corporativa porque
ele é uma ameaça pra quem está ocupando os cargos mais altos atualmente.
Otávio> Como exemplo contrário, eu cito as "startups", empresas
Otávio> pequenas que estão focando sempre na melhor solução
Otávio> tecnologica, para economizar tempo e dinheiro. Estas sim,
Otávio> estão invando muito e escolheriam o Perl em mais situações
Otávio> se nós fossemos mais fortes no fator 1. Estas empresas
Otávio> tendem a crescer, as IBMs do amanhã.
>> Se Perl é tão boa assim (e é tão óbvio isso, todo mundo sabe
>> disso) por que Perl não emplaca no "Baixo Mercado"?
Otávio> Perl já emplacou! Perl está em tudo o que nós usamos no
Otávio> dia-a-dia. Não existem muitas vagas focadas em Perl, isso é
Otávio> verdade, mas todas as empresas tem algo que é feito nesta
Otávio> linguagem, ou depende dele.
Eu diria que o "mercado baixo" já está relativamente emplacado, Perl
hoje em dia é quase como C, só que está atuando numa camada de
infra-estrutura que não gera mais hype porque as pessoas já se
acostumaram a ter isso disponível. Eu diria que o mercado-alvo de Perl
hoje em dia é outro e está disputando espaço com mais alternativas do
que existiam há 10 anos atrás.
Otávio> No entanto, hoje eu não me sinto mais tão incomodado com
Otávio> este cenário.Eu estou vendo tantas linguagens do passado
Otávio> voltando a ativa com toda a força, para resolver problemas
Otávio> que realmente elas são boas para. Observe os casos:
Otávio> * Paradigma funcional: há poucos anos atrás, ninguém mais
Otávio> escutava falar sobre ele, para as empresas ele havia morrido
Otávio> há tempos e já estava enterrado. Hoje, voltou a ser
Otávio> mainstream, e é a grande esperança de escalabilidade para os
Otávio> produtos na internet. Fenix;
Ninguém no mundo corporativo brasileiro, porque no ambiente acadêmico
sempre foi amplamente utilizado. E de novo, entra o efeito manada, as
pessoas falam sobre funcional aplicado a escalabilidade mas a grande
maioria não sabe fazer uma comparação com o paradigma imperativo e
explicar porque que ele teoricamente escalaria melhor, só falam porque
tem um monte de outras pessoas falando também.
Otávio> * SQL: tentando escalar aplicações chega-se a conclusão que
Otávio> banco de dados relacionais são um grande "encosto" (e é
Otávio> verdade!). Hoje nós temos o movimento "NoSQL" focando em
Otávio> usarmos ferramentas não-relacionais para substituir onde o
Otávio> SQL é inútil, e trazer este relacionamento (se necessário)
Otávio> para a aplicação;
Tem muita especulação a respeito, na minha visão o que acontece é que as
pessoas tem uma noção barata a respeito do que é o modelo relacional e
acham que é mais barato desenvolver soluções alternativas sem
comprovação formal do que pagar/pesquisar para ampliar a noção de modelo
relacional atual. SQL é só uma implementação de especificação da teoria
dos conjuntos, e pra dizer que a teoria dos conjuntos é um "encosto"
você precisaria derrubar séculos de pesquisa e desenvolvimento em
matemática e inclusive reformar todo o sistema de ensino
fundamental. Além do quê, o paradigma funcional é todo embasado na
teoria dos conjuntos, então adotar funcional e abandonar SQL é
completamente quanto contraditório.
Eu acho que o problema do modelo relacional, em específico a
implementação de SQL, é similar ao problema do Perl, a linguagem leva a
culpa pelo código porco criado por programadores ruins.
--
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://edenc.vox.com/ http://www.shadowcat.co.uk/servers/
More information about the SaoPaulo-pm
mailing list