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] -------------------------------------------------------------------------
