Petit tour du langage Io
Par Sébastien Pierre, mardi 25 avril 2006 à 20:02 :: Langages :: #16 :: rss
Io est un langage interprété qui a subi une croissance progressive depuis plusieurs années, et qui commence (certes doucement) à devenir utilisable. Sans être à même de remplacer des langages tels que Ruby ou Python, il présente néanmoins un ensemble de caractéristiques très intéressantes qui permettent de s'aérer l'esprit et d'expérimenter différents modèles de programmation. Faisons-donc un petit tour de ses particuliarités...
On parle souvent de traits pour qualifier les différentes caractéristiques d'un langage. Ces "traits" permettent de facilement catégoriser les langages, et de repérer les similarités entre eux. Ainsi, bien qu'il n'existe pas de nomenclature "standard", j'ai tenté de dégager des traits permettant de "dresser un portrait" du langage Io:
- Interprété : les programmes Io n'ont pas besoin d'être compilés et peuvent être directement exécutés à partir de leur code source. L'interpréteur Io lui permet aussi d'être 'embarqué' dans d'autres programmes.
- Dynamique : l'essentiel des mécanismes du langage se passe lors de l'execution d'un programme, plutôt que pendant la phase initiale d'interprétation. Comme Io est interprété, il est donc possible de charger un nouveau programme à partir de son code source directement pendant l'exécution du programme (très utile pour les plug-ins ou le déploiement automatique).
- Réflexif : en suivant le principe du code is data (LISP), un programme Io est entièrement représenté sous la forme d'un arbre manipulable par le programme lui-même. Il devient donc possible d'écrire un programme qui va maniupuler un programme Io (un 'meta-programme', donc).
- Auto-modifiable : grâce à la reflexivité d'un programme, il est possible de dynamiquement modifier un programme, et donc de littéralement changer le code du programme en cours d'exécution. Ce trait est en quelque sorte la conséquence des trois précédents.
- Embarquable : j'ai hésité à mettre ce trait là, car il est quasiment une conséquence du fait d'être interprété, mais je pense que c'est important. Il est ainsi possible d'intégrer Io dans une application plus grande (écrite dans un autre langage), et de permettre une communication bidirectionnelle entre l'application et Io.
Peu de langages disposent de l'ensemble de ces traits, qui confèrent à Io une flexibilité très importante. On pensera notamment à tous les outils de génie logiciel qui peuvent ainsi manipuler la structure du programme, et au domaine de l'intelligence artificielle (notamment les algos génétiques) qui pourrait tirer profit de l'auto-modification de programmes.
Outre les traits d'un langage, il y a également son modèle de donnée qui le caractérise. Io, étant conçu dans un esprit proche de SmallTalk, il dispose d'un modèle objet pur, dont voici les principales caractéristiques:
- Tout est objet : toute valeur du langage (nombres, chaînes, tableaux, instances... mais aussi, classes, fonctions, méthodes, ...) est manipulable selon une interface commune (l'interface d'un 'Objet'). Ceci apporte une possibilité de généricité importante, et selon les fonctionnalités permises à un objet, de transformer dans une large mesure le langage lui-même (malheureusement, c'est un peu long à détailler... un autre fois ?)
- Basé sur les messages : la notion de message permet de donner une représentation interne, accessible par un programme, de l'appel (invocation) d'une méthode sur un objet. Un message représente un identifiant (généralement le nom de la méthode), qui peut être traité par l'objet lui-même durant l'exécution du programme. Par exemple, en Java ou en C++, c'est la "runtime" du langage qui s'occupe de trouver comment une instance répond à un message (une méthode). L'absence de notion de message au sein du langage empêche par exemple un objet de répondre "dynamiquement" à des messages qui n'ont pas été définis au départ. Ainsi, lorsqu'un modèle objet réifie (rend manipulable par le programmeur) la notion de message, chaque objet dispose de méthodes prenant en paramètre un message, et qui s'occupent de trouver l'implantation correspondant au message donné. Le fait de pouvoir modifier ce processus permet de créer très facilement des langages de domaine (surtout lorsque cet aspect est conjugué au précédent).
- Prototypé : il existe principalement deux approches au mécanisme de généralisation/spécialisation dans les langages objets. La première est la plus connue, où l'on introduit la notion de classe (qui est un objet lorsque le langage est réflexif avec un modèle objet pur), pour définir un modèle, ou un moule pour créer les objets. L'autre approche est l'approche par prototype, où l'on va partir du principe que pour spécialiser un objet, on va le cloner (dupliquer). Le clonage introduit un lien de parenté qui fait que si le parent change et que l'objet cloné n'a pas modifié (surchargé/spécialisé) les attributs ou méthodes du parent, l'objet cloné changera aussi. Il y a donc un lien de parenté dynamique qui permet de reproduire finalement les mêmes mécanismes que dans une approche basée sur les classes, mais en éliminant la notion de classe, et donc en simplifiant le modèle.
En un mot : Io est un langage très flexible, où l'accent a été mis sur le minimalisme des concepts. Dans la continuité des langages "dynamiques" (ou "de script") actuels, Io offre beaucoup de libertés au programmeur pour adapter et modifier le langage lui-même, ce qui en fait donc une très bonne souche pour langages de domaines.
Certains se demanderont donc quel est l'intérêt de cette flexibilité ? Une réponse possible est que cette flexibilité permet aisément d'adapter le langage à des domaines particuliers, et par là de rendre les programmes plus expressifs. Ceci peut paraître simple (l'expressivité d'un programme), mais je crois que beaucoup de gens ne se rendent pas comptes des conséquences néfastes d'un programme peu expressif (maintenabilité, correction de bug, ajout de fonctionnalités).
L'expressivité d'un langage, ou d'une "framework", ou d'une API, permet de diminuer le nombre de lignes (voila qui va satisfaire les gens en manque de chiffre), de rendre le programme plus clair, et généralement de rapprocher l'écriture du programme de la spécification ou du "concept" du programme. Pour moi, c'est clairement ce dernier point qui est l'enjeu le plus important : bien des bugs sont la résultante d'un processus complexe de passage du concept à l'implantation (vous avez déja programmé avec les 'phtreads' ??)
En ce qui me concerne, j'ai notamment utilisé Io dans le cadre de prototypes de plateformes SIP pour Alcatel et Wengo, avec de très bon résultats : il était possible d'écrire de petites "applications SIP" (avec gestion des session, concurrence, etc) en à peine quelques dizaines de lignes... chose qu'il n'est pas encore vraiment possible avec HTTP.
Pour ceux qui veulent en savoir plus :
- La page d'accueil du langage Io, par Steve Dekorte
- Deux très bons petits billets (en anglais) sur le langage Io (1) et (2)
- Un article de présentation que j'ai écrit il y a un peu plus d'un an
- "Prototype-based Programming" sur Wikipedia.
Commentaires
1. Le mercredi 26 avril 2006 à 11:38, par Ozone
2. Le mercredi 26 avril 2006 à 14:11, par Sébastien
3. Le lundi 1 mai 2006 à 23:11, par ozone
4. Le mardi 2 mai 2006 à 20:16, par Sébastien
5. Le mardi 9 mai 2006 à 12:10, par zoe
6. Le mardi 9 mai 2006 à 14:16, par Sébastien
7. Le samedi 7 mars 2009 à 10:44, par René Lenoir
8. Le samedi 7 mars 2009 à 18:18, par Sébastien
9. Le mardi 17 août 2010 à 08:27, par prom dress
10. Le mardi 24 août 2010 à 14:54, par timberland shoe company
Ajouter un commentaire