Tout est un peu dans le titre. J'ai l'impression que les devs système sont finalement assez satisfaits de C, et que C++ est difficilement détrônable sur le reste. Quoi qu'il en soit, je retrouve dans D tout un tas de choses que je trouve archaïques, et que seuls les devs C ou C++ comprennent, car ils se sentent à l'aise avec.
Une première chose est la verbosité des déclarations. Finalement, les histoires de "@safe pure nothrow" ne sont que des commandes d'optimisation, que l'on utilise principalement pour aider les compilos. Je ne suis pas certain que ça soit au programmeur de gérer ça. La raison principale est que, selon mon expérience, ça nuit à l'évolution et à la flexibilité du programme. Je ne connais pas assez D, mais en C++, on se tape des arbres super-complexes de const à gérer ; modifier le status "const" d'une variable est quasiment impossible dans un programme complexe, le compilo hurle avec des milliers de messages d'erreur, et on finit par saloper le design avec des mutable, et/ou par dupliquer toutes les méthodes avec une version const et une version non-const strictement identiques. Je pense que les langages doivent aussi être conçus pour les gens qui ne sont pas des experts en programmation, y compris en évitant au maximum de faire faire le boulot du compilo aux programmeurs.
L'autre truc qui me fait vraiment reculer, c'est le fait que les tableaux sont gérés comme en C comme des pointeurs. Alors oui, c'est élégant et rapide, mais ça demande un mode de réflexion qui n'est pas naturel pour la plupart des gens, ça rend le code lourd, et surtout, ça induit un mode de programmation basé sur les boucles (indentations récurrentes, définition de variables temporaires qui s'appellent "i" ou "x" et qui ne sont parfois pas réutilisées… Alors c'est sûr, on a toujours tout un tas de bibliothèques externes qui implémentent des vecteurs et des matrices, mais, à mon avis, la présence de ces bibliothèques ne fait que confirmer le manque de gestion des structures simples par le langage (sans comper que l'utilisation correcte de la STL nécessite une expertise assez hallucinante).
signifie, pour un être humain normal, [2,3,4]. Alors oui, c'est certain, un cerveau est assez flexible pour comprendre que ça n'est pas le cas et d'apprendre comment faire une boucle à la place, mais je ne comprends pas comment on peut encore se retrouver avec des langages qui ne gèrent pas intuitivement la concaténation de caractères
string toto = "Mon prénom est " + "Toto";
ou la manipulation de vecteurs
double moy = sum(tab)/size(tab);
Je me demande s'il n'y a pas un peu d'obfuscation volontaire de la part des gens qui créent et utilisent des langages basés sur des concepts qui ont 30 ou 40 ans, et qui, finalement, sont bien contents de se sentir supérieurs grâce à leur compréhension intuitive des std::const_iterator<std::vector<double> > obj.begin(). On crée D, E, F, G, H ou I avec la volonté d'être moins verbeux, mais finalement, on ne fait que changer le langage en laissant les habitudes inchangées.
# Y'a-t-il encore besoin de nouveaux langages "bas niveau"?
Posté par arnaudus . En réponse à la dépêche Le langage D. Évalué à 6.
Tout est un peu dans le titre. J'ai l'impression que les devs système sont finalement assez satisfaits de C, et que C++ est difficilement détrônable sur le reste. Quoi qu'il en soit, je retrouve dans D tout un tas de choses que je trouve archaïques, et que seuls les devs C ou C++ comprennent, car ils se sentent à l'aise avec.
Une première chose est la verbosité des déclarations. Finalement, les histoires de "@safe pure nothrow" ne sont que des commandes d'optimisation, que l'on utilise principalement pour aider les compilos. Je ne suis pas certain que ça soit au programmeur de gérer ça. La raison principale est que, selon mon expérience, ça nuit à l'évolution et à la flexibilité du programme. Je ne connais pas assez D, mais en C++, on se tape des arbres super-complexes de const à gérer ; modifier le status "const" d'une variable est quasiment impossible dans un programme complexe, le compilo hurle avec des milliers de messages d'erreur, et on finit par saloper le design avec des mutable, et/ou par dupliquer toutes les méthodes avec une version const et une version non-const strictement identiques. Je pense que les langages doivent aussi être conçus pour les gens qui ne sont pas des experts en programmation, y compris en évitant au maximum de faire faire le boulot du compilo aux programmeurs.
L'autre truc qui me fait vraiment reculer, c'est le fait que les tableaux sont gérés comme en C comme des pointeurs. Alors oui, c'est élégant et rapide, mais ça demande un mode de réflexion qui n'est pas naturel pour la plupart des gens, ça rend le code lourd, et surtout, ça induit un mode de programmation basé sur les boucles (indentations récurrentes, définition de variables temporaires qui s'appellent "i" ou "x" et qui ne sont parfois pas réutilisées… Alors c'est sûr, on a toujours tout un tas de bibliothèques externes qui implémentent des vecteurs et des matrices, mais, à mon avis, la présence de ces bibliothèques ne fait que confirmer le manque de gestion des structures simples par le langage (sans comper que l'utilisation correcte de la STL nécessite une expertise assez hallucinante).
Typiquement,
int tab[] = [1, 2, 3];
tab = tab + 1;
signifie, pour un être humain normal, [2,3,4]. Alors oui, c'est certain, un cerveau est assez flexible pour comprendre que ça n'est pas le cas et d'apprendre comment faire une boucle à la place, mais je ne comprends pas comment on peut encore se retrouver avec des langages qui ne gèrent pas intuitivement la concaténation de caractères
string toto = "Mon prénom est " + "Toto";
ou la manipulation de vecteurs
double moy = sum(tab)/size(tab);
Je me demande s'il n'y a pas un peu d'obfuscation volontaire de la part des gens qui créent et utilisent des langages basés sur des concepts qui ont 30 ou 40 ans, et qui, finalement, sont bien contents de se sentir supérieurs grâce à leur compréhension intuitive des
std::const_iterator<std::vector<double> > obj.begin(). On crée D, E, F, G, H ou I avec la volonté d'être moins verbeux, mais finalement, on ne fait que changer le langage en laissant les habitudes inchangées.