Je suis partagé en ce qui concerne le langage à utiliser pour un premier cours d'algo/programmation. Il y a quelques années, j'aurais sans doute dit comme toi: Python, Perl (oui je sais, plein de gens trouvent ça caca, mais moi j'aime), ou Ruby me semblaient de bons candidats. Et puis à partir de 2004-2005 y'a eu la petite révolution des architectures multicœur. Et depuis je me dis que l'important, ce serait plutôt, quel que soit le langage, de donner de bonnes bases d'algorithmique à tout le monde (au moins pour les algos « fondateurs »), de façon à ce que le programme soit relativement facilement parallélisable. Selon moi cela signifie aborder les algorithmes un peu différemment, et ça passe par des langages différents. Par exemple, à l'université de Rice (Houston, TX), ils utilisent un langage appelé CnC (Concurrent Collection), qui « découple » la description de l'algorithme (les étapes de calcul) et la programmation proprement dite de chaque étape. CnC est juste un langage de description qui rend explicite les dépendances de données entre les étapes d'un algorithme. Suivant l'implémentation faite de CnC (Intel a l'implémentation de référence, écrite en C++, et qui repose sur Threading Building Blocks; Rice a une implémentation en Java de CnC; il existe une implémentation pour Haskell; etc.), on doit écrire l'étape dans un langage impératif, de façon séquentielle. L'idée est de rendre correctement modulaire ses algorithmes, mais de ne pas utiliser de constructions parallèles explicites (seules les dépendances de données, de type producteur-consommateur, sont exprimées).
Du coup, l'expert dans un domaine (physique, bio, méca...) exprime son algo sous forme d'étapes, programme lesdites étapes dans un langage « séquentiel » (C/C++, Java, Haskell, ...), et plus tard, un expert en optimisation (un infoteux donc) pourra, s'il le faut, optimiser chaque étape, forcer un ordonnancement spécifique entre les étapes pour rendre l'application plus rapide, etc.
Évidemment, ça ne résout pas le problème de « quel langage séquentiel choisir », mais ça force à repenser l'enseignement-même de l'algorithmie. Concernant Scheme, LISP, etc., j'ai vu des linguistes aller de la linguistique pure vers la reconnaissance vocale (donc au départ, pas de formation informatique à proprement parler), etc., et user de combinaisons entre Java et LISP assez étranges, et ils ne s'en portaient pas plus mal. Je pense que le problème de LISP ou Scheme n'est pas le langage (et il faudrait arrêter un peu de se focaliser là-dessus); il s'agit plus de la manière dont le langage est enseigné. Quand j'ai lu que le bouquin dont il est question ici a été écrit par un agrégé de maths, je me suis dit « encore un bouquin qui ne servira qu'aux informaticiens/théoriciens ». Je pense que ça me plairait beaucoup comme bouquin hein, c'est juste que je pense que beaucoup de gens (infoteux compris) détestent la programmation fonctionnelle parce qu'elle est enseignée par des gens un chouïa trop matheux. Bien sûr, les langages fonctionnels ont une origine qui s'y prêtent, mais quand on y pense, Fortran aussi, et pourtant ...
Bref. L'auteur de ce journal n'avait visiblement pas l'étudiant moyen en tête lorsqu'il a écrit sa bafouille, et pensait clairement à un futur informaticien. Et dans ce cadre-là, je pense que ce genre de bouquin passe parfaitement.
[^] # Re: Par pitie
Posté par lasher . En réponse au journal Du livre "Premiers cours de programmation en Scheme". Évalué à 7.
Je suis partagé en ce qui concerne le langage à utiliser pour un premier cours d'algo/programmation. Il y a quelques années, j'aurais sans doute dit comme toi: Python, Perl (oui je sais, plein de gens trouvent ça caca, mais moi j'aime), ou Ruby me semblaient de bons candidats. Et puis à partir de 2004-2005 y'a eu la petite révolution des architectures multicœur. Et depuis je me dis que l'important, ce serait plutôt, quel que soit le langage, de donner de bonnes bases d'algorithmique à tout le monde (au moins pour les algos « fondateurs »), de façon à ce que le programme soit relativement facilement parallélisable. Selon moi cela signifie aborder les algorithmes un peu différemment, et ça passe par des langages différents. Par exemple, à l'université de Rice (Houston, TX), ils utilisent un langage appelé CnC (Concurrent Collection), qui « découple » la description de l'algorithme (les étapes de calcul) et la programmation proprement dite de chaque étape. CnC est juste un langage de description qui rend explicite les dépendances de données entre les étapes d'un algorithme. Suivant l'implémentation faite de CnC (Intel a l'implémentation de référence, écrite en C++, et qui repose sur Threading Building Blocks; Rice a une implémentation en Java de CnC; il existe une implémentation pour Haskell; etc.), on doit écrire l'étape dans un langage impératif, de façon séquentielle. L'idée est de rendre correctement modulaire ses algorithmes, mais de ne pas utiliser de constructions parallèles explicites (seules les dépendances de données, de type producteur-consommateur, sont exprimées).
Du coup, l'expert dans un domaine (physique, bio, méca...) exprime son algo sous forme d'étapes, programme lesdites étapes dans un langage « séquentiel » (C/C++, Java, Haskell, ...), et plus tard, un expert en optimisation (un infoteux donc) pourra, s'il le faut, optimiser chaque étape, forcer un ordonnancement spécifique entre les étapes pour rendre l'application plus rapide, etc.
Évidemment, ça ne résout pas le problème de « quel langage séquentiel choisir », mais ça force à repenser l'enseignement-même de l'algorithmie. Concernant Scheme, LISP, etc., j'ai vu des linguistes aller de la linguistique pure vers la reconnaissance vocale (donc au départ, pas de formation informatique à proprement parler), etc., et user de combinaisons entre Java et LISP assez étranges, et ils ne s'en portaient pas plus mal. Je pense que le problème de LISP ou Scheme n'est pas le langage (et il faudrait arrêter un peu de se focaliser là-dessus); il s'agit plus de la manière dont le langage est enseigné. Quand j'ai lu que le bouquin dont il est question ici a été écrit par un agrégé de maths, je me suis dit « encore un bouquin qui ne servira qu'aux informaticiens/théoriciens ». Je pense que ça me plairait beaucoup comme bouquin hein, c'est juste que je pense que beaucoup de gens (infoteux compris) détestent la programmation fonctionnelle parce qu'elle est enseignée par des gens un chouïa trop matheux. Bien sûr, les langages fonctionnels ont une origine qui s'y prêtent, mais quand on y pense, Fortran aussi, et pourtant ...
Bref. L'auteur de ce journal n'avait visiblement pas l'étudiant moyen en tête lorsqu'il a écrit sa bafouille, et pensait clairement à un futur informaticien. Et dans ce cadre-là, je pense que ce genre de bouquin passe parfaitement.