ai galera, blz?
Estava conversando com um camarada meu e este me mostrou estes artigos abaixo falando pq C# é melhor que Java
C# Melhor que Java Parte I
Ai, eu só queria a opinião da galera.
falou
ai galera, blz?
Estava conversando com um camarada meu e este me mostrou estes artigos abaixo falando pq C# é melhor que Java
C# Melhor que Java Parte I
Ai, eu só queria a opinião da galera.
falou
Olá
Aparentemente estes artigos são antigos e a comparação foi feita usando a versão 1.4. Quem escreveu é um cara competente mas TOTALMENTE adepto da M$. Será que este artigo é isento o bastante para que eu leia o resto?
Mas de qualquer forma não me importa qual é a melhor rodando somente no Windows. Faz tempo que dou valor a coisas que funcionam também em ambiente Unix-like e não sei se o C# já chegou lá.
[]s
Luca
Post de blog velho, não considera Java 5. Diversas funcionalidades agora existem: autoboxing/unboxing, anotations, enums, foreach, varargs
“com alguma dificuldade”. Isso que é benchmark.
O cara não programa em Java
O cara REALMENTE não programa em Java
Não é em XML mas faz a mesma coisa.
Não sabia que C# fazia assim. Que perigo @.@
pediu pro java ir sem escudo e espada pra essa comparacao.
Uma coisa que eu achei legal foi o switch com String.
Bem que poderia ter ^^
Sim, estes artigos estão meio “desatualizados” ou comparando versões diferentes das atuais ^^
Além da defasagem de versão que o Luca comentou, existem algumas coisas estranhas nesse artigo. Sobre a Parte I:
:arrow: Semelhanças: “Orientação por Objetos” e “Herança” são características separáveis??
:arrow: Recursos novos em C#:
Propriedades: Existe alguma dificuldade em criar getters e setters? Se não me engano, a sintaxe de propriedades em C# é mesmo interessante, mas é basicamente a mesma coisa…a diferença é que é criado um “método” de propriedade que implementa o get e o set
Documentação integrada com XML: Nunca pesquisei, mas não é possível com algum Doclet?
Arquivo “executável” independente do namespace:
“Um ‘package’ Java obrigatoriamente está associado a um único arquivo ‘.class’.” Ahn??? :roll:
Chama APIs do Windows e DLLs: Pode chamar sim, com JNI
[quote=escordeiro]
Documentação XML - quá quá quá… Qual a diferença entre isto:
/// <summary>
/// "Capitaliza" uma string (ou seja, converte a primeira letra para maiúscula
/// e deixa as restantes em minúsculas).
/// </summary>
/// <param name="s">A string a ser capitalizada</param>
/// <returns>A versão capitalizada da string</returns>
/// <remarks>Esta versão não capitaliza por palavras. Portanto, se
/// tivermos a entrada "JOSE DA SILVA" a saída será "Jose da silva".</remarks>
public static string capitalize (string s) {
if (s.Length > 1) {
return s.Substring(0,1).ToUpper() + s.Substring (1).ToLower();
} else if (s.Length == 1) {
return s.ToUpper();
} else {
return "";
}
}
e isto:
/**
* "Capitaliza" uma string (ou seja, converte a primeira letra para maiúscula
* e deixa as restantes em minúsculas).
* @param s A string a ser capitalizada
* @return A versão capitalizada da string
* @ext.remarks Esta versão não capitaliza por palavras. Portanto, se
* tivermos a entrada "JOSE DA SILVA" a saída será "Jose da silva".
*/
public static String capitalize (String s) {
if (s.length() > 1) {
return s.substring(0,1).toUpperCase() + s.substring(1).toLowerCase();
} else if (s.length() == 1) {
return s.toUpperCase();
} else {
return "";
}
}
Tudo bem, o .NET gera por default um arquivo XML contendo um resumo da documentação para poder ser lido por qualquer ferramenta que saiba ler XML, mas até aí não é nada que não possa ser resolvido via doclets.
Essa parte específica tem um “não” categórico e uma frase que explica outra coisa (go figure…)
Mas o artigo apresenta alguns pontos interessantes sim, apesar do autor ser um religioso “do outro lado”
Há pouco tempo atrás tive de escrever um programa C# - nada demais, um serviço do Windows que atende a conexões TCP. O que achei legal no C#:
[DllImport ("kernel32.dll", CharSet=CharSet.Auto, SetLastError=true)]
public static extern int CreateHardLink (String fileName, String existingFileName, System.IntPtr securityAttributes);
java.util.HashMap -> System.Collections.Hashtable
java.io.InputStream -> System.IO.BinaryReader
java.io.OutputStream -> System.IO.BinaryWriter
java.io.File -> System.IO.File, System.IO.Directory
Class.forName (“Teste”).newInstance -> Type.GetType(“Teste”).GetConstructor (new Type[0]).Invoke (new Object[0])
System.arraycopy -> Array.Copy
java.lang.StringBuffer, java.lang.StringBuilder -> System.Text.StringBuilder
new String(byte[], String), String.getBytes(String) -> System.Text.Encoding
Olá
Dei uma lidinha a mais no artigo e vi uma citação a um artigo de maio de 1996 ao explicar de forma incompleta como o Java é montado e omitir hotspot que segundo a Sun é tecnologia chave do Java. São coisas assim que tiram a credibilidade de um artigo. Pena, perdi a vontade de ler.
[]s
Luca
[quote=kina][quote=escordeiro]
E isto acima, não foi uma comparação de plataforma ??? Como é que faz mesmo para o C# chamar uma API do X-Window ???
Sobre o uso de Javadoc
Já viu o suporte que as IDE oferecem para Javadoc ? Um refactor do eclipse muda inclusive os javadocs (o visual.Net faz isso ?) Eu até achava a idéia do Knuth de escrever em CWEB legal, mas Javadoc é muito bom…
E mais uma coisa: Tratamento de exceções.
C# - você não é obrigado a tratar Exceptions.
Java - você é obrigado a tratar Exceptions ( a menos das RuntimeException) ou declarar que o método irá lança-las.
[quote=rodrigousp]E mais uma coisa: Tratamento de exceções.
C# - você não é obrigado a tratar Exceptions.
Java - você é obrigado a tratar Exceptions ( a menos das RuntimeException) ou declarar que o método irá lança-las.
[/quote]
É, percebi isso. Estou muito acostumado com o esquema do Java; quando vi que em C# isso não era obrigatório acabei ficando com uns programas assim em C# (o Visual Studio nem diz que exceção um trecho de código pode lançar - você tem de ficar procurando API por API o que pode acontecer )
try {
faça alguma coisa que não sei que raio de exceção vai jogar
} catch (Exception ex) {
trate tudo de qualquer jeito mesmo
}
O System.Exception do C# equivale ao java.lang.Throwable.
Coisas que não deveriam ter no C#:
Ponteiros: Perigoso e obscuro. É o tipo de coisa que a gente quer em linguagens de baixo-nível
Sobrecarga de operadores: torna o código sujo, difícil de ler.
Goto: sem comentários !!!
Argumentos irrelevantes quando comparar a linguagem e não a plataforma.
Chama APIs do Windows e DLLs
Chama objetos COM/COM+
Cria objetos COM/COM+
Destructor: na verdade, no Java não é o possível finalizar um objeto diretamente, mas o comportamento do destructor pode ser reimplementado, sobreescrevendo o método finalize.
Como já disseram, esses artigos são bem antigos, de 2001 se não me engano. Eu os li quando estava começando a aprender Java, em 2002/2003. Os artigos em si têm muitos pontos confusos e não-verdadeiros, mesmo pra época que foram escritos. Mas já está defasado e não importa mais.
Bom, quem conhece sabe que o autor dos artigos, Mauro Santanna, é reconhecidamente um cara polêmico, que adora semear a discórdia por aí. Quem lê ou leu as revistas MSDN Magazine (como eu que tive assinatura) sabe que ele implica com tudo. Tudo mesmo. Claro que ele tem que defender o ganha-pão dele, já que ele é Microsoft Regional Whatever MotherFucker sei-lá-o-quê Director, mas muitas vezes ele faz isso de forma meio cega. Só pra se ter uma idéia, eu peguei um range de exemplares da revista pra ver o que exatamente ele criticava, na sua coluna (é, porque é só isso que ele faz):
#10: -
#11: Modelo Open-Source
#12: Javascript
#13: Essa foi demais… críticas bem pesadas ao W3C e o padrão Html, ao Javascript novamente, ao padrão SQL ANSI…
#14: -
#15: Portabilidade
#16: -
#18: Críticas bem nonsense ao C/C++
#19: Metodologias e processos
Todas as críticas sempre têm uma alfinetada, direta ou indireta, ao Linux ou ao Java, e a maioria de suas críticas são bem contraditórias com o que acontece no mundo real, e pior, com o que acontece no mundo Microsoft.
Olá
[quote=rodrigousp]Destructor: na verdade, no Java não é o possível finalizar um objeto diretamente, mas o comportamento do destructor pode ser reimplementado, sobreescrevendo o método finalize.
[/quote]
Prática desnecessária e totalmente condenável além de ter poucas chances de funcionar tal como o desenvolvedor médio imagina! Melhor simplesmente fazer o objeto = null (atenção para os Arrays e as Collections)
[]s
Luca
Não, Luca. Quem escreveu este artigo se chama Mauro Sant’anna. Competência não é bem o adjetivo que eu associaria ao seu nome
BTW, http://www.manageability.org/manageabilityWiki/WhyJavaIsBetterThanDotNet
[quote=Daniel Quirino Oliveira]
Não, Luca. Quem escreveu este artigo se chama Mauro Sant’anna. Competência não é bem o adjetivo que eu associaria ao seu nome
BTW, http://www.manageability.org/manageabilityWiki/WhyJavaIsBetterThanDotNet[/quote]
“Better GUI Framework - Why isn’t VS.NET written in a .NET language?” :lol:
Enquanto leio o texto desse cara eu tenho mais certeza de que o Java é bem melhor que o .NET. Bah!