Novas tendências em programação
“Artigo sobre as novas tendências em programação. Se você gosta de novidades na área o artigo é um parque de diversões. Trata de Java DB, Google Gears, Groovy, GridGain, Scala e Erlang.”
Enviado por Cid Rodrigues de Andrade (falecomΘcidandrade·pro·br) - referência (blog.cidandrade.pro.br).
(postado por Augusto Campos)
Comentários dos leitores
Comentário de Bruno Laturner
24/09/07 10:44 - usuário registrado #4102
O futuro: O artigo confirma umas suspeitas que venho tendo:
- The One Platform to Rule Them All: Linguagens, ou mais exatamente implementações oficiais/de fato de linguagens, em Java Virtual Machine, e consequentemente, interoperáveis com o Java (e seus bilhões de classes oficiais).
- Complementares ao Java: Fazem tudo o que Java não faz muito bem, ou que requer muito hacking/verbosidade pra chegar à um resultado parecido (e inferior).
- Domain Specific Languages, todas transparentemente plugáveis nessas linguagens descritas acima; e de forma padronizada: uma DSL pode ser usada em qualquer linguagem, sem qualquer mudança. (OK, não está no artigo mas é que eu acho)
Comentário de LKRaider
24/09/07 13:00 - usuário registrado #14432
Só Java?: Interessante, pena que o artigo não conseguiu se distanciar do mundo Java.
Melhor mudar o título para "Novas tendências em programação Java".
Melhor mudar o título para "Novas tendências em programação Java".
Comentário de Sonolento
24/09/07 13:27
O pior do java é isso, não: O pior do java é isso, não são algumas deficiencias da linguagem, a exigencias de recursos nem nenhum outro aspecto técnico.
A JVM é ótima, torço para que invistam mais no Jython ou criem outra implementação de python bem atualizada que use a JVM.
Voltando...
O problema do Java são seus fãs. O "java político". O java cria várias especificações, muitas são uma gigantesta burocracia, mas algumas especificações são excelentes. O problema é que eles implementam essas especificações criam várias dependências de estruturas que só o ambiente java dispõe. Inviabilizando que outras linguagens as implementem.
Fora a questão de pegarem algo que já existe, criarem uma especificação versão "mundo Java" e lançarem como uma suuuper novidade.
Daí você diz... "ok, que me importa, não uso java, eles que se f..." Nã nã ni na não.....
Como java é a linguagem do momento, que os Gerentes de TI amam, muitas das coisas criadas nessas especificações se tornam um "must have".
Daí vê fala de Python, Ruby, etc e seu gerente diz "O que, essa tal novidade aí não implementa JMX?? Nossa, que porcaria, não serve pra nada."
Gerente tacanha esse. Sim, mas sabe como é, ser ignorante e medíocre exige muito menos esforço que pensar ;)
A JVM é ótima, torço para que invistam mais no Jython ou criem outra implementação de python bem atualizada que use a JVM.
Voltando...
O problema do Java são seus fãs. O "java político". O java cria várias especificações, muitas são uma gigantesta burocracia, mas algumas especificações são excelentes. O problema é que eles implementam essas especificações criam várias dependências de estruturas que só o ambiente java dispõe. Inviabilizando que outras linguagens as implementem.
Fora a questão de pegarem algo que já existe, criarem uma especificação versão "mundo Java" e lançarem como uma suuuper novidade.
Daí você diz... "ok, que me importa, não uso java, eles que se f..." Nã nã ni na não.....
Como java é a linguagem do momento, que os Gerentes de TI amam, muitas das coisas criadas nessas especificações se tornam um "must have".
Daí vê fala de Python, Ruby, etc e seu gerente diz "O que, essa tal novidade aí não implementa JMX?? Nossa, que porcaria, não serve pra nada."
Gerente tacanha esse. Sim, mas sabe como é, ser ignorante e medíocre exige muito menos esforço que pensar ;)
Comentário de Copernico Vespucio
28/09/07 15:52 - usuário registrado #4868
Especificações Java:
Em toda plataforma com certa idade (ou melhor, maturidade) e que busca sempre uma solução melhor para seus problemas, sempre surgirá esse tipo de problema: idéias menos do que ideais fazendo escola ao cobrir um nicho onde há falta de coisa melhor. Soluções sendo empurradas "assim porque sim" porque há gente ingênua e mal preparada ávida por encontrar martelos dourados que sirvam para bater seus pregos.
Esse tipo de coisa existe no Linux, por exemplo! :)
No entanto, na comunidade Java existe uma coisa muito positiva, já testada pela natureza e comentada por Darwin, chamada "seleção natural".
Temos via de regra uma especificação oficial (JCP) para cada coisa. Ela nem sempre é a melhor (ex.: EJB 2.1 ou abaixo), mas costuma ser a mais "sóbria" existente no momento. Isso evita que o "batuque do afro-brasileiro insano" tome conta do cenário e tudo vire uma Babel das "melhores idéias da última semana".
A especificação oficial fica no trono até que uma idéia independente ganhe maturidade e tome conta do cenário o suficiente para derrubá-la dele. Daí se cria uma especificação que normatize a nova solução. Foi o que aconteceu, por exemplo com Hibernate e JPA. E eu particularmente acho esse um bom processo. Desenvolvedores Java sempre mantém o conceito de "aderência a padrões" ecoando na mente.
Eu acho que ainda bem que existe uma política, ao invés do balaio de mil gatos que vejo em outras plataformas. Ainda que toda a política seja invariavelmente chata, a alternativa é pior...
Há um erro sério aí... Seguindo o seu exemplo, o que se entende por "JMX" (Java Management eXtension) é apenas a especificação Java para implementação do protocolo público SNMP (Simple Network Management Protocol), que é usado a muito tempo mesmo no gerenciamento de sistemas (creio eu que antes da plataforma Java aparecer). E ele realmente acrescenta valor agregado a sistemas corporativos (permitindo auditar seu processamento a partir de qualquer ferramenta aderente ao protocolo - não necessariamente feita em Java - e alterar as configurações do sistema "on the fly").
A plataforma Java hoje é uma das poucas que implementa o protocolo de forma satisfatória. Mas ele continua sendo público. Pare de reclamar e implemente-o em sua linguagem preferida. Não enxergo essa "impossibilidade de implementação" em nenhum caso em que consigo pensar.
Isso é uma constante na comunidade Java. A maioria das vantagens competitivas da plataforma são apenas fruto de um trabalho de normatização e implementação de padrões públicos e que gozam de grande aceitação na indústria. Não foi a comunidade Java, por exemplo, que criou o conceito de WebServices, mas creio eu que é em Java que existe a melhor implementação desses padrões.
Java é uma plataforma que venceu com justiça um processo de "seleção natural". Muitos dos seus "oponentes" de antes hoje em dia repoduzem muitas de suas idéias e conceitos (as vezes, reproduzem tudo!). É por esse motivo que muitas soluções estão se desenvolvendo em torno dela, ao invés de em paralelo.
Ainda no uso desse exemplo, se (e somente se) o SNMP é uma vantagem ao atender a um requesito não funcional desejado para o sistema, ele está certo e você errado.
Se ele não tem necessidade do SNMP hoje, mas poderá ter amanhã e não quer arcar com custos de migração, ele está certo e você errado.
Se ele quer garantir o uso do protocolo porque o arquiteto ou empresa de consultoria que ele *paga* diz que é uma boa idéia (arquiteto ou consultoria que se supõe estar fazendo corretamente o seu trabalho), ele está certo e você errado.
Não espere que um arquiteto desista de uma funcionalidade interessante para o sistema só porque a plataforma de sua preferência não a implementa da forma competitiva.
java cria várias especificações, muitas são uma gigantesta burocracia
Em toda plataforma com certa idade (ou melhor, maturidade) e que busca sempre uma solução melhor para seus problemas, sempre surgirá esse tipo de problema: idéias menos do que ideais fazendo escola ao cobrir um nicho onde há falta de coisa melhor. Soluções sendo empurradas "assim porque sim" porque há gente ingênua e mal preparada ávida por encontrar martelos dourados que sirvam para bater seus pregos.
Esse tipo de coisa existe no Linux, por exemplo! :)
No entanto, na comunidade Java existe uma coisa muito positiva, já testada pela natureza e comentada por Darwin, chamada "seleção natural".
Temos via de regra uma especificação oficial (JCP) para cada coisa. Ela nem sempre é a melhor (ex.: EJB 2.1 ou abaixo), mas costuma ser a mais "sóbria" existente no momento. Isso evita que o "batuque do afro-brasileiro insano" tome conta do cenário e tudo vire uma Babel das "melhores idéias da última semana".
A especificação oficial fica no trono até que uma idéia independente ganhe maturidade e tome conta do cenário o suficiente para derrubá-la dele. Daí se cria uma especificação que normatize a nova solução. Foi o que aconteceu, por exemplo com Hibernate e JPA. E eu particularmente acho esse um bom processo. Desenvolvedores Java sempre mantém o conceito de "aderência a padrões" ecoando na mente.
Eu acho que ainda bem que existe uma política, ao invés do balaio de mil gatos que vejo em outras plataformas. Ainda que toda a política seja invariavelmente chata, a alternativa é pior...
Daí vê fala de Python, Ruby, etc e seu gerente diz "O que, essa tal novidade aí não implementa JMX?? Nossa, que porcaria, não serve pra nada."
Há um erro sério aí... Seguindo o seu exemplo, o que se entende por "JMX" (Java Management eXtension) é apenas a especificação Java para implementação do protocolo público SNMP (Simple Network Management Protocol), que é usado a muito tempo mesmo no gerenciamento de sistemas (creio eu que antes da plataforma Java aparecer). E ele realmente acrescenta valor agregado a sistemas corporativos (permitindo auditar seu processamento a partir de qualquer ferramenta aderente ao protocolo - não necessariamente feita em Java - e alterar as configurações do sistema "on the fly").
A plataforma Java hoje é uma das poucas que implementa o protocolo de forma satisfatória. Mas ele continua sendo público. Pare de reclamar e implemente-o em sua linguagem preferida. Não enxergo essa "impossibilidade de implementação" em nenhum caso em que consigo pensar.
Isso é uma constante na comunidade Java. A maioria das vantagens competitivas da plataforma são apenas fruto de um trabalho de normatização e implementação de padrões públicos e que gozam de grande aceitação na indústria. Não foi a comunidade Java, por exemplo, que criou o conceito de WebServices, mas creio eu que é em Java que existe a melhor implementação desses padrões.
Java é uma plataforma que venceu com justiça um processo de "seleção natural". Muitos dos seus "oponentes" de antes hoje em dia repoduzem muitas de suas idéias e conceitos (as vezes, reproduzem tudo!). É por esse motivo que muitas soluções estão se desenvolvendo em torno dela, ao invés de em paralelo.
Gerente tacanha esse. Sim, mas sabe como é, ser ignorante e medíocre exige muito menos esforço que pensar ;)
Ainda no uso desse exemplo, se (e somente se) o SNMP é uma vantagem ao atender a um requesito não funcional desejado para o sistema, ele está certo e você errado.
Se ele não tem necessidade do SNMP hoje, mas poderá ter amanhã e não quer arcar com custos de migração, ele está certo e você errado.
Se ele quer garantir o uso do protocolo porque o arquiteto ou empresa de consultoria que ele *paga* diz que é uma boa idéia (arquiteto ou consultoria que se supõe estar fazendo corretamente o seu trabalho), ele está certo e você errado.
Não espere que um arquiteto desista de uma funcionalidade interessante para o sistema só porque a plataforma de sua preferência não a implementa da forma competitiva.