Em duas palestras no QCon Beijing, Gavin King apresentou a linguagem de programação Ceylon, em que tem trabalhado durante os últimos anos na Red Hat. A notícia se espalhou rapidamente pelo Twitter e sites como Lambda the Ultimate, Slashdot, Reddit e o Hacker News, sendo a nova linguagem muitas vezes citada como "Java-killer". Como esclarecimento, Gavin publicou um post sobre o Ceylon em seu blog, afirmando que esta nunca foi a intenção do projeto:
"Primeiramente, nunca anunciei um "assassino" do Java ou a próxima geração da linguagem; não são minhas palavras. Ceylon não é Java, é uma nova linguagem que foi profundamente influenciada por Java e projetada por fãs assumidos de Java. Java não morrerá tão cedo e nada está matando esta linguagem"
Sendo uma linguagem baseada na JVM, o Ceylon compilará para bytecode e rodará sobre a JVM. O Ceylon tem uma abordagem de tipos genéricos mais restrita que Java, sem coringas, e suporta co/contra variância em parâmetros e no retorno de métodos, apesar de não existir um operador explícito para a coerção de tipos.
As palavras-chave "in" e "out" em parâmetros indicam seu suporte à co/contra variância. Não há nada que impeça que código Ceylon seja compilado para outras maquinas virtuais, mas a JVM é o foco inicial. O Ceylon também traz parâmetros nomeados e parâmetros com valores padrão, os quais são um motivo comum para o uso de sobrecarga de métodos em Java. Métodos também podem receber métodos como parâmetro, criando funções de alta ordem. Em Ceylon, tudo é tipado como objeto, ou seja, literais numéricos primitivos não se distinguem de objetos, apesar de o tipo void ser representado por uma palavra-chave.
Com relação a Java, muitas palavras-chave mudam, por exemplo em vez de "implements" para interfaces, é usado "satisfies". Outras foram substituídas ou removidas: "public" virou "shared", "protected" e "private" não são utilizados; "abstract" mudou para "formal" e "actual" é usado para fornecer implementações de interfaces específicas. Também se pode combinar interfaces separando-as por "&" em vez de ",".
Outra novidade são os operadores, por exemplo "<=>", que é uma abreviação para o método Comparable.compare(); e "==", que se tornou sinônimo de .equals(). A sobrecarga de operadores é permitida de maneira limitada, por exemplo ">" é traduzido para Comparable.largerThan(), que pode ser sobrescrito por um tipo específico. Mas ao contrário do que acontece em Scala, que permite que métodos tenham nomes não ASCII e se assemelhem a operadores, o conjunto de operadores predefinido não pode ser estendido. É possível apenas sobrescrever o comportamento dos operadores existentes.
Não há null em Ceylon. Ao invés disso, um tipo parametrizado "Optional<T>" declara uma instância de um objeto opcional, que pode ser nulo. E o sufixo ? em um tipo é uma abreviação de Optional<T>, ou seja, ao invés de Optional<String> pode ser utilizado apenas String?.
O Ceylon oferece ainda herança por composição (mixins), como em Scala, permitindo que métodos sejam implementados em uma interface, apesar da inicialização não ser permitida. Essa característica é similar às propostas pelo projeto Coin.
Como muitas pessoas têm feito, perguntamos, por que simplesmente não usar Scala? Ao que respondeu Gavin King:
"Scala é uma linguagem interessante e uma das muitas que influenciaram o Ceylon. Examinamos Scala de perto, mas concluímos, em conjunto, que não era o que precisávamos. Pessoalmente, acho o sistema de tipos de Scala mais complexo do que quero ou que preciso."
Como o Ceylon não suporta a coerção de tipos, uma nova-palavra chave "case (is...)" foi adicionada ao switch, oferecendo coerção segura para um tipo específico. Se a expressão case for verdadeira, então o corpo do bloco vê o tipo especializado do objeto original. Se não for um objeto daquele tipo, o bloco não é executado.
A palestra de apresentação do Ceylon no QCon Beijing também abordou a modularização, uma funcionalidade ausente também em Scala, mas não entrou em detalhes sobre seu funcionamento. O Maven e o OSGi foram taxados como "complexos demais", juntamente com a sincronização em Java. Algumas afirmações feitas na apresentação foram muito criticadas, como "Java se juntou ao modismo do XML" e "Não há uma boa maneira de se definir uma interface gráfica em Java". Alguns exemplos do Ceylon mostram como interfaces gráficas poderiam ser criadas declarativamente, de forma similar a JavaFX, apesar das interfaces gráficas serem frequentemente desenvolvidas em outras tecnologias. Outros criticaram o fato de que a sintaxe para definição de funções embutidas (inline), citada como "roubada do Smalltalk", não se assemelha à sintaxe de blocos de Smalltalk. Apesar de serem críticas válidas, elas se referem mais à palestra do que à linguagem em si.
O futuro está aberto para o projeto Ceylon, e a apresentação aconteceu antes que o material do projeto estivesse disponível. Gavin King concluiu a apresentação dessa maneira:
"Minha equipe passou os últimos dois anos projetando o que achamos que uma linguagem deveria ser, escrevendo uma especificação da linguagem, uma gramática ANTLR e um protótipo de compilador. No entanto, ainda ainda não se pode escrever código. Pretendemos lançar uma versão inicial do compilador este ano."
Entrevista com Gavin King
O InfoQ procurou Gavin para mais detalhes sobre o Ceylon:
InfoQ: Existem muitos comentários comparando Ceylon a Scala. Onde você vê as principais diferenças entre as linguagens, além de Scala permitir funções com nomes não-ASCII?
Gavin King: Bem, Scala é uma das linguagens que influenciaram o design de Ceylon, mas existem grandes diferenças de enfoque nos dois projetos.
O código em Ceylon deve ser legível para pessoas que não são programadores Ceylon. Evitamos incluir construções sintáticas que prejudicassem a legibilidade. Por exemplo, não usamos pontuação complexa nos casos em que palavras seriam melhores. E não vamos suportar a sobrecarga real de operadores. Queremos que seja criado código simples e legível, não "ASCII Art" executável.
Uma das forças importantes que tornaram o Java tão bem-sucedido foram o que a linguagem deixou de fora. Mas é necessário ser inteligente nesse caso: a decisão do Java de não incluir funções de alta ordem foi prejudicial. Já a equipe do Scala seguiu um caminho muito diferente, criando um sistema de tipos muito rico. Prefiro resolver problemas com poucas construções mais gerais, do que com um número maior de construções menos poderosas.
Assim, criei algumas coisas para tornar possível um meta-modelo com tipos estáticos, uma versão typesafe de Reflection. Não conheço outra linguagem que ofereça essa funcionalidade, apesar de ser possível que tenha sido feito antes em projetos de pesquisa. Não há sobrecarga nem "tipos existenciais", nem há "null" escondido na especificação. Tudo isso seria útil para a interoperabilidade com Java, mas aumentaria complexidade. Além disso, argumentos com tipos genéricos serão abstraídos, o que abre muitas possibilidades, mas também prejudica um pouco a interoperabilidade. Como estamos planejando um novo SDK, o Ceylon faz poucas concessões no sistema de tipos para obter interoperabilidade com Java.
Finalmente, um objetivo fundamental do projeto é oferecer uma sintaxe elegante para anotações e para definição de interfaces com o usuário e dados estruturados. Seria como o suporte à "programação declarativa". Agora que a Oracle se afastou do JavaFX, o Ceylon será "A linguagem" para desenvolvedores de interfaces com o usuário.
InfoQ: Você menciona que Maven e OSGI são prejudiciais. O que o Ceylon oferece para modularização?
Gavin King: Vamos nos basear em uma especificação de repositórios bem definida e integrada, desde o compilador e o IDE, até a execução. Quando se tem um ambiente mais controlado, é possível utilizar ferramentas muito mais simples. Estamos baseando o sistema de módulos no JBoss Modules, que formará o núcleo do JBoss AS 7. O JBoss Modules é um sistema de módulos muito simples e enxuto, bem mais simples que as outras soluções disponíveis.
InfoQ: Você afirma que todo objeto é um semáforo e daí a origem de "synchronized". Quais são os planos do Ceylon para suportar multi-threading e primitivas de sincronização?
Gavin King: Acredito fortemente que concorrência, ao menos até que alguma revolução aconteça nessa área, é algo que deve ser resolvido por bibliotecas. A linguagem não precisa incluir primitivas de concorrência. Existem vários padrões competindo para o tratamento de concorrência, de atores a STM, e o Ceylon deve tornar possível a escrita de bibliotecas que implementem esses padrões.
InfoQ: Você diz que Java se juntou ao modismo do XML. Mas isso não se trata de um problema da linguagem, mas sim de frameworks como o Spring, que usam frequentemente XML. É isso que quis dizer?
Gavin King: Quis dizer que não há uma maneira elegante de se definir uma interface com o usuário ou qualquer outra estrutura hierárquica estática na linguagem em si. Sendo assim, frameworks têm duas opções: definir estruturas hierárquicas usando código procedural (Swing, Wicket) ou recorrer ao XML (JSF e muitos outros).
InfoQ: Por que "void" é uma palavra reservada e não um tipo?
Gavin King: Na verdade, existe um tipo chamado "Void", que é o tipo de retorno de um método "void"; mas "void" minúsculo é uma palavra reservada. O motivo disso é indicar ao compilador que não é necessário um "return" na definição do método. Note que o Ceylon representa alguns conceitos que fazem parte da especificação de muitas linguagens, como tipos numéricos, valores null e tipos de função. É por isso que o sistema de tipos precisa ser bem mais poderoso que o de Java.
InfoQ: Para subtipos enumerados, o conjunto de subtipos é fechado? Em outras palavras, dado "class Nó of Ramo | Folha", é possível criar uma terceira subclasse de Nó?
Gavin King: Não. O propósito da cláusula "of" é dizer ao compilador que esses são os únicos subtipos, permitindo assim que o compilador valide instruções "case" que enumeram os subtipos. É uma maneira conveniente de se implementar o padrão visitor sem perder a segurança de tipos.
InfoQ: Para contra e co-variância de tipos, faz sentido usar as palavras reservadas "in" e "out" (que em outras linguagens indicam parâmetros com valores de retorno)? Isso não confundiria os programadores que estão acostumados com parâmetros "in" e "out" usados com o significado mais comum?
Gavin King: Descobrimos recentemente que o time do C# introduziu essa mesma sintaxe de forma idependente, o que me deixou confiante nela. Certamente é muito melhor que "+" e "-". Outra opção seria "produces" e "consumes", mas isso seria prolixo quando houver muitos parâmetros. Melhor manter resumido.
InfoQ: O Ceylon introduz "satisfies", mas ainda usa subclasses nomeadas como interfaces; qual é o benefício de incluir esta nova palavra-chave?
Gavin King: Java é irregular nesse ponto. Numa definição de classe, a lista de uma ou mais interfaces é precedida por "implements". Em interfaces, a lista de interfaces é precedida por "extends", o que também aparece na definição de classes para algo completamente diferente. O Ceylon é regular. Listas de tipos sempre vêm depois de "satisfies"; "extends" é sempre seguida por uma expressão que cria a superclasse. Acreditamos que a regularidade da sintaxe é muito importante.
InfoQ: Finalmente, quais são os planos para publicação do projeto? Ele será disponibilizado no GitHub?
Gavin King: Sim, assim que a versão M1 do compilador estiver pronta, estará tudo no GitHub. Mas não quero publicar a gramática e o verificador de tipos sem ter pronto o backend que os acompanhe. Para ser honesto, não estava esperando que o Ceylon fosse aparecer no Slashdot tão cedo. ;-)
As apresentações da equipe do Ceylon estão disponíveis online: introducing project Ceylon e the Ceylon type system.
E você, o que achou do Ceylon?