Jak działało programowanie, gdy programiści używali kart perforowanych?

Widziałem to: uczenie się programowania na kartach do gry

i widziałem to: http://en.wikipedia.org/wiki/Computer_programming_in_the_punched_card_era

ale pozostawiają wiele do życzenia.

Czy ktoś może mi wyjaśnić, w jaki sposób programiści zaprogramowali się, gdy używali kart perforowanych? W szczególności system komputerów wejściowych wykorzystywany do uzyskiwania instrukcji z samej karty perforowanej.

Niewiele wiem o retrokomputerach, więc każdy system wprowadzania danych, który znasz, byłby w porządku. Doceniane są również bardziej ogólne odpowiedzi.

Jednym słowem słabo.

Przynajmniej na jakiejkolwiek maszynie, z której kiedykolwiek korzystałem lub o której słyszałem, nie podawano kart po kolei. Były zautomatyzowane czytniki kart, które karmiły i czytały setki kart na minutę (prawdopodobnie około 1000 na minutę, ale nie jestem pewien dokładnych specyfikacji).

W typowym przypadku napisałeś kod ręcznie, a następnie przełożyłeś go na karty. Każda karta zawiera jeden wiersz kodu (do 80 kolumn). Zabrałeś talię kart do wykonania. W zależności od zaległości, od godziny do około dnia później, otrzymałeś swoją talię wraz z wydrukiem wyników.

Powinienem chyba dodać: ponieważ twoja talia kart działała jako zadanie, nie tylko przesłałeś kod dla samego programu - musiałeś napisać coś niejasno podobnego do pliku wsadowego / skryptu powłoki ze wskazówkami, jak skompilować i wykonać swój kod. Na przykład IBM JCL pozostaje pod silnym wpływem jego kart Hollerith.

Kolejna drobna uwaga: w większości systemów pamiętam, że na każdej karcie dziurkowania zwykle umieszczasz numer linii. Najwyraźniej uniknąłeś zrzucenia talii, gdybyś mógł, ale kiedy (nie jeśli) ktoś został upuszczony, tak naprawdę wielu nie wyobrażało sobie takiej tragedii. Ciekawy punkt boczny: przynajmniej sortowniki kart, które widziałem, używały sortowania radix - dzielą karty na 10 pojemników na podstawie jednej cyfry numeru linii, a następnie „łączą” je razem (upuszczają wszystkie karty w jedną bin w kolejności), a następnie powtórz tyle razy, ile cyfr w numerach linii.

Karty Hollerith były niezwykle wpływowe - 80 kolumn jako limit wciąż utrzymuje się w prawie niepokojącym stopniu. Przynajmniej na komputerach mainframe Control Data, na system plików miał duży wpływ. Dobrze po tym, jak większość kart Hollerith zniknęła, ich resztki były widoczne w systemie operacyjnym - na przykład pliki tekstowe były często przechowywane jako seria 80-znakowych rekordów, bez względu na to, jak mało / wiele znaków faktycznie zawierała linia. Nadal pamiętam moje zaskoczenie „zacofaniem” systemu takiego jak Unix, w którym trzeba było przeczytać wszystkie poprzednie wiersze, aby znaleźć wiersz N pliku tekstowego, zamiast po prostu szukać bezpośrednio.

Wykorzystałeś dziurkacz karty jako edytor.

• Włóż == przebij nową kartę.
• Przesuń == podnieś kartę i przenieś ją we właściwe miejsce.
• Usuń == wyjmij kartę i wrzuć do kosza
• Kopiuj - lepsze stemple na kartach miały funkcję kopiowania, która mogła kopiować kolejną kolumnę karty po kolumnie.
• Odmień znak - użyj funkcji kopiowania, ale wpisz znaki zastępcze po osiągnięciu znaku, który chcesz zastąpić.
• Usuń znak - użyj funkcji kopiowania, ale przytrzymaj skopiowaną kartę, aby zatrzymać jej ruch i naciśnij spację dla każdej postaci, którą chcesz „usunąć”
• Wstaw znaki - skorzystaj z funkcji kopiowania, ale trzymaj oryginalną kartę nieruchomą podczas pisania nowego tekstu.

W przeważającej części karty były „niezmienne”, ale można było usuwać postacie, osłaniając dziury cienką nieprzezroczystą taśmą klejącą.

Czytasz w swoim programie w otoczeniu odpowiedniego JCL i czekałeś, aż drukarka wypluje wyniki. (Mogą to być godziny!)

Bardzo powoli.

Moja matka była takim programistą, więc dorastając miałam mnóstwo takich kart w domu. To, co zrobiliby, to kodowanie programu na kartach, a następnie podawanie kart do czytnika kart jeden po drugim (podobnie jak teraz działają automaty do głosowania). Jeśli upuścisz karty - będziesz miał dużo kłopotów, ponieważ masz tylko przydzielony czas X maszyny i będziesz musiał ustawić je we właściwej kolejności i ponownie zacząć karmić maszynę od nowa i spróbować na czas, zanim następny programista cię wyrzuci. Trywialny (w naszych obecnych standardach) program mógł wymagać setek, jeśli nie tysięcy takich kart, oraz godzin pracy maszyny, aby ją załadować i uruchomić.

Bardzo nudne.

Pod pewnymi względami „niezbyt inny”, pod pewnymi względami „bardzo inny”.

Pisali kod źródłowy, zwykle na papierze. Zostało to ponownie wpisane na kartach dziurkowanych (jedna linia kodu źródłowego na kartę, zwykle z numerami linii, dzięki czemu można łatwo naprawić kod źródłowy, gdy skończy się w złej kolejności).

Program został następnie prefiksowany kartami z instrukcjami dotyczącymi kompilacji programu i sufiksem z instrukcjami dotyczącymi jego uruchomienia i plików danych do użycia (lub taśm do zamontowania itp.).

Następnie przekazano to operatorom, którzy ładowali karty do czytnika prędkości, uruchamiali zadanie i zwracali wyniki na wydrukach.

Ponieważ typowy cykl edycji / kompilacji / wyników jest na poziomie „jutra”, ludzie mieli tendencję do bardziej paranoicznego sprawdzania kodu pod kątem błędów składniowych.

Bez możliwości interaktywnego debugowania jedynym sposobem na śledzenie wykonania byłyby linie debugowania drukowane podczas wykonywania.

W niektórych miejscach kod byłby umieszczony na taśmie perforowanej, a nie na kartach perforowanych.