Comment fonctionnait la programmation lorsque les programmeurs utilisaient des cartes perforées?

Je l'ai vu: apprendre à programmer sur des cartes perforées

et je l'ai vu: http://en.wikipedia.org/wiki/Computer_programming_in_the_punched_card_era

mais ils laissent beaucoup à désirer.

Quelqu'un peut-il m'expliquer comment les programmeurs ont programmé lorsqu'ils ont utilisé des cartes perforées? Plus précisément, le système d'ordinateurs d'entrée utilisé pour dériver des instructions de la carte perforée elle-même.

Je ne connais pas grand-chose aux rétrocomputerateurs, donc n'importe quel système d'entrée que vous connaissez serait bien. Des réponses plus générales sont également appréciées.

En un mot, mal.

Au moins sur n'importe quelle machine que j'aie jamais utilisée ou dont j'ai entendu parler, vous n'avez cependant pas alimenté les cartes une à la fois. Il y avait des lecteurs de cartes automatisés qui alimentaient et lisaient des centaines de cartes par minute (probablement environ 1000 / minute, mais je ne suis pas sûr des spécifications exactes).

Dans un cas typique, vous avez écrit le code à la main, puis vous l'avez frappé sur des cartes. Chaque carte contient une ligne de code (jusqu'à 80 colonnes). Vous avez pris le jeu de cartes à exécuter. En fonction du carnet de commandes, d'une heure environ à un jour ou deux plus tard, vous avez récupéré votre jeu avec une impression des résultats.

Je devrais probablement ajouter: puisque votre jeu de cartes a fonctionné comme un travail, vous n'avez pas simplement soumis le code du programme lui-même - vous avez dû écrire quelque chose de vaguement similaire à un fichier batch / script shell avec les instructions pour compiler et exécuter votre code. IBM JCL (par exemple) reste fortement influencé par ses origines de cartes Hollerith.

Autre petit point: sur la plupart des systèmes, je me souviens, vous incluiez normalement un numéro de ligne sur chaque carte perforée. Vous avez évidemment évité de laisser tomber un deck si vous le pouviez, mais quand (pas si) un a été largué, ce n'était pas vraiment la tragédie que beaucoup imaginent. Point de côté intéressant: au moins les trieurs de cartes que j'ai vus utilisaient un tri radix - ils séparaient les cartes en 10 cases, sur la base d'un chiffre du numéro de ligne, puis les «fusionnaient» ensemble (déposez toutes les cartes en une seule bin dans l'ordre) puis répétez autant de fois que vous aviez de chiffres dans les numéros de ligne.

Les cartes Hollerith étaient extrêmement influentes - 80 colonnes car une limite survit encore à un degré presque inquiétant. Au moins sur les mainframes Control Data, des éléments comme le système de fichiers ont également été fortement influencés. Bien après que les cartes Hollerith aient disparu, les restes étaient visibles dans le système d'exploitation - par exemple, les fichiers texte étaient souvent stockés sous la forme d'une série d'enregistrements de 80 caractères, quel que soit le nombre / le nombre de caractères qu'une ligne contenait réellement. Je me souviens encore de ma surprise devant le "retard" d'un système comme Unix où il fallait lire toutes les lignes précédentes pour trouver la ligne N d'un fichier texte, au lieu de pouvoir simplement la rechercher directement.

Vous avez utilisé le perforateur de carte comme éditeur.

• Insérez == perforez une nouvelle carte.
• Déplacer == ramasser la carte et la déplacer au bon endroit.
• Supprimer == sortir la carte et la jeter à la poubelle
• Copie - les meilleurs perforateurs de cartes avaient une fonction de copie qui pouvait copier une autre carte colonne par colonne.
• Remplacer un caractère - utilisez la fonction de copie mais saisissez les caractères de remplacement lorsque vous atteignez le caractère que vous devez remplacer.
• Supprimer un personnage - utilisez la fonction de copie mais maintenez la carte copiée pour l'empêcher de bouger et appuyez sur l'espace pour chaque personnage que vous souhaitez "supprimer"
• Insérer des caractères - utilisez la fonction de copie mais maintenez la carte d'origine immobile pendant que vous saisissez le nouveau texte.

Pour la plupart, les cartes étaient "immuables", mais vous pouviez supprimer les caractères en collant les trous avec du ruban adhésif fin et opaque.

Vous avez lu dans votre programme entouré du JCL approprié et attendu que l'imprimante crache les résultats. (Ça pourrait être des heures!)

Très lentement.

Ma mère était un tel programmeur, donc j'avais des tonnes de ces cartes à la maison en grandissant. Ce qu'ils allaient faire était d'encoder le programme sur les cartes, puis d'insérer les cartes une par une dans le lecteur de cartes (comme le fonctionnement actuel des machines à voter). Si vous laissiez tomber les cartes - vous auriez beaucoup de problèmes, car vous n'avez que le temps de la machine X alloué pour vous et vous devriez les disposer dans le bon ordre et recommencer à alimenter la machine à nouveau et essayer de faire à temps avant que le prochain programmeur ne vous expulse. Un programme trivial (dans nos normes actuelles) aurait pu nécessiter des centaines, voire des milliers, de telles cartes, et des heures de temps machine pour le charger et l'exécuter.

Très fastidieux.

À certains égards, «pas trop différent», à certains égards «très différent».

Ils ont écrit le code source, généralement sur papier. Celui-ci a ensuite été retapé sur des cartes perforées (une ligne de code source par carte, généralement avec des numéros de ligne, afin que vous puissiez facilement corriger votre code source lorsqu'il s'est retrouvé dans le mauvais ordre).

Le programme a ensuite été préfixé avec des cartes contenant des instructions sur la façon de compiler le programme et suffixé avec des instructions sur la façon de l'exécuter et sur les fichiers de données à utiliser (ou les bandes à monter, etc., etc.).

Cela a ensuite été soumis aux opérateurs, qui chargeaient les cartes dans un lecteur de vitesse, exécutaient le travail et renvoyaient les résultats sur les impressions.

Avec un cycle typique d'édition / compilation / résultats de l'ordre de "demain", les gens avaient tendance à être plus paranoïaques à vérifier leur code pour les erreurs de syntaxe.

Sans possibilité de débogage interactif, la seule façon de suivre l'exécution serait de déboguer les lignes imprimées pendant l'exécution.

Dans certains endroits, le code serait sur du ruban perforé plutôt que sur des cartes perforées.