"Java platform increases programmer efficiency..." (será?)

Então cara, profissionalmente só trabalhei com Java mas na faculdade quando programava em C++ senti uma diferença bem grande quando comecei a programar em Java ainda na faculdade, sem contar as IDEs que ajudam absurdamente (Eclipse e NetBeans).
Tem uma galera aqu no GUJ que trabalha com outras linguagens tbm, Ruby, C++, .Net, eles saberão responder com mais detalhes.

Realmente, acho que ele está falando da migração das linguagens anteriores ao Java, para o Java. Nesse caso, as opções da época eram o Delphi, o C++, o Visual Basic.

Em relação ao C++, acho que para a maior parte das aplicações existe sim, um grande ganho de eficiência. Só pelo fato de gerenciar memória não ser um grande problema em Java, já há um ganho significativo.

No caso do Visual Basic, também há ganho. O VB não era orientado a objetos e tinha um péssimo esquema de tratamento de erros. Também não era multi-plataforma.

No caso do Delphi, o ganho era realmente pequeno.

Porém, o Java entrou fortemente no mercado web, coisa que essas três linguagens deixaram muito à desejar. E, para quem desenvolvia na internet, o Java ganhou larga vantagem. O concorrente da época era o PHP, que não permitia modularização e orientação objeto até então, nem tinha o rigor sintático que um projeto realmente grande existe.

E, obviamente, se o Java não apresentasse ganho em relação a outras linguagens, dificilmente teria ganhado as proporções que tomou.

A pergunta é: Hoje em dia, o Java ainda é a linguagem mais vantajosa? É difícil dizer. Já existem concorrentes que estão de igual para igual. Um exemplo bastante citado é o Ruby, que para aplicações comerciais comuns, tem sido relatado como uma linguagem superior ao Java, ou as linguagens funcionais, que tem sido cada vez mais comentadas por aí.

pcassiano:

Você verificou aumento significativo em sua produtividade e/ou na performance de sua aplicação por usar uma linguagem em detrimento da outra?

O que esse cara tá falando é verdade: Java aumenta a eficiência do programador?

performance nao é um problema já que não tem a ver com a linguagem, hj em dia ate mesmo linguagens dinâmicas podem ser compiladas para bytecodes na jvm, mas produtividade sem duvida será aumentada se vc usa uma linguagem mais moderna que Java, em grande parte porque vc abre mão de toda complexidade sintática do Java mas não de todos os frameworks, apis e bibliotecas já existentes.

Ou seja, a JVM aumenta a produtividade do programador, não a linguagem Java, que pelo contrário, ultimamente tem sido mais malhada que Judas em final de ano.

Programação desktop ainda acho Delphi muito mais produtivo que Java. E a performance da aplicação cliente também. Mas quando precisei de ganhar escala programando 3 camadas, foi nítido a superioridade do Java.

Pra desenvolvimento Web, concordo com o colega acima, Delphi e VB não conseguiram passar a mesma produtividade pro ambiente web e o Java foi projetado pra isso.

Hoje em dia vejo muita gente falando em outras linguagens e elogiando, mas no mercado, pelo menos na minha região, raramente vejo um projeto que não seja Java, .NET ou legado Delphi. Por isso sempre achei mais lucrativo continuar investindo em Java e só estudar essas linguagens novas se um dia elas realmente ganharem mercado em escala, uma vez que aprender linguagem nova não é uma coisa tão demorada assim.

O cara fala em seu livro, obviamente, de Java + Flex. O fato de poder desenvolver para duas plataformas distintas usando uma única ferramenta (Eclipse) me agrada muito e, claro, me dá alguma vantagem “produdutiva”… porém ainda estou, digamos, “perplexo” de ele ter dito o que disse sobre a linguagem Java, quando existe uma leva de programadores que dizem o contrário… :shock:

Publicar um livro de Java pra malhar o Java não seria muito produtivo tb.

Sim, fato; só que “publicar um livro de Java ‘mentindo’” também não seria muito produtivo, seria?

Veja que coloquei o “mentindo” entre aspas, pois assim me pareceu…

E, sei lá, cada vez mais me convenço que “produtividade” e “eficiência” depende menos da tecnologia/linguagem/plataforma que de qualquer outra coisa… o que mais vejo são “comentários e mais comentários” dizendo que a tecnologia/linguagem/plataforma X é “mais produtiva” que Java, ou é “mais fácil que Java” etc, porém vi poucos benchmarks e, pior, ainda não pude eu mesmo comparar… por isso pedi “ajuda aos universitários”… :roll:

Enquanto não vejo nada que de facto me convença a “abandonar” Java, sinto-me tentado a prosseguir usando esta tecnologia/linguagem/plataforma… :twisted:

Sim, fato; só que "publicar um livro de Java ‘mentindo’ também não seria muito produtivo, seria?

Veja que coloquei o “mentindo” entre aspas, pois assim me pareceu…

E, sei lá, cada vez mais me convenço que “produtividade” e “eficiência” depende menos da tecnologia/linguagem/plataforma que de qualquer outra coisa… o que mais vejo são “comentários e mais comentários” dizendo que a tecnologia/linguagem/plataforma é “mais produtiva” que Java, ou é “mais fácil que Java” etc, porém vi poucos benchmarks e, pior, ainda não pude eu mesmo comparar… por isso pedi “ajuda aos universitários”… :roll:

Enquanto não vejo nada que de facto me convença a “abandonar” Java, sinto-me tentado a prosseguir usando esta tecnologia/linguagem/plataforma… :twisted:

Depende né… Como o Vini falou ali em cima, em Java vc não precisa ficar preocupado desalocando memória, já que isso é feito automaticamente.
Nesse caso a produtividade melhora bastante por causa da tecnologia empregada.

renamed:

Depende né… Como o Vini falou ali em cima, em Java vc não precisa ficar preocupado desalocando memória, já que isso é feito automaticamente.
Nesse caso a produtividade melhora bastante por causa da tecnologia empregada.

Isso é um recurso nativo da linguagem Java, porém entendo que “produtividade” tem a ver com o desenvolvimento da aplicação em si, aglidade para desenvolver e “entregar”, sem se preocupar com “detalhes” etc. Vale dizer que (chuto eu) 80% do que se produz em Java é para a Web, então, penso que um progrador “produtivo” é aquele que “entrega”, “mais e melhor”, aplicações web “prontas para o uso”…

Sobre este “entregar mais e melhor”, “de maneira mais simples” etc é que tem uma horda de programadores defendendo outras linguagens/plataformas mais, digamos “modernas” e “ágeis”… diferente do que fez o autor do livro, que está “defendendo” Java…

pcassiano:

renamed:

Depende né… Como o Vini falou ali em cima, em Java vc não precisa ficar preocupado desalocando memória, já que isso é feito automaticamente.
Nesse caso a produtividade melhora bastante por causa da tecnologia empregada.

Isso é um recurso nativo da linguagem Java, porém entendo que “produtividade” tem a ver com o desenvolvimento da aplicação em si, aglidade para desenvolver e “entregar”, sem se preocupar com “detalhes” etc. Vale dizer que (chuto eu) 80% do que se produz em Java é para a Web, então, penso que um progrador “produtivo” é aquele que “entrega”, “mais e melhor”, aplicações web “prontas para o uso”…

Sobre este “entregar mais e melhor”, “de maneira mais simples” etc é que tem uma horda de programadores defendendo outras linguagens/plataformas mais, digamos “modernas” e “ágeis”… diferente do que fez o autor do livro, que está “defendendo” Java…

Sim, é um recurso nativo. Logo, demonstra um amadurecimento e uma proposta (que com o tempo vimos que foi bem aceita) para evitar o vazamento de memória, grande problema de aplicações complexas feitas em C++.

No meu ponto de vista, não há como entregar “mais e melhor” sem se preocupar com detalhes como vazamento de memória, métodos de ordenação não eficientes (é muito mais rápido criar um bubble sort com complexidade exponencial do que um merge sort com complixidade logarítmica) etc.

Eu não sei quais outras linguagens vc está falando, mas acho que Java é uma linguagem mto boa para o que precisamos.
Se eu fosse apontar um problema em Java que não gosto, realmente é a falta de integração com o SO.

renamed:

Depende né… Como o Vini falou ali em cima, em Java vc não precisa ficar preocupado desalocando memória, já que isso é feito automaticamente.
Nesse caso a produtividade melhora bastante por causa da tecnologia empregada.

gerenciamento automático de memória foi inventado muito antes do Java e todas linguagens modernas são gerenciadas. Portanto esse argumento só serve para escolher entre Java e c++, enquanto o autor do tópico foi claro ao se referir a linguagens mais modernas como ruby, Python.

pcassiano:

Folheando o livro Beginning Java and Flex, li:

“… Developers should enjoy programming in Java and are often surprised at how fast they can obtain results. Studies have consistently shown that switching to the Java platform increases programmer efficiency. Java is a simple and elegant language that has a well-designed and intuitive set of APIs. Programmers write cleaner code with a lower bug count when compared with other languages, which in turn reduces development time…”.

Eu juro que está certo isso: o cara tá falando sobre Java! :shock:

Sei que tem gente aqui com bastante experiência em desenvolvimento e deploy de aplicações web tanto em Java quanto em outras linguagens/plataformas, como Ruby/Rails e Python/Django. A estes, pergunto:

Você verificou aumento significativo em sua produtividade e/ou na performance de sua aplicação por usar uma linguagem em detrimento da outra?

O que esse cara tá falando é verdade: Java aumenta a eficiência do programador?

A afirmação do autor não tem nada a ver com produtividade. O problema se prende com o mesmo assunto que é abordado em Effective Java. Effectiveness é a capacidade de escrever código limpo com pouco esforço.

java por ser fortemente tipado, compilado e ter uma vasta API permite que pouco codigo faça muito, mas faça com certeza. Linguagens de script nunca poderão competir com isto porque erros só aparecem em runtime. Mesmo com testes - que é a ferramenta preferida ao compilador para quem usa linguagens de script - existe a possibilidade de partes ou caminhos não testados que levam a resultados aburdos por falta de tipagem forte e checking em tempo de compilação.

Posto de outra forma, se o seu código java compila isso é meio caminho para que funcione. Isso não existem em linguagens de script.

Ué, mas não é justamente isso que a “turma da agilidade” diz ser possível conseguir com Ruby/Python e não com Java? :shock:

Eu posso até ter traduzido mal o termo, porém entendo que “produtividade”, “eficiência”, “performance”, “entregar mais, mais rápido e melhor” etc são coisas relacionadas…

sergiotaborda:

java permite que pouco codigo faça muito, mas faça com certeza. Linguagens de script nunca poderão competir com isto porque erros só aparecem em runtime.

que besteira,

cada linguagem nova que criam a primeira coisa que fazem é comparar o no. de linhas de código com o equivalente em Java. Ao contrario do que vc diz, fazer do programador uma babá do compilador é um dos principais problemas do Java no que tange a produtividade. Linguagens dinâmicas (não de script como vc se refere equivocadamente) não tem pretensao de substituir processos e boas praticas isso vc tem razao. Mas ao mesmo, qualquer um que tenha atuado no mercado java sabe que compilador naoajuda em nada os programas funcionarem corretamente.

sergiotaborda:

Posto de outra forma, se o seu código java compila isso é meio caminho para que funcione. Isso não existem em linguagens de script.

posto de outra forma, se o codigo compila vc ainda tem 50% de trabalho nao feito.

Não? Nossa, eu não sabia. Meu compilador sempre me ajudou, e muito.
Mas tem gente que usa reflexão de maneira desmedida por aí, e acaba perdendo muito dos benefícios dele.

De qualquer forma, você garante os outros 50%, já feitos. E nesse ponto concordo com o Sergio. Você não corre o risco do seu sistema capotar em runtime por causa de um erro de tipo, ou de digitação.

Não? Nossa, eu não sabia. Meu compilador sempre me ajudou, e muito.
Mas tem gente que usa reflexão de maneira desmedida por aí, e acaba perdendo muito dos benefícios dele.

De qualquer forma, você garante os outros 50%, já feitos. E nesse ponto concordo com o Sergio. Você não corre o risco do seu sistema capotar em runtime por causa de um erro de tipo, ou de digitação.

Problemas causados por erro de digitação ou tipos não contabiliza 50% do meu projeto.

No meu entendimento se vc usa compilador como ferramenta pra capturar bugs esta usando de forma errada. Compiladores acusam erros apenas como efeito colateral do seu trabalho que é converter um programa entre representações e portanto são péssimos substitutos dos testes automatizados.

mochuara:

Problemas causados por erro de digitação ou tipos não contabiliza 50% do meu projeto.

No meu entendimento se vc usa compilador como ferramenta pra capturar bugs esta usando de forma errada. Compiladores acusam erros apenas como efeito colateral do seu trabalho que é converter um programa entre representações e portanto são péssimos substitutos dos testes automatizados.

Eu acho que uma coisa não exclui a outra. Primeiro, porque os compiladores irão capturar erros sintáticos e léxicos, enquanto os testes unitários focam mais em erros semânticos. A tipagem em classes irá reforçar a semântica do seu código, e o compilador também te prevenirá contra um uso acidental.

Segundo, porque o compilador faz isso de maneira automática, sob toda a extensão do código, enquanto não há garantia de cobertura total em testes unitários, testes de integração, ou qualquer outro tipo de testes.

E terceiro, porque é muito rápido capturar o erro no compilador. Ele está associado à sua IDE, e pode ser ativado à qualquer momento, sem absolutamente nenhum esforço de programação.

Eu considero sua afirmação incompleta, o correto seria: “Se vc usa apenas compilador como ferramenta pra capturar bugs esta usando de forma errada.” Mesmo uma linguagem de estrutura mais forte não dispensa outros métodos, como os testes unitários, de integração, e mesmo testes de uso.

Ué, mas não é justamente isso que a “turma da agilidade” diz ser possível conseguir com Ruby/Python e não com Java? :shock:

Não.
O que vc consegue com essas linguagem e mais recursos da linguagem e outras API. Ou seja, apis que funcionam diferente das dos java e se encaixam de forma diferente. Ha preocupação em escrever pouco codigo e conseguir muito. Isto é o chamado ration feature per line of code (F/Loc) Em java este numero é baixo nas api padrão. (coisas como Method Chaining podem mudar isto de certa forma)

Tem muitas features por linha de codigo não é ter codigo limpo, não é ser efetivo, não é ser proficiente, não é ser agil nem é ser produtivo. Isto porque features por linha de codigo é uma caracterisica da linguagem, não do programador.

Em todas as linguagem vc pode criar codigo porco e codigo limpo. Mas criar codigo porco é mais dificil em algumas linguagens que em outras. É mais facil escrever codigo limpo usando OO que usando procedural. Testes unitários nem fazem sentido fora de OO (não existe a 'unidade")

Eu posso até ter traduzido mal o termo, porém entendo que “produtividade”, “eficiência”, “performance”, “entregar mais, mais rápido e melhor” etc são coisas relacionadas…

Não vejo assim.

Produtividade significa aumentar a velocidade = aumentar os SP por sprint. Isto advem não do programador mas de um conjunto de coisas. A produtividade do programador em si pode aumentar apenas aumentando o fator de foco ( o tempo em que realmente o cara está programando por dia) sem mexer na capacidade do cara ou na linguagem.
Eficiência é escrever codigo limpo. Corretamente escrito, que é inteligeivel. Que segue padrões de nomenclatura corretos , segue principios OO , etc… O codigo é tanto mais eficiente quanto mais simples de entender por uma pessoa que nunca o viu antes e quanto mais facil for modificável por outra pessoa que não o autor original.

Codigo limpo, e programação eficiente levam a aumento da produtividade.

Estas coisas são independentes da linguagem.

A ideia aqui é que java é uma linguagem onde escrever código limpo é fácil e incluir bugs é mais dificil.
bugs de tipagem não existem em java, só isso já cria uma familia de bugs enorme para as linguagens fracamente tipadas.

Linguagens com muita simbologia são mais difícil de ler porque ha muita informação numa unica linha, vc ainda pode criar codigo limpo com linguagens assim, apenas exige mais esforço e concentração e portanto podem causar mais erros por distração.

Não é por acaso que quem escolhe rubi escolhe tb testes unitários continuos. Pois sem eles os bugs seriam imensos e dificeis de encontrar e resolver. Em java isto pode ser feito mas é menos necessário: ou seja, em java ninguem escreve testes para verificar a tipagem correta.

Eu considero sua afirmação incompleta, o correto seria: “Se vc usa apenas compilador como ferramenta pra capturar bugs esta usando de forma errada.” Mesmo uma linguagem de estrutura mais forte não dispensa outros métodos, como os testes unitários, de integração, e mesmo testes de uso.

Acho que vc não entendeu. Compilador é ferramenta pobre para capturar erros da aplicação. Ele foi projetado para a linguagem, não para o programador.

Portanto se a linguagem requer compilação ótimo, senão requer melhor ainda porque é uma etapa amenos pra se preocupar.

Correto, mas capturar erros da linguagem é positivo, como o Sergio bem falou. É censo comum que um erro em tempo de compilaçao é muito menos caro do que em runtime. E etapa de compilação não é coisa pra se preocupar, porque em toda IDE é só pressionar uma tecla. :lol: E se der erro, é um erro que você conseguiu achar antes da execução, o que é ótimo!

Ficaria para a aplicação somente os erros semânticos que não pudessem ser detectados nos testes unitários. Mas pra esses, as linguagens de script também deixa passar.

Resumo
Linguagens de script: erros sintaticos em runtime e erros semânticos em runtime
Linguagens compiladas: erros sintaticos em designtime e erros semânticos em runtime

Concordo, nem sempre um código menos verboso é mais legível. Haja visto perl.

Não se esta discutindo se o compilador é positivo ou não. Se o compilador for necessário será distribuído junto com o sdk da linguagem. O javac por exemplo foi feito pra transformar código Java em bytecodes, apenas isso, mas se quer usar como ferramenta de teste, design ou qualquer coisa faca por sua conta e risco. O que não da pra levar a serio é alguém dizer que linguagens dinâmicas são limitadas porque não tem uma etapa de compilação.

Sem falar que seu resuminho não serve de nada no dia a dia de qualquer projeto Java com toneladas de código externalizado em xml e usando reflexão de classes em tempo de execução.

Podemos dizer que Java reúne o pior do dois mundos.

mochuara:

Podemos dizer que Java reúne o pior do dois mundos.

Java tem certa culpa na situação. Caso não tenha ficado claro, se vc defende que se confie ao compilador a tarefa de capturar erros da aplicação mas recorre a reflection api na primeira oportunidade que aparece vc entrou em contradição.