J'ai appris Smalltalk il y a près de 20 ans en premier avec Smalltalk V. Je ne me souviens pas que cela a été particulièrement difficile et douloureux. Mais il y a sans doute 2 raisons principales à cela: 1) l'image était beaucoup plus petite (150 classes 3500 méthodes). Donc beaucoup plus facile de naviguer dans le code sans se perdre dans les méandres et de comprendre globalement l'implémentation. 2) le "tutorial" de Smalltalk V était très bien conçu, simple et graduel. On apprend la syntaxe et quelques classes et messages de base en même temps en utilisant l'interpréteur (doIt printIt inspectIt) avant d'attaquer la programmation d'une classe.

Ensuite je suis passé sur Smalltalk-80 (350 classes 7000 méthodes mais compilateur Smalltalk inclus) et j'ai approfondi avec les 3 Adele Goldberg (Blue, Orange et quoi déjà ?). Mais il m'a peut être fallu un an ou plus pour désosser le jouet et bien comprendre la machine virtuelle, le compilateur, le byte code, Metaclass class, aucune instruction de branchement nécessaire hormis sendMessage et return, le garbage collect et autres beautés. Tout cela n'est pas nécessaire, mais la curiosité...

Je dirais aux nouveaux qu'il ne faut pas se décourager mais dépenser ces quelques jours d'investissement. C'est quand les acquis vont s'accumuler que la beauté du langage va apparaître. Personne n'a appris Smalltalk en trois jours. Au début, on est tenté d'ouvrir les implementors/senders et de pister le code en ouvrant des dizaines de fenêtres (les poupées russes) pour reconstituer le fil linéaire habituel. Le code est toujours simple, quelques lignes, mais éparpillé, c'est un peu déroutant. On a l'impression que quelque chose nous échappe, qu'on a jamais fini de débobiner la pelote. Et puis il y a toutes ces branches possibles (les implementors d'une même méthode). Puis on finit par retrouver les mêmes classes et mêmes messages dont on commence à comprendre le sens, et le puzzle se reconstitue, ce n'est pas un déclic mais quelque chose qui vient progressivement. On finit par abandonner complètement la vision linéaire du gros fichier source global quand on a l'impression de pouvoir faire le tour d'un joli code Smalltalk fait d'un nombre réduit de petites méthodes élégantes. Small is beautiful. On devient fasciné par ces méthodes qui ne font pas plus de 5 lignes. Rien de tel alors que de naviguer dans le code source existant pour appréhender le langage et apprendre par l'exemple.

Toutefois, mon impression est que si je démarrais aujourd'hui avec Visualworks (+ de 3000 classes 80000 méthodes) ou Squeak (+ de 2000 classes 50000 méthodes) ce serait beaucoup plus difficile. Simplement parce que le nombre de classes et de méthodes a explosé et fait qu'on peut se perdre dans le code et qu'on a l'impression d'être devant une montagne. L'implémentation a souvent perdu en simplicité (Les interfaces graphiques par exemple). La liste hiérarchique des classes, et leurs méthodes faisaient partie du tutorial Smalltalk V. Aujourd'hui on pourrait remplir des centaines de pages avec l'image actuelle !

Commencer à naviguer dans le code d'une image moderne demande un effort mental harassant pour un nouveau. Quand on cherche les implementors, on peut en avoir plus de 10 pour un message, alors pour explorer le code, il faut être capable de fermer un certain nombre de parenthèses mentalement. Si il y a des centaines de classes et des milliers de méthodes à ingurgiter avant de comprendre l'implémentation, cela devient rédhibitoire et on a alors besoin de prêtres et de gourous pour nous initier. Mais ce n'est pas cela l'esprit initial de Smalltalk.

C'est pourquoi je pense qu'il est essentiel de commencer par un bon didacticiel et une image réduite pour apprendre le langage, ses concepts, la syntaxe, la réflexivité (self, super, les classes sont des objets, et les essentiels Behavior Metaclass perform:...), et les bibliothèques principales (Collections ArithmeticValue MVC etc...). Apprendre à naviguer, découvrir que le navigateur lui même est écrit en Smalltalk, le modifier en ligne... Modifier le langage lui même: créer des structures de contrôle et pourquoi pas modifier la syntaxe... Jouer avec le système. Je ne connais aucun autre langage qui donne un tel pouvoir au programmeur.

Bien sûr, la tentation est grande de balancer tout de suite le novice dans le grand bain, en lui faisant miroiter ces outils formidables Seaside et autres RefactoringBrowser. Mais je suis sûr que je devrais probablement moi même "browser" des centaines de méthodes avant de comprendre où faire une petite modification dans le RefactoringBrowser. Ce n'était pas le cas pour le vieux Browser.

On n'apprend pas le langage C à un programmeur en lui donnant à lire les 3 millions de lignes de code de la machine virtuelle Java.

Il est beaucoup plus gratifiant de comprendre un programme simple que de sécher devant un programme compliqué non ? Et il est encore plus gratifiant de se rendre compte qu'un problème compliqué peut être résolu par un petit programme si simple...

L'image squeak est formidablement riche, foisonnante et imaginative, il y a certes un côté ludique, mais cela à aussi tendance à rendre l'interface plus complexe (je pense aux Morph).

Je comprends parfaitement qu'un nouveau venu se sente aujourd'hui frustré. Je milite pour qu'une version allégée soit proposée aux autodidactes pour apprendre la philosophie du langage, et se rendre compte à quel point Smalltalk est élégant efficace lisible compréhensible et Small. Quitte à changer pour une image plus étoffée quand l'acquis est suffisant.

Qu'en pensez vous ?