Há alguns meses perguntaram ao Rich Hickey:
“How much does a choice of language really matter? Are there good reasons to choose one language over another or does it all come down to taste?”
E sua resposta foi:
“I think it matters quite a bit. A good language is opinionated, and strives to make a particular style of programming easy and idiomatic. It only seems a matter of taste when you are comparing languages that are more similar than they are different, like Java/C# or Python/Ruby. Try something really different like Clojure, Haskell, or Erlang and the fact that it matters becomes readily apparent.”
Eu acho que concordo bastante com sua opinião. Discutir se Java é melhor do que C#, por exemplo, é inútil, porque as duas linguagens são muito semelhantes. Nesse caso, o que acaba pesando mais na hora da escolha é o ecosistema no qual cada linguagem está inserida, que pode agradar mais a um ou a outro programador. É puro gosto.
O mesmo vale para Ruby e Python, como ele mesmo cita.
Mundos diferentes
Mas e se a comparação for entre Java e Ruby, por exemplo, como é que fica? Na minha humilde opinião, fica no sense. Porque Java e Ruby não são liguagens de mesma proposta; e mesmo sendo ambas de propósito geral, ambas tem objetivos claramente diferentes.
Comparação entre mundos diferentes
Agora vou, propositalmente, contradizer um pouco o que eu disse à cima: faz sentido, sim, você comparar Ruby com Java; Erlang com Python; F# com PHP. Sim, faz sentido.
Faz sentido quando você está escolhendo a linguagem que oferece a melhor solução para um dado domínio de problema.
Super CRUD com Erlang? Não, acho que não.
Precisar de concorrência massiva, tolerância a falhas, processos distribuídos, downtime mínimo? Humm, não sei não, mas será que não é de Erlang que você precisa?
Entende? É nessa hora que a escolha de uma linguagem começa a pesar de verdade. Isso realmente importa.
Mundos diferentes se complementam
Tempos atrás, escrevendo programas Erlang/OTP, senti falta de uma ferramenta que me ajudasse a criar rapidamente a estrutura inicial do projeto e umas coisas mais. O que fiz? Criei uma ferramenta que faz isso: otp_kickoff. Em Erlang? Não, em Ruby. Fiz isso em poucas horas, usando Thor.
Pouco tempo depois, senti falta de uma ferramenta de build amigável. Novamente, o que fiz? Criei o ebuilder, usando Ruby/Thor.
Um outro exemplo de mundos diferentes que se complementam é o JSparrow, um cliente de JMS bem fluente, que fiz usando JRuby.
Essa é a ideia de tirar o melhor de cada linguagem!
Mesmo porque, dificilmente, você constroi um sistema de verdade — que não seja um super CRUD — com apenas uma única linguagem de programação. Na minha equipe mesmo, há sistemas desenvolvidos em C# .NET, que são buildados, testados e deployados com Ruby/Rake/Cucumber e usam Java/Ivy como repositório de assemblies. Isso sem falar em JavaScript, que também tem de monte.
Esse é o mundo real dos sistemas de verdade.
Moral da história
Isso me faz pensar que brigas de fanboys de linguagens — em frenéticas buscas por prosélitos — são uma verdadeira piada.
CØdeZØne! 
Falae Leandro,
Bacana o Post!
Outra questão que também acho pertinente nesse tema é:
“Quem na sua empresa está fazendo a escolha tecnológica?”
Acredito que existam muitos casos onde essa escolha é feita pela gerencia ou até mesmo pela diretoria da empresa. Nesses casos, muitas vezes, são outras questões que motivam a escolha tecnológica como:
“Qual é a oferta de profissionais na tecnologia
X em relação à tecnologia Y?”
“O que é mais interessante para a minha empresa? Ser parceira Oracle ou ser parceira Microsoft? NDA?”
Nem quero entrar no mérito se esse tipo de decisão é melhor ou pior do que a decisão da equipe técnica pois sou adepto da teoria de que o que é bom para um não necessariamente seja bom para outro.
Particularmente, acho bem interessante e gosto bastante desse “mix” de tecnologias para te dar suporte ao próprio desenvolvimento como você citou.
abs,
-LeoLuz-
Opa, Léo!
Essas questões de “oferta de profissional”, “parcerias”, “preço”, etc, são algumas das quais fazem parte do que chamamos de ecosistema [no qual cada linguagem está inserida]. São questões importantes, sim, mas não do ponto de vista de se comparar se uma linguagem é melhor do que outra.
Por exemplo: não dá pra dizer que ASP é melhor do que Haskell, porque você sai na rua e tropeça em programadores ASP, enquanto que programadores Haskell são uma raridade.
Mas, sim, questões de ecosistema, que agradam mais a um programador do que a outro, por puro gosto, podem ser bem cruciais para caras que estão mais ligados ao negócio da empresa (digamos assim), que estão pensando em coisas como:
– quanto tempo vamos levar para por essas aplicação no ar?
– quanto tempo vamos conseguir sobreviver “crescendo” com essa aplicação?
– quão dificil é manter uma aplicação “crescendo” nessa linguagem?
– quão caro são as ferramentas para se trabalhar com essa linguagem?
– etc, etc.
Por isso é importante que caras técnicos e de negócio estejam sempre bem alinhados. Para que os caras de negócio digam onde querem chegar e os técnicos mostrem o caminho.
Abraço!
Olá Leandro,
Muito bacana seu post. Escrevi algo relacionado no começo do ano. Se puder dê uma lida, acho que vai se interessar.
http://codificando.com/2010/02/nao-se-apaixone-pela-sua-tecnologia/
[]s
artigo muito bom esse eim, eu nunca fui de comparar linguagens sempre achei que você tem que escolher a linguagem de acordo com o seu projeto