Offtopic (?) - Java vs .NET
Marcos Dell Antonio
http://www.javafree.org/noticia/3962/Java-vs-NET.html
--
Marcos Dell' Antonio
http://www.marcosdellantonio.net
Rafael Rosa
Atenciosamente,
Rafael Rosa
www.rafaelrosafu.com
www.rubyinside.com.br
Marcos Dell Antonio
Eu conheço ele. Só não sei dizer porque ele escreveu um artigo como este...
Rogerio Santos
Rafael Rosa
Marcos Dell Antonio
Não é de autoria do Dalton mesmo...
T+
Juliano Oliveira
[]´s
Juliano Oliveira
Analista Desenvolvedor
.Net, C#, Actionscript, Flex, NHibernate
http://programandoem.net
twitter: @juloliveira - skype: juloliveira
Marcos Dell Antonio
Juliano Oliveira
"Dedo podre desse Dalton pra escolher post..."
mar...@hypequino.com
corresponde com a verdade.
É polêmico, claro, mas nada oportunista ou tomando partido de algo.
Em 04/06/2009, Marcos Dell Antonio <marcosde...@gmail.com>
escreveu:
> O interessante nesse caso é que o autor do artigo é o Dalton Camargo, que
> foi o responsável pelo desenvolvimento e implantação do novo fórum de jogos
> do UOL.
>
> Eu conheço ele. Só não sei dizer porque ele escreveu um artigo como este...
>
> 2009/6/4 Rafael Rosa <rafael...@gmail.com>
>
> > Poucos sites são tão inúteis quanto o JavaFree. Uma vez publicaram um link
> > para um post do Carlos Brando, que trabalha comigo no Ruby Inside Brasil, e
> > colocaram a chamada deturpando a mensagem dele. O que vêm de lá eu
> > desconsidero.
> >
Dilter Porto
--
Dilter Porto
Analista de Sistemas
Cel.: (27) 9836 4975
Juliano Oliveira
[]´s
Juliano Oliveira
Analista Desenvolvedor
.Net, C#, Actionscript, Flex, NHibernate
http://programandoem.net
twitter: @juloliveira - skype: juloliveira
mar...@hypequino.com
Em 04/06/2009, Dilter Porto <dilter...@gmail.com> escreveu:
> Este artigo não parece ter sido escrito recentemente. Ou o autor só
> consultou informações antigas a respeito do .NET. Fazendo sitações ao J#
> (descontinuado), se referindo ao VS como Visual Studio .NET (geralmente
> usado para se referir à primeira versão da IDE.
> O artigo é morno, na minha opinião.
>
aplnas
Att,
Antonio Pedro
Marcos Dell Antonio
Marcelo: conciso o artigo está, bem escrito só se for gramaticalmente, e olhe lá!
Nunca dei muita bola para discussões como essa porque geralmente elas não têm fundamento algum. É raro (talvez impossível) encontrar um profissional capacitado e atualizado para comparar duas tecnologias tão abrangentes como estas.
Rodrigo Braga
propriedade de ferramentas/tecnologias/... esse tipo de assunto
raramente acrescenta muita coisa; afinal a maioria das pessoas acabam
puxando sardinha pro lado preferido.
Eu acho esse assunto válido em bate-papos de amigos no bar... você
acaba aprendendo alguma coisa nova e talz... nas listas de debate pela
internet devem ter threads com 5 mil respostas e nada definido, mesmo
pq todas as tecnologias modernas e com alguma penetração no mercado
tem qualidade sim para solucionar a grande maioria dos problemas,
concordo que com X ou Y pode ser ter algum resultado melhor, mas mesmo
com Z poderemos alcançar resultados práticos.
2009/6/4 Marcos Dell Antonio <marcosde...@gmail.com>:
Att.,
Rodrigo Braga
mar...@hypequino.com
Quando disse que não vi nada demais é por que penso assim tb. Ele
escreveu um artigo sóbrio, sem "a microsoft é do mal", comparando
no ponto de vista dele. Não acrescentou nada de útil, não disse
nenhuma mentira nem inventou baboseiras. É um artigo frio, sem nada
a acrescentar, como vc disse. Ou como eu disse, nada demais.
Em 04/06/2009, Marcos Dell Antonio <marcosde...@gmail.com>
escreveu:
armando.miani
monopolística da Microsoft. " é bem parcial mesmo...
On 4 jun, 16:08, marc...@hypequino.com wrote:
> Marcos, concordo contigo.
>
> Quando disse que não vi nada demais é por que penso assim tb. Ele
> escreveu um artigo sóbrio, sem "a microsoft é do mal", comparando
> no ponto de vista dele. Não acrescentou nada de útil, não disse
> nenhuma mentira nem inventou baboseiras. É um artigo frio, sem nada
> a acrescentar, como vc disse. Ou como eu disse, nada demais.
>
>
>
>
> > Juliano: agora entendi :P
>
> > Marcelo: conciso o artigo está, bem escrito só se for gramaticalmente, e
> > olhe lá!
>
> > Nunca dei muita bola para discussões como essa porque geralmente elas não
> > têm fundamento algum. É raro (talvez impossível) encontrar um profissional
> > capacitado e atualizado para comparar duas tecnologias tão abrangentes como
> > estas.
>
> > 2009/6/4 aplnas <apl...@hotmail.com>
>
> > > É verdade, eu lembro desta ocasião.
>
> > > Att,
>
> > > Antonio Pedro
>
> > > On 4 jun, 14:46, Rafael Rosa <rafaelros...@gmail.com> wrote:
> > > > Poucos sites são tão inúteis quanto o JavaFree. Uma vez publicaram um
> > > link
> > > > para um post do Carlos Brando, que trabalha comigo no Ruby Inside Brasil,
> > > e
> > > > colocaram a chamada deturpando a mensagem dele. O que vêm de lá eu
> > > > desconsidero.
>
> > > > Atenciosamente,
> > > > Rafael Rosawww.rafaelrosafu.comwww.rubyinside.com.br
>
> > --
> > Marcos Dell' Antonio
>
> - Mostrar texto das mensagens anteriores -
Giovanni Bassi
http://www.baguete.com.br/colunasDetalhes.php?id=3070
Dá até vergonha alheia.
[]'s
Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com
Giovanni Bassi
Giovanni Bassi
"No item escalabilidade, as implementações das duas plataformas provêem mecanismos de balanceamento de carga, permitindo habilitar um cluster de máquinas para servir às cargas dos usuários que forem aumentando ao longo do tempo. A grande diferença entre o J2EE e o .NET é que desde que o .NET suporta apenas Win32, um número maior de máquinas se faz necessário, comparando ao J2EE, devido às limitações dos processadores. "
Pelo que entendi ele quer dizer que o .Net não suporta 64 bits. Só que suporta sim, desde a versão 1.0. Desinformação. Ou seja, desconsiderado.
"Em um fator de extrema importância, como velocidade de desenvolvimento, o .NET leva grande vantagem. A sua IDE proprietária, o Visual Studio, é baseado em RAD (Rapid Application Development), aumentando a agilidade na construção de aplicações. O Visual Studio .NET inclui várias ferramentas interessantes em termos de produtividade, como por exemplo o Web Forms. Estima-se que um projeto criado do zero, leve-se de 10% a 20% menos tempo para entrar em produção quando desenvolvido em .NET. "
Se você considerar só a IDE realmente é de 10% a 20% a menos. Se considerar que no Java usam-se 300 frameworks para fazer uma coisa, e que cada vez que você contrata um desenvolvedor precisa ensinar ele a usar o framework que você utiliza, já perde mais uns 10%. Colocando outras possibilidades, como delegates, enums (que o Java só recebeu recentemente), LINQ, etc, vai mais uns 10%. Ou seja, dá uma produtividade de até 40% a mais... Ainda bem que desenvolvedor é barato, e que o caro é máquina, não é? Ops, acho que é o contrário...
Agora... esse é o melhor de todos, de tão absurdo. Vai ser o que eu vou mais gostar de desmistificar.
"O Microsoft .NET oferece independência de linguagem, permitindo os componentes serem escritos em VB.NET, C# e J#, por exemplo. (...) Com um conjunto de linguagens rodando sobre a plataforma .NET, os desenvolvedores diminuem a habilidade de compartilhar as melhores práticas, diminuindo a assertividade do compartilhamento de informações. Assim, especula-se que um conjunto de linguagens rodando em CLR pode levar a uma combinação de código espaguete que fica difícil de manter. Com a liberdade para se utilizar diversas linguagens, a aplicação torna-se mais complexa, necessitando de experts em diferentes linguagens, o que também faz aumentar o TCO e a entropia do sistema. "
O primeiro absurdo é o cara jogar no lixo o conceito de melhor ferramenta para o trabalho. Linguagens funcionais onde o esforço é cálculo, matemático, etc. Linguagens dinâmicas onde é possível. Linguagens estáticas são ainda uma opção, e linguagens nativas para trabalhar no baixo nível. Algumas, como o C#, trazem conceitos de todas (nativa, funcional, dinâmica e estática).
Além disso, entendo que melhores práticas são compartilhadas entre linguagens. Eu uso o SRP em VB e em C#, por exemplo.
Ainda assim, a maioria dos projetos não possui mais do que uma linguagem principal (desconsiderando HTML, UML, XML, Javascript, etc). Vi pouquíssimos com mais de uma. E qual o problema de ter um time focado em F#, e outro em C#? Não temos médicos cardiologistas, médicos ortopedistas, médicos neurocirurgiões? Ter só um tipo de especialista (em C#, por exemplo) significaria que estes especialistas resolveriam todos os problemas com o mesmo resultados, uma grande mentira.
Além disso, o paradigma da multi-linguagem na plataforma nos permite aproveitar o melhor do mercado. Prova disso é que em breve poderemos programar, opcionalmente, o tão comentado Rails com Ironruby no .Net. (Algo que já é feito em Java, por acaso, com JRuby)
Entendo que o TCO diminui, porque um código em F#, desde que bem um utilizado, pode ser até 4 vezes menor que um código em C# (ou Java) que faz a mesma coisa. É uma linguagem incrível, e eu quero ela na minha caixa de ferramentas.
"As duas tecnologias apresentam uma curva de aprendizado parecida, com a diferença de que o Java possui mais material para aprendizado na internet do que o .NET, que é proprietário e a principal fonte de conteúdo é o MSDN."
Quem disse? Meu blog não está no MSDN. O de vocês está? (André Dias, você não vale! :) )
Esse grupo não está no MSDN. O codeplex não está no MSDN. Pode ser impressão minha, mas sempre que procurei ajuda em Java, tive muito mais dificuldade. Aos fluentes nos 2 mundos, poderiam dar seu feedback (Philip, André, etc)?
Analisando o último quesito, portabilidade, praticamente não há o que comparar. Como já dito na coluna anterior, o Java segue o princípio write once, run anywhere, permitindo executar as aplicações na virtual machine em praticamente qualquer ambiente. O .NET roda apenas no Windows, no seu hardware suportado, e no ambiente .NET. Há algumas implementações adicionais do .NET que rodam em outras plataformas, porém que não permitem o uso de todo o potencial do framework.
.Net roda em MAC, Linux e Unix. Silverlight (que é .Net) já roda em aparelhos Nokia, por exemplo. É questão de tempo.
E como assim, "no seu hardware suportado"? Até onde sei, servidores de baixa plataforma rodam tanto Linux quanto Windows, com a diferença que você não tem que ficar caçando drivers na rede para o Windows, o Windows Update cuida disso pra você.
Nunca disse que o Java era ruim. Só que, pelos motivos que dei acima, prefiro .Net (até meio óbvio, né?).
Sou fã das ferramentas, são linguagens 100% OO, posso usar a linguagem que quiser (adoro isso). Não há um único motivo para usar Java, na minha opinião.
Por fim, IMHO, o JCP, que é a organização que decide o futuro do Java, impede muito o progresso do Java. Ok, é "democrático", mas e daí? Ok, o Java é open source. E daí? As empresas sérias esperam um release oficial, não saem por aí, com poucas exceções, reconstruindo o Java, enfiando delegates no Java enquanto o JCP não decide se vai entrar ou não.
Fora que esse lance de open source é uma brincadeira. No board final de decisões do JCP estão IBM, Oracle, Sun, BEA (ou seja, Oracle, Oracle e Oracle), etc. Na prática, o que a Microsoft faz sozinha, de forma monopolística (sic), é feito por um oligopólio, que tem a Oracle como membro triplo-votante. Isso pode até ser alerdeado com o democracia, mas não é. Essas empresas lutam no JCP para enfiar na linguagem coisas que façam sentido para suas estratégias comerciais, e fingem-se de bem intencionadas através de um processo OS. Hipocrisia até a última gota. Pior que tem quem compre essa baboseira.
E com o Eclipse é a mesma coisa.
Giovanni Bassi
Rafael Rosa
Raphael Molesim
superficial do assunto.
Comparar Java e .NET já é complicado. Agora comparar PHP com Ruby On
Rails?????
Lamentável...
Giovanni Bassi
Phillip Calçado
2009/6/5 Giovanni Bassi <gig...@giggio.net>:
> Pelo que entendi ele quer dizer que o .Net não suporta 64 bits. Só que
> suporta sim, desde a versão 1.0. Desinformação. Ou seja, desconsiderado.
Acho que ele estava falando em relação a sistemas operacionais, mas
realmente ficou confuso. De qualquer maneira quem coloca clusters como
escalabilidade razoável em 2009 dificilmente teve que lidar com
problemas sérios de escalabilidade.
> Se considerar
> que no Java usam-se 300 frameworks para fazer uma coisa, e que cada vez que
> você contrata um desenvolvedor precisa ensinar ele a usar o framework que
> você utiliza, já perde mais uns 10%. Colocando outras possibilidades, como
> delegates, enums (que o Java só recebeu recentemente), LINQ, etc, vai mais
> uns 10%. Ou seja, dá uma produtividade de até 40% a mais... Ainda bem que
> desenvolvedor é barato, e que o caro é máquina, não é? Ops, acho que é o
> contrário...
Assim como eu vejo diversos pontos errados no texto original tenho que
pedir para que mantenhamos o FUD fora desta lista. Em java existem 300
frameworks para fazer qualquer coisa da mesma forma que existem tantas
possibilidades de resolver qualquer problema. Ter poucas opções não só
não é bom bem como não garante produtividade nenhuma -muitos projetos
.Net que eu tive que lidar com acabaram criando seu próprio framework
caseiro.
> O primeiro absurdo é o cara jogar no lixo o conceito de melhor ferramenta
> para o trabalho. Linguagens funcionais onde o esforço é cálculo, matemático,
> etc. Linguagens dinâmicas onde é possível. Linguagens estáticas são ainda
> uma opção, e linguagens nativas para trabalhar no baixo nível.
Não sei exatamente de onde você tirou estas definições de "cenário
ideal" mas elas são bem problemáticas. Misturar tipagem (estática,
dinâmica, etc.) com paradigma principal (funcional, OO, etc.) não faz
o menor sentido. Você pode ter linguagens OO estáticas ou dinâmicas
(Java/C# e Ruby) assim como pode ter linguagens funcionais estáticas
ou dinâmicas (Haskell e Scheme).
> Algumas, como
> o C#, trazem conceitos de todas (nativa, funcional, dinâmica e estática).
Não sei exatamente onde C# tem algo de linguagens de tipagem dinâmica
(dado que inferência de tipos é bem comum em linguagens estáticas).
Também não entendo o que C# tem de funcional, a menos que você conte
lambdas que são comuns em dezenas de linguagens não funcionais.
> Esse grupo não está no MSDN. O codeplex não está no MSDN. Pode ser impressão
> minha, mas sempre que procurei ajuda em Java, tive muito mais dificuldade.
> Aos fluentes nos 2 mundos, poderiam dar seu feedback (Philip, André, etc)?
Estando de volta à .Net após um longo período (o último projeto foi em
2006) posso dizer que sim, é bem mais difícil achar informação *de
qualidade* em .Net. A documentação de referência não é suficiente -bem
como a documentação oficial do Java nunca foi suficiente- e nas
últimas duas semanas o que tem me salvado são os livros e as listas
como esta. Os blogs e artigos de revista geralmente parecem estar mais
interessados em mostrar em qual botão clicar (com screenshot!) do que
nos porques e melhores técnicas.
> Até onde sei, servidores de baixa
> plataforma rodam tanto Linux quanto Windows, com a diferença que você não
> tem que ficar caçando drivers na rede para o Windows, o Windows Update cuida
> disso pra você.
Desculpe mas isso é mais FUD. A última vez que tive que procurar
driver para placa de rede em uma máquina com Linux foi há mais de
cinco anos.
> Sou fã das ferramentas, são linguagens 100% OO, posso usar a linguagem que
> quiser (adoro isso).
C# não é 100% OO (não que isso importe na prática).
> Por fim, IMHO, o JCP, que é a organização que decide o futuro do Java,
> impede muito o progresso do Java. Ok, é "democrático", mas e daí? Ok, o Java
> é open source. E daí? As empresas sérias esperam um release oficial, não
> saem por aí, com poucas exceções, reconstruindo o Java, enfiando delegates
> no Java enquanto o JCP não decide se vai entrar ou não.
Isso não condiz com minha experiência. Se você contar apenas a JVM eu
já trabalhei com mais de 6 fornecedores diferentes -o que era muito
comum antes do HotSpot da Sun se tornar excelente. Em três empresas
nós utilizamos em produção uma máquina virtual com patches ou escritos
por nós mesmos ou que nos foram enviados pelo suporte da Sun como
código-fonte antes de serem incluídos na distribuição oficial.
> Fora que esse lance de open source é uma brincadeira. No board final de
> decisões do JCP estão IBM, Oracle, Sun, BEA (ou seja, Oracle, Oracle e
> Oracle), etc. Na prática, o que a Microsoft faz sozinha, de forma
> monopolística (sic), é feito por um oligopólio, que tem a Oracle como membro
> triplo-votante. Isso pode até ser alerdeado com o democracia, mas não é.
> Essas empresas lutam no JCP para enfiar na linguagem coisas que façam
> sentido para suas estratégias comerciais, e fingem-se de bem intencionadas
> através de um processo OS. Hipocrisia até a última gota. Pior que tem quem
> compre essa baboseira.
Desculpe mas isto é mais FUD. O JCP não é o melhor processo do mundo
mas a simples existência do EJB 3 -criado pela comunidade, apoiado por
um fornecedor open-source de tamanho muito pequeno e que se tornou
padrão contrariando coisas grotescas e altamente lucrativas como
UIX/BC4J da Oracle- mostra que as coisas não são assim.
> E com o Eclipse é a mesma coisa.
Ahm?
Fico bem decepcionado em ler este tipo de email nesta lista. É a
primeira vez que eu participo de uma comunidade brasileira de .Net
exatamente porque pela primeira vez vi algo em português que não tinha
este tipo de pensamento de que "opções são ruins", "JCP não presta" e
que "Java é uma droga". Se alguém escreve um artigo falando
extremamente mal informado sobre .Net será que temos que reagir da
mesma maneira sobre Java? Será que não é melhor tentarmos entender que
em 2009 temos conhecimento e maturidade como indústria o suficiente
para que utilizemos as arquiteturas que façam mais sentido para um
dado cenário?
Deixo meu convite para que pensemos melhor e voltemos a discutir sobre
o que conhecemos e sobre o que queremos conhecer.
[]s
--
Phillip Calçado
http://fragmental.tw
http://www.fragmental.com.br
Emmanuel G. Brandão
Rodrigo Vieira
http://msdn.microsoft.com/en-us/library/s1ax56ch.aspx
De qq forma esse conceito de "o que é ser 100% OO" varia mesmo, muita
gente diz que a única linguagem totalmente OO é Smalltalk!
2009/6/7 Emmanuel G. Brandão <egomes...@gmail.com>:
Emmanuel G. Brandão
Marcelo Castellani
Emmanuel G. Brandão escreveu:
> eu conheço, SmallTalk eu não conheço.
>
> Brandão, Emmanuel G.
> CSM
> http://egomesbrandao.blogspot.com
>
>
> 2009/6/7 Rodrigo Vieira <rodr...@gmail.com <mailto:rodr...@gmail.com>>
>
> C# não é 100% OO pois possui value types que não são objetos, por
> exemplo int.
>
> http://msdn.microsoft.com/en-us/library/s1ax56ch.aspx
>
> De qq forma esse conceito de "o que é ser 100% OO" varia mesmo, muita
> gente diz que a única linguagem totalmente OO é Smalltalk!
>
>
> 2009/6/7 Emmanuel G. Brandão <egomes...@gmail.com
> >
> > Somente a título de curiosidade mesmo, e sem criar polêmica, e
> mais ainda
> > isso não importa na prática; mas por que você disse que C# não é
> 100% OO?
> > Até onde eu sei, ou sabia, C# desde que foi lançado é 100% OO, ao
> contrário
> > do Java que não era naquela época.
> > Brandão, Emmanuel G.
> > CSM
> > http://egomesbrandao.blogspot.com
> <http://egomesbrandao.blogspot.com/>
> >
> >
> > 2009/6/7 Phillip Calçado <pcal...@gmail.com
> <mailto:pcal...@gmail.com>>
> <mailto:gig...@giggio.net>>:
> >> http://www.fragmental.com.br <http://www.fragmental.com.br/>
> >> >>
> >
>
>
> >
Jeferson Spencer Chaves
Mas dificilmente uma linguagem comercial adere a um só paradigma ou implementa 100% os paradigmas que ela adere.
Java e C# são linguagens comerciais e são exemplo disso tal qual VB, Delphi, etc.
Um abraço,
Jéferson Spencer Chaves
--
------------------------------------------------------------
Jéferson Spencer Chaves
Phillip Calçado
> Mas isso o Java também tem... Aliás, acho que todas as linguagens OO que eu
> conheço, SmallTalk eu não conheço.
Exato. Eu não falei que Java é 100% Orientada a Objetos, qualquer um
que escreva um programa usando reflection vai ver que mesmo com
autoboxing você sempre tem que lidar int e Integer como coisas
diferentes. Aliás, Gilad Bracha escreveu recentemente sobre como isso
é o "pecado original" desta linguagem:
http://gbracha.blogspot.com/2009/05/original-sin.html
Ruby é dita ser 100% OO. Para mim o fato de que existe diferença entre
blocos e procs faz com que isso não seja verdade.
Giovanni Bassi
Não vou discutir sobre o que você considera FUD, porque pelo que entendi vamos ficar dando volta em circulos, e o objetivo não é esse.
Entendo que uma linguagem dinâmica não possui somente a tipagem dinâmica. O modelo de dispatch, por exemplo, tem que ser dinâmico também. Tipagem é só mais uma característica...
Misturei os conceitos porque são características que dominam a maneira como as linguagens são utilizadas. Por exemplo, Ruby é uma linguagem orientada a objetos dinâmica, mas quando falamos de Ruby não falamos de uma linguagem OO, mas de uma linguagem dinâmica. O mesmo para F#: é funcional, e é OO (multi-paradigma), mas é vista principalmente como uma linguagem funcional.
Quanto ao C# ter características dinâmicas, veja aqui:
http://unplugged.giggio.net/post/C-40-Uma-linguagem-dinamica.aspx
Veja que nesse caso, a tipagem é estática, mas o dispatch é dinâmico.
Da mesma forma que o objeto é o conceito mais importante em OO, a função é em uma linguagem funcional. E as lambdas trazem a função à tona no C# como conceito de primeiro nível. Isso já podia ser feito antes como delegates anonimos, mas as lambdas facilitaram e deixaram o código mais explícito, o que é um grande passo. Quanto à várias linguagens implementarem lambdas, isso só reforça o conceito. Não estou sozinho nesta opinião, o mercado entende que, sim, as lambdas são a característica funcional do C#.
Legal seu feedback com relação à busca de informação em .Net. Será que é porque originamos de mundo diferentes, e quando procuro algo em Java também tenho dificuldade, da mesma forma que você no mundo de .Net? Faz sentido? Alguns sites, como o stackoverflow.com são excelentes fóruns de discussão, e não só de .Net. O que falta exatamente? De repente tem uma oportunidade aí, algo não atendido. O que o mundo de Java tem que o mundo de .Net não tem nesse sentido?
Eu não vivo em um mundo de Java, mas nunca vi um cliente alterar a JVM, nem em clientes grandes, nem pequenos. Mas, como eu disse, não vivo nesse mundo... de qualquer forma, entendo ser algo arriscado. E se a linguagem evoluir para o lado oposto? Você perde as customizações que fez no código? Nesses cenários que você citou, a empresa evoluia o Java independentemente, acrescentando ou mundando comportamento e sintaxe?
Philip, não entendo como é possível que você ache que o JCP está evoluindo o Java com uma velocidade boa. Os caras demoram anos para concluir as coisas... Enfim, vai ver eu estou mal acostumado...
O que eu disse do Eclipse, é que grandes empresas colocam muito dinheiro para evoluir a ferramenta de acordo com suas aspirações comerciais, e vendem isso como trabalho comunitário. Não gosto dessa atitude. Se é pelo lucro, que assuma isso.
Em nenhum momento eu disse que Java é uma droga. Aqui nessa thread mesmo eu disse: "Não acho que o .Net ganhe em absolutamente em tudo, e quando não ganha eu digo." A questão é: prefiro .Net. E dei meus motivos para isso.
Quando eu critico o JCP, entendo que quem deveria criticar são os próprios profissionais que trabalham com Java. Eu não trabalho com Java, e se a linguagem parar no tempo, não vai me afetar. São eles que devem se incomodar com a lentidão que vejo no JCP. Se o mundo de Java está ok com o JCP, então está tudo certo.
Quanto à opção, veja bem: o fato de, de certa forma, muitas empresas esperarem a Microsoft lançar para usar alguma ferramenta ou conceito, tem dois lados. O primeiro é que simplifica o mercado, e é muito fácil reaproveitar o profissional, que é o recurso mais caro em TI hoje em dia. O segundo, que é ruim e decorre do primeiro, é que muitos conceitos bons não são usados porque não há ferramenta Microsoft oficial que suporte o conceito. Um exemplo: mocks. Não há framework de mocks da Microsoft, e muita empresa não usa porque não há um "oficial". Isso é ruim. Da mesma forma, mesmo tendo ORMs muito bons, só agora, que o Entity Framework foi feito, é que a maioria do mundo de .Net está olhando esse assunto com seriedade.
Por fim, respondendo à sua pergunta:
"Será que não é melhor tentarmos entender que em 2009 temos conhecimento e maturidade como indústria o suficiente para que utilizemos as arquiteturas que façam mais sentido para um dado cenário?"
A minha opinião é que .Net atende a mim e aos meus clientes melhor. Tenho motivos para achar isso. Em que cenários? Em muitos: desenvolvimento web, client, mobile, games, embedded, robótica, BD, cloud computing, etc, etc. Ainda assim, eu não diria a um cliente que investiu milhões em Java que o abandone, a não ser que ele considerasse isso antes de mim, a não ser que isso doesse para ele. De outra forma, não funcionaria.
Eu entendo que o valor do .Net é maior em muitos desses cenários. Entendo que um profissional de Java discorde de mim, e isso faz parte. É uma discordância profissional, e cada um fique com o que entende como melhor.
De qualquer forma, essa discussão é irrelevante, e o mercado é muito grande, e há espaço para todo tipo de profissional. Java, .Net, Ruby, PHP, etc, etc...
Por fim, o que o C# não tem de 100% OO? Herança múltipla não é obrigatório no meu entendimento. OO não é algo fechado, 100% definido. Não há uma organização que defina o que é OO ou não.
Raphael Molesim
é MUITO MAIS RÁPIDA que qualquer empresa como a Microsoft.
Concordo com o giovanni de que alterar um JVM é algo complicado por
questões de atualização com a versão principal do java. Mas que é
importante você ter a opção caso realmente precise. Um exemplo disso é
o Android, que não existiria se o linux não fosse aberto.
Quanto a questão dos vários frameworks de java, ainda bem que temos
muitas opções. Já imaginou só termos o Entity Framework? Ter de
esperar até a versão 2.0 para começar a ficar razoável? Um detalhe, a
diferença do Hibernate para EF V.2.0 é de somente CINCO anos.
Prefiro ter várias opções do que ser preso a uma fidelidade
predatória, como por exemplo o Web Forms.
Para mim a pergunta "Vamos utilizar web forms?" é algo parecido com
"Vamos multilar o cerebro dos desenvolvedores web?". Ainda bem que
hoje a própria microsoft volta atrás com o ASP.NET MVC.
Não sou contra o Web Forms ou contro o EF, acho que ambos possuem seus
cenários de aplicação. O problemas foi não darem opções, ambas as
soluções não solucionavam todos os cenários, se não fosse a
contribução da comunidade teria sido muito complicado.
SEMPRE falei de ambiente HETEROGÊNEOS e sempre fui tido como "o do
contra" por alguns aqui da comunidade.
Foi o que eu disse a poucos dias sobre a comunidade .NET ser insular,
esta melhorando, mas ainda falta muito.
OBS: Não conheço quase nada de linux, instalei pela primeira vez faz
uns dois ou três meses, mas uma coisa eu posso diser: Foi muito, mas
muito, mas muito mais fácil do que instalar qualquer versão do Windows
que já instalei! A instalação de softwares então, com Synaptic nunca
ví algo tão fácil. Adorei o Ubuntu e o Ruby, não largo por nada! De
Ruby o que tenha a diser é: quanto mais eu conheço mais eu gosto! É
realmente apaixonante!
Em Ruby posso fazer private.class e isso é uma classe! OO de verdade!
Antes que alguém fale, eu não disse 100%.
>
> mais »
Phillip Calçado
2009/6/8 Giovanni Bassi <gig...@giggio.net>:
> Entendo que uma linguagem dinâmica não possui somente a tipagem dinâmica. O
> modelo de dispatch, por exemplo, tem que ser dinâmico também. Tipagem é só
> mais uma característica...
Ok, é sua definição pessoal mas não entendo no que dynamic dispatch
seria relevante dado que Java e C# -e basicamente qualquer linguagem
que tenha polimorfismo- o possuem.
> Misturei os conceitos porque são características que dominam a maneira como
> as linguagens são utilizadas. Por exemplo, Ruby é uma linguagem orientada a
> objetos dinâmica, mas quando falamos de Ruby não falamos de uma linguagem
> OO, mas de uma linguagem dinâmica. O mesmo para F#: é funcional, e é OO
> (multi-paradigma), mas é vista principalmente como uma linguagem funcional.
Novamente é a sua opinião, ok.
Para mim continua não fazendo sentido mas creio que temos opiniões diferentes.
> Quanto ao C# ter características dinâmicas, veja aqui:
> http://unplugged.giggio.net/post/C-40-Uma-linguagem-dinamica.aspx
No seu último email você não afirmou que estava falando da futura
versão de C#. Meu email trata de tecnologias e técnicas que estão
disponíveis, do contrário poderíamos, por exemplo, estar discutindo
sobre as propostas de closures para Java.
> Veja que nesse caso, a tipagem é estática, mas o dispatch é dinâmico.
Acho que estamos com conceitos bem diferentes sobre dispatch dinâmico
aqui. Dispach dinâmico é apenas o ato de não fazer a ligação entre
identificador do método (ou equivalente) à sua implementação durante a
compilação, fazê-lo apenas em runtime. Como disse anteriormente tanto
Java quanto C# utilizam isso para implementar polimorfismo. O que seu
artigo fala é -novamente- sobre tipagem dinâmica.
> Da mesma forma que o objeto é o conceito mais importante em OO, a função é
> em uma linguagem funcional. E as lambdas trazem a função à tona no C# como
> conceito de primeiro nível. Isso já podia ser feito antes como delegates
> anonimos, mas as lambdas facilitaram e deixaram o código mais explícito, o
> que é um grande passo. Quanto à várias linguagens implementarem lambdas,
> isso só reforça o conceito.
Não é bem por aí. Creio que você está fazendo uma confusão entre
linguagens funcionais e higher-order functions. O que C# e Ruby
possuem é a última característica, o que não caracteriza uma inguagem
como funcional.
> Não estou sozinho nesta opinião, o mercado
> entende que, sim, as lambdas são a característica funcional do C#.
Eu não confio no "mercado" quando o assunto são linguagens de
programação. O mercado afirma o que for mais interessante, ao
contrário da ciência da computação que tende a afirmar algo apenas
após pesquisas e resultados.
> Legal seu feedback com relação à busca de informação em .Net. Será que é
> porque originamos de mundo diferentes, e quando procuro algo em Java também
> tenho dificuldade, da mesma forma que você no mundo de .Net? Faz sentido?
> Alguns sites, como o stackoverflow.com são excelentes fóruns de discussão, e
> não só de .Net. O que falta exatamente? De repente tem uma oportunidade aí,
> algo não atendido. O que o mundo de Java tem que o mundo de .Net não tem
> nesse sentido?
Acho que falta profundidade. É o mesmo problema que tenho, por
exemplo, em Rails e Cocoa (desenvolvimento para IPhone): existem
zilhões de tutoriais mas ninguém está interessado em explicar o porque
de alguma coisa. Em Rails eu geralmente leio o código fonte.
Felizmente ao contrário de minha experiência em 2005-2006 com .Net
hoje em dia existe muito código aberto (ainda que não livre) pela
Microsoft e é possível adotar a mesma prática. No caso do IPhone é
sentar e chorar.
> Eu não vivo em um mundo de Java, mas nunca vi um cliente alterar a JVM, nem
> em clientes grandes, nem pequenos. Mas, como eu disse, não vivo nesse
> mundo... de qualquer forma, entendo ser algo arriscado. E se a linguagem
> evoluir para o lado oposto? Você perde as customizações que fez no código?
> Nesses cenários que você citou, a empresa evoluia o Java independentemente,
> acrescentando ou mundando comportamento e sintaxe?
Nestes casos não houve mudança na sintaxe e sim na JVM. Na maioria das
vezes eram bugs a serem corrigidos. Eu trabalhei em diversas empresas
que integravam C++ com Java e a quantidade de bugs que só aconteciam
em uma determinada versão de SO com uma determinada versão de Java e
uma determinada versão de GCC ou VC++ era enorme. O poblema é que
exeto por noso projeto ninguém mais no mundo ligava para este
problema. A solução muitas vezes foi escrever o patch, outras foi
pagar suporte da Sun e receber um patch.
As modificações geralmente são enviadas de volta ao mantenedor
(antigamente seria a Sun, hoje existe o projeto OpenJDK) e quase
sempre eram incluídas. Quando não o foram a empresa pelo menos ganhou
tempo para remover a causa do problema -geralmente fazendo upgrade de
SO ou compilador- antes de migrar para a próxima versão de Java.
> Philip, não entendo como é possível que você ache que o JCP está evoluindo o
> Java com uma velocidade boa. Os caras demoram anos para concluir as
> coisas... Enfim, vai ver eu estou mal acostumado...
Eu não disse isso. O que eu disse é que sua afirmação sobre o JCP ser
uma "baboseira" não era verdade e dei um exemplo. O JCP é extremamente
lento e ineficiente mas nos áureos tempos de Java (i.e. 2003-2006)
isso nunca foi problema porque o JCP nunca inovou de verdade (e quando
o fez sempre foi uma tragédia). Como no caso de Groovy, Hibernate,
Spring e tantos outros o que o JCP faz de melhor é apenas criar um
padrão para unir diversas teconogias já estabelecidas.
Isso é um problema para a *linguagem* Java porque dificilmente se
conseguiria evoluir uma linguagem tão amarrada quanto Java sem ter que
envolver todo um comitê -como contra-exemplo recomendo uma leitura
sobre como CLOS, o sistema OO de Common Lisp, foi desenvolvido sem
modificar a linguagem. IMHO isso foi uma das grandes causas do
esvaziamento de Java (linguagem) mas acredito que hoje a comunidade
esteja relativamente satisfeita ao se partir em dezenas de linguagens
que rodam na JVM.
> O que eu disse do Eclipse, é que grandes empresas colocam muito dinheiro
> para evoluir a ferramenta de acordo com suas aspirações comerciais, e vendem
> isso como trabalho comunitário. Não gosto dessa atitude. Se é pelo lucro,
> que assuma isso.
Este é um ponto interessante, entretanto eu não concordo com seu
argumento. A maioria dos projetos de software open-source são fundados
por empresas que lucram em cima deles.
O Eclipse é uma ótima IDE -apesar de ter entregue muito pouco em suas
duas últimas versões- mas o projeto tem diversos problemas causados
pelo fato de ser um consórcio. Eu conheço pessoas dentro da Eclipse
Foundation e o grande problema que eles têm é certamente o que
qualquer organização tem após criar uma plataforma de sucesso: não há
mais como se movimentar rapidamente. Uma mudança brusca -consertar a
terrível API do SWT, por exemplo- envolve quebrar milhões de produtos
de milhões de fornecedores diferentes.
> Quanto à opção, veja bem: o fato de, de certa forma, muitas empresas
> esperarem a Microsoft lançar para usar alguma ferramenta ou conceito, tem
> dois lados. O primeiro é que simplifica o mercado, e é muito fácil
> reaproveitar o profissional, que é o recurso mais caro em TI hoje em dia. O
> segundo, que é ruim e decorre do primeiro, é que muitos conceitos bons não
> são usados porque não há ferramenta Microsoft oficial que suporte o
> conceito. Um exemplo: mocks. Não há framework de mocks da Microsoft, e muita
> empresa não usa porque não há um "oficial". Isso é ruim. Da mesma forma,
> mesmo tendo ORMs muito bons, só agora, que o Entity Framework foi feito, é
> que a maioria do mundo de .Net está olhando esse assunto com seriedade.
Eu adicionaria à sua lista o fato de que muitas vezes a ferramenta
ofical é uma bela porcaria. Para tentar evitar polêmica desnecessária
eu vou dar um exempo em Java: EJB 2.1. EJBs eram *a* forma de forma de
fazer computação distribuída em Java, muitas empresas utilizam até
hoje porque é suportado por IBM, Oracle e etc.
Entretanto, como disse no meu email anterior, era uma bela porcaria. O
que a comunidade fez foi tentar resolver este problema de modos
diferentes, daí surgiram os 300 frameworks para mesma coisa. O detalhe
importante é que dos 300 frameworks geralmente apenas um ou dois são
amplamente utilizados mas os outros continuam como opções.
> Por fim, respondendo à sua pergunta:
>>
>> "Será que não é melhor tentarmos entender que em 2009 temos conhecimento e
>> maturidade como indústria o suficiente para que utilizemos as arquiteturas
>> que façam mais sentido para um dado cenário?"
>
> Entendo que por arquitetura você está falando desta discussão toda em volta
> de linguagens e sistema operacionais.
Não. Estou falando em arquiteturas heterogêneas. Como um exemplo posso
dar meu projeto atual que é um site com um volume monstruosos de
acessos. O projeto é em .Net mas eu estou usando diversos componentes
que são usados em arquiteturas UNIX (memcached, ngnix, Apache,
Squid...). Eu não estou preso à .Net ou UNIX, estou preso ao que
representa o melhor custo/benefício.
> Eu entendo que o valor do .Net é maior em muitos desses cenários. Entendo
> que um profissional de Java discorde de mim, e isso faz parte. É uma
> discordância profissional, e cada um fique com o que entende como melhor.
Um ponto interessante aqui é que há muito tempo eu não me considero
"um profissional de Java". Eu sou um desenvolvedor de software que
conhece uma quantidade razoável de plataformas e tenta utilizar a
melhor para cada caso. Tenho minhas preferências mas isso não define
que profissional eu sou.
> Por fim, o que o C# não tem de 100% OO? Herança múltipla não é obrigatório
> no meu entendimento. OO não é algo fechado, 100% definido. Não há uma
> organização que defina o que é OO ou não.
O critério mais comum para algo ser 100% Orientado a Objetos é quando
tudo na linguagem é um objeto. Nem Java nem C# possuem esta
característica. Value types em C#, primitivos em Java -e autboxing é
apenas um workaround feito pelo compilador.
Giovanni Bassi
Quanto à dispatch dinâmico: em C# (.Net em geral), a ligação é em tempo de compilação. Somente com o DLR é que o Dispatch passou a ser realmente dinâmico, ou seja, resolvidoem tempo de runtime. Mesmo com polimorfismo, a ligação da chamada do método é feita em tempo de compilação. Não há, por exemplo, avaliação de qual overload vai ser chamado em tempo de execução. Portanto, a ligação é estática. Isso só será possível agora com o DLR. Antes, com reflection, havia essa possibilidade, mas não era a mesma coisa.
Quanto à linguagens funcionais: segundo sua definição, então o F# também não é uma linguagem funcional, e nem o OCAML, do qual ele é uma simplificação.
Eu não disse que C# era uma linguagem funcional, mas que tinha características funcionais.
Continuo achando que opções demais é ruim. Na prática essas opções demais não existem, como você mesmo disse, já que só um ou outro sobrevive. O que sobra é barulho.
Quanto ao JCP: baboseira é essa história de ser comunitário, não o processo todo. É algo dirigido, é isso que eu disse. Comunitário é ilusão.
Entendo que você não se coloque como "profissional de java", e respeito isso. No entanto, eu não acredito ser possível acompanhar a quantidade de tecnologias que estão surgindo, e ainda fazer isso em n plataformas em paralelo. Hoje eu estudo a fundo o .Net. Conheço C#, VB, J#, C++, IronRuby, F#... Algumas linguagens mais que as outras. Conheço ASP.Net WF, MVC, Windows Forms, WPF, entlib, NH, Silverlight, Mobile, XNA, ADO.Net, EF, WCF, WF, etc, etc, etc... a lista não para. Algumas mais do que outras também. Se eu tivesse ainda que focar em Java, meu conhecimento em .net seria infinitamente mais superficial, por um só motivo: não há tempo. No mundo de hoje, foco é fundamental. Acho um diferencial importante você conhecer memcache, só não acho que vou investir nisso, porque há coisas mais importantes no próprio .Net a avaliar.
Não concordo com sua definição de 100% OO, mas respeito.
Ficou faltando você dizer os recursos de documentação/suporte de Java que o .net não tem...
Ricardo Cunha
Marcos Dell Antonio
Acho que são poucas as chances de vermos pessoas inteligentes (Phillip, Giovanni, etc), discutindo e defendendo alguns ideais e principalmente esclarecendo alguns conceitos.
Se tudo o que eles falaram aqui fosse numa thread ".NET é a melhor plataforma", excluindo a comparação com o java, tenho certeza que não teríamos críticas como essa sua. Veja bem, é a minha opinião, a lista é democrática, não se ofenda!
Ricardo Cunha
Daniel Moreira Yokoyama
Atenciosamente,
Daniel Moreira Yokoyama.
"I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do."
(HAL 9000)
Giovanni Bassi
Entendo seu sentimento.
Eu realmente gosto desta discussão. Na verdade eu gosto muito de debater qualquer assunto. Acho que ajuda a esclarecer.
Acho os comentários do Philip e de todos importante. Ele trouxe diversos pontos de vista, e, mesmo não concordando com todos, respeito e gosto de saber como ele pensa.
Realmente fugimos do assunto da lista. Até por isso o Marcos marcou o tópico como off, para que saibamos que estamos debatendo um assunto paralelo. Quem acha que não interessa pode simplesmente ignorar.
Temos tido diversos outros assuntos que não são off-topic na lista, e não sinto que algumas discussões paralelas cheguem a atrapalhar ou motivar a saída da lista. Essa não é primeira, e certamente não é a última.
De certa forma entendi que a discussão interessava ao grupo, que trata de .Net, ainda que especificamente de arquitetura. Se me enganei, peço que outros membros entrem em contato em particular e me digam, para entender como o grupo vê isso. Por outro lado, se outros membro do grupo entendem, como o Marcos, que a discussão, não deixem de me dizer também.
Ricardo Cunha
Cássio Rogério Eskelsen
Cássio Rogério Eskelsen
Ricardo Cunha
Phillip Calçado
2009/6/9 Giovanni Bassi <gig...@giggio.net>:
> Eu acho que isso aqui está ficando muito grande. Vou tentar ser breve...
> Quanto à dispatch dinâmico: em C# (.Net em geral), a ligação é em tempo de
> compilação. Somente com o DLR é que o Dispatch passou a ser realmente
> dinâmico, ou seja, resolvidoem tempo de runtime. Mesmo com polimorfismo, a
> ligação da chamada do método é feita em tempo de compilação. Não há, por
> exemplo, avaliação de qual overload vai ser chamado em tempo de execução.
> Portanto, a ligação é estática. Isso só será possível agora com o DLR.
> Antes, com reflection, havia essa possibilidade, mas não era a mesma coisa.
Parece que estamos com definições *bem* diferentes de dynamic
dispatch. Como você disse static dispatch é quando a implementação
para os métodos são encontrados em compile time. Este é o default em
C# mas a coisa muda de figura quando você marca um método como
virtual. Um método virtual possui dynamic dispatch, por isso que você
não precisa recompilar uma dll de terceiros para estender uma classe,
por exemplo.
Uma referência:
Este livro é altamente recomendado, um dos poucos sobre linguagens de
programação que usa exemplos em linguagens mainstream como C#, Java e
Ruby.
> Quanto à linguagens funcionais: segundo sua definição, então o F# também não
> é uma linguagem funcional, e nem o OCAML, do qual ele é uma simplificação.
Eu não me lembro de ter dado nenhuma definição de linguagem funcional,
apenas de dizer que higher-order functions não fazem de uma linguagem
funcional.
> Eu não disse que C# era uma linguagem funcional, mas que tinha
> características funcionais.
Correto, eu acabei passando por cima do que você disse.
> Continuo achando que opções demais é ruim. Na prática essas opções demais
> não existem, como você mesmo disse, já que só um ou outro sobrevive. O que
> sobra é barulho.
Não. As opções existem, muitas vezes você precisa utilizar um
framework de nicho para solucionar um problema específico. Como
exemplo rápido, ano passado eu desenvolvi um sistema que era um
instance-based component, algo que era distribuído como um arquivo JAR
que outras pessoas utilizariam em seus projetos. O projetinho cresceu
e precisávamos de algo como um framework de injeção de dependências.
O framework mais mainstram em Java é o Spring mas este possui centenas
de recursos que não utilizaríamos e acrescentaria alguns megabytes ao
nosso projeto. Solução? PicoContainer. Um ótimo framework para injeção
de dependências que não tem nem metade do público do Spring. Opções
são boas.
> Quanto ao JCP: baboseira é essa história de ser comunitário, não o processo
> todo. É algo dirigido, é isso que eu disse. Comunitário é ilusão.
Foi exatamente isso que eu combati. É a terceira vez que eu trabalho
em uma empresa que faz parte do JCP e minha experiência não
corresponde com esta afirmação.
> Entendo que você não se coloque como "profissional de java", e respeito
> isso. No entanto, eu não acredito ser possível acompanhar a quantidade de
> tecnologias que estão surgindo, e ainda fazer isso em n plataformas em
> paralelo. Hoje eu estudo a fundo o .Net. Conheço C#, VB, J#, C++, IronRuby,
> F#... Algumas linguagens mais que as outras. Conheço ASP.Net WF, MVC,
> Windows Forms, WPF, entlib, NH, Silverlight, Mobile, XNA, ADO.Net, EF, WCF,
> WF, etc, etc, etc... a lista não para. Algumas mais do que outras também. Se
> eu tivesse ainda que focar em Java, meu conhecimento em .net seria
> infinitamente mais superficial, por um só motivo: não há tempo. No mundo de
> hoje, foco é fundamental. Acho um diferencial importante você conhecer
> memcache, só não acho que vou investir nisso, porque há coisas mais
> importantes no próprio .Net a avaliar.
Bom, eu discordo largamente. O que importa são conceitos, as
implementações são sempre muito parecidas. O Velocity da MS, por
exemplo, é uma outra implementação do mesmo conceito do memcached.
Acredito que ao se aprofundar mais nos conceitos (e daí parte minha
crítica anterior aos blogs de .Net) a implementação importa muito
pouco. Essa ao menos é minha experiência.
> Ficou faltando você dizer os recursos de documentação/suporte de Java que o
> .net não tem...
Não entendi este ponto, é com relação à minha crítica aos blogs?
Giovanni Bassi
> Ficou faltando você dizer os recursos de documentação/suporte de Java que o
> .net não tem...
Não entendi este ponto, é com relação à minha crítica aos blogs?
Quanto ao dispatch dinâmico, realmente estamos falando coisas diferentes. Porque, se for assim, todas as chamadas no C# são virtuais. O livro mencionado falha largamente em mencionar esse tipo de coisa. E mesmo nesse caso, não há dispatch dinâmico, a ligação é em tempo de compilação. Veja um exemplo:
class Class1
{
public virtual void Virtual()
{
}
public void NaoVirtual()
{
}
}
class Class2 : Class1
{
public override void Virtual()
{
base.Virtual();
}
}
Duas classes, uma base da outra, a base com uma função virtual, e a outra não.
As chamadas na classe program:
void ChamaC1()
{
var c1 = new Class1();
c1.Virtual();
c1.NaoVirtual();
}
void ChamaC2()
{
var c2 = new Class2();
c2.Virtual();
c2.NaoVirtual();
}
Agora, veja o IL gerado:
.method private hidebysig instance void ChamaC1() cil managed { .maxstack 1 .locals init ( [0] class ConsoleApplication2.Class1 c1) L_0000: nop L_0001: newobj instance void ConsoleApplication2.Class1::.ctor() L_0006: stloc.0 L_0007: ldloc.0 L_0008: callvirt instance void ConsoleApplication2.Class1::Virtual() L_000d: nop L_000e: ldloc.0 L_000f: callvirt instance void ConsoleApplication2.Class1::NaoVirtual() L_0014: nop L_0015: ret } .method private hidebysig instance void ChamaC2() cil managed { .maxstack 1 .locals init ( [0] class ConsoleApplication2.Class2 c2) L_0000: nop L_0001: newobj instance void ConsoleApplication2.Class2::.ctor() L_0006: stloc.0 L_0007: ldloc.0 L_0008: callvirt instance void ConsoleApplication2.Class1::Virtual() L_000d: nop L_000e: ldloc.0 L_000f: callvirt instance void ConsoleApplication2.Class1::NaoVirtual() L_0014: nop L_0015: ret } |
- Não há diferença entre uma chamada virtual e uma não virtual.
- Todas as chamadas passam por um "callvirt", ou seja, de certa forma todas são virtuais.
static void Main(string[] args)
{
dynamic c1 = new Class1();
c1.Virtual();
}
Veja o IL gerado (resumido):
L_0011: ldstr "Virtual"
L_0016: ldtoken ConsoleApplication2.Program
L_001b: call class [mscorlib]System.Type [mscorlib]System.Type::GetTypeFromHandle(valuetype [mscorlib]System.RuntimeTypeHandle)
L_0020: ldnull
L_0021: ldc.i4.1
L_0022: newarr [Microsoft.CSharp]Microsoft.CSharp.RuntimeBinder.CSharpArgumentInfo
L_0027: stloc.2
L_0028: ldloc.2
L_0029: ldc.i4.0
L_002a: ldc.i4.0
L_002b: ldnull
L_002c: newobj instance void [Microsoft.CSharp]Microsoft.CSharp.RuntimeBinder.CSharpArgumentInfo::.ctor(valuetype [Microsoft.CSharp]Microsoft.CSharp.RuntimeBinder.CSharpArgumentInfoFlags, string)
L_0031: stelem.ref
L_0032: ldloc.2
L_0033: newobj instance void [Microsoft.CSharp]Microsoft.CSharp.RuntimeBinder.CSharpInvokeMemberBinder::.ctor(valuetype [Microsoft.CSharp]Microsoft.CSharp.RuntimeBinder.CSharpCallFlags, string, class [mscorlib]System.Type, class [mscorlib]System.Collections.Generic.IEnumerable`1<class [mscorlib]System.Type>, class [mscorlib]System.Collections.Generic.IEnumerable`1<class [Microsoft.CSharp]Microsoft.CSharp.RuntimeBinder.CSharpArgumentInfo>)
L_0038: call class [System.Core]System.Runtime.CompilerServices.CallSite`1<!0> [System.Core]System.Runtime.CompilerServices.CallSite`1<class [mscorlib]System.Action`2<class [System.Core]System.Runtime.CompilerServices.CallSite, object>>::Create(class [System.Core]System.Runtime.CompilerServices.CallSiteBinder)
L_003d: stsfld class [System.Core]System.Runtime.CompilerServices.CallSite`1<class [mscorlib]System.Action`2<class [System.Core]System.Runtime.CompilerServices.CallSite, object>> ConsoleApplication2.Program/<Main>o__SiteContainer0::<>p__Site1
L_0042: br.s L_0044
L_0044: ldsfld class [System.Core]System.Runtime.CompilerServices.CallSite`1<class [mscorlib]System.Action`2<class [System.Core]System.Runtime.CompilerServices.CallSite, object>> ConsoleApplication2.Program/<Main>o__SiteContainer0::<>p__Site1
L_0049: ldfld !0 [System.Core]System.Runtime.CompilerServices.CallSite`1<class [mscorlib]System.Action`2<class [System.Core]System.Runtime.CompilerServices.CallSite, object>>::Target
L_004e: ldsfld class [System.Core]System.Runtime.CompilerServices.CallSite`1<class [mscorlib]System.Action`2<class [System.Core]System.Runtime.CompilerServices.CallSite, object>> ConsoleApplication2.Program/<Main>o__SiteContainer0::<>p__Site1
L_0053: ldloc.1
L_0054: callvirt instance void [mscorlib]System.Action`2<class [System.Core]System.Runtime.CompilerServices.CallSite, object>::Invoke(!0, !1)
Isso para mim é uma chamada com dispatch dinâmico. Note todo o trabalho de uso do DLR para encontrar a função.
Juliano Oliveira
[]´s
Juliano Oliveira
Analista Desenvolvedor
.Net, C#, Actionscript, Flex, NHibernate
http://programandoem.net
twitter: @juloliveira - skype: juloliveira
Phillip Calçado
2009/6/9 Giovanni Bassi <gig...@giggio.net>:
>> Não entendi este ponto, é com relação à minha crítica aos blogs?
>
> Você havia dito que em Java é mais fácil achar informação. O que há em Java
> que não há em .Net? De repente conseguimos preencher um gap...
Como falei antes falta profundidade nos blogs e artigos técnicos.
> Quanto ao dispatch dinâmico, realmente estamos falando coisas diferentes.
> Porque, se for assim, todas as chamadas no C# são virtuais. O livro
> mencionado falha largamente em mencionar esse tipo de coisa. E mesmo nesse
> caso, não há dispatch dinâmico, a ligação é em tempo de compilação. Veja um
> exemplo:
Em uma pesquisa no Google achei alguns resultados interessantes sobre
o que dos métodos não-virtuais serem "virtualizados" pelo compilador:
http://stackoverflow.com/questions/845657/why-is-the-c-compiler-emitting-a-callvirt-instruction-for-a-gettype-method-cal
http://barrkel.blogspot.com/2006/05/call-vs-callvirt-for-c-non-virtual.html
http://www.eggheadcafe.com/software/aspnet/34026727/why-callvirt-on-sealed-ty.aspx
Ou seja: basicamente uma otimização do compilador. Uma coisa boa desta
discussão é que acabo de adicionar o livro mencionado no Stackoverflow
no meu shopping cart, parece bem interessante.
Mas antes de mais nada é importante não confundir a linguagem com sua
implementação. Uma linguagem pode ser implementada de diversas
maneiras, o bytecode gerado pelo compilador não faz parte da
linguagem, ele vai ser otimizado e perder semântica.
E o livro que eu recomendei fala sobre a linguagem de programação e
não sobre a implementação A ou B. Mas se não gostou do livro não há
problema, basta consultar outras obras sobre linguagens de programação
(até a wikipedia!) e pode-se perceber, como falei antes, que se C#
fosse apenas baseada em static dispatch não conseguiria estender uma
classe definida dentro de um binário e tê-la participando de uma
operação polimórfica sem ter que recompilar o binário, dado que quando
o binário foi compilado sua classe não existia.
Mas ainda que a implementação fosse levada em conta o exemplo que você
postou a mim só prova que -por um detalhe de implementação, não pela
linguagem- toda invocação de método em C# é feita por dynamic
dispatching e não apenas métodos virtuais!
Estaria muito interessado em ver alguma referência do que para você é
dynamic dispatching mas, sinceramente, eu paro este assunto por aqui.
Existe literatura mais que abundante sobre o assunto disponível
gratuitamente na Internet para pesquisa e não acho que eu consiga
explicar melhor que a bibliografia. Eu entendo que a nomenclatura
confusa dificulta o entendimento mas dynamic e static dispatch models
são conceitos bem antigos em ciência da computação.
André Dias
http://msdn.microsoft.com/en-us/library/ms998530.aspx
Chapter 1 — Fundamentals of Engineering for Performance
Chapter 2 — Performance Modeling
Chapter 3 — Design Guidelines for Application Performance
Chapter 4 — Architecture and Design Review of a .NET Application for Performance and Scalability
Chapter 5 — Improving Managed Code Performance
Chapter 6 — Improving ASP.NET Performance
Chapter 7 — Improving Interop Performance
Chapter 8 — Improving Enterprise Services Performance
Chapter 9 — Improving XML Performance
Chapter 10 — Improving Web Services Performance
Chapter 11 — Improving Remoting Performance
Chapter 12 — Improving ADO.NET Performance
Chapter 13 — Code Review: .NET Application Performance
Chapter 14 — Improving SQL Server Performance
Chapter 15 — Measuring .NET Application Performance
Chapter 16 — Testing .NET Application Performance
Chapter 17 — Tuning .NET Application Performance
Checklist: ADO.NET Performance
Checklist: Architecture and Design Review for Performance and Scalability
Checklist: ASP.NET Performance
Checklist: Enterprise Services Performance
Checklist: Interop Performance
Checklist: Managed Code Performance
Checklist: Remoting Performance
Checklist: SQL Server Performance
Checklist: Web Services Performance
Checklist: XML Performance
How To: Improve Serialization Performance
How To: Monitor the ASP.NET Thread Pool Using Custom Counters
How To: Optimize SQL Indexes
How To: Optimize SQL Queries
How To: Page Records in .NET Applications
How To: Perform Capacity Planning for .NET Applications
How To: Scale .NET Applications
How To: Submit and Poll for Long-Running Tasks
How To: Time Managed Code Using QueryPerformanceCounter and QueryPerformanceFrequency
How To: Use ACT to Test Performance and Scalability
How To: Use ACT to Test Web Services Performance
How To: Use Custom Performance Counters from ASP.NET
How To: Use CLR Profiler
How To: Use EIF
How To: Use SQL Profiler
http://msdn.microsoft.com/en-us/library/29eafad8.aspx
- Add-ins and Extensibility
- Administration and Management
- Asynchronous Programming Design Patterns
- Component Authoring for the Design Environment
- Dynamic Source Code Generation and Compilation
- Emitting Dynamic Methods and Assemblies
- Expression Trees
- Garbage Collection
- Hosting the Common Language Runtime
- Interoperability
- .NET Remoting
- Network Programming
- Reflection
- Reliability
- Serialization
- Managed Threading
- Writing Serviced Components
Phillip Calçado
Obrigado pelas referências. Eu conheço a MSDN e a utilizo
frequentemente, infelizmente ela não supre todas as dúvidas, bem como
nenhuma documentação de fornecedor nenhum o vai. O meu ponto não é que
a MSDN é incompleta -creio que não falei isso aqui- mas que a
documentação em .Net em geral não se foca no "porque" e sim no "como".
Eu entendo que isso não é visto como um problema pela maioria das
pessoas então não quero convencer ninguém sobre isso.
Sobre dynamic dispatch acho que você não entendeu bem. Não apenas não
é um pattern -é uma característica de uma dada linguagem de
programação- bem como você não precisa de reflection para verificá-lo
em C#, basta usar polimorfismo puro e simples.
[]s
2009/6/9 André Dias <br.a...@hotmail.com>:
> Philip
>
> Eu não sei que tipo de informação que você está buscando e onde você está
> buscando. Mas discordo de você que não há documentação em profundidade,
> preocupação com melhores práticas, etc.
>
> Seguem alguns links para te apoiar na sua busca e se você sentir falta de
> alguma coisa, deixe me saber:
>
--
Emmanuel G. Brandão
Você que tem uma experiência internacional, eu sempre vi que aqui no Brasil o .Net tem mesmo pouquíssima profundidade em exemplos, tanto blog's, revistas e até mesmo no próprio site da Microsoft Brasil. Sempre achei que era mais uma questão cultural, no início por todos procurarem informações em inglês diretamente, mas depois percebi que aqui as pessoas querem mais receitas de bolo, do que textos profundos. Você vê isso em .Net fora do Brasil também?
Acho que esse grupo é uma forma de preencher esse gap. Não serve apenas para os Arquitetos de cargo, mas para todos os desenvolvedores.
Um comentário sobre as diversidade de soluções para o mesmo problema: as vezes isso atrapalha, é complicado, pois ter diversidade é bom, mas demais é ruim, pouco é pior... É interessante que ter esses nichos, mas no .Net por ter começado como uma plataforma completamente fechada não formou essa comunidade. Hoje já esta um pouco diferente com o CodePlex. Um exemplo é que na revista aqui do grupo que estamos lançando, tem um artigo de uma pessoa que achou que nenhum framework de persistência servia para o projeto dele, e começou um, que hoje esta disponível no CodePlex.http://egomesbrandao.blogspot.com
Juliano Oliveira
[]´s
Juliano Oliveira
Analista Desenvolvedor
.Net, C#, Actionscript, Flex, NHibernate
http://programandoem.net
twitter: @juloliveira - skype: juloliveira
Emmanuel G. Brandão
Juliano Oliveira
Juliano Oliveira
[]´s
Juliano Oliveira
Analista Desenvolvedor
.Net, C#, Actionscript, Flex, NHibernate
http://programandoem.net
twitter: @juloliveira - skype: juloliveira
Paulo Bezerra
Alex Takitani Pires
Tão facil rebater os argumentos dele do mesmo jeito estúpido:
"Java é pior pq roda em muitas plataformas, ao contrario do .net especializado em windows, assim garantindo sempre a melhor performance e compatibilidade".
Giovanni Bassi
Seguindo no assunto de dynamic dispatch. Vou te passar algumas referências, já que elas fizeram falta.
Antes de mais nada, gostaria de deixar claro que entendo o que você chama de dynamic dispatch por outro nome: virtual dispatch.
Você verá algumas referências desta terminologia na comunidade de Java aqui:
http://blog.javia.org/assembly-java/ (artigo meio estranho, mas o conceito é exibido conforme eu o entendo)
http://codefeed.com/blog/?p=77
O google também entende isso:
http://code.google.com/p/google-web-toolkit/wiki/OverlayTypes
E no .Net, temos um excelente artigo na MSDN Magazine americana (maio de 2005):
http://msdn.microsoft.com/en-us/magazine/cc163791.aspx#S13
Esse último artigo explica um pouco do que significa o virtual dispatch e como ele funciona. Serve bem para ilustrar a terminologia. Vou seguir explicando o que entendo por virtual dispatch.
Um exemplo mais simples:
class B
{
public void M() {}
public virtual void N() {}
}
class D : B
{
public override void N() {}
}
A melhor forma de entender o virtual dispatch, é assumindo que cada método possui um "slot" associado a ele. Em tempo de execução, cada slot contém uma referência para algum código que implemente o método. Nesse cenário, as classes B e D têm 2 slots cada uma, de nomes M e N.
Cada instância de B e de D só podem ter uma coisa no slot M: a implementação de M que está em B. Quando alguém faz uma chamada no slot M, o compilador não tem que procurar qual o método referenciado pelo slot. Ele já sabe o que tem nesse slot e gera código para chamá-lo direto. Isso não aparece na IL gerada por um detalhe de implementação, como você havia dito. Conforme passado na referência que você indicou do StackOverflow, o motivo para esse comportamento do compilador é performance (ele evita uma verificação de nulo), e é um detalhe da implementação do compilador.
Já o slot N é diferente. Alguns objetos podem ter B.N no slot N, outros podem ter uma referência para D.N. No entanto, é importante entender que o compilador sabe qual slot chamar, não sabendo apenas qual a implementação será utilizada, ou seja, não sabe o que há no slot, não sabe qual a referência deste slot, não sabe para qual método ele aponta. Por esse motivo, o compilador gera código (IL) para fazer essa verificação (o tal do "callvirt").
Isso é meio que um "late binding", já que o código que vai ser chamado só é determinado em tempo de execução. No entanto, o slot a ser chamado é conhecido, e por isso é chamado de virtual dispatch. Só a referência do método é procurada.
Em uma chamada dinâmica, com o keyword "dynamic", como o exemplo a seguir:
void Foo()
{
dynamic d = new D();
d.M();
}
O compilador sequer sabe qual slot chamar. Isso fica claro naquele trecho grande de IL gerado no meu exemplo da mensagem anterior.
Nesse caso, o slot de chamada só é descoberto em tempo de execução. O compilador nem sabe que o slot M deve ser chamado, porque não sabe o tipo com que está lidando e é impossível gerar um código para o slot de chamada.
Esse é tipo um "late binding anabolizado". E esse sim é o dynamic dispatch que eu estava mencionando desde o começo.
Resumindo: em virtual dispatch você tem o slot determinado, mas o método (código) a ser chamado não. Em dynamic dispatch, você tem ambos indeterminados.
Entendo a confusão. Vi que há pessoas que chamam virtual dispatch de dynamic dispatch, principalmente em literaturas mais clássicas. Vi também pessoas chamando dynamic dispatch de dynamic binding.
Espero que agora tenha ficado claro o que eu estava querendo dizer.
Só para retornar no ponto inicial: agora o C# possui características dinâmicas. Apesar de continuar com tipagem estática, agora possui dynamic dispatch.
André Dias
Eu acho dificil você não encontrar o que precisa, na profundidade que você
busca nos meios oficiais da MS, entre eles, MSDN, Technet, Forums, Blogs,
CodePlex, MS Learning, etc, mas pode acontecer. Nestes caso, há todo um time
composto por funcionários e MVPs como o Giovanni prontos para te ajudar.
Quando você diz: "O MSDN não supre todas as dúvidas ou a documentação em
geral foca no como e não no porque", você acaba limitando a ajuda que
podemos te dar, já que você não foca no problema. Se você nos disser que
tipo de informação você procurou e não encontrou, talvez possamos ajudá-lo
melhor e quem sabe ajudar a melhorar essa imagem "ruim" que você possui em
relação a documentação.
Sobre os Dispatchs, dei uma lida no wikipedia e podemos dizer que:
1) Polimorfismo = Single dispatch
2) Sobrecarga de métodos = multiple dispatch
(ok, só mudaram o nome das coisas pra variar, mas vamos lá)
mas ambos são static dispatch, já que são resolvidos em tempo de compilação.
E se pra ser dinamico precisa ser resolvido em tempo de execução, porque é
errado afirmar que o C# implementa dynamic dispatch através de Reflection ou
a keyword dynamic do c# 4.0?
Aproveitando o e-mail, eu estava lendo as outras mensagens dessa thread e vi
que vcs estavam discutindo linguagens 100% OO e lembrei de uma coisa bizarra
que tinha no Java, não sei se isso ainda persiste. Que eram dois métodos que
não existiam e nenhuma classe. Mas que se você os implementasse a JVM os
chamava ... Se não me engano era algo como readObject() e writeObject() para
customizar serialização, porém não faziam parte de nenhuma classe. Isso
ainda existe?
Porém, tem um ponto que sinto muita falta do Java. São as checked
Exceptions. Pra quem não conhece, toda vez que um código java lança uma
exceção, o código que invoca este método é obrigado a tratá-la ou
explicitamente transferir a responsabilidade para o chamador podendo chegar
até o primeiro método que iniciou a cadeia. Isso é fantástico, pois se há
alguma chance do seu código levantar uma exceção, se ela não for tratada
você receberá um erro de compilação. Infelizmente isso foi sacrificado no c#
pelo design da linguagem. Neste post
http://www.artima.com/intv/handcuffs.html de 2003 (época em que ainda
brincava com Java e tinha o James Gosling com ídolo) o Anders Hejlsberg
explica o motivo.
Vocês acham que checked exception seria util no dia a dia de vcs?
[]s
André Dias
SCJP - SCWCD - MCP - MCTS
http://blogs.msdn.com/andredias
http://twitter.com/andrediasbr
From: "Phillip Calçado" <pcal...@gmail.com>
Sent: Tuesday, June 09, 2009 10:30 AM
To: <dotnetar...@googlegroups.com>
Subject: [dotnetarchitects] Re: Offtopic (?) - Java vs .NET
Giovanni Bassi
Na verdade, eu queria é que eles liberassem o Spec#. Se tivesse checked exceptions melhor ainda.
Phillip Calçado
2009/6/10 André Dias <br.a...@hotmail.com>:
> Quando você diz: "O MSDN não supre todas as dúvidas ou a documentação em
> geral foca no como e não no porque", você acaba limitando a ajuda que
> podemos te dar, já que você não foca no problema. Se você nos disser que
> tipo de informação você procurou e não encontrou, talvez possamos ajudá-lo
> melhor e quem sabe ajudar a melhorar essa imagem "ruim" que você possui em
> relação a documentação.
Ok, da próxima vez que encontrar este problema eu falo contigo.
> Sobre os Dispatchs, dei uma lida no wikipedia e podemos dizer que:
> 1) Polimorfismo = Single dispatch
> 2) Sobrecarga de métodos = multiple dispatch
>
> (ok, só mudaram o nome das coisas pra variar, mas vamos lá)
>
> mas ambos são static dispatch, já que são resolvidos em tempo de compilação.
Er... não. Citando a Wikipedia (que não é a melhor fonte mas é a mais
acessível):
"Dynamic dispatch is needed when multiple classes contain different
implementations of the same method foo(). If the class of an object x
is not known at compile-time, then when x.foo() is called, the program
must decide at runtime which implementation of foo() to invoke, based
on the runtime type of object x. This case is known as single dispatch
because an implementation is chosen based on a single type—that of the
type of the instance. Single dispatch is supported by many
object-oriented languages, including statically typed languages such
as C++ and Java, and dynamically typed languages such as Smalltalk and
Objective-C."
Single dispatch e multiple dispatch são, como o parágrafo acima
afirma, casos de dynamic dispatch.
> E se pra ser dinamico precisa ser resolvido em tempo de execução, porque é
> errado afirmar que o C# implementa dynamic dispatch através de Reflection ou
> a keyword dynamic do c# 4.0?
Não entendi este trecho.
> Aproveitando o e-mail, eu estava lendo as outras mensagens dessa thread e vi
> que vcs estavam discutindo linguagens 100% OO e lembrei de uma coisa bizarra
> que tinha no Java, não sei se isso ainda persiste. Que eram dois métodos que
> não existiam e nenhuma classe. Mas que se você os implementasse a JVM os
> chamava ... Se não me engano era algo como readObject() e writeObject() para
> customizar serialização, porém não faziam parte de nenhuma classe. Isso
> ainda existe?
Acho que por "não fazem parte de nenhuma classe" você quer dizer que
eles não são definidos por uma superclasse já que eles vão sim fazer
parte da classe que implementa Serializable. Eles não estão definidas
na interface porque são uma convenção que você deve seguir. Isto não
tem muita relação com Orientação a Objetos mas sim com a tipagem
estática de Java, que é bem fraca.
> Porém, tem um ponto que sinto muita falta do Java. São as checked
> Exceptions. Pra quem não conhece, toda vez que um código java lança uma
> exceção, o código que invoca este método é obrigado a tratá-la ou
> explicitamente transferir a responsabilidade para o chamador podendo chegar
> até o primeiro método que iniciou a cadeia. Isso é fantástico, pois se há
> alguma chance do seu código levantar uma exceção, se ela não for tratada
> você receberá um erro de compilação. Infelizmente isso foi sacrificado no c#
> pelo design da linguagem. Neste post
> http://www.artima.com/intv/handcuffs.html de 2003 (época em que ainda
> brincava com Java e tinha o James Gosling com ídolo) o Anders Hejlsberg
> explica o motivo.
>
> Vocês acham que checked exception seria util no dia a dia de vcs?
Interessante você falar isso. A maioria dos programadores experientes
em java que eu conheço odeia checked exceptions por serem burocráticas
e não trazerem benefícios.
[]s
André Dias
André Dias
>> E se pra ser dinamico precisa ser resolvido em tempo de execução, porque
>> é
>> errado afirmar que o C# implementa dynamic dispatch através de Reflection
>> ou
>> a keyword dynamic do c# 4.0?
>
> Não entendi este trecho.
Já ficou claro no e-mail do Giovanni, vamos para a próxima.
>
>> Aproveitando o e-mail, eu estava lendo as outras mensagens dessa thread e
>> vi
>> que vcs estavam discutindo linguagens 100% OO e lembrei de uma coisa
>> bizarra
>> que tinha no Java, não sei se isso ainda persiste. Que eram dois métodos
>> que
>> não existiam e nenhuma classe. Mas que se você os implementasse a JVM os
>> chamava ... Se não me engano era algo como readObject() e writeObject()
>> para
>> customizar serialização, porém não faziam parte de nenhuma classe. Isso
>> ainda existe?
>
> Acho que por "não fazem parte de nenhuma classe" você quer dizer que
> eles não são definidos por uma superclasse já que eles vão sim fazer
> parte da classe que implementa Serializable. Eles não estão definidas
> na interface porque são uma convenção que você deve seguir. Isto não
> tem muita relação com Orientação a Objetos mas sim com a tipagem
> estática de Java, que é bem fraca.
Ok, mas não é estranho todos os métodos do Java pertencerem a alguma classe
e apenas esses 2, não? Isso me cheira "gambiarra". No .net, além do atributo
[Serializable] que correponde Serializable do java, temos outros atributos
como [OnSerializing], [OnSerialized], [OnDeserializing], [OnDeserialized]
para serem utilizados em métodos que farão esse trabalho.
Pode parecer besteira, mas acho a implementação do .net muito mais clara
neste ponto!
>> Porém, tem um ponto que sinto muita falta do Java. São as checked
>> Exceptions. Pra quem não conhece, toda vez que um código java lança uma
>> exceção, o código que invoca este método é obrigado a tratá-la ou
>> explicitamente transferir a responsabilidade para o chamador podendo
>> chegar
>> até o primeiro método que iniciou a cadeia. Isso é fantástico, pois se há
>> alguma chance do seu código levantar uma exceção, se ela não for tratada
>> você receberá um erro de compilação. Infelizmente isso foi sacrificado no
>> c#
>> pelo design da linguagem. Neste post
>> http://www.artima.com/intv/handcuffs.html de 2003 (época em que ainda
>> brincava com Java e tinha o James Gosling com ídolo) o Anders Hejlsberg
>> explica o motivo.
>>
>> Vocês acham que checked exception seria util no dia a dia de vcs?
>
> Interessante você falar isso. A maioria dos programadores experientes
> em java que eu conheço odeia checked exceptions por serem burocráticas
> e não trazerem benefícios.
>
Eu também odiava quando programava em Java, depois com o Eclipse passei a
odiar menos já que o Eclipse colocava os blocos try/catch automáticos, e
depois que fui pro .NET fez uma falta. Sabe aquela coisa que só damos valor
quando perdemos? Talvez se aplique aqui :-)
Phillip Calçado
2009/6/10 Giovanni Bassi <gig...@giggio.net>:
> Antes de mais nada, gostaria de deixar claro que entendo o que você chama de
> dynamic dispatch por outro nome: virtual dispatch.
Ok, entendi agora. Bom, Virtual Dispatch é apenas Dynamic Dispatch
usando uma v-table :)
http://en.wikipedia.org/wiki/Virtual_table
http://en.wikipedia.org/wiki/Virtual_function#Purpose
Um paper bem interessante (sobre C++ mas o conceito é o mesmo):
http://www.cs.ucsb.edu/~urs/oocsb/papers/oopsla96.pdf
Citação:
"Dynamic dispatch, i.e., the run-time selection of a target procedure
given a message name and the receiver type, is a central feature of
object-oriented languages. Compared to a subroutine call in a
procedural language, a message dispatch incurs two kinds of overhead:
adirect cost and anindirect cost. Thus the presence of dynamic
dispatch hinders optimization, and
consequently, the resulting program will run more slowly. [...]
2.1 Virtual function tables
C++ implements dynamic dispatch using virtual function tables (VFTs).
VFTs were first used by Simula [DM73] and today are the preferred C++
dispatch mechanism [ES90]. The basic idea of VFTs is to determine the
function address by indexing into a table of function pointers (the
VFT). Each class has its own VFT, and each instance contains a pointer
to the appropriateVFT."
Mas acho que no final concordamos que C# possui Virtual Dispatch, eu
só deixo claro que Virtual Dispatch é apenas uma implementação de
Dynamic Dispatch usando uma V-Table.
> A melhor forma de entender o virtual dispatch, é assumindo que cada método
> possui um "slot" associado a ele.
Isto é uma v-table ;)
> No entanto, é importante entender que o
> compilador sabe qual slot chamar, não sabendo apenas qual a implementação
> será utilizada, ou seja, não sabe o que há no slot, não sabe qual a
> referência deste slot, não sabe para qual método ele aponta. Por esse
> motivo, o compilador gera código (IL) para fazer essa verificação (o tal do
> "callvirt").
E isto é *exatamente* dynamic binding ;) Da wikipedia novamente:
"C++ uses a virtual table which defines the message to method mapping
for a given class. Instances of that type will then store a pointer to
this table as part of their instance data. This is complicated when
multiple inheritance is used. The virtual table in a C++ object cannot
be modified at run-time which limits the potential set of dispatch
targets to a finite set chosen at compile-time."
> Em uma chamada dinâmica, com o keyword "dynamic", como o exemplo a seguir:
> void Foo()
> {
> dynamic d = new D();
> d.M();
> }
> O compilador sequer sabe qual slot chamar. Isso fica claro naquele trecho
> grande de IL gerado no meu exemplo da mensagem anterior.
> Nesse caso, o slot de chamada só é descoberto em tempo de execução. O
> compilador nem sabe que o slot M deve ser chamado, porque não sabe o tipo
> com que está lidando e é impossível gerar um código para o slot de chamada.
Ele não sabe qual slot chamar porque não sabe qual o tipo do seu
objeto. A v-table é específica para um tipo (conf. documentação sobre
newslot no "Common Language Infrastructure" do ECMA) logo o runtime
vai ter que descobrir o tipo do objeto para poder chamar o método
correspondente -por isso a chamada a GetTypeFromHandle no seu exemplo
anterior.
Isto é exatamente o comportamento esperado em *tipagem* dinâmica, não
necessariamente dynamic dispatch -você pode uma linguagem que seja
estaticamente tipada mas com static binding apesar deste não ser o
caso de C#.
> E esse sim é o dynamic dispatch
> que eu estava mencionando desde o começo.
Bom, agora chegamos a um círculo interessante. Lá no início eu falei
que você estava misturando tipagem dinâmica com outros conceitos, você
falou que linguagens dinâmicas possuiam mais que tipagem dinâmica. No
fim das contas o que você me mostrou aqui é apenas tipagem dinâmica :)
Eu sei que havia dito que ia parar com a discussão mas acho que
estamos voltando ao rumo.
Phillip Calçado
2009/6/10 André Dias <br.a...@hotmail.com>:
> Já ficou claro no e-mail do Giovanni, vamos para a próxima.
Na verdade não ficou não.
>> Acho que por "não fazem parte de nenhuma classe" você quer dizer que
>> eles não são definidos por uma superclasse já que eles vão sim fazer
>> parte da classe que implementa Serializable. Eles não estão definidas
>> na interface porque são uma convenção que você deve seguir. Isto não
>> tem muita relação com Orientação a Objetos mas sim com a tipagem
>> estática de Java, que é bem fraca.
>
> Ok, mas não é estranho todos os métodos do Java pertencerem a alguma classe
> e apenas esses 2, não? Isso me cheira "gambiarra". No .net, além do atributo
> [Serializable] que correponde Serializable do java, temos outros atributos
> como [OnSerializing], [OnSerialized], [OnDeserializing], [OnDeserialized]
> para serem utilizados em métodos que farão esse trabalho.
Er... como falei antes isso de "não pertencer a uma classe" não
procede já que eles vão pertencer à classe que os implementar. Como
também falei antes isso é uma convenção do framework de serialização.
E como também falei antes isso representa uma /bad smell/ no sistema
de tipos, não necessariamente em orientação a objetos.
> Pode parecer besteira, mas acho a implementação do .net muito mais clara
> neste ponto!
Ok.
André Dias
> 2009/6/10 André Dias <br.a...@hotmail.com>:
>> Já ficou claro no e-mail do Giovanni, vamos para a próxima.
>
> Na verdade não ficou não.
Pra mim ficou, para falar a verdade eu nem lembro mais porque estamos
discutindo isso :-)
>>
>> Ok, mas não é estranho todos os métodos do Java pertencerem a alguma
>> classe
>> e apenas esses 2, não? Isso me cheira "gambiarra". No .net, além do
>> atributo
>> [Serializable] que correponde Serializable do java, temos outros
>> atributos
>> como [OnSerializing], [OnSerialized], [OnDeserializing], [OnDeserialized]
>> para serem utilizados em métodos que farão esse trabalho.
>
> Er... como falei antes isso de "não pertencer a uma classe" não
> procede já que eles vão pertencer à classe que os implementar. Como
> também falei antes isso é uma convenção do framework de serialização.
> E como também falei antes isso representa uma /bad smell/ no sistema
> de tipos, não necessariamente em orientação a objetos.
>
Errrr.... Se eu quero customizar o equals eu sobrescrevo o método, se quero
customizar o toString eu tenho que sobrescrever o método, Com esses dois não
tem que ser diferente. Neste ponto você pode chamar do conceito que quiser,
classificá-lo da forma que quiser, mas pra mim (Como eu falei antes),
continua sendo uma bela gambiarra.
Phillip Calçado
2009/6/10 André Dias <br.a...@hotmail.com>:
> Errrr.... Se eu quero customizar o equals eu sobrescrevo o método, se quero
> customizar o toString eu tenho que sobrescrever o método, Com esses dois não
> tem que ser diferente. Neste ponto você pode chamar do conceito que quiser,
> classificá-lo da forma que quiser, mas pra mim (Como eu falei antes),
> continua sendo uma bela gambiarra.
Não exatamente. Diversos recursos em Java são baseados em convenções.
É a mesma coisa sobre chamar os controladores do ASP.Net MVC de
"XyzController".
Aliás, se o uso de convenções para você é gambiarra eu fico realmente
curioso sobre a sua opinião sobre Rails... :)
André Dias
>> quero
>> customizar o toString eu tenho que sobrescrever o método, Com esses dois
>> não
>> tem que ser diferente. Neste ponto você pode chamar do conceito que
>> quiser,
>> classificá-lo da forma que quiser, mas pra mim (Como eu falei antes),
>> continua sendo uma bela gambiarra.
>
> Não exatamente. Diversos recursos em Java são baseados em convenções.
> É a mesma coisa sobre chamar os controladores do ASP.Net MVC de
> "XyzController".
>
> Aliás, se o uso de convenções para você é gambiarra eu fico realmente
> curioso sobre a sua opinião sobre Rails... :)
>
Sendo prático! Toda mulher tem dois seios. Se aparecer uma com apenas um
seio você também vai chamar de convenção? Eu não vou falar que a mulher é
uma gambiarra ou que está com defeito pq é muita sacanagem, mas posso
afirmar que não é normal. Assim como não é normal todos os métodos - 2 do
java pertencerem a alguma classe e essas duas criaturas não! Por que eles
são mais bonitos que os outros?
Sobre o Rails, o único contato que tive foi numa palestra do Akita. Eu achei
interessante, uma forma bem diferente da que desenvolvo hoje e apesar de
estar no meu radar, não é prioridade para esse ano.
Hummm .. Rails, convenção, mulheres com apenas 1 seio .... É ..acho que tá
na hora de ir dormir ... Boa noite!
Phillip Calçado
2009/6/10 André Dias <br.a...@hotmail.com>:
> Sendo prático! Toda mulher tem dois seios. Se aparecer uma com apenas um
> seio você também vai chamar de convenção? Eu não vou falar que a mulher é
> uma gambiarra ou que está com defeito pq é muita sacanagem, mas posso
> afirmar que não é normal. Assim como não é normal todos os métodos - 2 do
> java pertencerem a alguma classe e essas duas criaturas não! Por que eles
> são mais bonitos que os outros?
Bom, eu já falei algumas dezenas de vezes que o método pertence a uma
classe e que é apenas uma convenção mas me parece que você está muito
mais interessado em atacar Java do que participar de um debate sadio
-do contrário não usaria comparações ridículas e de mau gosto ou
ficaria repetindo o mesmo argumento que já foi combatido.
Boa sorte com seus seios, com você eu parei por aqui. Não alimento trolls.
Giovanni Bassi
Rodrigo Vieira
2009/6/10 Giovanni Bassi <gig...@giggio.net>:
André Dias
Nem sempre a sua opinião convencerá todas as pessoas. Meu argumento foi
combatido, porém eu não concordo com a sua opinião. Quando você diz que é
por convenção, eu interpreto como "É assim porque é assim e pronto.".
Esses métodos estão completamente fora do padrão e eu esperava uma resposta
mais relevante do que "É assim porque é assim". Talvez uma explicação porque
isso está diferente dos outros, porque não criaram uma interface
java.io.Serializable2 com esses métodos, etc. Você que é um cara que defende
tanto o "Porque" das coisas, não acha estranho aceitar uma resposta tão
simples e vaga como essa?
Sobre a brincadeira, eu fui para esse tom justamente para encerrar o assunto
porque eu vi que não íamos concordar nesse ponto, mas se ofendi você ou
algum outro membro da lista, peço minhas sinceras desculpas!
Alias, não estou atacando o java não. Como já disse, trabalhei um bom tempo
com ele e só mudei porque encontrei uma plataforma melhor (IMHO). E esse
ponto que citei é tão pequeno perto do java que nem vale a pena a discussão.
Só foi citado porque acho uma coisa bizarra ou como eu disse em e-mails
anteriores, uma bela gambiarra (IMHO tb).
Abraços
--
André Dias
SCJP - SCWCD - MCP - MCTS
http://blogs.msdn.com/andredias
http://twitter.com/andrediasbr
>
Phillip Calçado
Desculpas aceitas.
Só uma dica: se você lança um argumento e alguem o refuta com algo que
você não concorda você provavelmente deveria responder com o porque
não concorda. Repetir o argumento inicial três vezes não ajuda em nada
no andamento do debate.
Eu não estou tentando te convencer, acredite. Estou apenas
argumentando na esperança de aprender algo com o que você sabe. Se
você ou qualquer outra pessoa vai sair convencida ou não é outro
problema.
Dada a sua boa vontade no email anterior eu vou tentar explicar
utilizando outras palavras -note que o conteúdo é o mesmo.
Serialização padrão em Java é feita por um framework baseado em
convenções. Uma das maneiras de serializar e deserializar um objeto é
provendo um par de métodos privados, um para ler e outro para escrever
o objeto. Estes métodos são chamados pela JVM num processo
transparente e só são necessários caso o desenvolvedor deseje
personalizar a serialização da classe ao invés de utilizar o mecanismo
normal.
A sua crítica, pelo que entendi, é que estes métodos não fazem parte
de uma superclasse ou interface. Eu *imagino* que neste caso isso é
feito por que este método não deveria ser público como uma interface
exigiria e ao mesmo tempo não se deseja poluir uma hierarquia de
classes que, dada a herança simples de Java, não tem muitos recursos.
Imagine, por exemplo, que você crie uma classe chamada Usuario que
estende uma classe chamada Pessoa. Se você quer transformar Usuario em
serializável então teria que fazer Pessoa (ou pior: sua superclasse!)
implementar a classe que contiver os métodos de leitura e escrita do
objeto. Isso não é lá muito desejável, especialmente porque a classe
Pessoa pode ser originária de uma biblioteca que você não pode
alterar.
A solução que se encontrou em 1997 foi criar a convenção de que se uma
classe implementar Serializable e possuir tais métodos ela pode
personalizar a forma com que seus dados são serializados. Note que
isso foi muito antes de metadados aparecerem em Java.
É uma convenção. Convenções são ruins? Não necessariamente. O JUnit
era baseado em convenções até a versão 4 (métodos tem que começar com
'test', serem públicos e terem retorno void, não são herdados de
nenhum lugar). O Struts sempre foi criticado por utilizar um modelo
baseado em herança para seus controladores e por isso o WebWork/Struts
2 utiliza convenções -muito parecidas, aliás, com as convenções que
foram para no ASP.Net MVC. Rails é todo baseado em convenções.
Convenções evitam inchar a linguagem com keyworks e sintaxes muito
específicas e evitam a necessidade de configurar as coisas.
Mas isto não fere o sistema de tipos? Não, mas o deixa bem mais pobre.
Uma linguagem estaticamente tipada que se preze vai tirar o máximo
proveito do sistema de tipos, se alguém usa este tipo de convenção ele
não faz checagem estática de tipos logo perde a única vantagem do
modelo. Isto é bem comum em Java que possui um sistema de tipos já bem
pobre (C# 3 é levemente superior, especificamente por ter inferência
de tipos).
Bom, a explicação é essa. Se você ainda acha horrível não vai estar
sozinho mas a última vez que eu precisei utilizar a serialização
padrão em Java foi em 2004.
[]s
2009/6/10 André Dias <br.a...@hotmail.com>:
Mauricio Aniche
Só para complementar, além de tipagem dinâmica, o C# apresenta outras características de linguagens dinâmicas. Você tem closures (se não me engano desde a versão 2.0, com delegates anônimos) e até higher-order functions (com o uso de predicates), por exemplo.
O que acho que talvez possa dificultar é a sintaxe do C# para todas essas coisas. Uma closure em Ruby, por exemplo, é muito mais "simples" (não conheço muito de Ruby, tudo que sei foi participando de dojos, então o código abaixo pode estar errado, mas a idéia é essa):
--
def pessoasRicas(pessoas)
saldoDosRicos = 50000
return pessoas.select { |p| p.dinheiroNaConta > saldoDosRicos }
end
public List<Pessoa> PessoasRicas(List<Pessoa> pessoas) {
int saldoDosRicos = 50000;
return pessoas.FindAll(delegate(Pessoa p) {
return p.DinheiroNaConta > saldoDosRicos;
}
}
--
Pode-se ver no trecho acima que a implementação em Ruby é mais simples, a declaração da função começa logo no "{". Além disso, o duck typing, e a não-necessidade da palavra return ajudam a simplificar ainda mais o código. Já o código em C# exige muito mais código. Mas ambos apresentam o mesmo comportamento.
Abraços,
Mauricio Aniche
Phillip Calçado
2009/6/11 Mauricio Aniche <maurici...@gmail.com>:
> Só para complementar, além de tipagem dinâmica, o C# apresenta outras
> características de linguagens dinâmicas. Você tem closures (se não me engano
> desde a versão 2.0, com delegates anônimos) e até higher-order functions
> (com o uso de predicates), por exemplo.
São funcionalidades bem impressionantes sim mas não estão relacionadas
com linguagens dinâmicas. Closures e higher-order functions são
funcionalidades ortogonais, encontradas em linguagems dinâmicas
(Ruby/Python/Lisp), estáticas(Haskell, F#, Ocaml) e mesmo de tipagem
fraca (Perl).
(note que ainda estou assumindo que "linguagem dinâmica" se refere à
tipagem dinâmica já que outras características citadas são ortogonais)
Mauricio Aniche
Essa é uma questão interessante (que acho que você mesmo levantou em algum dos e-mails anteriores). Como "classificar" uma linguagem como dinâmica? Será que pra classificar uma linguagem como dinâmica basta apenas ter tipagem dinâmica?
É como você disse, essas funcionalidades ortogonais podem ser encontradas/simuladas em linguagens não-dinâmicas. Higher-order functions, por exemplo, podem ser simuladas em C, trabalhando com o ponteiro da função.
Mas será que podemos dizer que uma linguagem é dinâmica, quando ela nos ajuda a fazer tudo isso, oferencendo maneiras fáceis e diretas para essas funcionalidades? No exemplo de código do meu e-mail anterior, por exemplo, Ruby me ajudou a escrever closures de forma simples. C# também, mas com um pouco mais de trabalho. Será que o "nível de facilidade" na implementação desses recursos possa servir para classificar a linguagem como dinâmica?
Vou pesquisar mais sobre isso.
Abraços,
Mauricio Aniche
www.aniche.com.br
Marcos Dell Antonio
Stop That Serialization!
OK, we have seen quite a bit about the serialization process, now let's see some
more. What if you create a class whose superclass is serializable but you do not
want that new class to be serializable? You cannot unimplement an interface, so if
your superclass does implement Serializable, your new class implements
it, too (assuming both rules listed above are met). To stop the automatic
serialization, you can once again use the private methods to just throw the
NotSerializableException. Here is how that would be done:
10 private void writeObject(ObjectOutputStream out) throws IOException
20 {
30 throw new NotSerializableException("Not today!");
40 }
50 private void readObject(ObjectInputStream in) throws IOException
60 {
70 throw new NotSerializableException("Not today!");
80 }
Fonte: http://java.sun.com/developer/technicalArticles/Programming/serialization/--
Marcos Dell' Antonio
http://www.marcosdellantonio.net
Rogério Moraes de Carvalho
Eu observei que o conceito de linguagem dinâmica está gerando muitas
discordâncias e não pretendo postar sobre este assunto agora.
Eu somente estarei comentando sobre a simplificação que é possível
fazer no seu exemplo com o uso de "expressões lambda", que foram
introduzidas na versão 3.0 da linguagem C#. Neste caso, a expressão em
C# fica tão simples quanto a expressão que você apresentou em Ruby.
Segue o seu exemplo convertido para usar o recurso de "expressões
lambda" do C# 3.0.
public List<Pessoa> PessoasRicas(List<Pessoa> pessoas) {
int saldoDosRicos = 50000;
}
O novo operador "=>" é denominado "operador lambda". Esta
simplificação é essencial no uso de Standard Query Operators do LINQ
(Language INtegrated Query).
Apenas por uma questão de curiosidade, veja a evolução que houve no
uso de delegates durante os lançamentos das versões 1.0, 2.0 e 3.0 da
linguagem C#.
Na linguagem C# 1.0, você era obrigado a criar um método separadamente
e referenciá-lo ao instanciar o delegate, como mostrado no código
abaixo.
public List<Pessoa> PessoasRicas(List<Pessoa> pessoas) {
}
private static bool filtrarRicos(Pessoa p) {
int saldoDosRicos = 50000;
return p.DinheiroNaConta > saldoDosRicos;
}
Na linguagem C# 2.0, houve a introdução de um novo recurso denominado
“métodos anônimos”, simplificando o uso de delegates, como mostrado no
código abaixo.
public List<Pessoa> PessoasRicas(List<Pessoa> pessoas) {
int saldoDosRicos = 50000;
return pessoas.FindAll(delegate(Pessoa p) {
return p.DinheiroNaConta > saldoDosRicos;
}
Este foi o código que você apresentou no seu exemplo. Porém, observe
que você esqueceu de fechar os parênteses na lista de parâmetros do
método “FindAll”, além de ter esquecido de finalizar a instrução da
chamada deste método com ponto e vírgula.
Na linguagem C# 3.0, houve a introdução do recurso de “expressões
lambda” simplificando ainda mais o uso de delegates, como mostrado no
código que coloquei no início do post e copiado novamente abaixo.
public List<Pessoa> PessoasRicas(List<Pessoa> pessoas) {
return pessoas.FindAll(p => p.DinheiroNaConta > saldoDosRicos);
}
Como a idéia era somente mostrar que dava para simplificar a expressão
na versão 3.0 da linguagem C#, eu não estarei comentando sobre o
restante do código de exemplo.
Abraços,
Rogério Moraes de Carvalho
Rogério Moraes de Carvalho
> O que acho que talvez possa dificultar é a sintaxe do C# para todas essas
> coisas. Uma closure em Ruby, por exemplo, é muito mais "simples" (não
> conheço muito de Ruby, tudo que sei foi participando de dojos, então o
> código abaixo pode estar errado, mas a idéia é essa):
>
> --
> def pessoasRicas(pessoas)
> saldoDosRicos = 50000
> return pessoas.select { |p| p.dinheiroNaConta > saldoDosRicos }
> end
>
> public List<Pessoa> PessoasRicas(List<Pessoa> pessoas) {
> int saldoDosRicos = 50000;
> return pessoas.FindAll(delegate(Pessoa p) {
> return p.DinheiroNaConta > saldoDosRicos;
> }}
>
> --
>
> Pode-se ver no trecho acima que a implementação em Ruby é mais simples, a
> não-necessidade da palavra *return* ajudam a simplificar ainda mais o
> mesmo comportamento.
Eu observei que o conceito de linguagem dinâmica está gerando muitas
discordâncias e não pretendo postar sobre este assunto agora.
Eu somente estarei comentando sobre a simplificação que é possível
fazer no seu exemplo com o uso de "expressões lambda", que foram
introduzidas na versão 3.0 da linguagem C#. Neste caso, a expressão em
C# fica tão simples quanto a expressão que você apresentou em Ruby.
Segue o seu exemplo convertido para usar o recurso de "expressões
public List<Pessoa> PessoasRicas(List<Pessoa> pessoas) {
return pessoas.FindAll(p => p.DinheiroNaConta > saldoDosRicos);
}
uso de delegates durante os lançamentos das versões 1.0, 2.0 e 3.0 da
linguagem C#.
Na linguagem C# 1.0, você era obrigado a criar um método separadamente
e referenciá-lo ao instanciar o delegate, como mostrado no código
abaixo.
}
private static bool filtrarRicos(Pessoa p) {
return p.DinheiroNaConta > saldoDosRicos;
}
Na linguagem C# 2.0, houve a introdução do recurso de “métodos
anônimos” simplificando o uso de delegates, como mostrado no código
abaixo.
public List<Pessoa> PessoasRicas(List<Pessoa> pessoas) {
int saldoDosRicos = 50000;
return pessoas.FindAll(delegate(Pessoa p) {
return p.DinheiroNaConta > saldoDosRicos;
}
Este foi o código que você apresentou no seu exemplo. Porém, observe
que você esqueceu de fechar os parênteses na lista de parâmetros do
método “FindAll”, além de ter esquecido de finalizar a instrução da
Na linguagem C# 3.0, houve a introdução de um novo recurso denominado
“expressões lambda”, simplificando ainda mais o uso de delegates, como
mostrado no código do início do post e copiado novamente abaixo.
public List<Pessoa> PessoasRicas(List<Pessoa> pessoas) {
Rogério Moraes de Carvalho
apresentado. Eu pensei que não tinha sido enviado.
Giovanni Bassi
Mauricio Aniche
Obrigado por lembrar! Não havia pensado nos lambdas quando escrevi o e-mail, até por falta de prática minha (ainda não tive muitas oportunidades de utilizá-lo). Mas realmente, o código ficou bem parecido com o de Ruby.
O meu código devia ter erro mesmo, escrevi direto aqui no e-mail, a idéia era só exemplificar.
Mudo aqui então minha opinião sobre meu comentário "... C# com um pouco mais de trabalho". Nesse caso, ambos são bem parecidos.
Abraços,
Mauricio Aniche