Scala: O vencedor da batalha Java vs .Net 

Oct/13
26

Depois de um ano trabalhando com C# , gostaria de partilhar algumas ideias comparativas entre a plataformas .NET e a Java e as linguagens C# e Java.

J√° devem estar pensando que l√° vem mais um cara fazer compara√ß√Ķes e dizer que √© tudo a mesma coisa. N√£o.¬† N√£o √© tudo a mesma coisa e resposta √© bem definitiva. A plataforma Java est√° a anos luz¬† √† frente da plataforma .net. A raz√£o √© simples. A plataforma .net n√£o se preocupa muito em acomodar as preocupa√ß√Ķes e os casos de uso de bilh√Ķes de pessoas. O seu foco √© mais no aqui e agora, com possibilidade de interagir com o OS.¬† √Č poss√≠vel ter grandes sistemas criados em .NET ? com certeza, mas a um custo e esfor√ßo muito maior. A plataforma .net √© voltada a resultados e n√£o √© muito acad√™mica. A curva de aprendizado √© suave e rapidamente voc√™ consegue ter algo funcionando. Especialmente se o seu stack tecnol√≥gico √© completamente baseado em tecnologias Microsoft. Ai sim a plataforma brilha. Contudo certas partes s√£o um pouco restringentes demais. Se olharmos o cubo de arquitetura e compararmos as duas plataformas em rela√ß√£o a teremos uma melhor ideia do que estou falando.

plataforma

A plataforma f√≠sica √© a pr√≥pria m√°quina seguida de drivers na plataforma baixa , o OS na plataforma alta, as tecnologias de programa√ß√£o na plataforma virtual e a plataforma de aplica√ß√£o que a (infra) estrutura do seu sistema.¬† A plataforma .NET permite a voc√™ mais flexibilidade na hora de comunicar com a plataforma alta e interagir com o OS, mas ao mesmo tempo tamb√©m √© mais restrita ao n√≠vel da aplica√ß√£o. Ele sabe fazer apenas uma coisa e pronto. Ou a sua aplica√ß√£o encaixa com isso, ou nada feito. N√£o ha nada que voc√™ possa manipular ou alterar para fazer melhor. Quando ha, s√£o coisas a que poucos se atrevem pela complexidade e pelo custo/beneficio. Nesse caso √© mais comum voc√™ partir para componentes prontos e alguns at√© pagos, porque n√£o √© divertido mexer com o interior da m√°quina.¬† Porque a plataforma prov√™ quase tudo, n√£o ha necessidade de inventar muito e voc√™ consegue ter um resultado palp√°vel rapidamente.¬† A Microsoft sempre teve tradi√ß√£o no desenvolvimento RAD. O problema √© que quando voc√™ quer alterar ou prover alguma coisa um pouco diferente voc√™ est√° nas m√£os da plataforma que tende a ser mais fechada que a plataforma Java. Fechada n√£o √© bem o termo. Coloquemos assim: a caixa √© mais preta. ¬†Do outro lado a plataforma java lhe d√° zero controle sobre o OS e a plataforma alta, embora voc√™ possa conseguir a interface necess√°ria via JNI (Java Native Interface) a programa√ß√£o dessa parte n√£o acontece na plataforma em si. Esta aus√™ncia de controle √© proposital e quando necess√°ria √© provida pela JVM que ao longo do tempo tem vindo a prover mais formas de interagir com a plataforma alta. Mas este n√£o √© o objetivo. O objetivo √© prover uma plataforma virtual – ou seja, uma plataforma boa para muitos tipos de aplica√ß√Ķes e muitos e diversificados ambientes. Desde o Java Card rodando no seu cart√£o de cr√©dito, √† sua set-top-box da sua companhia de TV por cabo , ao chip de celular ( ou do decodificador de dito set-top-box) , at√© √† aplica√ß√£o de declara√ß√£o de impostos no seu desktop, ao servidor web e empresarial que alimenta o tweeter. E mais recentemente a placas como o Raspbery Pi¬† que j√° roda Java 8 Embeded. O objetivo √© prover APIs que facilitam todos estes tipos de aplica√ß√£o. A plataforma Java , por design, n√£o tenta fazer o trabalho por voc√™. Ela apenas promove as API para que voc√™ possa desenvolver a sua pr√≥pria plataforma de aplica√ß√£o.¬† √Č por isso que as pessoas t√™m a sensa√ß√£o que em java se programa mais e as coisas demoram mais. √Č porque as empresas t√™m a mania de criar uma plataforma de aplica√ß√£o para cada aplica√ß√£o que fazem. A plataforma de aplica√ß√£o √© a parte mais cara do custo do software e se voc√™ faz uma cada aplica√ß√£o o neg√≥cio n√£o escala. √Č por isso que em alguns lugares voc√™ houve falar de “frameworks” ou de “infraestrutura” que em tese √© reaproveit√°vel de umas aplica√ß√Ķes para outras. O problema desta abordagem √© que quem cria esses frameworks n√£o sabe muito bem o que est√° fazendo e eles acabam ficando obsoletos rapidamente.¬† Para que uma plataforma de aplica√ß√£o sobreviva ao tempo ela tem que abstrair a plataforma virtual por baixo. E isso, acredite, n√£o √© f√°cil. Nada mesmo.¬† Alguns exemplos de sucesso nessa area s√£o o Ruby On Rails e o Grails que partem de uma plataforma virtual como o ruby ( no primeiro caso) e java+ groovy no segundo para prover um nivel de isolamento que torna a plataforma de aplica√ß√£o mais independente da plataforma virtual subjacente.

Portanto, em java voc√™ precisa criar sua plataforma de aplica√ß√£o do ch√£o porque a plataforma virtual java lhe d√° muitas op√ß√Ķes. Talvez op√ß√Ķes demais. Em .Net as op√ß√Ķes s√£o menos e mais dirigidas a resultados. Praticamente tudo foi decidido por voc√™, voc√™ apenas tem que usar. A quantidade de frameworks dispon√≠veis para java n√£o √© coincid√™ncia. √Č o pr√≥prio prop√≥sito da plataforma, e como tal a plataforma √© um sucesso. √Č imposs√≠vel remover java do mundo.¬† Tanto √© assim que √© poss√≠vel executar Java dentro do .Net e muitos frameworks conhecidos do mundo java tem sido portados para o mundo .net. Porqu√™ ? Porque, como disse, o custo beneficio √© muito pequeno quando isto √© feito em pequena escala. Mas frameworks como Log4 , Hibernate e Spring s√£o praticamente onipresentes.

Em poucas palavras a plataforma Java é melhor que plataforma .Net. Sem meios mas.

Mas enquanto a plataforma √© onipresente e excelente em v√°rios n√≠veis, a linguagem java est√° mostrando seus anos. A linguagem em si sempre foi muito alinhada com a plataforma e a linkagem din√Ęmica sempre foi uma das suas maiores features, mas √© exatamente ela que torna as coisas t√£o complicadas.¬† O Java 7 deu um passo monstruoso na dire√ß√£o certa ao introduzir um novo bytecode. Ao contr√°rio da microsoft que n√£o v√™ problema em quebrar compatibilidade com c√≥digo anterior , a Sun e agora a Oracle n√£o t√™m esse luxo. S√£o milhares de milh√Ķes de linhas de c√≥digo que j√° est√£o escritas e compiladas em jars que as pessoas usam at√© hoje. Os mesmos jars.¬†O Java 8 trar√° uma nova forma de pensar ao mundo java com a introdu√ß√£o de lambdas, mas o m√©rito n√£o est√° na funcionalidade em si, mas na forma como ela foi implementada para vencer todos os entraves e limita√ß√£o que a compatibilidade reversa implica.¬† Com o java 8 vem tamb√©m um novo conceito. O conceito que existem muitos e diferentes compiladores java e o javac da Oracle √© apenas um entre eles. Com isso em mente a Oracle est√° lan√ßando o conceito de um compilador expans√≠vel. Isto significa que poder√° usar o compilador do java para criar outros compiladores ou compilar seu c√≥digo em diferentes formas, inclusive criando suas pr√≥prias extens√Ķes √† linguagem como novos operadores, por exemplo. Este conceito √© revolucion√°rio. Significa basicamente “se acham que √© t√£o simples estender o java, ent√£o fa√ßam voc√™s mesmos”.¬†¬† O ponto aqui √© todos sabem que a linguagem java precisa de uma revitaliza√ß√£o ou ir√° ser relegada. Mas ela √© t√£o intr√≠nseca √† API Java que seria irrealista criar uma nova linguagem para a plataforma que n√£o pudesse usar as APIs que j√° existem. V√°rias linguagens t√™m aparecido e continuam aparecendo para preencher este vazio deixado pela linguagem java.¬† Linguagens como Scala e Groovy j√° provaram que √© poss√≠vel estender a linguagem java a outro n√≠vel.

A linguagem C# sofre de alguns problemas conceituais que atrapalham¬† um pouco a vida ( como o conceito de strut), especialmente quando voc√™ trabalha com gen√©ricos ( que embora n√£o sofram de erasure como em java,¬† sofre como problemas de vari√Ęncia e contra-variancia. Por exemplo apenas interfaces podem ser contra-variantes, mas classes n√£o. E struts n√£o s√£o classes, o que significa que os gen√©ricos s√£o mais ou menos gen√©ricos porque constrangimentos gen√©ricos nem sempre funcionam bem para classes e struts ao mesmo tempo e n√£o ha como destingir entre os dois de uma forma transparente). Tenho trabalhando com C# no √ļltimo ano e realmente √© uma linguagem muito vers√°til e √ļtil (se n√£o tiver problemas em ignorar algumas falhas conceituais) . As vantagens s√£o : conceito de operador, extens√Ķes n√£o virtuais e LINQ. O conceito de operador n√£o √© util em larga escala, mas √© muito √ļtil ao criar objetos de valor como Money , Fraction e outros que traduzem valores e v√™m equipados com opera√ß√Ķes. O sistema de operadores n√£o √© t√£o sofisticado como o de scala, mas atende perfeitamente. O conceito de extens√Ķes √© bastante √ļtil, sobre tudo encapsulando c√≥digo repetitivo que de outra forma teria que ir num Utils da vida. Como s√£o m√©todos √© simples encadear chamadas a v√°rias extens√Ķes e o compilador faz um bom trabalho escolhendo a extens√£o certa tendo em conta os tipos das vari√°veis e os tipos gen√©ricos usados nas extens√Ķes. Linq √© um conceito interessante. Ele se parte em duas vertentes. A primeira √© a base para o resto que √© o conceito que o compilador pode ler um lambda e processar sua informa√ß√£o num objeto chamado Expression que por sua vez pode ser usado para executar o lambda, mas mais importante que isso para ter acesso ao que o lambda est√° fazendo. √Č como ter objetos Method no java, mas em que o objeto lhe diz que opera√ß√Ķes v√£o acontecer l√° dentro e entre quais argumentos. Este truque do compilador permite que voc√™ possa escrever lambdas que s√£o mais fluentes de entender e depois obter toda a √°rvore de chamadas. √Č como um reflection avan√ßado feito em compile time. A outra parte √© pegar nesse objeto Expression ( que na realidade √© forma uma arvore) e us√°-lo para automatizar consultas ao banco de dados ou qualquer outra tecnologia como XML , Diret√≥rios de Arquivos, grafos, ou de diret√≥rios de nomes. Enfim, qualquer estrutura de dados que possa ser pesquisada. Esta √© uma capacidade que o compilador d√° que pode ser usada para muitas coisas diferentes que n√£o s√≥ pesquisa. Pode ser usada para configura√ß√Ķes complexas. Pode ser usada, na realidade para construir Builders avan√ßados que s√£o muito fluentes.

Claro que nem tudo s√£o rosas e por outro lado, o uso de lamdas √© um pouco mais restrito que nos lambdas do java e outras linguagens, porque SAM types (Single Abstract Method Types) n√£o s√£o poss√≠veis de abstrair com lambdas. Apenas delegates. Que √© um conceito diferente que n√£o existem em¬† java, mas na realidade n√£o √© assim t√£o necess√°rio (√© basicamente o padr√£o listenner na forma de um construto da linguagem). ¬†A linguagem C# tem avan√ßos em rela√ß√£o ao Java que no dia a dia s√£o muito √ļteis e permitem que o seu c√≥digo fique curto e fluente, contudo o pre√ßo a pagar √© que nem todas as apis ou construtos s√£o igualmente sensacionais.

A aten√ß√£o que foi dada a generics √© realmente limitada e √© √≥bvio que ningu√©m pensou direito das consequ√™ncias das coisas de uma forma abrangente. Tanto √© que, as features relacionadas a generics foram sendo incrementalmente lan√ßadas e n√£o todas de uma vez. Uma ue ficou para o fim, que √© realmente triste √© a Vari√Ęncia (co e contra). E coisas simples e obivas como a co-vari√Ęncia de m√©todos s√£o simplesmente proteladas por falta de interesse de uns poucos como se pode ler em algumas respostas interessantes no stackoverflow. Chega a beirar o descaso de que tantos usu√°rios da Microsoft lamentam. A diferen√ßa √© que a Sun conseguir formar uma comunidade em torno da tecnologia. E isso lhe saia caro, mas tamb√©m por isso ela foi comprada pela Oracle. O Java n√£o √© feito por uma pessoa, √© feito por milhares, e nem todos pertencentes √† empresa. √Č pera isso que existe o JCP e as universidades s√£o chamadas a intervir e muito trabalho acad√™mico est√° por detr√°s das decis√Ķes. No .NET as decis√Ķes s√£o tomadas com base em custo/beneficio e n√£o na opini√£o ou requisi√ß√£o de quem usa a ferramenta.

A linguagem C# √© realmente mais convenientes que a linguagem java e o pessoal da Oracle , e a comunidade como um todo sabem disso. √Č por isso que linguagens emergem para a plataforma todos os dias: Cylon, Kotlin, Fantom, Groovy, Scala , Xtend, JRuby, JPyton … s√≥ para nomear algumas. Extentions s√£o muito √ļteis e existem em scala e xtend de uma forma inteligente. Mas o poder co C# vem realmente do Linq, porque ele mune a linguagem com a capacidade de entender Monads e isso √© muito poderoso (de novo, Scala tamb√©m tem isso)

Resumindo, a linguagem do futuro √© algo como mais como Scala e menos como Java ou C#. Isto porque tanto o java e o C# n√£o fizeram um t√£o bom servi√ßo quanto podiam ao incluir conceitos como generics, covariancia, extens√Ķes e monads. O java porque tem problemas de retrocompatibilidade originados na sua linkagem din√Ęmica e o C# porque teve alguns problemas no processo de tomar decis√Ķes¬† e encontrar compromissos com a comunidade , especialmente a de utilizadores e a acad√™mica. Scala √© fortemente baseado em orienta√ß√£o a objetos como Java (Em C# √© poss√≠vel criar uns bichos meio estranhos que violam alguns princ√≠pios b√°sicos de OO atrav√©s de uma coisa chamada Explicit Implementation que viola explicitamente o principio de substitui√ß√£o de Liskov). Mas o que √© bonito em scala √© que a linguagem consegue manter-se fiel aos conceitos de OO e fugir dos problemas conceituais do C# e de compatibilidade do java. Um exemplo √© a implementa√ß√£o de generics. Em scala os gen√©ricos s√£o retificados como em C# (o que significa que vc consegue qual √© o tipo real que est√£o em T) e manter os princ√≠pios de vari√Ęncia e co-vari√Ęncia como em java.

Claramente o futuro √© Scala , mas embora scala seja uma bem desenhada linguagem ela n√£o tem uma API pr√≥pria muito grande. Ou seja, √© uma linguagem, mas n√£o √© uma plataforma virtual. Scala j√° funciona na plataforma java e at√© na plataforma .Net (atrav√©s de um truque com uma m√°quina virtual java que corre em .NET). No fim de contas voc√™ pode ter o melhor de todas as op√ß√Ķes. A melhor plataforma existente – java – com a linguagem que deixa no chinelo todas as outras – Scala. A migra√ß√£o de .Net/C# para Java/Scala me parece natural neste momento da historia , embora eu entenda que nem todo o mundo pode fazer essa migra√ß√£o, j√° existem exemplos de que √© poss√≠vel. E mais do que isso, que √© a solu√ß√£o √≥bvia.

Tentei mostrar como chegar nesta conclus√£o de um ponto de vista macro ( e r√°pido, embora longo de escrever), mas internamente eu tive que chegar nesta conclus√£o iterativamente. Ap√≥s iniciar o projeto MiddleHeaven e ver como a plataforma java evolu√≠a (especialmente a plataforma JEE) comecei a ver que ao mesmo tempo que ficava mais complexo criar e manter o MiddleHeaven eu ia descobrindo as limita√ß√Ķes da linguagem java. No fim descobri que precisava n√£o apenas de uma API mas de uma linguagem que tornasse o uso da api f√°cil. Por um tempo brinquei com a ideia de criar a minha pr√≥pria linguagem. Eu queria uma linguagem OO pura como java com uma sintaxe similar, mas com as capacidades avan√ßadas que o C# e outras linguagens modernas t√™m. E cada vez que chegava em uma funcionalidade interessante para a linguagem via que Scala j√° tem essas capacidades. Al√©m disso o compilador do Scala pode ser programado o que permite ainda mais op√ß√Ķes (sim, a ideia do compilador java ser extens√≠vel n√£o √© original). Ai fica dificil de argumentar que √© necess√°ria outra linguagem… fora o tempo e os recursos que implicam criar uma linguagem…

Ai fica a ideia…

 

4 comentários para “Scala: O vencedor da batalha Java vs .Net”

  1. Excelente artigo. Mas tenho uma d√ļvida, Scala j√° uma linguagem madura o suficiente para sua ado√ß√£o? A plataforma Java conta com uma s√©rie de frameworks para auxiliar no desenvolvimento, como fica essa quest√£o com scala?

  2. Madura com certeza sim. Tem várias empresas usando. Quando à API você pode usar toda a API Java e todos os frameworks java. Portanto vc pode fazer o mesmo que poderia fazer em java. Existem alguns frameworks especificos de scala que são melhores em algumas coisas ( como atores) e tem até um servidor web voltado mais para o paradigma scala (lift) , mas nada impede de usar scala junto com as tecnologias tradicionais do java.

  3. A verdade é que Scala teve seu momento de Boom mas percebeu-se que é uma linguagem complexa demais, cheia de estruturas difíceis de usar e entender. Agora estão fazendo um trabalho para esconder essa complexidade, mas o estrago já foi feito.

  4. F√°bio, gostaria que envia-se algum link para corroborar sua opini√£o. Scala √© uma linguagem muito rica que se utiliza de artificios muito espertos da OO e de programa√ß√£o orientada a fun√ß√Ķes mais alguns truques de compilador. Contudo, scala √© ainda mais purista que java no que toca a Orienta√ß√£o a Objectos. Seus objetos tender a ser imut√°veis o que os torna mais simples, n√£o mais complexos. Talvez muita gente se sinta intimidada pelo poder dos tipos gen√©ricos em scala, mas isso √© porque scala implementou tipos gen√©ricos como deve ser e n√£o como um pensamento √† posteriori como java e c#. Isso torna scala mais poderoso, mas n√£o mais complexo.
    √Č f√°cil dizer que scala parece mais complicado. Mas o mesmo pode ser dito do java se a pessoa so programa com C ou PHP. Sim, ha uma evolu√ß√£o natural que a pessoa tem que fazer para entender, mas qualquer pessoa com experi√™ncia em programa√ß√£o pode entender e apreciar o poder do scala. Scala n√£o √© mais complexa, √© mais rica.

Comente

Enquete

Sobre quais assuntos gosta de ler neste blog ?

View Results

Loading ... Loading ...

Artigos