On 3 Apr 2003, at 9:36, Alexandre Monteiro Janoni wrote:
> http://www.portaldaprogramacao.com/artigos2.asp?n=104 Eu achei muito engracada a lista de "vantagens" do C# sobre o Java. Torcidas organizadas aa parte, vamos e- xaminar algumas delas: 1 - "Compilado para c�digo nativo Java: Raramente. O Java � quase sempre interpretado." (Nosso amigo autor do artigo certamente nunca ouviu falar em JIT.) "C#: Sempre compilado para c�digo nativo. A compila��o pode ser feita na instala��o ou na primeira execu��o do programa." Ou seja: perde-se a portabilidade do binario ao e- xecutar a 1a. vez. Isso eh "vantagem" ? Ok. 2 - "Todos os tipos derivados de ancestral comum" "Java: N�o." Excelente! Se eu quiser um boolean apenas, ocupo um byte da memoria, e nao o espaco de um objeto intei- ro, apenas para guardar um estado logico! Sem contar que eh um objeto a menos para o garbage collector tratar... "C#: Sim, todos os tipos s�o derivados de object." Duh... Novamente nao entendi a "vantagem". Mas vamos adiante... 3 - "'Boxing' e 'Unboxing' - convers�o de tipos por valor para tipos por refer�ncia" "Java: N�o. Exige convers�o manual." "C#: Sim." Ei, estamos falando de uma linguagem fortemente tipa- da. Nao de Visual Basic. Conversao automatica signi- fica execucao mais lenta, porque a toda hora o runtime tem que ficar checando tipos de dados. Tipagem forte significa checagem sendo feita apenas em tempo de com- pilacao, nao de execucao - logo, o codigo roda mais rapido! Cade a "vantagem", que eu ainda nao vi ? Ok, vamos ser pacientes, devem estar todas no final... 4 - "Structs" "Java: N�o." "C#: Sim." Essa eu confesso que nao entendi: ele estah se refe- rindo a estruturas do C ? Mas vem cah, se Java eh uma linguagem TOTALMENTE ORIENTADA A OBJETO, que sentido faz suportar estruturas de dados C-like ? 5 - "Enum" "Java: N�o." "C#: Sim." Ok, aqui dou o braco a torcer: eu ateh que gostaria de ter tipos enumerados em Java. Com eles, dah para escrever um codigo mais claro e legivel do que ficar fazendo coisas do tipo: public final static int MINHA_CONSTANTE_1 = 1; public final static int MINHA_CONSTANTE_2 = 2; Mas nada que me tire o sono ou me faca correr deses- perado para o C#. Vamos adiante. 6 - "Passagem de par�metros por refer�ncia" "Java: N�o." "C#: Sim, de duas maneiras: ref para par�metros de entrada e sa�da e out para par�metro apenas de sa�da." Sinceramente ? Prefiro assim. Porque ? Bom, para qual plataforma voces acham que eh mais facil surgir uma falha de seguranca explorando justamente acessos ilegais aa areas de memoria ? 7 - "Propriedades" "Java: N�o. Podem ser simuladas com m�todos Get/Set, com alguma dificuldade." "C#: Sim, diretamente. A cria��o de �componentes� � bastante facilitada." Componentes visuais. Mas o conceito de componente vai alem de uma GUI com iconezinhos para arrastar num formulario. Um EJB eh um componente; uma servlet, um portlet, e por aih vai. Todos com propriedades e metodos, passiveis de customizacao. A unica diferen- ca eh que no Java nao se usa uma GUI (ateh existe su- porte a programar desta maneira em algumas ferramen- tas, como o Visual Age for Java, mas nunca usei - e sinceramente, nao me fez falta). Eu gostaria de saber se ele saberia escrever uma aplicacao em C# sem a GUI... :) 8 - "Eventos e Delegates" "Java: N�o, categoricamente (veja link abaixo)." "C#: Sim. Um �delegate� � um �ponteiro de fun��o orientado a objetos�, permitindo a associa��o de um evento de uma classe ao c�digo de outra de maneira conceitualmente simples e poderosa." Novamente: isso eh plenamente possivel de ser feito em Java. Apenas, nao eh visual (selecionar um even- to num object inspector, e selecionar um metodo pronto ou escrever um novo). 9 - "Atributos" "Java: N�o." "C#: Sim, permitindo �etiquetar� o c�digo com caracter�sticas que s�o interrogadas em tempo de execu��o atrav�s de �reflection�." Vide acima. 10 - "Ponteiros" "Java: N�o suportado diretamente, apenas indiretamente atrav�s de �refer�ncias�." "C#: A princ�pio suporta refer�ncias, mas os ponteiros podem ser usados em c�digo �inseguro� por quest�es de performance ou compatibilidade com DLLs." Alguem mais estah sentindo cheiro de falhas de se- guranca e codigo amarrado aa plataforma Windows ? 11 - "Sobrecarga de operadores" "Java: N�o." "C#: Sim." Se com "sobrecarga de operadores" ele estah falando de sobrecarga de metodos, nosso amigo estah por fo- ra, mesmo... 12 - "Operadores de convers�o" "Java: N�o." "C#: Sim." Dispensaveis gracas aa forte tipagem da linguagem. 13 - "Operadores de cast" "Java: Um, sintaxe semelhante ao C/C++." "C#: Dois, um semelhante ao C/C++ e o outro �as�. Um retorna null e outro dispara exception em casso de erro de convers�o." Ou seja, seu codigo pode compilar e ainda sim estar errado. Eh por isso que a tipagem forte do Java eh melhor. Ele realmente acha isso "vantagem" ? 14 - "Inteiros sem sinal" "Java: N�o." "C#: Sim." Realmente, nao existem inteiros sem sinal no Java. Tambem nao existem no Pascal, Visual Basic e um monte de outras linguagens. Na verdade, soh existem inteiros unsigned no C e C++, pelo que Lembro. E ainda assim o mundo nao acabou. 15 - "Tipo num�rico pouco sujeito a erros de representa��o e arredondamento" "Java: N�o." "C#: Sim, o tipo decimal pode ser usado em softwares que n�o toleram facilmente erros de arredondamento, como programas de contabilidade" java.text.NumberFormat java.util.Currency Simples e preciso. 16 - "Forech: loop para varrer arrays e cole��es" "Java: N�o." "C#: Sim." 17 - "Campo readonly" "Java: N�o." "C#: Sim." Simples: nao implemente o metodo set do atributo. Duh... 17 - "Documenta��o integrada em XML" "Java: N�o." "C#: Sim, permitindo que o programador escreva facilmente a documenta��o enquanto programa. Este documenta��o pode depois ser extra�da do fonte ou usada no pr�prio ambiente de desenvolvimento." Ele jah ouviu falar de JavaDoc ? 18 - "Switch com strings" "Java: N�o." "C#: Sim, facilitando o desenvolvimento." E diminuindo a performance. Internamente, o switch comparando strings eh construido de forma diferen- te (e mais lenta) do que usando um literal (int, char ou coisa que o valha). Resta saber o que eh melhor: ter uma vez o conforto de usar um string para controlar um processo, ou escrever um codigo que gera um opcode menor e execute mais rapido to- das as vezes. 19 - "Controle sobre �estouro de faixa� num�rica" "Java: N�o." "C#: Sim. As palavras reservadas checked e unchecked permitem mudar o que o programa faz quando h� um �estouro de faixa num�rica�: o checked dispara uma exception; o unchecked n�o." Ou seja, eh um bypass do mecanismo de tratamento de excecao. Para quem jah estah acostumado a lidar com try - catch, eh um superfluo. E quem nao estah, eventualmente vai ter que se acostumar, porque to- dos os outros tipos de erro geram excecoes, e nao tem como desliga-las todas. 20 - "Fun��es com n�mero vari�vel de par�metros" "Java: N�o." "C#: Sim, de forma �tipada�, com a palavra reservada params." Oh... Tem razao: eu nao consigo escrever codigo dubio e pouco legivel facilmente com Java. Que droga. 21 - "Formas do m�todo Main" "Java: Uma." "C#: Quatro. O main pode aceitar um array de strings ou nada; pode retornar inteiro ou nada." Este eh o segundo ponto em que eu realmente acho que o Java peca: o metodo Main() nao faz qualquer retor- no ao sistema operacional sobre o status final da e- xecucao. Isso pode ser util no caso de execucao a partir de shell scripts no Unix. 22 - "Goto" "Java: N�o." "C#: Sim, com a restri��o de que n�o pode entrar em um bloco." Java nao tem GOTO! Java nao eh BASIC! Vamos todos dizer: AMEM! Qualquer curso de programacao serio jah aboliu o GOTO faz alguns anos. Seja em qual linguagem for. Eh altamente prejudicial para a legibilidade do codigo e modularizacao. Ateh em Cobol se proibe o uso de GOTO hoje em dia, e vem nosso amigo anunciar isso como "vantagem"... Soh se for para o Java. 23 - "Arquivo �execut�vel� independente do namespace" "Um �package� Java obrigatoriamente est� associado a um �nico arquivo �.class�." "N�o existe rela��o direta entre o �namespace� e a DLL que o implementa, dando mais flexibilidade ao desenvolvedor na hora de quebrar seus projetos em peda�os menores." E ajudando a manter o caos na hora de organizar o codigo... E francamente, de onde saiu esse "um package estah obrigatoriamente associado a um unico arquivo .class ?" 24 - "Especificadores de acesso" "Quatro." "Cinco. O internal, adicional, especifica acesso apenas no mesmo �assembly� (mesma DLL, a grosso modo)." Java eh independente de plataforma. Eh a sua principal caracteristica. Eu acho otimo que seja assim. 25 - "Diretivas de compila��o condicional (#ifdef etc)" "Java: N�o." "C#: Sim." Diretiva de compilacao para codigo binario que executa sem modificacao em qualquer plataforma ? 26 - "Destrutores" "Java: N�o, mas o m�todo Finalize pode ser usado." "C#: Sim." Quando nao se tem um bom garbage colletor... 27 - "Padroniza��o por algum organismo internacional" "Java: N�o. Duas submiss�es da Sun foram posteriormente retiradas." "C#: Sim. Submetido e aceito pelo ECMA (http://www.ecma.ch)." Java eh usado largamente pela industria de software, de telefonia movel, meios academicos e cientificos. A sonda Sojourney rodava Java. Eh uma linguagem que se consagrou como um padrao de fato. Alguem aih sabe o que eh ECMA, por acaso ? 28 - "Chama APIs do Windows e DLLs" "Java: N�o. Mesmo o suporte �nativo� de alguns compiladores � extremamente limitado pela falta de ponteiros na linguagem." "C#: Sim." Vamos todos dizer, irmaos: AMEM por isso! 29 - "Chama objetos COM/COM+" "Java: N�o." "C#: Sim." 30 - "Cria objetos COM/COM+" "Java: N�o." "C#: Sim." Quem precisa de COM (M$) quando tem CORBA (open source) ? "Existem alguns pontos importantes por tr�s dos t�picos acima: * O C# implementa caracter�sticas interessantes do C++ que foram removidas no Java, como passagem de par�metros por refer�ncia, enum, struct, sobrecarga de operadores, operadores de convers�o e compila��o condicional;" Tudo foi retirado com um proposito: tornar a linguagem universal e totalmente portavel. Nao foi por outro mo- tivo. "* O C# tem v�rios recursos que melhoram a performance, como uso de �tipos por valor� (structs e enums) em situa��es simples onde o uso de uma classe seria muito �caro� e suporte direto a ponteiros;" E tem varias "vantagens" que podem jogar a performance no chao, como a tipagem fraca (pior de todos, heranca maldi- ta do BASIC que a Microsoft ateh hoje insiste em manter nas suas linguagens, criando maus habitos de programacao) e os switches usando strings. "* Suporte direto a componentes, atrav�s de a propriedades e eventos;" Java eh *todo componentes* - apenas nao sao visuais. "* A unifica��o do sistema de tipos (tudo � derivado de object) e a convers�o de valores para refer�ncias atrav�s de �boxing� s�o recursos que, ao mesmo tempo simplificam a programa��o, como tamb�m permitem melhores abstra��es;" E jogam contra a performance. "* Boa integra��o com c�digo anterior escrito para Windows:" Mantendo voce atrelado aa plataforma Windows, nao por acaso. "suporte a ponteiros, chamar DLLs, chamar objetos COM e criar objetos COM. N�o � necess�rio abandonar o C# para usar alguma facilidade n�o contemplada pela biblioteca de classes;" Eh o trade-off que se faz por ficar atado ao Windows. Talvez para alguns isso seja aceitavel, mas nao para todos. No resumo deste testamento, fica a seguinte impressao: C# promete "facilitar a vida" do programador - mas soh do pro- gramador "desenhista de formularios"; aquele que realmente sabe programar, que conhece os pros e contras de cada tec- nologia, sabem que no geral, Java estah ganhando e facil, pelo menos no aspecto tecnico. Infelizmente, este canto de sereia da Microsoft seduz muita gente boa - e principalmente, muita gente que toma decisoes dentro de empresas. Cabe aa nos, que conhecemos a ferramenta que usamos e seu potencial, nos esforcarmos para que a verdade sempre se sobreponha ao marketing. Vamos trabalhar nesse sentido, sem radicalismos exagerados, sempre procurando embasar nossas opinioes em fatos e nao em emocao (o que eh muito dificil, eu sei bem). Isso nao eh torcida por time de futebol, eh nosso ganha- pao. Tambem nao eh religiao (pelo menos para mim), portanto respeitar diferencas de opiniao faz parte. Apenas, nao permitir que este tipo de material se torne "verdade" por conta de nosso silencio e omissao. Abracos, Carlos ------------------------------ LISTA SOUJAVA ---------------------------- http://www.soujava.org.br - Sociedade de Usu�rios Java da Sucesu-SP d�vidas mais comuns: http://www.soujava.org.br/faq.htm regras da lista: http://www.soujava.org.br/regras.htm historico: http://www.mail-archive.com/java-list%40soujava.org.br para sair da lista: envie email para [EMAIL PROTECTED] -------------------------------------------------------------------------
