Programmer, c’est difficile : penser logiquement, par étapes, sans en sauter aucune et en envisageant toutes les possibilités de ses actions demande une grande attention, une grande rigueur. Mais à ces complications s’ajoute encore l’apprentissage d’une syntaxe extrêmement ardue, qui ne supporte pas la moindre faute, à la virgule près. Sans compter que ladite syntaxe nous prend à rebrousse-poil. La simple instruction A=A+1, que l’on trouve dans presque tous les langages informatiques, y compris le vieux Basic, pourtant censé s’adresser aux néophytes, semble une insulte à ce que nous connaissons des mathématiques depuis l’école primaire. On a déjà eu du mal à avaler les maths, faudrait-il maintenant les jeter aux orties ?

Un autre obstacle, peut-être moins évident, est l’absence de résultats immédiatement gratifiants pour les débutants. Prenez, par exemple, la première instruction enseignée lorsqu’on aborde un nouveau langage informatique : le fameux “hello world”. Il s’agit de montrer comment afficher sur l’écran les mots “hello world” (ou quelque autre phrase). C’est le programme plus simple qu’on puisse imaginer. Mais qui cela excite-t-il ? On a parfois l’impression que les informaticiens vivent encore à la fin de l’ère des cartes perforées, où voir des lettres s’afficher à l’écran tenait encore du miracle. Aujourd’hui, en lieu et place de quelques mots, on devrait pouvoir au moins aussi facilement obtenir une belle image, ou une petite animation. Mais la plupart de ces résultats sont en général bien plus difficiles à obtenir. Même Python, peut-être le plus simple et le plus élégant des « grands » langages informatiques actuels, se complique immédiatement dès qu’il s’agit d’afficher une image, tracer un dessin ou sortir un son.

Les langages visuels

L’une des premières tâches de simplification consisterait donc à mettre au point des langages sans possibles erreurs de syntaxe. C’est l’objectif de la « programmation visuelle ». Au lieu d’écrire du texte, on manipule des icônes, des blocs, des boutons. On construit une espèce de Lego et on exprime la logique du programme par des connexions entre les modules. Plus de complications liées à l’écriture des instructions, seule la logique devient susceptible de nous causer des problèmes.

Un des produits phares du genre, Alice, élaboré à l’université de Carnegie Mellon, permet de créer très rapidement des petits films interactifs en 3D. On choisit un décor, des personnages et on décrit leur comportement en optant pour les instructions qui leur correspondent (attention, elles sont en anglais). L’intérêt d’Alice, outre sa capacité à fournir un produit fini bien léché, est qu’il enseigne les bases de ce qu’on appelle la programmation « orientée objet ». Grosso modo, on peut considérer un programme « classique » comme une recette de cuisine. On indique une par une les démarches à suivre du début à la fin, et c’est un acteur unique et centralisateur, le « cuisinier » qui exécute une à une toutes les tâches. Dans la programmation orientée objet, on se retrouve plutôt à diriger une improvisation théâtrale. On dispose de plusieurs “personnages” (par exemple boutons, icônes, fenêtres) et on leur indique ce qu’ils ont le droit de faire lorsqu’ils font face à telle situation. La programmation orientée objet est donc préférable à la méthode classique lorsqu’on crée des applications hautement interactives (c’est-à-dire TOUTES les applications depuis l’invention de la souris et des fenêtres). Alice ne fait au final que prendre au pied de la lettre cette métaphore “théâtrale” de la programmation-objet.

Les créateurs d’Alice ont cherché à définir des packages d’accessoires et de personnages correspondant à certains univers particuliers (heroic fantasy, science-fiction, etc.). Une version spécifique d’Alice, Storytelling Alice est particulièrement destinée aux filles de 12 ans, qui dit-on, seraient rebutées par le côté trop abstrait de la programmation. Storytelling Alice est, comme son nom l’indique, spécialement orienté vers la création d’histoires.

Rien n’empêcherait théoriquement Alice de cesser d’être simplement un logiciel d’apprentissage de la programmation pour devenir une véritable machine à créer des petits films ou même des jeux d’aventures (pas d’action). Seul obstacle : définitivement orientée vers l’éducation et la salle de classe, Alice ne permet pas aisément d’intégrer de nouveaux personnages et décors afin de créer ses propres scénarios. La plupart du temps, le débutant (qui, dans la logique d’Alice, est invariablement un néophyte, un « jeune » ou un enfant, jamais un adulte motivé) n’a guère le choix qu’entre les packages proposés par les éducateurs. La nouvelle version d’Alice 3 intégrerait les personnages issus du jeu Les Sims, une initiative qui devrait contribuer à faciliter l’apparition d’une “scène” d’échange de personnages et de décors entre les utilisateurs (quoique nous n’ayons pas trouvé trace de cette fonction d’import dans la version Beta actuellement disponible).

Kodu, le produit de Microsoft, rassemble beaucoup à Alice, même si, de l’aveu même d’un des concepteurs d’Alice, il est encore meilleur et plus facile d’accès. Ici aussi, on assigne des comportements à des personnages parmi une palette de réactions possibles. Le but avoué de Microsoft est de permettre à tout un chacun de programmer des jeux… pour Xbox. Malheureusement, au jour d’aujourd’hui, Kodu semble lui aussi limité par ses capacités d’importer nouveaux personnages, accessoires et décors…

Les enfants du Smalltalk

Lorsque Alan Kay et son équipe ont créé le langage Smalltalk au Xerox Park, et avec lui la programmation orientée objet, leur but était de rendre le langage informatique si naturel que les plus jeunes pourraient s’y mettre sans difficulté. Small talk, en anglais, c’est le “papotage”, la conversation informelle. Trente ans après, Smalltalk existe toujours, mais il est employé par les bac+5 en informatique, et la notion d’“objet” est devenue l’un de ces concepts abscons réservés aux spécialistes. « Lorsque j’ai conçu la programmation orientée objet, croyez-moi, je n’avais pas en tête le C++ », dira plus tard Alan Kay.

Kay ne renonça pas pour autant à faire du Smalltalk un langage “pour tous”. C’est ainsi qu’est né Squeak, une version moderne du Smalltalk qui intègre le multimédia. Squeak reste cependant assez peu utilisé « tel quel » par les débutants en informatique. Il a revanche servi d’environnement de développement à deux systèmes de programmation visuelle spécialement destinés aux plus jeunes : Etoys et Scratch.

Etoys est le plus ancien des deux. Un peu comme avec Alice, on définit des objets graphiques et on leur attribue des comportements divers qu’on programme sous la forme de « blocs » qu’on assemble sans écrire grand-chose d’autre que quelques variables numériques. Mais l’environnement est en 2D et on peut importer toutes sortes de médias.

Scratch est plus récent, mais se base sur les mêmes principes qu’Etoys :« Nous avons établi trois principes de conception fondamentaux pour Scratch : le rendre plus « bidouillable » (tinkerable), plus significatif et plus social que les autres environnements de programmation », affirme Mitchel Resnick (.pdf), qui dirige le « Lifelong Kindergarden » au MIT. Bidouillable, à cause précisément de son interface sous forme de blocs analogues à des Legos. Ainsi, « les enfants peuvent triturer les briques comme ils le désirent, et les arranger en différentes séquences pour voir comment les choses se passent », précise son créateur. Il est également « plus significatif » : c’est-à-dire qu’il permet aux gens de créer aisément des projets personnalisés, importer leurs propres médias, leurs propres histoires. « C’est pourquoi nous avons choisi de nous concentrer sur la 2D plutôt que sur la 3D », explique Resnick. « Il est plus facile pour les gens de créer, importer ou personnaliser des travaux artistiques en 2D ».

Enfin, il est plus social : le site web de Scratch a été surnommé le « YouTube de la programmation », car chacun peut y héberger ses projets et bien sûr commenter ceux des autres et voter pour ses préférés. C’est cette communauté, ce partage, qui permet aux utilisateurs de s’approprier plus aisément le langage. Une chose qui manquait aux langages éducatifs d’antan. Et Resnick de citer à ce propos Marvin Minsky, pape de l’Intelligence artificielle au MIT qui aurait dit du Logo (premier langage destiné au plus jeunes) qu’il « possédait une belle grammaire, mais pas une grande littérature ».

Quelles sont les différences entre Scratch et Etoys ? Difficile de faire une comparaison sans une longue expérience des deux systèmes. Voici quelques premières impressions. L’interface de Scratch est plus séduisante. Les blocs d’Etoys sont essentiellement textuels, et leur texte n’est pas toujours compréhensible (ils conservent une syntaxe Smalltalk) et quant à leur couleur vert pâle, elle est assez tristounette. Au contraire, on s’amuse beaucoup à assembler les blocs Scratch, colorés et explicites, capables de changer de formes selon la façon dont on les associe. Voilà peut-être des considérations superficielles pour un professionnel, mais elles comptent pour un amateur, surtout quand il a 8 ans. En revanche, Etoys semble doté d’un plus grand nombre de fonctionnalités, par exemple l’intégration de Kedama, un « système multi agent » destiné à modéliser les comportements collectifs (comme ceux des fourmis).

Un billet du blog d’Olpc news semble confirmer nos impressions. On nous y explique qu’« Eric Eisaman, un professeur de physique qui a utilisé Squeak et Etoys pendant plusieurs années, a remarqué des comportements différents des élèves face à Squeak et à Etoys. Cela semble indiquer que Scratch est une bonne introduction à Etoys, qui serait lui-même une bonne introduction à Squeak ».

Malgré ses côtés séduisants, Scratch reste quand même un système qui convient avant tout aux plus jeunes. Mais que faire de la grande masse des adultes qui souhaitent se lancer dans la programmation sans retourner au jardin d’enfants ?

Il existe deux dérivés de Scratch susceptibles de les intéresser. Starlogo TNG (for « the new generation », pour le distinguer de l’ancien Starlogo, d’ailleurs créé par Mitchel Resnick, qui ne semble pas avoir joué de rôle dans la réalisation de TNG) est à la fois un langage de modélisation des systèmes complexes « multi-agents », et un système de création de jeu en 3D. Le tout donc en Scratch et sans demander l’écriture d’une ligne de texte.

Contrairement à Alice et à Kodu, il est assez aisé d’importer des formes 3D dans starlogo TNG, à l’aide du format .kmz de Google Sketchup, l’un des plus accessibles modeleurs 3D du marché, tant au plan financier (gratuit) qu’en terme d’utilisation. Attention, contrairement à Kedama, qui est partie intégrante d’Etoys, Starlogo TNG ne figure pas dans la distribution originale de Scratch : c’est un logiciel indépendant.

Force est cependant de reconnaître que, du point de vue purement ludique, les applications créées par Starlogo TNG restent assez primitives et finalement frustrantes. Peut-être que Resnick avait-il raison de renoncer à la 3D dans le Scratch originel ? Quant à ceux qui souhaitent travailler en profondeur sur les notions de complexité, ils préfèreront sans doute recourir au Starlogo original, ou mieux encore à son clone plus abouti, Netlogo.

L’autre dérivé de Scratch est encore plus intéressant. Google utilise en effet Scratch comme base pour son système App Inventor qui a pour but de faciliter la création d’applications Android par tout un chacun (vidéo). App Inventor ajoute au Scratch classique bien des fonctionnalités propres aux mobiles et à l’univers Google : il devient possible de manipuler les « googles maps », de recourir à la géolocalisation, etc. Jusqu’à aujourd’hui, il semblait qu’il y ait toujours eu une frontière entre les recherches « académiques » d’un groupe de chercheurs travaillant sur l’enseignement de la programmation et le monde des services commerciaux. Avec App Inventor, pour la première fois, on voit un modèle expérimental de programmation graphique au coeur d’un service destiné à des millions d’utilisateurs.

Enfin, il est utile de préciser que la programmation visuelle ne s’adresse pas uniquement au débutant. Le langage Pure Data, qui sera largement présenté dans un prochain article de ce dossier, repose aussi sur une métaphore visuelle, mais ne s’adresse certainement pas aux nouveaux venus. De plus, il existe bon nombre de systèmes professionnels qui intègrent une part de programmation visuelle. Dans beaucoup d’environnements de développement, on peut générer graphiquement son interface (boutons, icônes fenêtres) et déterminer sans programmer certaines actions, mais pour le coeur du projet, il faut recourir aux méthodes classiques.

Plus proches dans l’esprit de la la programmation visuelle, il y a les systèmes comme Hypercard, dont les nostalgiques des premiers macs se souviennent encore avec émotion. Hypercard se présentait lui aussi comme un outil de création de programmes destiné aux non spécialistes, mais ce produit, et bon nombre des logiciels auteurs qui ont suivi (comme Director) proposaient en fait des systèmes hypermédia assez simples, et non des langages de programmation complets. Lorsqu’on voulait complexifier les choses on recourait de nouveau à un langage traditionnel intégré, comme Hypertalk ou Lingo.

Dans un système comme Scratch, c’est le coeur du langage qui s’exprime sous forme d’icônes : les initialisations des variables, les boucles, les conditions… Pas simplement l’interface graphique ou des éléments spécifiquement multimédia.

Processing, pour les artistes et designers

Il existe toutefois une autre voie pour permettre à des non-initiés d’aborder la programmation. Celle qui consiste moins à simplifier la syntaxe qu’à permettre très vite la création de programmes de haute qualité et gratifiants. Dans le monde des designers, un langage remporte ainsi tous les suffrages : Processing.

Processing est basé sur Java, dont il peut apparaître comme une version accessible et simplifiée. Force est de le reconnaître, lorsqu’on installe Processing, on n’apprécie pas forcément sur le champ sa valeur révolutionnaire. Par bien des côtés, il s’agit d’un langage de programmation “classique”. Ainsi, il ne dispose pas d’un interpréteur destiné à tester ses instructions “à la volée” comme le font des systèmes comme Squeak ou Python. De plus, il faut encore définir le “type des variables”, string, integer ou float, bref des tas de termes dont on ignore la signification, sans parler de l’usage systématique des { et } si difficiles d’accès depuis le clavier, ni du point virgule obligatoire dont l’oubli peut tout gâcher. En termes de syntaxe et de facilité d’usage, Python est bien plus avancé…

Mais là où Processing fait très fort, c’est la facilité avec laquelle il permet de manipuler les données multimédias, images, films et sons. Pour un artiste, ou un chercheur désireux de visualiser des données, par exemple, Processing est un must. Processing n’est pas une solution pour dilettantes auquel on s’initie à ses moments perdus. Il s’adresse à des passionnés qui ont à coeur de réaliser un projet et qui n’hésiteront pas, pour ce faire, à investir de l’huile de coude dans l’apprentissage d’un « vrai » langage de programmation.

D’ailleurs la programmation visuelle constitue-t-elle réellement une initiation si facile pour tous les débutants ?

Franchement, la multitude de blocs, boutons, menus et icônes d’Etoys, App Inventor ou Scratch peut parfois s’avérer aussi complexe et confuse qu’un langage à la syntaxe rigoureuse (et ne parlons pas de la relecture d’un programme conçu par autrui). Il est probable que les langages visuels attireront une nouvelle population de programmeurs, ceux qui sont dotés d’une intelligence visuelle, spatiale, les bidouilleurs de toutes sortes. Un langage comme Processing de son côté, reste d’une approche assez classique qui plaira plutôt à ceux dotés d’une mentalité d’ingénieur, de planificateurs. Qu’en est-il en revanche de ceux qui possèdent une intelligence plus « littéraire » que « mathématique » ou « visuelle » ? Peut-être le monde de la programmation du langage naturel et du web sémantique leur offrira-t-il des systèmes, des moyens d’expression de leur pensée que ni les langages de programmation traditionnels ni les nouvelles interfaces visuelles ne sont en mesure de leur offrir ?

Rémi Sussan

Retrouvez le dossier L’avenir de la programmation :

• 1e partie : programmer, une activité culturelle ?
• 2e partie : la programmation pour les non-programmeurs
• 3e partie : programmer le langage naturel
• 4e partie : programmer la complexité
• 5e partie : programmer le vivant
• 6e partie : programmer le multivers