BT

Opinião: Scala é o novo EJB 2?

por Alex Blewitt , traduzido por Alexandre Simundi em 21 Dez 2011 |

Stephen Colebourne, desenvolvedor da API Joda Time e líder da JSR 310, que trata de melhorias na API de datas e horas do Java, questionou em um post a aplicabilidade da linguagem Scala. Ele compara Scala com EJB 2, especificação considerada um dos pontos mais fracos do Java EE.

[No EJB 2] uma grande quantidade de configurações, código XML e complexidade foram impostas na plataforma Java. A especificação foi amplamente adotada, mas debaixo de muitas críticas. Desenvolvedores descobriram que embora a especificação EJB 2 procurasse reduzir a complexidade na construção de aplicações corporativas, com um alto nível de abstração, na verdade adicionava mais complexidade sem oferecer os ganhos esperados.

Colebourne coloca que prefere a linguagem Fantom a Scala, e que também está aberto a outras linguagens como Kotlin, Groovy e Ceylon. Ele acredita, porém, que Scala não é uma linguagem adequada para o futuro.

Uma de suas objeções é que Scala não fornece um sistema de módulos adequado. Ele aponta que o Java inicialmente também não oferecia tal funcionalidade (e ainda não oferece, mas pelo menos hoje a necessidade é reconhecida); por isso ferramentas como Maven, Ivy e o padrão OSGi tiveram que ser criados para suprir essa lacuna. Entretanto, quando se trabalha em sistemas de grande porte, a modularização é uma ferramenta muito importante para auxiliar a manutenção.

Na verdade, existiu uma proposta de modularidade em Scala há cerca de dois anos, que foi rapidamente abandonada. Houve forte resistência em suportar versões ou módulos (dos quais o sistemas de módulos dependem para funcionar). Naquele momento, Scala ainda não era uma linguagem pronta para uso corporativo e dois anos depois, continua na mesma situação.

Stephen também considera o sistema de tipos em Scala excessivamente complexo, concordando com a opinião de Steve Yegges:

90% da especificação de Scala é sobre o sistema de tipos. É o maior sistema de tipos que já se viu, multiplicado por cinco. Há tipos de tipos, e tipos de tipos de tipos; tanta complexidade ...] Existe um conceito chamado complexidade da complexidade<T>, significando que não é apenas complexidade, nem mesmo complexidade da complexidade: é complexidade da complexidade parametrizada. Existem tipos nos tipos de tipos. É assombroso.

Stephen também ressalta que as assinaturas de tipos, inicialmente usadas para demonstrar que o método compila corretamente, perdem o sentido no Scala, mesmo antes do suporte a Unicode. Ele apresenta o seguinte exemplo, retirado de uma das bibliotecas do Scala, e desafia todos a tentar descrever o que faz o código:

def ++ [B >: A, That] (that: TraversableOnce[B])(implicit bf: CanBuildFrom[List[A], B, That]) : That

Stephen argumenta que o sistema de tipos do Scala está dando má fama à tipagem estática:

Sinto que esse enorme sistema de tipos existe para prevenir erros de compilação e para pré-verificar o código. Mas se for aplicada essa lógica na direção oposta, ninguém vai conseguir fazer nada útil com a linguagem. Para mim, o sistema de tipos do Scala extrapola em muito o razoável, dado o que oferece em troca.

Estas opiniões não são novas. Ceki Gülcü, criador dos projetos Log4j e do SLF4j, questiona se Scala merece confiança, observando que a linguagem evoluiu, mas que quebrou a compatibilidade com versões anteriores diversas vezes.

Existe um aspecto em Scala que acho profundamente irritante. A linguagem está sempre quebrando a compatibilidade binária a cada nova versão. Apesar de promessas anteriores, a compatibilidade foi quebrada na versão 2.7, quebrada novamente na versão 2.8, e de novo na versão 2.9.

Complementando o argumento de Ceki: antes de o Java aparecer, recompilar o código era a forma de se obter portabilidade entre diferentes sistemas operacionais e diferentes versões. Isso continuou até a criação do padrão "C ABI", possibilitando que binários fossem disponibilizados e usados para diferentes versões de um mesmo sistema operacional, e finalmente levando a distribuições binárias como Debian, RedHat e Ubuntu. Foi a falta destas ABIs que impediram empresas de entregar versões binárias de seus produtos nos primeiros releases do kernel do Linux e sistemas operacionais.

Ceki arhumenta ainda que as linguagens que estão "concorrendo" com o Scala irão reduzir a distância e melhorar seus pontos fracos; e Scala vai parar de ser tão atraente. Scala, segundo ele, conseguiu inicialmente capturar a imaginação de um grande grupo de desenvolvedores Java. A linguagem instiga os que querem aprender sobre os aspectos da programação funcional e criar código conciso.

Mas, ao constantemente ignorar o que torna uma linguagem estável ao longo do tempo, e seguindo o mesmo caminho de inchamento que o Java (ao mesmo tempo ignorando a compatibilidade entre releases), o Scala se manteve fora dos projetos corporativos. Existem sim histórias de sucesso de times que adotaram Scala inicialmente, mas não há casos de sucesso de equipes que mantiveram o código um ou dois anos depois.

Agora temos uma variedade de outras linguagens baseadas na JVM que oferecem meios semelhantes de exploração, de Fantom a Xtend, que estão intensificando seus trabalhos para ganhar espaço. Até mesmo o Java irá trazer módulos e lambdas na próxima versão; e mesmo que essas mudanças no Java tenham sido adiadas por mais um ano, ainda é provável que o Java consiga trazer a programação funcional para as massas antes que o Scala estabilize. Talvez seja tarde de mais para o Scala arrumar a casa antes que o Java tome conta.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Nenhum comentário by Carlos Eduardo

é, nenhum comentário

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

1 Dê sua opinião
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.