FalkBruegmann observed that the GameOfGo is reminiscent of Smalltalk – I agree with him. Also Lisp, Postscript, and Forth. In Go, the game is in the play, instead of the rules – in the same way that in Lisp, Postscript, Forth, and Smalltalk, the semantics are in the environment, not the syntax. Thus, the rules of Go are easy to learn – readily accessible to young children. The implications of the rules have been explored for several thousand years now with no end in sight.

- http://c2.com/cgi/wiki?GameOfGo -

Voyons voir ça, qui utilise lisp et quelles sont les mouvances actuelles en programmation du jeu de Go en lisp ? Il va nous falloir établir une liste des projets existant et faire une analyse des résultats obtenus pour savoir si ce langage s’est révélé à la hauteur dans ce domaine.

Rien de tel qu’un bon schéma pour bien comprendre :

• première figure tirée de Wikipedia:

Sert à illustrer la page sur le perceptron et les notations utilisées pour les calculs qui y sont expliqués.

• ensuite sur la page de Gérard Weisbuch du Laboratoire de Physique Statistique de l’ENS (Paris)

Figure tirée de http://www.lps.ens.fr/~weisbuch/livre/b0.jpg, livre de Gérard Weisbuch "Dynamique des systèmes complexes"..

Voila, pour la correspondance entre le neurone (« biologique ») et le neurone formel, très court et donc très vulgarisé. On retiendra surtout pour la suite l’importance de la « somme ». La somme des entrées, chacune pondérée par un poids.

Pour bien comprendre « comment marche un neurone » on va réaliser un petit programme qui calcul un « Et » (Et-logique).
Puis on fera doucement mais sûrement des améliorations.

Donc un Et logique, on peut représenter cela par la « table de décision » suivante :

Ou bien en plus clair, si les deux entrées de notre système sont activés alors la sortie l’est aussi. Dans les autres cas la sortie ne s’active pas.

Ca jusque là on a pas besoin de réseau de neurone pour le programmer, je suis d’accord. Mais si on ne commence pas par qqchose de simple on ne va pas s’en sortir ! …

Voilà de quoi freiner les ardeurs liées à nos habitudes et l’investissement que l’on a consacré sur nos technos CMS préférées. C’est l’occasion de regarder avec un regard neuf et actualisé ce qui se fait actuellement. C’est cadeaux, c’est un « livre blanc », et y’en a plusieurs autres à découvrir.

En Lisp ou en Tcl par exemple, voici des exemples :

• factorielle en lisp

(defun factorial (n)
"Calcule la factorielle de l'entier n."
(if (<= n 1)
1
(* n (factorial (- n 1)))))

• factorielle en Tcl

proc ! x {expr {$x<2? 1: $x*[! [incr x -1]]}}

Juste pour le plaisir !

Le voici en français : pixel_fr.

Bien entendu certaines traductions sont à mon goût je me suis efforcé de rester sobre.

Rapide retour sur expérience : après avoir cherché une solution e-commerce et pour des raisons multiples et variées, j’ai été amené à travailler avec la solution e-coomerce Drupal / Ubercart avec des besoins spécifiques au delà des modules existants.

Il s’agit donc de bien évaluer combien coûtent ce temps de développement incluant la prise en main de Drupal (coté développement) par rapport à ce que peuvent fournir les principaux concurrents comme Magento dont l’utilisation est plus coûteuse de base (serveur et support). Nous somme donc ici dans le cadre d’une solution d’entreprise, et où le critère de la gratuité de la solution n’est pas primordiale.

Prenons le cas des champs paramétrables coté utilisateur qui est limité chez Ubercart et plus large dans Magento. C’est actuellement facile pour un développeur habitué à Drupal d’étendre les possibilité d’Ubercart en la matière mais pas de façon modulaire donc avec une maintenance plus lourde.

Un simple T-shirt personnalisable par une phrase de votre client et tout devient moins clair.

Pour compléter cette opinion voici un très bon article d’ordre général sur Drupal.