.Net

[quote=Marcio_Nogueira]O objetivo é ver se os membros desenvolvem em ambas as plataformas, pois tem pessoas que metem o malho no .net.
Acho importante abrir a cabeça para outras possibilidades.[/quote]

Quem malha .Net provavelmente pensa que o mundo se resume a aplicativos web, mas quem programa no ambiente windows fala muito bem de .net. Na verdade java é o forasteiro e sua complexidade e estagnação que são motivos de piadas.

Mas esse sentimento está começando a mudar na medida que java perde terreno para aplicações web que usam linguagens dinâmicas, creio que a tendência é a maioria dessas pessoas mudarem de ambiente (ao invés de mudarem a maneira de criar aplicativos web, ou seja, adotarem linguagens dinâmicas) fazendo com que esse pré-conceito bobo seja superado.

[quote=ViniGodoy]Eu gosto de vários recursos:

  1. Extension Methods;
  2. Lambda;
  3. LINQ;
  4. Propriedades;
  5. Sobrecarga de operadores;
  6. Delegates;

Acho que só o que não simpatizo muito são as partial classes.[/quote]

Já programei alguns produtos em C#.Net, gostei bastante (não do produto e sim da linguagem), ainda mais que é parecido com java. Só não entendi muito bem a empregabilidade dos Delegates, mas tá valendo. Pra que eu precisaria de um objeto para um método?

Tenho trauma da plataforma da microsoft desde 2001. Quando vi vb6 pela primeira vez.
Vi a primeira versão do .net e não gostei também.
Quando vi java em 2002 minha vida mudou, parei com as drogas e sou feliz.
Velocidade de desenvolvimento depende muito.
Estamos usando jsf2 + primefaces 2 e o negocio ta muito rápido. :thumbup:
t+

Não acho que o forte do .NET seja a IDE, mas o próprio C# é bem interessante, gosto muito da linguagem.

Hoje temos IDEs mais poderosas em termos de coding fora do âmbito C#.

Eles são uma substituição àquelas interfaces que só tem um método dentro, como a interface Runnable, ou a Comparator do Java.
A vantagem deles é que, justamente, não te forçam a precisar de um objeto para um método. Por exemplo, no caso do Comparator, você poderia definir apenas uma função static, e passa-la para o delegate.

Por exemplo, considere o delegate:

Você pode inicializado assim:

Onde funcaoCompare é um método estático. Ou assim:

Onde comparador é uma função da instância. Nesse caso, o delegate sabe que tem que guardar o objeto MeuObjeto junto, pois ele será necessário ao chamar a função de comparação da instância.

Outra vantagem do delegate é que ele só cria dependência quanto a assinatura do método, não quanto à classe que o contém. Por exemplo, se a interface Runnable fosse um delegate

Você poderia disparar uma thread sobre qualquer método, de qualquer objeto que não recebesse parâmetro. Mesmo que fosse uma classe de uma API contida num .jar, e que você não tivesse qualquer controle sobre sua declaração.
Como essa aqui:

 //Chama o método pack do JFrame sobre outra thread
//Isso é possível pois o pack tem a assinatura requerida pelo delegate
//Em java, teríamos que criar uma interface, passar o JFrame para ela como parâmetro, implementar 
//seu método run, para só então chamar o pack(). Ou então, teríamos que fazer o JFrame implementar runnable, 
//o que não é possível pq JFrame é uma classe do Java, não nossa.
new Thread(jframe.pack).start();

Se tudo correr bem, em breve volto a desenvolver em .net (VB e C#)