Quando eu era estudante não entendia porque o programador batia no peito e sentia orgulhoso ao dizer que programava em Java. O ego do programador Java sempre me transmitia de uma pessoa algumas vezes não muito agradável e que acha que sabe tudo. Comecei a trajetória com PL/SQL, quando era secundarista, e depois com PHP, no inicio da faculdade. O PL/SQL foi substituido pelo PHP nos aplicativos WEB porque o código do PL/SQL exibia as variáveis na opção de exibir código fonte. Trabalhei com API's que imprimiam no browser via comando "http.print('');" em PL/SQL.
Quando comecei a trabalhar com PHP percebia que o desenvolvimento em PHP era muito mais rápido apesar do Java ser um pouco mais seguro e verboso e por isso mais lento de se desenvolver. Você faz uma linha em PHP para escrever três em Java para executar uma mesma operação e isso me parecia lento.
Quando comecei a trabalhar com Java falei aos programadores mais antigos que não achava que Java fosse tudo aquilo que se falava. Acabei ouvindo frases como "você não sabe o que está falando" e também ouvi uma que nunca que esqueci: "quando você começar a andar pelas empresas e ver o cenário de caos você vai entender o que é o Java". Bom, o cenário de caos apareceu.
Continuo achando que o PHP é mais rápido para pequenos sites, mas tudo depende também do cenário. Hoje, existe uma euforia criada pelo "two way data bind do Angularjs" que parece ser interessante. Porém o PL/SQL se mostrou extremamente fraco para desenvolvimento em equipe. Existem duas grandes questões para essa fraqueza que seriam as ferramentas utilizadas para SVN e GIT que na grande maioria não possuem uma opção de merge que funcione como a do Eclipse (mesmo as Eclipse based) e a segunda seria o problema da Integração Contínua e quem já programou em Java sabe do que estou falando.
Na pratica arquivos são alterados e jogados diretamente em produção e o GIT acaba não sendo atualizado e isso jamais aconteceria com o Java porque o processo de Integração Continua garante que o arquivo alterado seja atualizado primeiro na base de homologação, depois seja testado e atualizado na base produtiva. No PHP a Integração Continua talvez nem faça sentido já que não é necessário criar um arquivo *.WAR. Mas como compilar o código para criar uma nova base em PL/SQL puro? E como fazer com os dados? Não encontrei nenhuma forma eficiente, mesmo que se fizesse utilizando Shellscript. E se a rede for baseada em Windows então?
A escolha da linguagem também depende do cenário, da necessidade ou possibilidade de investimento, se a aplicação vai ficar restrita em uma rede interna ou se vai ficar em rede aberta, se deve rodar no browser ou no desktop, no computador, no tablet, no celular ou em algum coletor de dados. Para tanto o Java é a única linguagem que oferece suporte para qualquer aplicação seja no Windows, no Linux ou no Mac.
Comparado o Java com o PHP, pode ser que com PHP seja mais rápido fazer uma aplicação pequena, mas se aplicação depender de muitas conexões somente o Java poderá gerenciar um Pool de conexões para um grande volume de usuários. E tem ainda a questão das Threads (processamento concorrente) que só existem em Java. Mesmo a comunicação via Serial/USB possui uma biblioteca rxtx específica em Java, a única linguagem que chega mais perto com exceção de C é o Python, porém o Java depois que fecha uma conexão via rxtx em uma porta bloqueia outras requisições na mesma porta ate o encerramento da mesma e o Python permite que vários aplicativos se comuniquem nesta mesma porta utilizada o que pode gerar um "crush" de informações.
O Ruby on Rails quando foi lançado ganhou mercado por já ser Orientado a Objetos e por ser 20 vezes mais rápido que o Java em alguns testes. Foi quando lançaram a segunda versão do compilador e as aplicações começaram a parar porque o compilador havia sido alterado e alguns comandos não possuíam mais suporte. E quando lançaram a terceira versão do compilador aconteceu novamente.
Voltando ao Java, na verdade a grande pergunta que todo o desenvolvedor Java faz a si mesmo e aos companheiros é: "afinal, se você tivesse que iniciar um projeto Java hoje, que tecnologias você usaria?" e essa é a grande questão.
Há um ano atrás eu provavelmente jamais escolheria o Angularjs, porém o tempo tem se mostrado a favor e muitas empresas estão decidindo utilizar o Angularjs no front-end com o Java no back-end. Foi lançado recentemente a versão 2.0 e parece que ambas as versões podem funcionar simultaneamente e o fato do código ser mantido pela Google traz um pouco de tranquilidade. Já no back-end se desenvolveu uma nova forma de trabalhar e ao invés de se programar com um simples MVC está sendo usado Rest antes da camada de modelo. O próprio Spring pode ser desbravado com ou sem o Hibernate e agora existe a opção do Rest junto a tudo isso. Como o Angularjs trabalha com a opção de envio de um único objeto em JSON para o back-end então existe a necessidade de se transformar o JSON em um objeto para a camada de service e essa opção pode ser dada por algumas bibliotecas como JAXB na camada service ou outra opção JAX-RS na camada de modelo.
O fato é que Java é Java. E a pergunta continua: "afinal, se você tivesse que iniciar um projeto Java hoje, que tecnologias você usaria?"
Quando comecei a trabalhar com PHP percebia que o desenvolvimento em PHP era muito mais rápido apesar do Java ser um pouco mais seguro e verboso e por isso mais lento de se desenvolver. Você faz uma linha em PHP para escrever três em Java para executar uma mesma operação e isso me parecia lento.
Quando comecei a trabalhar com Java falei aos programadores mais antigos que não achava que Java fosse tudo aquilo que se falava. Acabei ouvindo frases como "você não sabe o que está falando" e também ouvi uma que nunca que esqueci: "quando você começar a andar pelas empresas e ver o cenário de caos você vai entender o que é o Java". Bom, o cenário de caos apareceu.
Continuo achando que o PHP é mais rápido para pequenos sites, mas tudo depende também do cenário. Hoje, existe uma euforia criada pelo "two way data bind do Angularjs" que parece ser interessante. Porém o PL/SQL se mostrou extremamente fraco para desenvolvimento em equipe. Existem duas grandes questões para essa fraqueza que seriam as ferramentas utilizadas para SVN e GIT que na grande maioria não possuem uma opção de merge que funcione como a do Eclipse (mesmo as Eclipse based) e a segunda seria o problema da Integração Contínua e quem já programou em Java sabe do que estou falando.
Na pratica arquivos são alterados e jogados diretamente em produção e o GIT acaba não sendo atualizado e isso jamais aconteceria com o Java porque o processo de Integração Continua garante que o arquivo alterado seja atualizado primeiro na base de homologação, depois seja testado e atualizado na base produtiva. No PHP a Integração Continua talvez nem faça sentido já que não é necessário criar um arquivo *.WAR. Mas como compilar o código para criar uma nova base em PL/SQL puro? E como fazer com os dados? Não encontrei nenhuma forma eficiente, mesmo que se fizesse utilizando Shellscript. E se a rede for baseada em Windows então?
A escolha da linguagem também depende do cenário, da necessidade ou possibilidade de investimento, se a aplicação vai ficar restrita em uma rede interna ou se vai ficar em rede aberta, se deve rodar no browser ou no desktop, no computador, no tablet, no celular ou em algum coletor de dados. Para tanto o Java é a única linguagem que oferece suporte para qualquer aplicação seja no Windows, no Linux ou no Mac.
Comparado o Java com o PHP, pode ser que com PHP seja mais rápido fazer uma aplicação pequena, mas se aplicação depender de muitas conexões somente o Java poderá gerenciar um Pool de conexões para um grande volume de usuários. E tem ainda a questão das Threads (processamento concorrente) que só existem em Java. Mesmo a comunicação via Serial/USB possui uma biblioteca rxtx específica em Java, a única linguagem que chega mais perto com exceção de C é o Python, porém o Java depois que fecha uma conexão via rxtx em uma porta bloqueia outras requisições na mesma porta ate o encerramento da mesma e o Python permite que vários aplicativos se comuniquem nesta mesma porta utilizada o que pode gerar um "crush" de informações.
O Ruby on Rails quando foi lançado ganhou mercado por já ser Orientado a Objetos e por ser 20 vezes mais rápido que o Java em alguns testes. Foi quando lançaram a segunda versão do compilador e as aplicações começaram a parar porque o compilador havia sido alterado e alguns comandos não possuíam mais suporte. E quando lançaram a terceira versão do compilador aconteceu novamente.
Voltando ao Java, na verdade a grande pergunta que todo o desenvolvedor Java faz a si mesmo e aos companheiros é: "afinal, se você tivesse que iniciar um projeto Java hoje, que tecnologias você usaria?" e essa é a grande questão.
Há um ano atrás eu provavelmente jamais escolheria o Angularjs, porém o tempo tem se mostrado a favor e muitas empresas estão decidindo utilizar o Angularjs no front-end com o Java no back-end. Foi lançado recentemente a versão 2.0 e parece que ambas as versões podem funcionar simultaneamente e o fato do código ser mantido pela Google traz um pouco de tranquilidade. Já no back-end se desenvolveu uma nova forma de trabalhar e ao invés de se programar com um simples MVC está sendo usado Rest antes da camada de modelo. O próprio Spring pode ser desbravado com ou sem o Hibernate e agora existe a opção do Rest junto a tudo isso. Como o Angularjs trabalha com a opção de envio de um único objeto em JSON para o back-end então existe a necessidade de se transformar o JSON em um objeto para a camada de service e essa opção pode ser dada por algumas bibliotecas como JAXB na camada service ou outra opção JAX-RS na camada de modelo.
O fato é que Java é Java. E a pergunta continua: "afinal, se você tivesse que iniciar um projeto Java hoje, que tecnologias você usaria?"
Nenhum comentário:
Postar um comentário