Abstrações são passíveis de “vazamentos” e não-otimização, ou seja, você pode ter trabalho extra ao ter que lidar com suas inadequações, vide SQL/ORM, HTML+Javascript/(JSF,GWT,etc). Já evitá-las pode ser danoso se a rede de contextos pede soluções técnicas que acabam mais complexas numa linguagem/ecosistema não pensada (ou menos adaptável) para elas, podendo dar muito mais trabalho para reproduzir “aquele efeito novo” ou construirmos/usarmos abstrações (frameworks) que lhe criam ainda mais camadas intermediárias, onde gambiarras encontram terreno fértil…

Ao meu ver estamos numa época de transição (sempre estamos numa, mas ainda estamos esperando um novo bolsão de equilíbrio) e há muitas situações diferentes que podem ser resolvidas de diversas formas (“A verdade é uma terra sem caminho”, J. Krishnamurti), então, por exemplo, se vamos usar coisas como Ruby, gosto do que diz Uncle Bob, ele reconhece que é fácil fazer bagunça com ela (“Com grandes poderes…”), mas que aprendendo com os erros passados (ele se refere a “Smalltalk”) sabemos que isso pode ser extremamente minimizado com o uso de TDD (e outras técnicas ágeis, corroborando com o que diz o R. Pontes)… Agora, ocorre que isso também envolve mudanças num sub-contexto delicado e bastante conhecido por todos chamado “cabeça do desenvolvedor”…

A arte de resolver problemas, a inteligencia, o pensamento, é sempre o mesmo e é o mais importante, independente de linguagem. Linguagem é exercício, conceitos, paradigmas, se aprende, senta na cadeira e aprende.

Não conheço nenhuma linguagem que torne programadores ruins em bons programadores, que torne pessoas burras em inteligentes, e a contra-positiva também vale, se você é bom, se seu time é bom, inteligente, uma linguagem não vai tornar ele burro.

Ou talvez os conheça bem demais! rs.

Eu sou particularmente contra a adoção de uma unica plataforma por motivo de facilitar o controle, em desenvolvimento esse tipo de mentalidade não deu certo com raríssimas exceções, o ideal é utilizar a ferramenta certa no lugar certo sempre.

Em termos de linguagens estáticas e dinamicas cada qual tem seu uso adequado, inclusive plataforma.

Pelo contrário, deve ser mais seguro desenvolver em Fortran do que em Asembly. Os compiladores Fortran geram código assembly tão bons ou até mais otimizados do que se feitos um programador, abstraindo detalhes da máquina como registradores de CPU. Claro que não estou falando de somar A + B, mas programas complexos de um modo geral.

2 – “Aí veio o pessoal do C/C++ dizendo que Java abstraía demais, deixando margens a bugs serem introduzidos nos programas pelo compilador e/ou pela vm ou porquê simplesmente ele não estava alocando/desalocando memória manualmente.”

Mais uma vez é o contrário: é mais seguro desenvolver em Java do que em C++. Preciso falar do famigerado “segmentation fault”?

3 – “Linguagens dinâmicas dão maiores possibilidades de inclusão de erro no código com isso aumentando de forma significativa a refatoração”

Sim, acredito nessa afirmação. É fácil perceber que linguagens estáticas privilegiam “safety” e linguagens dinâmicas “liveness”. Vejam o exemplo:

linguagem estática X – function somar(int a, int b)
linguagem dinâmica Y – function somar(var a, var b)

Se forem passados argumentos do tipo string, apenas a linguagem Y vai executar. Porém a linguagem X fará a verificação de tipos, antecipando a correção de erros.

Não estou dizendo que linguagens estáticas são melhores ou mais produtivas, apenas que são mais seguras por conta das verificações de tipo.

Hoje um bom desenvolvedor tem que saber utilizar a ferramenta certa para o problema específico. A briga está mesmo para valer a pena em Plataforma A x Plataforma B, linguagem já não é mais tão importante assim.

Hoje o poder e a necessidade de integrar várias linguagens em várias plataformas está bem maior.

E lembrando uma frase: “Não existe bala de prata !”. Isso é fato.

Boa colocação do Delberto

Enfim, post sucinto mas bem colocado.