C'est rigolo comme approche. Effectivement, le comportement d'un code objet est parfaitement émulé.
Ce code est très impératif. La fermeture utilisée pour instancier une classe, généralement on s'en sert pour aider le compilo à ne pas évaluer une expression deux fois, ou partager une fonction partiellement appliquée (par exemple pour ne compiler qu'une fois une expression régulière) et l'appliquer ensuite sur plein de chaines).
Le pattern matching concrètement c'est pas différent d'un filtrage avec des instanceof en java, c'est juste beaucoup beaucoup plus sucré. La syntaxe primitive est le match foo with | bar => 3 | baz => 1 | …
Une approche fonctionnelle pourrait consister à construire les lignes récursivement en piochant dans une liste et en décomptant les caractères.
Ça c'est une variable privée :
let buffer = Buffer.create length
Oui et non, buffer n'est pas une variable, c'est une déclaration. Seulement la valeur attachée à buffer, elle, est une variable, et n'a rien de fonctionnel. Ça viole la transparence référentielle.
fonctionnel/objet ne sont que des représentations d'un même code
Ça dépend comment on défini "même code", parce que par exemple, pour la factorielle entre
acc = 1; while(n) acc *= n--;
et
(\f.\x.f(x x) \x.f(x x)) (\f.\n.if n == 0 then 1 else n * f (n-1)) n
il y a un monde.
Dans certains langages de programmation fonctionnel, c'est vraiment la seconde version qui est exécutée. Il y a le graphe de l'expression qui est construit dans le tas et l'évaluation se fait en réduisant ce graphe.
D'autre part j'ai tendance à penser que LA caractéristique des langages fonctionnels, aussi importante que la récursivité est la pureté. L'idée c'est d'écrire des maths dans un programme et que l'ordinateur les mouline.
est-ce que mon interrogation est naïve, et je ne fait que constater des évidences, ou bien est-ce moi qui suis trop imbibé de code objet et n'ai pas réussi à m'en détacher ?
OCaml est un langage multi-paradigme. Avec Haskell par exemple il est impossible d'écrire ce genre de chose sans encapsulation.
# Ben, non, pas vraiment...
Posté par Zylabon . En réponse au message Paradigme fonctionnel : juste un habillage ?. Évalué à 2.
C'est rigolo comme approche. Effectivement, le comportement d'un code objet est parfaitement émulé.
Ce code est très impératif. La fermeture utilisée pour instancier une classe, généralement on s'en sert pour aider le compilo à ne pas évaluer une expression deux fois, ou partager une fonction partiellement appliquée (par exemple pour ne compiler qu'une fois une expression régulière) et l'appliquer ensuite sur plein de chaines).
Le pattern matching concrètement c'est pas différent d'un filtrage avec des instanceof en java, c'est juste beaucoup beaucoup plus sucré. La syntaxe primitive est le match foo with | bar => 3 | baz => 1 | …
Une approche fonctionnelle pourrait consister à construire les lignes récursivement en piochant dans une liste et en décomptant les caractères.
Oui et non, buffer n'est pas une variable, c'est une déclaration. Seulement la valeur attachée à buffer, elle, est une variable, et n'a rien de fonctionnel. Ça viole la transparence référentielle.
Ça dépend comment on défini "même code", parce que par exemple, pour la factorielle entre
acc = 1; while(n) acc *= n--;
et
(\f.\x.f(x x) \x.f(x x)) (\f.\n.if n == 0 then 1 else n * f (n-1)) n
il y a un monde.
Dans certains langages de programmation fonctionnel, c'est vraiment la seconde version qui est exécutée. Il y a le graphe de l'expression qui est construit dans le tas et l'évaluation se fait en réduisant ce graphe.
D'autre part j'ai tendance à penser que LA caractéristique des langages fonctionnels, aussi importante que la récursivité est la pureté. L'idée c'est d'écrire des maths dans un programme et que l'ordinateur les mouline.
OCaml est un langage multi-paradigme. Avec Haskell par exemple il est impossible d'écrire ce genre de chose sans encapsulation.
Please do not feed the trolls