Novas Linguagens estão surgindo para atender demanda que o JAVA e outras nao suprem

Um pouco tendenciosa a reportagem (em favor do F#), visto que existem linguagens funcionais para a plataforma Java, e que a própria linguagem Java a partir da versão 8, terá conceitos funcionais.

Não mencionaram no artigo:

• Ruby
• Scala
• Groovy
• Go
• Python
• Pearl

E muitas outras…

brunoborges:

Um pouco tendenciosa a reportagem (em favor do F#), visto que existem linguagens funcionais para a plataforma Java, e que a própria linguagem Java a partir da versão 8, terá conceitos funcionais.

Não mencionaram no artigo:

• Ruby
• Scala
• Groovy
• Go
• Python
• Pearl

E muitas outras… :-)

O próprio c++ já possui com a expansão c++11. E a linguagem c com as expansões vala e objective c. Esse artigo aí está completamente atrasado.

Sei. Você leu 5% do artigo e acha que é tendenciosa em favor do F#

Poderia ter indicado que o artigo (não reportagem) fala sobre a X10, que é uma linguagem da IBM que é igualzinha à Java, exceto que está mais bem preparada que ela para suportar arquiteturas paralelas

carlosanalista:

http://www.computer.org/portal/web/computingnow/software%20engineering/content?g=53319&type=article&urlTitle=computing-trends-lead-to-new-programming-languages

Segundo o artigo publicado na revista “COMPUTER”, uma publicação do IEEE, as linguagens mais utilizadas numa pesquisa feita a partir de 45 milhões de linhas de código são respectivamente:
C, C++ e Java.

Entretanto estas linguagens, segundo o artigo, podem perder lugar de destaque para novas linguagens, pois apresentam algumas deficiências que tornam exaustivo seu uso em cenários computacionais que utilizam por exemplo processamento paralelo, CPUs multicore, alta performance e cloud computing, sistemas distribuidos e Mobile. O artigo apresenta alguns exemplos de novas linguagens como exemplo: Microsoft F# que é apresentada como funcional e prática.

Hoje é obvio a todos que o modelo de usar VM é muito melhor que escrever codigo diretamente para o CPU. Isto era obvio antes - porque a VM nada mais é que um nivel de indireção e todos os problemas podem ser resolvidos com o nivel de indireção a mais - mas as pessoas resistiam à ideia. Hoje não mais. E a JVM da Sun, hoje Oracle é a melhor que existe no mercado em termos de VM. Ora, mas ela é uma máquina. então da mesma forma que várias linguagens compilam para máquinas reais, várias podem compilar para máquinas virtuais. Aliás, o .net sempre partiu deste principio. A linguagens .net compilam todas para a mesma linguagem comum que depois é executada.
Ora, o que estamos vendo agora é o pessoa entendendo que “VM” é legal, mas ainda é apenas uma VM. E da mesma forma que o java quiz ser cross plataform, a nova vaga de linguanges quer ser “cross-Vm” e aqui está um potencial imenso ainda inesplorado. Inclusive entenderam que a VM javacript é um alvo de mais linguanges ( o dart prova isto)
E é a corrida ao ouro. Todas querem ser o próximo java. A Haxe , assim como Fantom apostam neste ideia de corss-vm, mas isso vem com consequencias. Vamos ter UI para tudo ? Imagine ter algo semelhante ao swing que corre em qualquer VM. Imagine vc escrever um código que realmente nunca mais vc terá que reescrever porque vc vai trocar de VM , não de linguagem. Isto seria otimo. Uma linguagem e API para governar todas as outras. A uma-linguagem é próximo santo graal e quem conseguir encontrá-la vai ficar milionário. O problema é que o trabalho é imenso. Imagine compatibilizar .net com java com javascript, com php , com ruby, etc… loucura. Mas se vc tiver algo que corra vm de javacript (e ha várias , cada browser tem a sua) e algo que corra em uma plataforma de servidor como java ou .net ( ou ambas), pronto. Tá fechado. O problema agora é comercial e econômico. Porque alguém iria migrar para essas novas meta-plataformas ? E será que realmente os resultados são bons ? Dá para confiar ? Esta é a pergunta chave.

Como ainda é tudo muto corre-corre, ainda não dá para apostar tudo em uma delas. Então o pesoal precavido ainda fica no java ou no .net e no máximo faz um programa hibrido usando uma em um nodo e outra em outro (tipo android no cliente +.net no servidor). É que a linguagem é apenas o primeiro passo, o dificil é compatibilizar as API. sobretudo as básicas (I/O, Threads, UI ) (como se abre um arquivo em javascript ? )

Eu acho que é o futuro e estou de olho no melhor candidato e ha muitos. Realmente muitos. Mais dos que estão no artigo. Tem o fantom que já citei, mas tem o scala, o kotlin o gosu e muitos outros. Algumas querem ser meta-plataforma outros não . Por exemplo o scala ainda usa muita API do java. Ele pode ser compilado para .net ( porque o java pode ser compilado para .net via ikvm) mas é estranho tanta mistura. O idela seria ter uma aPI scala pura e o compilador se virar para usar API da plataforma base. Outros já partem deste principio. O fantom por exemplo tem api propria para muitas coisas e deixa usar o conceito de “native” que em java é usado para programa em C++ , em fantom é usado para programar código “nativo java” ou “nativo C#”. É um conceito interessante.

tudo se resume à robustez. quando estas novas plataformas mostrarem que valem o investimento, as pessoas vão começar a migrar. E no entretanto todas as variantes mostram as vantagens e desvantegens das outras. Hoje em dia se vc não é OO, esquece. E tem que ser fortemente tipado e tem que ser dinamicamente tipado e tem que ter closures e tem que ter paralelismo e um monte de outras coisas. E está se procurando o melhor encaixe para tudo isso. O problema que eu vejo com essas linguagens é que são pouco simples. têm muitas palras chave em vez de conceitos profudamente compreendidos . O java é muito bom em ser simples, com poucas palavras chave, mas parece que ninguem quer seguir isso. Talvez quem conseguir esta simplicidade seja o ganahdor da corrida.

Vamos ver o que o futuro nos trás

sergiotaborda:

carlosanalista:

http://www.computer.org/portal/web/computingnow/software%20engineering/content?g=53319&type=article&urlTitle=computing-trends-lead-to-new-programming-languages

Segundo o artigo publicado na revista “COMPUTER”, uma publicação do IEEE, as linguagens mais utilizadas numa pesquisa feita a partir de 45 milhões de linhas de código são respectivamente:
C, C++ e Java.

Entretanto estas linguagens, segundo o artigo, podem perder lugar de destaque para novas linguagens, pois apresentam algumas deficiências que tornam exaustivo seu uso em cenários computacionais que utilizam por exemplo processamento paralelo, CPUs multicore, alta performance e cloud computing, sistemas distribuidos e Mobile. O artigo apresenta alguns exemplos de novas linguagens como exemplo: Microsoft F# que é apresentada como funcional e prática.

Hoje é obvio a todos que o modelo de usar VM é muito melhor que escrever codigo diretamente para o CPU. Isto era obvio antes - porque a VM nada mais é que um nivel de indireção e todos os problemas podem ser resolvidos com o nivel de indireção a mais - mas as pessoas resistiam à ideia. Hoje não mais. E a JVM da Sun, hoje Oracle é a melhor que existe no mercado em termos de VM. Ora, mas ela é uma máquina. então da mesma forma que várias linguagens compilam para máquinas reais, várias podem compilar para máquinas virtuais. Aliás, o .net sempre partiu deste principio. A linguagens .net compilam todas para a mesma linguagem comum que depois é executada.
Ora, o que estamos vendo agora é o pessoa entendendo que “VM” é legal, mas ainda é apenas uma VM. E da mesma forma que o java quiz ser cross plataform, a nova vaga de linguanges quer ser “cross-Vm” e aqui está um potencial imenso ainda inesplorado. Inclusive entenderam que a VM javacript é um alvo de mais linguanges ( o dart prova isto)
E é a corrida ao ouro. Todas querem ser o próximo java. A Haxe , assim como Fantom apostam neste ideia de corss-vm, mas isso vem com consequencias. Vamos ter UI para tudo ? Imagine ter algo semelhante ao swing que corre em qualquer VM. Imagine vc escrever um código que realmente nunca mais vc terá que reescrever porque vc vai trocar de VM , não de linguagem. Isto seria otimo. Uma linguagem e API para governar todas as outras. A uma-linguagem é próximo santo graal e quem conseguir encontrá-la vai ficar milionário. O problema é que o trabalho é imenso. Imagine compatibilizar .net com java com javascript, com php , com ruby, etc… loucura. Mas se vc tiver algo que corra vm de javacript (e ha várias , cada browser tem a sua) e algo que corra em uma plataforma de servidor como java ou .net ( ou ambas), pronto. Tá fechado. O problema agora é comercial e econômico. Porque alguém iria migrar para essas novas meta-plataformas ? E será que realmente os resultados são bons ? Dá para confiar ? Esta é a pergunta chave.

Como ainda é tudo muto corre-corre, ainda não dá para apostar tudo em uma delas. Então o pesoal precavido ainda fica no java ou no .net e no máximo faz um programa hibrido usando uma em um nodo e outra em outro (tipo android no cliente +.net no servidor). É que a linguagem é apenas o primeiro passo, o dificil é compatibilizar as API. sobretudo as básicas (I/O, Threads, UI ) (como se abre um arquivo em javascript ? )

Eu acho que é o futuro e estou de olho no melhor candidato e ha muitos. Realmente muitos. Mais dos que estão no artigo. Tem o fantom que já citei, mas tem o scala, o kotlin o gosu e muitos outros. Algumas querem ser meta-plataforma outros não . Por exemplo o scala ainda usa muita API do java. Ele pode ser compilado para .net ( porque o java pode ser compilado para .net via ikvm) mas é estranho tanta mistura. O idela seria ter uma aPI scala pura e o compilador se virar para usar API da plataforma base. Outros já partem deste principio. O fantom por exemplo tem api propria para muitas coisas e deixa usar o conceito de “native” que em java é usado para programa em C++ , em fantom é usado para programar código “nativo java” ou “nativo C#”. É um conceito interessante.

tudo se resume à robustez. quando estas novas plataformas mostrarem que valem o investimento, as pessoas vão começar a migrar. E no entretanto todas as variantes mostram as vantagens e desvantegens das outras. Hoje em dia se vc não é OO, esquece. E tem que ser fortemente tipado e tem que ser dinamicamente tipado e tem que ter closures e tem que ter paralelismo e um monte de outras coisas. E está se procurando o melhor encaixe para tudo isso. O problema que eu vejo com essas linguagens é que são pouco simples. têm muitas palras chave em vez de conceitos profudamente compreendidos . O java é muito bom em ser simples, com poucas palavras chave, mas parece que ninguem quer seguir isso. Talvez quem conseguir esta simplicidade seja o ganahdor da corrida.

Vamos ver o que o futuro nos trás

Parabens sergio.

Se alguém postar aqui o TIOBE index, eu tranco o tópico.

De qualquer forma, todo ano tem dezenas de reportagens dessas, anunciando a morte de linguagens antigas (que nunca morrem) e dizendo que o futuro pertence ao código funcional ou a linguagens de nome bem estranho.

É tudo muito legal, mas poucas dessas realmente vingam na prática. A razão é simples: Para uma coisa vingar, ela deve oferecer uma vantagem bastante substancial em relação a tecnologia antiga. Não pode ser pouco, ou então, as pessoas não estarão dispostas a vencer a curva de aprendizado, nem as empresas terão coragem de investir numa tecnologia incerta.

De qualquer forma, eu vivi a queda do Clipper, a do VB e do Delphi e não estou preocupado com o declínio do Java. Quando isso acontecer, veremos qual é a nova aposta nos classificados, veremos vários artigos saindo sobre a nova tendência. E, no final das contas, é só uma questão de estudar.

ViniGodoy:

De qualquer forma, eu vivi a queda do Clipper, a do VB e do Delphi e não estou preocupado com o declínio do Java. Quando isso acontecer, veremos qual é a nova aposta nos classificados, veremos vários artigos saindo sobre a nova tendência. E, no final das contas, é só uma questão de estudar.

Tecnicamente o VB não caiu (ainda é uma linguagem do .net) assim como o Delphi (idem .net). O que caiu for a plataforma. A API. O jeito de fazer as coisas, não a linguagem em si. O Clipper caiu porque era mais uma ferramenta que uma plataforma.
Então, na realidade sempre assistimos à queda das plataformas e amnutenção ou evolução das linguagens. Isto porque as pessoas querem aproveitar o que sabem. Por exemplo , a linguagem java foi feita em cima do C++ porque se queria que as pessoas aproveitassem o que já sabiam. O C# em cima do java, idem. E todas essas linguagens do futuro de apoiam no C++/javaC# pela mesma razão. As linguagens em si não são tão novas assim. São as plataformas e os conceitos. A sintaxe do C++ e do java são muito semelhantes, a do java e mais simples até. Mas adiciona o cocneito de vm, adiciona o GC, e outras cosias que o C++ como plataforma não tem.

A tua postura parece mais de “vamos esperar e depois mudamos”, o eu entendo. Mas não seria legal apostares na linguagem certa ? O pessoal que apostou no java em 1990 se deu super bem porque foram os primeiros.
Por outro lado, porque esperar se poderiamos estar agora mesmo inventando a nossa propria linguagem ? Se eu soubesse fazer isso, podes ter a certeza que já tinha feito. Esse negocio de ficar escolhendo entre java e .net , cliente ou servidor, ui rica ou pobre já encheu a paciência.

ViniGodoy:

Se alguém postar aqui o TIOBE index, eu tranco o tópico.

De qualquer forma, todo ano tem dezenas de reportagens dessas, anunciando a morte de linguagens antigas (que nunca morrem) e dizendo que o futuro pertence ao código funcional ou a linguagens de nome bem estranho.

É tudo muito legal, mas poucas dessas realmente vingam na prática. A razão é simples: Para uma coisa vingar, ela deve oferecer uma vantagem bastante substancial em relação a tecnologia antiga. Não pode ser pouco, ou então, as pessoas não estarão dispostas a vencer a curva de aprendizado, nem as empresas terão coragem de investir numa tecnologia incerta.

De qualquer forma, eu vivi a queda do Clipper, a do VB e do Delphi e não estou preocupado com o declínio do Java. Quando isso acontecer, veremos qual é a nova aposta nos classificados, veremos vários artigos saindo sobre a nova tendência. E, no final das contas, é só uma questão de estudar.

E nem sempre a vantagem é em prol dos programadores. Java por exemplo tem como vantagem ser popular, que torna a mão de obra barata.

sergiotaborda:

Tecnicamente o VB não caiu (ainda é uma linguagem do .net) assim como o Delphi (idem .net). O que caiu for a plataforma. A API. O jeito de fazer as coisas, não a linguagem em si. O Clipper caiu porque era mais uma ferramenta que uma plataforma.
Então, na realidade sempre assistimos à queda das plataformas e amnutenção ou evolução das linguagens. Isto porque as pessoas querem aproveitar o que sabem. Por exemplo , a linguagem java foi feita em cima do C++ porque se queria que as pessoas aproveitassem o que já sabiam. O C# em cima do java, idem. E todas essas linguagens do futuro de apoiam no C++/javaC# pela mesma razão. As linguagens em si não são tão novas assim. São as plataformas e os conceitos. A sintaxe do C++ e do java são muito semelhantes, a do java e mais simples até. Mas adiciona o cocneito de vm, adiciona o GC, e outras cosias que o C++ como plataforma não tem.

A tua postura parece mais de “vamos esperar e depois mudamos”, o eu entendo. Mas não seria legal apostares na linguagem certa ? O pessoal que apostou no java em 1990 se deu super bem porque foram os primeiros.
Por outro lado, porque esperar se poderiamos estar agora mesmo inventando a nossa propria linguagem ? Se eu soubesse fazer isso, podes ter a certeza que já tinha feito. Esse negocio de ficar escolhendo entre java e .net , cliente ou servidor, ui rica ou pobre já encheu a paciência.

Só uma correção: Java foi feito “em cima” de Objective-c.

When I left Sun to go to NeXT, I thought
Objective-C was the coolest thing since sliced bread, and I hated C++.
So, naturally when I stayed to start the (eventually) Java project, Obj-C
had a big influence. James Gosling, being much older than I was, he had
lots of experience with SmallTalk and Simula68, which we also borrowed
from liberally.

http://cs.gmu.edu/~sean/stuff/java-objc.html

JoseIgnacio:

sergiotaborda:

Tecnicamente o VB não caiu (ainda é uma linguagem do .net) assim como o Delphi (idem .net). O que caiu for a plataforma. A API. O jeito de fazer as coisas, não a linguagem em si. O Clipper caiu porque era mais uma ferramenta que uma plataforma.
Então, na realidade sempre assistimos à queda das plataformas e amnutenção ou evolução das linguagens. Isto porque as pessoas querem aproveitar o que sabem. Por exemplo , a linguagem java foi feita em cima do C++ porque se queria que as pessoas aproveitassem o que já sabiam. O C# em cima do java, idem. E todas essas linguagens do futuro de apoiam no C++/javaC# pela mesma razão. As linguagens em si não são tão novas assim. São as plataformas e os conceitos. A sintaxe do C++ e do java são muito semelhantes, a do java e mais simples até. Mas adiciona o cocneito de vm, adiciona o GC, e outras cosias que o C++ como plataforma não tem.

A tua postura parece mais de "vamos esperar e depois mudamos", o eu entendo. Mas não seria legal apostares na linguagem certa ? O pessoal que apostou no java em 1990 se deu super bem porque foram os primeiros.
Por outro lado, porque esperar se poderiamos estar agora mesmo inventando a nossa propria linguagem ? Se eu soubesse fazer isso, podes ter a certeza que já tinha feito. Esse negocio de ficar escolhendo entre java e .net , cliente ou servidor, ui rica ou pobre já encheu a paciência.

Só uma correção: Java foi feito "em cima" de Objective-c.

When I left Sun to go to NeXT, I thought
Objective-C was the coolest thing since sliced bread, and I hated C++.
So, naturally when I stayed to start the (eventually) Java project, Obj-C
had a big influence. James Gosling, being much older than I was, he had
lots of experience with SmallTalk and Simula68, which we also borrowed
from liberally.

http://cs.gmu.edu/~sean/stuff/java-objc.html

Pode até ser, mas olhe a sintaxe de ObjC e do C++ e do Java e me diga qual é mais parecida. A influencia da arquitetura pode ser do objC, mas a sintaxe ?

em Object C vc chama um método assim

[obj method:argument];

em smalltalk assim

obj method: argument

em C++ assim

obj.method(argument);

em java assim

obj.method(argument);

qual é mais parecido ?

Não tou dizendo que o cara está mentido, estou dizendo que é muito difícil acreditar.
Olha o que diz no texto:

Isto sim faz sentido. Mas a sintaxe. Isso não.

O design da JVM foi baseado no ambiente de runtime do Smalltalk.

A sintaxe foi deliberadamente emprestada do C++, segundo o Gosling (até para reduzir as resistências dos programadores C e C++), mas o conceito de interfaces e herança simples foi copiado do Objective-C. De qualquer maneira, o Objective-C hoje em dia, na versão da Apple, também aceita a sintaxe obj.method (argument).

http://www.gotw.ca/publications/c_family_interview.htm

ViniGodoy:

Se alguém postar aqui o TIOBE index, eu tranco o tópico.

De qualquer forma, todo ano tem dezenas de reportagens dessas, anunciando a morte de linguagens antigas (que nunca morrem) e dizendo que o futuro pertence ao código funcional ou a linguagens de nome bem estranho.

É tudo muito legal, mas poucas dessas realmente vingam na prática. A razão é simples: Para uma coisa vingar, ela deve oferecer uma vantagem bastante substancial em relação a tecnologia antiga. Não pode ser pouco, ou então, as pessoas não estarão dispostas a vencer a curva de aprendizado, nem as empresas terão coragem de investir numa tecnologia incerta.

De qualquer forma, eu vivi a queda do Clipper, a do VB e do Delphi e não estou preocupado com o declínio do Java. Quando isso acontecer, veremos qual é a nova aposta nos classificados, veremos vários artigos saindo sobre a nova tendência. E, no final das contas, é só uma questão de estudar.

Concordo, as vezes o melhor é esperar mesmo, não dá pra ficar seguindo tudo o que aparece, uma tecnologia só substitui outra quando prova ser melhor, MUITO melhor, desculpa o erro gramatical.

Mas a verdade é que se você sair atirando pra todo lado, não vai se especializar em nada, tipo um cara que sabe 3, 4 linguagens diferentes mas, não domina elas, enquanto um carinha que sabe no máximo duas é altamente espacializado em ao menos uma.

Temos que ser criteriosos, o mercado pode dizer que quer você com suas 3, 4 linguagens mas na hora de codar, vai mandar você codar na plataformar que eles querem. E aí? O que isso significa? Nada! E se você dar mole e não preencher as expectativas, leva um pesão na bunda, fato.

cleiton.franca:

enquanto um carinha que sabe no máximo duas é altamente espacializado em ao menos uma.
.

Sei. Português não deve ser uma delas

A sintaxe é diferente porque obj-c permite enviar qualquer mensagem a qualquer objeto ([obj metodo:argumento]), enquanto Java e C# estão limitados à metodos definidos por uma interface estática.

sergiotaborda:

carlosanalista:

http://www.computer.org/portal/web/computingnow/software%20engineering/content?g=53319&type=article&urlTitle=computing-trends-lead-to-new-programming-languages

Segundo o artigo publicado na revista “COMPUTER”, uma publicação do IEEE, as linguagens mais utilizadas numa pesquisa feita a partir de 45 milhões de linhas de código são respectivamente:
C, C++ e Java.

Entretanto estas linguagens, segundo o artigo, podem perder lugar de destaque para novas linguagens, pois apresentam algumas deficiências que tornam exaustivo seu uso em cenários computacionais que utilizam por exemplo processamento paralelo, CPUs multicore, alta performance e cloud computing, sistemas distribuidos e Mobile. O artigo apresenta alguns exemplos de novas linguagens como exemplo: Microsoft F# que é apresentada como funcional e prática.

Hoje é obvio a todos que o modelo de usar VM é muito melhor que escrever codigo diretamente para o CPU. Isto era obvio antes - porque a VM nada mais é que um nivel de indireção e todos os problemas podem ser resolvidos com o nivel de indireção a mais - mas as pessoas resistiam à ideia. Hoje não mais. E a JVM da Sun, hoje Oracle é a melhor que existe no mercado em termos de VM. Ora, mas ela é uma máquina. então da mesma forma que várias linguagens compilam para máquinas reais, várias podem compilar para máquinas virtuais. Aliás, o .net sempre partiu deste principio. A linguagens .net compilam todas para a mesma linguagem comum que depois é executada.
Ora, o que estamos vendo agora é o pessoa entendendo que “VM” é legal, mas ainda é apenas uma VM. E da mesma forma que o java quiz ser cross plataform, a nova vaga de linguanges quer ser “cross-Vm” e aqui está um potencial imenso ainda inesplorado. Inclusive entenderam que a VM javacript é um alvo de mais linguanges ( o dart prova isto)
E é a corrida ao ouro. Todas querem ser o próximo java. A Haxe , assim como Fantom apostam neste ideia de corss-vm, mas isso vem com consequencias. Vamos ter UI para tudo ? Imagine ter algo semelhante ao swing que corre em qualquer VM. Imagine vc escrever um código que realmente nunca mais vc terá que reescrever porque vc vai trocar de VM , não de linguagem. Isto seria otimo. Uma linguagem e API para governar todas as outras. A uma-linguagem é próximo santo graal e quem conseguir encontrá-la vai ficar milionário. O problema é que o trabalho é imenso. Imagine compatibilizar .net com java com javascript, com php , com ruby, etc… loucura. Mas se vc tiver algo que corra vm de javacript (e ha várias , cada browser tem a sua) e algo que corra em uma plataforma de servidor como java ou .net ( ou ambas), pronto. Tá fechado. O problema agora é comercial e econômico. Porque alguém iria migrar para essas novas meta-plataformas ? E será que realmente os resultados são bons ? Dá para confiar ? Esta é a pergunta chave.

Como ainda é tudo muto corre-corre, ainda não dá para apostar tudo em uma delas. Então o pesoal precavido ainda fica no java ou no .net e no máximo faz um programa hibrido usando uma em um nodo e outra em outro (tipo android no cliente +.net no servidor). É que a linguagem é apenas o primeiro passo, o dificil é compatibilizar as API. sobretudo as básicas (I/O, Threads, UI ) (como se abre um arquivo em javascript ? )

Eu acho que é o futuro e estou de olho no melhor candidato e ha muitos. Realmente muitos. Mais dos que estão no artigo. Tem o fantom que já citei, mas tem o scala, o kotlin o gosu e muitos outros. Algumas querem ser meta-plataforma outros não . Por exemplo o scala ainda usa muita API do java. Ele pode ser compilado para .net ( porque o java pode ser compilado para .net via ikvm) mas é estranho tanta mistura. O idela seria ter uma aPI scala pura e o compilador se virar para usar API da plataforma base. Outros já partem deste principio. O fantom por exemplo tem api propria para muitas coisas e deixa usar o conceito de “native” que em java é usado para programa em C++ , em fantom é usado para programar código “nativo java” ou “nativo C#”. É um conceito interessante.

tudo se resume à robustez. quando estas novas plataformas mostrarem que valem o investimento, as pessoas vão começar a migrar. E no entretanto todas as variantes mostram as vantagens e desvantegens das outras. Hoje em dia se vc não é OO, esquece. E tem que ser fortemente tipado e tem que ser dinamicamente tipado e tem que ter closures e tem que ter paralelismo e um monte de outras coisas. E está se procurando o melhor encaixe para tudo isso. O problema que eu vejo com essas linguagens é que são pouco simples. têm muitas palras chave em vez de conceitos profudamente compreendidos . O java é muito bom em ser simples, com poucas palavras chave, mas parece que ninguem quer seguir isso. Talvez quem conseguir esta simplicidade seja o ganahdor da corrida.

Vamos ver o que o futuro nos trás

Não concordo que a vm é a solução para todos os problemas. Um exemplo disso é comparar o ios com o android. O segundo precisa de 3x mais hardware para conseguir o que o primeiro faz com pouco. Existe um “talvez” e um “depende” enorme aí na sua resposta.

cleiton.franca:

ViniGodoy:

Se alguém postar aqui o TIOBE index, eu tranco o tópico.

De qualquer forma, todo ano tem dezenas de reportagens dessas, anunciando a morte de linguagens antigas (que nunca morrem) e dizendo que o futuro pertence ao código funcional ou a linguagens de nome bem estranho.

É tudo muito legal, mas poucas dessas realmente vingam na prática. A razão é simples: Para uma coisa vingar, ela deve oferecer uma vantagem bastante substancial em relação a tecnologia antiga. Não pode ser pouco, ou então, as pessoas não estarão dispostas a vencer a curva de aprendizado, nem as empresas terão coragem de investir numa tecnologia incerta.

De qualquer forma, eu vivi a queda do Clipper, a do VB e do Delphi e não estou preocupado com o declínio do Java. Quando isso acontecer, veremos qual é a nova aposta nos classificados, veremos vários artigos saindo sobre a nova tendência. E, no final das contas, é só uma questão de estudar.

Concordo, as vezes o melhor é esperar mesmo, não dá pra ficar seguindo tudo o que aparece, uma tecnologia só substitui outra quando prova ser melhor, MUITO melhor, desculpa o erro gramatical.

Mas a verdade é que se você sair atirando pra todo lado, não vai se especializar em nada, tipo um cara que sabe 3, 4 linguagens diferentes mas, não domina elas, enquanto um carinha que sabe no máximo duas é altamente espacializado em ao menos uma.

Temos que ser criteriosos, o mercado pode dizer que quer você com suas 3, 4 linguagens mas na hora de codar, vai mandar você codar na plataformar que eles querem. E aí? O que isso significa? Nada! E se você dar mole e não preencher as expectativas, leva um pesão na bunda, fato.

Concordo com você em não sair pegando o que há de tão novo no mercado. Aliás se couber a mim trabalhar encabeçando um projeto vou escolher linguagens mais maduras e com uma gama grande de apis.

Se VB.Net é VB, então C++ é C.

VB.Net é uma criatura bem diferente do que era o VB. É orientado a objetos (o VB era estruturado), tem suporte a threads (o VB não tinha) e aboliu vários comandos perigosos da linguagem.
Em resumo, virou linguagem de verdade.

Tanto que um código VB é totalmente incompatível com um código VB.Net.

Quando digo que o VB morreu, estou falando do VB que existiu até a versão 6, e que inspirou o VBA e o ASP.

Acho que manteremos essa fragmentação de linguagens por um bom tempo ainda.
Acredito que as coisas irão realmente mudar quando começarem a surgir comercialmente os primeiros computadores quânticos. Pois quando chegarmos neste momento, realmente teremos uma série de necessidades específicas em termos de linguagem. Por mais que tenhamos hoje em dia cloud, VMs, paralelismo, interfaces ricas, mobile, etc… não vejo nessas tendências/tecnologias uma grande alteração no paradigma computacional e na forma como abordamos problemas.

giulianocosta:

Acho que manteremos essa fragmentação de linguagens por um bom tempo ainda.
Acredito que as coisas irão realmente mudar quando começarem a surgir comercialmente os primeiros computadores quânticos. Pois quando chegarmos neste momento, realmente teremos uma série de necessidades específicas em termos de linguagem. Por mais que tenhamos hoje em dia cloud, VMs, paralelismo, interfaces ricas, mobile, etc… não vejo nessas tendências/tecnologias uma grande alteração no paradigma computacional e na forma como abordamos problemas.

Essa coisa de fragmentação de linguagem não existe. O que existe são “empresas de hardware” e são essas quem ditam as regras. Se você for desenvolver um montador é o manual do processador ou microcontrolador delas que irá ler.

Linguagens “diferentes” precisam existir porque elas estão “extremamente relacionadas” com o tipo de projeto que se desenvolve. Vide lego mindstorms com a “nxc” própria deles.

juliocbq:

Essa coisa de fragmentação de linguagem não existe. O que existe são “empresas de hardware” e são essas quem ditam as regras. Se você for desenvolver um montador é o manual do processador ou microcontrolador delas que irá ler.

Linguagens “diferentes” precisam existir porque elas estão “extremamente relacionadas” com o tipo de projeto que se desenvolve. Vide lego mindstorms com a “nxc” própria deles.

O que quis dizer com fragmentação é referente a ter muitas linguagens com foco em diferentes problemas. Eu não disse em ponto algum que elas não devem existir! Inclusive eu as apoio.

Eu aposto na computação quântica, pois ela realmente trará novos desafios e novas possibilidades. Nosso modelo computacional e mercado de hardware, há anos, se baseiam em poder de processamento paralelo dos 0s e 1s. Na computação quântica haverá uma mudança substancial nesse conceito.

entanglement:

cleiton.franca:

enquanto um carinha que sabe no máximo duas é altamente espacializado em ao menos uma.
.

Sei. Português não deve ser uma delas :(

Obrigado pela correção

Aqui no GUJ a gente vê a língua bem “extendida”. Até certa vez criei um tópico sobre isso:
http://www.guj.com.br/java/148207-nossa-lingua-portuguesa

giulianocosta:

juliocbq:

Essa coisa de fragmentação de linguagem não existe. O que existe são “empresas de hardware” e são essas quem ditam as regras. Se você for desenvolver um montador é o manual do processador ou microcontrolador delas que irá ler.

Linguagens “diferentes” precisam existir porque elas estão “extremamente relacionadas” com o tipo de projeto que se desenvolve. Vide lego mindstorms com a “nxc” própria deles.

O que quis dizer com fragmentação é referente a ter muitas linguagens com foco em diferentes problemas. Eu não disse em ponto algum que elas não devem existir! Inclusive eu as apoio.

Eu aposto na computação quântica, pois ela realmente trará novos desafios e novas possibilidades. Nosso modelo computacional e mercado de hardware, há anos, se baseiam em poder de processamento paralelo dos 0s e 1s. Na computação quântica haverá uma mudança substancial nesse conceito.

A linha core ix da intel já é um grande avanço pois consegue passar uma grande quantidade de bits em um barramento relativamente pequeno, mas ainda é o paradigma elétrico. Quando chegar nesse que você diz aí por luz vai abrir um leque de infinitas possibilidades.

Acho que hoje dentro do próprio .NET ou Java temos formas relativamente simples de resolver grandes problemas com eficiência. Java e .Net evoluem muito mais do que as plataformas mais usadas no passado, “evoluindo” até demais para os lados formando tribos diferentes na mesma plataforma. Ai o ruim é quando pegamos projetos que usam coisas relativamente complicadas e burocráticas sem necessidade, exigindo mais, engessando na hora de grandes mudanças de layout ou regras, ai a plataforma é taxada de “complexa”.

É, o “pior” é que na descrição das vagas ao invés dos 50 frameworks de uma mesma linguagem como vemos hoje em dia o pessoal começará a colocar 50 frameworks de 50 linguagens diferentes. 50x mais estudo e pelo mesmo salário ou menor. E 90% destes frameworks/linguagens serão utilizados para fazer cruds…
Não acho ruim termos opções, o problema é ter que aprender tudo isso. Quando eu comecei a utilizar python vi que é uma linguagem bem simples mas mesmo assim demorou um pouco pra eu ficar produtivo com essa linguagem, pois até coisas simples tinha que parar pra ler sobre a biblioteca, testar os exemplos, etc; enquanto que no java eu saberia fazer sem consultar documentação nenhuma. Agora imagina isso multiplicado por 50x ou mais.
Por isso que eu concordo que o melhor é esperar do que ficar se matando pra estudar algo que talvez nem seja utilizado.

Em termos de linguagem o Java está bem lento para evoluir. Em parte era culpa da falência da Sun, mas faz um bocado de tempo que a Oracle assumiu e ainda não temos programação funcional (e, detalhe, o C++ já tem).

Enquanto isso, o .Net, que já tem esse recurso desde a versão 3.5, mostra um framework excelente de assincronismo na versão 4.
Eu mesmo fiquei de queixo caído quando usei para implementar o core do Aurélio para Windows 8.

Em termos de linguagem o Java está bem lento para evoluir. Em parte era culpa da falência da Sun, mas faz um bocado de tempo que a Oracle assumiu e ainda não temos programação funcional (e, detalhe, o C++ já tem).

Enquanto isso, o .Net, que já tem esse recurso desde a versão 3.5, mostra um framework excelente de assincronismo na versão 4.
Eu mesmo fiquei de queixo caído quando usei para implementar o core do Aurélio para Windows 8.

Muito lento mesmo. A maioria não percebe o quanto java ficou para traz. A linguagem vala não tem muito mais que 5 anos e está bem afrente em recursos funcionais. O grande problema da java é que a oracle “engessou” a linguagem para fins mais corporativos na maioria dos anos. Agora no final que veio investindo na linguagem para outras soluções como o jafafx para ARM. Mas isso a Google já tinha conseguido a muitos anos atras.

Não através de reflexão (embora isso seja cheating).

No caso do C++, não existe essa limitação também. É uma benção poder criar uma função para qualquer coisa que atenda determinada interface, mesmo ele não implementando explicitamente aquela interface.

Em termos de linguagem o Java está bem lento para evoluir. Em parte era culpa da falência da Sun, mas faz um bocado de tempo que a Oracle assumiu e ainda não temos programação funcional (e, detalhe, o C++ já tem).

Enquanto isso, o .Net, que já tem esse recurso desde a versão 3.5, mostra um framework excelente de assincronismo na versão 4.
Eu mesmo fiquei de queixo caído quando usei para implementar o core do Aurélio para Windows 8.
Valeu, se hoje a linguagem do Java está meio parada tô por fora, mas lembro que em termos de plataforma quando tentava aprender Java enquanto trabalhava com Delphi era uma loucura, a cada edição de revista era algo totalmente novo, lembro que por muuito tempo. E o .NET copiou isso tudo muito bem e tá evoluindo ainda. Só o que acho estranho é que no Java não existe uma solução web action-based apoiada oficialmente pela Sun/Oracle. Enquanto na comunidade .NET é mais unanime apoiar action-based para novas soluções, no Java é component-based é muito valorizado, mas sei que o component-based do Java é muito melhor que do .NET. Uma fortalece a outra. Quando surgem duplas concorrentes diretas é que a coisa fica fortalecida.

Em termos de linguagem o Java está bem lento para evoluir. Em parte era culpa da falência da Sun, mas faz um bocado de tempo que a Oracle assumiu e ainda não temos programação funcional (e, detalhe, o C++ já tem).

Enquanto isso, o .Net, que já tem esse recurso desde a versão 3.5, mostra um framework excelente de assincronismo na versão 4.
Eu mesmo fiquei de queixo caído quando usei para implementar o core do Aurélio para Windows 8.
Valeu, se hoje a linguagem do Java está meio parada tô por fora, mas lembro que em termos de plataforma quando tentava aprender Java enquanto trabalhava com Delphi era uma loucura, a cada edição de revista era algo totalmente novo, lembro que por muuito tempo. E o .NET copiou isso tudo muito bem e tá evoluindo ainda. Só o que acho estranho é que no Java não existe uma solução web action-based apoiada oficialmente pela Sun/Oracle. Enquanto na comunidade .NET é mais unanime apoiar action-based para novas soluções, no Java é component-based é muito valorizado, mas sei que o component-based do Java é muito melhor que do .NET. Uma fortalece a outra. Quando surgem duplas concorrentes diretas é que a coisa fica fortalecida.

No caso o .net herdou tudo que seria da linguagem object pascal quando a microsoft comprou Anders Heijsberg da antiga borland. O .net é mais delphi com “properties” e várias outras funcionalidades da linguagem do que “java” em si.

Em termos de linguagem o Java está bem lento para evoluir. Em parte era culpa da falência da Sun, mas faz um bocado de tempo que a Oracle assumiu e ainda não temos programação funcional (e, detalhe, o C++ já tem).

Enquanto isso, o .Net, que já tem esse recurso desde a versão 3.5, mostra um framework excelente de assincronismo na versão 4.
Eu mesmo fiquei de queixo caído quando usei para implementar o core do Aurélio para Windows 8.
Valeu, se hoje a linguagem do Java está meio parada tô por fora, mas lembro que em termos de plataforma quando tentava aprender Java enquanto trabalhava com Delphi era uma loucura, a cada edição de revista era algo totalmente novo, lembro que por muuito tempo. E o .NET copiou isso tudo muito bem e tá evoluindo ainda. Só o que acho estranho é que no Java não existe uma solução web action-based apoiada oficialmente pela Sun/Oracle. Enquanto na comunidade .NET é mais unanime apoiar action-based para novas soluções, no Java é component-based é muito valorizado, mas sei que o component-based do Java é muito melhor que do .NET. Uma fortalece a outra. Quando surgem duplas concorrentes diretas é que a coisa fica fortalecida.

No caso o .net herdou tudo que seria da linguagem object pascal quando a microsoft comprou Anders Heijsberg da antiga borland. O .net é mais delphi com “properties” e várias outras funcionalidades da linguagem do que “java” em si.

A parte de desktop sim totalmente Delphi e linguagem Java. WebForms também. Hoje felizmente a coisa ta bem mais Java e Rails no .NET na web, foco em produtividade escrevendo código.

JoseIgnacio:

Só uma correção: Java foi feito “em cima” de Objective-c.

Uma pena que não copiou as boas idéias. Objective C é uma linguagem dinâmica, que, entre outras coisas, permite que você adicione métodos em classes, não tem null pointer, etc. Fora que as APIs da Foundation e Cocoa são muito melhores que as do Java.

Até a persistência com Core Data é muito mais fácil do que Hibernate.

Java é muito ruim.

Não através de reflexão (embora isso seja cheating).

No caso do C++, não existe essa limitação também. É uma benção poder criar uma função para qualquer coisa que atenda determinada interface, mesmo ele não implementando explicitamente aquela interface.

Não é isso a que ele se refere. O que ele quer dizer é eu posso enviar uma mensagem para qualquer objeto, mesmo que ele implemente o método ou não. Caso não implemente então o método retorna nil, sem dar exception de nada.

Em Java ou C++ isso não existe.

Longino:

JoseIgnacio:

Só uma correção: Java foi feito “em cima” de Objective-c.

Uma pena que não copiou as boas idéias. Objective C é uma linguagem dinâmica, que, entre outras coisas, permite que você adicione métodos em classes, não tem null pointer, etc. Fora que as APIs da Foundation e Cocoa são muito melhores que as do Java.

Até a persistência com Core Data é muito mais fácil do que Hibernate.

Java é muito ruim.

Você está falando de um grande problema, que é dar manutenção em grandes projetos no futuro.

Umas das ideias e preocupações do java é ser boa para escrever e ótima para ler e dar manutenção.

Se você ver java como plataforma, pode se criar linguagens dinâmicas.

Já rodei por muitas linguagens em projetos gigantescos, e digo sem sombra de duvidas e agradeço a falecida SUN :

Java é Excelente.

No QT tem algo mais interessante. Você pode definir um objeto que envia um signal. Esse objeto envia esse sinal, sem se preocupar se alguém escuta ou não o sinal. Em outro momento, você implementa alguém que tem um slot para receber o sinal, e usa um comando para associar os dois.

Não é exatamente a mesma coisa, mas é tão flexível quanto.

Uma linguagem que não foi citada no artigo e que é anos luz mais avançada que java é Scala.
Essa ao meu ver, é a única linguagem na jvm que se aproxima do poder de c# e do c++.

Mas hoje em dia, considero c++ como a linguagem mais completa que existe, e que tem mais
beneficios, mesmo não gostando pessoalmente da sintaxe.

johnny quest:

Uma linguagem que não foi citada no artigo e que é anos luz mais avançada que java é Scala.
Essa ao meu ver, é a única linguagem na jvm que se aproxima do poder de c# e do c++.

Mas hoje em dia, considero c++ como a linguagem mais completa que existe, e que tem mais
beneficios, mesmo não gostando pessoalmente da sintaxe.

É a mesma opinião que tenho e como o o vini citou no post acima do seu. É a linguagem mais flexível e com compilador competente para gerar o código mais enxuto que existe.
O esquema de sinais e slots do qt são uma espécie de função de callback segura semelhante a do toolkit gtk(sendo essa sem segurança usando ponteiros em c). É o melhor sistema de troca de mensagens que já vi de todos os frameworks que conheço(que não são poucos);

j-menezes:

Você está falando de um grande problema, que é dar manutenção em grandes projetos no futuro.

Umas das ideias e preocupações do java é ser boa para escrever e ótima para ler e dar manutenção.

Se você ver java como plataforma, pode se criar linguagens dinâmicas.

Já rodei por muitas linguagens em projetos gigantescos, e digo sem sombra de duvidas e agradeço a falecida SUN :

Java é Excelente.

Java é só server side, para todo o resto é ruim.

Em vista do desenvolvimento tanto do Objective C quanto do C++, que estão ficando melhores a cada nova versão, eu não vejo razão de usá-lo para nada que envolva desktop, mobile, etc, ou seja, quase tudo. Quase tudo fica melhor em linguagens nativas.

Longino:

j-menezes:

Você está falando de um grande problema, que é dar manutenção em grandes projetos no futuro.

Umas das ideias e preocupações do java é ser boa para escrever e ótima para ler e dar manutenção.

Se você ver java como plataforma, pode se criar linguagens dinâmicas.

Já rodei por muitas linguagens em projetos gigantescos, e digo sem sombra de duvidas e agradeço a falecida SUN :

Java é Excelente.

Java é só server side, para todo o resto é ruim.

Em vista do desenvolvimento tanto do Objective C quanto do C++, que estão ficando melhores a cada nova versão, eu não vejo razão de usá-lo para nada que envolva desktop, mobile, etc, ou seja, quase tudo. Quase tudo fica melhor em linguagens nativas.

Quase tudo fica mais bugado em linguagem nativa, isso sim !!!

Longino:

j-menezes:

Você está falando de um grande problema, que é dar manutenção em grandes projetos no futuro.

Umas das ideias e preocupações do java é ser boa para escrever e ótima para ler e dar manutenção.

Se você ver java como plataforma, pode se criar linguagens dinâmicas.

Já rodei por muitas linguagens em projetos gigantescos, e digo sem sombra de duvidas e agradeço a falecida SUN :

Java é Excelente.

Java é só server side, para todo o resto é ruim.

Em vista do desenvolvimento tanto do Objective C quanto do C++, que estão ficando melhores a cada nova versão, eu não vejo razão de usá-lo para nada que envolva desktop, mobile, etc, ou seja, quase tudo. Quase tudo fica melhor em linguagens nativas.

Putz, você não exagerou nem nada … Android é mobile e usa a linguagem java (embora android não seja java no sentido que a vm não é igual) Objective C é para Apple , e já vai com sorte…

Se fosse verdade que tudo fica melhor em linguagens nativas a JVM com JIT não batia a performance do codigo compilado com C++. O dinamismo de um VM é muito relevante em muitos cenários e pode oferecer uma melhor performance a aplicativos de longo curso. Claro que para apps isso é irrelevante, mas não são as apps que movem o mundo. Ainda são os servidores. As apps são meros clientes e não fazem nada que não possa ser feito num browser. É apenas um modelo de negocio, não de desenvolvimento.

É muito exagerado o que você disse, fora que confunde a linguagem java com a plataforma java.

A linguagem java tem realmente problemas, mas não a plataforma. Hoje em dia tem até java correndo no ios.

É que o titulo do topico é enganador. Não são novas linguagens , são novas plataformas que estão surgindo.

Pelo visto tem gente aqui no forum que nunca teve problemas sérios com C++, são erros invisíveis
difícil de achar, ponteiros, sobrecarga, lixo de memória apis próprias de cada fabricante é uma coisa
de louco.

Ainda falando em apenas um SO, ainda que engana, o bicho pega quando se envolve mais plataformas.

Até onde testei o windows com toda aquela equipe de engenheiros e programadores bons, carrega erros
invisíveis que fogem a boa lógica, o mesmo aconteceu com o solaris antes do surgimento do java.

Falar que a jvm tem performance pior que c++ isso ai já é falta sujar as mãos de verdade. Existem
otimizações na jvm que deixam c++ comendo poeira.

Quanto a java ser boa pra desktop, pra mim é ótima, desenvolvi api pra facilitar o meu trabalho.

Quero lembrar que como muitos aqui também programo em c e c++, não basta a linguagem ter mais
recursos, tem que ser boa pra manutenção também e nisso java dá um show !!!.

sergiotaborda:

É que o titulo do topico é enganador. Não são novas linguagens , são novas plataformas que estão surgindo.

Sergio, você não quis dizer o contrário? Novas linguagens surgiram mas não surgem novas plataformas?

sergiotaborda:

Longino:

j-menezes:

Você está falando de um grande problema, que é dar manutenção em grandes projetos no futuro.

Umas das ideias e preocupações do java é ser boa para escrever e ótima para ler e dar manutenção.

Se você ver java como plataforma, pode se criar linguagens dinâmicas.

Já rodei por muitas linguagens em projetos gigantescos, e digo sem sombra de duvidas e agradeço a falecida SUN :

Java é Excelente.

Java é só server side, para todo o resto é ruim.

Em vista do desenvolvimento tanto do Objective C quanto do C++, que estão ficando melhores a cada nova versão, eu não vejo razão de usá-lo para nada que envolva desktop, mobile, etc, ou seja, quase tudo. Quase tudo fica melhor em linguagens nativas.

Putz, você não exagerou nem nada … Android é mobile e usa a linguagem java (embora android não seja java no sentido que a vm não é igual) Objective C é para Apple , e já vai com sorte…

Se fosse verdade que tudo fica melhor em linguagens nativas a JVM com JIT não batia a performance do codigo compilado com C++. O dinamismo de um VM é muito relevante em muitos cenários e pode oferecer uma melhor performance a aplicativos de longo curso. Claro que para apps isso é irrelevante, mas não são as apps que movem o mundo. Ainda são os servidores. As apps são meros clientes e não fazem nada que não possa ser feito num browser. É apenas um modelo de negocio, não de desenvolvimento.

É muito exagerado o que você disse, fora que confunde a linguagem java com a plataforma java.

A linguagem java tem realmente problemas, mas não a plataforma. Hoje em dia tem até java correndo no ios.

É que o titulo do topico é enganador. Não são novas linguagens , são novas plataformas que estão surgindo.

A plataforma faz toda a diferença e é na minha opinião a principal parte a ser considerada. No caso da plataforma java e plataforma android existe uma grande diferença entre elas. Android já é “todo um sistema operacional” enquanto java não é. Além da dalvik ter privilégios de poder rodar a nível de kernel, gerenciar vários processos simultâneos enquanto a primeira não faz isso. A Oracle liberou uma versão de java para arm com jfx. Isso faz quase a vm da oracle se tornar uma dalvik, tirando a questão dos privilégios.

Rodar java, scala, jpython na jvm não faz diferença no desempenho da aplicação porque é o mesmo bytecode que é executado. Faz diferença apenas para nós humanos. A mesma coisa com c# para android com mono e exceção ao Qt que produz código nativo e roda um passo abaixo das aplicações comuns.

artigo com tendencialismo elevado ao infinito esse…
bem foi uma propaganda disfarçada da Micro$oft!

j-menezes:

Pelo visto tem gente aqui no forum que nunca teve problemas sérios com C++, são erros invisíveis
difícil de achar, ponteiros, sobrecarga, lixo de memória apis próprias de cada fabricante é uma coisa
de louco.

Ainda falando em apenas um SO, ainda que engana, o bicho pega quando se envolve mais plataformas.

Até onde testei o windows com toda aquela equipe de engenheiros e programadores bons, carrega erros
invisíveis que fogem a boa lógica, o mesmo aconteceu com o solaris antes do surgimento do java.

Falar que a jvm tem performance pior que c++ isso ai já é falta sujar as mãos de verdade. Existem
otimizações na jvm que deixam c++ comendo poeira.

Quanto a java ser boa pra desktop, pra mim é ótima, desenvolvi api pra facilitar o meu trabalho.

Quero lembrar que como muitos aqui também programo em c e c++, não basta a linguagem ter mais
recursos, tem que ser boa pra manutenção também e nisso java dá um show !!!.

Rapaz, eu trabalho a mais de dez anos com c++ e linguagem c e nunca sofri com leaks do jeito que você está apresentando. Olha que peguei c++ na época do c++95 em que não existia boa parte das ferramentas que fazem contagem de referência nem implementam um modelo de memória robusto com smart pointers como share_ptr etc. Isso aí não procede não.

juliocbq:

sergiotaborda:

Longino:

j-menezes:

Você está falando de um grande problema, que é dar manutenção em grandes projetos no futuro.

Umas das ideias e preocupações do java é ser boa para escrever e ótima para ler e dar manutenção.

Se você ver java como plataforma, pode se criar linguagens dinâmicas.

Já rodei por muitas linguagens em projetos gigantescos, e digo sem sombra de duvidas e agradeço a falecida SUN :

Java é Excelente.

Java é só server side, para todo o resto é ruim.

Em vista do desenvolvimento tanto do Objective C quanto do C++, que estão ficando melhores a cada nova versão, eu não vejo razão de usá-lo para nada que envolva desktop, mobile, etc, ou seja, quase tudo. Quase tudo fica melhor em linguagens nativas.

Putz, você não exagerou nem nada … Android é mobile e usa a linguagem java (embora android não seja java no sentido que a vm não é igual) Objective C é para Apple , e já vai com sorte…

Se fosse verdade que tudo fica melhor em linguagens nativas a JVM com JIT não batia a performance do codigo compilado com C++. O dinamismo de um VM é muito relevante em muitos cenários e pode oferecer uma melhor performance a aplicativos de longo curso. Claro que para apps isso é irrelevante, mas não são as apps que movem o mundo. Ainda são os servidores. As apps são meros clientes e não fazem nada que não possa ser feito num browser. É apenas um modelo de negocio, não de desenvolvimento.

É muito exagerado o que você disse, fora que confunde a linguagem java com a plataforma java.

A linguagem java tem realmente problemas, mas não a plataforma. Hoje em dia tem até java correndo no ios.

É que o titulo do topico é enganador. Não são novas linguagens , são novas plataformas que estão surgindo.

A plataforma faz toda a diferença e é na minha opinião a principal parte a ser considerada. No caso da plataforma java e plataforma android existe uma grande diferença entre elas. Android já é “todo um sistema operacional” enquanto java não é. Além da dalvik ter privilégios de poder rodar a nível de kernel, gerenciar vários processos simultâneos enquanto a primeira não faz isso. A Oracle liberou uma versão de java para arm com jfx. Isso faz quase a vm da oracle se tornar uma dalvik, tirando a questão dos privilégios.

Rodar java, scala, jpython na jvm não faz diferença no desempenho da aplicação porque é o mesmo bytecode que é executado. Faz diferença apenas para nós humanos. A mesma coisa com c# para android com mono e exceção ao Qt que produz código nativo e roda um passo abaixo das aplicações comuns.

Processos simultâneos pode ser implementado a qualquer hora, na realidade a vm não precisa do kernel embora o use, a implementação pode invocar a instrução diretamente da bios, ou ainda acessar um recurso qualquer de hardware.

Android nada mais é que linux modificado e dalvik nada mais é que uma simples vm.

Quanto a rodar java, scala, jpython entre outras na jvm, não fazer diferença no desempenho, isso não 100% verdade,
justamente porque você pode fazer uma linguagem em jvm com um algoritimo novo para tal tarefa, e isso poderá sim criar diferença de performance, inclusive ser mais rápido que a gerada pelo próprio compilador java.

A byte é o mesmo mas a implementação da rotina nem sempre !!!

juliocbq:

j-menezes:

Pelo visto tem gente aqui no forum que nunca teve problemas sérios com C++, são erros invisíveis
difícil de achar, ponteiros, sobrecarga, lixo de memória apis próprias de cada fabricante é uma coisa
de louco.

Ainda falando em apenas um SO, ainda que engana, o bicho pega quando se envolve mais plataformas.

Até onde testei o windows com toda aquela equipe de engenheiros e programadores bons, carrega erros
invisíveis que fogem a boa lógica, o mesmo aconteceu com o solaris antes do surgimento do java.

Falar que a jvm tem performance pior que c++ isso ai já é falta sujar as mãos de verdade. Existem
otimizações na jvm que deixam c++ comendo poeira.

Quanto a java ser boa pra desktop, pra mim é ótima, desenvolvi api pra facilitar o meu trabalho.

Quero lembrar que como muitos aqui também programo em c e c++, não basta a linguagem ter mais
recursos, tem que ser boa pra manutenção também e nisso java dá um show !!!.

Rapaz, eu trabalho a mais de dez anos com c++ e linguagem c e nunca sofri com leaks do jeito que você está apresentando. Olha que peguei c++ na época do c++95 em que não existia boa parte das ferramentas que fazem contagem de referência nem implementam um modelo de memória robusto com smart pointers como share_ptr etc. Isso aí não procede não.

Você deve ser um gênio. Até hoje não arrumaram o windows com esses erros que eu citei.

giulianocosta:

sergiotaborda:

É que o titulo do topico é enganador. Não são novas linguagens , são novas plataformas que estão surgindo.

Sergio, você não quis dizer o contrário? Novas linguagens surgiram mas não surgem novas plataformas?

Não é ao contrário.
Hoje em dia linguagens não operam sozinhas. Em OO é necessário o conceito de API padrão. São aquelas classes básicas que vc usa para implementar suas aplicações.
Por outro lado, a plataforma é inutil sem um API onde ela possa plugar as coisas. Ou seja, a VM utiliza-se de coisas como herança, encapsulamento, polimorfismo para poder criar a funcionalidade de correr em vários lugares ao mesmo tempo, provendo a mesma funcionalidades.

O Java é usado não apenas porque corre em todo o lugar mas principalmente pela vasta API , quer padrão quer e terceiros, que , por causa da VM irá correr em qualquer lugar da mesma forma. Esta estabilidade é que é vital e que não ha em outras tecnologias.

Então, quando vc desenvolver um groovy ou um scala que obrigam vc a usar a mesma API que o java, isso não é uma plataforma. É apenas uma nova linguagem. Mas quando vc cria uma outra API que permite que vc programe em uma linguagem X e compile em qualquer plataformas, isso sim é uma vantagem. Mas ai a api tem que ser tão poderosa quando a do java (pelo menos) e isso é muita coisa. O scala até que vai bem , mas ainda não é possivel remover os pacotes java dos imports.

Mas outras tecnologias como Haxe, Fantom e Gosu permitem utilizar os recursos a partir de uma API própria. Isso é bom porque corre em varias lugares (jvm, .net, browser) mas imagine criar uma API Itext ou um JasperReports ou um Hibernate em cima dessa nova plataforma. Só quando isso existir, é que o pessoal vai começar a usar, porque o java os habituou mal. Então, são plataformas ( vm + API + linguagem) que importam e não a linguagem em si. A linguagem é só um fornt end. O que é relevante é usar a mesma API. Vc quer ter flexibilidade de mudar a linguagem e a VM. Hoje o java corre em muitos sistemas e inclusive dentro do .net. O que possibilita usar scala dentro do .net. Mas vc vai usar System.out ? Não dá. Tem que usar Console. E ai quebra a universalidade do seu sistema.

Se vc usa programa para uma API alvo e alguem garante que essa aPI vai funcionar em qualquer lugar, isso permite que vc crie seu aplicativo apenas uma vez. E apenas uma vez de verdade ( não como o java) porque o que vc vai fazer a seguir é mudar o compilador, não a linguagem. Ou seja, seus fontes são eternos e não importa que tecnologia vem a seguir. Para este tipo de maturidade, vc precisa de plataformas , não de linguagens. A linguagens é apenas um detalhes.

O que o artigo fala, e o que é a tendencia é a ciração de novas plataformas. Sim, ha criação de novas linguagens (que não são paltaformas, como groovy e scala) mas tb ha as que são. E a nova moda é implementar novas API em cima de velhas VM (aproveitando ou não a API padrão da VM, não importa porque o programador não vê).

ou seja, o interessante não é linguagem que vem com a plataforma (porque isso pode mudar, criar outra, etc… ) é a plataforma em si.

Bom, não entendi nada agora. Pelo teus posts achei que tu querias dizer que estão sendo criadas varias linguagens porém ainda não temos indícios de criação de nova uma plataforma “mainstream” como foi/é o C++, Java, etc…

Conceito de plataforma e linguagem eu conheço.

Bom, como disse em outros posts. Não acredito que apenas os requisitos atuais(paralelismo, cloud, vms, etc) façam necessária uma nova plataforma. Acredito que só quando houver uma alteração substancial na computação atual(processamento sequencial).

j-menezes:

juliocbq:

sergiotaborda:

Longino:

j-menezes:

Você está falando de um grande problema, que é dar manutenção em grandes projetos no futuro.

Umas das ideias e preocupações do java é ser boa para escrever e ótima para ler e dar manutenção.

Se você ver java como plataforma, pode se criar linguagens dinâmicas.

Já rodei por muitas linguagens em projetos gigantescos, e digo sem sombra de duvidas e agradeço a falecida SUN :

Java é Excelente.

Java é só server side, para todo o resto é ruim.

Em vista do desenvolvimento tanto do Objective C quanto do C++, que estão ficando melhores a cada nova versão, eu não vejo razão de usá-lo para nada que envolva desktop, mobile, etc, ou seja, quase tudo. Quase tudo fica melhor em linguagens nativas.

Putz, você não exagerou nem nada … Android é mobile e usa a linguagem java (embora android não seja java no sentido que a vm não é igual) Objective C é para Apple , e já vai com sorte…

Se fosse verdade que tudo fica melhor em linguagens nativas a JVM com JIT não batia a performance do codigo compilado com C++. O dinamismo de um VM é muito relevante em muitos cenários e pode oferecer uma melhor performance a aplicativos de longo curso. Claro que para apps isso é irrelevante, mas não são as apps que movem o mundo. Ainda são os servidores. As apps são meros clientes e não fazem nada que não possa ser feito num browser. É apenas um modelo de negocio, não de desenvolvimento.

É muito exagerado o que você disse, fora que confunde a linguagem java com a plataforma java.

A linguagem java tem realmente problemas, mas não a plataforma. Hoje em dia tem até java correndo no ios.

É que o titulo do topico é enganador. Não são novas linguagens , são novas plataformas que estão surgindo.

A plataforma faz toda a diferença e é na minha opinião a principal parte a ser considerada. No caso da plataforma java e plataforma android existe uma grande diferença entre elas. Android já é “todo um sistema operacional” enquanto java não é. Além da dalvik ter privilégios de poder rodar a nível de kernel, gerenciar vários processos simultâneos enquanto a primeira não faz isso. A Oracle liberou uma versão de java para arm com jfx. Isso faz quase a vm da oracle se tornar uma dalvik, tirando a questão dos privilégios.

Rodar java, scala, jpython na jvm não faz diferença no desempenho da aplicação porque é o mesmo bytecode que é executado. Faz diferença apenas para nós humanos. A mesma coisa com c# para android com mono e exceção ao Qt que produz código nativo e roda um passo abaixo das aplicações comuns.

Processos simultâneos pode ser implementado a qualquer hora, na realidade a vm não precisa do kernel embora o use, a implementação pode invocar a instrução diretamente da bios, ou ainda acessar um recurso qualquer de hardware.

Android nada mais é que linux modificado e dalvik nada mais é que uma simples vm.

Quanto a rodar java, scala, jpython entre outras na jvm, não fazer diferença no desempenho, isso não 100% verdade,
justamente porque você pode fazer uma linguagem em jvm com um algoritimo novo para tal tarefa, e isso poderá sim criar diferença de performance, inclusive ser mais rápido que a gerada pelo próprio compilador java.

A byte é o mesmo mas a implementação da rotina nem sempre !!!

De maneira alguma. A jvm roda a nível de aplicação enquanto a dalvik roda como módulo de kernel(ela pode fazer chamadas de sistema). A plataforma java não é um sistema operacional, é somente um software que simula um processador ou uma máquina real como O Sun spot(um microprocessador/controlador)(.

jvm

dalvik

Quanto a rodar java, scala, jpython entre outras na jvm, não fazer diferença no desempenho, isso não 100% verdade,
justamente porque você pode fazer uma linguagem em jvm com um algoritimo novo para tal tarefa, e isso poderá sim criar diferença de performance, inclusive ser mais rápido que a gerada pelo próprio compilador java.

A byte é o mesmo mas a implementação da rotina nem sempre !!!

É verdade, o mesmo bytecode rodando no mesmo hotspot(compiladores e otimizadores). Se você escrever em scala ou java vai gerar o mesmo bytecode a não ser que mude o seu algoritmo de um para outro.

Ela precisa de kernel, tanto é que a jvm é uma “aplicação” e não pode acessar nenhum tipo de hardware ainda mais um chip como uma “bios”. Ela não consegue enxergar nem mesmo uma porta serial(Você consegue isso usando bibliotecas de terceiros como rxtx escrita em c). A jvm não gerencia processos da maneira que a dalvik faz, por exemplo, quando você executa 2 programas distintos a jvm cria duas instâncias distintas dela mesma para esses processos enquanto a dalvik faz isso com apenas 1 processo gerenciando os dois.

Elas são plataformas completamente diferentes

j-menezes:

juliocbq:

j-menezes:

Pelo visto tem gente aqui no forum que nunca teve problemas sérios com C++, são erros invisíveis
difícil de achar, ponteiros, sobrecarga, lixo de memória apis próprias de cada fabricante é uma coisa
de louco.

Ainda falando em apenas um SO, ainda que engana, o bicho pega quando se envolve mais plataformas.

Até onde testei o windows com toda aquela equipe de engenheiros e programadores bons, carrega erros
invisíveis que fogem a boa lógica, o mesmo aconteceu com o solaris antes do surgimento do java.

Falar que a jvm tem performance pior que c++ isso ai já é falta sujar as mãos de verdade. Existem
otimizações na jvm que deixam c++ comendo poeira.

Quanto a java ser boa pra desktop, pra mim é ótima, desenvolvi api pra facilitar o meu trabalho.

Quero lembrar que como muitos aqui também programo em c e c++, não basta a linguagem ter mais
recursos, tem que ser boa pra manutenção também e nisso java dá um show !!!.

Rapaz, eu trabalho a mais de dez anos com c++ e linguagem c e nunca sofri com leaks do jeito que você está apresentando. Olha que peguei c++ na época do c++95 em que não existia boa parte das ferramentas que fazem contagem de referência nem implementam um modelo de memória robusto com smart pointers como share_ptr etc. Isso aí não procede não.

Você deve ser um gênio. Até hoje não arrumaram o windows com esses erros que eu citei.

O kernel linux é todo escrito em c estruturado e assembly e não existem esses tipos de problemas porque é bem testado. O que existe é uma coisa chamada known how. Além do mais o modelo de memória de todos os windows (nt) utilizam uma máquina virtual(escrita em c++ com o compilador da intel) para proteger a área de memória dos programas, dessa maneira você não consegue acessar os registradores da cpu usando um programa que roda em nível de aplicação.

Acredite em mim, o windows possui uma arquitetura fantástica. Quem fala mal não tem noção disso.

sergiotaborda:

giulianocosta:

sergiotaborda:

É que o titulo do topico é enganador. Não são novas linguagens , são novas plataformas que estão surgindo.

Sergio, você não quis dizer o contrário? Novas linguagens surgiram mas não surgem novas plataformas?

Não é ao contrário.
Hoje em dia linguagens não operam sozinhas. Em OO é necessário o conceito de API padrão. São aquelas classes básicas que vc usa para implementar suas aplicações.
Por outro lado, a plataforma é inutil sem um API onde ela possa plugar as coisas. Ou seja, a VM utiliza-se de coisas como herança, encapsulamento, polimorfismo para poder criar a funcionalidade de correr em vários lugares ao mesmo tempo, provendo a mesma funcionalidades.

O Java é usado não apenas porque corre em todo o lugar mas principalmente pela vasta API , quer padrão quer e terceiros, que , por causa da VM irá correr em qualquer lugar da mesma forma. Esta estabilidade é que é vital e que não ha em outras tecnologias.

Então, quando vc desenvolver um groovy ou um scala que obrigam vc a usar a mesma API que o java, isso não é uma plataforma. É apenas uma nova linguagem. Mas quando vc cria uma outra API que permite que vc programe em uma linguagem X e compile em qualquer plataformas, isso sim é uma vantagem. Mas ai a api tem que ser tão poderosa quando a do java (pelo menos) e isso é muita coisa. O scala até que vai bem , mas ainda não é possivel remover os pacotes java dos imports.

Mas outras tecnologias como Haxe, Fantom e Gosu permitem utilizar os recursos a partir de uma API própria. Isso é bom porque corre em varias lugares (jvm, .net, browser) mas imagine criar uma API Itext ou um JasperReports ou um Hibernate em cima dessa nova plataforma. Só quando isso existir, é que o pessoal vai começar a usar, porque o java os habituou mal. Então, são plataformas ( vm + API + linguagem) que importam e não a linguagem em si. A linguagem é só um fornt end. O que é relevante é usar a mesma API. Vc quer ter flexibilidade de mudar a linguagem e a VM. Hoje o java corre em muitos sistemas e inclusive dentro do .net. O que possibilita usar scala dentro do .net. Mas vc vai usar System.out ? Não dá. Tem que usar Console. E ai quebra a universalidade do seu sistema.

Se vc usa programa para uma API alvo e alguem garante que essa aPI vai funcionar em qualquer lugar, isso permite que vc crie seu aplicativo apenas uma vez. E apenas uma vez de verdade ( não como o java) porque o que vc vai fazer a seguir é mudar o compilador, não a linguagem. Ou seja, seus fontes são eternos e não importa que tecnologia vem a seguir. Para este tipo de maturidade, vc precisa de plataformas , não de linguagens. A linguagens é apenas um detalhes.

O que o artigo fala, e o que é a tendencia é a ciração de novas plataformas. Sim, ha criação de novas linguagens (que não são paltaformas, como groovy e scala) mas tb ha as que são. E a nova moda é implementar novas API em cima de velhas VM (aproveitando ou não a API padrão da VM, não importa porque o programador não vê).

ou seja, o interessante não é linguagem que vem com a plataforma (porque isso pode mudar, criar outra, etc… ) é a plataforma em si.

Ótimo texto. A linguagem se torna relevante somente para nós seres humanos como uma maneira de organizar e entender melhor um bloco de código. Para um computador o que interessa são instruções de processador e aí entra a qualidade da plataforma. Já programei com compiladores ruins de linguagem c e não importa a sua habilidade, o resultado que é o programa para processador x é um monte de instruções repetitivas de má qualidade. Se a plataforma é robusta, o resultado tende a ser robusto também.

juliocbq:

j-menezes:

juliocbq:

j-menezes:

Pelo visto tem gente aqui no forum que nunca teve problemas sérios com C++, são erros invisíveis
difícil de achar, ponteiros, sobrecarga, lixo de memória apis próprias de cada fabricante é uma coisa
de louco.

Ainda falando em apenas um SO, ainda que engana, o bicho pega quando se envolve mais plataformas.

Até onde testei o windows com toda aquela equipe de engenheiros e programadores bons, carrega erros
invisíveis que fogem a boa lógica, o mesmo aconteceu com o solaris antes do surgimento do java.

Falar que a jvm tem performance pior que c++ isso ai já é falta sujar as mãos de verdade. Existem
otimizações na jvm que deixam c++ comendo poeira.

Quanto a java ser boa pra desktop, pra mim é ótima, desenvolvi api pra facilitar o meu trabalho.

Quero lembrar que como muitos aqui também programo em c e c++, não basta a linguagem ter mais
recursos, tem que ser boa pra manutenção também e nisso java dá um show !!!.

Rapaz, eu trabalho a mais de dez anos com c++ e linguagem c e nunca sofri com leaks do jeito que você está apresentando. Olha que peguei c++ na época do c++95 em que não existia boa parte das ferramentas que fazem contagem de referência nem implementam um modelo de memória robusto com smart pointers como share_ptr etc. Isso aí não procede não.

Você deve ser um gênio. Até hoje não arrumaram o windows com esses erros que eu citei.

O kernel linux é todo escrito em c estruturado e assembly e não existem esses tipos de problemas porque é bem testado. O que existe é uma coisa chamada known how. Além do mais o modelo de memória de todos os windows (nt) utilizam uma máquina virtual(escrita em c++ com o compilador da intel) para proteger a área de memória dos programas, dessa maneira você não consegue acessar os registradores da cpu usando um programa que roda em nível de aplicação.

Acredite em mim, o windows possui uma arquitetura fantástica. Quem fala mal não tem noção disso.

Falar que dentro da jvm não dar pra enxergar a bios, aí já é d+ heim !!!. Eu to falando dentro da implementação da jvm e não da
limitação imposta por ela aos programas java.

Você já ouviu falar de Jnode e JavaOS ??

j-menezes:

juliocbq:

j-menezes:

juliocbq:

j-menezes:

Pelo visto tem gente aqui no forum que nunca teve problemas sérios com C++, são erros invisíveis
difícil de achar, ponteiros, sobrecarga, lixo de memória apis próprias de cada fabricante é uma coisa
de louco.

Ainda falando em apenas um SO, ainda que engana, o bicho pega quando se envolve mais plataformas.

Até onde testei o windows com toda aquela equipe de engenheiros e programadores bons, carrega erros
invisíveis que fogem a boa lógica, o mesmo aconteceu com o solaris antes do surgimento do java.

Falar que a jvm tem performance pior que c++ isso ai já é falta sujar as mãos de verdade. Existem
otimizações na jvm que deixam c++ comendo poeira.

Quanto a java ser boa pra desktop, pra mim é ótima, desenvolvi api pra facilitar o meu trabalho.

Quero lembrar que como muitos aqui também programo em c e c++, não basta a linguagem ter mais
recursos, tem que ser boa pra manutenção também e nisso java dá um show !!!.

Rapaz, eu trabalho a mais de dez anos com c++ e linguagem c e nunca sofri com leaks do jeito que você está apresentando. Olha que peguei c++ na época do c++95 em que não existia boa parte das ferramentas que fazem contagem de referência nem implementam um modelo de memória robusto com smart pointers como share_ptr etc. Isso aí não procede não.

Você deve ser um gênio. Até hoje não arrumaram o windows com esses erros que eu citei.

O kernel linux é todo escrito em c estruturado e assembly e não existem esses tipos de problemas porque é bem testado. O que existe é uma coisa chamada known how. Além do mais o modelo de memória de todos os windows (nt) utilizam uma máquina virtual(escrita em c++ com o compilador da intel) para proteger a área de memória dos programas, dessa maneira você não consegue acessar os registradores da cpu usando um programa que roda em nível de aplicação.

Acredite em mim, o windows possui uma arquitetura fantástica. Quem fala mal não tem noção disso.

Falar que dentro da jvm não dar pra enxergar a bios, aí já é d+ heim !!!. Eu to falando dentro da implementação da jvm e não da
limitação imposta por ela aos programas java.

Você já ouviu falar de Jnode e JavaOS ??

A jvm é programada em c. É claro que esse software poderia fazer isso, mas não pode e não faz porque ela foi desenvolvida para executar como uma aplicação. A jvm não roda a nível de kernel como a dalvik faz no android entendeu?

Android = VM + kernel
jvm = vm apenas.

ok?

Jnode e javaos são vms rodando em cima de um kernel escrito em assembly. O android faz isso com um kernel escrito em c e elém disso como plataforma o android está a anos luz de distância desses, que nem tem um escalonamento de processos decente.

juliocbq:

j-menezes:

juliocbq:

j-menezes:

juliocbq:

j-menezes:

Pelo visto tem gente aqui no forum que nunca teve problemas sérios com C++, são erros invisíveis
difícil de achar, ponteiros, sobrecarga, lixo de memória apis próprias de cada fabricante é uma coisa
de louco.

Ainda falando em apenas um SO, ainda que engana, o bicho pega quando se envolve mais plataformas.

Até onde testei o windows com toda aquela equipe de engenheiros e programadores bons, carrega erros
invisíveis que fogem a boa lógica, o mesmo aconteceu com o solaris antes do surgimento do java.

Falar que a jvm tem performance pior que c++ isso ai já é falta sujar as mãos de verdade. Existem
otimizações na jvm que deixam c++ comendo poeira.

Quanto a java ser boa pra desktop, pra mim é ótima, desenvolvi api pra facilitar o meu trabalho.

Quero lembrar que como muitos aqui também programo em c e c++, não basta a linguagem ter mais
recursos, tem que ser boa pra manutenção também e nisso java dá um show !!!.

Rapaz, eu trabalho a mais de dez anos com c++ e linguagem c e nunca sofri com leaks do jeito que você está apresentando. Olha que peguei c++ na época do c++95 em que não existia boa parte das ferramentas que fazem contagem de referência nem implementam um modelo de memória robusto com smart pointers como share_ptr etc. Isso aí não procede não.

Você deve ser um gênio. Até hoje não arrumaram o windows com esses erros que eu citei.

O kernel linux é todo escrito em c estruturado e assembly e não existem esses tipos de problemas porque é bem testado. O que existe é uma coisa chamada known how. Além do mais o modelo de memória de todos os windows (nt) utilizam uma máquina virtual(escrita em c++ com o compilador da intel) para proteger a área de memória dos programas, dessa maneira você não consegue acessar os registradores da cpu usando um programa que roda em nível de aplicação.

Acredite em mim, o windows possui uma arquitetura fantástica. Quem fala mal não tem noção disso.

Falar que dentro da jvm não dar pra enxergar a bios, aí já é d+ heim !!!. Eu to falando dentro da implementação da jvm e não da
limitação imposta por ela aos programas java.

Você já ouviu falar de Jnode e JavaOS ??

A jvm é programada em c. É claro que esse software poderia fazer isso, mas não pode e não faz porque ela foi desenvolvida para executar como uma aplicação. A jvm não roda a nível de kernel como a dalvik faz no android entendeu?

Android = VM + kernel
jvm = vm apenas.

ok?

Jnode e javaos são vms rodando em cima de um kernel escrito em assembly. O android faz isso com um kernel escrito em c e elém disso como plataforma o android está a anos luz de distância desses, que nem tem um escalonamento de processos decente.

Antes voce disse que jvm precisava de sistema operacional, agora voce concorda diz que pode rodar em cima de kernel, pois te digo novamente nem de kernel precisa.

O kernel é o “núcleo” sistema menezes e é ele que se comunica com o hardware. Jnode é uma tentativa de android com jvm (nem sei se é a oracle ou alguma coisa desenvolvida pela equipe deles). A oracle vm para arm embarcados é uma melhor solução que essa porque você pode instalá-la num kernel linux e se aproximar do que a “plataforma” android oferece com javafx. Para ficar igual precisa fazer a jvm rodar a nível de kernel porque a dalvik é concebida para conversar com o kernel. Por isso você tem acesso a:

1. sensores;
2. memória: física e vídeo com opengl es;
3. memória de massa: flash e hds

em suma é possível escrever desde gerenciadores de janelas inteiros(caso do launcher touchwiz da samsung), serviços e drivers com java em cima da dalvik.

Com a jvm isso não é possível porque ela não roda a nível de kernel. Não pode criar serviços, nem drivers, nem escrever numa placa aceleradora etc…

A java pode rodar como rm(real machine). Um processador que entende bytecode como o Sun Spot. Os celurares antigos usavam um micro otimizado para instruções java.

A jvm (virtual) não pode ser executada sem um sistema(o que é óbvio: win, linux, mac, symbian, etc…)

juliocbq:

j-menezes:

Antes voce disse que jvm precisava de sistema operacional, agora voce concorda diz que pode rodar em cima de kernel, pois te digo novamente nem de kernel precisa.

O kernel é o “núcleo” sistema menezes e é ele que se comunica com o hardware. Jnode é uma tentativa de android com jvm (nem sei se é a oracle ou alguma coisa desenvolvida pela equipe deles). A oracle vm para arm embarcados é uma melhor solução que essa porque você pode instalá-la num kernel linux e se aproximar do que a “plataforma” android oferece com javafx. Para ficar igual precisa fazer a jvm rodar a nível de kernel porque a dalvik é concebida para conversar com o kernel. Por isso você tem acesso a:

1. sensores;
2. memória: física e vídeo com opengl es;
3. memória de massa: flash e hds

em suma é possível escrever desde gerenciadores de janelas inteiros(caso do launcher touchwiz da samsung), serviços e drivers com java em cima da dalvik.

Com a jvm isso não é possível porque ela não roda a nível de kernel. Não pode criar serviços, nem drivers, nem escrever numa placa aceleradora etc…

A java pode rodar como rm(real machine). Um processador que entende bytecode como o Sun Spot. Os celurares antigos usavam um micro otimizado para instruções java.

A jvm (virtual) não pode ser executada sem um sistema(o que é óbvio: win, linux, mac, symbian, etc…)

Pode rodar embaixo de um sistema operacional, ou em um “arrancador” qualquer de maquina, como no caso do JNode, ou ainda num microcontrolador, eu me lembro do basic rodando no hard.

No entanto a “implementação da maquina virtual java” pode enxergar todo o hardware se desejar.

O que tem que se garantir é no final pra ser JVM, passar pelos testes de compatibilidade, padronização, segurança e etc da oracle.

Quanto a questão de fazer essas coisinhas do dalvik, basta a oracle mudar a politica do java, não tem nada tecnicamente que impeça
de fazer isso.

“Isso aí e’ coisa da sua cabeça.”

Cuidado com essas suas frases !!! , melhor você se dar ao luxo de ler primeiro o fonte do JNode pra depois opinar sobre isso.

Outra coisa, eu não disse que dalvik é igual jvm, o que eu disse é que uma “simples vm”, você não gostou !?, ah !!! puxa o cabelo,
das umas piroletas, isso passa ! ( rs ).

Cara, eu conheço o jnode e ele é um sistema operacional completo. Você não pode subir uma máquina virtual em cima de um sistema de boot porque ali não existe kernel(o boot sobe o kernel desse sistema e carrega o openjdk ou outra máquina virtual). Quem exerga o hardware é o kernel e todos os módulos(que são os drivers) são programas que rodam com privilégios de acessar suas bibliotecas.

O jnode é uma máquina virtual em cima de um kernel escrito em assembly: Ele é uma tentativa de sistema operacional escrito com java. Sugiro você reler as informações sobre ele, porque o que diz não remete o que está no site dele.

“Isso aí e’ coisa da sua cabeça.”

juliocbq:

j-menezes:

Pode rodar embaixo de um sistema operacional, ou em um “arrancador” qualquer de maquina, como no caso do JNode, ou ainda num microcontrolador, eu me lembro do basic rodando no hard.

No entanto a “implementação da maquina virtual java” pode enxergar todo o hardware se desejar.

O que tem que se garantir é no final pra ser JVM, passar pelos testes de compatibilidade, padronização, segurança e etc da oracle.

Quanto a questão de fazer essas coisinhas do dalvik, basta a oracle mudar a politica do java, não tem nada tecnicamente que impeça
de fazer isso.

“Isso aí e’ coisa da sua cabeça.”

Cuidado com essas suas frases !!! , melhor você se dar ao luxo de ler primeiro o fonte do JNode pra depois opinar sobre isso.

Outra coisa, eu não disse que dalvik é igual jvm, o que eu disse é que uma “simples vm”, você não gostou !?, ah !!! puxa o cabelo,
das umas piroletas, isso passa ! ( rs ).

Cara, eu conheço o jnode e ele é um sistema operacional completo. Você não pode subir uma máquina virtual em cima de um sistema de boot porque ali não existe kernel(o boot sobe o kernel desse sistema e carrega o openjdk ou outra máquina virtual). Quem exerga o hardware é o kernel e todos os módulos(que são os drivers) são programas que rodam com privilégios de acessar suas bibliotecas.

O jnode é uma máquina virtual em cima de um kernel escrito em assembly: Ele é uma tentativa de sistema operacional escrito com java. Sugiro você reler as informações sobre ele, porque o que diz não remete o que está no site dele.

“Isso aí e’ coisa da sua cabeça.”

Serve somente para você, porque eu só falo o que eu conheço.

http://pt.wikipedia.org/wiki/JNode

Veja que JNode fala em nano-kernel, realmente é um nano mesmo, somente interfaceia.

Pra ler frases, diagramas, você é bom, pra ler os fontes dos programas pelo visto… !!!

Leia os fontes e veja o quanto você está equivocado.

Se você tem tanta certeza que pode rodar uma aplicação que precisa de kernel sem um e que estou enganado, me prove então.

juliocbq:

j-menezes:

Veja que JNode fala em nano-kernel, realmente é um nano mesmo, somente interfaceia.

Pra ler frases, diagramas, você é bom, pra ler os fontes dos programas pelo visto… !!!

Leia os fontes e veja o quanto você está equivocado.

Se você tem tanta certeza que pode rodar uma aplicação que precisa de kernel sem um e que estou enganado, me prove então.

Se você tá querendo aula particular podemos ver isso pra alguma hora que eu esteja disponível.

j-menezes:

juliocbq:

j-menezes:

Veja que JNode fala em nano-kernel, realmente é um nano mesmo, somente interfaceia.

Pra ler frases, diagramas, você é bom, pra ler os fontes dos programas pelo visto… !!!

Leia os fontes e veja o quanto você está equivocado.

Se você tem tanta certeza que pode rodar uma aplicação que precisa de kernel sem um e que estou enganado, me prove então.

Se você tá querendo aula particular podemos ver isso pra alguma hora que eu esteja disponível.

Eu não preciso, mas já te dei várias de “sistemas operacionais” hoje. Porque agora tenho certeza de que você não sabe como funciona um.

juliocbq:

j-menezes:

juliocbq:

j-menezes:

Veja que JNode fala em nano-kernel, realmente é um nano mesmo, somente interfaceia.

Pra ler frases, diagramas, você é bom, pra ler os fontes dos programas pelo visto… !!!

Leia os fontes e veja o quanto você está equivocado.

Se você tem tanta certeza que pode rodar uma aplicação que precisa de kernel sem um e que estou enganado, me prove então.

Se você tá querendo aula particular podemos ver isso pra alguma hora que eu esteja disponível.

Eu não preciso, mas já te dei várias de “sistemas operacionais” hoje. Porque agora tenho certeza de que você não sabe como funciona um.

Pelo visto o que você precisa mesmo é uma de aula de leitura e entendimento.

Eu nao disse que sistemas operacionais não usam kernel, o que eu disse foi que pode se implementar uma jvm acessando o hardware diretamente sem passar pelo tal do “kernel”, logico que vai dar bem mais trabalho mas é possível.

Como dizia um gujuser “Corram para as montanhas!!”

Uso o sinônimo “De novo flores”

rs

É um bug do ser humano, toda discussão aqui acaba em demonstração de ego.
Camaradas, vamos manter o foco no assunto, sem ofensas ou ataques pessoais.
Todos vocês sabem muito, vamos respeitar a visão de cada um, defendendo, claro sua posiçao, mas sem ataques.
Tem outros membros que estão acompanhando o tópico, como eu, e que gostaria de aprender mais com a opinião de cada um.
Obrigado.

j-menezes

Eu nao disse que sistemas operacionais não usam kernel, o que eu disse foi que pode se implementar uma jvm acessando o hardware diretamente sem passar pelo tal do “kernel”, logico que vai dar bem mais trabalho mas é possível.

Com licença, mas tudo passa pelo kernel, ate mesmo a JVM.

A unica forma de voce implementar algo sem passar pelo kernel se chama microcontroladores, ou, CHIP.

rof20004:

j-menezes

Eu nao disse que sistemas operacionais não usam kernel, o que eu disse foi que pode se implementar uma jvm acessando o hardware diretamente sem passar pelo tal do “kernel”, logico que vai dar bem mais trabalho mas é possível.

Com licença, mas tudo passa pelo kernel, ate mesmo a JVM.

A unica forma de você implementar algo sem passar pelo kernel se chama microcontroladores, ou, CHIP.

O que ele quis dizer é que a vm poderia fazer parte do próprio kernel…

a jvm pode fazer parte de qualquer coisa, ate dentro de um microcontrolador, como é o caso dos celulares antigos que rodavam java nativamente a partir do hardware.

E era simplesmente isso que ele tinha falado, só bastava usar um pouco de bom senso para interpretar!

E era simplesmente isso que ele tinha falado, só bastava usar um pouco de bom senso para interpretar!

Em um forum, ou voce expoe ideias claras, ou fica no escuro, bom senso nao interpreta pensamentos.

Não existe “jvm” dentro de microcontrolador. Não é possível que alguém possa dizer uma coisa dessas. O que existe é uma jrm(java real machine que é um processador).

http://www.sunspotworld.com/

A jvm é um “emulador” desse processador. É uma aplicação. '-_-

E era simplesmente isso que ele tinha falado, só bastava usar um pouco de bom senso para interpretar!

O que é um conceito completamente errado também. Então está errado em dobro.

nofan:

rof20004:

j-menezes

Eu nao disse que sistemas operacionais não usam kernel, o que eu disse foi que pode se implementar uma jvm acessando o hardware diretamente sem passar pelo tal do “kernel”, logico que vai dar bem mais trabalho mas é possível.

Com licença, mas tudo passa pelo kernel, ate mesmo a JVM.

A unica forma de você implementar algo sem passar pelo kernel se chama microcontroladores, ou, CHIP.

O que ele quis dizer é que a vm poderia fazer parte do próprio kernel…

Não pode fazer parte do kernel. O kernel é o primeiro nível entre o seu hardware e o software. Junto com ele rodam os drivers, acima aplicações. O que o android fez foi possuir um kernel com toda uma api exposta para a sua máquina virtual.

A Oracle não pode fazer isso com a sua jvm porque não é dona de nenhum sistema operacional. (Win, linux, Macos). A google saiu na frente com isso.

Não existe “jvm” dentro de microcontrolador. Não é possível que alguém possa dizer uma coisa dessas. O que existe é uma jrm(java real machine que é um processador).

http://www.sunspotworld.com/

A jvm é um “emulador” desse processador. É uma aplicação. '-_-

Isso mesmo, nao lembrava o nome disso.

juliocbq:

nofan:

rof20004:

j-menezes

Eu nao disse que sistemas operacionais não usam kernel, o que eu disse foi que pode se implementar uma jvm acessando o hardware diretamente sem passar pelo tal do “kernel”, logico que vai dar bem mais trabalho mas é possível.

Com licença, mas tudo passa pelo kernel, ate mesmo a JVM.

A unica forma de você implementar algo sem passar pelo kernel se chama microcontroladores, ou, CHIP.

O que ele quis dizer é que a vm poderia fazer parte do próprio kernel…

Não pode fazer parte do kernel. O kernel é o primeiro nível entre o seu hardware e o software. Junto com ele rodam os drivers, acima aplicações. O que o android fez foi possuir um kernel com toda uma api exposta para a sua máquina virtual.

A Oracle não pode fazer isso com a sua jvm porque não é dona de nenhum sistema operacional. (Win, linux, Macos). A google saiu na frente com isso.

Errado, Oracle é dona do Solaris, baseado em Unix.

rof20004:

juliocbq:

nofan:

rof20004:

j-menezes

Eu nao disse que sistemas operacionais não usam kernel, o que eu disse foi que pode se implementar uma jvm acessando o hardware diretamente sem passar pelo tal do “kernel”, logico que vai dar bem mais trabalho mas é possível.

Com licença, mas tudo passa pelo kernel, ate mesmo a JVM.

A unica forma de você implementar algo sem passar pelo kernel se chama microcontroladores, ou, CHIP.

O que ele quis dizer é que a vm poderia fazer parte do próprio kernel…

Não pode fazer parte do kernel. O kernel é o primeiro nível entre o seu hardware e o software. Junto com ele rodam os drivers, acima aplicações. O que o android fez foi possuir um kernel com toda uma api exposta para a sua máquina virtual.

A Oracle não pode fazer isso com a sua jvm porque não é dona de nenhum sistema operacional. (Win, linux, Macos). A google saiu na frente com isso.

Errado, Oracle é dona do Solaris, baseado em Unix.

Tem razão, a oracle descontinuou foi a versão aberta dele. O OpenSolaris.

Olha, larguei do Java faz tempo, é muita gente usando e os salários caíram demais, um monte de gente sabe fazer um hello world em Java. Novos projetos na maioria hoje não começam mais em Java, e o TIOBE reflete bem a queda, vi lá o índice de Janeiro/2013 e não se recupera mais, está despencando.

Knowledgebr

knowledgebr:

Olha, larguei do Java faz tempo, é muita gente usando e os salários caíram demais, um monte de gente sabe fazer um hello world em Java. Novos projetos na maioria hoje não começam mais em Java, e o TIOBE reflete bem a queda, vi lá o índice de Janeiro/2013 e não se recupera mais, está despencando.

Knowledgebr