Come funzionava la programmazione quando i programmatori utilizzavano le schede perforate?

Ho visto questo: imparare a programmare su schede perforate

e ho visto questo: http://en.wikipedia.org/wiki/Computer_programming_in_the_punched_card_era

ma lasciano molto a desiderare.

Qualcuno può spiegarmi come i programmatori hanno programmato quando hanno usato le schede perforate? In particolare, il sistema di computer di input utilizzato per ricavare istruzioni dalla scheda perforata stessa.

Non so molto sui retrocomputer, quindi qualsiasi sistema di input con cui hai familiarità andrebbe bene. Sono anche apprezzate risposte più generali.

In una parola, male.

Almeno su qualsiasi macchina che io abbia mai usato o sentito parlare, però non hai alimentato le carte una alla volta. C'erano lettori di carte automatizzati che potevano alimentare e leggere centinaia di carte al minuto (probabilmente circa 1000 / minuto, ma non sono sicuro delle specifiche esatte).

In un caso tipico, hai scritto il codice a mano, quindi l'hai punzonato sulle carte. Ogni carta contiene una riga di codice (fino a 80 colonne). Hai preso il mazzo di carte per essere eseguito. A seconda dell'arretrato, da circa un'ora a circa un giorno circa, il mazzo viene ripristinato insieme a una stampa dei risultati.

Dovrei probabilmente aggiungere: dal momento che il tuo mazzo di carte è stato eseguito come lavoro, non hai semplicemente inviato il codice per il programma stesso, ma hai dovuto scrivere qualcosa di vagamente simile a un file batch / script di shell con le istruzioni per compilare ed eseguire il tuo codice. IBM JCL (per esempio) rimane fortemente influenzato dalle origini delle sue carte Hollerith.

Un altro punto secondario: sulla maggior parte dei sistemi che ricordo, di solito includevi un numero di riga su ogni scheda perforata. Ovviamente hai evitato di far cadere un mazzo se potevi, ma quando (non se) uno è stato lasciato cadere, non è stata quasi la tragedia che molti immaginano. Interessante punto laterale: almeno gli smistatori di carte che ho visto hanno usato un ordinamento radix: avrebbero separato le carte in 10 scomparti, in base a una cifra del numero di linea, quindi le avrebbero "unite" insieme (lasciando cadere tutte le carte in una singola bin in ordine), quindi ripetere tutte le volte quante sono state le cifre nei numeri di riga.

Le carte Hollerith erano estremamente influenti: 80 colonne come limite sopravvivono ancora in misura quasi inquietante. Almeno sui mainframe di Control Data, anche cose come il file system sono state influenzate abbastanza pesantemente. Ben dopo che le carte Hollerith erano quasi completamente sparite, i resti di esse erano visibili nel sistema operativo - ad esempio, i file di testo venivano spesso archiviati come una serie di record di 80 caratteri, indipendentemente da quanti / quanti caratteri contenessero effettivamente una riga. Ricordo ancora la mia sorpresa per la "arretratezza" di un sistema come Unix in cui dovevi leggere tutte le righe precedenti per trovare la riga N di un file di testo, invece di essere solo in grado di cercarlo direttamente.

Hai usato il punch card come editor.

• Inserisci == perfora una nuova carta.
• Sposta == raccogli la carta e spostala nel punto giusto.
• Elimina == estrai la carta e gettala nel cestino
• Copia: i migliori perforatori di carte avevano una funzione di copia che poteva copiare un'altra carta colonna per colonna.
• Sostituisci un personaggio: usa la funzione di copia ma digita i caratteri sostitutivi quando raggiungi il carattere che devi sostituire.
• Elimina un personaggio - usa la funzione copia ma tieni premuta la carta copiata per fermarla e colpire lo spazio per ogni personaggio che vuoi "cancellare"
• Inserisci caratteri: utilizza la funzione di copia ma tieni ferma la scheda originale durante la digitazione del nuovo testo.

Per la maggior parte le carte erano "immutabili" ma si potevano rimuovere i personaggi facendo tap sui fori con un sottile nastro adesivo opaco.

Hai letto nel tuo programma circondato dal JCL appropriato e hai aspettato che la stampante sputasse i risultati. (Potrebbero essere ore!)

Molto lentamente.

Mia madre era una tale programmatrice, quindi ho avuto tonnellate di queste carte a casa mentre crescevo. Quello che avrebbero fatto sarebbe stato codificare il programma sulle carte e quindi inserire le carte nel lettore di carte una alla volta (in modo simile a come funzionano ora le macchine di voto). Se lasci cadere le carte, potresti avere un sacco di problemi, perché hai solo X tempo macchina assegnato per te e dovresti farli sistemare nell'ordine giusto e ricominciare a alimentare nuovamente la macchina e provare a fare in tempo prima che il prossimo programmatore ti butti fuori. Un programma banale (nei nostri attuali standard) potrebbe aver richiesto centinaia, se non migliaia, di tali schede e ore di tempo macchina per caricarlo ed eseguirlo.

Molto noioso.

In un certo senso "non troppo diverso", in un certo senso "molto diverso".

Hanno scritto il codice sorgente, di solito su carta. Questo è stato quindi riscritto su schede perforate (una riga di codice sorgente per scheda, di solito con numeri di riga, in modo da poter facilmente aggiustare il codice sorgente quando è finito nell'ordine sbagliato).

Il programma è stato quindi preceduto da schede con istruzioni su come compilare il programma e suffisso con istruzioni su come eseguirlo e quali file di dati utilizzare (o nastri da montare, ecc., Ecc.).

Questo come poi presentato agli operatori, che caricavano le carte in un lettore di velocità, eseguiva il lavoro e restituiva i risultati sulle stampe.

Con un tipico ciclo di modifica / compilazione / risultati nell'ordine di "domani", le persone tendevano ad essere più paranoiche al banco controllando il loro codice per errori di sintassi.

Senza alcuna possibilità di debug interattivo, l'unico modo per tracciare l'esecuzione sarebbero le righe di debug stampate durante l'esecuzione.

In alcuni punti, il codice si troverebbe sul punch tape anziché sulle schede perforate.