Era postato su Usenet dal autore, Ed Nather (<nather@astro.as.utexas.edu>), 21 maggio 1983.
Articolo
recente, devoto al lato macho della programmazione,
faceva
questa evidente e semplice dichiarazione:
I
programmatori veri scrivono in FORTRAN.
Forse
lo fanno oggi,
in questa decadente era di
birra
leggera, calcolatrici tascabili e software “user-friendly”
ma
nei Bei Vecchi Tempi,
quando il termine “software” suonava comico
e Comuputer Veri
erano fatti di memorie a tamburo e valvole,
i
Programmatori Veri scrivevano in codice
macchina.
No FORTRAN. No RATFOR. Neanche
linguaggio assembler.
Codice Macchina.
Crudi,
impenetrabili numeri esadecimali senza abbellimenti.
Direttamente.
Affinché
intera nuova generazione di programmatori
non cresce in ignoranza di questo
passato glorioso,
mi
sento obbligato di descrivere,
come meglio mi riesce tra divario
generazionale,
come un Vero Programmatore scriveva il codice.
Lo
chiamerò Mel,
perché questo era il suo nome.
Per
prima volta ho riscontrato Mel quando sono venuto a lavorare
per Royal McBee Computer Corp.,
ormai defunto fornitore
di una compagnia di macchine da scrivere.
La
ditta fabbricava LGP-30,
piccolo, economico (secondo
i standard di quei giorni)
calcolatore con memoria a tamburo,
e
ha appena cominciato fabbricare
RPC-4000, molto perfezionato,
più
grande, migliore, più veloce — calcolatore con memoria a
tamburo.
Le
memorie a feritte costavano troppo,
e non erano disponibili, comunque.
(Eco
perché non avete mai sentito di quella ditta,
o di quel
calcolatore.)
Sono
stato assunto per scrivere compilatore FORTRAN
per quel nuovo
prodigio e Mel era la mia guida tra le sue meraviglie.
Mel non approvava
i compilatori.
“Se il programma non può modificare suo stesso
codice”,
chiedeva, “può essere
buono?”
Mel ha scritto,
in esadecimale,
il
programma più popolare che la ditta posedeva.
Girava
su LGP-30
e giocava blackjack con potenziali clienti
alle
fiere.
Il suo effetto era sempre
teatrale.
La
bellezza di LGP-30 era su ogni fiera,
e venditori di IBM stavano
attorno
parlando tra di loro.
Se
hanno veramente venduto qualche computer o no
era la questione che non
abbiamo mai discusso.
Lavoro
di Mel era riscrivere
programma blackjack per
RPC-4000.
(Porting? Che cosa significa?)
Il
nuovo computer aveva schema
d'indirizzamento uno-più-uno,
in
cui ogni istruzione macchina,
in aggiunta al codice operativo
e
indirizzo del operando richiesto,
aveva
un altro indirizzo che indicava dove, sul tamburo rotante,
era collocata
prossima istruzione.
In parlato
moderno,
ogni singola istruzione era seguita
da GO TO!
Mettetevi questo nella pipa Pascal e
fumatevelo.
Mel amava RPC-4000
perché
poteva ottimizzare suo codice:
cioè, mettere
istruzioni sul tamburo
così che appena una finisce il suo lavoro,
l'altra
sta arrivando sotto la “testina”
ed è disponibile
per esecuzione immediata.
C'era
un programma per fare questo lavoro,
un “assembler
ottimizzante”,
ma Mel ha rifiutato di usarlo.
“Non sai mai dove va a mettere le cose”,
ha
spiegato, “così devi usare le costanti
separate”.
Solo
molto tempo dopo ho capito questa osservazione.
Dato
che Mel conosceva valore numerico
di ogni istruzione operativa,
e
assegnavale suoi indirizzi sul tamburo,
ogni
istruzione che scriveva poteva essere vista
come costante numerica.
Poteva
prendere precedente istruzione di “somma”, per
nominare una,
e moltiplicare per essa,
se aveva valore numerico che gli
serviva.
Modificare
il suo codice non era facile per qualcun altro.
Ho
confrontato programmi di Mel ottimizzati a mano
con lo stesso codice
massaggiato da assembler ottimizzante,
e sempre quelli di Mel giravano più
veloce.
Questo
perché il metodo di progettazione di programmi “top-down”
non era stato ancora
inventato,
e comunque Mel non lo userebbe mai.
Scriveva
come primo la parte interna dei suoi cicli,
così che poteva scegliere
prima
indirizzo ottimo sul tamburo.
Assembler
ottimizzante non era abbastanza brillante per farlo in questo modo.
Mel non
ha scritto mai un ciclo per ritardo, mai,
persino quando cocciuto
Flexowriter
richiedeva ritardo tra caratteri di output per stamparli
correttamente.
Egli
semplicemente metteva le istruzioni sul tamburo
così che ogni successiva ha
appena passato la
testina
quando era chiamata;
il
tamburo doveva fare un altro giro completo
per trovare prossima
istruzione.
Ha coniato un
termine indimenticabile per questa procedura.
Benchè “ottimo” è un termine assoluto,
come “unico”, è diventato la prassi verbale comune
di farlo
relativo:
“non del tutto ottimo” o “meno ottimo”
o “non troppo ottimo”.
Mel chiamava
la locazione con massimo ritardo
“il
più pessimo”.
Dopo
aver finito il programma blackjack
e averlo portato a girare
(“Addirittura il inizializzatore è
ottimizzato”,
diceva fieramente),
ha
ricevuto dal dipartimento vendite Richiesta di Cambiamento.
Il
programma usava elegante (e ottimizzato)
generatore di numeri casuali
per
mischiare le “carte” e metterle sul “tavolo”,
ed alcuni del dipartimento vendite lo sentivano
troppo onesto,
perché ogni tanto i clienti perdevano.
Volevano
da Mel cambiare il programma
così, che azionando un interruttore sul
pannello,
programma cambia comportamento a lascia il cliente vincere.
Mel rifiutava.
Pensava
che questo era palesemente disonesto,
che era,
e che questo violava la sua
integrità personale come programmatore,
che violava,
allora ha rifiutato
di farlo.
Il
Capo Vendite ha parlato con Mel,
così come ha fatto anche il Grande Capo
e, sull'insistenza del capo,
alcuni Amici Programmatori.
Alla
fine Mel ha ceduto e ha scritto il codice,
ma completamente
capovolto,
e, quando
interruttore era nella posizione giusta,
il programma barava, vincendo
ogni volta.
Mel era
deliziato,
sostenendo che suo subconscio era incontrollabilmente etico,
a
ha inflessibilmente rifiutato di ripararlo.
Dopo
che Mel ha lasciato la ditta per pa$coli più verdi,
il Grande Capo mi ha
chiesto di vedere il codice
se potevo trovare il test e rovesciarlo.
Con
qualche rillutanza ho accettato di guardare.
Attraversare codice di
Mel era vera avventura.
Spesso
credevo che programmazione è una forma d'arte,
di cui reale valore può essere
apprezzato solo
da altro esperto in questa arte arcana;
c'erano
incantevoli gemme e mosse splendenti
nascosti dal sguardo umano e
ammirazione, a volte per sempre,
dalla natura stessa del processo.
Potete
imparare molto su di un individuo
semplicemente leggendo suo codice,
anche
esadecimale.
Mel era, penso, un
genio non celebrato.
Il
mio choc più grande è venuto
quando ho trovato un ciclo innocente, che non
aveva nessun test dentro.
Nessun test. Niente.
Senso
comune dice che questo deve essere un circuito chiuso,
dove il programma gira
per sempre, senza fine.
Tuttavia,
il programma andava dritto tra questo ciclo,
e in salvo usciva su altro
lato.
Mi sono volute due
settimane per scoprire come.
Il
computer RPC-4000 aveva una facilità veramente
moderna
chiamata index register.
Permette
a programmatore di scrivere ciclo
che usa istruzioni indicizzate
dentro;
ogni volta dentro,
il
valore di index register
era sommato con indirizzo di quella
istruzione,
così poteva riferire
al prossimo dato della serie.
Si
doveva solo incrementare index register
ogni volta.
Mel non lo ha usato mai.
Invece, lui
metteva la istruzione nel registro della macchina,
aggiungeva uno al suo
indirizzo,
e la scriveva dietro.
Poteva
eseguire la istruzione modificata
direttamente dal registro.
Il
ciclo era scritto in modo che tempo di addizione
era preso in
considerazione —
appena
la istruzione finiva,
la prossima era sotto testina del
tamburo,
pronta per uso.
Ma il
ciclo non aveva nessun test dentro.
Indizio
vitale era venuto quando ho notato
index register bit,
il bit
collocato tra indirizzo
e codice operazione nella istruzione,
era
uno —
eppure Mel non usava mai index register,
lasciandolo
zero per tutto il tempo.
La
illuminazione era così forte da accecarmi.
Mel
ha messo i dati che elaborava
vicino fine dello spazio di
memoria —
alle locazioni più alte che le istruzioni potevano
indirizzare —
così, quando
l'ultimo dato era elaborato,
incrementando indirizzo della istruzione
si
manifestava overflow.
Il
riporto aggiungeva uno al
codice di operazione, cambiandola alla
prossima nel'insieme d'istruzioni:
istruzione di salto.
Bastava
questo, la prossima istruzione del programma era
sulla
locazione zero,
e il programma felicemente proseguiva in questa
strada.
Non
ho tenuto contatti con Mel,
allora non so se lui sapeva di andar
contro
le tecniche di programmazione
nei quei giorni lontani.
Mi piace pensare che non lo
sapeva.
In ogni caso,
ero
così impressionato che ho smesso di cercare
il test offensivo,
dicendo al
Grande Capo che non lo posso trovare.
Non
sembrava sorpreso.
Quando
ho lasciato la ditta,
il programma blackjack barava
ancora
quando avevate girato interruttore nel senso giusto,
e penso che
dovrebbe essere così.
Non
mi sentirei a mio agio
tagliando a pezzi il codice di Vero
Programmatore.
Questo è un pezzo grosso della epica eroica di hackeraggio, versi sciolti o no. Nelle alcune immagini laterali capta di più della estetica e psicologia di hackeraggio che tutti altri testi scolastici sul argomento messi insieme. (Ma per punto di vista opposto vedi Real Programmer.)
[postscriptum 1992 — autore scrive: “La versione originale postata nella rete non era in versi sciolti, neanche approsivamente — era semplice testo prosaico, in paragrafi non allineati. Rimbalzando nella rete apparentemente era stato modificato in forma di 'versi sciolti', tanto popolare oggi. In altre parole, ha nella rete subito hacking. Sembra appropriato, comunque.” Autore ha aggiunto che la versione in 'versi sciolti' gli piace più del suo originale prosaico ...]
[aggiornamento 1999: Cognome di Mel è adesso noto. Il manuale di LGP-30 riferisce a “Mel Kaye di Royal McBee che ha fatto grosso di programmazione [...] del sistema ACT 1”.]
[2001: Royal McBee LPG-30 ha un altro caso che acresce la sua fama. È saltato fuori che meteorologo Edward Lorenz faceva le simulazioni di tempo su LGP-30 quando, in 1961, ha scoperto “Effetto Farfalla” e il caos computazionale. Sembra, in qualche modo, appropriato.]
[2002: La copia di manuale di programmazione per LGP-30 è disponibile ancora http://ed-thelen.org/comp-hist/lgp-30-man.html]