Agora sim: GCC 4.1 lançado
“No último dia do mês de fevereiro, e não em novembro passado como anunciado erroneamente no Slashdot, foi disponibilizada à comunidade a versão 4.1.0 do GCC (GNU Compiler Collection) com algumas mudanças . O GCC inclui front-ends para as linguagens C, C++, Objective C, Fortran, Java e Ada e bibliotecas para as mesmas. Agora sim estmos mais perto de ter um compilador livre para Java capaz de traduzir bytecodes ou código Java para código nativo de máquina. E a distribuição Fedora já o incorporou e em sua versão Core 5 estará disponível juntamente com o GCC 3.2 como alternativa por motivos de compatibilidade. Lembre-se que no comitê que dirige o desenvolvimento do GCC estão presentes três funcionários da Red Hat, apesar dessas afiliações serem somente para auxiliar na identificação dos mesmos, sendo que eles não representam os interesses de suas instituições.
Seguindo a filosofia de software livre você também pode contribuir com o projeto com novas funcionalidades, solucionando bugs, atualizando a documentação, melhorando as páginas web, realizando testes, etc... Informe-se no site do GCC.” A nota foi enviada por Fausto C. de Siqueira (fausto·siqueiraΘgmail·com) , que enviou este link para mais detalhes.
(postado por Augusto Campos)
Comentários dos leitores
Comentário de Ark
02/03/06 8:27
Desempenho: Será que melhoraram o péssimo desempenho com c++?
Comentário de nemesis
02/03/06 9:55 - usuário registrado #1514
melhoraram: basta programar em C. :)
;; ((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 Fernando Pimentel
02/03/06 9:58
Moderação: Pessoal, acho que voçês deveriam ir mais devagar com o recurso moderação.
Ultimamente tenho visto vários comentários sem nenhum indício de ofensa/flame moderados.
Bom senso sempre é bem vindo =)
Ultimamente tenho visto vários comentários sem nenhum indício de ofensa/flame moderados.
Bom senso sempre é bem vindo =)
Comentário de rafaelsouzaf
02/03/06 12:11
Compilar qual versão do Java?: E será que o compilador já suporta a versão 1.5 do Java? Provavelmente não, deve suportar apenas a versão 1.4.
E logo vai sair a versão 1.6 (mustang).
E logo vai sair a versão 1.6 (mustang).
Comentário de nemesis
02/03/06 12:15 - usuário registrado #1514
e logo mais...: ... a versão 1.7 ( mustard ), e 1.8, 1.9 ...
enquanto isso, velhos apps java 1.1 e 1.2 continuam rodando e recebendo manutenção...
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
enquanto isso, velhos apps java 1.1 e 1.2 continuam rodando e recebendo manutenção...
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de Felipe Raposo
02/03/06 12:48 - usuário registrado #226
Moderação: Fernando, pelo que eu sei, o Augusto alterou o padrão do site e todos os comentários de usuários não "logados" aparecerão como se tivessem sido moderados. Acho que você tem que ir em algum lugar para alterar isso, mas eu não sei onde é.
Felipe Raposo
Felipe Raposo
Comentário de espardo
02/03/06 14:17 - usuário registrado #200
apesar disso...: A maioria das aplicações em versões anteriores rodam (quase) sem problemas nas máquinas virtuais mais recentes.
--
Direito de escolha combina com software livre. (Augusto Campos)
JID: emerson.pardo
--
Direito de escolha combina com software livre. (Augusto Campos)
JID: emerson.pardo
Comentário de nemesis
02/03/06 14:23 - usuário registrado #1514
e agora tmb com GCJ :)
: e agora tmb com GCJ :)
;; ((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 Marco Aurélio
02/03/06 14:28
Se a preocupação é com o compilador...: Se a preocupação é com o compilador apenas, use o do Eclipse. É livre, suporta Java 1.5, é o mais rápido que existe, dentre N outras características interessantes. E provavelmente acompanhará as outras versões do Java.
Mesmo o GCJ já alcançou um patamar interessante. Compila e roda o Eclipse, Tomcat, para citar alguns bons exemplos. E o suporte ao Java 5 está próximo (o Classpath em si já suporta).
Aliás, essa possível corrida de versões do Java, ao meu ver, é inútil. A maioria sequer utiliza os novos recursos do Java 5. E as futuras versões do Java parecem remediar necessidades de grupos bem pequenos de desenvolvimento ou coisas que acadêmicos adoram, mas que na prática ficam juntando poeira e que a imensa maioria nunca vai dar por falta. Parece-me mais uma maneira da SUN desencorajar projetos livres, que não conseguem acompanhar tantas especificações (sim, que é o que o JCP melhor sabe fazer).
É legal ser bleeding edge, mas até certo ponto. Que tal todo mundo escrever em C99 ou de acordo com uma especificação recente do C++? Isso ninguém cobra né? E, ao mesmo tempo, o mundo continua girando... e bem.
Mesmo o GCJ já alcançou um patamar interessante. Compila e roda o Eclipse, Tomcat, para citar alguns bons exemplos. E o suporte ao Java 5 está próximo (o Classpath em si já suporta).
Aliás, essa possível corrida de versões do Java, ao meu ver, é inútil. A maioria sequer utiliza os novos recursos do Java 5. E as futuras versões do Java parecem remediar necessidades de grupos bem pequenos de desenvolvimento ou coisas que acadêmicos adoram, mas que na prática ficam juntando poeira e que a imensa maioria nunca vai dar por falta. Parece-me mais uma maneira da SUN desencorajar projetos livres, que não conseguem acompanhar tantas especificações (sim, que é o que o JCP melhor sabe fazer).
É legal ser bleeding edge, mas até certo ponto. Que tal todo mundo escrever em C99 ou de acordo com uma especificação recente do C++? Isso ninguém cobra né? E, ao mesmo tempo, o mundo continua girando... e bem.
Comentário de nemesis
02/03/06 15:02 - usuário registrado #1514
ecj: "É livre, suporta Java 1.5, é o mais rápido que existe, dentre N outras características interessantes."
e é apenas um compilador de bytecodes. vamos precisar de uma boa VM livre para rodá-los... oops! sem sorte, hein?...
"Que tal todo mundo escrever em C99 ou de acordo com uma especificação recente do C++?"
por falar nisso, o Stroustrup vem dando uma canja do que vem por aí em C++:
http://www.artima.com/cppsource/cpp0x.html
http://www.research.att.com/~bs/popl06.pdf
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
e é apenas um compilador de bytecodes. vamos precisar de uma boa VM livre para rodá-los... oops! sem sorte, hein?...
"Que tal todo mundo escrever em C99 ou de acordo com uma especificação recente do C++?"
por falar nisso, o Stroustrup vem dando uma canja do que vem por aí em C++:
http://www.artima.com/cppsource/cpp0x.html
http://www.research.att.com/~bs/popl06.pdf
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de Teppic
02/03/06 19:58 - usuário registrado #2893
Não vou mudar: Por ora não vejo nenhum motivo para mudar de versão de compilador, continuo com meu 3.4.4.
Comentário de escovadordebit
02/03/06 23:58 - usuário registrado #282
Ô beleza..: Coisa bonita de se ver...
Quando se trata de linguagens de programação a paixão aparece do mesmo modo que usuários defendem suas distros preferidas.
Chega a lembrar aquela guerrinha do Linus e do Tanenbaum.
Quase guerra santa...
Linux user #226380
"Linux é amigável... Ele apenas sabe escolher os amigos."
Quando se trata de linguagens de programação a paixão aparece do mesmo modo que usuários defendem suas distros preferidas.
Chega a lembrar aquela guerrinha do Linus e do Tanenbaum.
Quase guerra santa...
Linux user #226380
"Linux é amigável... Ele apenas sabe escolher os amigos."
Comentário de Hugo
03/03/06 1:41 - usuário registrado #9
Eclipse não é compilador,: Eclipse não é compilador, é IDE.... uma IDE muito boa por sinal.. pena que come memória demais...
Todas as coisas novas do java 1.5 são uteis... generics, enuns, etc... algumas são apenas "syntax sugar" como o novo uso do
Pelo menos eu e o pessoal que conheço que programa em C++ programa de acordo com a sepecificação mais recente do C++ e ainda espera ancioso para sair logo o prometido C++0x.
--
"Precisamos de mais gênios humildes no mundo, hoje somos poucos!"
JID: hugo@jabber.org
Todas as coisas novas do java 1.5 são uteis... generics, enuns, etc... algumas são apenas "syntax sugar" como o novo uso do
for, Java sem generics é horrivel... 1 milhão de casts...
Pelo menos eu e o pessoal que conheço que programa em C++ programa de acordo com a sepecificação mais recente do C++ e ainda espera ancioso para sair logo o prometido C++0x.
--
"Precisamos de mais gênios humildes no mundo, hoje somos poucos!"
JID: hugo@jabber.org
Comentário de Marco Aurélio
03/03/06 1:46
> e é apenas um compilador d: > e é apenas um compilador de bytecodes. vamos precisar de uma boa VM
> livre para rodá-los... oops! sem sorte, hein?...
Cuidado com os detalhes. O comentário perguntava sobre um _compilador_, não sobre uma _máquina virtual_. No meu comentário, eu reforcei que existe um _compilador_ muito bom para isso. Dependendo do que você faz (uma máquina integradora, geradora de builds), é mais do que suficiente. De fato, os desenvolvedores do suporte ao Java 5 no gcj pensaram em jogar fora tudo que fizeram na parte 'compilador da coisa' e usar esse compilador do Eclipse no gcj 4.2. Veja, até eles reconhecem que são duas coisas (compilador e VM) que, juntas, formam a tecnologia Java (que a SUN tanto protege no seu conjunto). Bom, de fato, é compilador (javac/gcj) + VM (java/gij) + bibliotecas (re/classpath).
Mas, de fato, uma JVM livre seria uma boa idéia. Agora que, mais de uma década depois de criada a linguagem, a SUN, de certa forma, abriu "um pouco" as portas para a criação de uma implementação livre do Java, talvez a coisa mude de cenário. Mas não será com o gcj, a maioria está apostando no Harmony, mistura de kaffe (lembra-se disso?) e Classpath. Ah, e basta botar o compilador do Eclipse para fechar a equação.
> livre para rodá-los... oops! sem sorte, hein?...
Cuidado com os detalhes. O comentário perguntava sobre um _compilador_, não sobre uma _máquina virtual_. No meu comentário, eu reforcei que existe um _compilador_ muito bom para isso. Dependendo do que você faz (uma máquina integradora, geradora de builds), é mais do que suficiente. De fato, os desenvolvedores do suporte ao Java 5 no gcj pensaram em jogar fora tudo que fizeram na parte 'compilador da coisa' e usar esse compilador do Eclipse no gcj 4.2. Veja, até eles reconhecem que são duas coisas (compilador e VM) que, juntas, formam a tecnologia Java (que a SUN tanto protege no seu conjunto). Bom, de fato, é compilador (javac/gcj) + VM (java/gij) + bibliotecas (re/classpath).
Mas, de fato, uma JVM livre seria uma boa idéia. Agora que, mais de uma década depois de criada a linguagem, a SUN, de certa forma, abriu "um pouco" as portas para a criação de uma implementação livre do Java, talvez a coisa mude de cenário. Mas não será com o gcj, a maioria está apostando no Harmony, mistura de kaffe (lembra-se disso?) e Classpath. Ah, e basta botar o compilador do Eclipse para fechar a equação.
Comentário de CWagner
03/03/06 2:19 - usuário registrado #49
Cada um defende aquilo que ac: Cada um defende aquilo que acha certo.
Só acho errado inventar defeitos dos outros produtos, fazendo parecer que a sua escolha é melhor. Se há defeitos devem ser apontados, e cada lado deve ser humilde em aceitar os problemas de suas escolhas, na boa.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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!
Só acho errado inventar defeitos dos outros produtos, fazendo parecer que a sua escolha é melhor. Se há defeitos devem ser apontados, e cada lado deve ser humilde em aceitar os problemas de suas escolhas, na boa.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 Marco Aurélio
03/03/06 2:20
> Eclipse não é compilador,: > Eclipse não é compilador, é IDE.... uma IDE muito boa por sinal..
> pena que come memória demais...
Alguns já diriam que o Eclipse é um megazord project, sendo a IDE é um dos seus produtos. Outros podem dizer que ele é outro Emacs da vida. Mas, enfim, a questão é que, se você ler com calma a frase que escrevi, "Se a preocupação é com o compilador apenas, use o do Eclipse", perceberás que o "o" (entre o "use" e o "do") tem implícito o "compilador".
Quanto a comer muita memória, infelizmente todas as IDE Java devoram a memória da máquina. IDE para Java em Java é bonito, mas... qual seria o problema em escrever em outra linguagem, como C ou C++? :-)
> Todas as coisas novas do java 1.5 são uteis... generics, enuns,
> etc... algumas são apenas "syntax sugar" como o novo uso do for,
> Java sem generics é horrivel... 1 milhão de casts...
Concordo com as novidades do Java 5, principalmente o generics. Enuns... não utilizei até hoje para o que desenvolvi. O novo 'for' até que faz sentido, facilita um pouco e evita erros bestas, acho que a intenção foi boa. O que me chateia são as "inovações" do Java 6 e daí pra frente. Toda vez que leio a Java Magazine, tem um artigo descrevendo as maravilhas da próxima versão, uma supermegazord otimização no locking, que será muito útil para servidores de banco de dados de alta performance/escalabilidade. Ou então uma nova característica (clousures), ou sei lá mais o que. Coisas que outras linguagem, como Python, querem matar, porque ninguém usa (lambda em Python, mais especificamente) e que outras linguagens, funcionais, executam com maestria há anos, décadas.
De repente, eles querem fazer uma solução que se encaixa para todas as situações. Isso é insano. Bate de frente com a filosofia do Unix. É um terror para manter. Dificulta a construção de implementações livres.
> Pelo menos eu e o pessoal que conheço que programa em C++ programa
> de acordo com a sepecificação mais recente do C++ e ainda espera
> ancioso para sair logo o prometido C++0x.
Daqui a pouco saí o TR2. O gcc até que fornecia, para C, em algum canto do site, uma comparação do que ele faz e o que a especificação da linguagem exigia. Existe algo do gênero em C++? Seria legal saber isso.
Sobre o C++0x, procuro sobre ele no Google, no primeiro artigo que leio, o que vejo: "Bjarne offers a sneak peek at the next version of standard C++ ("C++0x") which should be complete by 2009.". 2009? Para o standard? Mais outros anos para a implementação (ao menos uma razoável). É tempo hein, melhor dar uma baixada nessa ansiedade pelo C++0x (que, se duvidar, vira C++xx).
> pena que come memória demais...
Alguns já diriam que o Eclipse é um megazord project, sendo a IDE é um dos seus produtos. Outros podem dizer que ele é outro Emacs da vida. Mas, enfim, a questão é que, se você ler com calma a frase que escrevi, "Se a preocupação é com o compilador apenas, use o do Eclipse", perceberás que o "o" (entre o "use" e o "do") tem implícito o "compilador".
Quanto a comer muita memória, infelizmente todas as IDE Java devoram a memória da máquina. IDE para Java em Java é bonito, mas... qual seria o problema em escrever em outra linguagem, como C ou C++? :-)
> Todas as coisas novas do java 1.5 são uteis... generics, enuns,
> etc... algumas são apenas "syntax sugar" como o novo uso do for,
> Java sem generics é horrivel... 1 milhão de casts...
Concordo com as novidades do Java 5, principalmente o generics. Enuns... não utilizei até hoje para o que desenvolvi. O novo 'for' até que faz sentido, facilita um pouco e evita erros bestas, acho que a intenção foi boa. O que me chateia são as "inovações" do Java 6 e daí pra frente. Toda vez que leio a Java Magazine, tem um artigo descrevendo as maravilhas da próxima versão, uma supermegazord otimização no locking, que será muito útil para servidores de banco de dados de alta performance/escalabilidade. Ou então uma nova característica (clousures), ou sei lá mais o que. Coisas que outras linguagem, como Python, querem matar, porque ninguém usa (lambda em Python, mais especificamente) e que outras linguagens, funcionais, executam com maestria há anos, décadas.
De repente, eles querem fazer uma solução que se encaixa para todas as situações. Isso é insano. Bate de frente com a filosofia do Unix. É um terror para manter. Dificulta a construção de implementações livres.
> Pelo menos eu e o pessoal que conheço que programa em C++ programa
> de acordo com a sepecificação mais recente do C++ e ainda espera
> ancioso para sair logo o prometido C++0x.
Daqui a pouco saí o TR2. O gcc até que fornecia, para C, em algum canto do site, uma comparação do que ele faz e o que a especificação da linguagem exigia. Existe algo do gênero em C++? Seria legal saber isso.
Sobre o C++0x, procuro sobre ele no Google, no primeiro artigo que leio, o que vejo: "Bjarne offers a sneak peek at the next version of standard C++ ("C++0x") which should be complete by 2009.". 2009? Para o standard? Mais outros anos para a implementação (ao menos uma razoável). É tempo hein, melhor dar uma baixada nessa ansiedade pelo C++0x (que, se duvidar, vira C++xx).
Comentário de Marco Aurélio
03/03/06 2:23
Tens é um bom motivo para ma: Tens é um bom motivo para manter-se no gcc 3.4.4. Gera código rápido e enxuto. O problema é que, para C++, o gcc 4.x é mais completo e está melhrando bastante (DSO, por exemplo). E, a partir do gcc 4.2, provavelmente o código gerado será melhor também.
Comentário de nemesis
03/03/06 7:15 - usuário registrado #1514
bytecodes: Compiladores para bytecode é o que mais tem por aí. É fácil, qualquer um pega o yacc/bison, alimenta com a especificação BNF de Java e já é um começo. VMs é que são o bicho, especialmente com JIT e bom desempenho.
É uma das razões para o GCJ ter preferido jogar fora a etapa de uma VM e partir para geração de código nativo mesmo. Solução única até agora.
A "maioria" -- que, acredito, vc esteja se referindo à indústria -- está apostando no Harmony pq não é licenciado pela GPL e pq recebe o apoio e contribuições de papai IBM: uma VM aqui, um classloader ali etc... assim, até eu crio uma implementação de java...
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
É uma das razões para o GCJ ter preferido jogar fora a etapa de uma VM e partir para geração de código nativo mesmo. Solução única até agora.
A "maioria" -- que, acredito, vc esteja se referindo à indústria -- está apostando no Harmony pq não é licenciado pela GPL e pq recebe o apoio e contribuições de papai IBM: uma VM aqui, um classloader ali etc... assim, até eu crio uma implementação de java...
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de nemesis
03/03/06 7:19 - usuário registrado #1514
generics: "Java sem generics é horrivel..."
E a despeito disso, programou-se em java durante todo esse tempo. Bom, se vale de alguma coisa, java *com* generics continua horrível... ;)
de qualquer modo, parece irônico tal comentário da parte de um programador C++... ;)
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
E a despeito disso, programou-se em java durante todo esse tempo. Bom, se vale de alguma coisa, java *com* generics continua horrível... ;)
de qualquer modo, parece irônico tal comentário da parte de um programador C++... ;)
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de nemesis
03/03/06 7:19 - usuário registrado #1514
generics: ;; ((lambda (x) x) "Isto é um comentário duplicado")
Comentário de nemesis
03/03/06 7:51 - usuário registrado #1514
paradigmas: "Outros podem dizer que ele é outro Emacs da vida."
Emacs costumava ser chamado "Eight Megabytes And Constantly Swapping". Eclipse poderia se chamar "Eighty Megabytes And Constantly Swapping", exceto que o acrônimo não faz sentido... ;)
"IDE para Java em Java é bonito, mas... qual seria o problema em escrever em outra linguagem, como C ou C++? :-)"
O problema é que eles não poderiam usar uma VM java embutida para prover análise sintática e semântica para autocompleção textual e criação de componentes ( beans ), debuggers integrados etc
Enfim, java requer java, o que é duplamente redundante e lamentável.
"Coisas que outras linguagem, como Python, querem matar, porque ninguém usa (lambda em Python, mais especificamente)"
Python realmente tem se tornado muito mainstream e começa a dar seus chiliques. É bom realmente tirarem seu lambda, que é extremamente limitado. E map, reduce e outros não fazem realmente muito sentido em Python, que é uma linguagem essencialmente imperativa e OO. Python tem tentado agradar programadores Java já há um bom tempo...
Quanto mais tempo eu passo com Python, mais gosto de meu Scheme. :)
"De repente, eles querem fazer uma solução que se encaixa para todas as situações."
Bom, em defesa deles, uma máquina virtual de propósito geral -- ao invés de feita pensando-se apenas na linguagem java -- seria interessante. Há uma proposta atual para tornar a VM mais amigável à linguagens dinamicamente tipadas, com a introdução de uma primitiva -- invokedynamic...
"Bate de frente com a filosofia do Unix."
Se vc pensar a respeito, Java não tem muito a ver com a filosofia *nix. Pequenos componentes de software executando tarefas específicas? ahã... Tudo são fluxos de caracteres? não fosse pelo porrilhão de classes...
Java nasceu de C++, que embora crescida na cultura *nix e C, só encontrou real massificação quando se tornou a linguagem de implementação da MFC da M$...
ok, a cultura por trás de Java foi diversa: C/C++, *nix, Win, Lisp...
por isso é um monstrengo... ;)
"É um terror para manter. Dificulta a construção de implementações livres."
haha, boa Sun!
"2009? Para o standard? Mais outros anos para a implementação (ao menos uma razoável). É tempo hein, melhor dar uma baixada nessa ansiedade pelo C++0x (que, se duvidar, vira C++xx)."
É engraçado mesmo essa evolução de linguagens que já tem estrada. Por que significa que "dialetos" da mesma estarão sempre em constante uso na indústria. O guri aprendendo Java hoje na faculdade vai encontrar alguma dificuldade para manter código de legado de Java 1.1 ou 1.2.
Com C++ o problema é ainda pior, pois ainda tem gente que usa C++ apenas como C sem printf ( cout << etc ), C com classes, C++ básico, C++ com templates, C++ com boost e C++ funcional com boost::lambda e similares... ;)
No fim das contas, programador de um dialeto tem dificuldades para lidar com código de outro. Uma das razões para eu achar que se familiarizar com um bocado de linguagens e paradigmas diferentes é uma boa pedida nessa profissão...
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Emacs costumava ser chamado "Eight Megabytes And Constantly Swapping". Eclipse poderia se chamar "Eighty Megabytes And Constantly Swapping", exceto que o acrônimo não faz sentido... ;)
"IDE para Java em Java é bonito, mas... qual seria o problema em escrever em outra linguagem, como C ou C++? :-)"
O problema é que eles não poderiam usar uma VM java embutida para prover análise sintática e semântica para autocompleção textual e criação de componentes ( beans ), debuggers integrados etc
Enfim, java requer java, o que é duplamente redundante e lamentável.
"Coisas que outras linguagem, como Python, querem matar, porque ninguém usa (lambda em Python, mais especificamente)"
Python realmente tem se tornado muito mainstream e começa a dar seus chiliques. É bom realmente tirarem seu lambda, que é extremamente limitado. E map, reduce e outros não fazem realmente muito sentido em Python, que é uma linguagem essencialmente imperativa e OO. Python tem tentado agradar programadores Java já há um bom tempo...
Quanto mais tempo eu passo com Python, mais gosto de meu Scheme. :)
"De repente, eles querem fazer uma solução que se encaixa para todas as situações."
Bom, em defesa deles, uma máquina virtual de propósito geral -- ao invés de feita pensando-se apenas na linguagem java -- seria interessante. Há uma proposta atual para tornar a VM mais amigável à linguagens dinamicamente tipadas, com a introdução de uma primitiva -- invokedynamic...
"Bate de frente com a filosofia do Unix."
Se vc pensar a respeito, Java não tem muito a ver com a filosofia *nix. Pequenos componentes de software executando tarefas específicas? ahã... Tudo são fluxos de caracteres? não fosse pelo porrilhão de classes...
Java nasceu de C++, que embora crescida na cultura *nix e C, só encontrou real massificação quando se tornou a linguagem de implementação da MFC da M$...
ok, a cultura por trás de Java foi diversa: C/C++, *nix, Win, Lisp...
por isso é um monstrengo... ;)
"É um terror para manter. Dificulta a construção de implementações livres."
haha, boa Sun!
"2009? Para o standard? Mais outros anos para a implementação (ao menos uma razoável). É tempo hein, melhor dar uma baixada nessa ansiedade pelo C++0x (que, se duvidar, vira C++xx)."
É engraçado mesmo essa evolução de linguagens que já tem estrada. Por que significa que "dialetos" da mesma estarão sempre em constante uso na indústria. O guri aprendendo Java hoje na faculdade vai encontrar alguma dificuldade para manter código de legado de Java 1.1 ou 1.2.
Com C++ o problema é ainda pior, pois ainda tem gente que usa C++ apenas como C sem printf ( cout << etc ), C com classes, C++ básico, C++ com templates, C++ com boost e C++ funcional com boost::lambda e similares... ;)
No fim das contas, programador de um dialeto tem dificuldades para lidar com código de outro. Uma das razões para eu achar que se familiarizar com um bocado de linguagens e paradigmas diferentes é uma boa pedida nessa profissão...
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de Hugo
03/03/06 10:44 - usuário registrado #9
Programo em java "forçado" p: Programo em java "forçado" pela universidade... onde tudo gira em torno do Java... quando volto de uma greve de X meses pode ter certeza que fazem exatamente X meses que não programo em java.
O generics do java5 ajudam... e isso por que infelizmente os generics só servem praticamente para "fazer um container do tipo T"...
--
"Precisamos de mais gênios humildes no mundo, hoje somos poucos!"
JID: hugo@jabber.org
O generics do java5 ajudam... e isso por que infelizmente os generics só servem praticamente para "fazer um container do tipo T"...
--
"Precisamos de mais gênios humildes no mundo, hoje somos poucos!"
JID: hugo@jabber.org
Comentário de lscalado
03/03/06 10:57 - usuário registrado #4083
JCreator Pro: Existe o JCreator Pro, que é muito bom. Gosto bastante é rápida e feita em C++