« Un arbre, un tri, je cherche à me souvenir quand j'ai eu à m'intérresser à ça, ouhla ça fait loin.. »
Mmmmh. Je m'en sers tous les jours en faisant des "cd ..", "cd /usr/share/doc", etc. Ah oui, et si tu manipules du XML, avec des requêtes XPath, ça peut être pas mal de comprendre comment fonctionne la structure d'un arbre. Ca peut aussi éclairer ta lanterne sur le fait qu'utiliser l'opérateur "//" doit être mûrement réfléchi.
« Pour le tri, il y a des librairies qui font cela que l'implémentation soit récursive ou pas bof. »
Idem pour les arbres (d'où ma référence à la glibc). Mais relis mieux ce que j'ai dit ensuite : le problème est de savoir utiliser les bons outils, et donc, connaître les forces et les faiblesses des structures de données manipulées.
« La plupart du temps quand on programme, cela tient plus de la recette de cuisine »
Euh. Tu te rends compte que ce que tu dis finalement, c'est « Puisque j'y arrive de cette manière, pourquoi j'essaierai d'apprendre à le faire d'une autre manière, aussi pratique soit-elle au final ? »
La programmation fonctionnelle est extrêmement puissante, permet de faire des programmes assez concis, et faciles à comprendre. Après, il est possible de faire de même en prog itérative, bien sûr. Mais il s'agit dans les deux cas d'outils à utiliser en fonction des besoins. Faire une IA en C est bien plus difficile que faire la même chose en LISP. Faire un programme sûr est bien plus facile avec un langage comme Java (qui est sûr du point de vue des types) qu'avec un langage de type C ou FORTRAN.
Dans tous les cas, la prog fonctionnelle n'est certainement pas plus compliquée à apprendre dans l'absolu que la prog itérative. D'ailleurs, si tu prends un langage comme Perl, il permet de faire les deux (en faisant une ou deux contorsions, c'est vrai).
[^] # Re: bof
Posté par lasher . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 7.
Mmmmh. Je m'en sers tous les jours en faisant des "cd ..", "cd /usr/share/doc", etc. Ah oui, et si tu manipules du XML, avec des requêtes XPath, ça peut être pas mal de comprendre comment fonctionne la structure d'un arbre. Ca peut aussi éclairer ta lanterne sur le fait qu'utiliser l'opérateur "//" doit être mûrement réfléchi.
« Pour le tri, il y a des librairies qui font cela que l'implémentation soit récursive ou pas bof. »
Idem pour les arbres (d'où ma référence à la glibc). Mais relis mieux ce que j'ai dit ensuite : le problème est de savoir utiliser les bons outils, et donc, connaître les forces et les faiblesses des structures de données manipulées.
« La plupart du temps quand on programme, cela tient plus de la recette de cuisine »
Euh. Tu te rends compte que ce que tu dis finalement, c'est « Puisque j'y arrive de cette manière, pourquoi j'essaierai d'apprendre à le faire d'une autre manière, aussi pratique soit-elle au final ? »
La programmation fonctionnelle est extrêmement puissante, permet de faire des programmes assez concis, et faciles à comprendre. Après, il est possible de faire de même en prog itérative, bien sûr. Mais il s'agit dans les deux cas d'outils à utiliser en fonction des besoins. Faire une IA en C est bien plus difficile que faire la même chose en LISP. Faire un programme sûr est bien plus facile avec un langage comme Java (qui est sûr du point de vue des types) qu'avec un langage de type C ou FORTRAN.
Dans tous les cas, la prog fonctionnelle n'est certainement pas plus compliquée à apprendre dans l'absolu que la prog itérative. D'ailleurs, si tu prends un langage comme Perl, il permet de faire les deux (en faisant une ou deux contorsions, c'est vrai).