C'est sympa de faire un journal là-dessus, j'avais déjà vu passer le nom mais sans m'y attarder. C'est un projet colossal et très intéressant. Par exemple, les quelques petites phrases qu'il donne sur la parallélisation de l'exécution des programmes écrits en Lisaac se jettent dans de vastes domaines de recherche grand ouverts. Le mien, entre autres.
En ce qui me concerne, Lisaac prend tout son sens en tant que langage évolué pour la programmation système. Actuellement, je n'en connais pas. C'est un domaine qui nécessite de pouvoir mettre le clavier dans le cambouis plus que ne le permet normalement un langage de haut niveau : par exemple, alors qu'un ramasse-miettes est très pratique en temps normal, il est catastrophique pour écrire un pilote de périphérique. Il reste à voir comment ça se passe dans la pratique, ce qui signifie lire la doc, le code, etc. Du temps à passer dessus en perspective...
Puisque je passe par là, j'en profite pour quelques mises au point. J'ai failli prendre un troll sur la tête en arrivant : vous pourriez ranger vos affaires, quand même...
Sur l'INRIA : c'est un très grand institut, assez disparate. J'ai eu l'occasion de voir que les chercheurs étrangers ont parfois du mal à en comprendre l'organisation, ce qui leur donne un point commun avec les Français. Notamment, elle contient de grands théoriciens et... de grands praticiens. En gros, dans mon projet, lorsque les gens ne codent pas en C, c'est qu'ils codent en Fortran. Ou qu'ils ne codent pas.
Sur la valorisation de la recherche, comme dit plus haut, les développeurs d'Objective Caml, par exemple, s'en occupent en compagnie de quelques très grosses entreprises. Cela ne doit pas faire oublier que c'est avant tout un langage expérimental, donc qui change souvent et profondément. Les chercheurs ont besoin de tels langages. Pour expérimenter, pas pour vendre.
Sur les nouveaux langages et nouveaux paradigmes, je me demande bien ce qui peut pousser à croire qu'il n'y en a pas, aux États-Unis ou ailleurs. Pict, fondé sur le pi-calcul, est l'exemple qui me vient là tout de suite, mais c'en est juste un. Il en apparaît tout le temps de nouveaux, ce qui est une excellente chose pour l'informatique en général.
Sur les anciens, il faut comprendre qu'un langage donné, plus largement un paradigme donné a son champ d'application. Par exemple, la programmation fonctionnelle s'applique très bien au traitement de données structurées, en particulier les langages de programmation. Ce n'est pas pour rien que les développeurs de gcc se sont donné tant de mal pour implanter tree-ssa dans la version 4 : cette traduction du code impératif et spaghetteux en une forme fonctionnelle favorise l'analyse et la transformation du code, et particulièrement son optimisation. Il est tentant de croire qu'un langage donné va sauver le monde, mais c'est illusoire. Écrire un serveur http en Caml, par exemple, serait possible mais difficile, du moins avec de bonnes performances.
Ah tiens, les performances. En voilà un domaine où les idées reçues ont la vie dure, sans doute en grande partie en raison d'une méconnaissance des architectures actuelles. En écrivant des boucles et des affectations plutôt que des fonctions récursives et des liaisons, on a l'impression d'être plus proche de la machine : on envoie une instruction, on enregistre le résultat, on passe à la suivante. Sans le dire comme ça, les gens ont en tête une machine de von Neumann. C'était vrai, en gros, jusqu'à l'arrivée du Pentium. Maintenant, on est passé à l'autre modèle : celui du flot de données. Les instructions sont exécutées dans le désordre, en parallèle tant que c'est possible, et le facteur limitant est généralement la latence de la mémoire : dès qu'une donnée arrive, elle réveille les instructions qui l'attendaient. Ainsi, le modèle le mieux adapté est la description du calcul en fonction de la disponibilité des données, en séparant autant que possible le code en morceaux indépendants. C'est ce qu'on fait, entre autres, en programmation fonctionnelle, où une évaluation est possible quand on a les résultats d'autres évaluations dont elle dépend, et pas en programmation impérative où on impose un ordre sur l'exécution des lignes du code (généralement du haut vers le bas, mais on trouve de tout dans le folklore).
C'est pour ce genre de raisons que, paradoxalement, on arrive très bien à convaincre des matheux du bien-fondé de la programmation fonctionnelle, mais on a plus de mal avec des informaticiens (ou plutôt des "informatheux", comme dirait une de mes connaissances) - sauf, comme c'est le cas dans certains établissements, quand on commence par là avec des étudiants ne sachant pas programmer (entendu dans un amphi brestois, deuxième semestre de MIAS : "les boucles c'est nul, la récursivité c'est vachement plus facile"). Les étudiants arrivent avec des idées qui reposent sur leur expérience et leurs connaissances, et un nouveau paradigme les bouscule plutôt violemment. Or, on ne peut guère parler d'analyse de langages de programmation à des gens qui n'ont pas encore les bases de la compilation, ou d'architectures parallèles alors qu'ils ne sont même pas initiés aux architectures séquentielles. En gros, les principaux avantages du paradigme fonctionnel ne leur sont pas encore accessibles, et il faut bien reconnaître que la fonction factorielle, fût-elle récursive terminale, montre assez vite ses limites. Alors on trouve toutes sortes de réactions, d'opinions qui peuvent durer ou changer. En tous cas rien de bien inquiétant.
Bon je vous laisse, j'ai comme l'impression que ma propension à écrire des pavés a encore frappé. Je vais donc aller exécuter un script : logout ; shutdown ; sleep.
[^] # Re: Pffff...
Posté par ɹǝıʌıʃO . En réponse au journal Un compte rendu de la conf sur isaac/lisaac. Évalué à 10.
En ce qui me concerne, Lisaac prend tout son sens en tant que langage évolué pour la programmation système. Actuellement, je n'en connais pas. C'est un domaine qui nécessite de pouvoir mettre le clavier dans le cambouis plus que ne le permet normalement un langage de haut niveau : par exemple, alors qu'un ramasse-miettes est très pratique en temps normal, il est catastrophique pour écrire un pilote de périphérique. Il reste à voir comment ça se passe dans la pratique, ce qui signifie lire la doc, le code, etc. Du temps à passer dessus en perspective...
Puisque je passe par là, j'en profite pour quelques mises au point. J'ai failli prendre un troll sur la tête en arrivant : vous pourriez ranger vos affaires, quand même...
Sur l'INRIA : c'est un très grand institut, assez disparate. J'ai eu l'occasion de voir que les chercheurs étrangers ont parfois du mal à en comprendre l'organisation, ce qui leur donne un point commun avec les Français. Notamment, elle contient de grands théoriciens et... de grands praticiens. En gros, dans mon projet, lorsque les gens ne codent pas en C, c'est qu'ils codent en Fortran. Ou qu'ils ne codent pas.
Sur la valorisation de la recherche, comme dit plus haut, les développeurs d'Objective Caml, par exemple, s'en occupent en compagnie de quelques très grosses entreprises. Cela ne doit pas faire oublier que c'est avant tout un langage expérimental, donc qui change souvent et profondément. Les chercheurs ont besoin de tels langages. Pour expérimenter, pas pour vendre.
Sur les nouveaux langages et nouveaux paradigmes, je me demande bien ce qui peut pousser à croire qu'il n'y en a pas, aux États-Unis ou ailleurs. Pict, fondé sur le pi-calcul, est l'exemple qui me vient là tout de suite, mais c'en est juste un. Il en apparaît tout le temps de nouveaux, ce qui est une excellente chose pour l'informatique en général.
Sur les anciens, il faut comprendre qu'un langage donné, plus largement un paradigme donné a son champ d'application. Par exemple, la programmation fonctionnelle s'applique très bien au traitement de données structurées, en particulier les langages de programmation. Ce n'est pas pour rien que les développeurs de gcc se sont donné tant de mal pour implanter tree-ssa dans la version 4 : cette traduction du code impératif et spaghetteux en une forme fonctionnelle favorise l'analyse et la transformation du code, et particulièrement son optimisation. Il est tentant de croire qu'un langage donné va sauver le monde, mais c'est illusoire. Écrire un serveur http en Caml, par exemple, serait possible mais difficile, du moins avec de bonnes performances.
Ah tiens, les performances. En voilà un domaine où les idées reçues ont la vie dure, sans doute en grande partie en raison d'une méconnaissance des architectures actuelles. En écrivant des boucles et des affectations plutôt que des fonctions récursives et des liaisons, on a l'impression d'être plus proche de la machine : on envoie une instruction, on enregistre le résultat, on passe à la suivante. Sans le dire comme ça, les gens ont en tête une machine de von Neumann. C'était vrai, en gros, jusqu'à l'arrivée du Pentium. Maintenant, on est passé à l'autre modèle : celui du flot de données. Les instructions sont exécutées dans le désordre, en parallèle tant que c'est possible, et le facteur limitant est généralement la latence de la mémoire : dès qu'une donnée arrive, elle réveille les instructions qui l'attendaient. Ainsi, le modèle le mieux adapté est la description du calcul en fonction de la disponibilité des données, en séparant autant que possible le code en morceaux indépendants. C'est ce qu'on fait, entre autres, en programmation fonctionnelle, où une évaluation est possible quand on a les résultats d'autres évaluations dont elle dépend, et pas en programmation impérative où on impose un ordre sur l'exécution des lignes du code (généralement du haut vers le bas, mais on trouve de tout dans le folklore).
C'est pour ce genre de raisons que, paradoxalement, on arrive très bien à convaincre des matheux du bien-fondé de la programmation fonctionnelle, mais on a plus de mal avec des informaticiens (ou plutôt des "informatheux", comme dirait une de mes connaissances) - sauf, comme c'est le cas dans certains établissements, quand on commence par là avec des étudiants ne sachant pas programmer (entendu dans un amphi brestois, deuxième semestre de MIAS : "les boucles c'est nul, la récursivité c'est vachement plus facile"). Les étudiants arrivent avec des idées qui reposent sur leur expérience et leurs connaissances, et un nouveau paradigme les bouscule plutôt violemment. Or, on ne peut guère parler d'analyse de langages de programmation à des gens qui n'ont pas encore les bases de la compilation, ou d'architectures parallèles alors qu'ils ne sont même pas initiés aux architectures séquentielles. En gros, les principaux avantages du paradigme fonctionnel ne leur sont pas encore accessibles, et il faut bien reconnaître que la fonction factorielle, fût-elle récursive terminale, montre assez vite ses limites. Alors on trouve toutes sortes de réactions, d'opinions qui peuvent durer ou changer. En tous cas rien de bien inquiétant.
Bon je vous laisse, j'ai comme l'impression que ma propension à écrire des pavés a encore frappé. Je vais donc aller exécuter un script : logout ; shutdown ; sleep.