[quote]Java core has stagnated, Java EE is dead, and Spring is over, but the JVM marches on. C’mon Oracle, where are the big ideas?
Oracle’s last two crap quarterly earnings can most definitely be described as the chickens coming home to roost. The core of the problem is that Oracle lacks anyone who can have a big idea, and a sales machine won’t produce the results that investors are accustomed to unless they have something to sell.[/quote]
Quem concorda?
Putz, só percebeu isso agora? rs
Desde o início da história Oracle-Java as pessoas já previam que isso ia acontecer.
[quote=lkbm]Putz, só percebeu isso agora? rs
Desde o início da história Oracle-Java as pessoas já previam que isso ia acontecer.
[/quote]
Não, faz tempo que venho advogando que o Java estagnou como linguagem. Qualquer um que dê um pulo na concorrência e veja o C++ ou o C#, já chegou a mesma conclusão.
Mas o fato é que boa parte da inércia do Java é por conta de APIs de terceiros, que não são tão estagnadas como o núcleo principal.
Desculpa, a pergunta foi pro autor do texto.
O “problema” (ser uma máquina de vendas, e não de idéias) existe desde a início da empresa, ou seja, está no seu DNA, o que será que fez o autor acordar em 2014 e resolver escrever um blog sobre isso não tenho a mínima idéia. rs
Sobre a concorrência, o maior risco para a linguagem Java é a chegada de um novo paradigma, e não C++ ou C#, porque essas linguagens são baseadas no mesmo paradigma que demonstra estar ultrapassado.
Na verdade, não é nem a chegada porque o paradigma funcional já chegou faz tempo, rs mais a consolidação mesmo que oferece risco…
Para mim, isso é simplesmente um indicativo da maturidade da linguagem, onde forças opostas atuam de um lado para manter o legado e outra no sentido da evolução, quase se anulando e diminuindo a velocidade das inovações.
O que vai fazer o Java evoluir ou o surgimento de uma nova plataforma (e linguagem) será o crescimento das necessidades não atendidas ou mal-atendidas. O que pode já estar acontecendo em alguma universidade ou startup por aí.
No momento, eu espero mais uma Google sair investindo numa nova (por meio de incorporação) plataforma do que a Oracle revolucionando o Java.
Se o autor estiver certo quanto as novas necessidade serem paradigmas orientadas a dados (cloud, NoSQL e big data) então podemos esperar um futuro menos promissor para linguagens orientadas a objetos (Java, C#, C++) .
[quote=lkbm][quote=A H Gusukuma]
O que vai fazer o Java evoluir ou o surgimento de uma nova plataforma (e linguagem) será o crescimento das necessidades não atendidas ou mal-atendidas. O que pode já estar acontecendo em alguma universidade ou startup por aí.
[/quote]
Se o autor estiver certo quanto as novas necessidade serem paradigmas orientadas a dados (cloud, NoSQL e big data) então podemos esperar um futuro menos promissor para linguagens orientadas a objetos (Java, C#, C++) .[/quote]
.NET/C# pelo menos sempre acompanhou bem as novas tendências, foi assim com o advento do Ruby on Rails e agora com algumas influências do NodeJs na próxima versão do ASP.NET MVC (codinome vNext). Fora isso, o fato dessa próxima versão do ASP.NET MVC da Microsoft poder rodar em web server Linux, ganhando mais um espaço muito importante.
[quote=javaflex][quote=lkbm][quote=A H Gusukuma]
O que vai fazer o Java evoluir ou o surgimento de uma nova plataforma (e linguagem) será o crescimento das necessidades não atendidas ou mal-atendidas. O que pode já estar acontecendo em alguma universidade ou startup por aí.
[/quote]
Se o autor estiver certo quanto as novas necessidade serem paradigmas orientadas a dados (cloud, NoSQL e big data) então podemos esperar um futuro menos promissor para linguagens orientadas a objetos (Java, C#, C++) .[/quote]
.NET/C# pelo menos sempre acompanhou bem as novas tendências, foi assim com o advento do Ruby on Rails e agora com algumas influências do NodeJs na próxima versão do ASP.NET MVC (codinome vNext). Fora isso, o fato dessa próxima versão do ASP.NET MVC da Microsoft poder rodar em web server Linux, ganhando mais um espaço muito importante.[/quote]
Eu achei impressionante o await a async do C#, que agora está sendo copiado pelo JavaScript. O fato deles terem feito um ajuste tão limpo e bem-feito já no paradigma assíncrono mostra que eles estão extremamente antenados com o que está vindo por aí.
Não subestimem o Anders Hejlsberg, criador do C#, ele sempre foi um brilhante idealizador de plataformas, desde a época do Delphi.
[quote=javaflex]
.NET/C# pelo menos sempre acompanhou bem as novas tendências, foi assim com o advento do Ruby on Rails e agora com algumas influências do NodeJs na próxima versão do ASP.NET MVC (codinome vNext). Fora isso, o fato dessa próxima versão do ASP.NET MVC da Microsoft poder rodar em web server Linux, ganhando mais um espaço muito importante.[/quote]
RoR e NodeJs não representam mudança de paradigma e tem uso restrito a nichos específicos, isso as torna mais fáceis de serem assimiladas pelos usuários, como tb serem copiadas pela concorrência.
O que é ótimo para programadores C# que atuam no mesmo nicho que RoR e NodeJs (programação web, basicamente), mas não diz nada sobre a capacidade da linguagem C# de se adequar a um novo paradigma de computação.
Tendências são mudanças que acontecem dentro do mesmo paradigma.
[quote=ViniGodoy]
Eu achei impressionante o await a async do C#, que agora está sendo copiado pelo JavaScript. O fato deles terem feito um ajuste tão limpo e bem-feito já no paradigma assíncrono mostra que eles estão extremamente antenados com o que está vindo por aí.
Não subestimem o Anders Hejlsberg, criador do C#, ele sempre foi um brilhante idealizador de plataformas, desde a época do Delphi.[/quote]
Açúcar sintático para o programador não ter que manipular threads manualmente é sempre bem vindo.
[quote=lkbm]Açúcar sintático para o programador não ter que manipular threads manualmente é sempre bem vindo.
[/quote]
Não é exatamente um sintax suggar. Estou incluindo toda a arquitetura em volta disso, que permite:
[quote=ViniGodoy]
Não é exatamente um sintax suggar. Estou incluindo toda a arquitetura em volta disso, que permite:
3 não é um recurso da linguagem C#, e nem é bem uma novidade, a Apple já oferece isso desde o mac 10.6 e ios 4.
É um avanço, não tenha dúvida dúvida, principalmente se você é programador front end.
O backend é que caminha para algo muito diferente (cloud, NoSQL e big data são tendências de backend) e linguagens orientadas a dados (funcionais) estão muito mais preparadas para esse tipo de situação do que as orientadas a objetos.
[quote=lkbm][quote=ViniGodoy]
Não é exatamente um sintax suggar. Estou incluindo toda a arquitetura em volta disso, que permite:
3 não é um recurso da linguagem C#, e nem é bem uma novidade, a Apple já oferece isso desde o mac 10.6 e ios 4.
É um avanço, não tenha dúvida dúvida, principalmente se você é programador front end.
O backend é que caminha para algo muito diferente (cloud, NoSQL e big data são tendências de backend) e linguagens orientadas a dados (funcionais) estão muito mais preparadas para esse tipo de situação do que as orientadas a objetos.[/quote]
Acho que você não está entendendo o que estou dizendo. Não falei que nenhuma dessas coisas era novidade isoladamente (no caso da MS, algo raramente é). Estou falando da arquitetura como um todo, da plataforma. Do fato de tudo estar lá, com uma sintaxe limpa, elegante e integrada na plataforma.
Programe um pouco para Windows 8, ou usando os recursos de async e await de fato, veja como funciona o paralelismo no Azure, e depois conversamos.
[quote=ViniGodoy][quote=lkbm][quote=ViniGodoy]
Não é exatamente um sintax suggar. Estou incluindo toda a arquitetura em volta disso, que permite:
3 não é um recurso da linguagem C#, e nem é bem uma novidade, a Apple já oferece isso desde o mac 10.6 e ios 4.
É um avanço, não tenha dúvida dúvida, principalmente se você é programador front end.
O backend é que caminha para algo muito diferente (cloud, NoSQL e big data são tendências de backend) e linguagens orientadas a dados (funcionais) estão muito mais preparadas para esse tipo de situação do que as orientadas a objetos.[/quote]
Acho que você não está entendendo o que estou dizendo. Não falei que nenhuma dessas coisas era novidade isoladamente (no caso da MS, algo raramente é). Estou falando da arquitetura como um todo, da plataforma. Do fato de tudo estar lá, com uma sintaxe limpa, elegante e integrada na plataforma.
Programe um pouco para Windows 8, ou usando os recursos de async e await de fato, veja como funciona o paralelismo no Azure, e depois conversamos. [/quote]
Muito bom poder usar todos os cores da máquina porque a interface continua responsiva. Como falei, programadores macos e ios sabem o que é isso faz tempo.
Quanto a paralelismo no azure, de fato nem lembro quando foi a última vez que precisei criar uma thread no backend, rs na sua opinião, porque acha que async e await é importante no backend?
Para não ter threads bloqueantes ocupando o servidor web. Senão dependendo do uso simultâneo e limite do servidor web a aplicação pode parar de responder.
Quando vejo falar de MS lembro da MFC, Silverlight, COM/DCOM, Activex e tantas tecnologias que foram o bam bam bam e a MS matou. Difícil ver um concorrente pro Java tão cedo. O Andrew C. Oliver sempre criticou o Java e sempre odiou a Oracle, mesmo na época da Sun e se não viu o que vai vir com os servlets 4.0 e nem as novidades do Java EE 7 (e o que está pra vir no 8) então é difícil discutir.
MFC não posso falar pois não conheço. Mas Silverlight, COM/DCOM, Activex não fazem sentido para os novos tempos, para que dar continuidade? Vai querer fazer novos projetos desktop em Swing? Faz sentido usar Flash ainda? Tem coragem de usar JavaFx para web (que já foi a proposta de Silverlight para Java)? Quem aposta em tecnologias “diferentes” acaba tendo esses riscos, por isso é bom nunca inventar muito.
[quote=javaflex]
Para não ter threads bloqueantes ocupando o servidor web. Senão dependendo do uso simultâneo e limite do servidor web a aplicação pode parar de responder.[/quote]
Na maioria da vezes (98%?), o gargalo de uma aplicação web é o banco, e não no modelo de threads usado pelo servidor.
Então repito a pergunta: tirando aficcionados node.js, quem mais liga para threads não-bloqueantes no backend?