Je reste mitigé quant au mixe des deux approches, impératives et fonctionnelles, parce qu'elles sont disjointes ; ce sont deux modes de pensée différentes au delà des simples constructions. En fonctionnel, il est plus naturel de penser top-down et de ce que l'on veut faire (pas comment faire) et le résultat est la composition de fonctions qui décrit les relations déclaratives (et sémantiques) entre les fonctions d'un programme.
Je n'accroche pas à cette argumentation. De la façon dont tu le dis, on pense à deux espèces extra-terrestres qui essaient de communiquer sans avoir aucun socle cognitif commun. En pratique on peut très bien mélanger programmation fonctionnelle et impérative, par exemple en OCaml ou en Haskell, et c'est un style tout à fait raisonnable (pas plus complexe en tout cas que la programmation orientée objet avec des effets de bord).
Je n'accroche pas non plus à l'idée que la programmation fonctionnelle est "déclarative". Certains styles de programmation fonctionnelle, dans certains modes d'usages locaux, peuvent être appelés "déclaratifs", par exemple ce qui repose sur "code is data" (construire une structure de donnée et écrire une fonction d'évaluation pour lui donner un sens), mais c'est l'exception plutôt que la norme, ou alors tu as une vision très, très large de ce que signifie "déclaratif" qui ne veut plus dire grand chose.
Ce qui est vrai c'est que les programmes fonctionnels tendent à décrire leurs résultats comme la composition d'opérations (plutôt qu'un séquençage d'instructions), mais la vision opérationnelle de ce que l'ordinateur va calculer reste très présente (même dans les langages paresseux par défaut où elle continue à importer pour des raisons de performances). En fait dès que tu veux contrôler les performances du programme, il faut programmer ("dire comment") et plus seulement spécifier ("dire quoi").
Un cas d'école dans la désillusion de la programmation déclarative est Prolog: c'est un langage qui se veut déclaratif mais qui est en fait sans doute le plus opérationnel des langages que je connaisse: si tu n'as pas précisément conscience de comment le langage va évaluer ton code, tu es mort. Il paraît que d'autres langages logiques font mieux, et c'est bien, mais moi le langage de programmation généraliste déclaratif je n'y crois plus vraiment (comme aux idées selon laquelle l'optimisation serait du ressort du compilateur, jamais du programmeur). Déclaratif sur un domaine spécifique où on peut se le permettre (SQL.. les bons jours), ou pour faire de la preuve, d'accord, mais pour la programmation générale bof.
[^] # Re: Hum ...
Posté par gasche . En réponse au journal Votre langage idéal ?. Évalué à 6.
Je n'accroche pas à cette argumentation. De la façon dont tu le dis, on pense à deux espèces extra-terrestres qui essaient de communiquer sans avoir aucun socle cognitif commun. En pratique on peut très bien mélanger programmation fonctionnelle et impérative, par exemple en OCaml ou en Haskell, et c'est un style tout à fait raisonnable (pas plus complexe en tout cas que la programmation orientée objet avec des effets de bord).
Je n'accroche pas non plus à l'idée que la programmation fonctionnelle est "déclarative". Certains styles de programmation fonctionnelle, dans certains modes d'usages locaux, peuvent être appelés "déclaratifs", par exemple ce qui repose sur "code is data" (construire une structure de donnée et écrire une fonction d'évaluation pour lui donner un sens), mais c'est l'exception plutôt que la norme, ou alors tu as une vision très, très large de ce que signifie "déclaratif" qui ne veut plus dire grand chose.
Ce qui est vrai c'est que les programmes fonctionnels tendent à décrire leurs résultats comme la composition d'opérations (plutôt qu'un séquençage d'instructions), mais la vision opérationnelle de ce que l'ordinateur va calculer reste très présente (même dans les langages paresseux par défaut où elle continue à importer pour des raisons de performances). En fait dès que tu veux contrôler les performances du programme, il faut programmer ("dire comment") et plus seulement spécifier ("dire quoi").
Un cas d'école dans la désillusion de la programmation déclarative est Prolog: c'est un langage qui se veut déclaratif mais qui est en fait sans doute le plus opérationnel des langages que je connaisse: si tu n'as pas précisément conscience de comment le langage va évaluer ton code, tu es mort. Il paraît que d'autres langages logiques font mieux, et c'est bien, mais moi le langage de programmation généraliste déclaratif je n'y crois plus vraiment (comme aux idées selon laquelle l'optimisation serait du ressort du compilateur, jamais du programmeur). Déclaratif sur un domaine spécifique où on peut se le permettre (SQL.. les bons jours), ou pour faire de la preuve, d'accord, mais pour la programmation générale bof.