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

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.

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 []

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 []

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?

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.

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!!!)

douglaskd:

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.

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!!!)

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?

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.

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

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.

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?

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

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?

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?

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

Abs []

adriano_si:

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?

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

Abs []

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?

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

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”.

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.

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

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

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

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 e voltando ao tópico…

Abs []

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”.

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 ???

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?

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

Os clientes estão satisfeitos ???

Preciso sair de onde estou hoje, pois o cenário que venho vivendo há uns 4 anos é completamente o oposto disso… O que vejo é sempre uma guerrinha entre “TI vs Cliente” onde a culpa sempre é do outro e ninguém está satisfeito.

Estou terminando um Post em meu blog sobre isso e gostaria de atualizar o status, pois até onde eu pensava, era a realidade do mercado

Nessas horas que vejo que estou no lugar errado.

Creio que a discussão está indo em um nível muito bom e cada opinião, achamos novidades…

Abs []

adriano_si:

Os clientes estão satisfeitos ???

Preciso sair de onde estou hoje, pois o cenário que venho vivendo há uns 4 anos é completamente o oposto disso… O que vejo é sempre uma guerrinha entre “TI vs Cliente” onde a culpa sempre é do outro e ninguém está satisfeito.

Estou terminando um Post em meu blog sobre isso e gostaria de atualizar o status, pois até onde eu pensava, era a realidade do mercado

Nessas horas que vejo que estou no lugar errado.

Creio que a discussão está indo em um nível muito bom e cada opinião, achamos novidades…

Abs []

Oi Adriano,

Sobre a guerrinha TI x Cliente acho que muitos por aqui tem experiências semelhantes.
Na minha opinião a culpa é de ambos. TI não consegue mostrar valor real para o cliente (ROI) e os clientes não querem perder “tempo” se envolvendo com os projetos, por medo, por não quererem perder o trabalho/comodismo deles, vários fatores.

Não fugindo ao tópico tem dois links que eu gostaria de compartilhar, acho que muitos aqui já devem ter lido

Um mais recente

Outro mais antigo mas que ainda se aplica totalmente a nossa realidade

Abs

Os clientes estão satisfeitos ???

Preciso sair de onde estou hoje, pois o cenário que venho vivendo há uns 4 anos é completamente o oposto disso… O que vejo é sempre uma guerrinha entre “TI vs Cliente” onde a culpa sempre é do outro e ninguém está satisfeito.

Acho que o JoseIgnacio quiz dizer “se as consultorias estão vendendo e o cliente não sabe que está sendo enganado”.
Na realidade o que vc observa é a insastifação de um cliente que não sabe que está sendo enganado. Poderiamos argumentar que ele que está enganando a TI, mas se ele estiver fazendo isso, isso é uma forma de se enganar a si mesmo (achando que está levando vantagem).
Aliás este é um assunto para uma thread inteira. O que realmente é vendido e o que realmente é entregue e como são as prespetivas e expectativas de cada lado.

Respondendo ao JoseIgnacio. Se vc estiver sozinho no meio do nada e matar, digamos, uma raposa quem vai saber ? Você vai saber.
É a mesma coisa no software. Se o cara faz um software porcaria ele vai saber. Agora, tal como no caso da raposa isso não significa que vc saiba que é mau ou bom, mas o fato em si , vc conhece-o. O juizo de valor é feito depois e à luz de uma moral e uma cultura. Ao discutir a prática A vs B estamos discutindo essa moral e essa cultura. Se a empresa A faz um software X por Z com .net e a empreza B faz o mesmo software X com java pelo menos preço , qual está enganando o cliente ?
Considerando que o preço é algo que se negocia, nenhuma. Mas considerando que o custo não é o mesmo, a empresa B , provavelmente teve menos lucro. Contudo, se B é proficiente em java e conta uma plataforma de aplicação , e ela que tem o maior lucro (ou igual). No prática o primeiro cenário é mais comum. Aliás o ceário mais comum é para um mesmo projeto X , java saia mais caro. Se sai melhor ou pior, teriamos que analizar caso a caso. Mas com certeza, o esforço em java é maior na prática devido à insuficiencia de investimento em plataformas de aplicação.

André Fonseca:

Na minha opinião a culpa é de ambos. TI não consegue mostrar valor real para o cliente (ROI) e os clientes não querem perder “tempo” se envolvendo com os projetos, por medo, por não quererem perder o trabalho/comodismo deles, vários fatores.

O que eu vejo como grave nisso tudo é que a responsabilidade de orientar os clientes, é nossa, como PROFISSIONAIS de TI.

Se você abre um Banco e contrata alguém pra assumir sua TI, você está dizendo que confia nesse alguém pra te direcionar no assunto TI.

Eu me passo e fico de cara quando vejo pessoas de consultoria, começando essa guerra, enganando os clientes, colocando a culpa de erros que poderiam ter sido evitados com algumas skils, puramente nos clientes, forçando os mesmos a assinar um calhamaço de documento de coisas mal escritas, fazendo o mesmo pensar que alí estão as regras reais, etc… Vocês podem me dizer que se o cliente assina está assumindo a responsabilidade, eu já discordo disso de forma sumária e definitiva, mas isso é assunto pra outro Post, sem desviar o assunto…

Nunca tinha pensado nisso, mas realmente o tempo nos dá essa capacidade, ou a apura para quem já nasce com ela no sangue.

Interessante que o Post não toca no tema “Tecnologia utilizada” levando em consideração que a importância disso beira o 0, afinal sem saber o problema, difícil fica de saber o que usar, e já que o artigo trata de problemas em geral, porque então falar de linguagens ???

Abs []

Acho que um grande problema em medir produtividade é a falta de métricas.
Raramente se vê alguém coletando indicadores do desenvolvimento de um projeto para saber o que foi bom ou ruim, lento ou rápido.

Com isso a produtividade não é medida, ela é “achada”, por feeling, experiências, velocidade do vento.

Isso faz com que na hora de comparar tecnologia, os mais sensatos adotem uma postura mais politicamente correta.
“Cada tecnologia tem seu caso de uso” ou “A produtividade individual conta mais do que a ferramenta”.

Apesar das frases fazerem todo sentido, acabam ocultando situações válidas:

• Cada tecnologia tem seu caso de uso? Sim, mas tem tecnologias voltadas para os mesmos casos. Por que não compará-las?

• A produtividade individual conta mais do que a ferramenta? Ok, comparem então duas pessoas com proficiência equivalente em ambas.

Se eu disser que o java 7 é bem mais produtivo do que o 1.1, acho que poucos vão se opor.
Por que não podemos comparar com a mesma frieza então, linguagens diferentes?

AbelBueno:

Acho que um grande problema em medir produtividade é a falta de métricas.
Raramente se vê alguém coletando indicadores do desenvolvimento de um projeto para saber o que foi bom ou ruim, lento ou rápido.

Com isso a produtividade não é medida, ela é “achada”, por feeling, experiências, velocidade do vento.

Isso faz com que na hora de comparar tecnologia, os mais sensatos adotem uma postura mais politicamente correta.
“Cada tecnologia tem seu caso de uso” ou “A produtividade individual conta mais do que a ferramenta”.

Apesar das frases fazerem todo sentido, acabam ocultando situações válidas:

• Cada tecnologia tem seu caso de uso? Sim, mas tem tecnologias voltadas para os mesmos casos. Por que não compará-las?

• A produtividade individual conta mais do que a ferramenta? Ok, comparem então duas pessoas com proficiência equivalente em ambas.

Se eu disser que o java 7 é bem mais produtivo do que o 1.1, acho que poucos vão se opor.
Por que não podemos comparar com a mesma frieza então, linguagens diferentes?

Na minha opinião o problema não é a falta de metricas, apesar de eu não conhecer métricas precisas a longo prazo.

Eu acredito que o principal problema é a natureza dinâmica da nossa profissão.

As pessoas trocam muito rápido de emprego, de função.

Um bom desenvolvedor demora tempo para se tornar produtivo também. E esse tempo é algo que muitas vezes não temos.

Muitas vezes uma pessoa que saiba muito acaba sendo menos produtiva do que outra que saiba muito menos do que ela mas que já está acostumada a lidar com as particularidades do ambiente do trabalho.

Uma coisa que eu sempre pensei é que: o problema dos projetos de SW não atingirem as metas dejadas raramente tem relação direta com a tecnologia adotada.

Abs

Eu concordo contigo.

Não acho que seja o principal fator também, muito pelo contrário.

Mas nem por isso acredito que podemos considerar que “tanto faz”.

Acho que a gente considera muita coisa equivalente quando na verdade podem ser bem diferentes.

De qualquer forma concordo que este não é o principal problema de nossa área.

Não conheço a plataforma .NET da mesma forma que conheço Java. Pouco posso opniar sobre produtividade, mas da opnião que expresso abaixo, toda ela está baseada em leituras e conversas com amigos.

A questão não se referente apenas a produtividade, mas a curva de aprendizado, evolução da plataforma e ferramentas. Se comparamos todos esses quesitos, acho que .NET leva uma certa vantagem.

Do pouco que conheço, a plataforma .NET oferece tudo integrado, desde a parte de desenvolvimento ate o deploy da aplicação. Não é necessário baixar diversas ferramentas como maven, ant, softwares para integração continua plugins para eclipse ou netbeans.

Outra quesito que .NET leva vantagem é que. Um desenvolvedor java dependendo da empresa que vai, precisa conhecer Hibernate, Spring, JSF, Struts, DWR, JBoss, Websphere, Maven, Ant eclipse ou netbeans. E isso varia de empresa para empresa. Na plataforma .NET todo esse conhecimento não é exigido. A adptação de um desenvolvedor .NET é muito mais rápida quando ocorre a troca de emprego.

Peço desculpas caso tenha falado alguma besteira. Talvez uma pessoa com conhecimentos em ambas das plataformas, possa melhor opnar sobre o assunto.

MauNunes:

Não conheço a plataforma .NET da mesma forma que conheço Java. Pouco posso opniar sobre produtividade, mas da opnião que expresso abaixo, toda ela está baseada em leituras e conversas com amigos.

A questão não se referente apenas a produtividade, mas a curva de aprendizado, evolução da plataforma e ferramentas. Se comparamos todos esses quesitos, acho que .NET leva uma certa vantagem.

Do pouco que conheço, a plataforma .NET oferece tudo integrado, desde a parte de desenvolvimento ate o deploy da aplicação. Não é necessário baixar diversas ferramentas como maven, ant, softwares para integração continua plugins para eclipse ou netbeans.

Outra quesito que .NET leva vantagem é que. Um desenvolvedor java dependendo da empresa que vai, precisa conhecer Hibernate, Spring, JSF, Struts, DWR, JBoss, Websphere, Maven, Ant eclipse ou netbeans. E isso varia de empresa para empresa. Na plataforma .NET todo esse conhecimento não é exigido. A adptação de um desenvolvedor .NET é muito mais rápida quando ocorre a troca de emprego.

Peço desculpas caso tenha falado alguma besteira. Talvez uma pessoa com conhecimentos em ambas das plataformas, possa melhor opnar sobre o assunto.

vejo muito isso, soma-se esse mesmo problema quando a empresa precisa manter sistemas legados em frameworks antigos…

porém microsoft também tem o problema com o asp classico, com a diferença que é extremamente facil, diferênte dos frameworks java…

Dei risada alta quando eu li isso!!! LOL!

Tipo, voce acha que desenvolvedores .NET nao se preocupam com design patterns, arquitetura “bem feita” e controle do codigo??

Quem desenvolve .NET sabe, se vc quiser criar um projeto MVC por exemplo, o Visual Studio ate tem um template que cria o projeto com algum codigo para voce (mesmo assim nao eh muito e nao eh porco de maneira alguma), tambem voce pode criar um projeto completamente branco. Mesma coisa com um projeto web com webforms, ou voce acha que soh porque o Visual Studio cria uma Default.aspx praticamente em branco e 3 folders eh muita coisa??

Na minha opiniao, desenvolver em .NET e mais produtivo que Java? Resposta, NAO. uhhhhh, descoberta do ano.

Eu nao acho que tem a ver com linguagens como alguns disseram, ate porque .NET suporta varias linguagens. E na minha opiniao isso faz a plataforma .NET se popularizar muito.

Ja trabalhei um bom tempo com Java e trabalho com .NET pouco mais de 4 anos e o que eu posso dizer eh, se alguem esta comecando a programar em Java profissionalmente, ok a pessoa tem que aprender Java (linguagem), leva um tempo para aprender, depois se for para programar pra web, tem que aprender outras coisas tipo, como funciona um servidor de aplicacao, como configurar e etc, depois tera que escolher dentre os milhares de frameworks disponiveis, aprender a usa-los e la se vai mais tempo, ai se ele quer aprender a otimizar processo de compilacao, packaging, deployment vai ter que aprender ANT, sem contar banco de dados, sistema de controle de versao e outras coisas mais “along the way”.
Ai quando a pessoa aprende tudo isso, faz um mabalarismo para fazer um hello world.

.NET por outro lado, voce tem o visual studio que eh uma otima IDE, tem alguns templates de projetos que mesmo sendo bem crus e algumas vezes vazios, ja servem como um ponto de partida pra quem esta comecando do zero. Fora isso existe o Cassini que eh um simples web server que hospeda ASP.NET entao, pra quem quer comecar um projeto seja webforms ou MVC, eh soh criar o projeto, teclar F5 e BAM!!! o browser abre com a pagina default ou default view para MVC e tudo funciona, vem ate com JQuery no folder scripts. Conexao com banco de dados eh muito simples, seja MSQL, MSQL Express, Oracle etc. Controle de acesso da sua aplicacao eh simples com Membership e Role providers.
A Microsoft tambem tem o TFS (Team Foundation Server) que eh usado para projetos em grupo, que tem controle de versao, tracking de projeto, controle de bugs e isso eh totalmente integrado com o Visual Studio, o que facilita muito, qualquer checkin eh associado a um projeto (story) ou um bug. A partir dai eu posso ver os bugs que foram reportados por projeto, criar queries para filtrar bugs do jeito que eu quiser, posso gerar um novo build e package da minha aplicacao, enfim, eh uma ferramente extremamente poderosa.

Pra quem reclama que .NET nao tem algo como o ANT, tem sim, tem o Windows PowerShell que da pra criar scripts para automizar compilacao, deployment, patch config files, mover ou copiar arquivos, funcoes administrativas no sistema, enfim, da pra fazer praticamente tudo.

Eu acho que a Microsoft fez um otimo trabalho em fazer todas essas ferramentas funcionarem de forma consistente, o que faz o aprendizado ser mais rapido. E isso na minha opiniao eh a maior vantagem em relacao ao Java hoje em dia. Voce consegue otimas resultados com Java, mas para isso voce tera que ter competencias em varias coisas que funcionam de maneira diferente e inconsistente. .NET esta tudo disponivel de maneira consistente e integrada.

Algumas pessoas podem argumentar, que isso eh o problema da microsoft que voce fica preso aos produtos que eles lancam, mas isso nao eh verdade, tem muitos projetos open source para projetos .NET . Outros argumentam com Microsoft nao eh transparente que os seus produtos sao uma “caixa-preta”, outra afirmacao que nao eh real, ano passado eu tive que implementar seguraca contra cross-site request forgery para projetos MVC na nossa framework e eu fiz o download do codigo do Microsoft MVC Framework que eh aberto para entender como funciona para ter inspiracao de como trabalhar na minha implementacao.

Sumarizando, pra mim nao depende de linguagem, nao depende de funcionalidades do .NET framework, como LINQ e outras framworks como Entity Framework e sim da uniformidade e integracao entre os produtos que fazem .NET ser uma otima plataforma para se trabalhar. Se isso faz as pessoas mais produtivas eu nao sei.

Produtividade eh muito subjetivo, um time pode ser super produtivo e entregar um projeto mal feito outro pode ser produtivo e ter um resultado de primeira. O que eh produtivo? Quem faz mais coisas em menos tempo ou quem faz menos mas com boa qualidade?

Os java fanboys costumam dizer que desenvolvedor .NET faz codigo mal-feito e alguns ate acham que design patterns eh uma coisa especifica para java. O que eu posso dizer eh que eu nunca vi tanto codigo mal feito quanto na epoca que eu trabalhei com Java, era um circo de horrores. Vi muita coisa boa, mas vi muita coisa ruim. Ate hoje soh vi codigo bom em .NET e eu acredito que eu melhorei 100% como desenvolvedor, aprendi nesses 4 anos. Pra mim, nao eh problema da plataforma e sim da peca em frente ao teclado.

PS: Essa foi a maior bosta que eu li nos ultimos anos.

//Daniel

A grande vantagem pregada pelo .NET sobre o java é o drag and drop. Esta pode ate ser em desktop, mas em projetos web ela é bem menor. .NET será mais produtiva se o cara não tem o menor conhecimento de HTML, css e javascritpt. Mas se ele não tem esse conhecimento, mesmo em .NET logo ele deixará de ser produtivo, porque vai se deparar com problemas que não vem com solução pronta.

E a diferença acaba ai. O que de fato aumenta/diminui a produtividade é a arquitetura da aplicação, a simplicidade com que o código foi feito, a clareza, o fácil entendimento do que está escrito e coisas do gênero. Coisas que independem completamente de linguagem/plataforma ou qualquer outra coisa.

Alguem citou ai que ninguem vai discutir que java 7 é mais produtivo que java 1. Pode ser, mas com certeza trabalhar numa base de código bem feita usando java 1 sera mais produtivo que numa base toda gambiarrada escrita em java 7.

As duas linguagens são tão parecidas, sempre uma copiando recursos uma da outra, que acho impossível ter alguma diferença de produtividade entre as duas linguagens.
Talvez um ou outro framework em uma área bem específica pode fazer uma pequena diferença. Mas no geral para mim a produtividade é a mesma.
Para termos uma produtividade perceptível teria que ter algum mudança de paradigma ou uma diferença grande entre as linguagens.

Vocês estão se esquecendo do principal…
A produtividade não está no Java nem no .Net, e sim nos frameworks aglomerados.

Vejam a exemplo:
Quem no mundo java dá mais produtividade?
Spring, Struts ou JSF?

No .Net, quem dá mais produtividade?
Spring, Asp.Net, Castle ou MVC3 Razor?

Entre Java e C#, escolho os dois… por incrível que pareça, o diferencial do C# durante muito tempo foi a api System.Linq.Expressions (Lambda Expressions), o que inclusive já existe pra Java.
Opa, mas o Visual Studio tem Drag 'n Drop!
E o Netbeans tá pôdi?
As ferramentas Drag 'n Drop do Netbeans e do JDeveloper são idênticas ao Visual Studio.

Ah, mas no Visual Studio tá tudo integrado, F5 e a página já abre.
Meu irmão zé goiaba, o Visual Studio vem com o IIS Express assim como o Netbeans vem com o Tomcat, a tecla é a diferença, F6 FTW.

Ah mas no mundo Java tem uma infinidade de Frameworks, coisa que faz falta no .Net
Zé ruela, acho que 99% do que existe open source tanto em java como em .net é dispensável, você vivem sem eles. A propósito, a maioria dos frameworks open java possuem uma implementação .Net.

Vou citar alguns dentre os que utilizo, e que estão em ambas as plataformas de forma idêntica:

MVC
Java: Vraptor
.Net: MVC3 Razor

Manipulação de XML
Java: JAXB
.Net: System.Xml

Persistência
Java: Hibernate
.Net: nHibernate

Reconhecimento de Linguagem
Java: Antlr
.Net: Antlr (até o nome é igual ahahaha)

Agendamento de tarefas
Java: Quartz
.Net: Quartz.Net

Gerenciamento de Logs
Java: log4j
.Net: log4net

Para o XNA não tem equivalente, é extremamente produtivo
Zé ruela, já existe o jXNA que é a mesma porqueira.

Me digam, existe algum outro tipo de tarefa que você faça que não se utilize dessas ferramentas? Caso tenha, só falar que eu posto aqui.

Sendo assim, não é na linguagem que reside a facilidade de desenvolvimento, e sim no Framework e no profissional que o utiliza.

Spring e Spring.Net são beeeem iguais, JSF e Asp.Net são mais parecidos do que vocês imaginam. Porém o Razor está anos luz além, oops tá nada, no java tem Vraptor que é igualzinho, sem tirar nem as annotations e a injeção de dependências.

Amigos, essa disputa sobre quem é mais produtivo é mais religiosa do que prática.

Se você tem um profissional Java com Vraptor e Spring, ele vai ser mais produtivo que um profissional com Asp.Net Clássico. Em contrapartida, um profissional Razor vai ser mais ágil que um JSF.

Agora, se alguém aqui acha que a linguagem é que é ou não produtiva, refaça a faculdade, a lógica é igual para todas as linguagens, o que muda é o framework utilizado na aplicação.

Para finalizar minha participação no post, tirando a parte grosseira, concordo com o texto acima, publicado pelo windsofhell.
Só acho que o assunto não merece um artigo. Opnião é opnião e deve ser respeitada. Publica um artigo comparando duas plataformas é dar um tiro no pé e com certeza não vai chegar a conclusão nenhuma.

Tem algo errado na sua analise. Porque aquilo que eu disse é o mesmo que vc disse nos dois paragrafos acima. Talvez você não tenha entendido, mas é o mesmo.
Você está julgando pela sua experiencia de ter programados nos dois, eu estou julgando pela experiencia de várias equipes de uma e outra plataforma. Talvez vc use padrões e boas práticas (provavelmente porque começou pelo java onde vc aprender isso) , mas não é comum o pessoal de .net saber ou usar padrões da mesma forma que em java. Para o pessoal do .net usar isso o lider tecnico precisa ser forte e com muita experiencia e uma certa pitada de autoritarismo, porque se não, o pessoal não aceita. A gamba é sempre o primeiro recurso.

Engraçado como vc diz a mesma coisa com palavras diferentes e depois diz que é tudo errado. :lol: :lol:

sergiotaborda:

Tem algo errado na sua analise. Porque aquilo que eu disse é o mesmo que vc disse nos dois paragrafos acima. Talvez você não tenha entendido, mas é o mesmo.
Você está julgando pela sua experiencia de ter programados nos dois, eu estou julgando pela experiencia de várias equipes de uma e outra plataforma. Talvez vc use padrões e boas práticas (provavelmente porque começou pelo java onde vc aprender isso) , mas não é comum o pessoal de .net saber ou usar padrões da mesma forma que em java. Para o pessoal do .net usar isso o lider tecnico precisa ser forte e com muita experiencia e uma certa pitada de autoritarismo, porque se não, o pessoal não aceita. A gamba é sempre o primeiro recurso.

Engraçado como vc diz a mesma coisa com palavras diferentes e depois diz que é tudo errado. :lol: :lol:

Nao mesmo. Pelo contrario, eu nao acredito que o pessoal que trabalha com .NET eh movido pelo “se funciona ou nao” como voce disse. Eu acho que os desenvolvedores .NET sao tao tecnicos, preocupados em obedecer os principios de orientacao a objetos, boas praticas, design patterns e etc, assim como eu acredito que tem gente assim desenvolvendo em Java.

Usando meu exemplo aqui na empresa, nos temos nosso proprio produto e varias frameworks, os nossos “usuarios” nao sao o usuario final e sim empresas parceiras que usam a nossa solucao e framework para desenvolvimento. Entao nos temos uma responsabilidade muito grande quanto ao codigo que nos lancamos. Primeiro que o produto tem que ser bem projetado ao ponto de ser flexivel o suficiente para atender as necessidades de outros desenvolvedores, segundo, tem que atender todos as boas praticas e padroes estabelecidos para .NET.

Nos temos o Resharper que eh uma extensao para Visual Studio que faz analise de codigo para assegurar que esta respeitando certos padroes. Fora isso, o nosso TFS (Team Foundation Server), a cada check-in roda todos os nossos unit tests, roda uma ferramenta que analisa client-server code (Javascript e CSS) caso tenha um problema check-in eh cancelado.

Fora isso antes de check-in o nosso codigo tem que ser revisado por pelo menos duas pessoas. Enfim, codigo tosco nao passa.

Nas empresas que eu trabalhei com Java, muitos lugares nao tinham unit tests, a maioria dos bugfixes eram gambis. Alguns projetos nao tinham nenhuma estrutura definida, check-ins a vontade, sem nenhuma qualidade, sem comentarios, sem reviews, sem nada.

Nao estou dizendo que eh regra. Ate porque eu tambem vi muito codigo bom e pessoas muito capacitadas trabalhando com Java, aqui no forum mesmo. Mas o que eu quero dizer eh que eh muito errada essa visao que o povo tem um projeto .NET eh tipo, ok, abro o meu Visual Studio, click e arrasto alguns controls para a minha pagina, ta rodando firmeza!

Talvez voce nao tenha entendido, mas o que eu quis dizer eh que eu nao acho que .NET eh mais produtivo que Java, mas pelo menos facilita um pouco a vida quando uma empresa disponibiliza tudo o que vc precisa, IDE, banco de dados, controle de versao, gerenciamento de projetos, frameworks diversos e tudo eh integrado e obedece um padrao, e o contrario que voce disse nao estamos “vendor locked in” porque tem muitos projetos open source disponiveis.

O mesmo eu nao sinto com Java, as vezes vc tem que confiar ate em projetos privados obscuros para desenvolvedor o seu projeto e pra fazer algo simples sao 4501 easy steps, configuracoes, erros, dor de cabeca, trocentas libs sem consistencia nenhuma, o que as vezes pode ser um impedimento para que o desenvolvimento ocorra de forma mais tranquila.

//Daniel

Os clientes estão satisfeitos ???

Preciso sair de onde estou hoje, pois o cenário que venho vivendo há uns 4 anos é completamente o oposto disso… O que vejo é sempre uma guerrinha entre “TI vs Cliente” onde a culpa sempre é do outro e ninguém está satisfeito.

Estou terminando um Post em meu blog sobre isso e gostaria de atualizar o status, pois até onde eu pensava, era a realidade do mercado

Nessas horas que vejo que estou no lugar errado.

Creio que a discussão está indo em um nível muito bom e cada opinião, achamos novidades…

Abs []

Repare que falei o cliente está satisfeito, e não os desenvolvedores da consultoria. Isso eu imaginei porque as consultorias continuam atuando no mercado, então os clientes estão voltando?

Os desenvolvedores concordo com você, pelo menos aqueles que valorizam sua profissão, quase sempre estarão infelizes num ambiente de consultoria, mas acho que isso é assunto pra outro tópico.

No que diz a produtividade, acho que o sergiotaborda tocou na raiz da questão quando falou que falta uma plataforma de aplicação no Java. Para o típico cliente de consultoria, que é averso à risco, isso faz muita falta.

Até porque, no fim o mais produtivo é aquele que consegue criar algo funcionando com janela, botões e tudo mais, não aquele que fica discutindo combinações de arquitetura/frameworks/padrões que não leva a lugar nenhum.

Os clientes estão satisfeitos ???

Preciso sair de onde estou hoje, pois o cenário que venho vivendo há uns 4 anos é completamente o oposto disso… O que vejo é sempre uma guerrinha entre “TI vs Cliente” onde a culpa sempre é do outro e ninguém está satisfeito.

Estou terminando um Post em meu blog sobre isso e gostaria de atualizar o status, pois até onde eu pensava, era a realidade do mercado

Nessas horas que vejo que estou no lugar errado.

Creio que a discussão está indo em um nível muito bom e cada opinião, achamos novidades…

Abs []

Repare que falei o cliente está satisfeito, e não os desenvolvedores da consultoria. Isso eu imaginei porque as consultorias continuam atuando no mercado, então os clientes estão voltando?

Os desenvolvedores concordo com você, pelo menos aqueles que valorizam sua profissão, quase sempre estarão infelizes num ambiente de consultoria, mas acho que isso é assunto pra outro tópico.

No que diz a produtividade, acho que o sergiotaborda tocou na raiz da questão quando falou que falta uma plataforma de aplicação no Java. Para o típico cliente de consultoria, que é averso à risco, isso faz muita falta.

Até porque, no fim o mais produtivo é aquele que consegue criar algo funcionando com janela, botões e tudo mais, não aquele que fica discutindo combinações de arquitetura/frameworks/padrões que não leva a lugar nenhum.

Não vejo problemas se criar algo que funcione com janela e botões… acho isso até muito valido… o problema começa quando isso PARA DE FUNCIONAR…
Em muitos desses casos, esse para de funcionar não existe. São casos que ferramentas como Maker e Genexus podem ser ótimas alternativas. Até o Access é alternativa.

As vezes as pessoas acham que uma tecnologia é improdutiva, mas não enxergam que na verdade estão matando moscas com bazuca!

Em relação a cultura .NET eu concordo com o Sergio. Não que não há bons desenvolvedores que trabalham com .NET. Pelo contrário, há excelentes… mas muita gente usa .NET para criar solução de má qualidade, graças a essa maravilhosa integração… e não que isso seja uma coisa ruim. Imagine se todo sistema de padaria precisasse ser criado com uma arquitetura ferrada e tals… tem fatia do mercado para esses “sisteminhas” sim! Só não adianta o pogramador achar que vai ganhar 10K por mês dessa forma!

Pior ainda quando se fala de PHP… se pegar 100 sistemas desenvolvidos em PHP, se apenas 1 deles utilizar OO, Classes, Arquitetura, etc… é muito… A maioria será um monte de script tosco misturado no código html… isso é ruim ??? Eu não acho… para quem tem esses sistemas, ou tem isso ou não teria nada!

Discordo da maioria dos seus argumentos. Primeiro de tudo, o maven não vem integrado no Java. O desenvolvedor já tem que começar aprendendo a usar o maven.
Depois, ele tem que saber o que são os milhares de pequenos pacotes e as opções que o maven dá.

Mesmo que ele baixe uma pacotaiada integrada, como no meu caso que estou usando Hibernate+Spring+JPA+GraniteDS, tem que conhecer à fundo onde cada peça desse enorme tabuleiro se encaixa. Há dezenas de XMLs para configurar, vários pequenos detalhes, construções obsoletas e equivalentes (como no caso do Hibernate e JPA), entre outras coisas que irão aparecer junto com as primeiras classes do projeto. Aí, começa também a fase de aprendizado, onde você começa a descobrir que limitações de um framework fazem com que a promessa de outros vão por água abaixo (por exemplo, o GraniteDS não suporta atributos em lazy-loading, o que limita o uso desse recurso lá no JPA).

Acho que não vale o argumento de “a culpa é do arquiteto” ou de que é “culpa do programador”. Esse é um argumento irracional, pois no final das contas, a culpa será sempre do arquiteto ou do programador. Esse tipo de argumento me lembra muito os fóruns de C++, quando o pessoal fala que ponteiros não tornam o programador C++ menos produtivo, pois os erros que eles trazem são culpa do programador…

Se estamos falando de frameworks e de produtividade, temos que entender o quanto ele facilita ou dificulta a vida de quem os usa. Ou seja, o quanto eles evitam os erros do programador, o quanto eles livram de burocracias e permitem que ele se foque nos problemas que realmente tem que resolver. Se estamos falando de produtividade, o questionamento é justamente nessa “uma facilidade a mais ou outra devido a alguma integração mais fácil com banco de dados ou coisa similar” que os frameworks fornecem.

No caso do .Net, acho que é mais fácil configurar um ambiente.

Na minha opinião as principais razões são:

• O .Net framework é mais novo, portanto há menos opções disponíveis. Isso tende a se reverter com o tempo. Por exemplo, hoje, você já pode escolher entre WebForms e MVC na camada de apresentação. Além disso, pode optar por usar ou não Razor. Amanhã ou depois, vão surgir ainda mais tecnologias e logo a sopa de letrinhas do .Net vai ficar tão complicada como a do Java;
• Como consequencia do fato de ser mais novo, a MS teve a oportunidade de criar uma pilha inicial já corrigindo falhas do Java, e integrando pontos problemáticos;
• A MS, ao realizar evolução tecnológica, pressiona os desenvolvedores a abandonarem as tecnologias antigas. As vezes até de forma um tanto agressiva (como o marcosalex gosta de ressaltar);
• Os produtos da MS são realmente muitíssimo bem integrados, confiáveis e o suporte da MS é muito bom.

Recursos que o C# tem a mais que o Java:

• Structs;
• Delegates
• Co-rotinas
• Properties
• Extension Methods
• Lambda (só vem no Java 8)
• Partial classes
• Sobrecarga de operadores
• Construtores implícitos
• LINQ
• Controle paralelo - que está entre os recursos mais espetaculares que já vi;
• Variáveis unsigned e de ponto-fixo;
• Visibilidade internal (publico no “.jar”, privado fora do .jar);

Alguns recursos no .C# também são melhores implementados:

• Generics não são um truque de compilação, e podem ser usados inclusive com tipos primitivos;
• Métodos unsafe, muito mais fáceis e seguros de usar que JNI;
• API de XML integrada ao LINQ;
• API de reflection com sintaxe muito mais simples e direta;

O .net não tem o recurso de Inner Class anônima, que é parcialmente suprido por lambdas e delegates.

Se você estiver no mercado de Desktop também vai notar que:

• O Swing é muito antiquado;
• Não há frameworks para aplicações gráficas como games;
• Há pouca integração com o SO, e JNI/JNA são trabalhosos comparados com os metodos unsafe;
• O Java delega ao usuário a responsabilidade de conhecer a VM;

Sobre o tema central da discussão.
.Net é mais produtivo que Java?

Creio que atualmente é, no mínimo, mais confortável programar em C# e .Net do que em Java.
Mas não ao ponto de isso significar uma vantagem decisória no projeto, ou uma redução muito significativa de custos.

O fato é que nunca é produtivo construir software robusto e de qualidade. Requisitos sempre mudam no meio do ciclo. Além disso, também compartilho da opinião do jmmenezes, onde não adianta tentar falar de produtividade “no geral”. Teríamos que especificar um tipo de situação e considerar algum tipo de know-how por parte das equipes sendo comparadas.

No caso de sistemas web, confesso que estou muito impressionado com a produtividade que tivemos com MVC + Razor. E, agora que estou programando lado-a-lado um sistema .Net e um Java, percebo que o Java se tornou muito burocrático durante os anos. Entretanto, no caso do .Net, sei que muita da integração veio do fato de termos praticamente toda infra Microsoft…

No mais, concordo muito com a opinião que o windsofhell colocou até agora. Esse história de programador MS ser programador Drag&Drop já foi verdade no passado, mas se torna menos verdade a cada ano. A MS tem estimulado muito os desenvolvedores a estudar padrões, os frameworks mais novos tem um novo grau de maturidade e há bons desenvolvedores na comunidade puxando o profissional para cima, como é o caso do Elemar Júnior.

Claro, ainda há mais desenvolvedores que abusam do Drag&Drop, assim como em Java tem o extremo oposto. Quem nunca parou aqui num projeto feito por um desenvolvedor que saiu encapsulando, generalizando e invertendo todas as dependências do projeto, criando centenas de camadas, só porque leu em algum lugar sobre IoC e MVC?

Quanta dessa burocracia se deve ao fato de não existir investimento em plataformas de aplicação nas empresas , sejam elas software houses ou que produzem in house ?

Para mim, a microsoft sempre teve esta filosofia de RAD (rapid application development) que vem desde do VB. E isso só se consegue com uma plataforma de aplicação.
A qual a MS integra no produto. Não N forma de acessar banco ou fazer telas. Ha 1 e pronto. No máxmo duas e vai-que-vai. Como vc falou a simplificação é grande. Não ao contrário do que falou, o .net não tem menos opções porque é novo, é porque design. Ele é feito para ter poucas opções que são usadas exaustivamente. novas coisas nascem quando o básico não dá conta ( o novo MVC é diferente de formas como o Spring MVC é diferente do JSF ou do Vaadin. Tratam nichos diferentes de aplicações. fazer e-comerce apenas com JSF é tão ruim quanto fazer com ASP.net não mvc)

O fato de ter sido verdade em algum momento é o ponto do argumento, porque demonstra que é possivel. É da escolha do profissional usar ou não, mas quando não é possivel, não se usa. Embora o netbeans tente seguir a filosofia RAD (afinal é o competidor do Visual Studio. O Eclipse não compete com o VS) o programador java não é ensinado dessa forma. A estrutrua mental do desenvolvedor java nasce longe do Drag&Drop, a do .net nasce perto e se afasta conforme a senioridade do dev. O junior que não faz drag&drop é porque tem um compreensão grande do que faz ou foi ensinado por alguém que sabia. Qantas pessoas saem assim dos cursos de formação ? vs quantas pessoas saem não usando drag&drop dos cursos de java ?

Sim, todo o mundo pode fazer asneiras. O ponto é que com menos facilidade, é menos provável fazer asneiras. Enão, java é mais seguro, nesse sentido, e por consequencia menos produtivo. Não dá para catar um cara aleatoriamente na rua e por para fazer tela swing (sem ide) mas dá para fazer isso com .NET e muitos fazem. Sim, sabemos que não são vocês que fazem, mas ha muitos que fazem.

Em java é mais dificil programar por coincidencia. É possivel, mas mais dificil. Em .net é mais fácil, e por isso a sensação que é mais produtivo, que é mais rápido, que se observam as telas funcionando em menos tempo.

Sim, a MS vem vindo a melhorar nesse aspeto (inclusive contratando pessoas da ex Sun, como o Joshua Bloch - não é por acaso que C#4 o LINQ existem). Mas esta melhoria é apenas uma tentativa de nivelar o mercado. Porque quando o cara faz gamb com o .net a MS leva por tabela porque o dev vai culpar a plataforma.

Não se nega que existam profissionais que sabem usar o .net como é suposto. O ponto é que é possivel que pessoas não preparadas também o usem -de formas alternativas - e mesmo assim produzam software funcional. O RAD atrai muita gente, inclusive as pessoas da gerencia e diretoria que não sabem pensar sem ver uma tela. O RAD existe em ferramentas como Rails (os varios sabores) mas isso é para web. (O Maker e outros da mesma laia prometem este mesmo RAD, ainda mais rápido às vezes. Os gerentes compram esta ideia ). O .net consegue o mesmo para desktop. Hoje existem algumas iniciativas para conseguir o RAD em java para desktop - aqui apenas acontece que o parque de aplicações desktop em java é ainda pequeno.
Sendo mais dificil em java começar do zero sem saber o que se está fazendo forçando a um setup de ambiente que no .net já vem integrado ( embora seja possivel conseguir o mesmo em java, é mais complexo e na prática ninguém cria um CD de instalação que monta eclipse, svn, sdk, etc… num golpe só) o java parece menos produtivo. E se vc tem um projeto para entregar em duas semans com 20 telas é muito provavel que não use java (a menos que já tenha um plataforma de aplicação pronta em java)
Esta facilidade inicial dá uma uma maior produtividade na fase inicial do projeto. A incepção é mais rápida e é possivel visualizar as coisas em menos tempos. Isto é uma forma de produtividade onde o .net ganha. Não porque apenas é possivel nele, mas porque já vem pronto nele. Em java tb é possivel, mas não vem pronto.

Dai para a frente a produtividade é a mesma. Ou seja, quando no projeto java as coisas estão encaixadas e vc simplesmente sai usando a “infra” (que é na realidade a plataforma de aplicação) ai vc está competindo de igual para igual. A produtividade neste nível é a mesma.

Depois vem a produtividade que é ganha pela suporte de deploy. Em java existem várias opções, todas semelhantes em conceito ao mundo .net (embora o .net não tenha um servidor de aplicação compativel com CORBA). À parte da diferença obvia de que java 'deploya" em muitos OS, os padrões EE também desacoplam a implementação do ambiente de execução. Por isto ha um overhead de configuração. Mas se vc usar produtos pagos vc terá a mesma facilidade que com o .net.
Neste nivel a produtividade é a mesma se compararmos produtos pagos. Se comparamos produtos free, acho que sempre haverá alguma configuração e alguma limitação, mas em geral, java tem uma ligeira vantagem por ser multiplataforma. Mas é muito pouca a diferença.

Portanto, olhando as 3 maiores fases de projeto (concepção, desenvolvimento e manutenção) em geral o .NET é realmente mais produtivo. Não pela linguagems, não pelos LINQ da vida , mas pelo empacotamento padrão que é dado à priori e pela IDE. Se em todas as aplicações java vc simplesmente importasse uma lib com tudo lá dentro seria tão ou mais rápido que o .net padrão. ( algums ambientes java fazem isto como o Spring Roo, o Grails e o Vaadin, mas não são padrão)

Acho que isso não tem nada a ver não, Sérgio. O netbeans funciona da mesma maneira que o visual studio. Isso é um mito que vem sendo difundido desde a era do delphi. O “Zé da esquina colocou na cabeça que é fácil escrever software usando object pascal porque a sua ide é simples e muito produtiva”. Acho que esse ítem se enquadra mais que pensar “desenvolvedores x fazem drag & drop”.

Essa questão de quem usava delphi só sabia montar janela era uma mentira danada que apareceu porque muita gente incompetente se meteu a analista de sistema e programador. Conheço uma equipe toda que usa dotnet e não se enquadra nesse perfil.

juliocbq:

Acho que isso não tem nada a ver não, Sérgio. O netbeans funciona da mesma maneira que o visual studio. Isso é um mito que vem sendo difundido desde a era do delphi. O “Zé da esquina colocou na cabeça que é fácil escrever software usando object pascal porque a sua ide é simples e muito produtiva”. Acho que esse ítem se enquadra mais que pensar “desenvolvedores x fazem drag & drop”.

Essa questão de quem usava delphi só sabia montar janela era uma mentira danada que apareceu porque muita gente incompetente se meteu a analista de sistema e programador. Conheço uma equipe toda que usa dotnet e não se enquadra nesse perfil.

Não estou dizendo que não. Não estou pondo todo o mundo no mesmo saco. Estou apenas dizendo que é porque alguns fazem isso (ou fizeram, não importa o tempo) a plataforma ganhou espaço como ferramenta RAD. O ponto é que existe esse perfil. E não quem se enquadra nele. Em java esse perfil não existe. E nunca existiu.
E esta diferença advem da cultura , da filosofia subjacente às plataformas.

Vejamos de outra maneira. Quantas pessoas em java sabem programar sem usar ide, só no sdk ? Muitas ? poucas ? A maioria ou a minoria ?
E em .net ? É possivel programar sem o IDE ? e se sim, é igual de produtivo que o java ? Deve ser , certo ? afinal é um monte de arquivos e um compilador.

O ponto é que em java as pessoas são instruidas as começar sem IDE. Aqui mesmo no guj essa máxima é vinculada. Em .net ?

Portanto podemos dizer que é uma questão de guerra de IDE e não das plataformas em si. Pois a linguagem é irrelevante - como já foi apontado - o design de OO é irrelevante - cada um faz o seu bem ou mal e a API em si é praticamente a mesma. Então o que sobra ? A IDE. .NET vem com IDE, java não. Isto causa diferença na hora de começar um projeto ? Para mim não. Eu uso o eclipse ha anos e sei configurá-lo para a minha produtividade. Mas em uma equipe só a configuração do ecplise pode levantar várias vagas de discussão. porquê ? Porque ha muitas opções. É flexivel de mais. Em .net vc instala e já é.
Para java também ha muitas ferramentas produtivas, mais até que o .net como a familia Grails, o Play o Spring Roo. Mas são ferramentas. Vendor lock-in.Não é portável.
Isto indica que quantas menos opções , quanto menos fexibilidade, quanto mais padronização e foco, mais produtividade.

O meu ponto é que .net sim é mais produtivo porque ele entrega um nivel diferente que o java não entrega e vc é obrigado a fazer em todos os projetos. Essa é a diferença. todos os frameworks que existem em java servem para preencher esta lacuna. E quando vc usa um framework, a produtividade fica igual. O ponto é que o tempo que o cara de java gastou para criar ou configurar o framework, o cara do .net já tem as telas feitas, navegáveis e demonstráveis.

sergiotaborda:

juliocbq:

Acho que isso não tem nada a ver não, Sérgio. O netbeans funciona da mesma maneira que o visual studio. Isso é um mito que vem sendo difundido desde a era do delphi. O “Zé da esquina colocou na cabeça que é fácil escrever software usando object pascal porque a sua ide é simples e muito produtiva”. Acho que esse ítem se enquadra mais que pensar “desenvolvedores x fazem drag & drop”.

Essa questão de quem usava delphi só sabia montar janela era uma mentira danada que apareceu porque muita gente incompetente se meteu a analista de sistema e programador. Conheço uma equipe toda que usa dotnet e não se enquadra nesse perfil.

Não estou dizendo que não. Não estou pondo todo o mundo no mesmo saco. Estou apenas dizendo que é porque alguns fazem isso (ou fizeram, não importa o tempo) a plataforma ganhou espaço como ferramenta RAD. O ponto é que existe esse perfil. E não quem se enquadra nele. Em java esse perfil não existe. E nunca existiu.
E esta diferença advem da cultura , da filosofia subjacente às plataformas.

Vejamos de outra maneira. Quantas pessoas em java sabem programar sem usar ide, só no sdk ? Muitas ? poucas ? A maioria ou a minoria ?
E em .net ? É possivel programar sem o IDE ? e se sim, é igual de produtivo que o java ? Deve ser , certo ? afinal é um monte de arquivos e um compilador.

O ponto é que em java as pessoas são instruidas as começar sem IDE. Aqui mesmo no guj essa máxima é vinculada. Em .net ?

Portanto podemos dizer que é uma questão de guerra de IDE e não das plataformas em si. Pois a linguagem é irrelevante - como já foi apontado - o design de OO é irrelevante - cada um faz o seu bem ou mal e a API em si é praticamente a mesma. Então o que sobra ? A IDE. .NET vem com IDE, java não. Isto causa diferença na hora de começar um projeto ? Para mim não. Eu uso o eclipse ha anos e sei configurá-lo para a minha produtividade. Mas em uma equipe só a configuração do ecplise pode levantar várias vagas de discussão. porquê ? Porque ha muitas opções. É flexivel de mais. Em .net vc instala e já é.
Para java também ha muitas ferramentas produtivas, mais até que o .net como a familia Grails, o Play o Spring Roo. Mas são ferramentas. Vendor lock-in.Não é portável.
Isto indica que quantas menos opções , quanto menos fexibilidade, quanto mais padronização e foco, mais produtividade.

O meu ponto é que .net sim é mais produtivo porque ele entrega um nivel diferente que o java não entrega e vc é obrigado a fazer em todos os projetos. Essa é a diferença. todos os frameworks que existem em java servem para preencher esta lacuna. E quando vc usa um framework, a produtividade fica igual. O ponto é que o tempo que o cara de java gastou para criar ou configurar o framework, o cara do .net já tem as telas feitas, navegáveis e demonstráveis.

Mas as telas construídas sendo com o netbeans ou o visual studio possuem a mesma complexidade. A microsoft só te entrega uma gama maior de ferramentas de produtividade, mas isso em questão não tem muita importância se forem usadas sozinhas, já que existem mais parâmetros que devem ser somados, como os “frameworks” que você citou.

Sobre “dummys”, eles estão por toda a parte. O drag & drop é uma realidade java, .net, c++(com visual studio, c++ builder, qtcreator…), pascal(delphi e lazarus). Não uma exclusividade de algumas.

Galera sem querer ser muito chato, mas se utilizar as ferramentas e recursos como argumento sobre produtividade iremos sempre falar das mesmas coisas que são ditas a + OU - 25 atrás. :shock:

Na época o centro das atenções eram Cobol, Basic x Clipper x C x Pascal - a discussão era exatamente A MESMA.

A MS sempre priorizou a facilidade e teve como principal alvo usuários leigos ou menos qualificados, ela se fez em cima desta estratégia; funcionou e funciona muito bem - não é demérito, ao contrario, percebendo a carência no setor ela soube e ainda sabe investir de forma certeira.

Quem construiu JAVA possui (ou ao menos possuía) outro conceito de facilidade / produtividade, bem diferente da MS.

flws

Tópico de altíssimo nível técnico! Parabéns a todos os debatedores!

Você esqueceu o primeiro framework action-based em Java full-stack => http://www.mentaframework.org

Acho que antes dele só tinha o Rife, mas esse é component-based.

Tirando isso não vejo muita relevância nesse tópico. As linguagens são extremamente parecidas, tanto na arquitetura quanto na sintaxe. Logo essa discussão só faz algum sentido se vc pegar dois times ou duas pessoas que nunca viram nenhuma das duas. Caso contrário me parece óbvio que quem tem experiência com .NET vai achar ela mais produtiva e quem tem experiência com Java vai achar Java mais produtivo.

Eu acho a linguagem Java um pouco mais simples que .NET. .NET te dá um pouco mais de poder o que pode complicar as coisas. Java é uma das linguagens mais simples que existem.

Por as linguagens serem muito parecidas, essa discussão é pointless, assim como se eu te perguntar quem é mais produtivo: Ruby ou Python?

Vc sentitizou bem. É isso ai mesmo.

Concordo com o fato de que a produtividade esta mais relacionada com o conhecimento do individuo sobre a linguagem/plataforma do que a linguagem/plataforma em si.

Apesar de .NET não ser feito somente de drag and drop e ter muitos recursos ótimos que são bem aproveitados por quem está preocupado com implementar uma arquitetura decente, a propaganda não é em cima desses recursos. Voce quase nao ouve “ah, partial eh legal, linq eh show, delegates eh massa” da maioria dos que dizem que .NET é mais produtivo.

Normalmente a propaganda é: “Nossa, .NET é muito melhor, voce tem tudo integrado, arrasta e já está pronto. Em alguns minutos voce já tem tudo funcionando.” Isso é ilusório, ou é real para aplicações pequenas. Esse pensamento para aplicações maiores é suicídio.

YvGa:

saoj:

… As linguagens são extremamente parecidas, tanto na arquitetura quanto na sintaxe. Logo essa discussão só faz algum sentido se vc pegar dois times ou duas pessoas que nunca viram nenhuma das duas. Caso contrário me parece óbvio que quem tem experiência com .NET vai achar ela mais produtiva e quem tem experiência com Java vai achar Java mais produtivo.

Eu acho a linguagem Java um pouco mais simples que .NET. .NET te dá um pouco mais de poder o que pode complicar as coisas. Java é uma das linguagens mais simples que existem.

Por as linguagens serem muito parecidas, essa discussão é pointless, assim como se eu te perguntar quem é mais produtivo: Ruby ou Python?

Concordo com o fato de que a produtividade esta mais relacionada com o conhecimento do individuo sobre a linguagem/plataforma do que a linguagem/plataforma em si.

Apesar de .NET não ser feito somente de drag and drop e ter muitos recursos ótimos que são bem aproveitados por quem está preocupado com implementar uma arquitetura decente, a propaganda não é em cima desses recursos. Voce quase nao ouve “ah, partial eh legal, linq eh show, delegates eh massa” da maioria dos que dizem que .NET é mais produtivo.

Normalmente a propaganda é: “Nossa, .NET é muito melhor, voce tem tudo integrado, arrasta e já está pronto. Em alguns minutos voce já tem tudo funcionando.” Isso é ilusório, ou é real para aplicações pequenas. Esse pensamento para aplicações maiores é suicídio.

Apesar de eu trabalhar com java nunca vi a microsoft vender suas soluções com esse argumento. Onde você leu isso?

juliocbq:

Apesar de eu trabalhar com java nunca vi a microsoft vender suas soluções com esse argumento. Onde você leu isso?

Nao eh da microsoft que normalmente eu ouço, mas da maioria dos desenvolvedores que dizem que .NET é mais produtivo.

Mas voce tem certeza que nunca ouviu a MS falar das suas maravilhas todas integradas?

YvGa:

Concordo com o fato de que a produtividade esta mais relacionada com o conhecimento do individuo sobre a linguagem/plataforma do que a linguagem/plataforma em si.

Apesar de .NET não ser feito somente de drag and drop e ter muitos recursos ótimos que são bem aproveitados por quem está preocupado com implementar uma arquitetura decente, a propaganda não é em cima desses recursos. Voce quase nao ouve “ah, partial eh legal, linq eh show, delegates eh massa” da maioria dos que dizem que .NET é mais produtivo.

Normalmente a propaganda é: “Nossa, .NET é muito melhor, voce tem tudo integrado, arrasta e já está pronto. Em alguns minutos voce já tem tudo funcionando.” Isso é ilusório, ou é real para aplicações pequenas. Esse pensamento para aplicações maiores é suicídio.

Bom saber que você despreza ferramentas visuais e programa tudo no Emacs. Mas falta de usabilidade do Java não a torna ideal para “sistemas de verdade”.

Esse É sim um grande calcanhar de aquiles do Java, não ter uma empresa por detrás investindo em uma ferramenta visual de verdade, com coisas do tipo drag and drop e outros recursos visuais sim, que quer você ou não, ajuda na produtividade do desenvolvedor.

Os clientes estão satisfeitos ???

Preciso sair de onde estou hoje, pois o cenário que venho vivendo há uns 4 anos é completamente o oposto disso… O que vejo é sempre uma guerrinha entre “TI vs Cliente” onde a culpa sempre é do outro e ninguém está satisfeito.

Estou terminando um Post em meu blog sobre isso e gostaria de atualizar o status, pois até onde eu pensava, era a realidade do mercado

Nessas horas que vejo que estou no lugar errado.

Creio que a discussão está indo em um nível muito bom e cada opinião, achamos novidades…

Abs []

Repare que falei o cliente está satisfeito, e não os desenvolvedores da consultoria. Isso eu imaginei porque as consultorias continuam atuando no mercado, então os clientes estão voltando?

Os desenvolvedores concordo com você, pelo menos aqueles que valorizam sua profissão, quase sempre estarão infelizes num ambiente de consultoria, mas acho que isso é assunto pra outro tópico.

E eu também estou falando de clientes… Eu lido com clientes desde meu primeiro emprego… Graças a Deus, nunca participei de fábrica a ponto de ficar isolado dos negócios sendo code monkey… Sempre trabalhei também, analisando problemas e buscando soluções. Acredite, também conheço o lado dos clientes e dos 15 - 20 mais diretos que já trabalhei, posso dizer que mais de 70% não está NEM UM POUCO satisfeito, o resto está apenas dando pro gasto. Tente mudar esse panorama… Simplesmente não dá, porque você, dev, ou esbarra no comercial, ou no Big “GERENTE”, que quer tudo pra ontem.

JoseIgnacio:

Até porque, no fim o mais produtivo é aquele que consegue criar algo funcionando com janela, botões e tudo mais, não aquele que fica discutindo combinações de arquitetura/frameworks/padrões que não leva a lugar nenhum.

Entendo seu ponto de vista e tenhos muitos conhecidos que o tem também, mas não concordo, principalmente quando o tema foco é Produtividade.

Abs []

YvGa:

juliocbq:

Apesar de eu trabalhar com java nunca vi a microsoft vender suas soluções com esse argumento. Onde você leu isso?

Nao eh da microsoft que normalmente eu ouço, mas da maioria dos desenvolvedores que dizem que .NET é mais produtivo.

Mas voce tem certeza que nunca ouviu a MS falar das suas maravilhas todas integradas?

Onde eu mais leio sobre essa questão de drag & drop é em fóruns. E dizem a mesma coisa sobre java, .net e delphi. É o que eu quis dizer mais acima, são “dummys” que dizem isso.

Que dê a entender sobre ser somente arrastar e colar da mídia da microsoft nunca, só em fóruns onde algumas pessoas dizem. Por isso eu não generalizo esse tipo de coisa.

Bem, apenas estou estudando e ainda não trabalho na área de desenvolvimento de sistemas, mas eu acho que, na verdade, a grande resposta para definir, cientificamente, os principais pontos de cada linguagem estará no estudo de baixo nível, ou seja, como cada recurso de determinada linguagem se comporta em situações peculiares de desenvolvimento, inclusive no que tange ao hardware…acho que, também, seria de grande valia dar uma estudada na área de Qualidade de Software…pois, não acredito que, analisando as linguagens em alto nível, chegaremos à real diferença.

Se voce esta falando de desktop pode ser, realmente ficar criando controles e posicionando tudo na mão toma muito tempo. Mas para web não vejo vantagem. Com um pouco de estudo em css e html voce consegue prototipar tão rapido quanto qualquer drag and drop.

É sobre esse tipo de afirmação que eu falo, drag and drops, sempre eles. E se eu não gosto deles (coisa que não disse) já se supoe que eu gosto de programar em bloco de notas. Um IDE é muito, muito mais que drag and drop. Trabalho ha anos com java para web e só senti falta desse recurso enquanto não tinha dedicado tempo a estudar javascript, html e css.

Desktop é outra historia.

É por esse tipo de pensamento que nós temos esses monstros monoliticos para dar manutenção hoje em dia. Seja lé em java, c#, php, delphi etc… Há uma preocupação com produtividade, sem medir produtividade de nada. A maior parte do tempo que se perde construindo uma aplicação grande é na definição e implementação das regras dessa aplicação.

Mas o que normalmente é feito? Já escolhem a tecnologia porque tem drag and drop e binding de componente. Ajuda? Em muitos casos sim, mas é só a ponta do iceberg. Então depois disso definido, e garantido que a equipe, que há anos não estuda nada de novo, vai ter uma curva de aprendizado suave o projeto começa. Protótipo, telinha pronta aqui, telinha pronta lá e tudo uma maravilha.

Porém antes, e muito antes, da aplicação entrar em produção começa o inferno da manutenção. Cada mudança de requisito é um parto, cada alteração gera um caminhão de bugs, isso sem usuário real usando ainda. E dá-lhe programador passando o dia inteiro olhando valor de variável no debug pra descobrir porque cada vez que ele altera uma coisa outra para de funcionar. E quando finalmente o negócio vai pra produção, se é que vai, o inferno toma conta de vez. E isso tudo muitas vezes sem precisar sequer por a mão naquela tela maravilhosa feita com drag and drop que garante a superprodutividade da equipe.

E vem gente dizer que ferramenta visual é o calcanhar de aquiles do java. Se o problema fosse esse tava tudo resolvido, faz-se tudo com ferramentas visuais, os projetos não atrasam, os clientes ficam satisfeitos, os prazos são cumpridos e o java morre.

Mas não é isso que se ve, nem em .Net, nem em Java, nem em Delphi, nem nada disso. O que se vê são projetos atrasados, clientes irritados, gerentes malucos e programadores insatisfeitos. Ora? no java isso é normal pois não tem “ferramentas visuais”. Mas em .Net e Delphi? Como? Se tem ferramentas visuais espetaculares e programadores que não perdem tempo com telinhas bobas?

.

juliocbq:

YvGa:

juliocbq:

Apesar de eu trabalhar com java nunca vi a microsoft vender suas soluções com esse argumento. Onde você leu isso?

Nao eh da microsoft que normalmente eu ouço, mas da maioria dos desenvolvedores que dizem que .NET é mais produtivo.

Mas voce tem certeza que nunca ouviu a MS falar das suas maravilhas todas integradas?

Onde eu mais leio sobre essa questão de drag & drop é em fóruns. E dizem a mesma coisa sobre java, .net e delphi. É o que eu quis dizer mais acima, são “dummys” que dizem isso.

Que dê a entender sobre ser somente arrastar e colar da mídia da microsoft nunca, só em fóruns onde algumas pessoas dizem. Por isso eu não generalizo esse tipo de coisa.

Sim, como eu mesmo disse, a maioria dessas opiniões vem de desenvolvedores.

O .NET não tem tando Drag n’ Drop como dizem e é até mais produtivo trabalhar sem isso na parte Web.

A sacada do .NET é que ele disponibiliza alguns componentes que seguem a mesma filosofia do VB6 (DataView, DataTable e etc), além de dar a opção de trabalhar mais próximo de obejtos (mais semelhante a forma que trabalhamos em Java), por ter essas opções, é mais fácil de aprender, já que trabalhar com um componente muitas vezes abstraí o trabalho de uma modelagem mais elaborada.

Eu diria que Java é mais produtivo para aplicações corporativas web, acho o JSF superior ao WebForms, e as soluções MVC que Java tem equivalem ao MVC3, nunca vi nada parecido com o GWT para .NET (se tiver, gostaria que me apresentassem). Para Desktop, o .NET está realmente anos luz a frente do Swing, porém não é multiplataforma (o Mono é incompleto e tem problemas de performance) e isso pode ser um problema.

Eu diria que as plataformas são equivalentes, é meio do gosto de cada programador e dos requisitos do projeto que será desenvolvido.

Nas minhas soluções escolho Java, escolho Java por ser melhor na parte que importa para os meus projetos, que geralmente são web e voltados ao negócio em si.

Acho que nem isso é vantagem, porque no caso da web esses tookits que a MS disponibiliza não são cross-browser e no fim você vai acabar apelando para um JQuery ou Extjs.

Olha aqui um sinal de que a filosofia da programação em ambiente Microsoft mudou: o tutorial oficial de C# é todo baseado em editor de texto e compilação por linha de comando.

YvGa:

Se voce esta falando de desktop pode ser, realmente ficar criando controles e posicionando tudo na mão toma muito tempo. Mas para web não vejo vantagem. Com um pouco de estudo em css e html voce consegue prototipar tão rapido quanto qualquer drag and drop.

É sobre esse tipo de afirmação que eu falo, drag and drops, sempre eles. E se eu não gosto deles (coisa que não disse) já se supoe que eu gosto de programar em bloco de notas. Um IDE é muito, muito mais que drag and drop. Trabalho ha anos com java para web e só senti falta desse recurso enquanto não tinha dedicado tempo a estudar javascript, html e css.

Desktop é outra historia.

É por esse tipo de pensamento que nós temos esses monstros monoliticos para dar manutenção hoje em dia. Seja lé em java, c#, php, delphi etc… Há uma preocupação com produtividade, sem medir produtividade de nada. A maior parte do tempo que se perde construindo uma aplicação grande é na definição e implementação das regras dessa aplicação.

Mas o que normalmente é feito? Já escolhem a tecnologia porque tem drag and drop e binding de componente. Ajuda? Em muitos casos sim, mas é só a ponta do iceberg. Então depois disso definido, e garantido que a equipe, que há anos não estuda nada de novo, vai ter uma curva de aprendizado suave o projeto começa. Protótipo, telinha pronta aqui, telinha pronta lá e tudo uma maravilha.

Porém antes, e muito antes, da aplicação entrar em produção começa o inferno da manutenção. Cada mudança de requisito é um parto, cada alteração gera um caminhão de bugs, isso sem usuário real usando ainda. E dá-lhe programador passando o dia inteiro olhando valor de variável no debug pra descobrir porque cada vez que ele altera uma coisa outra para de funcionar. E quando finalmente o negócio vai pra produção, se é que vai, o inferno toma conta de vez. E isso tudo muitas vezes sem precisar sequer por a mão naquela tela maravilhosa feita com drag and drop que garante a superprodutividade da equipe.

E vem gente dizer que ferramenta visual é o calcanhar de aquiles do java. Se o problema fosse esse tava tudo resolvido, faz-se tudo com ferramentas visuais, os projetos não atrasam, os clientes ficam satisfeitos, os prazos são cumpridos e o java morre.

Mas não é isso que se ve, nem em .Net, nem em Java, nem em Delphi, nem nada disso. O que se vê são projetos atrasados, clientes irritados, gerentes malucos e programadores insatisfeitos. Ora? no java isso é normal pois não tem “ferramentas visuais”. Mas em .Net e Delphi? Como? Se tem ferramentas visuais espetaculares e programadores que não perdem tempo com telinhas bobas?

Não é responsabilidade do programador definir regras, isso é papel do analista. O programador precisa implementar, ou seja, só a ponta do iceberg mesmo.

Se o resultado vai ser um sistema monolítico vai depender da habilidade do programador em implementar boas interfaces.

Isso é bobagem, e das velhas … o mundo seria um lugar melhor se os programadores fossem envolvidos com os clientes desde os primeiros estágios do projeto. A não ser é claro, que você esteja falando de analistas de negócios, que é uma responsabilidade completamente diferente do desenhador de UML. De qualquer maneira, programadores também tem responsabilidades sobre requisitos sim. E se o processo da empresa exige que existam analistas no meio do caminho, ele tem que ter no mínimo desconfiômetro para questionar.

gomesrod:

Olha aqui um sinal de que a filosofia da programação em ambiente Microsoft mudou: o tutorial oficial de C# é todo baseado em editor de texto e compilação por linha de comando.

http://msdn.microsoft.com/en-us/library/aa288436(v=vs.71).aspx

Este tutorial é da versão do Visual Studio .NET 2003, versão 1.1 do Framework.

Acho que nem isso é vantagem, porque no caso da web esses tookits que a MS disponibiliza não são cross-browser e no fim você vai acabar apelando para um JQuery ou Extjs.

Quem disse que não? Usei WebForms em um dos projetos e os componentes funcionaram perfeitamente em diversos navegadores.
A maioria gerava HTML puro, e relativamente simples.

Entretanto, é também um erro achar que a MS recomenda WebForms para grandes desenvolvimentos. Esse não é o foco do WebForms.
Se você quiser fazer um desenvolvimento maior, a solução recomendada é mesmo Razor + MVC.

JoseIgnacio:

Não é responsabilidade do programador definir regras, isso é papel do analista. O programador precisa implementar, ou seja, só a ponta do iceberg mesmo.

Se o resultado vai ser um sistema monolítico vai depender da habilidade do programador em implementar boas interfaces.

Esse post veio de 1990… como algo tão antigo veio parar aqui?

rmendes08:

Isso é bobagem, e das velhas … o mundo seria um lugar melhor se os programadores fossem envolvidos com os clientes desde os primeiros estágios do projeto. A não ser é claro, que você esteja falando de analistas de negócios, que é uma responsabilidade completamente diferente do desenhador de UML. De qualquer maneira, programadores também tem responsabilidades sobre requisitos sim. E se o processo da empresa exige que existam analistas no meio do caminho, ele tem que ter no mínimo desconfiômetro para questionar.

Estou falando como funciona em todas as consultorias. O analista de sistemas é que define o que precisa ser implementado.

Agora se vai tornar o mundo melhor não sei, não acho que esse seja o objetivo de nenhuma consultoria.

1990 tinha nem Gopher, quanto mais WWW.

ViniGodoy:

Esse post veio de 1990…

Assim como Java e OO. Qual seu ponto mesmo?

ViniGodoy:

como algo tão antigo veio parar aqui?

Sinceramente, não sei porque o seu post veio parar aqui, já que ele não acrescenta em nada a discussão.

Acho que nem isso é vantagem, porque no caso da web esses tookits que a MS disponibiliza não são cross-browser e no fim você vai acabar apelando para um JQuery ou Extjs.

Você vai ter que apelar pra jquery de qualquer maneira se precisar construir uma interface não trivial usando HTML e Javascript.

A não ser que você queira esperar pelo Javafx ficar pronto algum dia… ai vai poder dizer que usou Java.

Como faz uma animação gráfica usando JSF ou GWT?

JoseIgnacio:

rmendes08:

Isso é bobagem, e das velhas … o mundo seria um lugar melhor se os programadores fossem envolvidos com os clientes desde os primeiros estágios do projeto. A não ser é claro, que você esteja falando de analistas de negócios, que é uma responsabilidade completamente diferente do desenhador de UML. De qualquer maneira, programadores também tem responsabilidades sobre requisitos sim. E se o processo da empresa exige que existam analistas no meio do caminho, ele tem que ter no mínimo desconfiômetro para questionar.

Estou falando como funciona em todas as consultorias. O analista de sistemas é que define o que precisa ser implementado.

Agora se vai tornar o mundo melhor não sei, não acho que esse seja o objetivo de nenhuma consultoria.

Problema delas se querem pagar para alguem inutil, atravessando informação. Analista de sistemas que não programa é uma aberração que só TI é capaz de gerar.

E quem paga a conta são os clientes que ainda não aprenderam a contratar software.

Mas uma hora eles aprendem. E aí o que vai ter de pseudo-analista em fila de seguro desemprego não vai ser brincadeira.

Pelo menos nos casos das consultorias, acho que analistas estarão bem e o mais provável é que programadores sejam substituídos por ferramentas visuais.

Imagino algo com uma proposta tipo Rails, só que para analistas. O dia que inventarem isso vai bombar no mercado.

Como não? Estou criticando o que você falou. Eu conheço muitas empresas que já trabalham com agile, onde analista e programador tem ocupado exatamente o mesmo papel.

Eu, particularmente, considero a visão de que analista projeta e programador trabalha completamente obsoleta. Como o Yvga falou, analista que não programa é uma aberração. Essa visão também cria uma noção de hierarquia entre os dois cargos, como se o analista fosse chefe do programador. Logos vemos rixas idiotas entre analista e programador na empresa, gastando tempo e desperdiçando dinheiro do cliente. Sem falar, claro, na tonelada de documentação inútil, feita para apontar o dedo para o programador e dizer “eu não errei, foi você, está escrito aqui”, ou para apontar para o cliente e dizer “mas você assinou…”

Creio que hoje essas atividades sejam papéis durante o desenvolvimento, não um cargo.
Nem mesmo os processos menos iterativos, como o RUP, admitem hoje um analista que só analisa.

Mas nada disso tem a ver com a produtividade do java versus .net, só com produtividade em geral.

JoseIgnacio:

YvGa:

Problema delas se querem pagar para alguem inutil, atravessando informação. Analista de sistemas que não programa é uma aberração que só TI é capaz de gerar.

E quem paga a conta são os clientes que ainda não aprenderam a contratar software.

Mas uma hora eles aprendem. E aí o que vai ter de pseudo-analista em fila de seguro desemprego não vai ser brincadeira.

Pelo menos nos casos das consultorias, acho que analistas estarão bem e o mais provável é que programadores sejam substituídos por ferramentas visuais.

Imagino algo com uma proposta tipo Rails, só que para analistas. O dia que inventarem isso vai bombar no mercado.

Já inventaram isso, se chama Maker.

Sinceramente, eu não acho que os clientes sejam enganados pelas consultorias no desenvolvimento de SW.

Eu acho que se as coisas são assim é porque estão ganhando dinheiro desta forma, quando não estiverem mais outra irá surgir, desde que se ganhe mais dinheiro.

As consultorias tem uma margem de lucro altissima, algumas de mais de 50%, isso de lucro.

Bom, mas sem fugir do tópico eu acho que um ótimo desenvolvedor hoje não pode ser chamado como tal se não tiver um conhecimento bem grande do negócio em que está envolvido.

Não acredito em interpretadores de UML e geradores de código mais…

abs

ViniGodoy:

Como não? Estou criticando o que você falou. Eu conheço muitas empresas que já trabalham com agile, onde analista e programador tem ocupado exatamente o mesmo papel.

Eu, particularmente, considero a visão de que analista projeta e programador trabalha completamente obsoleta. Como o Yvga falou, analista que não programa é uma aberração. Essa visão também cria uma noção de hierarquia entre os dois cargos, como se o analista fosse chefe do programador. Logos vemos rixas idiotas entre analista e programador na empresa, gastando tempo e desperdiçando dinheiro do cliente. Sem falar, claro, na tonelada de documentação inútil, feita para apontar o dedo para o programador e dizer “eu não errei, foi você, está escrito aqui”, ou para apontar para o cliente e dizer “mas você assinou…”

Creio que hoje essas atividades sejam papéis durante o desenvolvimento, não um cargo.
Nem mesmo os processos menos iterativos, como o RUP, admitem hoje um analista que só analisa.

Mas nada disso tem a ver com a produtividade do java versus .net, só com produtividade em geral.

Pode não ser a última moda do momento, mas assim é feito em +90% das empresas de TI hoje.

Se isso é estar obsoleto, deixo a seu critério decidir.

André Fonseca:

Já inventaram isso, se chama Maker.

Sinceramente, eu não acho que os clientes sejam enganados pelas consultorias no desenvolvimento de SW.

Eu acho que se as coisas são assim é porque estão ganhando dinheiro desta forma, quando não estiverem mais outra irá surgir, desde que se ganhe mais dinheiro.

As consultorias tem uma margem de lucro altissima, algumas de mais de 50%, isso de lucro.

Bom, mas sem fugir do tópico eu acho que um ótimo desenvolvedor hoje não pode ser chamado como tal se não tiver um conhecimento bem grande do negócio em que está envolvido.

Não acredito em interpretadores de UML e geradores de código mais…

abs

Quando falo tipo Rails, estou falando que será simples para o próprio usuário fazer, e não que vai ser web, ou desktop, ou mobile, ou se vai usar banco de dados.

E se precisa ser simples acho que podemos descartar a possibilidade de ser baseado em UML ou fluxograma.

JoseIgnacio:

Pode não ser a última moda do momento, mas assim é feito em +90% das empresas de TI hoje.
Se isso é estar obsoleto, deixo a seu critério decidir.

Em cidade você mora? Gostaria de evita-la.
Aqui esse número certamente é bem mais baixo do que 90%.

Hehhehe costumo dizer que o mais produtivo é o que você sabe mais. Java é sim, robusto, pratico e certamente tem suas vantagens. Mais onde a Miscro$oft mais investe é em produtividade.

Snippets, ferramenta de correção de códigos, geração de códigos, nesse ponto, acho que as IDE´s deixa a desejar no java.

Há alguns recursos interessantes, get e set implicito, enfim, produtividade é sim o forte da Microsoft. O grande problema é que pelo fato de ser, de certa forma, acessivel, tem muita merda em .NET, menos comum em aplicações em Java.

Conheço uma aplicação em Java, impecável, (www.valemobi.com.br), os caras realmente fizeram um bom trabalho, mas para saber qual delas é realmente produtiva, teriam que pegar os melhores de cada linguagem e fazer o mesmo projeto. aí sim, daria para provar, caso contrário, melhor seria o que o desenv conhece mais.

AlexandreMinato:

Hehhehe costumo dizer que o mais produtivo é o que você sabe mais. Java é sim, robusto, pratico e certamente tem suas vantagens. Mais onde a Miscro$oft mais investe é em produtividade.

Snippets, ferramenta de correção de códigos, geração de códigos, nesse ponto, acho que as IDE´s deixa a desejar no java.

Há alguns recursos interessantes, get e set implicito, enfim, produtividade é sim o forte da Microsoft. O grande problema é que pelo fato de ser, de certa forma, acessivel, tem muita merda em .NET, menos comum em aplicações em Java.

Conheço uma aplicação em Java, impecável, (www.valemobi.com.br), os caras realmente fizeram um bom trabalho, mas para saber qual delas é realmente produtiva, teriam que pegar os melhores de cada linguagem e fazer o mesmo projeto. aí sim, daria para provar, caso contrário, melhor seria o que o desenv conhece mais.

concordo com você, mas no final ainda sim seria bem relativo.

Pois é, e se voce for avaliar bem, vai reparar ainda que dos outros 50% que não são lucro, pelo menos metade é desperdício. Analistas que não sabem programar, hierarquia enorme de gerentes, sub-gerentes, semi-gerentes e coordenadores que mais atrapalham que ajudam e não contribuem em nada para o produto em si. Consultorias e pessoal contratado específicamente para implantar CMMI, MPS BR, ISO e afins. E nada disso é capaz de fazer software de qualidade, mas o cliente paga a conta disso tudo.

A vantagem das grandes consultorias é que elas já tem uma base grande de clientes, que já se acostumaram a tudo isso. E acham, como eu já ouvi muitas vezes, que software é “assim mesmo”. Mas dificilmente uma empresa pequena com o mesmo modelo de gestão e produção das grandes vai conseguir crescer.

Obsoleto significa algo que não está mais em uso.

JoseIgnacio:

ViniGodoy:

Aqui esse número certamente é bem mais baixo do que 90%.

Obsoleto significa algo que não está mais em uso.

Não, tem 3 significados:

“Dicionário Aurélio”:

1. Que caiu em desuso; arcaico:
   ?fez que ressurgisse uma lei obsoleta, de há quatro séculos.? (Euclides da Cunha, Contrastes e Confrontos, p. 29).
2. V. antiquado.
3. Mal desenvolvido; atrofiado, rudimentar.

O que eu disse se enquadrava nos sinônimos 2 e 3.

E detalhe que “cair em desuso” não significa “não ser usado em lugar nenhum”. A língua dificilmente é matemática assim.
Significa que não é mais usado atualmente, e que geralmente, haverá coisa melhor.

E você chegou a essa conclusão baseado em que?

YvGa:

Pois é, e se voce for avaliar bem, vai reparar ainda que dos outros 50% que não são lucro, pelo menos metade é desperdício. Analistas que não sabem programar, hierarquia enorme de gerentes, sub-gerentes, semi-gerentes e coordenadores que mais atrapalham que ajudam e não contribuem em nada para o produto em si. Consultorias e pessoal contratado específicamente para implantar CMMI, MPS BR, ISO e afins. E nada disso é capaz de fazer software de qualidade, mas o cliente paga a conta disso tudo.

Se modelos de gestão ágil são mais produtivos porque não possuem margens de lucro maiores?

Acho que nem com modelo de gestão diferente porque os clientes ainda vão preferir lidar com analistas que entendam do negócio, do que com programadores diretamente…

Em qualquer livro moderno de metodologia?

Por exemplo, “Utilizando UML e Padrões”, do Craig Larman (que nem é tão moderno assim, e nem fala de uma metodologia tão ágil assim), onde ele aponta que a fase de análise do Processo Unificado agora é uma fase curta do desenvolvimento, e que é geralmente desempenhada pelos próprios programadores da solução?

Ou qualquer livro de metodologia ágil?

Talvez você também queira procurar por alguma pesquisa sobre a adoção de metodologias ágeis na indústria.

Agora, gostaria que você citasse a referência de que:
a) “a maioria” das consultorias ainda usa Waterfall;
e de que:
b) Não existe tendência de substituição por processos ágeis.

ViniGodoy:

Agora, gostaria que você citasse a referência de que:
a) “a maioria” das consultorias ainda usa Waterfall;

Não lembro de ter falado em Waterfall, mas empresas em que o papel de analista não é desempenhado por programadores.

ViniGodoy:

e de que:
b) Não existe tendência de substituição por processos ágeis.

Nunca vi consultoria sem separação entre analista e programadores. Como posso ter referência de algo que nunca vi? rs

Ok, desculpe, realmente me confundi. Mas serviriam referências (assim como vc pediu para mim) sobre isso também.

Creio que a sua evasividade já comprova meu argumento. Se você está baseando suas afirmações categóricas no que “você vê”, e “você acha”, então, ok, pense o que quiser…

JoseIgnacio:

Nunca vi consultoria sem separação entre analista e programadores. Como posso ter referência de algo que nunca vi? rs

Livros?

É como o Viny disse: não dá pra se basear só no que vemos pra tomar como verdade. Apesar de eu já ter visto muito os dois casos.

Mas imagine então uma empresa que trabalha da forma que voce diz. Vai um analista até o cliente, levanta todos os requisitos, bem certinho, tudo bem documentado. Aí ele volta para a empresa, faz a modelagem, escreve uma especificação e passa para um programador. O programador vai lá e implementa…

Nesse cenario ideal essa especificação contem tudo que o cliente pediu para a funcionalidade, descrito de forma bem detalhada, com todos os poréns e todas as exceções. Tudo muito bem descrito para que o programador possa desenvolver exatamente de acordo com aquilo que foi solicitado.

Isso pode parecer muito lógico e sensato a princípio, bastante intuitivo, mas vamos analisar mais de perto.

Digamos que o analista, mesmo ele não sendo um especialista no negócio (por mais conhecimento que tenha ele não é um especialista, coisa que só um profissional da área pode se dizer), consiga compreender exatamente o que é preciso, inclusive o que ficou nas entrelinhas, mesmo aquilo que o cliente esqueceu de dizer porque na cabeça dele está implícito.

Ao elaborar a tal especificação nada do que ele ouviu do cliente e entendeu perfeitamente pode ficar de fora do documento, porque o programador não estava na fase de levantamento de requisitos, logo não faz a menor ideia do que foi discutido, para ele o que vale é a especificação. Por tanto ali estarão além de prints de tela, previamente idealizadas pelo analista, exemplos do modelo de dados, descrevendo exatamente qual informação da tela vai para tal campo e etc e etc e etc.

E além disso, ele vai ter que descrever exatamente, e com riqueza de detalhes todo o processo a ser implementado, todos os possíveis caminhos, o principal, todos os alternativos, o que deve ou não gerar exceção, o que deve abortar a operação, o que deve somente alertar o usuário. Quais botões estarão habilitados e quando. E assim por diante.

Repare que o programador só entra na história na hora de traduzir para a máquina aquilo que o analista já projetou.

Mas pera aí? Não é para isso que serve uma linguagem de programação? Não é justamente para traduzir para a máquina aquilo que projetamos? Então por que diabos o analista ao invés de fazer prints de tela (no paint como já vi muitas vezes), já não faz em html (ou alguma ferramenta visual) a tela de verdade? Porque ele não escreve em Java, C#, php, C++ etc… aqueles processos todos que ele vai escrever no Word? Se todos os detalhes tem que estar lá, todos os caminhos, todas as exceções, a diferença de tempo que vai levar para fazer em um ou outro é pequena. Com a vantagem de que se for feito numa linguagem de programação, ao terminar já estará pronto para ser entregue.

Então eu pergunto: Qual a lógica? Sob que argumento é adicionada mais uma camada ao processo? O programador/digitador?

“Ah, o analista não tem domínio da linguagem de programação.” Então que se cuide, porque existem no mercado inúmeros analistas que tem esse domínio. Gente que sabe programar, e bem, e é capaz de levantar requisitos, entender o negócio e até - pasmem- conversar com o cliente.

Eu vejo a diferença entre analista e programador como perfil.

Tem o cara que gosta de transformar regra de negócio em software funcionando, gosta de entender um problema e achar soluções pra ele. Esse é o analista. Esse é o meu caso.

Tem o cara que gosta de escovar bit, fazer a máquina falar, virar um framework de ponta cabeça só pra saber como é feito, inventar algoritmos do nada. Esse é o programador. E para desmentir o que muitos pensam, os melhores programadores ganham muitas vezes mais que os melhores analistas.

Mas saber programar é requisito básico tanto pra um quanto pra outro. Analista que não programa está com os dias contados.

Vai me dizer que você nunca ouviu alguém dizer a seguinte frase sobre um analista? “Esse se for demitido não arruma emprego em lugar nenhum”.

Por que será?

Não tenho grande vivencia em Java, mas já fiz cursos e trabalhei num projeto usando Struts 2, o que atuo de fato é .NET, usando ASP.NET MVC, também baseado em action como o Struts 2.

Na parte de programar nas Views achei o .NET um pouco mais produtivo, Razor é muito mais legal de escrever do que Taglib (eu só aprendi dessa forma na época, não sei tem outra).

Na parte de controllers nao lembro muito no Java, mas lembro de ter muitos annotations e um XML no struts2 e no .NET é mais programático e uso de convenções mais fortes. Parte de filter por exemplo você programa de forma simples ao invés de configurar em XML, pelo menos foi o que usavam na época…

Na parte de model, realmente a questão dos gets e sets implícitos do C# deixam o código mais limpo e agradável.

Na parte de ORM, o Entity Framework da Microsoft fica anos luz atrás do Hibernate. Mas graças a comunidade existe o NHibernate para .NET, sei que é uma versão magra, mas para o que sempre precisei achei muito melhor que o Hibernate do Java, com mapeamento programático, sem XML ou amarração de annotations, e linguagem de consulta em objetos melhorada (QueryOver, que usa criteria por baixo dos panos).

Lembrando que todas essas vantagens que notei do .NET e ASP.NET MVC são frutos de cópias melhoradas do Java e Struts2.

Não trabalho com .NET desde a versão 2.0, então não conheço bem o Razor, MVC, nem as novidades da plataforma. Mas isso que você falou, se eu entendi bem, existe sim em Java, são os scriptlets. Mas são considerados má prática porque dificultam a manutenção do código (ele se espalha pra todo lado) e quebram o princípio básico da separação de responsabilidades.

YvGa:

javaflex:

Na parte de programar nas Views achei o .NET um pouco mais produtivo, Razor é muito mais legal de escrever do que Taglib (eu só aprendi dessa forma, não sei tem como usar diretamente sintaxe Java como acontece no .NET, onde o Razor permite trabalhar diretamente com linguagem C# nas Views).

Não trabalho com .NET desde a versão 2.0, então não conheço bem o Razor, MVC, nem as novidades da plataforma. Mas isso que você falou, se eu entendi bem, existe sim em Java, são os scriptlets. Mas são considerados má prática porque dificultam a manutenção do código (ele se espalha pra todo lado) e quebram o princípio básico da separação de responsabilidades.

Deve ser equivalente a isso mesmo, só que sem os delimitadores chatos <% %>, usa só um arroba @ no inicio. Só quebra a responsabilidade se a equipe quiser, para esses casos existe o WebMatrix, esse sim é para equipe que quer trabalhar dessa forma, seria como o JSP clássico. As equipes de boas empresas que trabalham com ASP.NET MVC geralmente seguem padrões e não precisam ter algo engessado para que não quebrem boas práticas, e ao mesmo tempo usufruem de uma programação mais natural na view e não somos crucificados por usar essa forma. Você só define qual classe model vai ser usada na view e partir daí navega em cima do objeto (requisitado por uma action). No ASP.NET WebForms confesso que na média era produtividade orientada a “bagunça” mesmo.

YvGa, eu sempre me pergunto:
"Alguém aí já brincou de telefone sem-fio e a mensagem chegou exatamente igual ao final da conversa?"

Então porque você acha que isso vai dar certo no processo de desenvolvimento do sistema?
Cliente->Analista->Documentação->Engenheiro->Documentação->Programador->Software.

O que acha que vai sair no software?

O Razor serve exatamente para evitar trabalhar com C# nas Views.
De qualquer forma, é um erro também usar isso na forma de scriptlets. O correto é estruturar corretamente o Controller, faze-lo criar classes para simplificar ao máximo o trabalho da View.

ViniGodoy:

YvGa, eu sempre me pergunto:
"Alguém aí já brincou de telefone sem-fio e a mensagem chegou exatamente igual ao final da conversa?"

Então porque você acha que isso vai dar certo no processo de desenvolvimento do sistema?
Analista->Documentação->Engenheiro->Documentação->Programador->Software.

O que acha que vai sair no software?

O Razor serve exatamente para evitar trabalhar com C# nas Views.
De qualquer forma, é um erro também usar isso na forma de scriptlets. O correto é estruturar corretamente o Controller, faze-lo criar classes para simplificar ao máximo o trabalho da View.

Abaixo exemplo de View no ASP.NET MVC.

A primeira linha define qual tipo de objeto a view vai receber.

O foreach abaixo por exemplo é linguagem C# de verdade, não é outro tipo de coisa como taglib.

“Model” por convenção é o objeto estruturado para a view, que a action da controller retornará do tipo definido acima.

O “@” é da sintaxe do motor Razor, para saber onde começa a instrução da linguagem C# no meio do html. E não precisamos definir onde termina, o Razor se encarrega de saber onde termina pelo contexto da instrução.

razor_imagem7.png531×555

Sim, o curioso é que, embora ele seja usado para você dar o comando C# nas Views, a recomendação é justamente que você evite ao máximo isso.

Quer dizer, você use o Razor para dar comandos simples, geralmente de uma só linha, e geralmente usando classes helper de alguma camada de fachada do servidor (como essa Html.ActionLink).
A recomendação existe para que não se faça em MS MVC o que se fazia em ASP padrão.

[2]

Ainda adiciono mais: Se você fizer direitinho, o Designer continua conseguindo editar as telinhas de view.

Acho um pouco simplista a idéia de que só pq a tag é “HTML like” vai ser mais fácil para o designer.

[2]

Ainda adiciono mais: Se você fizer direitinho, o Designer continua conseguindo editar as telinhas de view.

Acho um pouco simplista a idéia de que só pq a tag é “HTML like” vai ser mais fácil para o designer.
Exatamente, eu trabalho com designers que em pouco tempo já se familiarizaram com a sintaxe “não-tag” nos pontos que eles sabem muito bem que são partes dinâmicas. A coloração do editor de código na parte de linguagem servidor já ajuda melhor do que se fossem “tags”. O importante é o código ficar limpo e legível e sem muita lógica, ou seja o model já vir mastigado para atender a view. Para eles designers inferno era trabalhar com frameworks baseados em componentes como ASP.NET WebForms ou JSF, que é difícil ter o controle apurado do resultado.

ViniGodoy:

YvGa, eu sempre me pergunto:
"Alguém aí já brincou de telefone sem-fio e a mensagem chegou exatamente igual ao final da conversa?"

Então porque você acha que isso vai dar certo no processo de desenvolvimento do sistema?
Cliente->Analista->Documentação->Engenheiro->Documentação->Programador->Software.

O que acha que vai sair no software?

Concordo plenamente, eu só quis no meu post exemplificar que, ainda que fosse possível, essa cadeia de transmissão de informação é desnecessária. Por isso nem comentei sobre o efeito "telefone sem fio".

Se for usar como nesse seu exemplo, tudo bem. Realmente não há muita diferença entre um foreach e um <c:forEach. O problema é quando o pessoal começa a colocar regra de negócio diretamente ali.>

JoseIgnacio, o ViniGodoy está certo. O modelo em que se separa programador e analista está extremamente obsoleto. Existem aí diversos artigos que colocam que nesse modelo as chances de fracasso, horas e gastos extras são muito grandes. Mas apesar disso, devo concordar com você que mesmo aqui em SÃO PAULO muitas empresas grandes ainda adotam esse modelo ultrapassado. Não sei se são 90% como você disse mas são muitas mesmo. Eu trabalhei em um grande banco em que usava esse modelo. Empresas grandes de TI também como a Accenture também utilizam esse modelo. Apesar de ficar infeliz com esse fato, acho que ainda vai demorar muito para grandes empresas e multinacionais mudarem o modelo de desenvolvimento de software por aqui. Algumas até tentam, mas fazem um “MIX” de Waterfall com Ágil. Li alguns casos de sucesso, mas geralmente disso aí não deve sair muita coisa boa. A agilidade não está no processo, mas sim em conceito. Cada empresa deve adaptar o conceito ágil de acordo com a sua realidade e de acordo com cada projeto. Não é um modelo pronto.

Inúmeros? Talvez.

Infelizmente o programador típico não se interessa por ir além da interface do software e só quer saber de como ele é implementado.

caindo de paraquedas: citaram essa thread hoje no grupo .netbr e vim ler. Nossa muitos posts desde o inicio da thread, mui longa.
(PS: eu crei a conta no GUJ semana passada, só não a tinha usado ainda. É que eu leio mais do que escrevo)

Beleza, eu fiquei assustada que o Kiko tenha começado essa thread (e abandonado depois), eu conheci o Kiko, apesar dele provavelmente não lembrar quem eu sou, quando eu andava só com “povin de java” e quando eu trabalhava com Grails, na época eu nem me misturava muito com “comunidade” MS. E na época eu li um texto do Kiko onde ele dizia que não havia bala de prata. Usei as palavras dele mutias vezes em discussões, pois eu acreditava no que ele tinha dito.

Pois bem, uns 2 anos depois o vejo iniciando essa discussão que, sinto muito, já deu o que tinha que dar. Sério. Todo mundo pode ter a sua linguagem ou plataforma favorita, e cada um faz melhor onde conhece melhor. Estava eu discutindo com Vini Godoy e Elemar Junior, que foi citado na página 3 ou 4 dessa thread (acabei de avisa-lo), sobre guerrinhas de linguagens e plataformas e… poxa, não pode ser todo mundo amigo? Carambolas, eu estou dando uma ajuda com jsp, servlets e caralhada a 4 para uma amiga, mas se ela me perguntar onde eu serei mais produtiva vou dizer que em .net, pois é onde me aprofundei nos últimos tempos. Possível que se ela tivesse me perguntado a mesma coisa ha 2 anos eu teria respondido outra coisa.

Tá, uma coisa que eu e uns amigos dizemos, em tom de brincadeira, é que C# é uma linguagem melhor, mas Java é uma plataforma melhor.

Vi alguém dizendo que não há tantas diversidades no .net, que todo mundo só usa o que a MS decidir. Pois bem, existe bastante projeto feito pela comunidade… só que a “comunidade” .net ainda não pegou o costume de usar. Na verdade, vejo que a comunidade .net já alcançou a comunidade java, pois não vejo ninguém na comu java falar de mais nada tão novo assim. São muitas opções, sã, mas sempre as mesmas.

Falando de maturidade de comunidade, a comunidade .net já evoluiu também em muitas coisas da qual alguns de vocês apontaram o dedo, como por exemplo dizerem que dev .net só sabe usar drag in drop. Esse mito já caiu por terra. Quem tem costume de drag in drop não tem uma boa carreira e faria merda em qualquer plataforma, não somente em .net. Porque isso é cultural (como eu vi alguém dizer na página 1 ou 2 dessa thread), a pessoa iria fazer isso em qualquer lugar.

Okay, vejamos, a curva de aprendizado do .net é muito mais agradável que a do java. Falo isso pois eu dei aulas de reforço na faculdade onde estudei e percebi isso nos alunos. Porém os que eu vi irem contra a corrente mandavam bem em qualquer linguagem ou plataforma que quisessem aprender.

E isso separa o trigo do joio… ou seja lá como é a expressão. Vejo gente que por ter começado com java acabou aprendendo a pesquisar a fundo e procurar os macetes. Vejo muita gente no fórum da MSDN, da Microsoft e que, em pleno segundo semestre de 2012, em plena época de Asp.Net MVC 4, vem querendo umas ajudas absurdas, sem enm coragem de procurar no google ou ler os links que eu passo.

Mas, em contra partida, há quem manje muito também. Só que ficam ofuscados aos olhos das outras comunidades pois o maior burburinho vem da grande massa folgada. Mas isso eu vejo na comunidade java também. Ou vai dizer que todo mundo que trabalha com java é foda? Eu já vi casos béeeem tristes.

Conclusão:

gente, para de guerra, usa o que lhe for confortável e pronto.

[color=red]Outra coisa:[/color]

Acabaram de falar de razor e de código C# na view. Gente, é possível mas não é recomendável.

Isso infelizmente ocorre porque “empresas grandes” sente-se mais a vontade fazendo negócios com “empresas grandes” se houver qualquer indicativo de que a coisa lembre fundo de quintal na concepção das grandes empresas a coisa fica difícil ou até mesmo impossível, isto sem falar nos certificados.

Para fazer negócio com empresas grandes você tem que parecer grande também; e assim nascem vários problemas…fato.

flws

Exato. Parece que é mais confortável acreditar que algo esta obsoleto, mas a verdade é que Agile não demonstrou sua eficácia em ambiente de grandes empresas.

Relaxa, não virou briga…infelizmente alguns se prenderam a linguagem para argumentar, mas nada tão ruim. Há uns 20 anos que vejo isto acontecer e pensando bem acho que vai continuar acontecendo. As empresas produtoras de ferramentas usam a produtividade (também) como diferencial para alavancar as vendas de seus produtos natural isto acontecer.

flws

JoseIgnacio:

Exato. Parece que é mais confortável acreditar que algo esta obsoleto, mas a verdade é que Agile não demonstrou sua eficácia em ambiente de grandes empresas.

Mas voce gosta de afirmar as coisas ao vento, não é?

Quem disse que não? existem casos de sucesso de adoção de agile em empresas grandes. O problema é que empresas grandes são mais engessadas, as coisas demoram mais pra acontecer e está todo mundo mais preocupado em defender o seu do que fazer a coisa funcionar. É tudo muito burocrático.

Então o problema está na empresa não no agile, porque ágile em si é muito simples.

E curioso, você prefere jogar frases dispersas aqui e ali do que argumentar com profundidade. Leia meu post sobre analista e programadores e poste uma réplica a ele, ao invés de deixar frases soltas de como você acha que é em empresas grandes, baseando-se apenas naquela em que você trabalha.

É camarada…as vezes a coisa pode ser complicada; acho que isto que você disse, por incrível que possa parecer, daria mais um livro sobre o assunto rsrsr.

flws

[quoteYvGa]Então o problema está na empresa não no agile, porque ágile em si é muito simples.[/quote]

Concordo…

flws

YvGa:

Mas voce gosta de afirmar as coisas ao vento, não é?

Quem disse que não? existem casos de sucesso de adoção de agile em empresas grandes. O problema é que empresas grandes são mais engessadas, as coisas demoram mais pra acontecer e está todo mundo mais preocupado em defender o seu do que fazer a coisa funcionar. É tudo muito burocrático.

Então o problema está na empresa não no agile, porque ágile em si é muito simples.

E curioso, você prefere jogar frases dispersas aqui e ali do que argumentar com profundidade. Leia meu post sobre analista e programadores e poste uma réplica a ele, ao invés de deixar frases soltas de como você acha que é em empresas grandes, baseando-se apenas naquela em que você trabalha.

Não respondi a seu post porque não achei necessário, eu concordo com praticamente tudo que escreveu.

Mas em relação a sua pergunta:

A lógica é a do curto prazo. O que é melhor, usar um processo testado desde 1990, ou usar algo novo e de funcionalidade não comprovada a não ser por algums casos de sucesso?

JoseIgnacio:

A lógica é a do curto prazo. O que é melhor, usar um processo testado desde 1990, ou usar algo novo e de funcionalidade não comprovada a não ser por algums casos de sucesso?

Então você concorda que o problema está nas empresas e não nas práticas? As empresas ditas grandes (a maioria delas) tem muitos dos seus problemas praticamente originados num mesmo ponto. O “cover your ass”. Ninguém tem coragem de fazer nada diferente porque se der errado não vai querer pagar o pato. E pior ainda, sempre que entra num projeto a primeira preocupação é criar mecanismos de auto-proteção. Emails, documentos, tudo que for preciso pra, se der M…, ter uma boa explicação. E parece que quanto menor o cargo, maior a predisposição a se proteger, por incrível que pareça.

Por isso as empresas maiores demoram mais pra mudar suas práticas, mas isso não significa que elas estão certas e que devemos nos submeter a elas.

JoseIgnacio:

A lógica é a do curto prazo. O que é melhor, usar um processo testado desde 1990, ou usar algo novo e de funcionalidade não comprovada a não ser por algums casos de sucesso?

Ai é que está, na minha opinião o Agil não tem nada de tão novo assim, ele muda apenas a forma de se pensar o desenvolvimento do SW.

Metodologias tradicionais diziam que você deveria planejar tudo antes e se resguardar de todas as possiveis M que pudessem acontecer no futuro.

No PMI toda mudança fora do escopo leva a um processo complexo de change management (posso estar enganado aqui já que não sou especialista no assunto)

Para o Agil mudanção são bem vindas, desde que as prioridades sejam acordadas com o cliente.

Penso que o certo seria unir o melhor dos mundos, não é a toa que no PMI já temos uma vertente agil.

Falando sobre a minha experência própria eu ainda vejo que tem um grande caminho sim do Agil ser adotado pelas grandes empresas, principalmente porque o SW na maioria delas feito pelas consultorias usando o tal do outsourcing.

Porque eu acho que é assim? Porque as pessoas envolvidas ganham dinheiro assim e não tem “coragem” suficiente para mudar. Entre outras coisas.

Os projetos de SW falham não por causa da metodologia adotada ou por causa da tecnologia…

Depois que eu li, acabei respondendo quase igual ao Paulo…

Como assim, você nunca usou um foreach na view?? Seja view, view parcial ou view de html helper. Como você faz?

javaflex:

MayogaX:

[color=red]Outra coisa:[/color]

Acabaram de falar de razor e de código C# na view. Gente, é possível mas não é recomendável.

Como assim, você nunca usou um foreach na view?? Seja view, view parcial ou view de html helper. Como você faz então?

MayogaX:

caindo de paraquedas: citaram essa thread hoje no grupo .netbr e vim ler. Nossa muitos posts desde o inicio da thread, mui longa.
(PS: eu crei a conta no GUJ semana passada, só não a tinha usado ainda. É que eu leio mais do que escrevo)

Beleza, eu fiquei assustada que o Kiko tenha começado essa thread (e abandonado depois), eu conheci o Kiko, apesar dele provavelmente não lembrar quem eu sou, quando eu andava só com “povin de java” e quando eu trabalhava com Grails, na época eu nem me misturava muito com “comunidade” MS. E na época eu li um texto do Kiko onde ele dizia que não havia bala de prata. Usei as palavras dele mutias vezes em discussões, pois eu acreditava no que ele tinha dito.

Pois bem, uns 2 anos depois o vejo iniciando essa discussão que, sinto muito, já deu o que tinha que dar. Sério. Todo mundo pode ter a sua linguagem ou plataforma favorita, e cada um faz melhor onde conhece melhor. Estava eu discutindo com Vini Godoy e Elemar Junior, que foi citado na página 3 ou 4 dessa thread (acabei de avisa-lo), sobre guerrinhas de linguagens e plataformas e… poxa, não pode ser todo mundo amigo? Carambolas, eu estou dando uma ajuda com jsp, servlets e caralhada a 4 para uma amiga, mas se ela me perguntar onde eu serei mais produtiva vou dizer que em .net, pois é onde me aprofundei nos últimos tempos. Possível que se ela tivesse me perguntado a mesma coisa ha 2 anos eu teria respondido outra coisa.

Tá, uma coisa que eu e uns amigos dizemos, em tom de brincadeira, é que C# é uma linguagem melhor, mas Java é uma plataforma melhor.

Vi alguém dizendo que não há tantas diversidades no .net, que todo mundo só usa o que a MS decidir. Pois bem, existe bastante projeto feito pela comunidade… só que a “comunidade” .net ainda não pegou o costume de usar. Na verdade, vejo que a comunidade .net já alcançou a comunidade java, pois não vejo ninguém na comu java falar de mais nada tão novo assim. São muitas opções, sã, mas sempre as mesmas.

Falando de maturidade de comunidade, a comunidade .net já evoluiu também em muitas coisas da qual alguns de vocês apontaram o dedo, como por exemplo dizerem que dev .net só sabe usar drag in drop. Esse mito já caiu por terra. Quem tem costume de drag in drop não tem uma boa carreira e faria merda em qualquer plataforma, não somente em .net. Porque isso é cultural (como eu vi alguém dizer na página 1 ou 2 dessa thread), a pessoa iria fazer isso em qualquer lugar.

Okay, vejamos, a curva de aprendizado do .net é muito mais agradável que a do java. Falo isso pois eu dei aulas de reforço na faculdade onde estudei e percebi isso nos alunos. Porém os que eu vi irem contra a corrente mandavam bem em qualquer linguagem ou plataforma que quisessem aprender.

E isso separa o trigo do joio… ou seja lá como é a expressão. Vejo gente que por ter começado com java acabou aprendendo a pesquisar a fundo e procurar os macetes. Vejo muita gente no fórum da MSDN, da Microsoft e que, em pleno segundo semestre de 2012, em plena época de Asp.Net MVC 4, vem querendo umas ajudas absurdas, sem enm coragem de procurar no google ou ler os links que eu passo.

Mas, em contra partida, há quem manje muito também. Só que ficam ofuscados aos olhos das outras comunidades pois o maior burburinho vem da grande massa folgada. Mas isso eu vejo na comunidade java também. Ou vai dizer que todo mundo que trabalha com java é foda? Eu já vi casos béeeem tristes.

Conclusão:

gente, para de guerra, usa o que lhe for confortável e pronto.

[color=red]Outra coisa:[/color]

Acabaram de falar de razor e de código C# na view. Gente, é possível mas não é recomendável.

Oi Mayoga, como me esquecer de você?

Na realidade, eu continuo com a mesma opinião, de que não há bala de prata. O ponto, no entanto, é outro: é que após escutar tantas vezes o papo de que .net é mais produtivo que Java e bla bla bla, comecei a me questionar: de onde vêm esta história?
Será que tem um fundo de verdade nela?

E pelo que pude perceber, continua sendo a mesma balela, mas de qualquer forma, neste caso eu preferi apenas acompanhar o desdobramento (não abandonei a discussão :D) para aprender algo lendo a opinião dos colegas aqui do GUJ.

Aliás, voltando à bala de prata, acho essencial todo desenvolvedor ou envolvido em TI dar uma lida (e reler de vez em quando) o texto clássico do Peter Brooks cujo link segue abaixo:

Agora, minha opinião final: não acredito em bala de prata ou na existência da linguagem/plataforma mais produtiva do mundo. O argumento é simples: após mais de meio século de desenvolvimento esta ainda não surgiu.
Como eu sei que ainda não surgiu? Por que se tivesse aparecido, não teríamos TANTAS linguagens e plataformas de desenvolvimento como temos hoje. O número seria bem menor.

A única ferramenta que eu realmente conheço e que aumenta minha produtividade se chama “bom senso na hora de escolher o que usar”.

javaflex:

MayogaX:

[color=red]Outra coisa:[/color]

Acabaram de falar de razor e de código C# na view. Gente, é possível mas não é recomendável.

Como assim, você nunca usou um foreach na view?? Seja view, view parcial ou view de html helper. Como você faz?

Acho que ela quis dizer o que já dissemos. Que não é para sair codificando seu sistema todo na view, como se fazia em .ASP.
Não é porque seja possível, que seja recomendável.

ViniGodoy:

javaflex:

MayogaX:

[color=red]Outra coisa:[/color]

Acabaram de falar de razor e de código C# na view. Gente, é possível mas não é recomendável.

Como assim, você nunca usou um foreach na view?? Seja view, view parcial ou view de html helper. Como você faz?

Acho que ela quis dizer o que já dissemos. Que não é para sair codificando seu sistema todo na view, como se fazia em .ASP.
Não é porque seja possível, que seja recomendável.

O que eu já vi disso em sistemas construídos no delphi, dava para encher os dedos das mãos e dos pés.

juliocbq:

ViniGodoy:

javaflex:

MayogaX:

[color=red]Outra coisa:[/color]

Acabaram de falar de razor e de código C# na view. Gente, é possível mas não é recomendável.

Como assim, você nunca usou um foreach na view?? Seja view, view parcial ou view de html helper. Como você faz?

Acho que ela quis dizer o que já dissemos. Que não é para sair codificando seu sistema todo na view, como se fazia em .ASP.
Não é porque seja possível, que seja recomendável.

O que eu já vi disso em sistemas construídos no delphi, dava para encher os dedos das mãos e dos pés.

eu vejo isso todo dia … e vende como água …

Fico eternamente feliz que Kiko não tenha esquecido de mim. E fico mais aliviada já que ele explicou o motivo da thread.

rmendes08:

juliocbq:

ViniGodoy:

javaflex:

MayogaX:

[color=red]Outra coisa:[/color]

Acabaram de falar de razor e de código C# na view. Gente, é possível mas não é recomendável.

Como assim, você nunca usou um foreach na view?? Seja view, view parcial ou view de html helper. Como você faz?

Acho que ela quis dizer o que já dissemos. Que não é para sair codificando seu sistema todo na view, como se fazia em .ASP.
Não é porque seja possível, que seja recomendável.

O que eu já vi disso em sistemas construídos no delphi, dava para encher os dedos das mãos e dos pés.

eu vejo isso todo dia … e vende como água …

Pois é, Vini Godoy, foi o que eu quis dizer.
Já vi nego colocar lógica na view.

Vende? Vende… mas… depois na hora de ir lá dar manutenção lembra que certa regra ficou na view e por isso o que você está alterando em uma parte do código não está surtindo efeito… ou coisas do tipo.

Sobre Agile…
http://www.adaptworks.com.br/blog/2012/08/28/fbi-exibe-caso-de-sucesso-utilizando-scrum/

Sobre a mega super produtividade do .NET, acho que as opiniões já ficaram claras e os argumentos pipocaram de forma bem legal.

Acho que a Terceira guerra mundial vai sair do mundo de TI, talvez no dia que alguém da MS agredir o Linus de forma física ou então quando a Google e a Samsung fizerem um vídeo, cuspindo ni IPhone ou vice-versa.

Enquanto isso eu vou aprendendo e usando a favor.

Abs []

MayogaX:

Fico eternamente feliz que Kiko não tenha esquecido de mim. E fico mais aliviada já que ele explicou o motivo da thread.

rmendes08:

juliocbq:

ViniGodoy:

javaflex:

MayogaX:

[color=red]Outra coisa:[/color]

Acabaram de falar de razor e de código C# na view. Gente, é possível mas não é recomendável.

Como assim, você nunca usou um foreach na view?? Seja view, view parcial ou view de html helper. Como você faz?

Acho que ela quis dizer o que já dissemos. Que não é para sair codificando seu sistema todo na view, como se fazia em .ASP.
Não é porque seja possível, que seja recomendável.

O que eu já vi disso em sistemas construídos no delphi, dava para encher os dedos das mãos e dos pés.

eu vejo isso todo dia … e vende como água …

Pois é, Vini Godoy, foi o que eu quis dizer.
Já vi nego colocar lógica na view.

Vende? Vende… mas… depois na hora de ir lá dar manutenção lembra que certa regra ficou na view e por isso o que você está alterando em uma parte do código não está surtindo efeito… ou coisas do tipo.

rsrsrs … sou justamente eu quem sofre com essa falta de organização … pois tenho que migrar código Delphi todo na View para um novo sistema. Isso serviu para uma época em que TI e sistemas de informação era “um luxo” para as empresas. Hoje em dia não existe mais espaço para sistemas feitos dessa maneira.

rmendes08:

rsrsrs … sou justamente eu quem sofre com essa falta de organização … pois tenho que migrar código Delphi todo na View para um novo sistema. Isso serviu para uma época em que TI e sistemas de informação era “um luxo” para as empresas. Hoje em dia não existe mais espaço para sistemas feitos dessa maneira.

Discordo de você: neste aspecto o mercado infelizmente é igual coração de mãe: sempre cabe mais um

kicolobo:

rmendes08:

rsrsrs … sou justamente eu quem sofre com essa falta de organização … pois tenho que migrar código Delphi todo na View para um novo sistema. Isso serviu para uma época em que TI e sistemas de informação era “um luxo” para as empresas. Hoje em dia não existe mais espaço para sistemas feitos dessa maneira.

Discordo de você: neste aspecto o mercado infelizmente é igual coração de mãe: sempre cabe mais um :D

+1

Sempre tem espaço para aqueles que só precisam de um sistema que funcione…
ou só precisam de um site um pouco dinâmico com a salada de scripts php no meio do html!

E se isso ontem foi um luxo, hoje é obrigação… até padaria e farmacia do zé precisa as vezes de site e sistema customizado (nem sempre a solução pronta de prateleira atende)!
E nesses casos, ta cheio de sistema desse jeito… e muita empresa ganha dinheiro assim!

Se o certo mesmo era não ter nada dessa forma… seria a mesma coisa que falar que você precisaria de um engenheiro formado para fazer uma pequena reforma em sua casa… seguindo normas… bla bla bla… então vamos entrar em outro assunto… regulamentação de TI… e tudo mais! Até que ponto estas pessoas precisam efetivamente disso ?

+1

flws

MayogaX:

Fico eternamente feliz que Kiko não tenha esquecido de mim. E fico mais aliviada já que ele explicou o motivo da thread.

rmendes08:

juliocbq:

ViniGodoy:

javaflex:

MayogaX:

[color=red]Outra coisa:[/color]

Acabaram de falar de razor e de código C# na view. Gente, é possível mas não é recomendável.

Como assim, você nunca usou um foreach na view?? Seja view, view parcial ou view de html helper. Como você faz?

Acho que ela quis dizer o que já dissemos. Que não é para sair codificando seu sistema todo na view, como se fazia em .ASP.
Não é porque seja possível, que seja recomendável.

O que eu já vi disso em sistemas construídos no delphi, dava para encher os dedos das mãos e dos pés.

eu vejo isso todo dia … e vende como água …

Pois é, Vini Godoy, foi o que eu quis dizer.
Já vi nego colocar lógica na view.

Vende? Vende… mas… depois na hora de ir lá dar manutenção lembra que certa regra ficou na view e por isso o que você está alterando em uma parte do código não está surtindo efeito… ou coisas do tipo.

MayogaX, isso com certeza de não ter regras na view, só estranhei por você ter falado em não usar C#, pois qualquer programação na view se usa C# através do razor.

+1

flws

Não sei porque reclamam tanto de tecnologias antigas. Falavam tão mal do Delphi hoje o Swing do Java tem muitos aspectos que foram copiados dele.

O que vejo são uma explosão de linguagens com vários xiitas e que convertem vários seguidores. Se esquecendo de fazer o verdadeiro papel que seria resolver o problema do cliente.

Hoje as tecnologias viraram um comercio e cada um quer vender a sua como melhor. Viramos cosumidores na mão de vendedores picaretas.

Hempx:

Não sei porque reclamam tanto de tecnologias antigas. Falavam tão mal do Delphi hoje o Swing do Java tem muitos aspectos que foram copiados dele.

O que vejo são uma explosão de linguagens com vários xiitas e que convertem vários seguidores. Se esquecendo de fazer o verdadeiro papel que seria resolver o problema do cliente.

Hoje as tecnologias viraram um comercio e cada um quer vender a sua como melhor. Viramos cosumidores na mão de vendedores picaretas.

Até concordo com você…mas o ponto não foi este. A questão apontada é sobre a falta de boas práticas adotadas nos sistemas, independente da linguagem (nova ou antiga). O jmmenezes deu a entender que hoje em dia não haveria mais espaço para a pratica adota no sistema que ele estava fazendo migração e o kicoloco disse que no mercado sempre tem espaço para construção de sistemas com praticas inadequadas.

E eu concordo com ele (kicoloco), existem vários “lideres”, “gerentes”, “chefes” e etc… que não tem formação na área de TI e pouco menos bom senso que pensa em apenas se livrar dos problemas de qualquer maneira. Como consequência eles colocam qualquer pessoa que pensa que sabe o que é um for um while ou um if para por a mão na codificação do sistema independente da tecnologia adotada.

flws

+1

flws

Não sei porque reclamam tanto de tecnologias antigas. Falavam tão mal do Delphi hoje o Swing do Java tem muitos aspectos que foram copiados dele.

O que vejo são uma explosão de linguagens com vários xiitas e que convertem vários seguidores. Se esquecendo de fazer o verdadeiro papel que seria resolver o problema do cliente.

Hoje as tecnologias viraram um comercio e cada um quer vender a sua como melhor. Viramos cosumidores na mão de vendedores picaretas.

Se existissem esses aspectos até que estaria muito bom. A vcl e o delphi estão a “anos luz” á frente como framework de interface gráfica e ide.

fantomas:

Hempx:

Não sei porque reclamam tanto de tecnologias antigas. Falavam tão mal do Delphi hoje o Swing do Java tem muitos aspectos que foram copiados dele.

O que vejo são uma explosão de linguagens com vários xiitas e que convertem vários seguidores. Se esquecendo de fazer o verdadeiro papel que seria resolver o problema do cliente.

Hoje as tecnologias viraram um comercio e cada um quer vender a sua como melhor. Viramos cosumidores na mão de vendedores picaretas.

Até concordo com você…mas o ponto não foi este. A questão apontada é sobre a falta de boas práticas adotadas nos sistemas, independente da linguagem (nova ou antiga). O jmmenezes deu a entender que hoje em dia não haveria mais espaço para a pratica adota no sistema que ele estava fazendo migração e o kicoloco disse que no mercado sempre tem espaço para construção de sistemas com praticas inadequadas.

E eu concordo com ele (kicoloco), existem vários “lideres”, “gerentes”, “chefes” e etc… que não tem formação na área de TI e pouco menos bom senso que pensa em apenas se livrar dos problemas de qualquer maneira. Como consequência eles colocam qualquer pessoa que pensa que sabe o que é um for um while ou um if para por a mão na codificação do sistema independente da tecnologia adotada.

flws

Ah… sim beleza…boas praticas é bem diferente de “modinhas”.
Parabéns, concordo completamente.

+1

flws

Não sei porque reclamam tanto de tecnologias antigas. Falavam tão mal do Delphi hoje o Swing do Java tem muitos aspectos que foram copiados dele.

O que vejo são uma explosão de linguagens com vários xiitas e que convertem vários seguidores. Se esquecendo de fazer o verdadeiro papel que seria resolver o problema do cliente.

Hoje as tecnologias viraram um comercio e cada um quer vender a sua como melhor. Viramos cosumidores na mão de vendedores picaretas.

Se existissem esses aspectos até que estaria muito bom. A vcl e o delphi estão a “anos luz” á frente como framework de interface gráfica e ide.

Verdade , Ainda prefiro construir aplicações desktop com o bom e velho Delphi a utilizar o Swing.

Acho bastante improdutivo essa gama de frameworks da vida.

+1

flws

Não sei porque reclamam tanto de tecnologias antigas. Falavam tão mal do Delphi hoje o Swing do Java tem muitos aspectos que foram copiados dele.

O que vejo são uma explosão de linguagens com vários xiitas e que convertem vários seguidores. Se esquecendo de fazer o verdadeiro papel que seria resolver o problema do cliente.

Hoje as tecnologias viraram um comercio e cada um quer vender a sua como melhor. Viramos cosumidores na mão de vendedores picaretas.

Se existissem esses aspectos até que estaria muito bom. A vcl e o delphi estão a “anos luz” á frente como framework de interface gráfica e ide.

Verdade , Ainda prefiro construir aplicações desktop com o bom e velho Delphi a utilizar o Swing.

Acho bastante improdutivo essa gama de frameworks da vida.

Sobre soluções desktop 2D, já trabalhei muito com Delphi no passado e concordo sobre o que falou da VCL. Já Swing é coisa mais tosca que já vi, SWT achava bom, mas não sei o que ocorreu na comunidade que apoiaram mais Swing, talvez por causa da religião Sun.

É muito produtivo mesmo o Delphi, mas hoje dificilmente existem necessidades reais de se fazer sistemas de informação “desktop”, nem mesmo offline, só quando necessário acessar coisas na máquina que o browser ou plugins não deixam, a versatilidade do browser fala mais alto.

Na minha opinião acaba mais facil você responder essa questão puxando um exemplo pratico do nosso dia a dia.

Essa discussão se assemelha a aquelas discussões sobre time de futebol, com perguntas tipo “Qual time faz mais gols?! o meu ou o seu ?!”, “Qual time tem mais torcedores?!” ou “Qual time ganhou mais titulos?!”

Podemos (de certa forma) encarar o elenco de um time como as funcionalidades que cada plataforma apresenta. Seu time pode mandar muito bem em determinado campeonato e não em outro, por exemplo ir melhor num campeonato estadual e ir mal no Brasileirão.

A mesma coisa que já foi dita aqui, Java se apresenta melhor em algumas cituações assim com .NET se apresenta em outras.

Mas sempre se tem que levar em consideração que as vezes se ganha uma e perde outra, as vezes cai para segunda divisão, as vezes aparece com um bom jogador que da um up no time, as vezes outro time treina um jogador para parecer com o seu, é mesma coisa.

Então comparando os times com as plataformas, para mim sua produtividade se deve ao fato de quantas partidas ele ganha.