J'ai l'impression d'arriver un peu après la bataille, mais je me permets de proposer un point de vue un peu moins orthodoxe. Je suis assez d'accord sur les trois aspects demandés à un langage de programmation (concision, clarté, cohérence), bien que chacun de ces aspects doivent probablement plus à l'habilleté du programmeur qu'au langage lui-même. On peut bien sûr estimer que certains langages rendent la tâche plus ou moins facile, mais il reste tout à fait faisable d'écrire du code verbeux, obscur, et incohérent dans tous les langages de programmation.
Par contre, j'avoue me retrouver un peu perdu par la suite du journal, qui se focalise sur la formalisation mathématique et l'invention / la distribution d'outils de programmation innovants. Je suis un simple "utilisateur" de langages de programmation, je ne suis pas informaticien, et pour moi la programmation n'est pas une fin en soi, c'est juste un outil qui permet d'arriver à un résultat scientifique. Mon approche de la programmation est donc assez pragmatique, et l'objectif est d'optimiser un gloubiboulga de temps de formation, temps de codage, temps de déboggage, et temps d'exécution ; bref, de trouver des compromis. Or, j'ai l'impression que la "recherche en langage de programmation", telle que décrite dans ce document, n'a pas du tout pour objectif de faciliter la tâche de gens qui sont dans le même cas que moi. Je sens même que ça pourrait être le contraire. Typiquement, ce qui me gène le plus au quotidien, c'est le compromis performances/productivité. Pour les mini-projets, les langages de haut niveau (non-typés, avec d'énormes bibliothèques livrées par défaut—algorithmique, statistiques, GUI, I/O, etc) sont hyper-productifs ; en 5 minutes on peut avoir un script qui fonctionne, qui est portable, et qui fonctionnera encore probablement dans 15 ans. D'expérience, j'ai beaucoup moins de bugs dans ce genre de programmes que dans des langages compilés (pas de pointeurs, pas de comportements indéfinis, pas de dépassement de capacité...). Ce sont des langages qui sont concis, clairs, et cohérents pour l'usage au quotidien. En fait, je crois que c'est ça le problème : la programmation au quotidien, c'est 1% d'algorithmique et 99% de "trucs" autour, et ce sont ces trucs qui pourrissent la vie (lecture/écriture, formattage de données, internationalisation, etc).
Du coup, la discussion ci-dessus sur le langage Go est particulièrement éclairante. J'ai l'impression que Go est typiquement un outil dont une partie substantielle des programmeurs a besoin. Or, je suis surpris de voir autant de mépris de la part de la communauté des chercheurs en langages de programmation envers Go. Quelque part, je ne peux pas m'empêcher d'y voir un fossé énorme entre ce que les programmeurs ont besoin, et ce dont les chercheurs pensent que les programmeurs ont besoin. Et du coup, ce passage vers la formalisation mathématique des langages, moi, ça me laisse complètement froid, ce n'est pas ça dont j'ai besoin. Je n'ai pas besoin de démontrer mathématiquement que mon code est parfait, ça me semble même totalement inutile. Ce que je veux, c'est coder vite, que le code soit clair et évolutif, que mes collaborateurs et mes étudiants puissent le comprendre sans 4 ans de formation, et que le programme fonctionne vite et sans surprise (et qu'il plante s'il y a un bug).
# Avec un peu de distance...
Posté par arnaudus . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 10.
J'ai l'impression d'arriver un peu après la bataille, mais je me permets de proposer un point de vue un peu moins orthodoxe. Je suis assez d'accord sur les trois aspects demandés à un langage de programmation (concision, clarté, cohérence), bien que chacun de ces aspects doivent probablement plus à l'habilleté du programmeur qu'au langage lui-même. On peut bien sûr estimer que certains langages rendent la tâche plus ou moins facile, mais il reste tout à fait faisable d'écrire du code verbeux, obscur, et incohérent dans tous les langages de programmation.
Par contre, j'avoue me retrouver un peu perdu par la suite du journal, qui se focalise sur la formalisation mathématique et l'invention / la distribution d'outils de programmation innovants. Je suis un simple "utilisateur" de langages de programmation, je ne suis pas informaticien, et pour moi la programmation n'est pas une fin en soi, c'est juste un outil qui permet d'arriver à un résultat scientifique. Mon approche de la programmation est donc assez pragmatique, et l'objectif est d'optimiser un gloubiboulga de temps de formation, temps de codage, temps de déboggage, et temps d'exécution ; bref, de trouver des compromis. Or, j'ai l'impression que la "recherche en langage de programmation", telle que décrite dans ce document, n'a pas du tout pour objectif de faciliter la tâche de gens qui sont dans le même cas que moi. Je sens même que ça pourrait être le contraire. Typiquement, ce qui me gène le plus au quotidien, c'est le compromis performances/productivité. Pour les mini-projets, les langages de haut niveau (non-typés, avec d'énormes bibliothèques livrées par défaut—algorithmique, statistiques, GUI, I/O, etc) sont hyper-productifs ; en 5 minutes on peut avoir un script qui fonctionne, qui est portable, et qui fonctionnera encore probablement dans 15 ans. D'expérience, j'ai beaucoup moins de bugs dans ce genre de programmes que dans des langages compilés (pas de pointeurs, pas de comportements indéfinis, pas de dépassement de capacité...). Ce sont des langages qui sont concis, clairs, et cohérents pour l'usage au quotidien. En fait, je crois que c'est ça le problème : la programmation au quotidien, c'est 1% d'algorithmique et 99% de "trucs" autour, et ce sont ces trucs qui pourrissent la vie (lecture/écriture, formattage de données, internationalisation, etc).
Du coup, la discussion ci-dessus sur le langage Go est particulièrement éclairante. J'ai l'impression que Go est typiquement un outil dont une partie substantielle des programmeurs a besoin. Or, je suis surpris de voir autant de mépris de la part de la communauté des chercheurs en langages de programmation envers Go. Quelque part, je ne peux pas m'empêcher d'y voir un fossé énorme entre ce que les programmeurs ont besoin, et ce dont les chercheurs pensent que les programmeurs ont besoin. Et du coup, ce passage vers la formalisation mathématique des langages, moi, ça me laisse complètement froid, ce n'est pas ça dont j'ai besoin. Je n'ai pas besoin de démontrer mathématiquement que mon code est parfait, ça me semble même totalement inutile. Ce que je veux, c'est coder vite, que le code soit clair et évolutif, que mes collaborateurs et mes étudiants puissent le comprendre sans 4 ans de formation, et que le programme fonctionne vite et sans surprise (et qu'il plante s'il y a un bug).