At 05:40 21/7/2001 -0300, Lisias Toledo wrote:
>Mas rapaz!! T� esquecendo do Lisp, de Prolog e, creio que a mais port�vel e
>escal�vel de todas, FORTH! Nunca fui um expert em FORTH, mas ou�a um conselho
>: procure documenta��o dela e fa�a um programa pequeno mas complexo, e depois
>em uma linguagem procedural (OOP ou n�o)... Vale a pena.
>(...)
>Mas assim como a API da Java � o seu ponto mais forte (por manter-se est�vel
>em todas as implementa��es - foi isto que levou a Sun a processar a
>Microsoft), nada impede que uma API padronizada seja criada em outra
>linguagem.
>
>Creio que a consist�ncia destas APIs � tanto ou at� MAIS importante que a
>pr�pria linguagem. Logo, creio que esta caracter�stica deve ser credidata mais
>� J2EE que a Java em si...
Nossa, tirou do fundo do ba� essa hein :). Eu nunca vi uma linha sequer de
c�digo em FORTH, mas li em algum lugar que nao era estruturada. Mais ou
menos como Cobol e BASIC. Voltando ao assunto, tem que se tomar em conta
que Java s�o 3 coisas diferentes que a Sun quer vender como uma:
1 - Java, a linguagem de programa��o
2 - Java, o ambiente runtime
3 - Java, a biblioteca de classes
4 - Java, a especifica��o de c�digo bin�rio <-- Isso � o que sustenta tudo
Mas se vc prestar aten��o, as 3 primeiras sao irrelevantes. Vc pode
escrever para a plataforma Java em qualquer linguagem, pra rodar em um
ambiente de execucao implementado em qualquer plataforma, e programar sua
propria biblioteca de classes para essa linguagem, com a unica ressalva que
o seu programa gere bytecode segundo a especifica��o padr�o das m�quinas
virtuais Java. Exemplo? Jython. (www.jython.org). H� uma s�rie de
linguagens que compilam para bytecode Java
http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html . Al�m de ser
multiplataforma, Java tamb�m pode ser multilinguagem, por exemplo, vc pode
herdar classes Java de seu programa em Python, normal. .NET anyone?
Encare as APIs Java como bibliotecas din�micas. Nem todas est�o dispon�veis
em todo lugar. Se vc compilar seu programa estaticamente (em Java, escrever
e adicionar no pacote do seu programa todas as classes de que ele depende)
todo o problema � resolvido. N�o, n�o � pr�tico reimplementar HTTP ou
escrever uma nova biblioteca gr�fica a cada projeto como se faz em Linux,
Windows Mac e etc. Por isso existe a biblioteca de classes que j� faz tudo
isso, e � o ovo de colombo que a Sun promove. Em termos de possibilidade
t�cnica, nao � importante. Mas em termos de praticidade t�cnica faz muita
diferen�a.
>Eu duvido, mas eu duvido mesmo, que a dotNET consiga uma implementa��o em duas
>plataformas diferentes sem ao menos UM dos problemas que jogam pra cima do
>Java...
A CLR tem uns mecanismos interessantes, do tipo JITear todo o c�digo da
aplicacao antes da execucao, e nao apenas durante a execucao e somente as
partes mais usadas do c�digo (hot spots, como a Sun chama) como o Java. Mas
eu nao vi grandes ganhos de velocidade, est� tudo igual aqui. Talvez na
versao final eles entreguem o q prometeram. Ou n�o.
>
> > 2 - As m�quinas virtuais da Sun, IBM, Transvirtual, Borland, Microsoft,
> > Intel e etc sao livres para uso pessoal E comercial sem custo algum.
>
>Creio que o foco da discuss�o era mais sobre liberdade que custo...
Kaffe � GPL. H� algumas implementacoes GPL da API Java, como a Classpath
(http://www.gnu.org/software/classpath/classpath.html). Nada tao completo
qt as implementacoes propriet�rias, mas est� l� para quem quiser ajudar.
N�o � assim que funciona?
>Eu n�o concordo que Java no cliente � bloatware. Eu diria que Java no Desktop
>� bloatware (escrever um Office em Java, por exemplo, para mim � rid�culo -
>escrever um SO inteiro, s� como prova de conceito...
>http://javaos.sourceforge.net). Existem diversas pequenas aplica��es Java que
>s�o muito convenientes para se rodar num cliente... Especialmente aquelas em
>que a performance n�o � importante... 8-P
D� uma sacada nos sisteminhas do BBV. A interface de usu�rio deles � toda
em Java. N�o, nao � o melhor exemplo de aplicacoes end-user, mas pelo menos
� uma prova de que as pessoas estao usando. As m�quinas que eu vi eram
Dells novas, entao a performance nao � tao importante aqui. Podia ser feito
em Delphi, C++? Podia, e mais r�pido. Mas a integracao da interface de
usuario com o sistema deles rodando no servidor, via RMI, � algo q nao se
alcan�a em outra plataforma. Mas para o usuario, nao deixa de ser bloatware
se estiver rodando em um Pentium 100 =). Eu me lembro que j� vi uma noticia
de uns loucos que estavam portando Quake para a Java3D
(http://www.javasoft.com/products/java-media/3D/index.html).
>Mas o que eu disse sobre o 486 com Win95 vale aqui tbm... � *realmente
>necess�rio* ter a melhor performance poss�vel em Linux? A diferen�a entre usar
>uma box Linux mais potente para igualar a performance de uma outra box (win32
>por exemplo) n�o tem melhor custo/benef�cio do que usar uma plataforma
>propriet�ria (digo, paga)???
O que eu ganho em usar uma plataforma gr�tis que me custa 3x mais em
hardware para ter desempenho igual � plataforma propriet�ria? No caso do
Java, eu estou incluindo SIM as m�quinas Solaris/SPARC. Afinal, hoje vc
compra uma delas por 900 d�lares.
No final, vc nunca � 100% livre. O processador compat�vel com Intel q vc
est� usando � propriet�rio, e quem clona tem que pagar royalties. Gotcha :)
--
Thiago Pimentel
Preview Tecnologia
He who fights and run away lives to fight another day.
-- Bob Marley
Assinantes em 21/07/2001: 2242
Mensagens recebidas desde 07/01/1999: 124060
Historico e [des]cadastramento: http://linux-br.conectiva.com.br
Assuntos administrativos e problemas com a lista:
mailto:[EMAIL PROTECTED]
