| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | | E no entanto ela move-se... Cirruz
|
| | | .Net (Pontos:2, Engraçado) |
| | Já usei bastante a plataforma Java em multiplos flavours (EE,ME,SE e até o PJava) e confesso que em todas as vezes que tive de batalhar com o Java senti que era algo que devia sofrer inovações profundas.
Foi portanto com alguma alegria que descobri a alternativa multiplataforma e acima de tudo multilinguagem que é a .Net Framework.
Existem ports da .Net Framework para MacOS X, acho que Free BSD (este port foi iniciado pelo pessoal da Microsoft itself), para Linux (www.go-mono.com), etc.
Para quem nunca viu e/ou considerou, recomendo uma vista de olhos sobre o que se pode fazer com a .Net Framework e vão ver que irão mudar as opiniões.
Isto tudo para dizer que o Java devia ter sido assim desde o ínicio, uma plataforma para o séc. XXI e não algo que se torna num legado!
Nada do que foi escrito deve ser levado em consideração... |
| | | | | | | | Já usaste as implementações livres que existem? O mono ou o dotGnu? Alguns exercicios do curso .NET nem sequer funcionam nessas plataformas! Ou seja, o .NET neste momento só funciona em MS. (ponto final). As implementações livres são engraçadas. excelentes fontes de código, algumas ideias novas (treecc do dotgnu, por ex), mas não são minimamente funcionais por ora. Quanto ao .NET em si, é quase uma cópia do j2ee (aquilo mapeia quase um para um!), por isso não compreendo isto Isto tudo para dizer que o Java devia ter sido assim desde o ínicio. Mesmo algumas coisas que davam a ideia de ter sido corrigidas no .NET, estão apenas disfarçadas (por exemplo, as structs passadas como genéricos são enwrapadas[!!] em objectos através de uma keyword qualquer que lá há (wrap acho eu), tal como acontece com as primitivas do java).
-- carlos |
| | | | Se já usaste webservices no .Net sabes então como é fácil de implementar aquilo! IMO é bem melhor que o RMI, que assenta em protocolo proprietário (oppss a palavra proibida ;) ). Eu sei que em Java também se podem desenvolver webservices, mas é preciso ir buscar um package extra, enfim, a seca do costume.
Eu sei, tal como tu sabes (felizmente), que a .Net é uma cópia quase integral do Java mas o que lhe dá a mais valia são as pequenas coisas (como os webservices de raiz).
Depois o Java em si baseia-se apenas numa linguagem enquanto na .Net programas no que te der mais jeito ou no que dominares melhor.
Sobre as implementações, é dar-lhes tempo para amadurecer pois ainda NÃO são versões finais.
Tenho acompanhado o desenvolvimento do go-mono e confesso que fiquei bastante entusiasmado com aquilo.
Nada do que foi escrito deve ser levado em consideração... |
| | | | | webservices no .Net sabes então como é fácil de implementar aquilo! Não sei se te referes à sua implementação através do interface visual (.NET studio) ou à quantidade de código que é preciso escrever. No último caso é mais ou menos equivalente (no .NET é ligeiramente mais fácil), quanto à parte gráfica, o .NET studio é muito bom, mas dúvido que consigas criar webservices realmente úteis (e complexos) com aquilo. Alem do mais a Sun tb tem uma solução visual para criar webservices (não me lembro do nome, mas foi demonstrada na última techtalk da sun, há coisa de duas semanas). Quanto ao facto do suporte ser de raíz ou nao, isso nem sequer é muito importante (importante é estar disponível!). Seja como for, a nova versão do j2ee (1.4) vai sair em março e já vai incluir webservices de raíz. Em relação ao protocolo RMI, apesar de ser proprietário, é aberto (== conhecido). Senão ninguém conseguia implementar JVMs em última instância. Não há nada de grave ou mágico aqui. Era preciso chamar métodos e ter acesso a dados, e a sun desenhou um pequeno protocolo (que é basicametne uma mistura entre JRMP -java remote method protocol e java serialization) para os realizar. O problema é quando esses protocolos não são conhecidos. Neste caso isso não se passa. Java em si baseia-se apenas numa linguagem enquanto na .Net Não necessariamente. Então e o JPython e o JRuby (etc)... Podes programar numa série de linguagens, desde que estas produzam java bytecode. É verdade que o java é ... java centric, mas isso é mais marketing da sun que outra coisa (basta dizer que patentearam a palavra java, de forma a que nenhum produto possa incluir "java" no nome). No caso do .NET passa-se o mesmo: podes usar as linguagens que produzam bytecode IL. As limitações e conceitos presentes em todas as linguagens vão ser os mesmos (herança singular, objectos, referências, interfaces, bla bla).
-- carlos |
| | | | | Por acaso até fui ver o slashdot e não vi lá nada degenerativo ou grotesco. Pelo menos para uma companhia que diz aos seus clientes "Tomem, usem esta coisa do Java que é bastante bom, se não se importam nós usamos outra linguagem melhor porque esta está cheia de bugs, mas vocês usem à vontade". É claro que a imagem da Sun tem que um hit por causa disto, sinceramente, nem me pareceu um hit muito forte. E já agora... o que é que tem ter sido o ComdrTaco a aprovar o artigo? Suponho que por essa ordem de ideias o Ashes também é um porco fascizoide que adora a Microsoft e quer condenar a Sun ao Inferno...
"Se vi mais além do que outro, é porque estava nos ombros de gigantes."
Sir Isaac Newton |
| | | | | | Por acaso até fui ver o slashdot e não vi lá nada degenerativo ou grotesco
A forma como o artigo é apresentado. O próprio título "Even Sun Can't Use Java". O artigo em si demonstra que o memo não foi lido, já que o mesmo se refere a alguns bugs na plataforma Solaris, apenas.
se não se importam nós usamos outra linguagem melhor porque esta está cheia de bugs
E tu, leste o artigo ?
o que é que tem ter sido o ComdrTaco a aprovar o artigo
O dever de um editor não é simplesmente "aprovar artigos". O ComdrTaco tem feito valentes asneiras, desde a aprovar artigos que já têm anos, até publicar falsos alarmes sobre novos releases de aplicações, fornecer os sites principais para downloads de distribuições ( caso recente com o FreeBSD 5.0 ), entre outras palhaçadas.
|
| | | | | O ComdrTaco tem feito valentes asneiras Pois é verdade mas quem pode, pode. Mas não me parece que este artigo tenha sido uma asneira mas sim uma maneira sensacionalista de apresentar a coisa, à laia do register e quem sabe até à laia da TVI :)
"Se vi mais além do que outro, é porque estava nos ombros de gigantes."
Sir Isaac Newton
|
| | | | Li pelo /. q o a leak do memo (sendo o mesmo autentico) pode ter sido propositado, uma medida terrorista de forcar a sun a limpar a casa...
Como se diz por ca, "em casa de ferreiro espeto de pau".
## I live the way I type; fast, with a lot of mistakes. |
| | | | Essa do ashes não anda longe da verdade :).
|
| | | | Convém apontar que não se sabe se este memo é verdadeiro ou não mas parece ter umas inconsistências e vem de um site chamado qualquer coisa como internalmemos.com. Vejam a discussão no slashdot...
|
| | | | | Tirado do memo referido: The example above of "Hello World" is a good method for getting an idea of the minimum support code required at runtime. This support code includes garbage collector, byte code interpreter, exception processor and the like. Hello World written in Java2 requires 9M for this most basic support infrastructure. By comparison, this is slightly larger than automountd on Solaris8. The Python runtime required to execute Hello World is roughly 1.6M.
...
While the Java VM (as demonstrated above) grows rapidly as more complex code is executed, the Python VM grows quite slowly. Indeed, an inventory control program written entirely in Python having a SQL database, a curses UI, and network connectivity requires only 1.7M of resident set. Oh well.... Cumprimentos Mario Valente
|
| | | | | por Anonimo Cobarde em 10-02-03 22:02 GMT (#14)
|
| Deve ser por isso q todos o telemoveis agora vêm com Python... ai nao, é Java... hmmmm
|
| | | | | Os telemoveis nao vem com Java. Vêm com um "interpretador" do bytecode IL (Java Virtual Machine e Java Runtime Environment). O bytecode tanto pode ser gerado a partir de Java , como pode ser gerado a partir de JPython, JRuby ou outras linguagens. Cumprimentos Mario Valente
|
| | | | Ou seja vêm com uma máquina virtual de Java! A comparação que é feita é entre a VM do Python e a do Java. Se usas o JPython acabas por ter bytecode Java para usar numa Java VM.
Os telemoveis nao vem com Java. Vêm com um "interpretador" do bytecode IL (Java Virtual Machine e Java Runtime Environment).
Quer dizer, para os telemóveis virem com Java necessitavam de compilador??? Ok. Não lhe chames Java, chama-lhe o que quiseres...
|
| | | | | O facto dos telemóveis correrem java, não significa necessariamente que a linguagem seja melhor ou pior tecnicamente. Muitas vezes é por uma questão comercial, ou por outros motivos, como suporte, garantia na continuidade das plataformas, evolução das mesmas, etc... No caso do java, teve a sun por trás originalmente, e actualmente tem uma série de comités formados por várias empresas (um por cada "standard" ou "plataforma") para acompanharem a coisa. No j2me (o java que corre em telemóveis) estão presentes as principais marcas que fabricam telemóveis, como a nokia e motorola (entre outros). É lógico que estas marcas fabriquem telemóveis a suportar java e não python. Aliás, não sei porquê, mas a sun consegue impor as suas scr1pting languages para programar os devices. Já a cisco tinha escolhido TCL há uns anos atrás para programar algum do seu hardware (embora tcl não seja propriamente da sun, mas está ligado). Em termos técnicos, e apesar de eu preferir python, tenho que confessar que a escolha do java foi/é melhor. O bytecode está completamente definido (os javas compilam-se primeiro em classes e essas classes é que são corridas), tem um modelo de segurança e é fortemente estática, o que retira alguma flexibilidade mas evita que muitas coisas rebentem em runtime. No caso do python, é fortemente dinâmica, não tem modelo de segurança e o bytecode está "escondido". O seu uso é desaconselhado, e não é garantido que não mude (boa, uma dupla negativa). Embora no python as coisas não sejam tão radicais como no perl, em que o bytecode é completamente interno (em python, ver 18.10.1 da library reference, para uma descricao do bytecode actual -- doc/lib/bytecodes.html). Só mais uma nota. Existe uma ideia errada que em java se programa para todos os meios (web, console apps, graphical apps, small devices, servers). Na verdade, programar em j2me/midp é mais parecido com programação em C disfarçada de java: usar poucos objectos, muitos métodos estáticos (=funções), muitas variáveis estáticas (=variáveis globais), poucas classes. Se se tentar usar as técnicas normais de java, os programas terminam rapidamente por fragmentação de memória, alem de serem lentos.
-- carlos |
| | | | | Nao sei se alguem reparou, mas o problema que eles descrevem parece ser exclusivo 'a implementacao em Solaris, nao o Java em geral: We all agree that the Java language offers many advantages over the alternatives. We would generally prefer to deploy our applications in Java but the implementation provided for Solaris is inadequate to the task of producing supportable and reliable products.
"Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."
|
| | | | ... espeto de pau... :D
O Chico-Esperto pensa sempre em cima do joelho, incapaz de levantar a cabeça para ver ao longe, pois tem a espinha partida e os olhos cravados no umbigo. |
| |
|
