Merci Marc Bruxman, je partage votre avis, il faut savoir choisir le langage qu’on va utiliser en fonction de ce qu’on veut faire.

Certains langage permettent de faire certaines choses en quelques minutes avec très peu de lignes de codes alors qu’il faudrait plusieurs jours pour le coder avec un autre langage.
Et certains langage permettent d’introduire beaucoup moins d’erreur que d’autres et permettent de construire des applications très complexes (même avec des développeurs moyen).

Pourquoi passer trois jours a développer une application en C que l’on exécutera une fois en 1ms alors que l’on l’on peut faire en 3 minutes un script groovy qui s’exécutera en 1seconde mais fera la même choses.
A contrario essayer de développer une application très complexe avec de nombreux développeurs sans aucun typage ne serait pas plus intelligent. Le jour on l’on voudrait intégrer tout cela ensemble il y aurait des tas d’erreurs de partout sans que l’on puisse savoir d’où elles viennent.

Un bon nombre de vos commentaires laissent penser que vous imaginer que le développement ce résume à des applications clientes du type « word ».
Une grande partie des développements actuelles se concentrent en réalité sur des applications serveurs qui forment des systèmes complexes avec un grand nombre d’échanges de données.
Un techno comme java qui doit ça réputation de lenteur en grande partie à sa phase de démarrage en souffre beaucoup moins sur des applications qui ne s’arrêtent pas pendant plusieurs jours. Alors qu’une petite fuite mémoire C sur de telle application devient beaucoup plus problématique.

Les applications actuelles passent de main en main et même d’entreprise en entreprise. On développe et corrige certaines parties sans avoir le temps de savoir comment le reste fonctionne.
Alors oui il faut souvent mieux écrire un code clair que faire une optimisation qui sera efficace mais le rendra difficilement compréhensible.

Aucun développeur n’est parfait, il lui arrivera toujours de faire une petite erreur. Et si un langage permet d’en évité un grand nombre et évite de passer plusieurs semaines à comprendre d’où vient cette segmentation fault sur le système en production, alors ce langage à son intérêt, même s’il est plus lent.