Je confirme, c'était effectivement l'année dernière.
On peut faire la même chose avec tous ces langages, au moins en théorie, si l'on en croit Church et Turing. C'est une excellente raison pour choisir celui qui convient le mieux à la tâche à réaliser : C pour écrire un pilote de carte graphique, Fortran pour exploiter au mieux une grosse machine parallèle à mémoire partagée (le langage est horrible mais comme il est très utilisé par cette communauté, c'est pour lui qu'on a des compilateurs qui profitent pleinement du matériel), Prolog lorsque le problème s'exprime facilement sous forme déclarative, Lustre pour contrôler le système de sécurité d'un réacteur nucléaire, Caml pour le traitement de données structurées (langages, graphes, etc.). D'où l'intérêt d'enseigner plusieurs approches de la programmation. On n'est pas obligé d'aimer Caml, pas plus que Prolog ou Lustre, mais il faut au moins les connaître, sans quoi on manque quelque chose.
Au-delà du langage, c'est l'approche qui compte vraiment. Un exemple en est gcc : comme il doit être capable de s'auto-compiler, il doit impérativement :) être écrit en C. Pourtant, la principale nouveauté de la version 4 est le passage à un nouveau modèle de représentation du code intermédiaire appelé tree-ssa. Ce modèle est directement issu de l'approche fonctionnelle de la programmation, où on s'intéresse à différentes transformations sur les données structurées. Pour gcc, les transformations utilisées servent à optimiser le code. C'est ce genre d'exemples qui mène à des boutades du style "C (ou C++, ou autre chose) est le langage fonctionnel du futur".
C, un langage porté à bout de bras par le succès d'Unix, est un cas à part. Il bénéficie d'une gigantesque inertie : comme "tout" est écrit en C et que "tous les systèmes" ont un compilateur C, "tout le monde" apprend C et donc programme en C. Je ne sais plus qui remarquait que C n'est pas vraiment portable mais plutôt porté : on s'arrange pour que ça marche, puisqu'il le faut. À l'origine il était proche du matériel : on envoie au processeur une séquence d'instructions à exécuter, une par une, les données étant supposées disponibles. Très bien... pour une machine des années 1980. Maintenant nous sommes en 2006 et les machines ne fonctionnent plus du tout de cette manière, mais la base installée est tellement énorme et les progrès en traitement des langages tels que l'on adapte les compilateurs et on utilise des bibliothèques ou des services fournis par système (création et contrôle de processus) plutôt que réécrire les programmes. Personne ne sait si cette tendance va durer ou si d'autres langages vont s'imposer. Ce qui est sûr, c'est que chacun va pouvoir continuer de faire ce qui lui plaît. Pour ma part j'utilise généralement Caml quand j'ai quelque chose à écrire, mais ça ne m'empêche pas de garder de l'intérêt pour l'assembleur x86.
[^] # Re: apprendre la programmation fonctionnelle
Posté par ɹǝıʌıʃO . En réponse au journal Language F# - Du microsoft, mais il y a un rapport avec le libre !. Évalué à 3.
On peut faire la même chose avec tous ces langages, au moins en théorie, si l'on en croit Church et Turing. C'est une excellente raison pour choisir celui qui convient le mieux à la tâche à réaliser : C pour écrire un pilote de carte graphique, Fortran pour exploiter au mieux une grosse machine parallèle à mémoire partagée (le langage est horrible mais comme il est très utilisé par cette communauté, c'est pour lui qu'on a des compilateurs qui profitent pleinement du matériel), Prolog lorsque le problème s'exprime facilement sous forme déclarative, Lustre pour contrôler le système de sécurité d'un réacteur nucléaire, Caml pour le traitement de données structurées (langages, graphes, etc.). D'où l'intérêt d'enseigner plusieurs approches de la programmation. On n'est pas obligé d'aimer Caml, pas plus que Prolog ou Lustre, mais il faut au moins les connaître, sans quoi on manque quelque chose.
Au-delà du langage, c'est l'approche qui compte vraiment. Un exemple en est gcc : comme il doit être capable de s'auto-compiler, il doit impérativement :) être écrit en C. Pourtant, la principale nouveauté de la version 4 est le passage à un nouveau modèle de représentation du code intermédiaire appelé tree-ssa. Ce modèle est directement issu de l'approche fonctionnelle de la programmation, où on s'intéresse à différentes transformations sur les données structurées. Pour gcc, les transformations utilisées servent à optimiser le code. C'est ce genre d'exemples qui mène à des boutades du style "C (ou C++, ou autre chose) est le langage fonctionnel du futur".
C, un langage porté à bout de bras par le succès d'Unix, est un cas à part. Il bénéficie d'une gigantesque inertie : comme "tout" est écrit en C et que "tous les systèmes" ont un compilateur C, "tout le monde" apprend C et donc programme en C. Je ne sais plus qui remarquait que C n'est pas vraiment portable mais plutôt porté : on s'arrange pour que ça marche, puisqu'il le faut. À l'origine il était proche du matériel : on envoie au processeur une séquence d'instructions à exécuter, une par une, les données étant supposées disponibles. Très bien... pour une machine des années 1980. Maintenant nous sommes en 2006 et les machines ne fonctionnent plus du tout de cette manière, mais la base installée est tellement énorme et les progrès en traitement des langages tels que l'on adapte les compilateurs et on utilise des bibliothèques ou des services fournis par système (création et contrôle de processus) plutôt que réécrire les programmes. Personne ne sait si cette tendance va durer ou si d'autres langages vont s'imposer. Ce qui est sûr, c'est que chacun va pouvoir continuer de faire ce qui lui plaît. Pour ma part j'utilise généralement Caml quand j'ai quelque chose à écrire, mais ça ne m'empêche pas de garder de l'intérêt pour l'assembleur x86.