Não é de agora que venho acompanhando a incessante perfusão de linguagens para a plataforma Java. Talvez o java tenha começado tarde neste conceito, não por culpa dos seus designers, mas por falta de interessa da comunidade.

Os designers do java deram um passo em frente com a Scripting API, mas a mensagem acabou não passando. Linguagens de script têm um propósito simples : aumentar as capacidades de um sistema maior com pouco esforço. Este novo framework é ideal se você está pensando criar um programa altamente customizável na linha dos grandes ERPs. Mas uma linguagem de script não é construída para  ser suporte a programas com milhares de classes e linhas de código. Projetos dessa natureza demandam coisas simples como strong typing para manter o projeto no trilho.

Por outro lado, o uso de DSL (Domain Specific Languages) ganhou muito território e acaba sendo a escolha correta para implementar as linguagens próprias de produtos como referi acima. Se você tem um ERP muito provavelmente você quer trabalhar facilmente com conceitos do domínio e se preocupar menos com conceitos técnicos como a performance da query, ou até qual a query que está sendo usada ou sequer que existe uma query.

Então, quando falo em linguagem estou pensando também em ambiente de desenvolvimento end-to-end, compilador, arquivo compilado, e não em algo embutido.

A plataforma .NET desde o início mantém o conceito de uma plataforma, várias linguagens. A definição da common language (CL) é equivalente ao bytecode da JVM e é até possível converter bytecode em CL (o projeto ikvm se apresenta muito interessante para executar java na plataforma .NET que permite, por exemplo, correr Swing em .NET) e esta tecnologia pode ser usada para simplesmente criar linguagens cross-vm cujo fonte pode ser executado em ambas as plataformas.

O Java 8 comporta uma série de alterações à linguagens para simplificar conceitos como Function Object usando Lambda Expressions. Isto acontece num momento onde as outras linguagens para a JVM já provêm essa funcionalidade. O que irá acontecer é que o código de port da linguagem X para bytecode poderá agora utilizar novos truques e deixar o bytecode compilado mais performático.

Existem muitas linguagens para a JVM. Alguma são ports de outras VMs, algumas são feitas realmente para a JVM desde um começo. Fazer uma VM robusta e altamente performática não é simples. A JVM é atualmente a VM mais evoluída do mercado e é isso que atrai tantas plataformas e linguagens a serem migradas para a JVM. Esta migração não é trivial já que a maioria destas VM são dependentes de recursos específicos do OS . Nesta primeira categoria se incluem as linguagens como Ruby (JRuby) , Python (JPython), PHP (Quercus).Do outro lado temos linguagens que foram criadas pensando da JVM como sua base tecnologica: Groovy, Scala, Kotlin, Fantom, Loop e Clojure. Nenhum das  listas é exaustiva, aliás se conhecer alguma outra por favor deixe um comentário.

Aos poucos começamos a ver que a oferta é bastante e começamos a procurar qual delas se dá melhor para o objetivo que queremos.  Programação funcional hoje em dia é um must. Muitas delas oferecem sobrecarga de operadores. Mas o que todas têm em comum é que correm na JVM.

Fantom é ainda mais interessante pois se estabelece como uma plataforma que pode ser utilizada para compilar aplicações para a Plataforma Java, a Plataforma .NET e inclusive para javascript. O conceito interessante aqui é que o conceito de “native” diz respeito à tecnologia da VM subjacente e não à máquina física. Este mecanismo permite que tudo seja escrito em Fantom, mas quando necessário ( sobretudo em API da plataforma) é possível escrever um pedaço “nativo” para usar as ferramentas que a Plataforma oferece e/ou para diferenciar implementações do mesmo serviço entre plataformas.  Com a possibilidade de compilar para javascript, esta plataforma e outras futuras como ela, poderão suportar o HTML 5 “out-of-the-box” sem você ter que saber  sequer o que é HTML 5.

Scala utiliza a ikvm para compilar código java para .net , mas aqui temos o problema do uso de bibliotecas da API java VS uso da bibliotecas da API do .NET. Por exemplo, usar Console em vez de System.out. Aqui o scala ainda tem que prover um camada de abstração a fim do programador scala conseguir ter realmente código portável.

Kotlin é uma linguagem interessante criada para competir com Scala mas ainda é atrelada ao vendedor que a criou (Jetbrains) o que ainda implica em um risco de vendor lock-in  mas faz o mesmo que o Scala e de forma mais simples

De todas Scala começa a se colocar como a verdadeira alternativa a Java sendo capaz de não ser apenas uma linguagens e um runtime, mas também uma forma diferente de pensar. Conceitos como Ator e outros aparecem neste tecnologia como formas de alavancar a tecnologia na  JVM mas sem usar Java. Mas nem tudo são rosas e ainda ha muito espaço para a concorrência e isso é ótimo. Ktolin e Groovy correm atrás de manter uma semelhança funcional com o que o scala consegue, mesmo que os modelos sejam diferentes (por exemplo Groovy usa Metaclass como Ruby, enquanto que em scala isso não existe. Contudo existem outros mecanismos que podem prover a mesma funcionalidade)

Está difícil de escolher a próxima linguagem e o Java 8 vai deixar isso ainda mais difícil. As funcionalidades destas novas linguagens serão cada vez mais incluídas no java padrão (como o plano de colocar Metaclass para o Java 9) deixando estas outras linguagens como muito mais terreno para cobrir e manter seu lugar ao sol. Um diferencial importante é a sobrecarga de operadores que não tem plano para existir no java padrão, mas pode ser um nicho.

Contudo, a linguagem não é tudo. Mesmo que existisse um C# para a JVM o principal problema em termos de desenvolvimento é a dependência das classes da plataforma.  Scala, por exemplo, permite funcionar tanto na JVM como em .NET, mas utilizando bibliotecas diferentes.

Enquanto os construtores das linguagens e das plataformas associadas pensam nisto, nós temos que pensar que cada vez mais o código que construímos estará cada vez menos dependente da plataforma de execução. Em breve viveremos uma revolução semelhante à foi vivida quando o java apareceu. Tínhamos a independência do OS através de uma VM. Agora teremos independência da VM através de um linguagem que compila para diferentes VM alvo e uma API que esconde os detalhes sórdidos da compatibilidade.

Esta tecnologia influenciará diretamente o custo de projetos no futuro. A escolha não será mais entre OS (roda fora do windows ou não) , mas se a tecnologia usada compila para a plataforma escolhida.  Porque criar um componente em C# que só será usado em .NET se podemos escrever em java e compilar para CL ? ou usar Fantom e esconder a diferença ?

Talvez agora a escolha se resuma não apenas a como a linguagem é simples , mas como ela é suportada em diferentes VM e como as coisas se interligam

Enquanto isso, é bom irmos nos antenando com a evolução destas tecnologias e cenários de uso e se possível, ir escrevendo programas com alguma delas. Um novo paradigma nos aguarda.