[quote=Longino][quote=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.[/quote]
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.[/quote]
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 !!!.
[quote=sergiotaborda][quote=Longino][quote=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.[/quote]
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.[/quote]
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. [/quote]
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.
[quote=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 !!!.
[/quote]
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.
[quote=juliocbq][quote=sergiotaborda][quote=Longino][quote=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.[/quote]
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.[/quote]
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. [/quote]
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.[/quote]
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 !!!
[quote=juliocbq][quote=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 !!!.
[/quote]
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.[/quote]
Você deve ser um gênio. Até hoje não arrumaram o windows com esses erros que eu citei.
[quote=giulianocosta][quote=sergiotaborda]
É que o titulo do topico é enganador. Não são novas linguagens , são novas plataformas que estão surgindo. [/quote]
Sergio, você não quis dizer o contrário? Novas linguagens surgiram mas não surgem novas plataformas?[/quote]
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).
[quote=j-menezes][quote=juliocbq][quote=sergiotaborda][quote=Longino][quote=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.[/quote]
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.[/quote]
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. [/quote]
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.[/quote]
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 !!!
[/quote]
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
[quote]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 !!![/quote]
É 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.
[quote=j-menezes][quote=juliocbq][quote=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 !!!.
[/quote]
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.[/quote]
Você deve ser um gênio. Até hoje não arrumaram o windows com esses erros que eu citei.
[/quote]
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.
[quote=sergiotaborda][quote=giulianocosta][quote=sergiotaborda]
É que o titulo do topico é enganador. Não são novas linguagens , são novas plataformas que estão surgindo. [/quote]
Sergio, você não quis dizer o contrário? Novas linguagens surgiram mas não surgem novas plataformas?[/quote]
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.[/quote]
Ó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.
[quote=juliocbq][quote=j-menezes][quote=juliocbq][quote=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 !!!.
[/quote]
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.[/quote]
Você deve ser um gênio. Até hoje não arrumaram o windows com esses erros que eu citei.
[/quote]
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.[/quote]
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.
[quote=j-menezes][quote=juliocbq][quote=j-menezes][quote=juliocbq][quote=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 !!!.
[/quote]
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.[/quote]
Você deve ser um gênio. Até hoje não arrumaram o windows com esses erros que eu citei.
[/quote]
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.[/quote]
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 ??
[/quote]
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.
[quote=juliocbq][quote=j-menezes][quote=juliocbq][quote=j-menezes][quote=juliocbq][quote=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 !!!.
[/quote]
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.[/quote]
Você deve ser um gênio. Até hoje não arrumaram o windows com esses erros que eu citei.
[/quote]
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.[/quote]
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 ??
[/quote]
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. [/quote]
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:
sensores;
memória: física e vídeo com opengl es;
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…)
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.
[/quote]
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:
sensores;
memória: física e vídeo com opengl es;
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…)[/quote]
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.
[quote]“Isso aí e’ coisa da sua cabeça.”[/quote] Serve somente para você, porque eu só falo o que eu conheço.
[quote=juliocbq][quote=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 ).
[/quote]
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.
[quote]“Isso aí e’ coisa da sua cabeça.”[/quote] Serve somente para você, porque eu só falo o que eu conheço.
