Pascal Bourguignon wrote:

Il y a un antagonisme fondamental entre la programmation par objet et
la programmation fonctionnelle.

Dans la programmation fonctionnelle, quand on n'a que des fonctions
pures, il n'y a pas d'état.

C'est un peu réducteur, voir faux. En fait, en programmation fonctionnelle,
les entités logiciels manipulées sont des fonctions qui s'appuient
toutefois sur les types de base. Un langage fonctionnel est dit pur
lorsqu'il n'y a pas d'effet de bords dans la manipulation des données,
c'est tout. Un donnée, exprimée sous forme de fonction ou de types de base,
a au moins 1 état, seulement le passage d'un état à l'autre conduit à une
autre donnée ou fonction. Pour vraiment apprécier ce qu'est un langage
fonctionnel pur, voir Haskell qui plus est est libre.

Alors que la programmation par objet n'est concernée justement que par
l'état des objets.  Quand il n'y a pas d'état on est bien embêté en
POO, c'est là qu'on fait intervenir des classes et méthodes de classes
artificielles.

D'abord, je ne suis pas tout à fait d'accord sur cette assertion : dans un
premier temps, on se concentre sur le type de l'objet, donc sur la syntaxe
et la sémantique des messages, indépendamment de la structure interne de
l'objet qui décrit finalement son état ou plus exactement sa machine à
état. Dans un deuxième temps, on se concentre effectivement sur l'état de
l'objet. Du moins, c'est l'approche que je préconise dans le développement
objet.

Ensuite, dans la réalité, j'ai plus l'impression que l'on fait intervenir
des classes artificielles pour écrire ce qui a été mal (voir pas de tout)
exprimé ou modélisé. Car d'après mon expérience, lorsqu'il ne semble pas
avoir d'état, c'est qu'il y a déjà quelque part un problème ; en effet, une
entité a toujours au moins un état, que ce dernier soit ou non explicité
par son codeur.

Ça n'empêche pas de concevoir un language de programmation avec lequel
on puisse utiliser les deux approches (par exemple, en Lisp).  Mais il
faut savoir ce qu'on fait.

Hum ... CLOS par exemple. L'approche objet est une abstraction
supplémentaire dans la conception d'un programme, raison pour laquelle des
langages objet peuvent aussi bien revêtir une forme fonctionnelle
qu'impérative.