Kemeny et Kurtz contre-attaquent

Histoire du Langage Basic

Ordinateur

Dégoûtés par les nombreux dialectes BASIC qui avaient proliféré, en 1983, John Kemeny et Thomas Kurtz décidèrent de retourner à la planche à dessin ; plusieurs années plus tard, ils ont publié un nouveau BASIC structuré multiplateforme conforme à la norme ANSI appelé True BASIC.

Avec Dartmouth BASIC publié dans le domaine public pour encourager une large acceptation, ses créateurs ont perdu le contrôle de la langue - une langue que Kurtz, rappelez-vous, avait initialement pensé ne serait pas adoptée en dehors du Dartmouth College.

En sous-estimant sa popularité, Kemeny et Kurtz n'ont pas réussi à devancer le problème de la normalisation, entraînant ainsi la prolifération d'innombrables dialectes BASIC, dont certains ont dépouillé le langage, d'autres ont inséré des mots-clés et des fonctions dépendant du matériel.

Ironiquement, Kemeny et Kurtz se sont également appuyés sur une fonctionnalité dépendante du matériel afin qu'ils n'aient pas à écrire d'algorithmes à virgule flottante pour BASIC le premier : les routines à virgule flottante intégrées du GE-225, est une des principales raisons pour lesquelles ils sont allés avec GE en premier lieu.

"La mise en œuvre du langage est distincte de la conception du langage", a expliqué Kurtz. Kemeny et Kurtz ont adopté le terme ignoble "Street BASIC" pour décrire les nombreuses implémentations BASIC "inférieures" qui ont proliféré en dehors des limites douillettes du Dartmouth College.

"Nous sommes très préoccupés par le fait qu'une génération d'étudiants grandisse en apprenant le Street BASIC, un dialecte analphabète d'une belle langue", ont-ils écrit.

Les créateurs avaient quelques critiques mineures, notamment que le code d'indentation n'était pas possible dans de nombreux Street BASIC. L'indentation était purement pour des raisons de «jolie impression» ou esthétiques: elle permettait un code plus lisible et compréhensible; même au milieu des années 1960, Kemeny et Kurtz encourageaient l'indentation à Dartmouth.

Mais ils avaient également un certain nombre de critiques majeures à l'égard de Street BASIC. D'une part, la plupart des implémentations étaient des interpréteurs, pas des compilateurs (toutes les versions de Dartmouth BASIC ont été compilées).

Les interprètes n'exécutent qu'une seule ligne de code à la fois, ne se terminant généralement que lorsqu'ils rencontrent des erreurs de syntaxe, et peuvent donc ne pas reconnaître les mots clés manquants ou des erreurs de logique plus subtiles dans le code, ou peuvent signaler des lignes qui ne contiennent pas d'erreurs.

De plus, les rapports d'erreurs de Street BASIC étaient souvent laids et non spécifiques - rappelez-vous les messages d'erreur de Tiny BASICs HOW?, WHAT? et SORRY - rendant le langage BASIC plus difficile à utiliser que nécessaire.

Dans l'intérêt d'économiser de la mémoire, les programmeurs Street BASIC ont été encouragés à réduire le nombre d'espaces (contrairement à Dartmouth BASIC, ces variantes avaient tendance à ne pas être indépendantes de l'espace), à s'abstenir de commenter le code et même à changer le langage lui-même - en rendant le LET et mots-clés END facultatifs (et donc superflus) ou en supprimant complètement le mot-clé MAT.

Bien sûr, de tels changements apportés au BASIC étaient contraires à la vision originale de Kemeny et Kurtz : une déclaration par ligne ; chaque ligne commençant par une déclaration ; un mot-clé indiquant la fin d'un programme ; et encouragement pour les programmeurs à écrire un code clair, concis, indenté et commenté, tout en pouvant utiliser des caractères minuscules si possible (l'ordinateur couleur TRS-80, qui manquait de minuscules, utilisait des caractères vidéo inverse pour compenser).

Kememy et Kurtz avaient également, sans surprise, un choix à faire avec les commandes graphiques dépendantes du matériel dans certains dialectes BASIC, et IBM BASICA/GW-BASIC a fait l'objet d'un examen particulier. Au lieu de se conformer au plan cartésien (l'axe x-y), "évidemment, IBM [en réalité, Microsoft] a choisi de suivre l'industrie de la télévision, qui scanne une image télévisée en commençant par le haut, plutôt que nous, mathématiciens, qui préférons utiliser le plan cartésien que nous avons tous appris au lycée », ont-ils écrit.

Donc, pour paraphraser Willy Wonka, convertir mathématiquement les emplacements des pixels de votre moniteur en géométrie de coordonnées cartésiennes vous obligeait à penser latéralement et obliquement et longitudinalement et en arrière et en avant.

Ce qui n'avait aucun sens : "Si vous sentez que vous avez besoin d'un ordinateur pour faire tous ces calculs désordonnés, nous sommes d'accord avec vous... Mais vous avez un ordinateur ! un langage très mal conçu." Pour être juste, cependant, ce n'est pas seulement BASICA/GW-BASIC qui a adopté la pratique de l'industrie de la télévision consistant à localiser l'origine en haut à gauche de l'écran ; la plupart des autres langages de programmation de l'époque ont également adopté la même approche.

Kemeny et Kurtz avaient déjà montré, des années auparavant avec le SBASIC (Structured BASIC), qu'une approche structurée du BASIC était non seulement possible mais aussi préférable. Les structures conditionnelles et en boucle avancées, les sous-programmes et les cas autonomes étiquetés, les espaces blancs, l'indentation, la suppression totale des numéros de ligne et l'évitement des constructions de saut inconditionnelles (c'est-à-dire GOTO) sont quelques-uns des nombreux avantages par rapport à ses prédécesseurs qu'une forme structurée de BASIC a apportée à la table.

En fait, l'un des rares regrets que Kemeny et Kurtz ont publiquement exprimés avec le BASIC de Dartmouth sur les numéros de ligne : non pas qu'ils aient été utilisés en tant que tels, mais qu'ils aient servi d'étiquettes (ou d'adresses) à des segments de code particuliers ; si un programme avait besoin d'être renuméroté, les sauts (GOTO, GOSUB, etc.) auraient également besoin d'être ajustés, ce qui était assez compliqué sur un IDE en ligne de commande. (Bien que pas dans IBM BASICA/GW-BASIC, puisque la commande RENUM a ajusté le code en conséquence.)

Avec ces idées à l'esprit, Kemeny et Kurtz se sont mis au travail sur True BASIC, leur tentative de construire un BASIC structuré standardisé et indépendant de la plate-forme qui était conforme à de nombreux principes originaux de Dartmouth BASIC.

Les numéros de ligne étaient résiduels et maintenant facultatifs; GOTO n'était pas interdit mais ne fonctionnait qu'avec les numéros de ligne. Au lieu de cela, les programmeurs True BASIC ont été encouragés à regrouper le code en sous-programmes (en utilisant les instructions SUB / END SUB); comme dans QBASIC (qui a été publié plusieurs années après True BASIC), les sous-programmes pouvaient prendre des paramètres, contenir des variables strictement locales et ne renvoyaient pas de valeurs au programme principal lorsqu'ils étaient appelés (en utilisant le mot-clé CALL).

La vraie récursivité était donc possible en True BASIC. True BASIC était également similaire à QBASIC en ce qui concerne les fonctions (utilisant les instructions DEF / END DEF), qui renvoyaient des valeurs au programme principal.

L'instruction MAT est réapparue pour gérer les matrices, et le code de commentaire (les commentaires commençaient par des points d'exclamation) était encouragé.

Des bibliothèques de routines, accessibles avec l'instruction LIBRARY, pouvaient être construites et importées pour étendre les fonctionnalités de True BASIC, et les commandes graphiques étaient puissantes et intuitives. L'encapsulation via des "modules" permettait aux utilisateurs de construire de très gros programmes. Et il y avait même un support de souris offert.

Kemeny et Kurtz craignaient particulièrement que True BASIC, qui serait un descendant direct de Dartmouth BASIC construit à partir de BASIC the Seventh, puisse se comparer favorablement à Pascal, l'un des langages structurés les plus populaires - et le langage qui avait remplacé BASIC dans le milieu l'éducation.

Pour assurer une comparaison favorable, True BASIC a amélioré certaines constructions Pascal, telles que l'allocation automatique de mémoire avec des variables de chaîne et l'autorisation de sorties précoces des boucles.

Les premières sorties des boucles BASIC FOR ne provenaient pas de True BASIC, mais plutôt de North Star BASIC - qui a été conçu pour l'ordinateur North Star Horizon 8 bits à bus S-100 de 1977 - grâce à l'instruction EXIT. North Star BASIC avait d'autres différences notables avec les BASIC standard de Microsoft de l'époque, y compris des façons uniques de fonctionner avec des chaînes et des tableaux ainsi que des noms différents pour PEEK et POKE.

De plus, contrairement à l'approche fortement typée de Pascal, dans True BASIC, les variables n'avaient pas besoin d'être des types déclarés et les types numériques peuvent être "mixtes". Par conséquent, apprendre à programmer en utilisant True BASIC pourrait conduire à une utilisation bâclée des variables plus tard, car il n'y avait aucune incitation à anticiper, à économiser de la mémoire et à organiser avec soin les variables spécifiques nécessaires aux tâches à accomplir.

De plus, le typage variable remonte aux années 1950 avec FORTRAN ; John Backus a justifié la pratique de cette façon :

"... nous avons estimé que si du code pour la conversion de type devait être généré, l'utilisateur devrait en être conscient, et la meilleure façon de [le rendre] conscient était de lui demander de les spécifier ."

Faire apparaître soudainement des variables ad hoc dans le code True BASIC sans déclaration préalable pourrait conduire à une forme plus douce de code spaghetti.

True BASIC a fait ses débuts commerciaux en 1985 sur les systèmes d'exploitation Commodore Amiga, PC (DOS) et Mac. Les critiques étaient mitigées. Comme le clavier QWERTY, dont les raisons de survie étaient plus historiques que rationnelles, l'adoption du True BASIC à la place d'un BASIC peut-être moins logique ou fonctionnel a été lente à venir.

Un article de 1985 dans Byte de Jerry Pournelle se plaignait que les messages d'erreur et l'éditeur prêtaient à confusion. De petites choses, comme le point d'interrogation (?) Ne fonctionnant pas comme un substitut à un caractère pour PRINT, ont déconcerté l'examinateur. Notez également qu'aucune version de Dartmouth BASIC n'autorisait les deux-points à compresser plusieurs instructions en une seule ligne.

La barrière à l'adoption de True BASIC était élevée; apprendre à utiliser la langue nécessitait de lire "systématiquement le manuel entièrement bavard [imprimé]. Ne sautez pas." Pourtant, paradoxalement, dans une interview dans le livre Masterminds of Programming (2009), Kurtz déclare que "les programmeurs débutants ne devraient pas avoir à parcourir les manuels. La plupart des manuels sont beaucoup trop verbeux pour retenir l'attention des nouveaux étudiants."

L'accord de licence du logiciel a également fait l'objet de critiques dans l'article de Byte : "Les avocats d'Addison-Wesley ne pouvaient pas déterminer s'ils voulaient protéger leur produit - produit est un nom assez approprié pour la chose - par la loi sur le droit d'auteur, la loi sur les contrats. , ou loi sur le secret commercial : ils ont donc essayé pour les trois », ce qui a entraîné la « schizophrénie ».

Pire encore, Pournelle demande : "La vraie question est : pourquoi avons-nous besoin de True BASIC ?"

En effet, True BASIC ne semblait pas faire quoi que ce soit que le bon vieux BASIC - c'est-à-dire Street BASIC - avait toujours fait. Bien sûr, le critique n'a pas creusé beaucoup sous la surface, mais le fait qu'il se sente mal à l'aise ou qu'il ne veuille pas le faire en dit long sur les obstacles initiaux auxquels True BASIC a dû faire face.

Pourquoi passer de (gratuit) Microsoft BASIC ou CBASIC, demande-t-il, et vous compliquer la vie pour peu de gains apparents ? Ce qui touche au coeur du sujet. True BASIC a été écrit conformément à la norme ANSI, note-t-il, mais "pourquoi un institut de normalisation établirait une norme si différente des versions de BASIC que les micro-ordinateurs utilisent vraiment, je ne le sais pas." Pournelle accuse même obliquement Kurtz et le comité de normalisation BASIC, dans lequel Kurtz a joué un rôle de premier plan, de collusion.

D'autres critiques, cependant, ont fait l'éloge du produit. "True BASIC est idéal pour les étudiants et les éducateurs qui utilisent BASIC dans le cadre de leurs divers programmes. Il peut même convenir aux scientifiques ou aux ingénieurs en raison de la richesse des bibliothèques mathématiques et graphiques", a écrit un critique de MacTech à propos d'une version ultérieure de True BASIC.

Cependant, le seul coup constant sur True BASIC était qu'il fonctionnait trop lentement car "True BASIC n'est pas compilé en code de processeur natif (de sorte qu'il fonctionnera sur True BASIC sur plusieurs plates-formes), les programmes écrits en True BASIC sont plus lents. " Le True BASIC, contrairement au Dartmouth BASIC original, a été construit avec un compilateur multi-passes et, par conséquent, les programmes n'ont pas été convertis directement en code machine. Le compilateur lui-même a été écrit en True BASIC.

Une revue de logiciel de 1988 dans Info World l'a dit clairement : "Le True BASIC ne sera pas facile à apprendre pour un ancien hack BASIC en raison de son implémentation différente de nombreuses commandes et instructions. Mais le paradigme structuré devrait être facile à adapter si vous n'avez jamais programmé ou si vous avez de l'expérience avec un autre langage structuré, comme Pascal."

La conversion des anciens programmes BASIC en True BASIC était particulièrement difficile. "Si les auteurs souhaitent favoriser le mouvement de la communauté BASIC vers la norme proposée, le programme de conversion PC BASIC doit être associé au langage."

Kemeny et Kurtz étaient arrivés en retard à la fête qu'ils avaient eux-mêmes organisée, mais dont Microsoft et d'autres s'étaient emparés. De plus, contrairement à Dartmouth BASIC, que Kemeny et Kurtz ont donné gratuitement afin d'encourager son adoption, True BASIC avait un prix (ce sont les étudiants de Dartmouth qui ont convaincu Kemeny et Kurtz de transformer True BASIC en un produit vendable ; les professeurs ont lancé une société appelée True BASIC Inc. pour lancer le bal).

True BASIC, par conséquent, n'était pas tout à fait "The Original BASIC", comme le proclamait son slogan de produit. De plus, True BASIC n'a été chargé dans aucune ROM; c'était un logiciel autonome, donc les utilisateurs n'étaient jamais obligés d'interagir directement avec lui.

Au fur et à mesure que les systèmes d'exploitation évoluaient, les versions de True BASIC devaient suivre : "Cela s'est compliqué avec l'avènement des systèmes Windows", a admis Kurtz. "True BASIC sous Windows est plus compliqué à utiliser que True BASIC sous DOS."

Mais, comme Kurtz l'a ajouté dans une autre interview, True BASIC disposait de bibliothèques extensibles à l'infini et permettait des programmes essentiellement infiniment volumineux, ce que les variantes Microsoft BASIC, y compris Visual Basic, ne permettaient pas. Et Kurtz a affirmé que True BASIC était aussi orienté objet que Visual Basic (qui n'était pas entièrement orienté objet).

Microsoft BASIC a gagné la bataille, maintenant sa domination face à de dignes challengers comme True BASIC, mais il a finalement perdu la guerre depuis que Pascal a été adopté comme langage structuré de choix dans les établissements d'enseignement et les interfaces graphiques comme le texte déplacé du système d'exploitation Windows et Mac.

Les systèmes d'exploitation basés comme MS-DOS. Les versions contemporaines de True BASIC continuent d'être produites, offrant des fonctionnalités avancées, des corrections de bogues et des bibliothèques mises à jour pour une variété de systèmes d'exploitation.