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

O site é recém-nascido, mas já tem uns recursos bem legais, como sistema de pesquisa por palavras-chave, núvem de tags e entre outros. Vale a pena conferir e acompanhar sua evolução – e oportunidades de bons trabalhos.

Mais uma iniciativa bem interessante da Caelum.

Porém, isso só é verdade para  Jython 2.5, que ainda não está disponível para produção. Na verdade, o time de desenvolvimento ainda está para lançar uma versão alpha (2.5a1).

Quen, quen, quen, quennnnnn…

Gostei bastante do evento, apesar dos assuntos terem sido tratados de maneira muito superficial, deu pra ter uma boa idéia sobre os produtos do Google for developers, que, sinceramente, eu não tinha.

Bom, vamos lá… Das apresentações que eu vi…

AppEngine – Permite que você coloque seu aplicativos Web para rodarem na infra-estrutura do Google. Ele é muito simples, você faz e testa seu aplicativo em sua máquina e, quando estuver pronto, apenas faz upload para o AppEngine e ele está no ar.

Uma das coisas que achei interessantes do AppEngine é que você usa o data store do Google, invés de um banco de dados relacional; e também pode usar o sistema de login do Google para a sua aplicação.

Ah! Um detalhe: Por enquanto, o AppEngine está disponível apenas para aplicações Python. Mas, segundo os apresentadores, outras linguagens estão vindo por ai – Java, Ruby e PHP foram as citadas.

Gears – É uma extesão de browser Web que permite você executar aplicações Web off-line. Ele armazena localmente um banco de dados relacional para seu aplicativo, que pode ser pesquisado e atualizado por JavaScript. E tudo isso de forma assíncrona!

Achei fantástico para aplicativos de uso em campo – como pesquisas e vendas, por exemplo.

OpenSocial – Define uma API comum para aplicativos sociais, permitindo total interoperabilidade entre estes. Com o crescimento dos aplicativos de redes sociais, não precisa nem dizer a importancia de algo assim, né?

Queria também ter visto as apresentações da API de Mapas e do Android, mas… Não se pode ter tudo sempre… =’(

O Akita também registrou a sua impressão sobre o evento – a gente se trombou por lá ontem e trocou umas idéias. Um ponto que ele citou e que concordo em genero, número e grau foi falta a Wi-Fi. Meu, precariedade total… Pelo amor de Deus! Levei meu note e quanto tentei conectar a uma rede, nada! Mas quanto a pessoas no note, eu vi bastante gente sim – principalmente com Mac.

(Ah! Tenho um protesto a fazer: Minha camiseta veio GG, eu pedi P!!!)

No geral, gostei muito do evento. Valeu muito a pena…

Mas este ano… Ah, este ano… Tudo vai ser diferente… Este vai ser o Ano de Ruby pra mim!

Pretendo também, com muito esforço e otimismo, começar a aprender Python talvez a partir do meio do ano. Vamos ver como será meu progresso com Ruby.

Aproveitando, quero indicar também alguns posts sobre isso:

A próxima linguagem a aprender
Que linguagem você aprenderá em 2008

E você, vai aprender que linguagem em 2008? Responda aqui neste post…

A Máquina Virtual Java (JVM), por sua vez, já é considerada a melhor e mais moderna máquina virtual da atualidade, provendora de um robusto ambiente de execução de aplicativos em dezenas de plataformas de hardware e software diferentes.

Tudo isto é fantástico. Mas não é tudo!

A Plataforma Java não é sobre a Linguagem Java. Ela não é exclusiva à Linguagem Java. Em uma analise fria e simplista, ela é apenas uma plataforma para execução de aplicativos distribuídos em bytecodes nativos da JVM.

É claro que numa analise mais detalhada ela seria mais do que isto. Mas em poucas palavras, é isto mesmo que ela é. A própria Sun_Microsystems já tem acreditado nisto e vendido esta idéia. Os maiores exemplos são a linguagem Groovy, que está sendo padronizada pela JSR 241, a versão Java do interpretador Ruby, o JRuby.

Quer saber? Taí um dos motivos de louvor da plataforma .NET da Microsoft. A plataforma .NET pode executar mais de vinte linguagens de programação diferentes, como se fossem uma só, porque também trabalha com o conceito de bytecode, os quais são executados sobre a CLR (Common Runtime Language). Ou seja, você não precisa ter uma única linguagem de programação para resolver todos os seus problemas computacionais; você pode escolher a melhor para o momento - eu falo sobre isso no meu post anterior. Isto sim é fantástico! E o melhor de tudo, é que a Plataforma Java também está caminhando nesta direção.

Já há algum tempinho é possível você escrever programas usando Groovy, JRuby, Jython, ou mesmo JavaScript, e executar na JVM. É a magia da JSR 223, Scripting for the Java Plataform. E não pense você que isto é fazer o gosto de meia dúzia de programadores. Isto é, na verdade, um novo leque de oportunidades para a própria Platadorma Java.

Este é o futuro do Java como plataforma de desenvolvimento, distribuição e execução de aplicativos de alta disponibilidade.

# O jeito Ruby:
puts 'Tchau!'

# O jeito Python:
def tchau():
    print "Tchau!"

// O jeito Java:
public class Goodbye {
    public static void main(String[] args) {
        System.out.println("Tchau!");
    }
}

// O jeito Groovy:
println "Tchau!"