[Siergiej_Morozow]

Historia Mel'a
translated from English by Siergiej_Morozow
original:

Niedawny artykuł poświęcony programowaniu od strony *macho*
poczynił jasną i wyraźną deklarację:

Prawdziwi Programiści piszą w FORTRANie.

Może robią tak teraz,
w tej dekadenckiej epoce
jasnego piwa, kieszonkowych kalkulatorów i "przyjaznego" oprogramowania,
ale za Starych Dobrych Dni
kiedy termin "software" brzmiał śmiesznie
a Prawdziwe Komputery były zrobione z bębnów i lamp próźniowych,
Prawdziwi Programiści pisali w kodzie maszynowym.
Nie FORTRANie. Nie RATFORze. A nawet, nie w asemblerze.
W Kodzie maszynowym.
Surowe, nieozdobne, nieprzeniknione liczby szesnastkowe.
Bezpośrednio.

Aby całe kolejne pokolenie programistów
nie wyrosło w nieświadomości tej chwalebnej przeszłości
Czuję się zobowiązany opisać,
tak dobrze jak mogę, przez przepaść między pokoleniami,
jak Prawdziwy Programista pisał kod.
Będę go zwał Mel,
gdyż tak się właśnie nazywał.

Pierwszy raz spotkałem Mel'a, kiedy zacząłem pracę w Royal McBee Computer Corp.,
nieistniejącej już spółce podległej producentowi maszyn do pisania.
Firma produkowała LGP-30,
mały, tani (jak na ówczesne standardy)
komputer z pamięcią bębnową
i właśnie zaczęła produkować
RPC-4000, znacznie ulepszony,
większy, lepszy, szybszy - komputer z pamięcią bębnową.
Pamięci ferrytowe były zbyt drogie
zresztą i tak nie było im dane przetrwać.
(To dlatego nigdy nie słyszeliście o tej firmie
lub o jej komputerze.)

Zostałem najęty do pisania kompilatora FORTRANa
dla tego nowego cudu, a Mel stał się moim przewodnikiem po jego osobliwościach.
Mel nie pochwalał idei kompilatorów.

"Jeśli program nie może sam się modyfikować",
pytał, "co z niego za pożytek?"

Mel pisał
w kodzie maszynowym,
najpopularniejszy program, jaki miała firma.
Działał na LGP-30
i grał z potencjalnymi klientami w blackjacka
na pokazach komputerowych.
Wrażenie, które robił, było zawsze piorunujące.
Kiosk z LGP-30 był pełen po brzegi na każdym pokazie,
a sprzedawcy IBM-a stali wokół
rozmawiając ze sobą.
Czy faktycznie podnosiło to sprzedaż
było pytaniem, które nigdy nie padło.

Zadaniem Mel'a było przepisanie
programu do blackjacka na RPC-4000.
(Portowanie? Co to znaczy?)
Nowy komputer miał metodę adresowania
jeden-i-jeden,
w której każda instrukcja
oprócz kodu właściwego dla instrukcji
i adresu jej operandu,
zawierała drugi adres, który wskazywał, gdzie na wirującym bębnie
znajdowała się następna instrukcja.

Współczesnym językiem,
po każdej jednej instrukcji przychodził rozkaz GOTO!
Wsadź *to* do swej Paskalowej fajki i wypal to.

Mel uwielbiał RPC-4000
gdyż mógł optymalizować swój kod:
to jest, umieszczać instrukcje na bębnie
tak, że gdy jedna zrobiła swoje,
kolejna właśnie docierała do głowicy
dostępna do natychmiastowego wykonania.
Był od tego program,
"asembler optymalizujący",
ale Mel odmawiał wykorzystania go.

"Nigdy nie wiesz, jak on wszystko poukłada",
wyjaśniał, "więc musiałbyś używać osobnych stałych".

Minęło wiele czasu nim zrozumiałem tą uwagę.
Ponieważ Mel znał wartość liczbową
każdej instrukcji komputera,
i ustalał własne adresy na bębnie,
każda instrukcja, którą napisał, mogła być także uważana
za stałą liczbową.
Mógł, powiedzmy, wziąć wcześniejszą instrukcję "dodaj",
i pomnożyć coś przez nią
jeśli akurat miała odpowiednią wartość.
Jego kod nie był łatwy w modyfikacji dla kogoś innego.

Porównywałem ręcznie optymalizowane programy Mel'a
z tym samym kodem wymasowanym przez program optymalizujący
i kod Mel'a zawsze był szybszy.
Było to, ponieważ podejście "top-down" w projektowaniu programów
nie zostało jeszcze wynalezione,
zresztą Mel i tak by go nie używał.
Pisał najpierw najbardziej wewnętrzne pętle swojego programu,
więc jako pierwsze otrzymywały one
optymalne adresy na bębnie magnetycznym.
Asembler optymalizujący nie był na tyle sprytny.

Mel również nigdy nie pisał pętli oczekujących,
nawet gdy krnąbrny Flexowriter
musiał mieć opóźnienie między znakami na wejściu, aby działać prawidłowo.
Po prostu umieszczał instrukcje na bębnie
tak, że każda kolejna była tuż *za* głowicą odczytu
gdy była potrzebna;
Bęben musiał wykonać kolejny pełny obrót
by odnaleźć kolejną instrukcję.
Ukuł on niezapomniany termin dla tej procedury.
Choć "optymalny" jest terminem absolutnym,
jak "unikatowy", stało się powszechną praktyką językową
czynić go względnym:
"niezbyt optymalny" lub "mniej optymalny"
lub "nie bardzo optymalny".
Mel mówił o miejscach o największym czasie oczekiwania
"najbardziej pesymalne"

Gdy ukończył program do blackjacka
i uruchomił go
("Nawet inicjalizator jest zoptymalizowany",
rzekł dumnie),
otrzymał żądanie zmiany od zarządu.
Program używał eleganckiego (zoptymalizowanego)
generatora liczb losowych
aby tasować "karty" i pobierać z "talii",
i niektórzy w dziale sprzedaży czuli, że było to zbyt uczciwe,
gdyż czasem klienci przegrywali.
Chcieli, by Mel zmienił program
tak, by po przełączeniu przycisku na pulpicie kontrolnym,
mogli odmienić losy i pozwolić klientowi wygrać.

Mel wzburzył się.
Czuł że było to wyraźnie nieuczciwe,
gdyż istotnie było,
i że uderzało to w jego osobowość programisty,
co istotnie robiło,
przeto odmówił.
Menedżer Działu Sprzedaży mówił z nim,
jak również Szef Szefów i, na jego przynaglenia,
kilku Kolegów Programistów.
Mel ostatecznie poddał się i napisał program,
ale test uczynił na odwrót,
tak, że gdy przełącznik naciskano,
program oszukiwał, zawsze wygrywając.
Mel był wniebowzięty,
twierdząc, że jego podświadomość była bezgranicznie uczciwa,
i twardo sprzeciwiała się wezwaniom do poprawy.

Gdy Mel opuścił firmę, odchodząc ku zieleńszym pa$twi$kom,
Szef Szefów poprosił mnie, bym spojrzał na kod,
i sprawdził, czy zdołam odnaleźć test i odwrócić go.
Choć niechętnie, zgodziłem się.
Śledzenie jego kodu było prawdziwą przygodą.

Często czułem, że programowanie jest formą sztuki,
której prawdziwą wartość może tylko docenić
inny biegły w jej tajemnych arkanach;
są tam śliczne brylanty i znakomite wyczyny
ukryte przed ludzkim okiem i podziwem, czasem na zawsze,
przez samą tylko naturę tego procesu.
Możesz się wiele dowiedzieć o człowieku
po prostu czytając jego kod,
nawet w szesnastkowym.
Mel był, tak myślę, niewysłowionym geniuszem.

Zapewne mój największy wstrząs nadszedł
gdy znalazłem niewinną pętlę, która nie miała warunku zakończenia.
Bez warunku. Żadnego.
Zdrowy rozsądek podpowiadał, że była to pętla nieskończona,
gdzie program krążyłby, na zawsze, wiecznie.
Program jednak przekraczał ją
i bezpiecznie wynurzał się po drugiej stronie.
Dwa tygodnie zajęło mi rozwiązanie tego.

Komputer RPC-4000 miał naprawdę nowoczesny ustrój
zwany rejestrem zliczającym.
Pozwalał on programiście napisać pętlę,
która używała instrukcji indeksowanej;
za każdym przejściem
wartość tego rejestru
była dodawana do adresu operandu tej instrukcji
tak, aby wskazał on
kolejny rekord w serii danych.
Musiał on tylko inkrementować ten rejestr
za każdym przejściem.
Mel nigdy go nie używał.

Zamiast tego wciągał instrukcję do rejestru maszynowego,
dodawał jeden do jej adresu
i zapisywał ją z powrotem.
Potem wykonywał tak zmodyfikowaną instrukcję
prosto z rejestru.
Pętla była tak napisana, aby ten dodatkowy czas
był brany pod uwagę -
tuż po zakończeniu wykonywania tej instrukcji
kolejna była już pod głowica bębna,
gotowa do działania.
Ale pętla nie miała warunku zakończenia.

Niezbędna wskazówka nadeszła, gdy zauważyłem
bit rejestru zliczającego,
bit, który znajdował się między adresem
a kodem instrukcji w słowie maszynowym,
był ustawiony -
ale Mel nigdy nie używał rejestru zliczającego,
pozostawiając go zawsze na zerze.
Gdy światło zabłysło, niemal mnie oślepiło.

Umieścił dane, na których pracował
w pobliżu czubka pamięci -
najwyższej lokacji, jaką instrukcja mogła adresować -
zatem, kiedy ostatni rekord został przetworzony,
inkrementowanie adresu instrukcji
spowodowałoby jego zawinięcie się do zera.
Flaga przeniesienia dodałaby jeden
do kodu instrukcji, zmieniając ją na następną z zestawu instrukcji:
rozkaz skoku.
Oczywiście, kolejna instrukcja
była pod adresem zero,
a program wesoło biegł dalej swoją drogą.

Nie byłem w kontakcie z Melem,
więc nie wiedziałem, czy kiedykolwiek poddał się fali zmian,
która obmyła techniki programistyczne
od czasu tych dawno minionych dni.
Lubię myśleć, że nie.
W każdym razie
byłem pod takim wrażeniem, że przestałem szukać
tego obraźliwego testu,
mówiąc Szefowi Szefów, że nie mogłem go odnaleźć.
Nie wyglądał na zaskoczonego.

Gdy opuściłem firmę,
program do blackjacka nadal oszukiwał
kiedy przestawiłeś właściwy przełącznik
i myślę, że tak właśnie powinno być.
Nie czułem się spokojny
hakując kod Prawdziwego Programisty.

Jest to jeden z wielkich eposów heroicznych królestwa hakerów, wolnym wierszem lub nie. W kilku oszczędnych obrazach uchwycił więcej z estetyki i psychologii hakerstwa niż wszystkie uczone tomy razem wzięte. (Ale by zobaczyć sprawę z innego punktu widzenia, zobacz hasło Real Programmer w Jargonfile).

#programowanie #pasta

[D.....1]

tl;dr