Hello, world.

Cela fait quelques temps déjà que Lama a exécuté sa première addition et son premier programme "hello, world". A l'heure actuelle, il exécute en réalité un fichier contenant une centaine de lignes de test.

J'ai successivement franchi le cap de la compilation et de l'exécution d'instructions simples, puis de la création de procédures, puis de la lecture de fichiers sources, puis de la création de types et de structures, puis de la création de blocs conditionnels et de boucles, puis de la création de clôtures, puis de la création d'espaces de noms, puis du chargement d'extensions sous forme de librairies partagées.

Dernièrement, j'ai ajouté la définition de types-union (au sens des langages fonctionnels), qui permettent notamment d'intégrer la mécanique de gestion d'erreur que je souhaitais et dont j'ai parlé il y a quelques mois.

Pour résumer, les types-union permettent d'exprimer le fait qu'une valeur (une variable, un champ de structure, un paramètre ou un résultat) appartient à un type parmi un ensemble de types. Cet ensemble est connu à la compilation, le type effectif de la variable dépend de ce qui se passe à l'exécution. Le compilateur peut vérifier à la compilation que le programme traitera à peu près correctement tous les cas de figure qui se présenteront à l'exécution.

On utilise les types-union pour la gestion d'erreur en créant un type particulier pour le cas d'erreur, par exemple DivisionParZero, et en l'associant dans une union avec le type "normal". Par exemple:

proc inverse Real x -> DivisionParZero/Real y

  if x=0

    set y DivisionParZero

  else

    set y 1/x

    end

  end

Le type DivisionParZero est un cas particulier de type qu'on appelle "type unité" parce qu'il ne représente qu'une seule valeur. Avec Lama, on le définit comme un t-uple vide:

type DivisionParZero []

Dans ce cas particulier, on se moque de la valeur effective associée au type. Elle est simplement représentée par le nom du type lui-même.

Quand on utilise la procédure "inverse" définie ci-dessus, on obtient une valeur qui peut appartenir à l'un ou l'autre des deux types. Pour pouvoir l'utiliser, il faut d'abord vérifier à quel type elle appartient; on utilise la struture "on" pour ce faire:

var r: inverse z {avec z: un nombre quelconque}

on DivisionParZero r

  print "Erreur: division par zero"

  end

on Real r

  print "le résultat est:" ~ (toString r)

  end

Le compilateur vérifiera que tous les types de l'union sont passés en revue par le programme, comme pour un switch...case du C.

Les types-union résolvent une seconde difficulté: dans un langage à typage statique fort comme Lama, les structures de données classiques comme les listes ou les tableaux ne peuvent contenir qu'un seul type de données. Les unions permettent en quelque sorte de cacher plusieurs types dernière un seul type. C'est certes moins flexible qu'avec un langage dynamique, mais c'est aussi plus sûr et plus rigoureux.

Sur le plan de la syntaxe, il ne me reste plus qu'à implémenter les macros. Je prévois un système inspiré de Forth, où les macros sont des procédures particulières exécutées lors de la compilation. Celles-ci peuvent faire appel à certaines parties du compilateur pour remplir leur fonction. Un exemple d'utilisation très élémentaire serait que la macro "bricole" une chaine contenant l'expression voulue et appelle une procédure du genre "eval", ce qui équivaut déjà aux macros du langage C.

Cependant, sur le plan du fonctionnement, les choses sont moins avancées: il manque un gros morceau, la gestion automatique de mémoire (dont on pourra se passer pour une première version de "démo"); l'interpréteur a tendance à se planter facilement sur les erreurs de syntaxe. Enfin, il manque quelques vérifications stratégiques comme sur la structure "on" ci-dessus, ou sur le fait que la variable de retour reçoit bien une valeur dans tous les cas de figure.

PS: les liens pointent parfois vers des pages Wikipédia anglaises parce que la version française n'était pas suffisamment complète dans le cadre de mon propos.

HADOPI et compagnie

Je suis avec interêt les discussions autour de la loi Hadopi. J'avoue lire avec délectation les commentaires sur Clubic, ZDnet ou Tom's Guide, en particulier quand les participants se moquent à juste titre très souvent de l'ignorance technique des personnes en charge du dossier. Il y aussi des commentaires moins drôles, en particulier ceux qui justifient le piratage et ceux qui confondent politique et justice (ou justesse, pour employer un moins grand mot). La confirmation de cette direction par Sarkozy Lundi dernier, "j'irai jusqu'au bout", a évidemment soulevé une vague de commentaires principalement anti-Sarkosistes.

Entendons-nous bien: je n'ai aucune sympathie ou antipathie envers Sarkozy. Mais force est de constater qu'il se fonde sur des principes élémentaires.

Laisser faire un piratage massif est forcément nuisible aux créateurs, parce que cela les ampute mécaniquement d'une partie de leurs revenus.

Le fait que lesdits créateurs soient déjà riches ou que les diffuseurs s'accrochent à une affaire "juteuse" ne change rien au fait que sur le fond, la copie illégale est un vol. Il serait incensé de justifier auprès d'un juge que votre larcin n'en est pas un puisque vous avez volé dans une boutique Dior. Et gageons que son jugement sera identique que vous ayez volé un foulard dans une boutique Dior ou dans le supermarché du coin.

Le pire est que les pirates, quand bien même ils invoquent cette excuse lamentable, ne font sans doute pas preuve d'un tel discernement dans les faits. A force de se convaincre du bien-fondé de la justesse de leurs excuses, certains finissent par mettre tout les créateurs dans le même panier et copient sans remord (et parfois sans le savoir) l'artiste auto-produit qui a joué son va-tout dans l'aventure.

La nature immatérielle de certaines catégories d'oeuvres (musique, livre, film, logiciel, ...) rend insoluble le problème de l'interdiction ou de la limitation de la copie: ces oeuvres doivent nécessairement être produites pour vraiment exister, et donc il existera toujours un moyen de les re-produire. La culture elle-même est basée sur cette transmission. Tout dispositif de vérrouillage ou de limitation est voué à l'echec. 

Le fait que les règles usuelles de la société ne s'appliquent pas sur Internet est un vrai problème, dont la cause est l'anonymat qui conduit à l'irresponsabilité. Les internautes en subissent eux-mêmes tous les jours les désagréments: trolls, spam, mauvaise conduite sur les forums et les "chats". Cela peut prendre une tournure nettement plus malsaine quand des adultes s'incrustent sur des sites fréquentés par des enfants ou des adolescents.

Cela dit, vrai, la loi HADOPI est mal ficelée et probablement vouée à l'échec. Le fait que le conseil constitutionnel l'ait censurée pour des raisons évidentes pour tout un chacun est bien le signe qu'elle est partie sur de mauvaises bases juridiques. A cela s'ajoute la loi contraire qui a été votée au niveau européen. Comme si cela ne suffisait pas, elle est aussi fondée sur de mauvaises bases techniques: elle vous rend responsable de la protection de votre ordinateur, et est censée vous donner les moyens de le faire par le biais d'une certification de logiciels de sécurité. Or, il se trouve que sur un plan théorique, aucun logiciel de sécurité (anti-virus, pare-feu) ne peut être fiable à 100%. Et c'est encore plus vrai, comme on le sait, du simple fait des défaillances techniques (bogues, failles de sécurités).

Les gens se sont beaucoup moqués et scandalisés du principe de l'identification par adresse IP. Cependant, cela me paraît être la voie à suivre, car comme je l'ai dit l'anonymat est le coeur du problème.

Je reprendrais l'analogie un peu vieillote des autoroutes de l'information; après tout, la route est un autre domaine où le français aime à pratiquer le délit occasionnel ou quotidien, pour lequel il a également toujours une très bonne excuse.

Il est admis et reconnu par tous que Internet est une place virtuelle, mais aussi publique, à l'instar d'une route. Ce qu'on y écrit, peut être lu la plupart du temps par n'importe qui. Avec une bonne maîtrise de Google, vous pouvez amasser pas mal d'informations sur une personne qui ne fait pas trop attention. En fait, c'est comme prendre quelqu'un en filature, sauf que la personne n'a aucune chance de vous repérer.

Le piratage est comme un excès de vitesse: faire une pointe à 110 sur une route de campagne dégagée est un peu comme (le risque vital direct mis à part) envoyer une copie d'un CD à un ami pour lui faire découvrir un artiste. C'est une petite entorse si finalement, celui-ci n'aime pas et l'efface, ou au contraire aime et achète le dernier album, ou encore n'en garde qu'un morceau. Faire commerce de DVD pirates par lots de cent s'apparente (toutes proprtions gardées) à doubler sans visibilité en coupant une ligne blanche.

La sécurité routière ne pourrait pas fonctionner sans gendarmes, radars automatiques et surtout les plaques d'immatriculation, qui permettent l'identification, et qui sont d'ailleurs elles-mêmes protégées par la loi.

L'usage d'Internet devrait donc être parfaitement identifiable si besoin par "la police du net". Cela n'est pas si choquant, tant que les limites posées dans la vie réelle s'appliquent également à la vie virtuelle (protection de la correspondance privée, vidéo-surveillance réglementée, écoutes soumises à l'approbation d'un magistrat, etc.). Cela pourrait même être bénéfique aux internautes, si cela sert aussi à endiguer le spam, à contrer les escrocs, à refroidir les hackers du dimanche, à repérer les pédophiles passant à l'acte, etc. Utiliser l'adresse IP est une voie possible, à condition de la protéger de manière à ce qu'elle soit fiable.

Quelle que soit la méthode, une telle identification informatique pose le problème sérieux et de plus en plus aigu de la possiblité d'abus de toutes sortes dans des proportions jamais vues. Il est probable que nous vivons la période où se définit la vie sociale électronique de demain; cela pose des problèmes technico-juridiques inédits et ardus. La loi HADOPI est trop maladroite et trop simpliste pour être une bonne solution.

Emacs contre Vim

Je suis tombé sur ce commentaire sur reddit:

How do you manage files? Using a file manager of course. Vi is a great editor, it's not a file manager. The Unix way is do one thing and do it well, programs that try to do everything suck.

"Comment gerez-vous les fichiers? En utilisant un gestionnaire de fichier, évidemment. Vi est un bon éditeur, ce n'est pas un gestionnaire de fichiers. La philosophie Unix est de ne faire qu'une chose mais la faire bien, les programmes qui essaient de tout faire sont 'nazes'."

Ce commentaire a retenu mon attention car c'est l'un des points de départ de Lama.

La guerre de clochers entre Vim et Emacs est représentative d'un type de choix qui se présente souvent dans l'univers du logiciel: utiliser de petits logiciels spécialisés et performants dans leur domaine, ou un gros logiciel tout-en-un.

Contrairement à ce que pense ce commentateur, il n'y a pas un bon choix et un mauvais choix, car les avantages d'une alternative sont les inconvénients de l'autre.

Les logiciels tout-en-un comme Emacs, Opera ou les suites logicielles ont l'avantage de l'intégration: les différentes parties du logiciel dédiées à certaines tâches s'échangent général facilement les données, et l'interface utilisateur est cohérente. Le revers de la médaille est que ce sont en général des logiciels énormes, parfois limités dans les domaines qu'ils couvrent, et relativement fermés sur eux-mêmes. Si une des parties du logiciel est boguée ou a des capacités trop limitées par rapport à vos besoins, vous perdez beaucoup des avantages du logiciel intégré car vous devez contourner ses handicaps. Bien souvent, il faut attendre longtemps que ces points bloquants soit résolus par une mise à jour, car la taille du logiciel confère une grande inertie au projet.

Les logiciels spécialisés sont plus petits et plus pointus. Ils sont en général conçus pour communiquer avec d'autres logiciels, donc on peut choisir quel logiciel on utilise pour chaque tâche ou domaine. Le revers de la médaille est que la communication n'est pas toujours efficace. Il faut parfois faire soi-même les adaptations nécessaires pour faire communiquer deux logiciels, et le résultat n'est pas toujours satisfaisant. L'interface utilisateur est aussi fortement hétérogène, car chaque logiciel définit son interface utilisateur, malgré les personnalisations possibles. Enfin, bien que chaque logiciel spécialisé soit individuellement beaucoup plus petit que le logiciel tout-en-un, la taille cumulée de tous les logiciels spécialisés peut excéder celle du logiciel tout-en-un.

Comment réconcilier intégration et liberté de choix?
Une solution presque satisfaisante serait de définir une interface de communication entre logiciels vraiment standard. C'est le créneau qu'occupe XML sur le web en ce moment, et qui a été transposé pour certaines applications de bureau. Mais XML est à mon avis le pire standard de communication possible. Certains ont je crois déjà transposé cette remarque désobligeante qui portait à l'origine sur les expressions régulières: "ils ont choisi les expressions régulières pour tenter de résoudre leur problème. Maintenant ils ont deux problèmes". La communication par un format texte comme celui de XML est, pour commencer, complètement inefficace. Donc inadaptée à des gros volumes de données ou à des traitements ultra-rapides. L'idée absurde d'utiliser les syntaxe de balise de HTML n'arrange rien.

Une autre solution est de programmer ces logiciels dans un langage unique, et de faire communiquer ces logiciels par l'intermédiaire d'une programmation dans ce langage, qui servirait également de langage de script et de configuration. C'est je crois l'idée de TCL, qui a connu un certain succès à une époque. Le principe est bon, mais TCL n'est plus en vogue sans doute pour deux raisons: sa syntaxe et son mode de fonctionnement un peu particuliers, et son inefficacité.
Python est sans doute le TCL d'aujourd'hui. C'est un langage que je pourrais utiliser (ou plutôt Lua, qui est moins populaire, mais plus efficace et plus simple - j'en ai déjà parlé), mais je doute que l'utilisateur type de Lama tel que je me le représente l'apprécierait (c'est un langage de programmeur)

Lama est une tentative de reprendre cette idée en l'améliorant: être accessible à ceux qui ne programment pas toute la journée, être efficace et être ouvert.