O InfoQ.com ouviu Martin Odersky sobre o Typesafe Stack 2.0 e o Scala. Nesta entrevista, Martin discute o futuro da linguagem Scala, faz comparações entre o F# e o Scala e trata de questões de quebra de compatibilidade binária na linguagem. Odersky é o criador da linguagem de programação Scala e também o Presidente, co-fundador e Arquiteto Chefe da Typesafe. É autor do livro Programando em Scala, criador do javac e do scalac, além de ter sido aluno de Niklaus Wirth, o criador do Pascal, no Politécnica de Zurich, onde Odersky concluiu seu doutorado.
InfoQ: Começado pelas perguntas mais fáceis, você pode nos contar no que está trabalhando atualmente?
Martin Odersky: Estou finalizando os últimos retoques na implementação da proposta de 'value class' (Proposta de Melhoria 15). A ideia é ter classes extremamente leves que não necessitem de alocação de objetos para suas instâncias. Um detalhe é que isto pode ser feito sem introduzir novas sintaxes ao Scala.
InfoQ: A Typesafe tem chamado atenção desde que se formou e mais ainda recentemente, ao anunciar o Akka 2.0 e Play 2.0. Qual o nível de estabilidade dessas releases e os planos para elas?
Odersky: As duas releases passaram por várias fases beta antes de serem lançadas. Nosso processo de release candidate é bastante rigoroso, de forma que acredito que uma vez lançadas, serão estáveis. Os próximos grandes milestones para os dois projetos são no meio do ano, quando devem ser integradas com o Scala 2.10. Depois disso, planejamos adicionar uma nova base de dados como backend em setembro/outubro.
InfoQ: Algumas empresas muito conhecidas como o Twitter e o jornal britânico Guardian têm feito investimentos pesados em migração para o Scala. Você pode nos contar um pouco sobre isso e também como estes usuários têm influenciado a criação de novas funcionalidades?
Odersky: O Scala tem funcionado bem para o Twitter e para o Guardian, assim como para muitas outras empresas. Como Graham Tackley, o desenvolvedor líder do Guardian, escreveu: "O Scala nos permitiu entregar resultados mais rapidamente e com menos código. Isso revigorou nossa equipe." Geralmente essas empresas estão satisfeitas com as funcionalidades do Scala. E têm nos encorajado a trabalhar em melhores ferramentas, a exemplo do suporte de IDEs, que já entregamos. Também estamos trabalhando com o Twitter e a equipe do Akka, para criar uma fundação comum de concorrência, que poderá ser usada de ambos os lados (do Twitter e do Akka).
InfoQ: Uma questão comum em relação ao Scala é a compatibilidade binária, mais especificamente dos Application Binary Interfaces (ABIs, ou Interfaces Binárias de Aplicações). O Scala quebra a compatibilidade binária para novos releases, forçando os desenvolvedores a compilar a partir dos fontes para portar aplicações entre sistemas operacionais. Isto será tratado em algum momento? Caso não seja, qual a razão?
Odersky: O Scala atualmente só quebra a compatibilidade binária com as releases principais (major). Já as releases pontuais (minor) têm sido compatíveis por um bom tempo, e nós verificamos isto com a ajuda de uma ferramenta apropriada. Sempre que acontecem discussões sobre a compatibilidade binária, existe uma tensão entre o desejo de manter a estabilidade e o de aperfeiçoar APIs com funcionalidades novas e melhores. Não queremos outra java.util.Date no Scala! Gradualmente buscaremos obter mais estabilidade, aumentando os intervalos entre releases principais, criando um conjunto maior de bibliotecas fundamentais que permanecerão estáveis de uma versão principal a outra, e com a oferta de ferramentas que ajudarão na migração fazendo a reescrita automática do bytecode.
Um dos principais desafios para compatibilidade binária vem dos traits, do Scala, uma versão mais rica das interfaces do Java. Os traits facilitam a adição de métodos a APIs pré-existentes, o que é impossível em Java sem reescrever código. Em Scala, pode-se fazer isto, mas neste caso há necessidade de recompilação.
Devido à maior facilidade para extensão da API em Scala, os desenvolvedores tendem a criar mais extensões que em Java; e é isto que vem causando problemas em relação à compatibilidade binária. Sem dúvida, seria útil uma maneira de religar traits dinamicamente, sem a necessidade de recompilação, e a proposta de 'métodos de extensão' no projeto Lambda chega perto disso, mas infelizmente não é capaz ainda de suportar todas as formas de traits.
InfoQ: Talvez por causa do Scala.Net, parece haver um desejo de comparar o Scala ao F#. De algumas maneiras isto significa comparar programação funcional com orientada a objetos. Você vê desta forma?
Odersky: O Scala e o F# têm muitos aspectos em comum. Ambas são linguagens estaticamente tipadas, linguagens híbridas de funcional/OO sobre uma plataforma estabelecida (a JVM). Ambas inovaram no design de linguagens e algumas inovações são implementações independentes de ideias similares.
Por exemplo, os active patterns (padrões ativos) do F# são parecidos com os extractors do Scala; e os workflows do F# cumprem um papel similar às delimited continuations do Scala. A maior diferença que vejo é que o Scala se posiciona principalmente como uma linguaguem orientada a objetos moderna, em que se pode também fazer programação funcional.
Em contrapartida, vejo que o F# se posiciona como linguagem funcional que também suporta o modelo de objetos do .NET. O F#, contudo, é mais conservador que o Scala em relação à inovação na orientação a objetos. Em termos de medidas como tamanho de suas gramáticas, o Scala é 'menor' que o F#.
InfoQ: Tem havido debates na comunidade do Scala sobre a necessidade de se adicionar funcionalidades e ao mesmo tempo manter o Scala enxuto. Em qual direção está indo o Scala? Você considera que o Scala precisa se tornar uma linguagem pesada, multiparadigma e multiuso para se estabelecer no mercado?
Odersky: Acredito que o consenso é que devemos manter a linguagem enxuta. O Scala é uma linguagem compacta, apesar da enorme quantidade de possibilidades de uso; isso porque temos trabalhado muito pela unificação. Os mesmos conceitos descrevem objetos, funções e componentes. No lugar de adicionar funcionalidades, o Scala tem capacidades de abstração muito poderosas que permitem aos usuários definir funcionalidades similares em bibliotecas próprias. No futuro, ambiciono fazer do Scala uma linguagem menor, não maior. Sei que é difícil, mas tentaremos.
InfoQ: À medida que o Java introduz funcionalidades como módulos e lambdas, você acha que os programadores Java que desejam adicionar o paradigma funcional continuarão simplesmente a usar Java?
Martin: Seria bom se fosse simples assim! Não me entenda mal: Closures são uma adição bem-vinda ao Java. Mas para ser funcional ainda é preciso aparar várias outras arestas. Linguagens como Java são por natureza orientadas a declarações, que mudam variáveis como efeito secundário; já linguagens funcionais são orientadas a expressões. Por exemplo, a declaração try/catch no Java não pode retornar resultados, de forma que toda vez que você capturar uma exceção em um try, será preciso mudar variáveis para gerar qualquer efeito. Assim, considero que as closures no Java darão suporte a algum idioma funcional, mas a adoção abrangente do paradigma funcional mesmo assim será sofrida.
Para conhecer mais sobre Scala e sua relação com o Java, uma boa referência é o artigo recente do InfoQ Brasil, Scala ou Java: Explorando Mitos Polêmicas e Fatos. Para ver Odersky falando, recomendamos esta palestra no OSCON 2011, que trata de aspecto levantadas nesta entrevista.