Um amigo fez a seguinte pergunta que é muito comum hoje em dia com adoção crescente sobre linguagens dinâmicas, principalmente Ruby:
(…)”A dúvida era essa: Linguagens dinâmicas dão maiores possibilidades de inclusão de erro no código com isso aumentando de forma significativa a refatoração.”(…)
Em conversa com um excelente desenvolvedor aqui no Ceará, Delberto Muniz, ele escreveu a seguinte resposta:
Estava relendo um livro sobre os primórdios da programação e houve um debate semelhante: Os programadores Assembly achavam que programar em Fortan dava maiores possibilidades de erros porquê o programador não tinha total controle sobre o código gerado.
Dez anos depois o pessoal do Fortran falou mal do Algol porquê Algol abstraía demais e o programador não tinha total controle sobre a linguagem.
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.
Só mudaram as linguagens – o debate é sempre o mesmo: Se eu aumentar a abstração, meus programadores vão fazer besteira?
Se você está com essa dúvida, sinto muito: Você está nivelando por baixo e/ou não conhece seus desenvolvedores.
Typically chemist’s shop can sale to you with discreet treatments for various heartiness problems. There are numerous of safe online pharmacies that will deliver medications to your address. There are divers medicines for each afflictions. Learn more about “viagra manufacturer coupon“. Maybe “viagra discount coupons” is a so complicated matter. Matters, like “coupons for viagra“, are coupled numerous types of soundness problems. If you need to take recipe medications, ask your dispenser to check your testosterone levels before. Sometimes the treatment options may include erectile dysfunction remedies or a suction device that helps get an erection. Keep in mind web-site which is ready to sell erectile malfunction drugs like Viagra without a prescription is fraudulent. When you purchase from an unknown web-site, you run the risk of getting counterfeit remedies.
Na verdade, eu acredito que além do conhecimento da linguagem -não necessariamente um expert- o desenvolvedor precisa, principalmente, ter uma cultura mais ágil (TDD, design incremental e iterativo, baby steps etc) e ter bons conhecimentos sobre design de software (OOP, SOLID Principles etc). Assim, por mais que o desenvolvedor troque de linguagem ou mesmo plataforma ele saberá desenvolver software de qualidade.
Enfim, post sucinto mas bem colocado.
Sempre existiu e sempre vai existir essa briga LinguagemY x Linguagem Z.
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 😉
Excelente observação do Delberto Muniz, esse tipo de argumento é totalmente errado! Por isso hoje muitas empresas, inclusive a Microsoft e Sun investem em linguagens como Ruby e Python, na verdade a própria Microsoft vem modificando o C# para ter mais recursos de outras linguagens. A CLR já possui suporte para implementação de tais mudanças. As tecnologias evoluem, as linguagens de programação também e melhorar os níveis de abstração delas é algo essencial, usamos isso no nosso dia a dia com implementação de DSLs como a que vemos no Rails.
Pingback: Tweets that mention Milfont.org Ultrapassando os limites da WEB -- Topsy.com
1 – “Os programadores Assembly achavam que programar em Fortan dava maiores possibilidades de erros porquê o programador não tinha total controle sobre o código gerado.”
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.
Fábio, o ponto é que a argumentação segue sempre uma rotina ao longo do tempo: as dúvidas são de desconhecimento da nova plataforma/linguagem/comunidade/whatever por comodidade, simplesmente querem uma resposta pronta que não existe.
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.
“Se você está com essa dúvida, sinto muito: Você está nivelando por baixo e/ou não conhece seus desenvolvedores.”
Ou talvez os conheça bem demais! rs.
É por aí mesmo.
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.
Depende muito do contexto, diria até de uma rede de contextos formada de vários sub-contextos (“Small Worlds”) como contextos econômicos, culturais, estéticos, acadêmicos, de infra-estrutura, etc.
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”…