Comments on Programmation et flexibilité

« (d'ailleurs si quelqu'un est motivé pour faire passer une loi pour en interdir l'enseignement, de préférence avant le mois de septembre, je suis preneur…) »

J'ai honte de donner mon avis sur la question étant données mes compétences, mais je suis POUR !

Bon bon… Difficile de résister à l'appel de ce genre de billets. Voici quelques remarques en vrac.

D'abord sur le choix du langage: la seule chose saine à faire avec Java, c'est de le laisser tomber. Vraiment. (d'ailleurs si quelqu'un est motivé pour faire passer une loi pour en interdir l'enseignement, de préférence avant le mois de septembre, je suis preneur…). Pour pouvoir faire tourner un programme avec ton téléphone tu as une large variété de choix. Des compilateurs -> Javascript (il y en a en Haskell et en OCaml au moins (en Java aussi, mais je viens de dire qu'il fallait pas toucher)). Plus funky, des interpréteurs Javascripts (Obrowser en OCaml). Des compilateurs -> JVM (il y en a un en OCaml, et j'y arrive pour Scala). Scala c'est un langage qui me semble vraiment (vraiment) meilleurs que Java (c'est un peu comme Java avec des traits (héritage multiple), des fonctions d'ordre supérieure, du patter matching). J'ai jamais essayé, mais le backend principal c'est la JVM, et ça partage plein de code avec Java. Quant à choisir un langage pur objet, celui-ci me paraît un bon choix.

Pour le multiple dispatch, je ne suis pas d'accord sur le fait que c'est le bon paradigme pour ton projet. En effet, quand tu invoque un verbe (l'équivalent dans ton jeu d'une méthode, donc) tu ne sais pas combien d'objets sont concernés.

D'ailleurs à la lecture de ton billet, mon impression c'est que la principale question c'est la composabilité : in fine, tu ajoutes des nouveaux comportement s sur une pile de comportements, or si tu évalue les comportements dans l'ordre où ils sont ajoutés, tu es fortement sensible à cet ordre (et en particulier à l'ordre dans lequel tes différentes classes s'appellent l'une l'autre). Ca me paraît avoir deux défauts principal : il est quasiment impossible de prévoir le résultat pour quelque chose d'un peu complexe, et le comportement du programme peut changer à cause d'un détail qui n'a rien à voir avec ce qui a changé (deux fichiers ne sont plus évalués dans le même ordre parce que tu rajoutes une dépendance quelque part).

La réponse à la question du dispatch et de la composabilité me semble résider dans les trucs genre "predicate dispatch". Les deux propriétés qui nous intéressent là sont les suivantes :
- Au lieu d'appartenir à des objets, les méthodes appartiennent à des prédicats booleens. En particulier c'est variadique.
- Le pattern qui reçoit le message en premier est celui qui est le plus "précis". En somme si p -> q, et que q est vrai, alors on appelle la méthode sur q.

Il n'y a pas de vrai implémentation de predicate dispatch, pour autant que je sache, mais ça peut être intéressant de s'inspirer des méthodes qui ont été développée dans ce cadre.
Je ne peux pas aller plus dans les détails parce que je n'y connais rien au predicate dispatch. Néanmoins, il y a de la littérature dessus, donc en faisant un peu marcher google scholar, tu trouveras sans doute de quoi comprendre comment c'est sensé fonctionner.

Ce serait donc une sorte de "Lego" informatique. Dans ton programme l'utilisateur final n'aura rien à programmer du tout ? (sous forme de plug'in par exemple).
Gérer les "empêchements" me semble être un problème sans fin (surtout pour ce qui est de la hiérarchie des contraintes). Si un personnage trop chargé pour se baisser, se baisse quand même, et bien qu'il perde une partie de sa cargaison, tant pis pour lui. Et si en plus il n'y a rien au sol alors qu'il veut ramasser un objet, et bien il ne ramassera rien mais se penchera quand même. Je pense que c'est la méthode de l'objet qui doit assumer toutes les situations. Bien sûr, elle se documente. Il me semble que c'est cela un objet, comme un être normal en somme. Notre cerveau nous renseigne, il fait des probabilités et agit en conséquence.
Si on appelle la méthode "ramasser" de l'objet "personnage", je pense que cette methode n'a pas en paramètre à connaitre cet objet, elle le découvrira en se documentant et en cherchant un objet "ramassable" (qui sera trouvé en raison de sa proximité, de sa nature d'objet "ramassable" dans la pile concernée, de la direction du regard du personnage, etc). Cela fera plus de liberté pour l'utilisateur final.
La programmation objet, c'est le règne de l'individualisme! L'objet vit sa vie, il se croit au centre des choses. Il se sert des autres, pas l'inverse. En Java, tout n'est plus qu'objets ainsi faits. Quand je fais de la programmation objet, je pense souvent à Spinoza (surtout à l'exemple de la pierre), ça m'aide à trouver la solution la plus "élégante".

Marrant, en lisant la première phrase j'ai immédiatement pensé à Zork, mentionné juste après. C'est vrai que c'était fort divertissant, ces jeux écrits (et donc : où l'on avait la place pour imaginer).

Tu codes avant de concevoir sur le papier ?

D'ailleurs quitte à faire de la pub, un compilo scheme->javascript a été écrit dans la même équipe, ça peut peut-être t'intéresser.

C'est un sujet sympathique, je trouve. Tiens nous au courant si tu avances quelque part !
J'ai tendance à être assez allergique à l'orienté-objet, mais pour ce genre de problèmes, ça peut effectivement être plus qu'indiqué. Si j'ai le temps (on peut toujours rêver… de toute façon je n'ai même pas les compétences pour), j'essaierais bien de faire quelques essais en impératif / fonctionnel / objet, pour pour une fois me faire une idée des intérêts et inconvénients de chacun pour programmer un truc non trivial.

@Antoine : Pour faire du scheme sur JVM, il y a aussi <URL: http://www-sop.inria.fr/mimosa/fp/Bigloo/ > (bon, d'accord, je fais de la pub, mais je finis aujourd'hui un sur le sujet donc bon… :)

Pourquoi pas Lisp ?
Ma connaissance du langage n'est pas suffisamment avancée pour dire si oui ou non ça pourrait être utile dans ce contexte, mais d'après ce que j'ai lu sur le sujet ça a l'air de coller (code is data, fonctions comme primitives, macros permettant de faire des langages adaptés au domaine, système objet complètement dynamique …). A noter que Clojure permet de faire du lisp (enfin, du scheme) sur JVM (et il existe d'autres langages objet dynamiques, comme Groovy, qui tournent sur JVM aussi)