O mito da superior produtividade do .net em relação ao Java é real?

Assuntos Gerais
#1

Oi gente, tudo bem?

Recentemente participei de uma discussão na qual veio de novo a história de que “.net é mais produtivo que Java”. Aqui segue minha opinião sobre o assunto e gostaria de ouvir a de vocês.

  1. O papo de que .net já vêm “tudo integrado” e que o desenvolvedor não precisa ficar se preocupando com isto.

Pra mim isto é balela, porque não leva em consideração alguns fatos da Javolândia

  • Maven: há diversos arquétipos prontos para diversos frameworks e você não precisa ficar se preocupando com esta integração quando os usa
  • Frameworks full stack como Grails ou Play
  • O fato de que problemas de integração se ocorrerem, só ocorrem no início do projeto e, mesmo assim, se ocorrerem no meio, na sua maior parte são culpa do arquiteto mais que da plataforma.

E ignora outro fato: de que a plataforma .net, assim como a Java, com sua arquitetura padrão não se aplica a todas as situações do Universo.

  1. O papo de que a linguagem C# é mais produtiva

De novo, o problema fica mais entre o teclado e a cadeira. Problemas são difíceis de serem resolvidos em qualquer linguagem. O máximo que pode ocorrer é ter uma facilidade a mais ou outra devido a alguma integração mais fácil com banco de dados ou coisa similar. E com relação aos novos recursos, bem: pelo que pude ver até agora, a única falta no Java seriam os delegates, não?

  1. O fato da equipe se adaptar melhor a novos projetos

De novo, é acreditar que todos os projetos são iguais. Neste ponto, eu me pergunto se as mesmas dificuldades na adoção de um novo framework ou biblioteca do lado Java não se refletiria do lado .net.
É o mesmo problema, tudo de novo.

Não quero criar uma rinha de briga aqui, mas gostaria muito de ouvir a opinião de vocês, pois estou pensando sériamente em levar esta pesquisa mais a fundo (o que vai gerar um artiguinho monstro em breve, aguardem :slight_smile: )

#2

Nota: eu também não acredito no contrário, isto é, que Java seja mais produtivo que .net.
Por que os problemas são difíceis independente da linguagem/plataforma em que a gente tenta resolvê-los.

E porque este papo no final das contas só serve pra desviar a atenção dos problemas reais: falta de comunicação dentro da equipe e com o cliente, requisitos mal coletados, testes mal executados, gerência esquisita, etc.

Vale à pena reler o “No Silver Bullet” do Fred Brooks que ainda vale hoje. Não há bala de prata ou ferramenta que aumente exponencialmente a produtividade do desenvolvedor.

#3

Eu não faço ideia Kico, pois não conheço nada de .NET pra poder chegar a essa conclusão da pergunta direta do tópico.

Porém no quesito Tecnologia A Mais produtiva que B eu acho que consigo opinar.

Sou programador PHP, Java e agora engatinhando no Rails (tanto Ruby quanto Groovy).

O que posso dizer é que há coisas que são muito mais produtiva em umas e menos em outras, porém como vejo, tudo na vida tem um preço a ser pago. Toda a facilidade, toda a performance e toda a elegância que qualquer ferramenta dessa pode lhe dar, ela vai lhe cobrar um preço.

Aprendi isso de um jeito muito legal. Tenho um amigo, que estava por desenvolver um projeto e na época estava escolhendo a suíte Java com o qual ia trabalhar. Lembro que na época eu estava a toda estudando GRails e mostrei a ele um exemplo que desenvolvi, ele achou muito bacana, elogiou e tals, disse que era fácil elegante e coisa e tal e blá blá blá… 2 semanas depois ele concluiu o projeto (relativamente grande) usando GWT + Spring + JPA… E eu: “Ué, porque não usou o GRails pow ???”

E aí a resposta que eu nunca esqueci:

“Cara, eu trabalho há 7 anos com Java e sou MUITO produtivo com ela. Cabia muito bem dentro da solução que eu estava procurando e eu precisava resolver meu problema logo.”

Ele está estudando e se dedicando ao GRails (pois realmente gostou) mas me falou que só se sentirá seguro quando dominar mais 70% do Framework realmente bem, antes de colocar seus projetos críticos nele.

Naquele dia eu coloquei a mão na consciência e deixei de ser menos Xiita (pois pensei que eu não era mais) em relação a Tecnologia.

O resumo é, se .NET é mais produtivo que Java eu não sei, só sei que PRA MIM, HOJE, Java é o que há de mais produtivo no mundo. Pode ser que isso mude em breve, pois estou absorvendo bem o Rails (R e G), mas hoje, realmente Java é o que há.

Abs []

1 curtida
#4

[quote=adriano_si]Eu não faço ideia Kico, pois não conheço nada de .NET pra poder chegar a essa conclusão da pergunta direta do tópico.

Porém no quesito Tecnologia A Mais produtiva que B eu acho que consigo opinar.

Sou programador PHP, Java e agora engatinhando no Rails (tanto Ruby quanto Groovy).

O que posso dizer é que há coisas que são muito mais produtiva em umas e menos em outras, porém como vejo, tudo na vida tem um preço a ser pago. Toda a facilidade, toda a performance e toda a elegância que qualquer ferramenta dessa pode lhe dar, ela vai lhe cobrar um preço.

Aprendi isso de um jeito muito legal. Tenho um amigo, que estava por desenvolver um projeto e na época estava escolhendo a suíte Java com o qual ia trabalhar. Lembro que na época eu estava a toda estudando GRails e mostrei a ele um exemplo que desenvolvi, ele achou muito bacana, elogiou e tals, disse que era fácil elegante e coisa e tal e blá blá blá… 2 semanas depois ele concluiu o projeto (relativamente grande) usando GWT + Spring + JPA… E eu: “Ué, porque não usou o GRails pow ???”

E aí a resposta que eu nunca esqueci:

“Cara, eu trabalho há 7 anos com Java e sou MUITO produtivo com ela. Cabia muito bem dentro da solução que eu estava procurando e eu precisava resolver meu problema logo.”

Ele está estudando e se dedicando ao GRails (pois realmente gostou) mas me falou que só se sentirá seguro quando dominar mais 70% do Framework realmente bem, antes de colocar seus projetos críticos nele.

Naquele dia eu coloquei a mão na consciência e deixei de ser menos Xiita (pois pensei que eu não era mais) em relação a Tecnologia.

O resumo é, se .NET é mais produtivo que Java eu não sei, só sei que PRA MIM, HOJE, Java é o que há de mais produtivo no mundo. Pode ser que isso mude em breve, pois estou absorvendo bem o Rails (R e G), mas hoje, realmente Java é o que há.

Abs [][/quote]

Muito boas as suas colocações Adriano. Realmente, tá ai um ponto interessante pra nossa discussão: a produtividade individual. De fato, você é muito mais produtivo com aquilo que conhece bem.
E você sabe bem do que eu estou falando, pelo fato de programar também em PHP que, na minha opinião, foi um dos ambientes mais produtivos que já encontrei mas que, devido à minha própria ignorância, pra mim não foi nada produtivo pela minha falta de conhecimento. Bem lembrado levar em consideração o lado subjetivo!

Aonde eu vejo muito disto é naquelas listagens de número de horas por ponto de função, em que o .net sempre aparece com um número menor de horas. O que vejo é o seguinte: se existisse uma linguagem/plataforma que aumentasse significativamente a produtividade, esta já existiria, pois temos mais de 50 anos de pesquisa feita por peixe grande na área neste assunto. E se existisse, óbviamente seria A plataforma, e todas as demais seriam nichos, concorda?

Do ponto de vista de uma consultoria, este tipo de discussão é importantíssimo, porque tudo o que conta um minuto a mais de produtividade gera uma lucratividade maior. Talvez seja este desespero para “lucrar nos minutos” que alimente este tipo de mito.
Agora, e do ponto de vista coletivo?

#5

[quote=kicolobo]Nota: eu também não acredito no contrário, isto é, que Java seja mais produtivo que .net.
Por que os problemas são difíceis independente da linguagem/plataforma em que a gente tenta resolvê-los.

E porque este papo no final das contas só serve pra desviar a atenção dos problemas reais: falta de comunicação dentro da equipe e com o cliente, requisitos mal coletados, testes mal executados, gerência esquisita, etc.

Vale à pena reler o “No Silver Bullet” do Fred Brooks que ainda vale hoje. Não há bala de prata ou ferramenta que aumente exponencialmente a produtividade do desenvolvedor.[/quote]

eu diria ser cultural, explico:

facilmente se encontra projetos em java que utilizaram Spring e o mesmo depende de alguns conhecimento como: Interfaces, Reflection, Injeção de dependencias, genérics, MVC. muitos desses projetos também usam JPA.

.NET, a cultura é práticidade: veio o framework asp.net na época do VB, a facilidade do 2 cliques no botão…etc… (muito parecido com delphi). 0 uso de javascript, Querys em SQL, e programação em camadas (muitas empresas ainda usam esse esquema).

bom. ai veio o VS2010 com o MVC 3, que no exterior bomba demais, no brasil só em empresas com cultura de Padrões de Projeto, ainda não chega a ser tão disseminado,

ou seja…problema cultural:

JAVA: foco em padrões, codigo estruturado, arquitetura bem feita, maior controle do código gerado. (a maioria dos projetos)
C#: foco em Práticidade. (a maioria dos projetos).

pra você ter uma idéia, muitas vagas de .NET ainda hoje pedem: VB.NET, VB 6, ASP Classico, Delphi 7. (isso é ultrapassado!!!)

#6

[quote=douglaskd][quote=kicolobo]Nota: eu também não acredito no contrário, isto é, que Java seja mais produtivo que .net.
Por que os problemas são difíceis independente da linguagem/plataforma em que a gente tenta resolvê-los.

E porque este papo no final das contas só serve pra desviar a atenção dos problemas reais: falta de comunicação dentro da equipe e com o cliente, requisitos mal coletados, testes mal executados, gerência esquisita, etc.

Vale à pena reler o “No Silver Bullet” do Fred Brooks que ainda vale hoje. Não há bala de prata ou ferramenta que aumente exponencialmente a produtividade do desenvolvedor.[/quote]

eu diria ser cultural, explico:

facilmente se encontra projetos em java que utilizaram Spring e o mesmo depende de alguns conhecimento como: Interfaces, Reflection, Injeção de dependencias, genérics, MVC. muitos desses projetos também usam JPA.

.NET, a cultura é práticidade: veio o framework asp.net na época do VB, a facilidade do 2 cliques no botão…etc… (muito parecido com delphi). 0 uso de javascript, Querys em SQL, e programação em camadas (muitas empresas ainda usam esse esquema).

bom. ai veio o VS2010 com o MVC 3, que no exterior bomba demais, no brasil só em empresas com cultura de Padrões de Projeto, ainda não chega a ser tão disseminado,

ou seja…problema cultural:

JAVA: foco em padrões, codigo estruturado, arquitetura bem feita, maior controle do código gerado. (a maioria dos projetos)
C#: foco em Práticidade. (a maioria dos projetos).

pra você ter uma idéia, muitas vagas de .NET ainda hoje pedem: VB.NET, VB 6, ASP Classico, Delphi 7. (isso é ultrapassado!!!)[/quote]

Oi Douglas, muito boas as suas colocações também. Neste caso, você acredita que o fato de existirem mais ferramentas visuais para o desenvolvimento de interfaces gráficas contribuiria para isto?
Por que do ponto de vista prático, relativo a implementação de regras de negócio e tal, Spring, interfaces, JPA, etc são ferramentas que, quando bem conhecidas, aumentam significativamente a produtividade do desenvolvedor.

Na sua opinião, eu poderia dizer que a produtividade no desenvolvimento de interfaces gráficas com .net oculta um certo incentivo na escrita de arquiteturas ruins?

#7

Eu penso que o que o douglaskd colocou é perfeitamente cabível no que o adriano_si postou.
A curva de aprendizado do java passar por interfaces, reflection e tudo mais. Já .NET também possui tais recursos, além de alguns outros coringas. Assim como PHP os possui. Pois, interfaces são recursos que a orientação a objetos provê.

Quanto mais íntimo de uma determinada tecnologia, maior a produtividade.
Coloque alguém que nunca trabalhou com Linux ou Unix (só terminal) para administrar um servidor. Por mais que ele tenha todas as certificações Microsoft para servers e saiba muito de administração de servidores, ele irá, certamente, ter dificuldades.
Coloque um corredor da maratona para disputar a prova dos 100M rasos. Ele pode não vencer, mas, certamente, terminará a prova como o mais “inteiro”. Coloque um velocista para correr os 800 com barreira e você verá ele ficar para trás após a metade da prova (talvez menos).

Ou seja, estas grandezas são efetivamente subjetivas.

#8

kicolobo.

creio que oculta sim.

por default asp.net gera código sujo, o viewState Atrapalha, porém você consegue fazer quase…tudo como se estivesse criando uma app desktop, mas a app não fica performática, tem código repetido, não é legal.

quando inicia um desenvolvimento de qualidade, usando MVC, Orientação a objetos, Linq, Entity Framework, Jquery, você vê muito mais código, você programa a saída do código, você controla o processamento, portanto necessita de mais conhecimento para dar manutenção e da mais trabalho também, porém o resultado é “Profissional”.

digamos que o java pulou a parte facil/básica… não criando inúteis criadores de código sujo. e foi direto para a qualidade…

exatamente o que a MS esta tentando agora…buscar qualidade, porém o mercado ainda sofre com a cultura do 2-cliques

#9

[quote=drsmachado]Eu penso que o que o douglaskd colocou é perfeitamente cabível no que o adriano_si postou.
A curva de aprendizado do java passar por interfaces, reflection e tudo mais. Já .NET também possui tais recursos, além de alguns outros coringas. Assim como PHP os possui. Pois, interfaces são recursos que a orientação a objetos provê.

Quanto mais íntimo de uma determinada tecnologia, maior a produtividade.
Coloque alguém que nunca trabalhou com Linux ou Unix (só terminal) para administrar um servidor. Por mais que ele tenha todas as certificações Microsoft para servers e saiba muito de administração de servidores, ele irá, certamente, ter dificuldades.
Coloque um corredor da maratona para disputar a prova dos 100M rasos. Ele pode não vencer, mas, certamente, terminará a prova como o mais “inteiro”. Coloque um velocista para correr os 800 com barreira e você verá ele ficar para trás após a metade da prova (talvez menos).

Ou seja, estas grandezas são efetivamente subjetivas. [/quote]

Oi DrsMachado, boas comparações. Na sua opinião, o que gera então esta idéia de que .net é mais produtivo que Java dentro da gerência de consultorias?

#10

[quote=douglaskd]kicolobo.

creio que oculta sim.

por default asp.net gera código sujo, o viewState Atrapalha, porém você consegue fazer quase…tudo como se estivesse criando uma app desktop, mas a app não fica performática, tem código repetido, não é legal.

quando inicia um desenvolvimento de qualidade, usando MVC, Orientação a objetos, Linq, Entity Framework, Jquery, você vê muito mais código, você programa a saída do código, você controla o processamento, portanto necessita de mais conhecimento para dar manutenção e da mais trabalho também, porém o resultado é “Profissional”.

digamos que o java pulou a parte facil/básica… não criando inúteis criadores de código sujo. e foi direto para a qualidade…

exatamente o que a MS esta tentando agora…buscar qualidade, porém o mercado ainda sofre com a cultura do 2-cliques[/quote]

Oi Douglas, em diversos artigos mais antigos que li vejo os autores se referirem às ferramentas visuais de desenvolvimento como sendo ferramentas para geração de protótipos.
Será que este ganho de produtividade, que, como você mesmo diz, gerando código de baixa qualidade, não seria fruto de uma má compreensão da indústria a respeito do objetivo final destas ferramentas que era justamente gerar um protótipo rápido para alguns sistemas?

#11

[quote=kicolobo]Oi Douglas, em diversos artigos mais antigos que li vejo os autores se referirem às ferramentas visuais de desenvolvimento como sendo ferramentas para geração de protótipos.
Será que este ganho de produtividade, que, como você mesmo diz, gerando código de baixa qualidade, não seria fruto de uma má compreensão da indústria a respeito do objetivo final destas ferramentas que era justamente gerar um protótipo rápido para alguns sistemas?[/quote]

Interessante tocares no assunto da Prototipagem… Eis algo com o que eu adoro trabalhar.

Eu acho muito massa trabalhar com protótipos, pois rapidamente o cliente visualiza como ficará o Sistema. Olhando a face, o cliente consegue inclusive extrair regras que antes não havia imaginado.

O incrível é como que um protótipo consegue ser amigo e vilão, pois o mesmo passa a ideia de que já está quase pronto. Precisa de algum jogo de cintura pra explicar pro cliente que um protótipo tem muita sujeira e foi construído de qualquer jeito. O cliente sempre pensa que jogaraá fora o “trabalho rápido” e implorará que você continue com aquele projeto pra não “perder”.

Voltando para a época dos meus PFs e unindo isso à minha teoria de que as empresas de TI (a maioria das consultorias pelo menos) estão com pessoas no comando que não entendem P.N. de Software, me parece que o douglas acertou na mosca o problema.

  • Adriano, faça assim mesmo, desde que entregue pra ontem.
  • mas amigo, isso é só um protótipo, não…
  • Sem problema, pode fazer, não vamos jogar trabalho fora.
  • Ok.

Eu, claro, não reaproveitava e fazia tudo do 0, me matando pra entregar perto do tempo esperado… Isso me fez chutar o balde, hoje meus protótipos não são mais com ferramentas RAD, são feitos na unha com a base do que eu já vou entregar, assim não preciso jogar nada fora.

Desculpe ter desviado um pouco da proposta do tópico, mas foi quase que retornar aos meus primeiros anos na TI… rsrsrs :smiley:

Abs []

#12

[quote=adriano_si][quote=kicolobo]Oi Douglas, em diversos artigos mais antigos que li vejo os autores se referirem às ferramentas visuais de desenvolvimento como sendo ferramentas para geração de protótipos.
Será que este ganho de produtividade, que, como você mesmo diz, gerando código de baixa qualidade, não seria fruto de uma má compreensão da indústria a respeito do objetivo final destas ferramentas que era justamente gerar um protótipo rápido para alguns sistemas?[/quote]

Interessante tocares no assunto da Prototipagem… Eis algo com o que eu adoro trabalhar.

Eu acho muito massa trabalhar com protótipos, pois rapidamente o cliente visualiza como ficará o Sistema. Olhando a face, o cliente consegue inclusive extrair regras que antes não havia imaginado.

O incrível é como que um protótipo consegue ser amigo e vilão, pois o mesmo passa a ideia de que já está quase pronto. Precisa de algum jogo de cintura pra explicar pro cliente que um protótipo tem muita sujeira e foi construído de qualquer jeito. O cliente sempre pensa que jogaraá fora o “trabalho rápido” e implorará que você continue com aquele projeto pra não “perder”.

Voltando para a época dos meus PFs e unindo isso à minha teoria de que as empresas de TI (a maioria das consultorias pelo menos) estão com pessoas no comando que não entendem P.N. de Software, me parece que o douglas acertou na mosca o problema.

  • Adriano, faça assim mesmo, desde que entregue pra ontem.
  • mas amigo, isso é só um protótipo, não…
  • Sem problema, pode fazer, não vamos jogar trabalho fora.
  • Ok.

Eu, claro, não reaproveitava e fazia tudo do 0, me matando pra entregar perto do tempo esperado… Isso me fez chutar o balde, hoje meus protótipos não são mais com ferramentas RAD, são feitos na unha com a base do que eu já vou entregar, assim não preciso jogar nada fora.

Desculpe ter desviado um pouco da proposta do tópico, mas foi quase que retornar aos meus primeiros anos na TI… rsrsrs :smiley:

Abs [][/quote]

Oi Adriano, não acho que você fugiu do tópico: sabe o que eu percebi? Você foi no CENTRO dele.
Neste momento, eu me pergunto o seguinte (com base nesta nossa discussão): será que na realidade não estamos entregando para o cliente o protótipo ao invés do software real (pensando em .net ou qualquer ferramenta RAD ok?) e, com isto, estamos na realidade criando a ilusão de alta produtividade?

#13

Kicoloco, na minha opinião você, a grosso modo, já disse tudo no quote que inclui logo acima. Linguagens / ferramentas tem seus pontos altos e baixos em termos de produtividade, depende da aplicação. Se o técnico domina bem a linguagem e os requisitos se encaixam bem nos recursos as chances de produtividade aumentam bastante…e por ai vai.

Nenhum recurso especial, ou seja lá o que for, recupera ou sobrepõe os problemas de produtividade causados por:

  1. Falta de domínio da ferramenta.
  2. Falta de comprometimento.
  3. Não saber se comunicar.
  4. Falta de entendimento do que realmente tem que ser feito.
  5. Não saber o que significa “Satisfação do cliente”.
  6. Incompetência da liderança.
  7. Pensar que todos os projetos são iguais.
  8. Ter um bando de gente trabalhando juntas ao invés de uma equipe.
  9. Funcionários / colaboradores insatisfeitos.
  10. Projetos desestruturados.
  11. Péssima análise do projeto a ser desenvolvido.
  12. Rotatividade na equipe.
  13. Pensar que iniciantes irão conseguir executar atividades iguais aos mais experientes por causa das ferramentas e que isso não irá trazer consequências.
  14. Pensar que todos projetos duram 3 ou 6 meses.
  15. Pensar que TI não tem nada a ver com relações humanas.
  16. Não saber se expressar.
  17. Equipe com profissionais que estão na área apenas por dinheiro e não porque também gostam.
  18. Técnicos que pensam apenas como técnicos e não também como líderes.
  19. Não haver comprometimento do cliente com o projeto.
  20. Não saber elaborar uma arquitetura adequada.
    …
    Alguns itens podem estar redundantes mas a coisa é por ai.

Toda vez que ouço falar sobre recursos que trazem produtividade me vem a seguinte questão: O que se vê são recursos que trazem produtividade ou é alguma coisa que encobre a incompetência do usuário?

flws

#14

Bom, sem analizar o que realmente “produtividade” significa é dificil chegar em uma conclusão.
Se pensarmos em termos simples, “numero de horas uteis necessárias para que a funcionalidade esteja pronta” a produtividade do .net é maior.
Se pensarmos em termos mais complexos de “o que estou limitado a fazer” , a produtividade do java é maior. Este “limitado” é amplo. Considera-se por exemplo a limitação de não poder usar o component Xo u Y porque é pago, enquanto no java, embora haja coisas pagas a esmagadora maioria é free. Dá para fazer um sistema bem parrudo só usando coisas free. Esta mesma opção é uma das vantagens do .net o que aumenta a sua praticidade (leia-se “não preciso programar porque outro cara já fez para mim”).

O nivel tencologico do java é baixo no sentido que as API são construidas e pensadas para que os programadores criem outras libs. Em .net isso não é tão assim. Embora os componentes estejam lá, as pessoas aprendem a usar em mais alta abstração. Por exemplo, em java a tecnologia web começou de baixo para cima. Os servlets são encarnações java do CGI e o JSF é baseado em servlets. O JSP veio depois dos servlets para facilitar a coisas e seria equivalente ao ASP antigo. Em .net não ha mais o nivel do jsp , do asp antigo. Só ha o nivel do JSF e do Servlet. Mas ninguem precisa mexer com servlets diretamente (não lembro do nome da clase mas é algo como methodrequesthandler ou coisas assim). Porque se começa por cima, as pessoas .net tem menos profundidade naquilo que manipulam. Ao usar construros mais altos, a produtividade é obviamente maior. Contudo, em java, se vc souber usar os frameworks certos, vc obtem o mesmo nivel de produtividade porque vc abstrai essas camadas mais profundas. A diferença é que em java, sempre que eu quiser eu posso fazer um servlet, em .net não é tão simples (pela falta de uso dessa feature).

java vc c# é pointless. A linguagem não acelera nem atraza a produtividade quando a pessoa sabe o que está escrevendo. é a plataforma, a lib da API que faz a diferença.
Tanto em .net como em java existem linguagens alternativas para aqueles que querem ousar.

Para mim, acho que é viável escrever bons programas tanto em uma como em outra. O problema não está na plataforma, está, como foi dito, na cultura. A cultura.net é mais virada para “o minimo esforço possivel”. São usados muitos componentes de outrem, às vezes sem saber bem porque (porque são mais “bonitos” é uma razão válida") A distribuição das aplicações é diferente, não havendo um RMI da vida em .net sendo usado muito Http+xml/SOAP. O .net é mais plug & play. A IDE faz muito mais do que deveria ( embora o netbeans faça a mesma coisa). Ponha um dev .net a programar no notepad, ele vai ficar maluco sem poder usar a caixa de propriedades :lol: . Em java isso é natural.

A filosofia das plataformas é diferente. Java é uma plataforma virtual para criar plataformas de aplicação, .net é uma plataforma de aplicação (o link tem uma imagem que mostra a relação). É por isso que o pessoal do java normalmente tem mais profundidade tecnica no sentido de se preocupar com padrões de projeto , boas práticas , etc… porque trabalha nin nível mais baixo, em .net o pessoal se preocupa mais se funciona ou não. Dito de outra forma, projetos em java cria sua propria plataforma de aplicação ( como deve ser) e em .net eles compram essa plataforma (ficando sujeitos a vendor lock-in).

O mito é real ? Eu diria que sim, mas apenas se olharmos o resultado final. Se olharmos por baixo do capô a produtividade do .net advem de muita coisas implicita , assumida e controlada por outrem (microsoft) . Ou seja, ela é mais produtiva porque é mais simples, no sentido de restringir mais e por consequencia dar maior foco.
A mesma produtividade pode ser alcançada com java, mas é necessário um expert (normalmente chamado de Arquiteto) que lance mão de um conjunto de frameworks e os cole juntos para obter isso. A diferença é que neste cenário seria possivel mudar cada um desses frameworks por outros equivalentes. Em .net isso nem sempre é possivel. Contudo, a maior parte das vezes também não é desejável ( ou sequer se imagina que seja possivel). O que interessa é que funciona “com o menor esforço possivel”.

#15

Acho que as principais vantagens de produtividade do .NET são intimamente ligadas ao C#, e como a linguagem é mais ousada ao introduzir conceitos de programação funcional, delegates, type inference, etc. para facilitar a vida imediata (i.e. SLOC/minuto, expressividade do código) do programador. Esse aumento da produtividade percebida é o que é divulgado com mais energia, e sempre que converso com os fans de C#/.NET é uma das primeiras coisas a serem levantadas.

Mesmo com uma produtividade imediata melhor, talvez esse seja exatamente o contra-argumento do Java: como a linguagem e a SDK são mais estáveis, equipes que já estão confortáveis com a tecnologia não precisam estar constantemente modificando seus costumes para escrita de código, e o código não fique obsoleto tão rapidamente quanto em outras plataformas. E se, como o douglaskd disse, as empresas brasileiras valorizam mais padrões de código, arquiteturas bem feitas, etc., é fácil ver porque Java é mais atraente que .NET por essas bandas.

#16

Se tá zuando né ? Projeto de 2 semanas é trabalhinho de faculdade.

#17

Minha opnião:

Produtividade na minha visão se resume a alguns pilares: Necessidade, Tecnologia, Experiência, Ferramentas, Documentação

Necessidade:
Se falar de .NET e Java, em questão de necessidade, vai depender muito do que quer fazer. Há situações que Java pode ser mais produtivo que .NET e vice versa. Fazer sistemas desktop com diversas integrações com o sistema operacional Windows em Java é totalmente improdutivo se comparado a .NET. Fazer qualquer coisa em Mono (vamos falar que é o .NET multiplataforma) é bem improdutivo se comparado a Java. Tem casos que C++ pode ser muito mais produtivo que Java/.NET. No geral muitos cenários são atendidos pelas 2 plataformas e a produtividade vai depender muito mais da arquitetura em si. Fazer jsp com código sql pode ser tão produtivo quanto aspx com código sql. Há uns 15 anos atrás li uma frase inesquecivel. Basic é a linguagem mais dificil que existe. Experimente criar um emulador de video games com ele… A mesma coisa, php pode ser muito produtivo para coisas simples, mas sistemas grandes e complexos podem ser tornar um pesadelo se não forem bem estruturados e tornar php bem mais improdutivo que Java.

Tecnologia:
No geral se falar de .Net e Java, independente da linguagem, C# e Java, Vb.NET e Java, são muito parecidos e não consigo enxergar produtividade maior ou menor. Bem diferente de linguagem C que por ser mais complexa, reflete diretamente na produtividade (ok, há casos extremamente produtivos, principalmente usando QT em C++, mas são casos e casos).

Experiência:
Como já foi falado, a experiência dos profissionais envolvidos afeta diretamente a produtividade. Acho que um cara com 5 anos de experiência em Java é tão produtivo quanto um em .NET se a necessidade for criar algo bem suportado pelas 2 plataformas.

Ferramentas:
Vejo hoje netbeans e eclipse tão produtivos quanto visual studio. São pequenas diferenças que não vão ser significativas no desenvolvimento de um projeto que envolve diversas fases, análise, testes, homologação, etc (tem quem diga que a codificação representa apenas 30% do projeto). Neste caso, acho que o mito é forte, pois no inicio do Java as ferramentas eram bem improdutivas se comparadas ao .NET e talvez esse tenha sido o que criou este “mito”. Eu trabalhei numa época (1999) onde haviam apenas editores basicos de Java, se compilava programas pelo javac, etc… Realmente nessa época as ferramentas deixavam o desenvolvimento do java “tenso” perto de um visual studio…

Documentação:
Mesmo havendo mais documentação de java do que C#/VB.NET/etc… hoje tem tanta coisa de ambas as plataformas que as 2 são extremamente produtivas se considerar este aspecto…

Opnião pessoal

#18

Se tá zuando né ? Projeto de 2 semanas é trabalhinho de faculdade. [/quote]

Não cara, talvez minha definição foi ruim, mas um projeto relativamente grande para uma pessoa só desenvolver…

Acho que agora ficou mais claro :wink: e voltando ao tópico…

Abs []

#19

[quote=sergiotaborda]Bom, sem analizar o que realmente “produtividade” significa é dificil chegar em uma conclusão.
Se pensarmos em termos simples, “numero de horas uteis necessárias para que a funcionalidade esteja pronta” a produtividade do .net é maior.
Se pensarmos em termos mais complexos de “o que estou limitado a fazer” , a produtividade do java é maior. Este “limitado” é amplo. Considera-se por exemplo a limitação de não poder usar o component Xo u Y porque é pago, enquanto no java, embora haja coisas pagas a esmagadora maioria é free. Dá para fazer um sistema bem parrudo só usando coisas free. Esta mesma opção é uma das vantagens do .net o que aumenta a sua praticidade (leia-se “não preciso programar porque outro cara já fez para mim”).

O nivel tencologico do java é baixo no sentido que as API são construidas e pensadas para que os programadores criem outras libs. Em .net isso não é tão assim. Embora os componentes estejam lá, as pessoas aprendem a usar em mais alta abstração. Por exemplo, em java a tecnologia web começou de baixo para cima. Os servlets são encarnações java do CGI e o JSF é baseado em servlets. O JSP veio depois dos servlets para facilitar a coisas e seria equivalente ao ASP antigo. Em .net não ha mais o nivel do jsp , do asp antigo. Só ha o nivel do JSF e do Servlet. Mas ninguem precisa mexer com servlets diretamente (não lembro do nome da clase mas é algo como methodrequesthandler ou coisas assim). Porque se começa por cima, as pessoas .net tem menos profundidade naquilo que manipulam. Ao usar construros mais altos, a produtividade é obviamente maior. Contudo, em java, se vc souber usar os frameworks certos, vc obtem o mesmo nivel de produtividade porque vc abstrai essas camadas mais profundas. A diferença é que em java, sempre que eu quiser eu posso fazer um servlet, em .net não é tão simples (pela falta de uso dessa feature).

java vc c# é pointless. A linguagem não acelera nem atraza a produtividade quando a pessoa sabe o que está escrevendo. é a plataforma, a lib da API que faz a diferença.
Tanto em .net como em java existem linguagens alternativas para aqueles que querem ousar.

Para mim, acho que é viável escrever bons programas tanto em uma como em outra. O problema não está na plataforma, está, como foi dito, na cultura. A cultura.net é mais virada para “o minimo esforço possivel”. São usados muitos componentes de outrem, às vezes sem saber bem porque (porque são mais “bonitos” é uma razão válida") A distribuição das aplicações é diferente, não havendo um RMI da vida em .net sendo usado muito Http+xml/SOAP. O .net é mais plug & play. A IDE faz muito mais do que deveria ( embora o netbeans faça a mesma coisa). Ponha um dev .net a programar no notepad, ele vai ficar maluco sem poder usar a caixa de propriedades :lol: . Em java isso é natural.

A filosofia das plataformas é diferente. Java é uma plataforma virtual para criar plataformas de aplicação, .net é uma plataforma de aplicação (o link tem uma imagem que mostra a relação). É por isso que o pessoal do java normalmente tem mais profundidade tecnica no sentido de se preocupar com padrões de projeto , boas práticas , etc… porque trabalha nin nível mais baixo, em .net o pessoal se preocupa mais se funciona ou não. Dito de outra forma, projetos em java cria sua propria plataforma de aplicação ( como deve ser) e em .net eles compram essa plataforma (ficando sujeitos a vendor lock-in).

O mito é real ? Eu diria que sim, mas apenas se olharmos o resultado final. Se olharmos por baixo do capô a produtividade do .net advem de muita coisas implicita , assumida e controlada por outrem (microsoft) . Ou seja, ela é mais produtiva porque é mais simples, no sentido de restringir mais e por consequencia dar maior foco.
A mesma produtividade pode ser alcançada com java, mas é necessário um expert (normalmente chamado de Arquiteto) que lance mão de um conjunto de frameworks e os cole juntos para obter isso. A diferença é que neste cenário seria possivel mudar cada um desses frameworks por outros equivalentes. Em .net isso nem sempre é possivel. Contudo, a maior parte das vezes também não é desejável ( ou sequer se imagina que seja possivel). O que interessa é que funciona “com o menor esforço possivel”.
[/quote]

Realmente essa questão de “fazer funcionar” pode realmente colocar o .NET na frente do Java em alguns aspectos.
Entretanto, se o projeto for complexo, o fazer funcionar pode se tornar um pesadelo num futuro próximo…

Vamos ao mundo real… a maior parte dos projetos são complexos ou simples ??? Em empresas pequenas e médias ??? Acho que é esse o real motivo que .NET é falado como mais produtivo que Java… Em empresas pequenas e médias geralmente os problemas são simples, os projetos simples e precisam “apenas funcionar”…

Não seria esse o mesmo motivo de todo mundo falar que php é o que há quando se fala em produtividade em desenvolvimento de soluções web ??? Não só php mas todas essas linguagens da moda no mundo web ???

#20

[quote]
Oi Douglas, em diversos artigos mais antigos que li vejo os autores se referirem às ferramentas visuais de desenvolvimento como sendo ferramentas para geração de protótipos.
Será que este ganho de produtividade, que, como você mesmo diz, gerando código de baixa qualidade, não seria fruto de uma má compreensão da indústria a respeito do objetivo final destas ferramentas que era justamente gerar um protótipo rápido para alguns sistemas?[/quote]

Faz alguma diferença de que o software é chamado por blogueiros se as consultorias estão vendendo e o cliente está satisfeito?