Que manquait le DoD à Fortran?

Question

Selon https://en.wikipedia.org/wiki/COBOL le projet de conception de COBOL a commencé lorsque

Les 28 et 29 mai 1959 (exactement un an après la réunion de Zürich ALGOL 58), une réunion s'est tenue au Pentagone pour discuter de la création d'un langage de programmation commun pour les entreprises. Il a réuni 41 personnes et était présidé par Phillips. [20] Le ministère de la Défense se demandait s'il pouvait exécuter les mêmes programmes de traitement de données sur différents ordinateurs. FORTRAN, le seul langage courant à l'époque, n'avait pas les fonctionnalités nécessaires pour écrire de tels programmes.

De quelles fonctionnalités manquait FORTRAN, que le ministère de la Défense jugeait nécessaires pour écrire des logiciels d'entreprise portables? Les deux auxquels je peux penser sont l'arithmétique décimale et les enregistrements avec des champs nommés; Étaient-ce ce que le DoD avait en tête, ou pensaient-ils à quelque chose d'autre qui ne m'est pas venu à l'esprit?

Answer 1

La réunion qui a défini les exigences de la nouvelle langue a eu lieu les 28 et 29 mai 1959. Charles Phillips a préparé une note plusieurs mois plus tard résumant les décisions prises lors de cette réunion. Sa liste d'exigences est réimprimée à la page 201 de l' Histoire des langages de programmation de l'ACM .

une. La majorité du groupe a soutenu l'utilisation maximale de la langue anglaise simple; même si certains participants ont suggéré qu'il pourrait être avantageux d'utiliser le symbolisme mathématique.

b. Une minorité a suggéré que nous nous éloignions du langage axé sur les problèmes parce que l'anglais n'est pas une panacée car il ne peut pas être manipulé comme le peuvent les expressions algébriques.

c. Il faut un langage de programmation plus facile à utiliser , même s'il est un peu moins puissant.

ré. Nous devons élargir la base de ceux qui peuvent signaler des problèmes aux ordinateurs.

e. Le [Common Business Language] ne doit pas être biaisé par les problèmes actuels du compilateur.

Le comité n'a pas considéré FORTRAN comme une alternative. Selon Jean E. Sammet, qui était présidente (elle se décrit comme la «présidente») de deux des comités qui ont développé COBOL et siégé sur un troisième, les principales inspirations étaient FLOW-MATIC (développé par Grace Hopper et d'autres pour Remington -Rand Univac), AIMACO (développé par l'Air Materiel Command sur la base du travail de Hopper, et décrit par Sammet comme «une modification mineure de FLOW-MATIC») et COMTRAN (Traducteur commercial, qui à l'époque existait sous forme de manuel chez IBM, et n'avait jamais été mis en œuvre). Sammet affirme que FACT, développé à Honeywell, a eu beaucoup moins d'influence sur COBOL que certaines personnes ne le croyaient.

Le chapitre entier auquel je renvoie contient des notes détaillées que Sammet a prises à l'époque du comité qui a développé COBOL, et les décisions qu'il a prises.

Elle fait l'admission particulièrement intéressante à la page 221:

J'ai senti qu'il y avait un fort préjugé anti-IBM au sein de ce comité de ma part et de certains (mais certainement pas tous) des autres. Comme je ne travaillais pas pour IBM à l'époque, je peux admettre librement (mais pas avec fierté) que dans certains cas, des suggestions ou des décisions ont été prises sur la base de faire les choses différemment de la façon dont IBM l'a fait. Par exemple, nous avons estimé que le verbe for loop control ne devrait pas être appelé DOcar c'est ainsi que FORTRAN le faisait.

Sammet énumère parmi les idées que COBOL a tirées de FLOW-MATIC, «Il utilisait des noms de données complets plutôt que des noms symboliques courts (comme dans FORTRAN)», par exemple SOCIAL-SECURau lieu de SOCSEC, et utilisait des mots anglais comme commandes. Moins esthétiquement, cela permettait de regrouper les champs dans un mot de données. Elle dit: "Notez que Fortran suppose que chaque nombre est dans un seul mot machine." Il a séparé les définitions de données des instructions, qui, selon elle, sont devenues si courantes qu'il est difficile d'apprécier à quel point il s'agissait d'une percée conceptuelle.

Parmi les idées qu'elle énumère comme venant de COMTRAN, il y a des structures de données imbriquées, des expressions et des conditions. À l'époque, il était controversé d'autoriser des formules mathématiques et même des expressions booléennes, car certains membres du comité pensaient que celles-ci n'étaient nécessaires que dans quelques cas extrêmes.

Elle déclare également que IAL, qui s'est développé en ALGOL, a eu une influence significative, en convaincant le comité de ne pas suivre son exemple, et à la place de n'autoriser dans son code source que les caractères qui existent réellement.

Answer 2

À l'époque (* 1), FORTRAN manquait presque de tout, de la gestion des chaînes à toutes les E / S en plus de la lecture des nombres sur des cartes ou des bandes. Heck, même la taille entière n'était pas garantie sur toutes les machines.

Pas de véritable moyen de structuration ou de contrôle de flux à côté de GOTO - même les sous-programmes / fonctions n'ont été intégrés qu'un an auparavant avec FORTRAN II. Pour la plupart des pièces, FORTRAN est un assembleur symbolique axé sur les mathématiques, ce qui facilite l'écriture de formules, mais pas grand-chose d'autre.

Mais l'informatique dans le monde réel concerne la gestion des données et les E / S. Cela est particulièrement vrai pour une énorme organisation comme l'armée américaine, représentée par son bras bureaucratique, le DoD. Être capable d'écrire facilement des calculs complexes est bien, mais inutile dans un environnement là-bas, il s'agit de gérer les stocks, de commander des fournitures, de calculer la paie et de faire livrer tout cela à temps.

Une armée est comme une énorme société, pas un institut scientifique et la tâche à accomplir est le traitement des données, pas le calcul des chiffres.

Le traitement des données est très différent du calcul des nombres - c'est un monde complètement différent. Il s'agit de la boucle classique "lire la carte, traiter l'élément, écrire la sortie", ce qui a été automatisé avec les cartes perforées. C'est la raison principale pour laquelle le / 360 a survécu jusqu'à aujourd'hui en tant qu'architecture réussie. Son jeu d'instructions est parfaitement adapté aux données de la pelle, étant construit pour soutenir ces principes. Le fait qu'IBM ait essayé d'en faire une architecture complète (360 degrés) en incluant FP et même en essayant de l'adapter au contrôle de processus n'avait pas vraiment d'importance à long terme - d'autres étaient bien meilleurs pour l'un ou l'autre.

Et le DoD avait besoin d'un traitement de données pour combattre les guerres à l'époque (la Corée venait de se terminer et le Vietnam s'approchait), et d'un langage pour soutenir l'écriture de programmes de traitement de données d'une manière indépendante de la machine. C'est pourquoi COBOL a été développé à la suite de la conférence mentionnée.

---

* 1 - FORTRAN s'est beaucoup amélioré depuis, mais cela n'a pas vraiment changé la nature de base.