Pour LSE...

Alain Thomazo
 

   LSE est un langage souple, agréable à écrire sinon à parler, et même à lire. Le néophyte peut s'y sentir assez vite chez lui, ce qui en ces temps de régionalisme croissant ne devrait lui valoir que des succès ! À moins qu'il ne possède pas encore assez de dialectes locaux pour que chacun puisse se sentir roi dans son jardin... Apparemment donc, tout va pour le mieux dans le meilleur des mondes. Tout juste si, ça et là, se fait sentir une petite réticence sans justification très convaincante. Peut-être parce que la « vraie » informatique est et sera anglo-saxonne, du moins tant que les Japonais ne l'auront ramenée à son rôle normal : servir l'utilisateur, pas le contraire. Obscure, elle doit le rester. Sinon, que deviendront les « spécialistes » dont le vocabulaire sert de compétence ? Que deviendrait le respect qui leur est dû, et surtout leur rente de situation ?

   Il est également bien connu qu'il faut se garder de ses amis. LSE n'échappe pas à ce problème. À quelques petits détails, que nous verrons par la suite, le langage est satisfaisant. Malheureusement, un langage n'est pas tout. Et l'environnement de LSE est scandaleusement faible. S'il y a eu de petits progrès depuis les Mitra-15 et autres T-1600, il reste beaucoup à faire. Je me demande si la volonté de le faire existe. Qui veut tuer son chien... Il faut en effet avoir le coeur bien accroché pour ne pas être définitivement rebuté par des machines sur lesquelles l'écran est d'une stabilité douteuse, sans réglages accessibles par un utilisateur lambda, des machines sur lesquelles la moindre manipulation demande une concentration bien supérieure aux capacités d'un cerveau moyen. Que dire de la correction des erreurs par recherche d'une sous-chaîne à substituer ? Je connais des fanatiques de cette méthode, très « puissante » disent-ils. Le malheur est qu'aucun d'entre eux n'est capable de l'utiliser sans faire régulièrement de fausses manoeuvres. Soyons modestes, et utilisons plutôt un bon éditeur d'écran de type HP ou CBM avec une gestion rapide du curseur, et des touches à répétition automatique sans utilisation d'une clé. C'est au logiciel de faire ce travail, pas à l'utilisateur.

   Que dire encore du clavier « Éducation nationale », qui est sans doute un chef d'oeuvre d'inadaptation. Voyons en quelques aspects :

• Pas de pavé numérique, y compris les opérateurs arithmétiques et le E nécessaire à la notation exponentielle ;

• Les crochets, indispensables à l'utilisation des tableaux, sont soigneusement protégés d'une frappe malencontreuse ;

• Par une soigneuse inversion des « ouvrants » et « fermants »,
• Par une joyeuse gymnastique « majuscules-minuscules » dans d'autres cas.

   Pourvu qu'il ne vienne à l'idée de personne de ne les accepter qu'en inversion de la vidéo !

   Enfin, il devient difficile de se retrancher derrière le prix de la mémoire (16 K-octets pour 650 francs chez Sinclair, prix public) pour refuser de gérer une mémoire d'écran. Il est à la fois désagréable, et frustrant de devoir faire ré-exécuter un programme pour revoir un résultat par trop fugitif. Cette commodité existe déjà sur certains micros. LSE doit en profiter, de même qu'il est indispensable de pouvoir faire promener le curseur d'écran dans toute la liste du programme sans être obligé de se demander quelles sont les lignes limites à indiquer.

   Le langage lui aussi a quelques manques, parfois curieux. Ainsi, il est à peu près impossible de gérer des interruptions de type « délai » sur des machines destinés à l'enseignement. La seule instruction de ce type, ATT(), a disparu après avoir changé de comportement dans différentes versions Mitra-15. Plus grave peut-être, l'instruction XIT(X) a elle aussi été victime de la purge micro. Alors que les langages récents se structurent, LSE suit le chemin inverse ! Pourquoi avoir gardé l'instruction TANT QUE ? Cette réintroduction de XIT devrait être accompagnée de l'instruction REPETER n° de ligne pour faciliter la structuration des programmes. Par contre, l'introduction du type logique a alourdi inutilement me semble-t-il la programmation et amené des contraintes analogues à celles de PASCAL. Ou alors, il faut pouvoir réellement accéder au bit ! Pourquoi avoir abandonné ETL(X,Y), OUL(X,Y) et OXL(X,Y) ? .VRAI. et .FAUX. ne me semblent pas un gros progrès, surtout accompagnés de leurs points en édition.

   En conclusion, il me semble utile de demander à tous les utilisateurs de LSE, occasionnels ou non, d'indiquer tout ce qui les a choqué, de quelque nature que soit leur remarque. Il est en effet à craindre que l' élaboration d'un système LSE pour l'enseignement, ou pour tout autre but, ne « bénéficie » que de vieilles recettes sans intégrer les commodités les plus récentes, par conformisme ou par ignorance. Je ne vois pas pour quelles raisons les enseignants et leurs élèves ne devraient que se contenter de solutions de tvpe « emplâtre ». alors que les élèves ne se demandent pas si il faut ou il ne faut pas utiliser l'informatique : elle est. Alors, qu'elle soit. Agréable.

Alain Thomazo

Paru dans le Bulletin de l'EPI  n° 26 de juin 1982.

Cet article est sous licence Creative Commons (selon la juridiction française = Paternité - Pas de Modification). http://creativecommons.org/licenses/by-nd/2.0/fr/