Donc pour résumé, la récursion est optimisés (dans certain cas) dans les langages fonctionnelles et pas chez les langages impératifs.
C'est faux. GCC le fait, ICC le fait, MS-VC++ aussi. Si tu mets ta fonction sous forme récursive terminale, n'importe quel compilateur optimisant un minimum moderne sait transformer la récursion terminale en boucle. En fait, GCC sait faire de l'optimisation de récursion terminale depuis au moins la version 2.95 (pour rappel, on en est à GCC v4.8).
Encore pire, il existe tout un tas de cas où GCC va faire du « pattern matching » et reconnaître une forme récursive d'un algo, ou en tout cas un idiome récursif « facile » à transformer en récursion terminale, et du coup effectuer la transformation...
Bref, à moins qu'un compilateur pour langage fonctionnel ait des mécanismes permettant de plus facilement convertir une récursion « normale » en récursion terminale1, il n'y a absolument aucun avantage en termes d'optimisation à choisir un langage fonctionnel plutôt qu'impératif.
J'aime bien les langages fonctionnels, mais une fois que n'importe quel programme, écrit dans n'importe quel langage, a été correctement analysé (analyse lexicale, grammaticale, sémantique, blah), on se retrouve avec un arbre de syntaxe abstrait, c'est-à-dire une représentation intermédiaire qui permet de « visualiser » un programme sous forme de graphe de dépendance (de données, de contrôle, etc.), et autres machins. À partir de là, on peut commencer à effectuer des transformations sur le programme, à « marquer » les nœuds qui pourraient être groupés avec d'autres, ou même supprimés, etc.
Par contre, là où les langages fonctionnels ont tendance à briller (je trouve), c'est dans la façon dont ils manipulent plus souvent des « valeurs » que des variables. En gros, souvent les langages fonctionnels proposent un mode qui tient plutôt du « write-once » par défaut, qu'on peut explicitement invalider si on veut des effets de bord, alors que les langages impératifs ont tendance à autoriser les variables à être modifiables par défaut, et il faut ensuite mener une guerre méthodologique pour placer autant de constantes que possibles pour se prémunir contre les effets de bord non désirés.
[1] Et pour le coup je ne vois pas du tout comment ce serait possible...
[^] # Re: C'est pourtant évident.
Posté par lasher . En réponse à la dépêche Coder efficacement, bonnes pratiques et erreurs à éviter. Évalué à 5.
C'est faux. GCC le fait, ICC le fait, MS-VC++ aussi. Si tu mets ta fonction sous forme récursive terminale, n'importe quel compilateur optimisant un minimum moderne sait transformer la récursion terminale en boucle. En fait, GCC sait faire de l'optimisation de récursion terminale depuis au moins la version 2.95 (pour rappel, on en est à GCC v4.8).
Encore pire, il existe tout un tas de cas où GCC va faire du « pattern matching » et reconnaître une forme récursive d'un algo, ou en tout cas un idiome récursif « facile » à transformer en récursion terminale, et du coup effectuer la transformation...
Bref, à moins qu'un compilateur pour langage fonctionnel ait des mécanismes permettant de plus facilement convertir une récursion « normale » en récursion terminale1, il n'y a absolument aucun avantage en termes d'optimisation à choisir un langage fonctionnel plutôt qu'impératif.
J'aime bien les langages fonctionnels, mais une fois que n'importe quel programme, écrit dans n'importe quel langage, a été correctement analysé (analyse lexicale, grammaticale, sémantique, blah), on se retrouve avec un arbre de syntaxe abstrait, c'est-à-dire une représentation intermédiaire qui permet de « visualiser » un programme sous forme de graphe de dépendance (de données, de contrôle, etc.), et autres machins. À partir de là, on peut commencer à effectuer des transformations sur le programme, à « marquer » les nœuds qui pourraient être groupés avec d'autres, ou même supprimés, etc.
Par contre, là où les langages fonctionnels ont tendance à briller (je trouve), c'est dans la façon dont ils manipulent plus souvent des « valeurs » que des variables. En gros, souvent les langages fonctionnels proposent un mode qui tient plutôt du « write-once » par défaut, qu'on peut explicitement invalider si on veut des effets de bord, alors que les langages impératifs ont tendance à autoriser les variables à être modifiables par défaut, et il faut ensuite mener une guerre méthodologique pour placer autant de constantes que possibles pour se prémunir contre les effets de bord non désirés.
[1] Et pour le coup je ne vois pas du tout comment ce serait possible...