Étant développeur Ada depuis plus de 10 ans, je ne trouve pas qu'Ada soit si « extrême » que ça, ni difficile, mais c'est peut-être une déformation professionnelle de ma part... Je ne me considère pas guru en Ada.
Il y a le côté fortement typé du langage : au début, quand on vient du C/C++ ou Java, c'est nouveau et ça peut paraître plus difficile, mais rapidement on s'aperçoit que ça fait gagner du temps, car on peut borner beaucoup plus facilement le code à des plages de valeurs restreintes à son besoin, et empêcher de manipuler les variables n'importe comment. En C/C++ ou Java, t'es obligé de tester que ton argument d'entrée "int", "float" ou autre primitive, est correctement borné par rapport à ton attente. Parfois tu ne le fais pas, en te disant que ça a déjà été vérifié plus en amont dans le code, mais parfois tu te loupes (ou parce que soudain ta fonction est appelée d'ailleurs, sans vérification). En Ada, pas de soucis à se faire là-dessus. En fait, le code critique sera celui de la conversion de ta donnée d'entrée en donnée typée (c'est là que tu dois gérer les cas d'erreur possibles), mais il sera alors bien localisé, là où dans d'autres langages ça peut être plus flou (ou plus expéditif... avec son lot de bugs). Aujourd'hui, quand je manipule des variables de type primitives en C/C++/Java, j'ai vraiment l'impression de travailler sans filet de sécurité.
Mon point de vue maintenant sur les temps de développement, à partir de mon expérience perso. Je dirais que chaque langage a ses points forts (où l'on gagne du temps) et ses points faibles (où l'on perd du temps) et j'aurais bien du mal à les classer par ordre d'une manière générale.
Java
Le côté dynamique de Java permet de démarrer le codage très rapidement. Écrire et exécuter un test unitaire dans Eclipse est extrêmement facile et rapide, et c'est très agréable. Tester la couverture de code sans son IDE également. La compilation est également rapide, les messages d'erreur suffisamment clairs pour comprendre ce qui ne va pas. Les conventions de nommage (voire de codage) fortement imposées permettent d'écarter les questions de base philosophiques qui font perdre du temps pour rien. Bref tu lance ton IDE, Nouveau Projet, et c'est parti !
Le runtime Java est plutôt bien fourni, ça aide à coder rapidement également.
Beaucoup de bibliothèques existantes, mais parfois en terme de dépendances, on a l'impression de tirer la mer et les poissons. Quand on travail sur des systèmes critiques où il faut maîtriser toutes les dépendances, il faut parfois apprendre à s'en passer (pareil pour les potentielles galères de licences).
Là où ça se gâte à mon sens, c'est sur la partie packaging/déploiement, qui quand elle tourne mal, peut faire perdre pas mal de temps qu'on avait gagné en codage (et en général c'est pour des conneries). Certains outils sont censés simplifier ça en imposant une certaine structure (genre maven), mais d'une part je ne trouve pas la syntaxe de ces outils très fluide à manipuler, d'autre part, je suis souvent bloqué par un firewall très filtrant et je dois donc m'organiser comme si j'étais offline 100% du temps. Et là, ça coûte en temps pour la mise en place d'un environnement maven/nexus, l'import des dépendances (qui est devenu galère dans nexus 3), etc. Sur un gros projet, ces coûts pourront s'absorber, mais sur des petits programmes, ça peut parfois coûter plus que le temps de codage.
Autre point ennuyant, c'est pour faire un simple programme, là où en C, C++ ou Ada tu obtiens un binaire prêt à l'emploi, avec Java t'as un ou plusieurs jar, qu'il faut lier en général avec un script de lancement, tout en s'assurant d'avoir le bon JRE, le bon environnement, etc., bref un peu pénible à gérer.
Ada
En Ada, le côté verbeux rend forcément l'écriture de code plus lente (c'est tout de même atténué grâce à la complétion auto de l'IDE). Mais en même temps, c'est bien rare que j'arrive, dans n'importe quel langage, à écrire une fonction d'une traite de bout en bout sans me poser et réfléchir entre deux lignes.
La séparation entre spec (header) et body (source) prends également du temps. Elle permet toutefois de bien séparer le contrat de l'implémentation (pratique pour faire du logiciel propriétaire ;-)). En Java, il n'y a que le code, et le côté dynamique du langage permet d'en extraire les signatures de classes facilement, reste la javadoc, qu'il faut fournir « à côté », là où en Ada on peut se contenter de lire les commentaires présents dans le fichier spec. En C++, c'est la fête du slip.
La structure d'un programme Ada, en packages, présente les mêmes avantages que Java en terme d'organisation de code, et les packages s'importent simplement comme en Java, dans l'ordre qu'on veut. Le temps de compilation est généralement assez rapide (sauf cas particuliers), un peu comme en C je dirais, mais plus lent que Java.
Le runtime Ada s'est pas mal étoffé ces dernières années, et propose pas mal de choses.
Il n'existe pas beaucoup de bibliothèques en Ada, mais on peu faire des bindings avec les bibliothèques C assez efficacement (ça prend un peu de temps de développement).
Côté outils, Ada étant un langage de niche, il n'y en a pas 36, du coup on perds pas beaucoup de temps à choisir ;), mais on trouve généralement ce qu'il faut.
L'IDE, GNAT Programming Studio (GPS), commence à être vraiment pas mal.
Enfin, concernant la fabrication, là c'est c'est vraiment excellent. La description des projets dans des fichiers « .gpr » surpasse de loin tout ce que j'ai vu (Makefile, CMake & co) en terme de clarté, simplicité, rapidité à écrire et maintenir, réutilisation par divers outils (compilateur, IDE, analyseurs, ...). En plus, ça marche aussi pour d'autres langages comme C et C++ (ou pour mixer plusieurs langages).
C++
Bon là je vais être méchant, et ça me rend bien triste. J'ai commencé la programmation avec C++, et j'étais fan de ce langage, mais je n'en ai pas fait beaucoup durant cette décennie. De temps en temps, j'essaie d'en refaire un peu histoire de pas trop perdre la main.
Quand aujourd'hui je compare le C++ à Java ou Ada, je trouve que :
C'est un langage syntaxiquement compliqué. La STL me paraît également compliquée, et limitée. Il y a certaines fonctionnalités que je ne trouve pas alors que je les aurait facilement trouvées en Java ou Ada, ou alors elles existent mais sous une autre forme, propre au C++, mais donc je perds du temps à essayer de les trouver (je suis peut-être trop formaté Ada/Java). Aussi, peut-être je n'utilise pas les bons outils, mais voici un exemple de ce que me propose Eclipse lorsque je place le curseur sur ma variable de style vector:
Ça m'est totalement obscur. Voir ça en 2019 m'a fortement déçu sur l'évolution de C++ et de son écosystème. Et le bout de code en exemple, je l'ai trouvé sur le net. Tout seul je n'aurais pas su l'écrire, et d'ailleurs j'ai encore du mal comprendre comment il fonctionne (!), ce qui m'inquiète beaucoup.
Aussi je perds pas mal de temps à comprendre certains messages d'erreur de gcc (quand c'est pas de la bouillie templatique).
D'un point de vue organisation du code, à cause du mécanisme archaïque des includes, c'est bordélique. Il faut les mettre dans le bon ordre sinon ça pète. Un truc comme ça en 2019 c'est vraiment difficile à supporter.
La séparation déclaration/implémentation entre header et source n'est jamais claire, puisqu'on trouve du code dans les headers, partiellement ou complètement. Et honnêtement, je passe (perds) souvent du temps à me demander comment je vais organiser mon code, est-ce que telle fonction je la définis dans le header ou pas, etc.
D'autre part, je me retrouve à inclure des headers de plusieurs dizaines de milliers de ligne de code (genre vulkan.hpp) dans mes fichiers sources, et je le sens bien en temps de compilation, on se retrouve alors bien plus lent que Ada ou Java.
Concernant la fabrication, c'est pas encore la panacée à ce que je vois (Make, CMake, etc., communauté encore très fragmentée sur cette question), là où en Ada c'est très clair et simple, pourtant ce sont deux langages proches en terme de fabrication. Donc un peu de perte de temps à ce niveau. Point « positif » : à la fin, on a un binaire comme en Ada, donc de ce point de vue c'est plus simple à lancer hors d'un IDE qu'un programme Java.
Conclusion
Java: Hors écriture de code, Java dans l'IDE, c'est rapide, mais en dehors de l'IDE, c'est plus long.
Ada: Un peu plus long à écrire pour la verbosité, mais temps récupéré sur la qualité du code et des outils de développement. Développer en Ada ne coûte globalement pas plus cher qu'en C, C++ ni même Java à mon sens.
C++: Personnellement je perds du temps en C++ à me demander comment organiser mon code, à comprendre du code obscure, à trouver ce que je veux dans la STL, à trouver qu'est ce qui est censé être la bonne façon de faire telle ou telle chose en C++... mais l'utilisation des bibliothèques en C/C++ est facile (gain de temps ici). Je me pose vraiment des questions sur l'intérêt de C++ quand je vois ce qu'il est devenu (ou ce qu'il est resté).
Je n'ai pas encore testé Rust, mais à première vue, sa syntaxe tendance minimaliste n'est pas trop mon truc (je préfère plus de verbosité).
[^] # Re: Performance
Posté par Meku (site web personnel) . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 10.
Sommaire
Étant développeur Ada depuis plus de 10 ans, je ne trouve pas qu'Ada soit si « extrême » que ça, ni difficile, mais c'est peut-être une déformation professionnelle de ma part... Je ne me considère pas guru en Ada.
Il y a le côté fortement typé du langage : au début, quand on vient du C/C++ ou Java, c'est nouveau et ça peut paraître plus difficile, mais rapidement on s'aperçoit que ça fait gagner du temps, car on peut borner beaucoup plus facilement le code à des plages de valeurs restreintes à son besoin, et empêcher de manipuler les variables n'importe comment. En C/C++ ou Java, t'es obligé de tester que ton argument d'entrée "int", "float" ou autre primitive, est correctement borné par rapport à ton attente. Parfois tu ne le fais pas, en te disant que ça a déjà été vérifié plus en amont dans le code, mais parfois tu te loupes (ou parce que soudain ta fonction est appelée d'ailleurs, sans vérification). En Ada, pas de soucis à se faire là-dessus. En fait, le code critique sera celui de la conversion de ta donnée d'entrée en donnée typée (c'est là que tu dois gérer les cas d'erreur possibles), mais il sera alors bien localisé, là où dans d'autres langages ça peut être plus flou (ou plus expéditif... avec son lot de bugs). Aujourd'hui, quand je manipule des variables de type primitives en C/C++/Java, j'ai vraiment l'impression de travailler sans filet de sécurité.
Mon point de vue maintenant sur les temps de développement, à partir de mon expérience perso. Je dirais que chaque langage a ses points forts (où l'on gagne du temps) et ses points faibles (où l'on perd du temps) et j'aurais bien du mal à les classer par ordre d'une manière générale.
Java
Le côté dynamique de Java permet de démarrer le codage très rapidement. Écrire et exécuter un test unitaire dans Eclipse est extrêmement facile et rapide, et c'est très agréable. Tester la couverture de code sans son IDE également. La compilation est également rapide, les messages d'erreur suffisamment clairs pour comprendre ce qui ne va pas. Les conventions de nommage (voire de codage) fortement imposées permettent d'écarter les questions de base philosophiques qui font perdre du temps pour rien. Bref tu lance ton IDE, Nouveau Projet, et c'est parti !
Le runtime Java est plutôt bien fourni, ça aide à coder rapidement également.
Beaucoup de bibliothèques existantes, mais parfois en terme de dépendances, on a l'impression de tirer la mer et les poissons. Quand on travail sur des systèmes critiques où il faut maîtriser toutes les dépendances, il faut parfois apprendre à s'en passer (pareil pour les potentielles galères de licences).
Là où ça se gâte à mon sens, c'est sur la partie packaging/déploiement, qui quand elle tourne mal, peut faire perdre pas mal de temps qu'on avait gagné en codage (et en général c'est pour des conneries). Certains outils sont censés simplifier ça en imposant une certaine structure (genre maven), mais d'une part je ne trouve pas la syntaxe de ces outils très fluide à manipuler, d'autre part, je suis souvent bloqué par un firewall très filtrant et je dois donc m'organiser comme si j'étais offline 100% du temps. Et là, ça coûte en temps pour la mise en place d'un environnement maven/nexus, l'import des dépendances (qui est devenu galère dans nexus 3), etc. Sur un gros projet, ces coûts pourront s'absorber, mais sur des petits programmes, ça peut parfois coûter plus que le temps de codage.
Autre point ennuyant, c'est pour faire un simple programme, là où en C, C++ ou Ada tu obtiens un binaire prêt à l'emploi, avec Java t'as un ou plusieurs jar, qu'il faut lier en général avec un script de lancement, tout en s'assurant d'avoir le bon JRE, le bon environnement, etc., bref un peu pénible à gérer.
Ada
En Ada, le côté verbeux rend forcément l'écriture de code plus lente (c'est tout de même atténué grâce à la complétion auto de l'IDE). Mais en même temps, c'est bien rare que j'arrive, dans n'importe quel langage, à écrire une fonction d'une traite de bout en bout sans me poser et réfléchir entre deux lignes.
La séparation entre spec (header) et body (source) prends également du temps. Elle permet toutefois de bien séparer le contrat de l'implémentation (pratique pour faire du logiciel propriétaire ;-)). En Java, il n'y a que le code, et le côté dynamique du langage permet d'en extraire les signatures de classes facilement, reste la javadoc, qu'il faut fournir « à côté », là où en Ada on peut se contenter de lire les commentaires présents dans le fichier spec. En C++, c'est la fête du slip.
La structure d'un programme Ada, en packages, présente les mêmes avantages que Java en terme d'organisation de code, et les packages s'importent simplement comme en Java, dans l'ordre qu'on veut. Le temps de compilation est généralement assez rapide (sauf cas particuliers), un peu comme en C je dirais, mais plus lent que Java.
Le runtime Ada s'est pas mal étoffé ces dernières années, et propose pas mal de choses.
Il n'existe pas beaucoup de bibliothèques en Ada, mais on peu faire des bindings avec les bibliothèques C assez efficacement (ça prend un peu de temps de développement).
Côté outils, Ada étant un langage de niche, il n'y en a pas 36, du coup on perds pas beaucoup de temps à choisir ;), mais on trouve généralement ce qu'il faut.
L'IDE, GNAT Programming Studio (GPS), commence à être vraiment pas mal.
Enfin, concernant la fabrication, là c'est c'est vraiment excellent. La description des projets dans des fichiers « .gpr » surpasse de loin tout ce que j'ai vu (Makefile, CMake & co) en terme de clarté, simplicité, rapidité à écrire et maintenir, réutilisation par divers outils (compilateur, IDE, analyseurs, ...). En plus, ça marche aussi pour d'autres langages comme C et C++ (ou pour mixer plusieurs langages).
C++
Bon là je vais être méchant, et ça me rend bien triste. J'ai commencé la programmation avec C++, et j'étais fan de ce langage, mais je n'en ai pas fait beaucoup durant cette décennie. De temps en temps, j'essaie d'en refaire un peu histoire de pas trop perdre la main.
Quand aujourd'hui je compare le C++ à Java ou Ada, je trouve que :
Ça m'est totalement obscur. Voir ça en 2019 m'a fortement déçu sur l'évolution de C++ et de son écosystème. Et le bout de code en exemple, je l'ai trouvé sur le net. Tout seul je n'aurais pas su l'écrire, et d'ailleurs j'ai encore du mal comprendre comment il fonctionne (!), ce qui m'inquiète beaucoup.
Aussi je perds pas mal de temps à comprendre certains messages d'erreur de gcc (quand c'est pas de la bouillie templatique).
D'un point de vue organisation du code, à cause du mécanisme archaïque des includes, c'est bordélique. Il faut les mettre dans le bon ordre sinon ça pète. Un truc comme ça en 2019 c'est vraiment difficile à supporter.
La séparation déclaration/implémentation entre header et source n'est jamais claire, puisqu'on trouve du code dans les headers, partiellement ou complètement. Et honnêtement, je passe (perds) souvent du temps à me demander comment je vais organiser mon code, est-ce que telle fonction je la définis dans le header ou pas, etc.
D'autre part, je me retrouve à inclure des headers de plusieurs dizaines de milliers de ligne de code (genre vulkan.hpp) dans mes fichiers sources, et je le sens bien en temps de compilation, on se retrouve alors bien plus lent que Ada ou Java.
Concernant la fabrication, c'est pas encore la panacée à ce que je vois (Make, CMake, etc., communauté encore très fragmentée sur cette question), là où en Ada c'est très clair et simple, pourtant ce sont deux langages proches en terme de fabrication. Donc un peu de perte de temps à ce niveau. Point « positif » : à la fin, on a un binaire comme en Ada, donc de ce point de vue c'est plus simple à lancer hors d'un IDE qu'un programme Java.
Conclusion
Java: Hors écriture de code, Java dans l'IDE, c'est rapide, mais en dehors de l'IDE, c'est plus long.
Ada: Un peu plus long à écrire pour la verbosité, mais temps récupéré sur la qualité du code et des outils de développement. Développer en Ada ne coûte globalement pas plus cher qu'en C, C++ ni même Java à mon sens.
C++: Personnellement je perds du temps en C++ à me demander comment organiser mon code, à comprendre du code obscure, à trouver ce que je veux dans la STL, à trouver qu'est ce qui est censé être la bonne façon de faire telle ou telle chose en C++... mais l'utilisation des bibliothèques en C/C++ est facile (gain de temps ici). Je me pose vraiment des questions sur l'intérêt de C++ quand je vois ce qu'il est devenu (ou ce qu'il est resté).
Je n'ai pas encore testé Rust, mais à première vue, sa syntaxe tendance minimaliste n'est pas trop mon truc (je préfère plus de verbosité).