Instalando o Looking Glass - Desktop 3D da SUN
“'Se você nunca ouviu falar com certeza vai se surpreender ao ve-lo rodando. Desenvolvido pela Sun e utilizando linguagem Java, esse quebra todos os conceitos convencionais em termos de Desktop. Totalmente 3D o Looking Glass possui recursos muito interessantes como: transparência de janela, efeitos elegantes de maximização / minimização, plano de fundo animado, etc... Por exemplo, ao arrastar janelas para o canto da tela, elas ficam enfileiradas lado a lado como se fossem livros em uma estante. Os efeitos são realmente de surpreender, mas precisa de uma maquina relativamente potente para rodar todos os recursos sem problemas, também é necessário utilizar uma placa de vídeo com aceleração 3D como as Nvidia.'” A nota foi enviada por Andrei Drusian (drusianΘlinuxbsd·com·br), que acrescentou este link da fonte para maiores detalhes.(postado por Augusto Campos)
Comentários dos leitores
Comentário de Tango
06/06/06 10:35 - usuário registrado #43
Obsoleto: Pois é, eu já baixei uma vez um beta antigão, assim que ele começou a aparecer. Realmente impressionou e realmente é pesado.
Mas o XGL acabou por fazer o Looking Glass completamente obsoleto. Pode ser bonito e interesante, mas em termos de usabilidade ele ficou anos-luz atrás do XGL.
--
Este espaço está disponível para publicidade.
Mas o XGL acabou por fazer o Looking Glass completamente obsoleto. Pode ser bonito e interesante, mas em termos de usabilidade ele ficou anos-luz atrás do XGL.
--
Este espaço está disponível para publicidade.
Comentário de Fábio Rodrigues Ribeiro
06/06/06 11:18
Pesado não siginifica: Pesado não siginifica lerdo!
Não quero flamewar por causa disso... Ok!
Por mais que o java carregue alguns megas na memória o processamento das informações do java equivalente ou melhor que C/C++
Não tiro o mérito do C/C++ pois tenho em intenção de utilizar em alguns projetos com o wxWidgets!
Não quero flamewar por causa disso... Ok!
Por mais que o java carregue alguns megas na memória o processamento das informações do java equivalente ou melhor que C/C++
Não tiro o mérito do C/C++ pois tenho em intenção de utilizar em alguns projetos com o wxWidgets!
Comentário de simio
06/06/06 11:28 - usuário registrado #3386
não ?: Pesado não significa necessariamente lerdo mas com certeza é verdade que quanto mais aplicações pesadas maior a probabilidade do sistema inteiro ficar lerdo. Aliás, via de regra isso acontece.
E desculpe - se vc se basear no mesmo n?vel de programação , java não bate C++ e muito menos C.
E desculpe - se vc se basear no mesmo n?vel de programação , java não bate C++ e muito menos C.
Comentário de Java
06/06/06 15:27
Você que fede seu: Você que fede seu bosta.
Faça uma linguagem melhor e mais reaproveitavél.
Não que eu ame o java, mas é que odeio você! E pessoas que não tem o que falar e que nada fazem pela comunidade, só vem prá falar merda.
Porque você não coloca um disquete bomba no seu pc?
Assim se tivermos sorte vai derreter seu drive de disquete pegar fogo na sua torre na sua mesa, no seu carpete na sua casa e se tivermos muito mais sorte vai pegar fogo em você!!!
Seu baitola
Faça uma linguagem melhor e mais reaproveitavél.
Não que eu ame o java, mas é que odeio você! E pessoas que não tem o que falar e que nada fazem pela comunidade, só vem prá falar merda.
Porque você não coloca um disquete bomba no seu pc?
Assim se tivermos sorte vai derreter seu drive de disquete pegar fogo na sua torre na sua mesa, no seu carpete na sua casa e se tivermos muito mais sorte vai pegar fogo em você!!!
Seu baitola
Comentário de nemesis
06/06/06 15:48 - usuário registrado #1514
Java, a linguagem, fede. E: Java, a linguagem, fede. E o consumo de memória é deprimente.
Mas Java, a plataforma, autocontida e multiplataforma, é realmente bastante interessante. Até pq conta com uma das melhores VMs existentes.
e não, a performance não chega aos pés de C++, na prática. com compilação otimizada em tempo de execução ou não.
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Mas Java, a plataforma, autocontida e multiplataforma, é realmente bastante interessante. Até pq conta com uma das melhores VMs existentes.
e não, a performance não chega aos pés de C++, na prática. com compilação otimizada em tempo de execução ou não.
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de ricardomoc
06/06/06 16:18 - usuário registrado #440
Precisa mesmo?: Se não me engano, já tem uma distro que vem com o looking glass instalado.
Trata-se de um live cd, para quem tem curiosidade em experimentar. Parece que o nome é
algo como lg3d. O endereço é: https://lg3d.dev.java.net/. Já foi notícia aqui também.
http://www.danilobadaro.com
Trata-se de um live cd, para quem tem curiosidade em experimentar. Parece que o nome é
algo como lg3d. O endereço é: https://lg3d.dev.java.net/. Já foi notícia aqui também.
http://www.danilobadaro.com
Comentário de asd
06/06/06 16:54
2Gb!!! Cade GC???: Ferramenta certa para o lugar certo. E Iface grafica nao é lugar de Java (nao to nem ai o quanto isso ofende os desenvolvedores java, pq os verdadeiros desenvolvedores sao imparciais: http://www.artima.com/forums/flat.jsp?forum=276&thread=163017 ).
Isso é puro marketing da Sun pra mostrar cada vez mais o Java. Pra mostrar que pode estar em qualquer lugar.
Bem... se vc (qualquer um) acha que estão certos, vai la! Baixa e use! E os desafio a gostar!
("alguns megas na memoria" é muito bom!! Eu tenho aqui nos servers processos java com 2Gb!! E nao me venha falar que 'é questao de algoritmo (memo. din. alocada, libs, etc etc etc)' ... 2Gb é muito pra qualquer porcaria que o programa faça! (Sim, sou programador e pode baixar bem o nivel pra me justificar isso, se quiser))
CADE O GC NESSAS HORAS?!?! CADE James Gosling?!?!?!
E uma curiosidade, pq vc vai usar C/C++ com wxWidgets? Pq nao o proprio Java???
Isso é puro marketing da Sun pra mostrar cada vez mais o Java. Pra mostrar que pode estar em qualquer lugar.
Bem... se vc (qualquer um) acha que estão certos, vai la! Baixa e use! E os desafio a gostar!
("alguns megas na memoria" é muito bom!! Eu tenho aqui nos servers processos java com 2Gb!! E nao me venha falar que 'é questao de algoritmo (memo. din. alocada, libs, etc etc etc)' ... 2Gb é muito pra qualquer porcaria que o programa faça! (Sim, sou programador e pode baixar bem o nivel pra me justificar isso, se quiser))
CADE O GC NESSAS HORAS?!?! CADE James Gosling?!?!?!
E uma curiosidade, pq vc vai usar C/C++ com wxWidgets? Pq nao o proprio Java???
Comentário de nemesis
06/06/06 21:28 - usuário registrado #1514
hã?: "pq vc vai usar C/C++ com wxWidgets? Pq nao o proprio Java?"
talvez pq ele queira uma GUI portável como o Swing de java sem seus problemas de performance?
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
talvez pq ele queira uma GUI portável como o Swing de java sem seus problemas de performance?
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de nemesis
07/06/06 9:25 - usuário registrado #1514
a performance do java: a performance do java melhorou muito -- na mesma proporção em que o consumo de memória aumentou, aliás -- mas ainda não está no nível de C/C++/Haskell/OCaml e o Swing é obviamente bem mais lento para realizar operações gráficas do que via primitivas nativas.
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de marcosalex
07/06/06 13:09 - usuário registrado #250
A performance dos: A performance dos aplicativos Java sob uma máquina virtual nunca vai ser igual à aplicativos nativos. O mesmo vale pro .NET. Infelizmente, o consumo de memória e a performance é um dos obstáculos pro Java ganhar mais mercado.
Haskell developer
Haskell developer
Comentário de Copernico Vespucio
07/06/06 17:24 - usuário registrado #4868
Não me ofendo, mas...: Ferramenta certa para o lugar certo. E Iface grafica nao é lugar de Java
Vc. está enganado. Pesquise um pouco mais...
Bem... se vc (qualquer um) acha que estão certos, vai la! Baixa e use! E os desafio a gostar!
Eu tenho a distro com o Looking Glass pré-instalado (bem mais fácil que fazer tudo na mão) em uma partição, uso no dia a dia e gosto bastante (ainda faltam resolver algumas questões de usabilidade - que nada tem a ver com Java - para a UI ficar perfeita, mas o caminho é esse mesmo). Só não gosto mais pq não sou muito chegado ao "modo Make de ser" do Slax (distro na qual o CD é baseado).
Vc. sabia que existem jogos 3D em Java com alta performance? Eu mesmo faço um excelente curso de Java 3D na Unidev (http://www.unidev.com.br/curso/calendario.asp) e já consegui resultados bastante animadores.
O curso fala de Java3D, uma API de alto nível para construção de cenas e animações. Mas para obter ainda mais "intimidade" com as primitivas das placas de vídeo, já está se falando na comunidade da JOGL, uma API de nivel mais baixo para conseguir efeitos mais impressionantes ainda!
Eu tenho aqui nos servers processos java com 2Gb!!
Esses "processos" Java não seriam de servidores de aplicações distribuídas que são, em si mesmos, sistemas ambiciosos, exigentes de recursos e, por isso, pesados?
Já prestei serviço em uma das maiores empresas de telefonia celular do país (não digo qual, sem marketing aqui), que possui um portal nacional de atendimento ao cliente controlado por uma única central de servidores em cluster. Só na região sul do país, este servidor de aplicações segura cerca de 1.5 a 3 milhões de solicitações assíncronas por dia (entre as quais processos pesados como digitalização de espelhos de conta e acessos ao billing). Para isso, ele é obviamente um sistema exigente, consumindo justificadamente algo entre 1 a 2 Gb.
E o sistema funciona muito bem.
Java não é vaporware. Não é propaganda. Tem sucesso no mercado corporativo justificadamente, oferecendo vantagens reais.
CADE O GC NESSAS HORAS?
O compilador JIT (Just In Time: Compilador em Tempo de Execução) no modo server é capaz de executar além da coleta de lixo generacional, a desfragmentação do heap de forma a permitir que a GC colete apenas o necessário sem levar tempo demais nessa tarefa (em um sistema distribuído em um servidor, a responsividade é considerada mais importante que o consumo de memória). Não obstante, a memória reservada para o heap continua sendo mantida alta, para economizar o tempo de alocação, caso seja necessário.
É claro que, rodando o modo client do JIT (no seu desktop) a coisa muda radicalmente de figura. Tenta-se conseguir um equilibrio entre o consumo de recursos e a responsividade.
Frequentemente administradores de sistema podem ter resultados inferiores ao esperado utilizando o modo client do JIT ao invés do modo server, sem saber.
Existe também uma especificação de JVM de alto desempenho, sem as "paradas" para coleta de lixo... Procure no Google por "Real Time JVM Especification". Esse tipo de VM é própria para sistemas que exijam reações rápidas, como sistemas de suporte de vida, piloto automático e controle de vôo, por exemplo.
CADE James Gosling?!?!?!
No exato momento em que escrevo, deve estar terminando um dia de trabalho particularmente divertido na empresa em que trabalha, regiamente bem pago e escrevendo algo em seu blog, comemorando os mais de 10 anos de sucesso da plataforma cuja a equipe de desenvolvimento teve a oportunidade de chefiar. Pq?
Não me interprete mal. Sei que seu principal objetivo é denegrir a plataforma Java e já não tenho mais a intenção de provocar enormes flames na tentativa de te atrapalhar (já fiz muito disso por aqui, agora chega). Minha intenção foi apenas responder às suas perguntas.
[]s
Vc. está enganado. Pesquise um pouco mais...
Bem... se vc (qualquer um) acha que estão certos, vai la! Baixa e use! E os desafio a gostar!
Eu tenho a distro com o Looking Glass pré-instalado (bem mais fácil que fazer tudo na mão) em uma partição, uso no dia a dia e gosto bastante (ainda faltam resolver algumas questões de usabilidade - que nada tem a ver com Java - para a UI ficar perfeita, mas o caminho é esse mesmo). Só não gosto mais pq não sou muito chegado ao "modo Make de ser" do Slax (distro na qual o CD é baseado).
Vc. sabia que existem jogos 3D em Java com alta performance? Eu mesmo faço um excelente curso de Java 3D na Unidev (http://www.unidev.com.br/curso/calendario.asp) e já consegui resultados bastante animadores.
O curso fala de Java3D, uma API de alto nível para construção de cenas e animações. Mas para obter ainda mais "intimidade" com as primitivas das placas de vídeo, já está se falando na comunidade da JOGL, uma API de nivel mais baixo para conseguir efeitos mais impressionantes ainda!
Eu tenho aqui nos servers processos java com 2Gb!!
Esses "processos" Java não seriam de servidores de aplicações distribuídas que são, em si mesmos, sistemas ambiciosos, exigentes de recursos e, por isso, pesados?
Já prestei serviço em uma das maiores empresas de telefonia celular do país (não digo qual, sem marketing aqui), que possui um portal nacional de atendimento ao cliente controlado por uma única central de servidores em cluster. Só na região sul do país, este servidor de aplicações segura cerca de 1.5 a 3 milhões de solicitações assíncronas por dia (entre as quais processos pesados como digitalização de espelhos de conta e acessos ao billing). Para isso, ele é obviamente um sistema exigente, consumindo justificadamente algo entre 1 a 2 Gb.
E o sistema funciona muito bem.
Java não é vaporware. Não é propaganda. Tem sucesso no mercado corporativo justificadamente, oferecendo vantagens reais.
CADE O GC NESSAS HORAS?
O compilador JIT (Just In Time: Compilador em Tempo de Execução) no modo server é capaz de executar além da coleta de lixo generacional, a desfragmentação do heap de forma a permitir que a GC colete apenas o necessário sem levar tempo demais nessa tarefa (em um sistema distribuído em um servidor, a responsividade é considerada mais importante que o consumo de memória). Não obstante, a memória reservada para o heap continua sendo mantida alta, para economizar o tempo de alocação, caso seja necessário.
É claro que, rodando o modo client do JIT (no seu desktop) a coisa muda radicalmente de figura. Tenta-se conseguir um equilibrio entre o consumo de recursos e a responsividade.
Frequentemente administradores de sistema podem ter resultados inferiores ao esperado utilizando o modo client do JIT ao invés do modo server, sem saber.
Existe também uma especificação de JVM de alto desempenho, sem as "paradas" para coleta de lixo... Procure no Google por "Real Time JVM Especification". Esse tipo de VM é própria para sistemas que exijam reações rápidas, como sistemas de suporte de vida, piloto automático e controle de vôo, por exemplo.
CADE James Gosling?!?!?!
No exato momento em que escrevo, deve estar terminando um dia de trabalho particularmente divertido na empresa em que trabalha, regiamente bem pago e escrevendo algo em seu blog, comemorando os mais de 10 anos de sucesso da plataforma cuja a equipe de desenvolvimento teve a oportunidade de chefiar. Pq?
Não me interprete mal. Sei que seu principal objetivo é denegrir a plataforma Java e já não tenho mais a intenção de provocar enormes flames na tentativa de te atrapalhar (já fiz muito disso por aqui, agora chega). Minha intenção foi apenas responder às suas perguntas.
[]s
Comentário de asd
07/06/06 22:04
"Vc. está enganado.: "Vc. está enganado. Pesquise um pouco mais..."
Nao, nao estou. Leia o link que fiz post.
"já está se falando na comunidade da JOGL"
Falar. Isso que programador Java mais faz. Quando tiverem algo concreto como a OpenGL ai vcs vao estar contentes??
"...digitalização de espelhos de conta e acessos ao billing"
Conhecidencia!! Tb fiz um projeto de CoBilling (cobranca conjunta) e troca de cadastro de uma operadora de SP: extraia 2,5M de clientes (endereco, etc etc etc) em 1,7 dia. A Telefonica leva 3 dias para a mesma quantidade! Desenhei um processo proprio de alocacao de memoria dinamica sob demanda sequencial para o projeto com sincronizacao para o arquivo final (esta vendo pq amamos C/C++??? pq podemos fazer coisas como essa SEM CUSTO EXTRA!). Aaah... era para HPUX, mas compilava no windows!! ISSO é portabilidade! O resto é ABSTRACAO!!! E abstracao tem um custo!
O processo Java de 2Gb gera(va) as faturas em PDF para os clientes... onde ta a complexidade?
"O compilador JIT..."
Bla bla bla...
Opa...! Vc disse compilador?? E desde quando javanes conhece compiladores?? To vendo que logo logo vcs estarao trocando a JVM por compiladores (JIT)? Já reparou como vcs ficam exitadinhos quando falam em JIT?? ehehhehehehehe
"Tenta-se conseguir um equilibrio entre o consumo de recursos e a responsividade"
Estamos no aguardo...
"Real Time JVM Especification... VM é própria para sistemas que exijam reações rápidas, como sistemas de suporte de vida, piloto automático e controle de vôo"
Se usar o computador, nao beba! Se beber, nao use o computador!
Vc sabe o que classifica um RTOS?
Vc, pelo menos, imagina como é o processo de desenvolvimento de um software de 'suporte de vida' ou 'controle de voo'? O padrao de qualidade/requisito para esses projetos nao sao definidos na esquina e nem desenvolvidos por estudantes de faculdade/estagiarios.
"...oportunidade de chefiar. Pq?"
Pq depois de 10 anos vcs ainda nao substituiram C/C++, como o marketing escroto de Jonathan Schwartz tenta fazer. Os motivos vc mesmo cita no seu post.
E sobre o ultimo paragrafo:
Sim, meu objetivo é denegrir a plataforma Java pq eu ainda estou esperando o dia que programadores Javas iram calar a minha boca... Fazer-me morder a lingua. Mostrar algo realmente melhor que ninguem ainda tenha feito. Algo que a soma da inovacao com a qualidade seja excepcional, nao excludentes. Bla bla bla's e 'mochilinhas' estampadas o simbolo da Sun já nao me impressionam mais.
[]s
Nao, nao estou. Leia o link que fiz post.
"já está se falando na comunidade da JOGL"
Falar. Isso que programador Java mais faz. Quando tiverem algo concreto como a OpenGL ai vcs vao estar contentes??
"...digitalização de espelhos de conta e acessos ao billing"
Conhecidencia!! Tb fiz um projeto de CoBilling (cobranca conjunta) e troca de cadastro de uma operadora de SP: extraia 2,5M de clientes (endereco, etc etc etc) em 1,7 dia. A Telefonica leva 3 dias para a mesma quantidade! Desenhei um processo proprio de alocacao de memoria dinamica sob demanda sequencial para o projeto com sincronizacao para o arquivo final (esta vendo pq amamos C/C++??? pq podemos fazer coisas como essa SEM CUSTO EXTRA!). Aaah... era para HPUX, mas compilava no windows!! ISSO é portabilidade! O resto é ABSTRACAO!!! E abstracao tem um custo!
O processo Java de 2Gb gera(va) as faturas em PDF para os clientes... onde ta a complexidade?
"O compilador JIT..."
Bla bla bla...
Opa...! Vc disse compilador?? E desde quando javanes conhece compiladores?? To vendo que logo logo vcs estarao trocando a JVM por compiladores (JIT)? Já reparou como vcs ficam exitadinhos quando falam em JIT?? ehehhehehehehe
"Tenta-se conseguir um equilibrio entre o consumo de recursos e a responsividade"
Estamos no aguardo...
"Real Time JVM Especification... VM é própria para sistemas que exijam reações rápidas, como sistemas de suporte de vida, piloto automático e controle de vôo"
Se usar o computador, nao beba! Se beber, nao use o computador!
Vc sabe o que classifica um RTOS?
Vc, pelo menos, imagina como é o processo de desenvolvimento de um software de 'suporte de vida' ou 'controle de voo'? O padrao de qualidade/requisito para esses projetos nao sao definidos na esquina e nem desenvolvidos por estudantes de faculdade/estagiarios.
"...oportunidade de chefiar. Pq?"
Pq depois de 10 anos vcs ainda nao substituiram C/C++, como o marketing escroto de Jonathan Schwartz tenta fazer. Os motivos vc mesmo cita no seu post.
E sobre o ultimo paragrafo:
Sim, meu objetivo é denegrir a plataforma Java pq eu ainda estou esperando o dia que programadores Javas iram calar a minha boca... Fazer-me morder a lingua. Mostrar algo realmente melhor que ninguem ainda tenha feito. Algo que a soma da inovacao com a qualidade seja excepcional, nao excludentes. Bla bla bla's e 'mochilinhas' estampadas o simbolo da Sun já nao me impressionam mais.
[]s
Comentário de Copernico Vespucio
09/06/06 13:10 - usuário registrado #4868
não, não estou enganado: Infelizmente não estou enganado a seu respeito.
É mais um programador C++ magoado com o mercado que programadores Java tiraram de vcs.
Mais alguém que não tem conhecimento da plataforma mas acha que pode tecer críticas destrutivas.
Prefiro vc, Nêmesis, como "oponente". Tu é um pentelho, mas costuma ao menos saber o que está falando.
Ao contrário de vc, vou fazer o possível para responder a seus questionamentos sem procurar ofender vc. ou à sua tecnologia.
Vamos lá, "Dom Quixote":
Quando tiverem algo concreto como a OpenGL ai vcs vao estar contentes??
Fundamentalmente, JOGL é tão somente uma API que permite integrar diretamente os recursos OpenGL em aplicativos Java. Portanto, ela é tão "concreta" quanto, essa plataforma.
Falar. Isso que programador Java mais faz.
Sim, nós nos comunicamos em linguagem Java e código aberto :-)
https://jogl.dev.java.net/
Quando um conceito é proposto pela comunidade (JSR), não recebe aprovação final sem uma implementação de referência (RI). Vc. sabia disso, não?
processo proprio de alocacao de memoria dinamica sob demanda sequencial para o projeto com sincronizacao para o arquivo final
Que possivelmente vai forçar a realização de manutenções caras a qualquer mudança de maquinário ou sistema operacional, como tipicamente ocorre em sistemas com alocação de memória manual.
Aaah... era para HPUX, mas compilava no windows!!
A rigor, a tarefa de transformar um código fonte textual para um arquivo binário de acordo com as regras de uma linguagem está ao alcance de qualquer computador com qualquer SO. Se o programa for simples o suficiente posso compilar até mesmo "na mão", usando BNF, tabelas de conversão, lápis e papel. Se o Windows não conseguir fazer isso, migre pro Linux, rápido!
Compila no Windows, mas roda no Windows? Se não rodar, não é portável, simples assim.
O processo Java de 2Gb gera(va) as faturas em PDF para os clientes... onde ta a complexidade?
Para responder sua pergunta, preciso fazer algumas outras às quais talvez vc. não tenha se dado conta:
Para quantos clientes simultâneos? Qual a política de recuperação de falhas? Qual a disponibilidade do sistema? De onde vinham os dados? O sistema é escalável? O sistema sofreu profiling antes de ir para a produção? Houve uma análise da arquitetura da solução ou ele é (era?) só um brinquedo?
O mundo real é bem mais exigente que o mundo ideal dos requesitos funcionais.
O sistema de faturamento que citei aparentemente faz bem mais que isso (por questões de ética profissional não posso detalhar o processo aqui) com bem menos recursos do que vc. citou. Então o "seu" sistema deve nma verdade fazer bem mais que o "meu" ou existe algum problema (possivelmente localizado entre alguma cadeira e algum teclado) na sua organização...
Opa...! Vc disse compilador?? E desde quando javanes conhece compiladores?? To vendo que logo logo vcs estarao trocando a JVM por compiladores (JIT)?
Sim, disse compilador. Nós os conhecemos desde o momento em que lidamos com eles diariamente e a maioria dos projetos de pesquisa acadêmicos contam com compiladores escritos em Java. Em relação a JIT e JVM, o JIT não substitui a JVM e sim faz parte dela desde a versão 1.2. Vejo que vc. não sabe nada a respeito desse processo. Google de novo? Ou então uma visita à sua Universidade. VMs e compiladores em tempo de execução são assunto acadêmico "quente" hoje em dia. Não apenas para Java.
Vc sabe o que classifica um RTOS?
Sim, sei. Leia a especificação que indiquei.
Vc, pelo menos, imagina como é o processo de desenvolvimento de um software de 'suporte de vida' ou 'controle de voo'? O padrao de qualidade/requisito para esses projetos nao sao definidos na esquina e nem desenvolvidos por estudantes de faculdade/estagiarios.
Sim, "imagino" (rs*). Concordo em relação aos requesitos de qualidade e não, vc. não está falando com um estagiário.
Pq depois de 10 anos vcs ainda nao substituiram C/C++
Engraçado... Eu tenho quase certeza de que preciso procurar com uma lente de aumento e uma pinça por projetos corporativos decentes que não sejam feitos em Java ou (argh!) .NET. Não creio que seja necessário (basta olhar em volta), mas uma consulta ao Gartner pode resolver a questão.
Se vc. estiver falando de projetos de código aberto disponíveis, talvez deva dar uma olhada na curva do sourceforge e do freshmeat.
eu ainda estou esperando o dia que programadores Javas iram calar a minha boca...
Fundamentalmente, vc. pode falar o que quiser, verdade ou não. A única forma de fazer alguém "calar a boca" é com um esparadrapo ou uma pistola, e isso não é democrático nem ético.
Fazer-me morder a lingua. Mostrar algo realmente melhor que ninguem ainda tenha feito
Com os olhos fechados, fica difícil de ver, certo? :-]
Seus protestos foram registrados. Vc. tem o direito à sua opinião (ainda que com um embasamento tão fraco, ao menos foi a impressão que vc. me deu).
Mas se tiver algum dado realmente construtivo a acrescentar, acho que todos nós podemos ganhar com isso, divida com a gente! :)
É mais um programador C++ magoado com o mercado que programadores Java tiraram de vcs.
Mais alguém que não tem conhecimento da plataforma mas acha que pode tecer críticas destrutivas.
Prefiro vc, Nêmesis, como "oponente". Tu é um pentelho, mas costuma ao menos saber o que está falando.
Ao contrário de vc, vou fazer o possível para responder a seus questionamentos sem procurar ofender vc. ou à sua tecnologia.
Vamos lá, "Dom Quixote":
Quando tiverem algo concreto como a OpenGL ai vcs vao estar contentes??
Fundamentalmente, JOGL é tão somente uma API que permite integrar diretamente os recursos OpenGL em aplicativos Java. Portanto, ela é tão "concreta" quanto, essa plataforma.
Falar. Isso que programador Java mais faz.
Sim, nós nos comunicamos em linguagem Java e código aberto :-)
https://jogl.dev.java.net/
Quando um conceito é proposto pela comunidade (JSR), não recebe aprovação final sem uma implementação de referência (RI). Vc. sabia disso, não?
processo proprio de alocacao de memoria dinamica sob demanda sequencial para o projeto com sincronizacao para o arquivo final
Que possivelmente vai forçar a realização de manutenções caras a qualquer mudança de maquinário ou sistema operacional, como tipicamente ocorre em sistemas com alocação de memória manual.
Aaah... era para HPUX, mas compilava no windows!!
A rigor, a tarefa de transformar um código fonte textual para um arquivo binário de acordo com as regras de uma linguagem está ao alcance de qualquer computador com qualquer SO. Se o programa for simples o suficiente posso compilar até mesmo "na mão", usando BNF, tabelas de conversão, lápis e papel. Se o Windows não conseguir fazer isso, migre pro Linux, rápido!
Compila no Windows, mas roda no Windows? Se não rodar, não é portável, simples assim.
O processo Java de 2Gb gera(va) as faturas em PDF para os clientes... onde ta a complexidade?
Para responder sua pergunta, preciso fazer algumas outras às quais talvez vc. não tenha se dado conta:
Para quantos clientes simultâneos? Qual a política de recuperação de falhas? Qual a disponibilidade do sistema? De onde vinham os dados? O sistema é escalável? O sistema sofreu profiling antes de ir para a produção? Houve uma análise da arquitetura da solução ou ele é (era?) só um brinquedo?
O mundo real é bem mais exigente que o mundo ideal dos requesitos funcionais.
O sistema de faturamento que citei aparentemente faz bem mais que isso (por questões de ética profissional não posso detalhar o processo aqui) com bem menos recursos do que vc. citou. Então o "seu" sistema deve nma verdade fazer bem mais que o "meu" ou existe algum problema (possivelmente localizado entre alguma cadeira e algum teclado) na sua organização...
Opa...! Vc disse compilador?? E desde quando javanes conhece compiladores?? To vendo que logo logo vcs estarao trocando a JVM por compiladores (JIT)?
Sim, disse compilador. Nós os conhecemos desde o momento em que lidamos com eles diariamente e a maioria dos projetos de pesquisa acadêmicos contam com compiladores escritos em Java. Em relação a JIT e JVM, o JIT não substitui a JVM e sim faz parte dela desde a versão 1.2. Vejo que vc. não sabe nada a respeito desse processo. Google de novo? Ou então uma visita à sua Universidade. VMs e compiladores em tempo de execução são assunto acadêmico "quente" hoje em dia. Não apenas para Java.
Vc sabe o que classifica um RTOS?
Sim, sei. Leia a especificação que indiquei.
Vc, pelo menos, imagina como é o processo de desenvolvimento de um software de 'suporte de vida' ou 'controle de voo'? O padrao de qualidade/requisito para esses projetos nao sao definidos na esquina e nem desenvolvidos por estudantes de faculdade/estagiarios.
Sim, "imagino" (rs*). Concordo em relação aos requesitos de qualidade e não, vc. não está falando com um estagiário.
Pq depois de 10 anos vcs ainda nao substituiram C/C++
Engraçado... Eu tenho quase certeza de que preciso procurar com uma lente de aumento e uma pinça por projetos corporativos decentes que não sejam feitos em Java ou (argh!) .NET. Não creio que seja necessário (basta olhar em volta), mas uma consulta ao Gartner pode resolver a questão.
Se vc. estiver falando de projetos de código aberto disponíveis, talvez deva dar uma olhada na curva do sourceforge e do freshmeat.
eu ainda estou esperando o dia que programadores Javas iram calar a minha boca...
Fundamentalmente, vc. pode falar o que quiser, verdade ou não. A única forma de fazer alguém "calar a boca" é com um esparadrapo ou uma pistola, e isso não é democrático nem ético.
Fazer-me morder a lingua. Mostrar algo realmente melhor que ninguem ainda tenha feito
Com os olhos fechados, fica difícil de ver, certo? :-]
Seus protestos foram registrados. Vc. tem o direito à sua opinião (ainda que com um embasamento tão fraco, ao menos foi a impressão que vc. me deu).
Mas se tiver algum dado realmente construtivo a acrescentar, acho que todos nós podemos ganhar com isso, divida com a gente! :)
Comentário de asd
09/06/06 19:17
Bem... ta bom, vi q vc TB é: Bem... ta bom, vi q vc TB é um bom pentelho, entao vou me dirigir as assuntos tecnicos (Sun Tzu diz: é uma boa peneira intimidar os inimigos moralmente antes do combate. Apenas os que realmente confiam no que acreditam seguem firmes na guerra. hehehehe.. ele nao disse nao!).
- Mercado de trabalho / OpenGL:
De forma alguma. Se eu fosse programador de Delphi talvez sim.
Vc sabe, de um ponto de vista global, o mundo da IT (industrias de processadores, ind. de embedded, ind. de perifericos, ind. de softwares, etc) depende MUITO mais de C/C++ do que de Java. Até mesmo o proprio Java depende MUITO de C/C++! Agora o inverso nem é possivel imaginar.
To certo ou to errado? (é o caso da OpenGL que vc me disse. Só se vc digitou erradamente 'integrar' no lugar de 'reescrever').
- Sobre a aprovacao RI e comunidade JSR:
Por ter uma corporacao que tem 'bala na agulha' por tras (Sun) e outras apoiando (IBM, ...), Java nao é tratada como "a casa da mae Juana". Neste ponto nao nego que sao bem organizados comparando-os com linguagens como Perl e outras (Perl6 é uma palhaçada).
Porem, pelo que ando conversando com programadores javaneses, eles dizem que os drafts e releases de documentos de especificacao sao tao volateis que fica dificil dizer o que vingará e o que não na versao futura da SDK.
Nós (C/C++) temos a IEEE. Vc sabia disso, nao? Conhece o IEEE?? Pra te ser sincero nem imagino o que seja JSR e RI!
- Portabilidade e alocacao de memoria do meu programa:
Se portabilidade é tao simples assim, entao qual é a razao da JVM? E todo programa em C/C++ é simples (me decepcione com muitos programas maravilhosos até ver o codigo e ver que eu estava entendendo! Sim! Quando peguei o codigo do linux pensei que ia ver a Hackerlandia pela jabela e coisas que nao ia compreender... tudo que vi foram CONCEITOS de programacao, mas programacao propriamente dita, nada de novo!)
E sim, funciona no windows sim! Temos uma padrao chamado ANSI que nos garante isso. E por cima, funcoes, como de rede, possuem a mesma assinatura do padrao POSIX no windows (graaaaaande tio Bill! hehehehe).
Deus do ceu! Escrever codigo portavel é mais facil do que se imagina!! Pela mor de Deus, a ultima coisa no mundo que irei acreditar é que sou inteligente o bastante para fazer codigos portaveis de forma matematicamente milagrosas!! Nao... nao... nao!! Acredite! Vc nao precisa de uma JVM para escrever codigo portavel!! Nao é só entre SO's nao! Entre hardwares! Isso é o que a Sun colocou na cabeça de vcs e vcs acreditaram!!
- Sobre o processo Java de 2Gb:
Bem, aqui estou analisando como um usuário que nao conhece o codigo fonte, mas sim o problema e o ambiente comprado (desde máquinas à programadores). O VIP da IT pagou por uma solucao frente ao problema, nao por explicoes mirabolantes de programadores. Como por exemplo o windows, nao temos o fonte, nao nos interessa se ele conta ate 10 de 10 ate 1 ou de 1 ate 10, mas vemos ele comer memoria e ficar lento. Logo, criticamos e usamos o linux!
Eu nao sei pra quantos clientes, threads, web-services foi planejado! Eu nao sei de dados tecnicos do projeto. Só sei que é uma equipe de 4 programadores javas que possuem Eclipse (com bons desktops) e uma porrada de ferramentas de desenvolvimento (incluindo as nao gratuitas! como controladores de versoes e IDEs para documentos UML a pedido/expecificacao deles!), possuem provas/certificacoes (que julgam as pessoas nao por conhecerem a sintax da linguagem, mas sim DESIGN PATTERNS! Porra! isso é maravilhoso!). E com tudo isso, apresentar uma porcaria nao é toleravel!!!
Mais uma vez: estou julgando como usuário que quer a solucao!! Nao quero saber (assim como o usuario final) se a repimboca-da-parafuseta de configuracao do JIT esta ligada ou nao! Eu tenho maquinas que custam +- uns $ 40K por node (sao 6 Sun! Eu disse SUN!), uma equipe de desenvolvimento que custa +- uns R$ 100K/mes (especulando que cada um ganhe R$25/hora! Que nao eh! É mais!). Nao posso admitir um resultado desse!! Se vc fosse o VIP da area da IT, o que vc faria para, PELO MENOS, ganhar um pouco mais de performance? a) trocava o hardware (que é novissimo!); b) carcava na equipe de desenvolvimento e mandava refazer (tempo e grana sao como grama num jardim...); c) carcava na equipe de desenvolvimento e contrataria programadores C/C++ para fazerem o trabalho pesado (hehehehe... pode riscar a ultima. Sei que vc nao a escolheria. Eu sim)
- Sobre o JIT e a JVM:
Uma forma muito simples de explicar algo muito complexo:
caso 1: Joao fala no ouvido de Maria que por sua fez TRADUZ 10% e fala no ouvido de Jose.
caso 2: Joao fala no ouvido de Jose na linguagem que Jose entende.
Substitua Joao por 'programa em execucao', Maria por 'tradutor' e Jose por 'instucao do processador'.
Sacou? Nao precisa de ter PhD. Esse é um tipico problema obvio, de simples entendimento, mas que a solucao é muito complexa!
Nao tem jeito! Vc pode ter 90% das suas instrucoes nativas geradas na sua compilacao Java (byte code), ainda nao vao ser 100%! E os 10% estao justamente em pontos criticos como I/O, tratamento de sockets, File System, acesso a DMAs, multimidia, etc etc etc. E nao to falando só de windows e linux que sao bem parecidos entre si nestes pontos, e sim de, digamos, windows, mainframe e embeddeds! Ditado do mundo de 'patterns' que vc ja deve ter ouvido: Nao há bala de prata! NAO HA BALA DE PRATA!!!
Java so vai ser mais rapido quando tiver 100% das instrucoes nativas E gerar o mesmo numero de instrucoes. Simples e obvio! Me explica como seria melhorada os processos 1 e 2 acima?? (e olha que nao to contando o GC, que sendo uma thread (peso), logicamente deve haver um sistema de lock_critical_area na memoria para poder fazer o 'trabalho sujo' que o programador nao vez)
- RTOS:
O estagiario q citei nao é vc. O que disse é que estes sistemas nao ficam na mao de estagiarios, nem as partes mais pentelhas de programacao. Sao feitos por engenheiros do inicio ao fim.
E sim, java um dia pode estar em embedded, quando for mais rapido do que a porrada na frente de um carro até a abertura completa do airbag. Ou quando for rapido o suficiente para um robo segurar uma veia vazando sangue que nem uma mangueira de bombeiro a 1000 Km do médico, com retardo por causa do GC!
O que quero dizer aqui é: Quem vai querer reinventar a roda, se arriscar, quando já existe tecnologias totalmente viáveis e CONFIAVEIS para fazer esse trabalho? Pq vcs nao focam em programação para, sei la, processadores quanticos (é serio!)!! Vcs tao reinventando a roda por pirraça! Vcs querem mostrar que podem fazer isso só por pirraça! Vao programar para circuitos organicos ou qualquer coisa assim! Olha quanto prestigio vcs podem ter!! Deixem nós, velhos programadores C/C++ (tenho 25 anos), fazendo o que fazemos a mais de 30 anos em paz! Nao sejam crianças pirracentas e usem o entusiasmo contidos em vcs, jovens, para desbravar novas fronteiras!!
- Compiladores:
Nao disse que a JIT substitui a JVM, mas vejo que num futuro irá, algo bem parecido com a JIT.
Enquanto vcs consideram Generics e resolucao de dados um assunto "quente", nos já usamos Templates e RTTI (Run Time Type Information) a anos. Esses assuntos nao sao 'quentes' nao... tão ai a muito tempo.
- Projetos de qualidade corporativos:
Nao ha ligacao entre linguagem utilizada vrs. qualidade de projeto, e sim programadores vrs. qualidade. Qualquer consulta relativo a isso é igual, em importancia, ao numero de borboletas da Etiopia vrs. capacitores azuis usados em micro-ondas!
A curva do sourceforge e freshmeat monstram java ate com uma pequena vantagem. Mas vc alguma vez viu qualquer outra linguagem com o marketing que Java teve??? Serio mesmo! O lema de 'escreva uma vez e rode onde quiser' de 1997/2000 foi um Bum nunca antes visto na historia da IT-Desenvolvimento. Nem a ideia de OO fez mais estardalhaço que isso.
Eu sou extremamente criterioso e critico. Apenas C/C++ e Perl (usado para processar textos, nao vi nada melhor até hoje!!) me realmente conquistaram, pois como disse, a soma da inovacao com a qualidade sao as melhores que eu ja vi no quesito "Linguagem de Programacao"!
Eu ainda estou sendo maleavel: como disse no meu post anterior, a ferramenta certa para o lugar certo, e IDE grafica nao é o lugar de Java. Sistema Operacional nao é o lugar de Java.
Sabe qual é o lugar que vcs deveriam estar se preocupando? Desktops!! Justamente esse, pois é ai que a portabilidade é extremamente requisitada! Mas no entanto vcs preferem perder tempo guerriando com programadores C/C++ em servidores! Onde a troca de maquinas/SO são rarissimos (quando ocorrem sao por falha de planejamento, nao se muda um Solaris ou um AIX prum Windows da bobeira... Pra Linux até vai la, pq é 98,9% parecido falando em nivel de programacao C/C++).
Olha... somos embrioes perto dos engenheiros da Oracle, perto dos programadores da Apache e da IBM. Se eles, que sao franco apoiadores da tecnologia Java nao mudaram seus produtos, pq nos somos diferentes? O que vimos que eles nao?? Oras, se java fosse mais rapido, a Oracle já teria reescrito o engine anos atras com esses conceitos que vc me disse!
É obvio que é questao de qualidade (ou algo mais): nós discutimos tecnologia por paixao, essas empresas por grana!! E elas nao estao dispostas a perder. Por favor, me explique esse paradigma: pq o engine da Oracle ainda é em C sendo ela uma das empresas que mais apoiam o Java?? Por que o CICS e o OS/400 da IBM é em C++?? O http da Apache? Mozila? Google e seu core?? MySQL e PostGre?? Sun HotSpot JVM em C++?? Sun Solaris??
Pra mim, tem carosso escondido nesse angu chamado Java... hehehehe...
O que vc viu que eles nao??
[]s
- Mercado de trabalho / OpenGL:
De forma alguma. Se eu fosse programador de Delphi talvez sim.
Vc sabe, de um ponto de vista global, o mundo da IT (industrias de processadores, ind. de embedded, ind. de perifericos, ind. de softwares, etc) depende MUITO mais de C/C++ do que de Java. Até mesmo o proprio Java depende MUITO de C/C++! Agora o inverso nem é possivel imaginar.
To certo ou to errado? (é o caso da OpenGL que vc me disse. Só se vc digitou erradamente 'integrar' no lugar de 'reescrever').
- Sobre a aprovacao RI e comunidade JSR:
Por ter uma corporacao que tem 'bala na agulha' por tras (Sun) e outras apoiando (IBM, ...), Java nao é tratada como "a casa da mae Juana". Neste ponto nao nego que sao bem organizados comparando-os com linguagens como Perl e outras (Perl6 é uma palhaçada).
Porem, pelo que ando conversando com programadores javaneses, eles dizem que os drafts e releases de documentos de especificacao sao tao volateis que fica dificil dizer o que vingará e o que não na versao futura da SDK.
Nós (C/C++) temos a IEEE. Vc sabia disso, nao? Conhece o IEEE?? Pra te ser sincero nem imagino o que seja JSR e RI!
- Portabilidade e alocacao de memoria do meu programa:
Se portabilidade é tao simples assim, entao qual é a razao da JVM? E todo programa em C/C++ é simples (me decepcione com muitos programas maravilhosos até ver o codigo e ver que eu estava entendendo! Sim! Quando peguei o codigo do linux pensei que ia ver a Hackerlandia pela jabela e coisas que nao ia compreender... tudo que vi foram CONCEITOS de programacao, mas programacao propriamente dita, nada de novo!)
E sim, funciona no windows sim! Temos uma padrao chamado ANSI que nos garante isso. E por cima, funcoes, como de rede, possuem a mesma assinatura do padrao POSIX no windows (graaaaaande tio Bill! hehehehe).
Deus do ceu! Escrever codigo portavel é mais facil do que se imagina!! Pela mor de Deus, a ultima coisa no mundo que irei acreditar é que sou inteligente o bastante para fazer codigos portaveis de forma matematicamente milagrosas!! Nao... nao... nao!! Acredite! Vc nao precisa de uma JVM para escrever codigo portavel!! Nao é só entre SO's nao! Entre hardwares! Isso é o que a Sun colocou na cabeça de vcs e vcs acreditaram!!
- Sobre o processo Java de 2Gb:
Bem, aqui estou analisando como um usuário que nao conhece o codigo fonte, mas sim o problema e o ambiente comprado (desde máquinas à programadores). O VIP da IT pagou por uma solucao frente ao problema, nao por explicoes mirabolantes de programadores. Como por exemplo o windows, nao temos o fonte, nao nos interessa se ele conta ate 10 de 10 ate 1 ou de 1 ate 10, mas vemos ele comer memoria e ficar lento. Logo, criticamos e usamos o linux!
Eu nao sei pra quantos clientes, threads, web-services foi planejado! Eu nao sei de dados tecnicos do projeto. Só sei que é uma equipe de 4 programadores javas que possuem Eclipse (com bons desktops) e uma porrada de ferramentas de desenvolvimento (incluindo as nao gratuitas! como controladores de versoes e IDEs para documentos UML a pedido/expecificacao deles!), possuem provas/certificacoes (que julgam as pessoas nao por conhecerem a sintax da linguagem, mas sim DESIGN PATTERNS! Porra! isso é maravilhoso!). E com tudo isso, apresentar uma porcaria nao é toleravel!!!
Mais uma vez: estou julgando como usuário que quer a solucao!! Nao quero saber (assim como o usuario final) se a repimboca-da-parafuseta de configuracao do JIT esta ligada ou nao! Eu tenho maquinas que custam +- uns $ 40K por node (sao 6 Sun! Eu disse SUN!), uma equipe de desenvolvimento que custa +- uns R$ 100K/mes (especulando que cada um ganhe R$25/hora! Que nao eh! É mais!). Nao posso admitir um resultado desse!! Se vc fosse o VIP da area da IT, o que vc faria para, PELO MENOS, ganhar um pouco mais de performance? a) trocava o hardware (que é novissimo!); b) carcava na equipe de desenvolvimento e mandava refazer (tempo e grana sao como grama num jardim...); c) carcava na equipe de desenvolvimento e contrataria programadores C/C++ para fazerem o trabalho pesado (hehehehe... pode riscar a ultima. Sei que vc nao a escolheria. Eu sim)
- Sobre o JIT e a JVM:
Uma forma muito simples de explicar algo muito complexo:
caso 1: Joao fala no ouvido de Maria que por sua fez TRADUZ 10% e fala no ouvido de Jose.
caso 2: Joao fala no ouvido de Jose na linguagem que Jose entende.
Substitua Joao por 'programa em execucao', Maria por 'tradutor' e Jose por 'instucao do processador'.
Sacou? Nao precisa de ter PhD. Esse é um tipico problema obvio, de simples entendimento, mas que a solucao é muito complexa!
Nao tem jeito! Vc pode ter 90% das suas instrucoes nativas geradas na sua compilacao Java (byte code), ainda nao vao ser 100%! E os 10% estao justamente em pontos criticos como I/O, tratamento de sockets, File System, acesso a DMAs, multimidia, etc etc etc. E nao to falando só de windows e linux que sao bem parecidos entre si nestes pontos, e sim de, digamos, windows, mainframe e embeddeds! Ditado do mundo de 'patterns' que vc ja deve ter ouvido: Nao há bala de prata! NAO HA BALA DE PRATA!!!
Java so vai ser mais rapido quando tiver 100% das instrucoes nativas E gerar o mesmo numero de instrucoes. Simples e obvio! Me explica como seria melhorada os processos 1 e 2 acima?? (e olha que nao to contando o GC, que sendo uma thread (peso), logicamente deve haver um sistema de lock_critical_area na memoria para poder fazer o 'trabalho sujo' que o programador nao vez)
- RTOS:
O estagiario q citei nao é vc. O que disse é que estes sistemas nao ficam na mao de estagiarios, nem as partes mais pentelhas de programacao. Sao feitos por engenheiros do inicio ao fim.
E sim, java um dia pode estar em embedded, quando for mais rapido do que a porrada na frente de um carro até a abertura completa do airbag. Ou quando for rapido o suficiente para um robo segurar uma veia vazando sangue que nem uma mangueira de bombeiro a 1000 Km do médico, com retardo por causa do GC!
O que quero dizer aqui é: Quem vai querer reinventar a roda, se arriscar, quando já existe tecnologias totalmente viáveis e CONFIAVEIS para fazer esse trabalho? Pq vcs nao focam em programação para, sei la, processadores quanticos (é serio!)!! Vcs tao reinventando a roda por pirraça! Vcs querem mostrar que podem fazer isso só por pirraça! Vao programar para circuitos organicos ou qualquer coisa assim! Olha quanto prestigio vcs podem ter!! Deixem nós, velhos programadores C/C++ (tenho 25 anos), fazendo o que fazemos a mais de 30 anos em paz! Nao sejam crianças pirracentas e usem o entusiasmo contidos em vcs, jovens, para desbravar novas fronteiras!!
- Compiladores:
Nao disse que a JIT substitui a JVM, mas vejo que num futuro irá, algo bem parecido com a JIT.
Enquanto vcs consideram Generics e resolucao de dados um assunto "quente", nos já usamos Templates e RTTI (Run Time Type Information) a anos. Esses assuntos nao sao 'quentes' nao... tão ai a muito tempo.
- Projetos de qualidade corporativos:
Nao ha ligacao entre linguagem utilizada vrs. qualidade de projeto, e sim programadores vrs. qualidade. Qualquer consulta relativo a isso é igual, em importancia, ao numero de borboletas da Etiopia vrs. capacitores azuis usados em micro-ondas!
A curva do sourceforge e freshmeat monstram java ate com uma pequena vantagem. Mas vc alguma vez viu qualquer outra linguagem com o marketing que Java teve??? Serio mesmo! O lema de 'escreva uma vez e rode onde quiser' de 1997/2000 foi um Bum nunca antes visto na historia da IT-Desenvolvimento. Nem a ideia de OO fez mais estardalhaço que isso.
Eu sou extremamente criterioso e critico. Apenas C/C++ e Perl (usado para processar textos, nao vi nada melhor até hoje!!) me realmente conquistaram, pois como disse, a soma da inovacao com a qualidade sao as melhores que eu ja vi no quesito "Linguagem de Programacao"!
Eu ainda estou sendo maleavel: como disse no meu post anterior, a ferramenta certa para o lugar certo, e IDE grafica nao é o lugar de Java. Sistema Operacional nao é o lugar de Java.
Sabe qual é o lugar que vcs deveriam estar se preocupando? Desktops!! Justamente esse, pois é ai que a portabilidade é extremamente requisitada! Mas no entanto vcs preferem perder tempo guerriando com programadores C/C++ em servidores! Onde a troca de maquinas/SO são rarissimos (quando ocorrem sao por falha de planejamento, nao se muda um Solaris ou um AIX prum Windows da bobeira... Pra Linux até vai la, pq é 98,9% parecido falando em nivel de programacao C/C++).
Olha... somos embrioes perto dos engenheiros da Oracle, perto dos programadores da Apache e da IBM. Se eles, que sao franco apoiadores da tecnologia Java nao mudaram seus produtos, pq nos somos diferentes? O que vimos que eles nao?? Oras, se java fosse mais rapido, a Oracle já teria reescrito o engine anos atras com esses conceitos que vc me disse!
É obvio que é questao de qualidade (ou algo mais): nós discutimos tecnologia por paixao, essas empresas por grana!! E elas nao estao dispostas a perder. Por favor, me explique esse paradigma: pq o engine da Oracle ainda é em C sendo ela uma das empresas que mais apoiam o Java?? Por que o CICS e o OS/400 da IBM é em C++?? O http da Apache? Mozila? Google e seu core?? MySQL e PostGre?? Sun HotSpot JVM em C++?? Sun Solaris??
Pra mim, tem carosso escondido nesse angu chamado Java... hehehehe...
O que vc viu que eles nao??
[]s
Comentário de Copernico Vespucio
09/06/06 21:53 - usuário registrado #4868
vamos pentelhar: Ok, vc. conseguiu me atrair ao campo. Mas seu post é longo, vou tentar resumir o máximo possível sem sacrificar pontos importantes.
Vc sabe, de um ponto de vista global, o mundo da IT (industrias de processadores, ind. de embedded, ind. de perifericos, ind. de softwares, etc) depende MUITO mais de C/C++ do que de Java. Até mesmo o proprio Java depende MUITO de C/C++! Agora o inverso nem é possivel imaginar.
É errado definir "mundo da IT" (eu uso TI, é mais nacionalista) por apenas "industrias de processadores, ind. de embedded, ind. de perifericos", etc. Porquê?
No geral, a indústria de infra-estrutura desenvolve artefatos cujo tempo de vida é muito maior que a orientada para o usuário final (e, portanto, pode suportar cronogramas "lentos" de desenvolvimento), tem baixa preocupação com compatibilidade e baixo ganho com generalidades.
Isso diverge completamente das necessidades da indústria orientada ao usuário final, onde mora 80% da grana que corre no setor. O tempo de vida dos sistemas é pequeno (limitando cronograma e custo), a tolerância a falhas não-sistêmicas é menor, a preocupação com a compatibilidade é enorme e tudo deve ser feito o mais configurável, portável e flexível possível.
Antes de continuarmos, preciso garantir que em momento nenhum ninguém quer dizer que Java substituiu completamente C++. Para dizer a verdade, na indústria de TI jamais realmente "aposentamos" uma tecnologia, por inúmeros motivos. Trabalho no mercado de telecom e convivemos pacificamente com Natural, COBOL, C/C++, etc.
Nos cenários onde o que importa é a manipulação nativa de dispositivos (drivers, etc) e onde não haja ganho na generalização, é mais que correto utilizar tecnologia nativa e de baixo nível (assembly, C, etc).
A abordagem na cultura java, aliás, é escrever a parte nativa em baixo nível como um componente (complexa, mas não muda muito depois de pronta) e criar uma interface Java de alto nível, mais fácil de manipular pelas camadas clientes, que exigem maior manutenibilidade. É o caso do Java3D, por exemplo e do JOGL, de nível um pouco mais baixo.
Entretanto, é verdade que no mercado corporativo para usuário final, Java tomou conta do cenário realmente, reduzindo os tempos de desenvolvimento, fornecendo um ambiente de execução estável onde detalhes de baixo nivel não são de responsabilidade dos programadores e, mesmo assim, oferecendo uma cultura que não se rende ao ideal Micro$oft de emburrecer o programador. Um desenvolvedor Java decente sabe o que acontece em baixo nível, embora não tenha de se envolver com isso todas as vezes.
O que não significa que isso elimine de uma vez por todas o mercado C/C++. Java apenas mostrou-se mais apta em um nicho no qual C era considerado a única alternativa viável.
Só pra fechar o caso da OpenGL:
é o caso da OpenGL que vc me disse. Só se vc digitou erradamente 'integrar' no lugar de 'reescrever'
"Integrar" está correto. A maior parte das primitivas das quais a OpenGL depende está implementada nas próprias placas de vídeo. Não haveria ganho em reescrever essas primitivas. Java 3D/JOGL apenas fornecem uma interface inteligente (código de infraestrutura) para funcionalidades de alto nível. Ao contrário da OpenGL "pura", Java3D fala de objetos, grafos, cenas, etc. E dentro de um contexto onde gerenciar desalocação de memória manual se torna desnecessário e problemas como falhas de sincronia são muito mais fáceis de evitar.
Agora o inverso nem é possivel imaginar!
Vc. sabia que muitas coisas boas disponpiveis hoje tb. para C++ (como a eficiente biblioteca pthreads, vc. já deve ter usado) foram inspiradas em soluções que foram desenvolvidas para a plataforma Java?
- Sobre a aprovacao RI e comunidade JSR:
Vejo que vc. tem muitas dúvidas nesse assunto. Vamos a elas:
Java é controlada por um consórcio, formado de pessoas físicas, jurídicas, corporações, ONGs, Governos, etc. chamado JCP (www.jcp.org). A Sun não é mais "a dona da bola" da tecnologia. Nem tampouco qualquer empresa investidora pode dizer o mesmo.
Tudo o que aparece em termos de novidade (as JSR: Java Specification Request) é especificado e votado em várias fases, até se chegar à RI (Reference Implementation).
Então o JCP não é um apenas um comitê normativo, como ocorre no caso do IEEE e até mesmo da ECMA (que come na mão da Micro$oft). É um processo de desenvolvimento de novas tecnologias que conta com sua própria infra-estrutura.
P.S.: Sim, conheço o IEEE. Se vc. ler a especificação da linguagem e da JVM verá que são seguidas muitas de suas normas (ex.: IEEE 754 trata das regras de precisão para numeros de ponto flutuante).
O JCP está aberto para afiliação. Pessoas Físicas se juntam a iniciativa gratuitamente, vc. mesmo pode fazer isso se quiser.
Há quem diga que esta é a verdadeira força da plataforma Java, mais que apenas suas características técnicas. Sua comunidade é extremamente ativa.
eles dizem que os drafts e releases de documentos de especificacao sao tao volateis que fica dificil dizer o que vingará e o que não na versao futura da SDK
A partir do momento em que uma JSR é aprovada e um draft é escrito, ela "vingará", de um jeito ou de outro. A especificação será refinada por várias fases e revisões até chegar a sua forma final (proposed final draft), nas quais detalhes poderão mudar (inclusive a data de liberação). A partir da construção da RI, a JSR passará a ser versionada e cada mudança deverá manter estrita compatibilidade retroativa com as versões anteriores.
Não necessariamente todas as JSR estarão refletidas em uma das distribuições principais (JSE, JEE, JMe), é muita coisa! Ao invés disso, as funcionalidades consideradas essenciais são incorporadas e as outras são distribuídas como opcionais. Exemplo: JMX (implementação do protocolo SNMP) foi considerada essencial para JSE sendo incorporada a partir da versão 5, mas coisas como JavaSpeech ou JUSB tem interesse periférico e estão disponíveis como produtos separados.
Se portabilidade é tao simples assim, entao qual é a razao da JVM
Vindo da história do Java:
"A equipe Green tinha o objetivo de criar um conjunto de macros portáteis em C++ para quaisquer dispositivos (inicialmente, Java seria apenas isso). Devido a inúmeros problemas e discrepâncias no isolamento de processos e alocação/desalocação de memória, perceberam a necessidade de uma camada de compatibilidade baseada em máquina virtual."
A tecnologia de VMs não é de forma alguma nova, sendo adotada em várias plataformas anteriores, como Smalltalk.
Se vc fosse o VIP da area da IT, o que vc faria para, PELO MENOS, ganhar um pouco mais de performance?
Com cronograma de apenas 1 mês adicional, contrataria um único profissional (arquiteto qualificado) para trabalhar com a mesma equipe original para corrigir os problemas de performance.
Em outra empresa de telecomunicações que servi, tivemos um exemplo. Um grande e importante sistema de aprovisionamento (mal) escrito em Java tinha um aproveitamento insuficiente para o crescimento da companhia (escalabilidade baixa). Claro que houveram pressões para reescrever tudo em C++ (sempre existe esse tipo de pressão... Eu acho divertido!).
Com um trabalho sério e orientado de menos de 2 meses, corrigimos gargalos e implementamos mais assincronia, obtendo uma melhoria de performance da ordem de 400% (superior às promessas da proposta de reescrita em C++). Não reescrevemos o sistema inteiro (grandes partes continuam mal-escritas... :-< ), mas o objetivo foi cumprido. Prevejo que na mudança da versão JSE 1.4 para JSE5 a performance deverá subir outros 25% a 30% "de graça", sem que uma única linha de código seja reescrita.
Sobre os JIT:
No caso médio, compiladores em tempo de execução podem ser até superiores à soluções de otimização manual. E explico o motivo de forma resumida:
Vc. nunca tentou otimizar um trecho de código só pra perceber que a emenda piorou o soneto? Isso ocorre pq em tempo de projeto é muito fácil fazer suposições incorretas sobre onde é o gargalo e como deve ser corrigido.
A prática moderna de desenvolvimento é inclusive escrever código sem tentar otimizar, fazer o profiling e detectar as áreas mais vitais (hotspots) e só então otimizar. Tornar 0,01ms mais rápido um trecho de código executado 5 vezes ao dia tem um retorno proximo de zero.
JIT se baseia no mesmo princípio. Ao invés de depender do programador para otimizar o código de baixo nível, ele realiza um profiling na aplicação (1a execução) e com base nesses resultados compila os hotspots necessários da melhor forma possível com base no cenário.
Enquanto vcs consideram Generics e resolucao de dados um assunto "quente"
Nós quem, cara pálida? Generics em Java é um assunto discutido (e tratado com cautela) desde 1998. É uma técnica servida fria, como a maioria das novidades na plataforma. Converse com seus colegas que programam em Java e verá, inclusive, que Generics não é realmente igual aos Templates de C++, possuindo alguns diferenciais importantes.
De forma parecida temos a "novidade" dos tipos enumerados. Em C++ os enum não são realmente Type-Safe, em Java sim.
E sim, java um dia pode estar em embedded, quando for mais rapido do que a porrada na frente de um carro até a abertura completa do airbag. Ou quando for rapido o suficiente para um robo segurar uma veia vazando sangue que nem uma mangueira de bombeiro a 1000 Km do médico, com retardo por causa do GC!
Lembro de um Java ONE onde James Gosling demonstrava uma JVM Real Time... Era uma plataforma leve que flutuava em uma cuba dágua tendo sobre ela um pêndulo que se movimentava sobre o controle da JVM, mantendo o equilibrio. Durante todo o evento, ele e os outros palestrantes davam frequentes "pescoções" no dispositivo, e o pêndulo sempre compensava imediatamente o golpe, mantendo a plataforma acima do nível da água sem deixar a parte de cima molhar. Isso é RTS. Pode abrir o seu air-bag a tempo ou pinçar a sua veia.
Mas vc alguma vez viu qualquer outra linguagem com o marketing que Java teve???
Sim, já vi. Ela até hoje tem o nome de C++. Quando estava em seu auge ela recebia apoio de gigantes como a Borland, a Sun (sim, a Sun!) e até mesmo a Microsoft! As pessoas estavam entusiasmadas com a portabilidade prometida e a possibilidade de programação orientada a objetos.
Outras línguas apareceram e foram embora apoiadas por nichos distintos no mercado. Apenas C++ tinha a unanimidade. Sim, sou mais velho que vc., tenho 34 anos, eu sei pq eu estava vivo na época. C/C++ era a minha linguagem "de coração", era a maneira correta de fazer as coisas. Mas ela tinha produtividade baixa para o mercado SOHO e eu passava muito tempo depurando bugs. Eu precisava produzir pra comer...
Mas no entanto vcs preferem perder tempo guerriando com programadores C/C++ em servidores!
Nosso primeiro e maior sucesso palpável no mercado.
Onde a troca de maquinas/SO são rarissimos (quando ocorrem sao por falha de planejamento, nao se muda um Solaris ou um AIX prum Windows da bobeira...
Mas onde a portabilidade permite que eu escreva e teste sistemas corporativos em desktops de mesa e/ou servidores modestos antes de passá-los para o poderoso servidor SPARC de produção.
pq o engine da Oracle ainda é em C sendo ela uma das empresas que mais apoiam o Java?? Por que o CICS e o OS/400 da IBM é em C++?? O http da Apache? Mozila? Google e seu core?? MySQL e PostGre?? Sun HotSpot JVM em C++?? Sun Solaris??
Pelo mesmo motivo pelo qual eu convivo todos os dias (e integro) com sistemas legados, escritos até em COBOL. Pq é estupidez reescrever um sistema já antigo, maduro, robusto e testado, gastando todo o investimento inicial novamente, por mais que vc. ache que encontrou uma língua/plataforma melhor. É a lei mais básica do mercado de software. Vc. não reescreve, vc. integra.
Java interfaceia com CICS, roda sob As/400, o "http" (vc. quer dizer o Apache Web Server) possui módulo de integração com servlet containers como o Jakarta Tomcat, o navegador Mozilla suporta plugins e skins escritos em Java, o Core do Google (uma colcha de retalhos) tem várias partes escritas em Java, existem drivers JDBC para todos os bancos (incluindo MySQL - ruim, existem RDBMS puro-Java melhores - e PostGrès), Sun Solaris é a plataforma mais integrada a Java que existe, etc.
Curiosidade: Se vc. acha que Java precisa de uma JVM escrita em outra linguagem como C++, dê uma pesquisada na Jikes RVM.
O que eu vejo que eles vêem também??
Vc sabe, de um ponto de vista global, o mundo da IT (industrias de processadores, ind. de embedded, ind. de perifericos, ind. de softwares, etc) depende MUITO mais de C/C++ do que de Java. Até mesmo o proprio Java depende MUITO de C/C++! Agora o inverso nem é possivel imaginar.
É errado definir "mundo da IT" (eu uso TI, é mais nacionalista) por apenas "industrias de processadores, ind. de embedded, ind. de perifericos", etc. Porquê?
No geral, a indústria de infra-estrutura desenvolve artefatos cujo tempo de vida é muito maior que a orientada para o usuário final (e, portanto, pode suportar cronogramas "lentos" de desenvolvimento), tem baixa preocupação com compatibilidade e baixo ganho com generalidades.
Isso diverge completamente das necessidades da indústria orientada ao usuário final, onde mora 80% da grana que corre no setor. O tempo de vida dos sistemas é pequeno (limitando cronograma e custo), a tolerância a falhas não-sistêmicas é menor, a preocupação com a compatibilidade é enorme e tudo deve ser feito o mais configurável, portável e flexível possível.
Antes de continuarmos, preciso garantir que em momento nenhum ninguém quer dizer que Java substituiu completamente C++. Para dizer a verdade, na indústria de TI jamais realmente "aposentamos" uma tecnologia, por inúmeros motivos. Trabalho no mercado de telecom e convivemos pacificamente com Natural, COBOL, C/C++, etc.
Nos cenários onde o que importa é a manipulação nativa de dispositivos (drivers, etc) e onde não haja ganho na generalização, é mais que correto utilizar tecnologia nativa e de baixo nível (assembly, C, etc).
A abordagem na cultura java, aliás, é escrever a parte nativa em baixo nível como um componente (complexa, mas não muda muito depois de pronta) e criar uma interface Java de alto nível, mais fácil de manipular pelas camadas clientes, que exigem maior manutenibilidade. É o caso do Java3D, por exemplo e do JOGL, de nível um pouco mais baixo.
Entretanto, é verdade que no mercado corporativo para usuário final, Java tomou conta do cenário realmente, reduzindo os tempos de desenvolvimento, fornecendo um ambiente de execução estável onde detalhes de baixo nivel não são de responsabilidade dos programadores e, mesmo assim, oferecendo uma cultura que não se rende ao ideal Micro$oft de emburrecer o programador. Um desenvolvedor Java decente sabe o que acontece em baixo nível, embora não tenha de se envolver com isso todas as vezes.
O que não significa que isso elimine de uma vez por todas o mercado C/C++. Java apenas mostrou-se mais apta em um nicho no qual C era considerado a única alternativa viável.
Só pra fechar o caso da OpenGL:
é o caso da OpenGL que vc me disse. Só se vc digitou erradamente 'integrar' no lugar de 'reescrever'
"Integrar" está correto. A maior parte das primitivas das quais a OpenGL depende está implementada nas próprias placas de vídeo. Não haveria ganho em reescrever essas primitivas. Java 3D/JOGL apenas fornecem uma interface inteligente (código de infraestrutura) para funcionalidades de alto nível. Ao contrário da OpenGL "pura", Java3D fala de objetos, grafos, cenas, etc. E dentro de um contexto onde gerenciar desalocação de memória manual se torna desnecessário e problemas como falhas de sincronia são muito mais fáceis de evitar.
Agora o inverso nem é possivel imaginar!
Vc. sabia que muitas coisas boas disponpiveis hoje tb. para C++ (como a eficiente biblioteca pthreads, vc. já deve ter usado) foram inspiradas em soluções que foram desenvolvidas para a plataforma Java?
- Sobre a aprovacao RI e comunidade JSR:
Vejo que vc. tem muitas dúvidas nesse assunto. Vamos a elas:
Java é controlada por um consórcio, formado de pessoas físicas, jurídicas, corporações, ONGs, Governos, etc. chamado JCP (www.jcp.org). A Sun não é mais "a dona da bola" da tecnologia. Nem tampouco qualquer empresa investidora pode dizer o mesmo.
Tudo o que aparece em termos de novidade (as JSR: Java Specification Request) é especificado e votado em várias fases, até se chegar à RI (Reference Implementation).
Então o JCP não é um apenas um comitê normativo, como ocorre no caso do IEEE e até mesmo da ECMA (que come na mão da Micro$oft). É um processo de desenvolvimento de novas tecnologias que conta com sua própria infra-estrutura.
P.S.: Sim, conheço o IEEE. Se vc. ler a especificação da linguagem e da JVM verá que são seguidas muitas de suas normas (ex.: IEEE 754 trata das regras de precisão para numeros de ponto flutuante).
O JCP está aberto para afiliação. Pessoas Físicas se juntam a iniciativa gratuitamente, vc. mesmo pode fazer isso se quiser.
Há quem diga que esta é a verdadeira força da plataforma Java, mais que apenas suas características técnicas. Sua comunidade é extremamente ativa.
eles dizem que os drafts e releases de documentos de especificacao sao tao volateis que fica dificil dizer o que vingará e o que não na versao futura da SDK
A partir do momento em que uma JSR é aprovada e um draft é escrito, ela "vingará", de um jeito ou de outro. A especificação será refinada por várias fases e revisões até chegar a sua forma final (proposed final draft), nas quais detalhes poderão mudar (inclusive a data de liberação). A partir da construção da RI, a JSR passará a ser versionada e cada mudança deverá manter estrita compatibilidade retroativa com as versões anteriores.
Não necessariamente todas as JSR estarão refletidas em uma das distribuições principais (JSE, JEE, JMe), é muita coisa! Ao invés disso, as funcionalidades consideradas essenciais são incorporadas e as outras são distribuídas como opcionais. Exemplo: JMX (implementação do protocolo SNMP) foi considerada essencial para JSE sendo incorporada a partir da versão 5, mas coisas como JavaSpeech ou JUSB tem interesse periférico e estão disponíveis como produtos separados.
Se portabilidade é tao simples assim, entao qual é a razao da JVM
Vindo da história do Java:
"A equipe Green tinha o objetivo de criar um conjunto de macros portáteis em C++ para quaisquer dispositivos (inicialmente, Java seria apenas isso). Devido a inúmeros problemas e discrepâncias no isolamento de processos e alocação/desalocação de memória, perceberam a necessidade de uma camada de compatibilidade baseada em máquina virtual."
A tecnologia de VMs não é de forma alguma nova, sendo adotada em várias plataformas anteriores, como Smalltalk.
Se vc fosse o VIP da area da IT, o que vc faria para, PELO MENOS, ganhar um pouco mais de performance?
Com cronograma de apenas 1 mês adicional, contrataria um único profissional (arquiteto qualificado) para trabalhar com a mesma equipe original para corrigir os problemas de performance.
Em outra empresa de telecomunicações que servi, tivemos um exemplo. Um grande e importante sistema de aprovisionamento (mal) escrito em Java tinha um aproveitamento insuficiente para o crescimento da companhia (escalabilidade baixa). Claro que houveram pressões para reescrever tudo em C++ (sempre existe esse tipo de pressão... Eu acho divertido!).
Com um trabalho sério e orientado de menos de 2 meses, corrigimos gargalos e implementamos mais assincronia, obtendo uma melhoria de performance da ordem de 400% (superior às promessas da proposta de reescrita em C++). Não reescrevemos o sistema inteiro (grandes partes continuam mal-escritas... :-< ), mas o objetivo foi cumprido. Prevejo que na mudança da versão JSE 1.4 para JSE5 a performance deverá subir outros 25% a 30% "de graça", sem que uma única linha de código seja reescrita.
Sobre os JIT:
No caso médio, compiladores em tempo de execução podem ser até superiores à soluções de otimização manual. E explico o motivo de forma resumida:
Vc. nunca tentou otimizar um trecho de código só pra perceber que a emenda piorou o soneto? Isso ocorre pq em tempo de projeto é muito fácil fazer suposições incorretas sobre onde é o gargalo e como deve ser corrigido.
A prática moderna de desenvolvimento é inclusive escrever código sem tentar otimizar, fazer o profiling e detectar as áreas mais vitais (hotspots) e só então otimizar. Tornar 0,01ms mais rápido um trecho de código executado 5 vezes ao dia tem um retorno proximo de zero.
JIT se baseia no mesmo princípio. Ao invés de depender do programador para otimizar o código de baixo nível, ele realiza um profiling na aplicação (1a execução) e com base nesses resultados compila os hotspots necessários da melhor forma possível com base no cenário.
Enquanto vcs consideram Generics e resolucao de dados um assunto "quente"
Nós quem, cara pálida? Generics em Java é um assunto discutido (e tratado com cautela) desde 1998. É uma técnica servida fria, como a maioria das novidades na plataforma. Converse com seus colegas que programam em Java e verá, inclusive, que Generics não é realmente igual aos Templates de C++, possuindo alguns diferenciais importantes.
De forma parecida temos a "novidade" dos tipos enumerados. Em C++ os enum não são realmente Type-Safe, em Java sim.
E sim, java um dia pode estar em embedded, quando for mais rapido do que a porrada na frente de um carro até a abertura completa do airbag. Ou quando for rapido o suficiente para um robo segurar uma veia vazando sangue que nem uma mangueira de bombeiro a 1000 Km do médico, com retardo por causa do GC!
Lembro de um Java ONE onde James Gosling demonstrava uma JVM Real Time... Era uma plataforma leve que flutuava em uma cuba dágua tendo sobre ela um pêndulo que se movimentava sobre o controle da JVM, mantendo o equilibrio. Durante todo o evento, ele e os outros palestrantes davam frequentes "pescoções" no dispositivo, e o pêndulo sempre compensava imediatamente o golpe, mantendo a plataforma acima do nível da água sem deixar a parte de cima molhar. Isso é RTS. Pode abrir o seu air-bag a tempo ou pinçar a sua veia.
Mas vc alguma vez viu qualquer outra linguagem com o marketing que Java teve???
Sim, já vi. Ela até hoje tem o nome de C++. Quando estava em seu auge ela recebia apoio de gigantes como a Borland, a Sun (sim, a Sun!) e até mesmo a Microsoft! As pessoas estavam entusiasmadas com a portabilidade prometida e a possibilidade de programação orientada a objetos.
Outras línguas apareceram e foram embora apoiadas por nichos distintos no mercado. Apenas C++ tinha a unanimidade. Sim, sou mais velho que vc., tenho 34 anos, eu sei pq eu estava vivo na época. C/C++ era a minha linguagem "de coração", era a maneira correta de fazer as coisas. Mas ela tinha produtividade baixa para o mercado SOHO e eu passava muito tempo depurando bugs. Eu precisava produzir pra comer...
Mas no entanto vcs preferem perder tempo guerriando com programadores C/C++ em servidores!
Nosso primeiro e maior sucesso palpável no mercado.
Onde a troca de maquinas/SO são rarissimos (quando ocorrem sao por falha de planejamento, nao se muda um Solaris ou um AIX prum Windows da bobeira...
Mas onde a portabilidade permite que eu escreva e teste sistemas corporativos em desktops de mesa e/ou servidores modestos antes de passá-los para o poderoso servidor SPARC de produção.
pq o engine da Oracle ainda é em C sendo ela uma das empresas que mais apoiam o Java?? Por que o CICS e o OS/400 da IBM é em C++?? O http da Apache? Mozila? Google e seu core?? MySQL e PostGre?? Sun HotSpot JVM em C++?? Sun Solaris??
Pelo mesmo motivo pelo qual eu convivo todos os dias (e integro) com sistemas legados, escritos até em COBOL. Pq é estupidez reescrever um sistema já antigo, maduro, robusto e testado, gastando todo o investimento inicial novamente, por mais que vc. ache que encontrou uma língua/plataforma melhor. É a lei mais básica do mercado de software. Vc. não reescreve, vc. integra.
Java interfaceia com CICS, roda sob As/400, o "http" (vc. quer dizer o Apache Web Server) possui módulo de integração com servlet containers como o Jakarta Tomcat, o navegador Mozilla suporta plugins e skins escritos em Java, o Core do Google (uma colcha de retalhos) tem várias partes escritas em Java, existem drivers JDBC para todos os bancos (incluindo MySQL - ruim, existem RDBMS puro-Java melhores - e PostGrès), Sun Solaris é a plataforma mais integrada a Java que existe, etc.
Curiosidade: Se vc. acha que Java precisa de uma JVM escrita em outra linguagem como C++, dê uma pesquisada na Jikes RVM.
O que eu vejo que eles vêem também??
Comentário de nemesis
10/06/06 1:20 - usuário registrado #1514
sem querer me intrometer: ver um javali e um cmaismacho se espancando é sempre divertido. :)
continuem, por favor... :)
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
continuem, por favor... :)
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de CWagner
10/06/06 14:30 - usuário registrado #49
Realmente, é legal ver: Realmente, é legal ver certas coisas acontecerem.
Eu sempre tiro muita informação dessas discussões, que depois vou verificar com professores, livros ou na net (sempre aparecem links interessantes). É bom ver que muitos têm base para discutir, e não são apenas ferrenhos defensores sem calças.
Só me acordem quando tudo isso acabar, OK?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Carlos Wagner - São Luís / MA
P.S.: As palavras acima fazem parte da minha visão do assunto e não pretendem ser, de modo algum, a verdade absoluta sobre o mesmo.
Obrigado!
Eu sempre tiro muita informação dessas discussões, que depois vou verificar com professores, livros ou na net (sempre aparecem links interessantes). É bom ver que muitos têm base para discutir, e não são apenas ferrenhos defensores sem calças.
Só me acordem quando tudo isso acabar, OK?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Carlos Wagner - São Luís / MA
P.S.: As palavras acima fazem parte da minha visão do assunto e não pretendem ser, de modo algum, a verdade absoluta sobre o mesmo.
Obrigado!
Comentário de Copernico Vespucio
12/06/06 16:52 - usuário registrado #4868
obrigado: Puxa, é realmente bom saber que essas discussões (apesar do costume de se tornarem flames intermináveis e chatos) são produtivas para a comunidade.
Isso me honra e estimula a prosseguir, já que podem se tornar úteis para alguém.
Tem sido útil pra mim também. Aprendi muita coisa, tanto de foro técnico quanto pessoal. O BR-Linux tem me ensinado, sobretudo, a arte da tolerância e o sentimento de que a minha real comunidade é ainda maior que apenas a comunidade Java.
Somos aqui a comunidade dos que lutam por um mundo mais honesto, mais aberto, mais colaborativo, mais inteligente.
E enquanto estivermos aqui para trocar conhecimento (pacificamente ou não :-P), essa comunidade só tende a crescer.
Isso me honra e estimula a prosseguir, já que podem se tornar úteis para alguém.
Tem sido útil pra mim também. Aprendi muita coisa, tanto de foro técnico quanto pessoal. O BR-Linux tem me ensinado, sobretudo, a arte da tolerância e o sentimento de que a minha real comunidade é ainda maior que apenas a comunidade Java.
Somos aqui a comunidade dos que lutam por um mundo mais honesto, mais aberto, mais colaborativo, mais inteligente.
E enquanto estivermos aqui para trocar conhecimento (pacificamente ou não :-P), essa comunidade só tende a crescer.
Comentário de asd
13/06/06 14:28
Bem, antes de tudo,: Bem, antes de tudo, fresquinho: http://ask.slashdot.org/article.pl?sid=06/06/12/2044245
Selecionando os pontos:
"...a tolerância a falhas não-sistêmicas é menor, a preocupação com a compatibilidade é enorme e tudo deve ser feito o mais configurável, portável e flexível possível."
Sim, esta certo. E acredito que pra atingir estes objetivos pesa muito mais o conhecimento programador que a linguagem utilizada.
"Um desenvolvedor Java decente sabe o que acontece em baixo nível, embora não tenha de se envolver com isso todas as vezes."
A palavra 'decente' salvou este eu comentário, heim? Realmente há um abismo entre os decentes e os não. Conversando com alguns javaneses sobre a prova de certificação (a primeira), eles disseram que fora difícil pq caia operadores lógicos (bitwise)! Pela Mor de Deus! Isso mostra que muitos programadores Java não possuem nem noção do que é 1 byte! Falar que bitwise (eles não conhecem por esse nome) é algo complexo para se pedir em uma prova e se intitular programador certificado é muito pra minha paciência!
(ai, só pra 'butá fogo na fugueira', falei "Ooh! Nossa! Me explica direito esse negocio de bitwise! Me explica como faria uma função (ia pedir em um '#define', mas como não há isso) do tipo SET_BIT(byte, posicao_bit)". Os caras ficaram 1/2 hora pensando pra depois desistir. E são 'certificados'... pra mim eles deveria usar o diploma/certificação deles no banheiro, junto com a mochilinha para guardar papel-higienico (acho que deu pra notar a raiva que possuo dessas mochilinhas, ne?! O mesmo vale pra Oracle e MS... sim, talvez pq eu não tenha quem faça isso pra mim, ou talvez pq elas transmitem um ar de arrogância alem da conta (i.e. alem do que os 'mochileiros' podem suportar sobre pressão)))
"E dentro de um contexto onde gerenciar desalocação de memória manual se torna desnecessário e problemas como falhas de sincronia são muito mais fáceis de evitar.
Ótimo o objetivo desse JOGL! Porem prova o que estava dizendo: aplicativos Java são dependentes da programação C/C++, o que não faz sentido 'mata-lo' do mercado 'roubando' empregos.
Ok. Concordo muita coisa que foi dita acima, porem, este ponto da discussão iniciou-se quando vc citou que 'sou um programador C/C++ magoado' por ter perdido o mercado para a linguagem Java.
Apenas rebati o tópico dizendo que, alem de não me sentir preocupado/magoado, a industria de TI (ou IT) continua (e continuara) utilizando C/C++ por um bom tempo não só pelos sistemas legados, mas pq ela tem características impares (cuja quais vcs dependem).
O que vc escreveu me ajuda a ver melhor ainda a idéia que existe a ferramenta certa para o lugar certo. Por exemplo, não acho certo escrever web-applets se Java ou PHP podem fazer melhor que C/C++ e/ou num tempo de desenvolvimento melhor sendo que o resultado final seja aceitável.
Bem... resumindo, trabalhando com C/C++ não vejo o fim do mercado ou ameaçado por qualquer outra linguagem... não nos próximos 50 anos. Então, sobre o 'programador C++ magoado com o mercado que programadores Java tiraram de vcs' que vc disse, não, não estou magoado. Ha mercado a dar com pau pra minha linguagem.
E sim, ótimas coisas são frutos da comunidade Java, porem, o que nos tranquiliza é a nossa independência. E ser dependente é algo muito perigoso (vejamos um exemplo fora do mundo de TI: gás da Bolívia. É a constante sensação de tiro no pé OU a constante sensação de mal estar por continuar aturando o código 'ovelha-negra' no meio de milhares de linhas da linguagem definida como padrão na companhia. E diga vc mesmo, não é um saco ter código 'nao padrao' dentro do seu sistema?).
"Com cronograma de apenas 1 mês adicional, contrataria um único profissional (arquiteto qualificado) para trabalhar com a mesma equipe original para corrigir os problemas de performance."
É... é o que resta a fazer. Mas isso se torna irritante sabendo que 'eles' tinham as ferramentas que necessitaram e que não eram crianças (isto é, eram certificados e ganhavam o valor do mercado como tal). Isso é revoltante. É difícil de aceitar algo do tipo 'contrate MAIS UM profissional qualificado'. Jogando contra meu próprio time (desenvolvimento), acho que isso não deve ser aceito pacificamente. Reforçando: olhando como o usuário, não quero saber se eles planejaram a escalabilidade do software, isso é dever deles! O problema é que falharam e 'eu' terei que pagar ($).
"... obtendo uma melhoria de performance da ordem de 400% (superior às promessas da proposta de reescrita em C++).... Prevejo que na mudança da versão JSE 1.4 para JSE5 a performance deverá subir outros 25% a 30% "de graça", sem que uma única linha de código seja reescrita."
Perai... reescrever TAMBEM em C++ as MESMAS mudanças que lhe proporcionaram esse 400% em Java! Ai é um problema de algoritmo, não de linguagem. Assincronia não é característica de uma linguagem.
JIT se baseia no mesmo princípio. Ao invés de depender do programador para otimizar o código de baixo nível, ele realiza um profiling na aplicação (1a execução) e com base nesses resultados compila os hotspots necessários da melhor forma possível com base no cenário.
Sim. Concordo cegamente com isso: a optimizacao manual é traiçoeira. Sempre se deve usar ferramentas quando for otimizar (como no meu caso, gprof). O restante, deixamos para o compilador fazer: vetorização de loops, funções inline, substituição de mallocs que não fazem reallocs e nem estão dentro de loops por memória fixa, o mesmo para criação de objetos dinâmicos (new) por stack (automaticas), etc etc etc.
Agora estamos falando de 'otimizacao manual', temos que levar em conta também: a) a otimização 'forcada' (-Ox) utilizando os tópicos acima; b) a possibilidade de trocar de compilador sem muitas dores (desde que o compilador siga normas do tipo, para C: C98/ANSI, para C++: ANSI/BSI/DIN/ISO/EIC14882, etc etc etc): segundo benchmarks, o compilador icc (Intel) é cerca de 20% a 30% mais performático que o gcc (fonte usado para o benchmark foi o kernel do linux).. ahh, uma dica excelente: a versão linux do icc é gratuita!! Poucas pessoas sabem disso e continuam usando o gcc em produção [a) ver licença; b) pelo mor de Deus, amo o gcc, mas pq não usar o icc se é grátis? Se é melhor e tendo em produção hardware Intel, pq não usar um compilador que se ajusta como uma luva para o processador?] e utilizar projetos padrao VC++ da MS quando utilizando sistema Windows (aonda mais seria?); c) ter recursos como pre-compiladores, do tipo Oracle Pro*C, Informix PreComp, PostgreSQL (que não me lembro o nome) e duma porrada de DB sérios (o MySQL está para implementar o seu precompilador também): sistemas com alto volume e acesso PESADO ao banco, poder se comunicar com o DB via IPC inseridos no código (shmemo via precompilação de abstrações de comandos SQLs) ao invez de APIs (que fazem parsing/validação do comando) é um ganho substancial.
"Nós quem, cara pálida? Generics em Java é um assunto discutido (e tratado com cautela) desde 1998. É uma técnica servida fria, como a maioria das novidades na plataforma. Converse com seus colegas que programam em Java e verá, inclusive, que Generics não é realmente igual aos Templates de C++, possuindo alguns diferenciais importantes."
Generics é discutido desde 1998, MAS apenas agora estão estavelmente disponíveis (versão 1.5 ou 5), não?? Me desculpe, mas algo tão poderoso e importante numa linguagem tão difundida já deveria ser algo comum nas bocas dos javaneses há anos, e não 'servida fria' (isso me cheira a 'está ai... use por sua conta e risco'). E por mais diferente que seja Generics, poder escrever algo simples como:
Template void swap(X &a, X &b){
X c;
C = a; A = b; B = c;
}
não deveria demorar tanto.
Não vejo forma melhor de abstração e reutilização de código do que Templates/Generics. Acho que vcs mereciam isso a muito mais tempo (poxa! Ta vendo como sou bom!).
É. Em C++ o enum é label para um valor numérico (int). Mas os únicos problemas que vejo nisso é o usuário-programador: a) comparar um valor do enum com um tipo numero declarado como int (erro de design: programador quebrando a abstração); b) comparando com outro dado do tipo enum (erro de digitação. Comparar uma label de enum mes_t com uma label de, sei la, enum carro_t). Apesar da linguagem permitir estas 2 falhas, qualquer compilador irá reclamar. E outra, enum?? Em C++, ou até mesmo em C, crio um tipo de dado abstrato com métodos de get/set/compare.
"Lembro de um Java ONE onde James Gosling demonstrava uma JVM Real Time..."
Apenas perguntando, não estou afirmando nada: quantos programadores Java no Brasil estão aptos a fazer o mesmo trabalho que James G. fez? Ele apenas baixou ($) essa JVM-RTM do site da Sun e pronto?? (http://java.sun.com/j2se/realtime/)
E vc acha que isso é uma prova de produtividade (desenvolvimento, processo de depuração bem mais complexo que o normal, grande comunidade utilizando a mesma tecnologia, etc...) ou de "nós tb podemos, eeeee!!"?
"Sim, já vi. Ela até hoje tem o nome de C++. Quando estava em seu auge ela recebia apoio de gigantes como a Borland, a Sun (sim, a Sun!) e até mesmo a Microsoft! As pessoas estavam entusiasmadas com a portabilidade prometida e a possibilidade de programação orientada a objetos."
Ahh não.. vamos medir o marketing não por nós, que lemos Slashdot, e sim por quem não é da área. Pergunte, até mesmo para um Administrador da área de TI (que nunca colocou a mão em nenhum código-fonte, acho que eles nem sabem o que é..) ou até mesmo para o estagiário do RH, para citarem uma linguagem de programação, ou melhor, se fossem aprender uma linguagem de programação, qual eles escolheriam! Adivinhe a resposta (e eles nem vao saber exatamente pq esconhem Java.. vai ser pq é a unica que eles conhecem. E isso é tática de marketing: saturar a marca no mercado).
Um dia, minha mãe (sim!) chegou para mim e perguntou "O que é Java?"? A minha mãe!! Como isso chegou na boca dela? Cuja qual nem sabe o que é linux!
É o marketing, e não pq a linguagem fez isso, mas sim pq por trás dela tem uma empresa que não esta disposta a perder dinheiro. Compare com Perl. Que nasceu, se não antes, junto com Java e atinge o mesmo foco de programação.
É a Sun lutando pelo seu interesse.
Eu acho que vc deveria responder "Temos marketing em cima de nossa linguagem sim! E DAI?!" ou "Temos sim quem paga para fazer propaganda nossa na revista da Oracle sim, E DAI?!?!" Pronto...
Perl nasceu junto com Java, tem o mesmo foco em resolver problemas, é mais adotado dentro do underground e porque VIPs ou mamães nunca ouviram falar?? Se eu falo 'achocolatado', pq vc pensa em 'Nescau'? Sacou? Saturação da marca, e isso é responsabilidade do marketing.
(curiosidade: durou 1 dia a propaganda do compilador SunStudio11 no site principal da Sun: era um cara fazendo SkyDive, de cabeça pra baixo, e do lado escrito: "New SunStudio C/C++/Fortran Compilers. BECAUSE PERFORMANCE MATTERS" http://developers.sun.com/prodtech/cc/downloads/index.jsp ... até chorei este dia.. hehehe)
"Mas onde a portabilidade permite que eu escreva e teste sistemas corporativos em desktops de mesa e/ou servidores modestos antes de passá-los para o poderoso servidor SPARC de produção."
Quando comecei profissionalmente, achava isso um ponto excelente em Java: poder escrever os apps nos desktops e rodar nos servidores. E ainda acho.
Mas com o tempo, fui vendo que essa metodologia cria um certo 'emburrecimento' do programador sobre o sistema operacional (principalmente linux/unix): muitos programadores javas ficam 'pescando' comandos quando caem no shell do unix (desde comandos até expressões regulares para filtrarem o log, exemplo: 'tail f logfile | grep [Ee]xception') até o comportamento do próprio SO (idéias como: 'aahhh unix multiprocessado! vamos criar 27583 threads pq o sistema vai rodar mais rápido!'). Isso é muito comum... quantas e quantas vezes já tive que ajudar javaneses fazerem FTP do '.class' vindo da maquina unix!! Poxa, ridículo! Meu conhecimento de unix aumentou muito pq o ambiente que uso para desenvolver me obriga a isso: uso VIM via ssh. Se eu não soubesse usar um 'grep', um 'sort' ou 'uniq', regexp para navegar no código fonte, estaria na roça! E depois de ter aprendido (ok, levou tempo, mas não muito nao), não sou menos produtivo do que se estivesse usando Eclipse + plugin CDE. E vc, que usa linux, me diz se esse aprendizado é inútil? Pra mim, pessoas que dizem rodar programas em ambiente linux/unix (independente de linguagem), se não souberem fazer um simples 'grep', não devem ser contratadas.
"Pelo mesmo motivo pelo qual eu convivo todos os dias (e integro) com sistemas legados, escritos até em COBOL. Pq é estupidez reescrever um sistema já antigo, maduro, robusto e testado, gastando todo o investimento inicial novamente, por mais que vc. ache que encontrou uma língua/plataforma melhor. É a lei mais básica do mercado de software. Vc. não reescreve, vc. integra. Java interfaceia com CICS..."
Acredito que vc convive com sistemas legados pq não há motivos para altera-los.
A questão de 'manter o codigo legado funcional' é plausível até um certo ponto. Temos milhares de exemplos de sistemas que foram reescritos por se tornarem insuportaveis, os mais famosos: o Unix de linguagem B para C, o Oracle (http://en.wikipedia.org/wiki/Oracle_Corporation) em 1983 foi reescrito em C, e por ai vai. Assim como há aqueles que são reescritos em Java sim!!
Então isso prova que esse limite (aturar codigo legado) é quebrado quando surge algum interesse em jogo (normalmente $).
E seja qual for lá esse limite, a Oracle já o ultrapassou (cá entre nos Copernico, vc não acha que no laboratorio da Oracle eles já não criaram um Oracle 100% Java?? Vc acha que não?? Humm..? qualé! Eles teriam um orgasmo de 1 mês se fizessem um lançamento desse! Com marketing dizendo algo do tipo 'todos seus aplicativos Java vão ser muito mais integrados com o núcleo Oracle do que nunca!'. Seria capa da revista da Oracle por 1 ano inteiro! É claro que eles já fizeram esse teste!).
Sobre o Solaris ser a plataforma mais integrada com Java: uma vez fiz uma competição com os javaneses aqui (disputa de benchmark de threads, just4fun): eu propus rodar o benchmark versão Java no Solaris (depois de ter 'estrupado' a versão deles no HP-UX), pois sabe como é: 'estariam em casa', e ai me disseram que o Solaris não é a melhor plataforma para rodar Java!! Que a propria Sun reconhece que a JVM para Solaris não é a melhor! Poxa! Eu dando uma 'lambuja' e eles me vêem com essa!? Segundo eles, a melhor JVM é a do sistema Windows! Por sermos freqüentadores do fórum em questão, lamento por vc... mas seu windows já travou hoje? (hehehe)
"Curiosidade: Se vc. acha que Java precisa de uma JVM escrita em outra linguagem como C++, dê uma pesquisada na Jikes RVM."
Não acho que Java precise de uma JVM em C++ não, claro que não. Mas as melhores JVM são feitas em C++, NAO?? Li sobre o Jikes. Huum... a questão é: existe, mas vc usaria??
http://www-128.ibm.com/developerworks/java/library/j-jalapeno/
E o Jalapena não é 100% Java e não tem o principal foco do Java: portabilidade (irônico, não?). Ok... seria apenas 1 ou 2 linhas (+-900) pra torná-lo portável. Mas pra quem esta acostumado com portar sem mexer em nenhuma linha, isso parece muito (vai que cai um dedo!).
E outra, esse Jikes está mais me parecendo mais cunho acadêmico (http://jikesrvm.sourceforge.net/wiki/index.php/Current_Users) do que algo comercial/confiável para produção. Não achei ninguem que esteja usando isso comercialmente, tem?
"O que eu vejo que eles vêem também??"
Bem Copérnico...
Resumindo do meu ponto de vista: "Ferramenta certa para o lugar certo".
Não precisamos de Java em Iface Gráfica ou RTOS pq já temos tecnologia muito matura para isso. Porem, há pontos onde a utilização do Java é indiscutível.
Há lugares que Java poderia melhorar (ou melhor, lugares que estão pedindo socorro pra que Java melhore): desktop's.
Há lugares que a melhora de Java não irá trazer nada de novo (!), nada do que já temos hoje e que nos atende muito bem: servidores e RTOS.
Acho que ambas tecnologias não são excludentes, e sim, digamos: o Yin-Yang. Devem ser trabalhadas no lugar certo. Acho que Java deveria focar no que C/C++ pecam ou no que ainda não atendem.
Como vc pode ver, não estou sendo xiita e dizendo que Java não presta! Não, pelo contrário! Acho que presta e muito! Porem acho que estão gastando tempo onde as coisas já estão funcionando bem: pra que esperar 5 anos pelo Glass ficar igual ao KDE de hoje se já temos KDE, Gnome, CDE, FluxBox, etc etc etc (até mesmo o próprio Windows!)...?? Sendo que estes sistemas daqui 5 anos tambem estarão melhores!
Ahh, uma coisa que achei muito interessante durante minhas pesquisas, chamado JNI (já que o pessoal está lendo e gostando tb): http://www.javaworld.com/javaworld/jw-05-2001/jw-0511-legacy.html
Porra! Eu posso 'levantar' uma JVM dentro do meu código C/C++ (JNI_CreateJavaVM())!! Cacetada! Pq há programadores C/C++ que se odeiam tanto, heim?? (ehehehe. Brincadeira. Mas a surpresa é real)
Pela idéia de VM, JIT e compilar código nativo em run-time, jurava que o cenário era o contrario (único link que achei): http://forum.java.sun.com/thread.jspa?threadID=600123&messageID=3206642
Uma pergunta para entender melhor seu ponto de vista sobre 'resolução de problemas X tecnologia empregada': vc utiliza Java para tudo? Seja lá o projeto que parar hoje na sua mão, vc utiliza Java inconstitucionalmente?? Ou há problemas que vc emprega outras linguagens? E o que estes problemas apresentam de diferentes para mudar seu ponto de vista?
[]s
Selecionando os pontos:
"...a tolerância a falhas não-sistêmicas é menor, a preocupação com a compatibilidade é enorme e tudo deve ser feito o mais configurável, portável e flexível possível."
Sim, esta certo. E acredito que pra atingir estes objetivos pesa muito mais o conhecimento programador que a linguagem utilizada.
"Um desenvolvedor Java decente sabe o que acontece em baixo nível, embora não tenha de se envolver com isso todas as vezes."
A palavra 'decente' salvou este eu comentário, heim? Realmente há um abismo entre os decentes e os não. Conversando com alguns javaneses sobre a prova de certificação (a primeira), eles disseram que fora difícil pq caia operadores lógicos (bitwise)! Pela Mor de Deus! Isso mostra que muitos programadores Java não possuem nem noção do que é 1 byte! Falar que bitwise (eles não conhecem por esse nome) é algo complexo para se pedir em uma prova e se intitular programador certificado é muito pra minha paciência!
(ai, só pra 'butá fogo na fugueira', falei "Ooh! Nossa! Me explica direito esse negocio de bitwise! Me explica como faria uma função (ia pedir em um '#define', mas como não há isso) do tipo SET_BIT(byte, posicao_bit)". Os caras ficaram 1/2 hora pensando pra depois desistir. E são 'certificados'... pra mim eles deveria usar o diploma/certificação deles no banheiro, junto com a mochilinha para guardar papel-higienico (acho que deu pra notar a raiva que possuo dessas mochilinhas, ne?! O mesmo vale pra Oracle e MS... sim, talvez pq eu não tenha quem faça isso pra mim, ou talvez pq elas transmitem um ar de arrogância alem da conta (i.e. alem do que os 'mochileiros' podem suportar sobre pressão)))
"E dentro de um contexto onde gerenciar desalocação de memória manual se torna desnecessário e problemas como falhas de sincronia são muito mais fáceis de evitar.
Ótimo o objetivo desse JOGL! Porem prova o que estava dizendo: aplicativos Java são dependentes da programação C/C++, o que não faz sentido 'mata-lo' do mercado 'roubando' empregos.
Ok. Concordo muita coisa que foi dita acima, porem, este ponto da discussão iniciou-se quando vc citou que 'sou um programador C/C++ magoado' por ter perdido o mercado para a linguagem Java.
Apenas rebati o tópico dizendo que, alem de não me sentir preocupado/magoado, a industria de TI (ou IT) continua (e continuara) utilizando C/C++ por um bom tempo não só pelos sistemas legados, mas pq ela tem características impares (cuja quais vcs dependem).
O que vc escreveu me ajuda a ver melhor ainda a idéia que existe a ferramenta certa para o lugar certo. Por exemplo, não acho certo escrever web-applets se Java ou PHP podem fazer melhor que C/C++ e/ou num tempo de desenvolvimento melhor sendo que o resultado final seja aceitável.
Bem... resumindo, trabalhando com C/C++ não vejo o fim do mercado ou ameaçado por qualquer outra linguagem... não nos próximos 50 anos. Então, sobre o 'programador C++ magoado com o mercado que programadores Java tiraram de vcs' que vc disse, não, não estou magoado. Ha mercado a dar com pau pra minha linguagem.
E sim, ótimas coisas são frutos da comunidade Java, porem, o que nos tranquiliza é a nossa independência. E ser dependente é algo muito perigoso (vejamos um exemplo fora do mundo de TI: gás da Bolívia. É a constante sensação de tiro no pé OU a constante sensação de mal estar por continuar aturando o código 'ovelha-negra' no meio de milhares de linhas da linguagem definida como padrão na companhia. E diga vc mesmo, não é um saco ter código 'nao padrao' dentro do seu sistema?).
"Com cronograma de apenas 1 mês adicional, contrataria um único profissional (arquiteto qualificado) para trabalhar com a mesma equipe original para corrigir os problemas de performance."
É... é o que resta a fazer. Mas isso se torna irritante sabendo que 'eles' tinham as ferramentas que necessitaram e que não eram crianças (isto é, eram certificados e ganhavam o valor do mercado como tal). Isso é revoltante. É difícil de aceitar algo do tipo 'contrate MAIS UM profissional qualificado'. Jogando contra meu próprio time (desenvolvimento), acho que isso não deve ser aceito pacificamente. Reforçando: olhando como o usuário, não quero saber se eles planejaram a escalabilidade do software, isso é dever deles! O problema é que falharam e 'eu' terei que pagar ($).
"... obtendo uma melhoria de performance da ordem de 400% (superior às promessas da proposta de reescrita em C++).... Prevejo que na mudança da versão JSE 1.4 para JSE5 a performance deverá subir outros 25% a 30% "de graça", sem que uma única linha de código seja reescrita."
Perai... reescrever TAMBEM em C++ as MESMAS mudanças que lhe proporcionaram esse 400% em Java! Ai é um problema de algoritmo, não de linguagem. Assincronia não é característica de uma linguagem.
JIT se baseia no mesmo princípio. Ao invés de depender do programador para otimizar o código de baixo nível, ele realiza um profiling na aplicação (1a execução) e com base nesses resultados compila os hotspots necessários da melhor forma possível com base no cenário.
Sim. Concordo cegamente com isso: a optimizacao manual é traiçoeira. Sempre se deve usar ferramentas quando for otimizar (como no meu caso, gprof). O restante, deixamos para o compilador fazer: vetorização de loops, funções inline, substituição de mallocs que não fazem reallocs e nem estão dentro de loops por memória fixa, o mesmo para criação de objetos dinâmicos (new) por stack (automaticas), etc etc etc.
Agora estamos falando de 'otimizacao manual', temos que levar em conta também: a) a otimização 'forcada' (-Ox) utilizando os tópicos acima; b) a possibilidade de trocar de compilador sem muitas dores (desde que o compilador siga normas do tipo, para C: C98/ANSI, para C++: ANSI/BSI/DIN/ISO/EIC14882, etc etc etc): segundo benchmarks, o compilador icc (Intel) é cerca de 20% a 30% mais performático que o gcc (fonte usado para o benchmark foi o kernel do linux).. ahh, uma dica excelente: a versão linux do icc é gratuita!! Poucas pessoas sabem disso e continuam usando o gcc em produção [a) ver licença; b) pelo mor de Deus, amo o gcc, mas pq não usar o icc se é grátis? Se é melhor e tendo em produção hardware Intel, pq não usar um compilador que se ajusta como uma luva para o processador?] e utilizar projetos padrao VC++ da MS quando utilizando sistema Windows (aonda mais seria?); c) ter recursos como pre-compiladores, do tipo Oracle Pro*C, Informix PreComp, PostgreSQL (que não me lembro o nome) e duma porrada de DB sérios (o MySQL está para implementar o seu precompilador também): sistemas com alto volume e acesso PESADO ao banco, poder se comunicar com o DB via IPC inseridos no código (shmemo via precompilação de abstrações de comandos SQLs) ao invez de APIs (que fazem parsing/validação do comando) é um ganho substancial.
"Nós quem, cara pálida? Generics em Java é um assunto discutido (e tratado com cautela) desde 1998. É uma técnica servida fria, como a maioria das novidades na plataforma. Converse com seus colegas que programam em Java e verá, inclusive, que Generics não é realmente igual aos Templates de C++, possuindo alguns diferenciais importantes."
Generics é discutido desde 1998, MAS apenas agora estão estavelmente disponíveis (versão 1.5 ou 5), não?? Me desculpe, mas algo tão poderoso e importante numa linguagem tão difundida já deveria ser algo comum nas bocas dos javaneses há anos, e não 'servida fria' (isso me cheira a 'está ai... use por sua conta e risco'). E por mais diferente que seja Generics, poder escrever algo simples como:
Template
X c;
C = a; A = b; B = c;
}
não deveria demorar tanto.
Não vejo forma melhor de abstração e reutilização de código do que Templates/Generics. Acho que vcs mereciam isso a muito mais tempo (poxa! Ta vendo como sou bom!).
É. Em C++ o enum é label para um valor numérico (int). Mas os únicos problemas que vejo nisso é o usuário-programador: a) comparar um valor do enum com um tipo numero declarado como int (erro de design: programador quebrando a abstração); b) comparando com outro dado do tipo enum (erro de digitação. Comparar uma label de enum mes_t com uma label de, sei la, enum carro_t). Apesar da linguagem permitir estas 2 falhas, qualquer compilador irá reclamar. E outra, enum?? Em C++, ou até mesmo em C, crio um tipo de dado abstrato com métodos de get/set/compare.
"Lembro de um Java ONE onde James Gosling demonstrava uma JVM Real Time..."
Apenas perguntando, não estou afirmando nada: quantos programadores Java no Brasil estão aptos a fazer o mesmo trabalho que James G. fez? Ele apenas baixou ($) essa JVM-RTM do site da Sun e pronto?? (http://java.sun.com/j2se/realtime/)
E vc acha que isso é uma prova de produtividade (desenvolvimento, processo de depuração bem mais complexo que o normal, grande comunidade utilizando a mesma tecnologia, etc...) ou de "nós tb podemos, eeeee!!"?
"Sim, já vi. Ela até hoje tem o nome de C++. Quando estava em seu auge ela recebia apoio de gigantes como a Borland, a Sun (sim, a Sun!) e até mesmo a Microsoft! As pessoas estavam entusiasmadas com a portabilidade prometida e a possibilidade de programação orientada a objetos."
Ahh não.. vamos medir o marketing não por nós, que lemos Slashdot, e sim por quem não é da área. Pergunte, até mesmo para um Administrador da área de TI (que nunca colocou a mão em nenhum código-fonte, acho que eles nem sabem o que é..) ou até mesmo para o estagiário do RH, para citarem uma linguagem de programação, ou melhor, se fossem aprender uma linguagem de programação, qual eles escolheriam! Adivinhe a resposta (e eles nem vao saber exatamente pq esconhem Java.. vai ser pq é a unica que eles conhecem. E isso é tática de marketing: saturar a marca no mercado).
Um dia, minha mãe (sim!) chegou para mim e perguntou "O que é Java?"? A minha mãe!! Como isso chegou na boca dela? Cuja qual nem sabe o que é linux!
É o marketing, e não pq a linguagem fez isso, mas sim pq por trás dela tem uma empresa que não esta disposta a perder dinheiro. Compare com Perl. Que nasceu, se não antes, junto com Java e atinge o mesmo foco de programação.
É a Sun lutando pelo seu interesse.
Eu acho que vc deveria responder "Temos marketing em cima de nossa linguagem sim! E DAI?!" ou "Temos sim quem paga para fazer propaganda nossa na revista da Oracle sim, E DAI?!?!" Pronto...
Perl nasceu junto com Java, tem o mesmo foco em resolver problemas, é mais adotado dentro do underground e porque VIPs ou mamães nunca ouviram falar?? Se eu falo 'achocolatado', pq vc pensa em 'Nescau'? Sacou? Saturação da marca, e isso é responsabilidade do marketing.
(curiosidade: durou 1 dia a propaganda do compilador SunStudio11 no site principal da Sun: era um cara fazendo SkyDive, de cabeça pra baixo, e do lado escrito: "New SunStudio C/C++/Fortran Compilers. BECAUSE PERFORMANCE MATTERS" http://developers.sun.com/prodtech/cc/downloads/index.jsp ... até chorei este dia.. hehehe)
"Mas onde a portabilidade permite que eu escreva e teste sistemas corporativos em desktops de mesa e/ou servidores modestos antes de passá-los para o poderoso servidor SPARC de produção."
Quando comecei profissionalmente, achava isso um ponto excelente em Java: poder escrever os apps nos desktops e rodar nos servidores. E ainda acho.
Mas com o tempo, fui vendo que essa metodologia cria um certo 'emburrecimento' do programador sobre o sistema operacional (principalmente linux/unix): muitos programadores javas ficam 'pescando' comandos quando caem no shell do unix (desde comandos até expressões regulares para filtrarem o log, exemplo: 'tail f logfile | grep [Ee]xception') até o comportamento do próprio SO (idéias como: 'aahhh unix multiprocessado! vamos criar 27583 threads pq o sistema vai rodar mais rápido!'). Isso é muito comum... quantas e quantas vezes já tive que ajudar javaneses fazerem FTP do '.class' vindo da maquina unix!! Poxa, ridículo! Meu conhecimento de unix aumentou muito pq o ambiente que uso para desenvolver me obriga a isso: uso VIM via ssh. Se eu não soubesse usar um 'grep', um 'sort' ou 'uniq', regexp para navegar no código fonte, estaria na roça! E depois de ter aprendido (ok, levou tempo, mas não muito nao), não sou menos produtivo do que se estivesse usando Eclipse + plugin CDE. E vc, que usa linux, me diz se esse aprendizado é inútil? Pra mim, pessoas que dizem rodar programas em ambiente linux/unix (independente de linguagem), se não souberem fazer um simples 'grep', não devem ser contratadas.
"Pelo mesmo motivo pelo qual eu convivo todos os dias (e integro) com sistemas legados, escritos até em COBOL. Pq é estupidez reescrever um sistema já antigo, maduro, robusto e testado, gastando todo o investimento inicial novamente, por mais que vc. ache que encontrou uma língua/plataforma melhor. É a lei mais básica do mercado de software. Vc. não reescreve, vc. integra. Java interfaceia com CICS..."
Acredito que vc convive com sistemas legados pq não há motivos para altera-los.
A questão de 'manter o codigo legado funcional' é plausível até um certo ponto. Temos milhares de exemplos de sistemas que foram reescritos por se tornarem insuportaveis, os mais famosos: o Unix de linguagem B para C, o Oracle (http://en.wikipedia.org/wiki/Oracle_Corporation) em 1983 foi reescrito em C, e por ai vai. Assim como há aqueles que são reescritos em Java sim!!
Então isso prova que esse limite (aturar codigo legado) é quebrado quando surge algum interesse em jogo (normalmente $).
E seja qual for lá esse limite, a Oracle já o ultrapassou (cá entre nos Copernico, vc não acha que no laboratorio da Oracle eles já não criaram um Oracle 100% Java?? Vc acha que não?? Humm..? qualé! Eles teriam um orgasmo de 1 mês se fizessem um lançamento desse! Com marketing dizendo algo do tipo 'todos seus aplicativos Java vão ser muito mais integrados com o núcleo Oracle do que nunca!'. Seria capa da revista da Oracle por 1 ano inteiro! É claro que eles já fizeram esse teste!).
Sobre o Solaris ser a plataforma mais integrada com Java: uma vez fiz uma competição com os javaneses aqui (disputa de benchmark de threads, just4fun): eu propus rodar o benchmark versão Java no Solaris (depois de ter 'estrupado' a versão deles no HP-UX), pois sabe como é: 'estariam em casa', e ai me disseram que o Solaris não é a melhor plataforma para rodar Java!! Que a propria Sun reconhece que a JVM para Solaris não é a melhor! Poxa! Eu dando uma 'lambuja' e eles me vêem com essa!? Segundo eles, a melhor JVM é a do sistema Windows! Por sermos freqüentadores do fórum em questão, lamento por vc... mas seu windows já travou hoje? (hehehe)
"Curiosidade: Se vc. acha que Java precisa de uma JVM escrita em outra linguagem como C++, dê uma pesquisada na Jikes RVM."
Não acho que Java precise de uma JVM em C++ não, claro que não. Mas as melhores JVM são feitas em C++, NAO?? Li sobre o Jikes. Huum... a questão é: existe, mas vc usaria??
http://www-128.ibm.com/developerworks/java/library/j-jalapeno/
E o Jalapena não é 100% Java e não tem o principal foco do Java: portabilidade (irônico, não?). Ok... seria apenas 1 ou 2 linhas (+-900) pra torná-lo portável. Mas pra quem esta acostumado com portar sem mexer em nenhuma linha, isso parece muito (vai que cai um dedo!).
E outra, esse Jikes está mais me parecendo mais cunho acadêmico (http://jikesrvm.sourceforge.net/wiki/index.php/Current_Users) do que algo comercial/confiável para produção. Não achei ninguem que esteja usando isso comercialmente, tem?
"O que eu vejo que eles vêem também??"
Bem Copérnico...
Resumindo do meu ponto de vista: "Ferramenta certa para o lugar certo".
Não precisamos de Java em Iface Gráfica ou RTOS pq já temos tecnologia muito matura para isso. Porem, há pontos onde a utilização do Java é indiscutível.
Há lugares que Java poderia melhorar (ou melhor, lugares que estão pedindo socorro pra que Java melhore): desktop's.
Há lugares que a melhora de Java não irá trazer nada de novo (!), nada do que já temos hoje e que nos atende muito bem: servidores e RTOS.
Acho que ambas tecnologias não são excludentes, e sim, digamos: o Yin-Yang. Devem ser trabalhadas no lugar certo. Acho que Java deveria focar no que C/C++ pecam ou no que ainda não atendem.
Como vc pode ver, não estou sendo xiita e dizendo que Java não presta! Não, pelo contrário! Acho que presta e muito! Porem acho que estão gastando tempo onde as coisas já estão funcionando bem: pra que esperar 5 anos pelo Glass ficar igual ao KDE de hoje se já temos KDE, Gnome, CDE, FluxBox, etc etc etc (até mesmo o próprio Windows!)...?? Sendo que estes sistemas daqui 5 anos tambem estarão melhores!
Ahh, uma coisa que achei muito interessante durante minhas pesquisas, chamado JNI (já que o pessoal está lendo e gostando tb): http://www.javaworld.com/javaworld/jw-05-2001/jw-0511-legacy.html
Porra! Eu posso 'levantar' uma JVM dentro do meu código C/C++ (JNI_CreateJavaVM())!! Cacetada! Pq há programadores C/C++ que se odeiam tanto, heim?? (ehehehe. Brincadeira. Mas a surpresa é real)
Pela idéia de VM, JIT e compilar código nativo em run-time, jurava que o cenário era o contrario (único link que achei): http://forum.java.sun.com/thread.jspa?threadID=600123&messageID=3206642
Uma pergunta para entender melhor seu ponto de vista sobre 'resolução de problemas X tecnologia empregada': vc utiliza Java para tudo? Seja lá o projeto que parar hoje na sua mão, vc utiliza Java inconstitucionalmente?? Ou há problemas que vc emprega outras linguagens? E o que estes problemas apresentam de diferentes para mudar seu ponto de vista?
[]s
Comentário de a2gs
30/06/06 9:13 - usuário registrado #7691
e por fim....: http://shootout.alioth.debian.org/
(eu sou o asd, agora com nick registrado a2gs)
(eu sou o asd, agora com nick registrado a2gs)
Outra alternativa ? xgl + compiz ! Não deixa de precisar de uma placa de vídeo 3D razoável, mas o framework é em C:
http://video.google.com/videoplay?docid=-3304682858126153303&q=xgl
Já foi até notícia aqui na br-linux também:
http://br-linux.org/linux/?q=node/2842
Se vc já instalou suse 10.1 fica ainda mais fácil de ativar:
http://en.opensuse.org/Using_Xgl_on_SUSE_Linux