Aussi, lorsque tu écris que l'on peut mélanger la programmation fonctionnelle et impérative avec des langages fonctionnels, je comprend utiliser des constructions impératives pour exprimer certaines choses [...]. Et là dessus oui je suis d'accord.
Donc je ne comprends pas trop sur quoi on n'est pas d'accord. Pour moi avoir une "approche" fonctionnelle c'est d'utiliser surtout, globalement, des constructions fonctionnelles, et avoir une "approche" impérative c'est d'utiliser surtout, globalement, des constructions impératives (ou, dans certains cas, trouver des façons astucieuses de faire au premier ordre mais sans trop se fatiguer des choses qu'on ferait naturellement avec des fonctions d'ordre supérieur; par exemple un bon programmeur C peut aller très très loin avec juste des tableaux et des boucles).
Si tu as beaucoup d'effets de bord observables à moyenne/grande échelle dans ton application, tu vas devoir (pour faire ce que tu veux) utiliser surtout des constructions impératives. Si les effets de bord ne sont qu'aux frontières d'interaction, ou alors utilisées localement et pas observables de l'extérieur, on utilise surtout des constructions fonctionnelles. Il me semble donc que la "façon de penser" est fortement correllée avec les constructions utilisées. Sur un choix de design donné (par exemple passage d'état explicite ou par effet de bord), on fait un choix selon son habitude, celles des autres développeurs, et le compromis demandé entre rigide et implicite d'un côté (effets de bords, style monadique compris) et flexible et explicite de l'autre (style fonctionnel).
Bref, moi je peux lire du code et dire localement quel style il utilise : c'est concret, c'est (relativement) objectif. Par contre les grands discours sur "l'approche", la "façon de penser", "l'esprit" des programmes ou du programmeur, hum, bof.
Quant à mon expression de "déclaratif", il signifie ni plus ni moins que la manière dont sont écrites les fonctions : en déclarant ce qu'elles font par le biais d'autres fonctions (à opposer à stipuler comment elles doivent le faire).
À ce compte-là, C est un langage "déclaratif" parce que quand tu écris une fonction tu "déclares" ce qu'elle doit faire.
[^] # Re: Hum ...
Posté par gasche . En réponse au journal Votre langage idéal ?. Évalué à 2.
Donc je ne comprends pas trop sur quoi on n'est pas d'accord. Pour moi avoir une "approche" fonctionnelle c'est d'utiliser surtout, globalement, des constructions fonctionnelles, et avoir une "approche" impérative c'est d'utiliser surtout, globalement, des constructions impératives (ou, dans certains cas, trouver des façons astucieuses de faire au premier ordre mais sans trop se fatiguer des choses qu'on ferait naturellement avec des fonctions d'ordre supérieur; par exemple un bon programmeur C peut aller très très loin avec juste des tableaux et des boucles).
Si tu as beaucoup d'effets de bord observables à moyenne/grande échelle dans ton application, tu vas devoir (pour faire ce que tu veux) utiliser surtout des constructions impératives. Si les effets de bord ne sont qu'aux frontières d'interaction, ou alors utilisées localement et pas observables de l'extérieur, on utilise surtout des constructions fonctionnelles. Il me semble donc que la "façon de penser" est fortement correllée avec les constructions utilisées. Sur un choix de design donné (par exemple passage d'état explicite ou par effet de bord), on fait un choix selon son habitude, celles des autres développeurs, et le compromis demandé entre rigide et implicite d'un côté (effets de bords, style monadique compris) et flexible et explicite de l'autre (style fonctionnel).
Bref, moi je peux lire du code et dire localement quel style il utilise : c'est concret, c'est (relativement) objectif. Par contre les grands discours sur "l'approche", la "façon de penser", "l'esprit" des programmes ou du programmeur, hum, bof.
À ce compte-là, C est un langage "déclaratif" parce que quand tu écris une fonction tu "déclares" ce qu'elle doit faire.