C#/.NET - Porque tanta gente "odeia"?

Assuntos Gerais
#41

Fora o que falaram, tem as vantagens e desvantagens das duas plataformas, e do vendor-lockin.

Uma coisa que reclamam muito no mundo Java é a demora para evoluir a linguagem, no JCP demora anos para uma proposta ser feita, discutida, aprovada e implementada. Entrar em consenso com muitas pessoas de muitas empresas, cada uma com a sua agenda, é muito difícil. No mundo do .Net, a Microsoft disse, está feito.

Por outro lado, a especificação pode sair uma caca no lado do MS por não passar mais tempo discutindo com a comunidade sobre o que é melhor, porém a JCP já fez isso também, só para corrigir um pouco três anos depois numa nova especificação(por exemplo, Criteria API só vai sair na JPA 2.0, coisa que o Hibernate já faz desde anos antes do 1.0).

E terceiro, no .Net, se a MS levá-lo para um lado que pouca gente gosta, estará feito. Se quiser matar, estará morto. Para o Java, não dá para matar uma comunidade.

Dá uma raiva dessa lerdeza para lançar o Java 7, tem um monte de gente esperando algo como o invokedynamic, a última trava para liberar o boom de desenvolvimento na plataforma, e daqui a pouco vamos para o quarto ano de espera por isso.

#42

[quote=Bruno Laturner]Fora o que falaram, tem as vantagens e desvantagens das duas plataformas, e do vendor-lockin.

Uma coisa que reclamam muito no mundo Java é a demora para evoluir a linguagem, no JCP demora anos para uma proposta ser feita, discutida, aprovada e implementada. Entrar em consenso com muitas pessoas de muitas empresas, cada uma com a sua agenda, é muito difícil. No mundo do .Net, a Microsoft disse, está feito.

Por outro lado, a especificação pode sair uma caca no lado do MS por não passar mais tempo discutindo com a comunidade sobre o que é melhor, porém a JCP já fez isso também, só para corrigir um pouco três anos depois numa nova especificação(por exemplo, Criteria API só vai sair na JPA 2.0, coisa que o Hibernate já faz desde anos antes do 1.0).

E terceiro, no .Net, se a MS levá-lo para um lado que pouca gente gosta, estará feito. Se quiser matar, estará morto. Para o Java, não dá para matar uma comunidade.

Dá uma raiva dessa lerdeza para lançar o Java 7, tem um monte de gente esperando algo como o invokedynamic, a última trava para liberar o boom de desenvolvimento na plataforma, e daqui a pouco vamos para o quarto ano de espera por isso.[/quote]

acho que isso é uma das coisas que não vamos ver tão cedo no java.
Eu sonho com um unsigned byte até hoje, para não precisar sofrer ao fazer um software em c conversar com java.

#43

[quote=juliocbq][quote=Bruno Laturner]Fora o que falaram, tem as vantagens e desvantagens das duas plataformas, e do vendor-lockin.

Uma coisa que reclamam muito no mundo Java é a demora para evoluir a linguagem, no JCP demora anos para uma proposta ser feita, discutida, aprovada e implementada. Entrar em consenso com muitas pessoas de muitas empresas, cada uma com a sua agenda, é muito difícil. No mundo do .Net, a Microsoft disse, está feito.

Por outro lado, a especificação pode sair uma caca no lado do MS por não passar mais tempo discutindo com a comunidade sobre o que é melhor, porém a JCP já fez isso também, só para corrigir um pouco três anos depois numa nova especificação(por exemplo, Criteria API só vai sair na JPA 2.0, coisa que o Hibernate já faz desde anos antes do 1.0).

E terceiro, no .Net, se a MS levá-lo para um lado que pouca gente gosta, estará feito. Se quiser matar, estará morto. Para o Java, não dá para matar uma comunidade.

Dá uma raiva dessa lerdeza para lançar o Java 7, tem um monte de gente esperando algo como o invokedynamic, a última trava para liberar o boom de desenvolvimento na plataforma, e daqui a pouco vamos para o quarto ano de espera por isso.[/quote]

acho que isso é uma das coisas que não vamos ver tão cedo no java.
Eu sonho com um unsigned byte até hoje, para não precisar sofrer ao fazer um software em c conversar com java.[/quote]

usigned byte em java… ta doido… pra que trazer as dores de cabeça do C para o java? se pode simplificar pra que complicar…
se quer ter fortes dores de cabeça programe em C…

#44

Não conheço bem o .Net e nem o Mono, mas quando li sobre o assunto, tive a impressão de leigo de que o Mono é mais organizado e sério que o .Net. Me corrijam se estiver errado, mas foi essa a impressão que tive. E acho que isso se dá porque o Mono é um projeto Open Source. Para mim a M$ não sabe lidar com internet, comunidade, opiniões. Ela enfrenta um sério problema de resistência as mudança pós internet. Coisa que não se vê em outras empresas como IBM. Eu acho que hoje é preciso estar atento as necessidades das pessoas, e não decidir o que é bom para elas. Infelizmente a M$ age assim em quase todos os seus produtos e é o fator limitante dela hoje. Me lembro que o que mais me incentivou a programar em VB antes do java, era o número de parceiros da M$. Nisso ela é boa, mas infelizmente peca no quesito qualidade e flexibilidade. O que tenho ouvido é que C# é uma ótima linguagem, mas o .Net é uma péssima plataforma.

#45

[quote=juliocbq]
acho que isso é uma das coisas que não vamos ver tão cedo no java.
Eu sonho com um unsigned byte até hoje, para não precisar sofrer ao fazer um software em c conversar com java.[/quote]

Mas a VM trata todos os integers como 32 bit signed, não? Além do mais, se você não está fazendo contas o sinal é o de menos, pois você pode simplesmente ignorá-lo.

#46

[quote=Thiagosc][quote=juliocbq]
acho que isso é uma das coisas que não vamos ver tão cedo no java.
Eu sonho com um unsigned byte até hoje, para não precisar sofrer ao fazer um software em c conversar com java.[/quote]

Mas a VM trata todos os integers como 32 bit signed, não? Além do mais, se você não está fazendo contas o sinal é o de menos, pois você pode simplesmente ignorá-lo. [/quote]

Você não tem idéia do que está falando, cada bit tem que estar perfeitamente alinhado para operar em baixo nível com ABIs de outros programas.

#47

[quote=luistiagos][quote=juliocbq][quote=Bruno Laturner]Fora o que falaram, tem as vantagens e desvantagens das duas plataformas, e do vendor-lockin.

Uma coisa que reclamam muito no mundo Java é a demora para evoluir a linguagem, no JCP demora anos para uma proposta ser feita, discutida, aprovada e implementada. Entrar em consenso com muitas pessoas de muitas empresas, cada uma com a sua agenda, é muito difícil. No mundo do .Net, a Microsoft disse, está feito.

Por outro lado, a especificação pode sair uma caca no lado do MS por não passar mais tempo discutindo com a comunidade sobre o que é melhor, porém a JCP já fez isso também, só para corrigir um pouco três anos depois numa nova especificação(por exemplo, Criteria API só vai sair na JPA 2.0, coisa que o Hibernate já faz desde anos antes do 1.0).

E terceiro, no .Net, se a MS levá-lo para um lado que pouca gente gosta, estará feito. Se quiser matar, estará morto. Para o Java, não dá para matar uma comunidade.

Dá uma raiva dessa lerdeza para lançar o Java 7, tem um monte de gente esperando algo como o invokedynamic, a última trava para liberar o boom de desenvolvimento na plataforma, e daqui a pouco vamos para o quarto ano de espera por isso.[/quote]

acho que isso é uma das coisas que não vamos ver tão cedo no java.
Eu sonho com um unsigned byte até hoje, para não precisar sofrer ao fazer um software em c conversar com java.[/quote]

usigned byte em java… ta doido… pra que trazer as dores de cabeça do C para o java? se pode simplificar pra que complicar…
se quer ter fortes dores de cabeça programe em C…[/quote]

Na verdade complica mais. Imagina um byte sinalizado!? sendo que outros softwares de outras linguagens sempre trabalham com não sinalizado. Causa muita dor de cabeça com quem trabalha com bits.

#48

[quote=luistiagos]usigned byte em java… ta doido… pra que trazer as dores de cabeça do C para o java? se pode simplificar pra que complicar…
se quer ter fortes dores de cabeça programe em C.[/quote]

Tenho que discordar.

Você já tentou fazer uma aplicação que conversa com C?

Para ler um unsigned int, você tem que fazer algo assim:

long valor = (long) (byteBuffer.getInt() & 0xffffffffL);

Para escrever um unsigned byte:

bb.put(position, (byte) (value & 0xff));

Sendo que value precisa ser um short.

E nem vou falar aqui da gambi que é ler um unsigned long. Agora, eu já estaria satisfeito se classes feitas para trabalhar com sockets (como ByteBuffer e DataInput/OutputStream), já tivessem métodos que fizessem essas conversões.

Detalhe: o tipo unsigned é uma das coisas que não traz dor de cabeça no C.

#49

"

#50

[quote=Thiagosc][quote=juliocbq]
acho que isso é uma das coisas que não vamos ver tão cedo no java.
Eu sonho com um unsigned byte até hoje, para não precisar sofrer ao fazer um software em c conversar com java.[/quote]

Mas a VM trata todos os integers como 32 bit signed, não? Além do mais, se você não está fazendo contas o sinal é o de menos, pois você pode simplesmente ignorá-lo. [/quote]

Eu trabalho com microcontroladores e sei o que é fazer o micro conversar com um software java. Vocês não têm idéia do incômodo que é um byte sinalizado.

Enquanto por padrão todos dispositivos eletrônicos trabalham com 0 - 255, java tem que ser -128 - 128.

#51

[quote=marcosalex]Rodo a última versão do Gnome, o beta do 2.28 sem precisar do Mono e o código dele se baixar o fonte, vai ver que é C (nem C++ é).
Talvez exista um binding da gtk pro Mono se você quiser rodar dentro da vm, mas não é obrigatório. Apenas um ou outro aplicativo do Mono é C#.

E, segundo o site deles, eles não pretendem portar o mono, mas alguns aplicativos.
http://blogs.gnome.org/bolsh/2009/07/02/why-i-disagree-with-rms-concerning-mono/

Agora, tempo de lançar uma feature vai ser sempre mais lento, visto que tem de se preocupar com n plataformas e em atender uma grande gama de fornecedores. A MS simplesmente lança do jeito que ela quer, o resto que acompanhe se quiser.

Quanto mais amplo for o leque de plataformas atendidas, mais difícil é aprovar uma mudança. Vejam o W3C que tem 5 anos que estão trabalhando no HTML 5 e a previsão mais otimista dá pra 2012 a especificação…[/quote]

Sei que é escrito em c. O que digo, é que mono já é uma dependência do gnome. E no mesmo site que citou, vai ver que a tendência é o gnome se tornar mais dependente mono.
Todas as aplicações de dispositivos são c#. Inclusive a que gerencia processos.

#52

Existe sim, é o GTK#. Era a alternativa que utilizavam pra criar interfaces gráficas antes de portarem os Windows Forms.

O que eu percebo pelos vários comentários, é que quem se acostumou com o jeito Java, não gostam do .NET pela cara mais “impessoal” do framework.

Veja quantas são e como estão organizadas as comunidades Java, e as .NET. Você vai ver que nas de Java, geralmente são grupos de discussão de tecnologia, enquanto que as .NET geralmente são grupos de estudo da plataforma.

Ainda tem a questão dos frameworks. Java é muito aberto à frameworks de terceiros, na verdade isso é até incentivado. Em .NET, como a API padrão já tem muita coisa, muita gente só usa o que está disponível, sem se preocupar com outras forma de se fazer, isso dá a impressão que não existem frameworks de terceiros para tarefas menos “corriqueiras” em .NET.

#53

[quote=Bruno Laturner][quote=Thiagosc][quote=juliocbq]
acho que isso é uma das coisas que não vamos ver tão cedo no java.
Eu sonho com um unsigned byte até hoje, para não precisar sofrer ao fazer um software em c conversar com java.[/quote]

Mas a VM trata todos os integers como 32 bit signed, não? Além do mais, se você não está fazendo contas o sinal é o de menos, pois você pode simplesmente ignorá-lo. [/quote]

Você não tem idéia do que está falando, cada bit tem que estar perfeitamente alinhado para operar em baixo nível com ABIs de outros programas.[/quote]
Isso mesmo. Um valor com sinal diferente implica num cálculo complicado para conversão. Essa é realmente uma pedra, no quisito usar java para eletrônica digital.

Se implementassem um tipo unsigned, resolveria grande parte de problemas de conversão.

#54

[quote=juliocbq]
Sei que é escrito em c. O que digo, é que mono já é uma dependência do gnome. E no mesmo site que citou, vai ver que a tendência é o gnome se tornar mais dependente mono.
Todas as aplicações de dispositivos são c#. Inclusive a que gerencia processos.[/quote]
Olha só que curioso, falando de java e .Net eu não sinto ameaças nem motivos para levantar meu escudo, porque acredito que o .Net tenha seu espaço e clientes definidos e divididos com o java, cada qual com suas regras. Mas confesso que vendo a conversa de vocês sobre Mono( partes de M$) e Gnome (Ubuntu e Software Livre), todas os escudos se levantam e me sinto ameaçado. Não quero mudar o rumo da conversa, mas sou totalmente contra o Gnome ter dependências do Mono pelos motivos conhecidos. Dai já da para você ter uma ideia do porque alguns são tão radicais. Quem vê java para o mercado de trabalho, não se importa tanto com C#, mono e .Net. Mas quem vê java como Open-Source com certeza se incomodará com o Mono por ser parte da M$, e a M$ não pode ter nada totalmente Open-Source sem deixar de ser M$.
Pra mim o motivo da guerra é a empresa mesmo.

#55

Mono também é Open Source, não importa que a MS esteja por trás, se a empresa tomar uma atitude que desagrade, faz um fork e a vida segue.

#56

[quote=mvargens][quote=juliocbq]
Sei que é escrito em c. O que digo, é que mono já é uma dependência do gnome. E no mesmo site que citou, vai ver que a tendência é o gnome se tornar mais dependente mono.
Todas as aplicações de dispositivos são c#. Inclusive a que gerencia processos.[/quote]
Olha só que curioso, falando de java e .Net eu não sinto ameaças nem motivos para levantar meu escudo, porque acredito que o .Net tenha seu espaço e clientes definidos e divididos com o java, cada qual com suas regras. Mas confesso que vendo a conversa de vocês sobre Mono( partes de M$) e Gnome (Ubuntu e Software Livre), todas os escudos se levantam e me sinto ameaçado. Não quero mudar o rumo da conversa, mas sou totalmente contra o Gnome ter dependências do Mono pelos motivos conhecidos. Dai já da para você ter uma ideia do porque alguns são tão radicais. Quem vê java para o mercado de trabalho, não se importa tanto com C#, mono e .Net. Mas quem vê java como Open-Source com certeza se incomodará com o Mono por ser parte da M$, e a M$ não pode ter nada totalmente Open-Source sem deixar de ser M$.
Pra mim o motivo da guerra é a empresa mesmo.[/quote]

Qualquer um pode desenvolver uma máquina virtual .net, é, necessário somente seguir essas especificações:
http://www.ecma-international.org/publications/standards/Ecma-334.htm

O que sofre patente é o framework, que não tem nada haver com a máquina virtual, e que o mono possui completamente diferente, que é o gtk#, e outras implementações para sistemas unix.

#57

Mono também é Open Source, não importa que a MS esteja por trás, se a empresa tomar uma atitude que desagrade, faz um fork e a vida segue.[/quote]

Eu, sei. Mas o problema é o fato da M$ estar envolvida. Isso gera um mal estar em mim, que consigo ser imparcial no lado profissional, (mas não no lado pessoal). Imagina para quem defende o Open-Source com unhas e dentes. C# é uma criação M$ seja ela open-source ou não.
A primeira reação que vem a cabeça é: Se é da M$ não presta, ou tem surpresa escondida. Por isso identifiquei como sendo um problema da empresa e não da linguagem.

#58

[quote=Bruno Laturner][quote=Thiagosc][quote=juliocbq]
acho que isso é uma das coisas que não vamos ver tão cedo no java.
Eu sonho com um unsigned byte até hoje, para não precisar sofrer ao fazer um software em c conversar com java.[/quote]

Mas a VM trata todos os integers como 32 bit signed, não? Além do mais, se você não está fazendo contas o sinal é o de menos, pois você pode simplesmente ignorá-lo. [/quote]

Você não tem idéia do que está falando, cada bit tem que estar perfeitamente alinhado para operar em baixo nível com ABIs de outros programas.[/quote]

Sim, mas internamente todos os integers são 32 bit. O tipo “byte” é apenas uma conveniência para o programador. Ou usa-se um tipo maior ou ignora-se o sinal.

#59

[quote=ViniGodoy][quote=luistiagos]usigned byte em java… ta doido… pra que trazer as dores de cabeça do C para o java? se pode simplificar pra que complicar…
se quer ter fortes dores de cabeça programe em C.[/quote]

Tenho que discordar.

Você já tentou fazer uma aplicação que conversa com C?

Para ler um unsigned int, você tem que fazer algo assim:

long valor = (long) (byteBuffer.getInt() & 0xffffffffL);

Para escrever um unsigned byte:

bb.put(position, (byte) (value & 0xff));

Sendo que value precisa ser um short.

E nem vou falar aqui da gambi que é ler um unsigned long. Agora, eu já estaria satisfeito se classes feitas para trabalhar com sockets (como ByteBuffer e DataInput/OutputStream), já tivessem métodos que fizessem essas conversões.

Detalhe: o tipo unsigned é uma das coisas que não traz dor de cabeça no C.[/quote]

Cara, preciso discordar. Já programei VM e no caso usava o tipo byte para representar 256 valores. Como o byte do Java só vai até 127, após esse valor o ByteBuffer retorna -128 e vai incrementando os negativos. Simplesmente ignorava o sinal, visto que o byte em si já tinha os 8 bits necessários, a única diferença é que no código eu simplesmente usava -128, -127, -126, etc.

Por exemplo, um código assim funcionava tranquilo para pegar os 8 bits necessários.

  byte b = ByteBuffer.get(index);

Para dizer a verdade uma linguagem decente deveria manipular os números, tanto inteiros quanto de ponto flutuante, de forma transparente. Portanto você apenas usa o valor e a VM ou compilador trata de alocar o espaço apropriado para o valor que você deseja representar. Tanto a solução do Java quando do C não são boas.

#60

Acho que a grande sacada da Microsof foi submeter o C# ao w3c e torná-lo um padrão aberto. Desta forma, o C# conquistaria uma parcela dos programadores que utilizam outras linguagens, entre elas o java.