Questo gioiellino della cultura hacker circola in rete dal 1982. L’ho tradotta tempo fa, basandomi sull’edizione contenuta nel Jargon File e cencando di mantenerne la forma “poetica” e le particolarità nella punteggiatura. Per informazioni più approfondite rimando a Wikipedia.

Pubblicato su Usenet dall’autore, Ed Nather (nather@astro.as.utexas.edu), il 21 Maggio 1983.

Un recente articolo riguardo al “machismo” della programmazione
conteneva la secca, austera affermazione:

I Veri Programmatori scrivono in FORTRAN.

Forse lo fanno oggi,
in quest’evo decadente di
birra light, calcolatrici tascabili e programmi “user-friendly”
ma nei Bei Tempi Andati,
quando dire “software” sembrava buffo
e i Veri Computer erano valvole e memorie a tamburo
i Veri Programmatori scrivevano in linguaggio macchina.
Non in FORTRAN. Né in RATFOR. Neppure in assemblativo.
Linguaggio Macchina.
Rozzi, disadorni, imperscrutabili numeri esadecimali.
Direttamente.

Poiché temo che un’intera generazione di nuovi programmatori
cresca ignorando un passato così glorioso,
mi sento in dovere di descrivere,
nel modo migliore che il salto generazionale mi consenta,
come scriveva codice un Vero Programmatore.
Lo chiamerò Mel,
ché quello era il suo nome.

Incontrai Mel quando lavoravo per la Royal McBee Computer Corp.,
una succursale ormai defunta della società di macchine da scrivere.
La ditta produceva l’LGP-30,
un piccolo, economico (per gli standard del tempo)
computer con memoria a tamburo,
ed aveva iniziato a produrre
l’RCP-4000, un computer migliorato,
più grande e più veloce — sempre con memoria a tamburo.
I nuclei magnetici costavano troppo
e non sembravano destinati a durare.
(Ecco perché non avete mai sentito parlare della ditta,
né del computer).

Ero stato assunto per scrivere un compilatore FORTRAN
per questo nuovo prodigio, e Mel era la mia guida tra le sue meraviglie.
Mel non accettava i compilatori.

“Se un programma non può riscrivere il suo stesso codice”,
chiedeva, “a cosa serve?”

Mel aveva scritto,
in esadecimale,
il più famoso programma di proprietà della compagnia.
Girava sull’LGP-30
e giocava a blackjack con potenziali clienti
alle fiere dell’informatica.
Aveva sempre un effetto spettacolare.
Lo stand dell’LGP-30 era pieno ad ogni show,
e i rappresentanti dell’IBM se ne stavano lì attorno
a parlare tra loro.
Se poi ciò aiutasse a vendere computer
era una faccenda di cui non parlavamo mai.

Il lavoro di Mel era riscrivere
il programma del blackjack per l’RCP-4000.
(Port? Cos’è un port?)
Il nuovo computer aveva un metodo di indirizzamento
“one-plus-one”,
in cui ogni istruzione,
oltre al codice dell’operazione
e all’indirizzo dell’operando richiesto,
aveva un secondo indirizzo che indicava dove, sul tamburo rotante,
si trovasse l’istruzione successiva.

Nel gergo moderno,
ogni singola istruzione era seguita da un GO TO!
Pascal, prendi questo e porta a casa.

Mel amava l’RCP-4000
perché era in grado di ottimizzare il suo codice:
cioè, posizionare le istruzioni sul tamburo
cosicché, appena una finisse il proprio compito,
la successiva si trovasse proprio presso la testina
e pronta per l’esecuzione immediata.
C’era un programma che lo faceva,
un “assembler ottimizzante”,
ma Mel si rifiutava di usarlo.

“Non sai mai dove metterà le cose”,
spiegava, “quindi bisogna usare costanti separate”.

Passò parecchio prima che capissi quell’osservazione.
Poiché Mel sapeva il valore numerico
del codice di ogni operazione,
e si assegnava da solo gli indirizzi sul tamburo,
ogni istruzione che scriveva poteva essere allo stesso tempo
una costante numerica.
Poteva prendere, ad esempio, un’“add” scritto in precedenza
e moltiplicarlo per un altro numero,
se aveva il giusto valore aritmetico.
Il suo codice non era facile da modificare, per gli altri.

Comparavo i programmi ottimizzati a mano da Mel
con lo stesso codice rimaneggiato dall’assembler ottimizzante
e quelli di Mel erano sempre i più veloci.
Questo perché la programmazione “top-down”
non era stata ancora inventata,
e Mel non l’avrebbe comunque seguita.
Scriveva per prime le parti più interne dei suoi loop,
così avrebbero avuto la scelta migliore
per gli indirizzi ottimali sul tamburo.
L’assembler non era abbastanza furbo per farlo.

Mel non scriveva neppure loop ritardanti,
anche se la recalcitrante Flexowriter
aveva bisogno di una pausa tra i caratteri di output per non incepparsi.
Semplicemente, posizionava le istruzioni sul tamburo
in modo che la successiva fosse proprio oltre la testina
quando doveva essere eseguita;
il tamburo doveva effettuare un giro completo
per trovare la prossima istruzione.
Ideò un termine indimenticabile per questo sistema.
Anche se “ottimo” è un assoluto,
come “unico”, divenne prassi comune
usarlo in modo relativo:
“non proprio ottimo” o “meno ottimo”
o “non molto ottimo”.
Mel chiamava le posizioni col massimo ritardo
“le più pessime”.

Dopo aver finito il programma del blackjack
ed averlo fatto girare
(“Anche l’inizializzatore è ottimizzato”,
diceva orgoglioso)
ricevette una Richiesta di Modifica dal reparto vendite.
Il programma usava un elegante (ed ottimizzato)
generatore di numeri casuali
per mischiare le “carte” e pescare dal “mazzo”,
e per alcuni rappresentanti era troppo imparziale
visto che a volte i clienti perdevano.
Volevano che Mel modificasse il programma
cosicché, schiacciando un interruttore sulla console,
potessero cambiare le probabilità e far vincere il cliente.

Mel era riluttante.
Pensava fosse una cosa disonesta,
e lo era,
e che macchiasse la sua personale integrità di programmatore,
e la macchiava,
quindi si rifiutò.
Il Capo del reparto vendite parlò con Mel,
e così fece il Boss e, sotto la pressione del Boss,
Mel finalmente si arrese e scrisse quel codice,
ma scrisse il test al contrario,
e quando l’interruttore veniva attivato,
il programma barava e vinceva ogni volta.
Mel era estasiato:
affermava che il suo subconscio era etico oltre ogni controllo,
e si rifiutò inflessibilmente di correggere.

Dopo che Mel abbandonò la ditta per pa$coli più verdi,
il Boss mi chiese di studiare il codice
e provare a trovare il test e a capovolgerlo.
Un po’ controvoglia acconsentii a dare un’occhiata.
Seguire il codice di Mel fu una vera avventura.

Spesso ho pensato che la programmazione fosse una forma d’arte,
il cui valore effettivo possa essere misurato
solo da un altro edotto nella medesima arte arcana;
esistono amabili gemme e gesta brillanti
nascoste all’occhio e al plauso degli uomini, a volte per sempre,
per la natura stessa del procedimento.
Si può capire molto di una persona
solo leggendo il suo codice,
anche in esadecimale.
Mel, credo, fu un genio mai acclamato.

Forse lo shock più grande lo subii
quando trovai un semplice ciclo privo di condizione.
Nessun test. Nulla.
Il buonsenso suggeriva che doveva essere un ciclo chiuso
nel quale il programma avrebbe girato per sempre, senza fine.
Eppure il programma ci passava attraverso
e usciva senza problemi dall’altra parte.
Ci misi due settimane a capirlo.

L’RPC-4000 aveva una funzione molto moderna,
un registro indice.
Permetteva al programmatore di scrivere un loop
con all’interno un’istruzione indirizzata;
ogni volta,
il numero del registro indice
veniva addizionato all’indirizzo dell’istruzione
così da far riferimento
al dato successivo di una serie.
Bastava incrementare il registro indice
ogni volta.
Mel non lo usava mai.

Inviava invece l’istruzione ad un registro della macchina,
aggiungeva uno
e lo memorizzava di nuovo.
Poi eseguiva l’istruzione modificata
direttamente dal registro.
Il ciclo era scritto in modo che questo tempo d’esecuzione aggiuntivo venisse preso in considerazione —
appena questa istruzione finiva,
la prossima era già sotto la testina del tamburo,
pronta a partire.
Ma il ciclo non aveva condizioni.

L’indizio fondamentale arrivò quando notai
che il bit del registro indice,
il bit che giace tra l’indirizzo
ed il codice dell’operazione della parola dell’istruzione,
era attivo —
ma Mel non usava mai il registro indice,
lasciando quel bit a zero ogni volta.
Quando la luce si accese, quasi mi accecò.

Aveva messo i dati su cui lavorava
quasi in cima alla memoria —
le locazioni più grandi che indirizzabili dalle istruzioni —
cosicché, dopo aver gestito l’ultimo dato,
incrementare l’indirizzo dell’istruzione
lo mandava in overflow.
Il resto aggiungeva uno al codice
dell’operazione, trasformandola nella successiva istruzione del set:
un salto.
Ovviamente, l’istruzione seguente era
nell’indirizzo zero,
e il programma continuava a girare spensierato.

Non ho più sentito Mel,
quindi non so se si è arreso al diluvio di
cambiamenti che ha spazzato via le tecniche di programmazione
dopo quei giorni ormai passati.
Mi piace pensare che non l’abbia fatto.
Ad ogni modo,
ero così impressionato che smisi di cercare
il test trasgressore,
dicendo al Boss che non riuscivo a trovarlo.
Non mi sembrò sorpreso.

Quando lasciai la ditta,
il programma del blackjack barava ancora
se attivavi il giusto interruttore,
e penso che così devono andare le cose.
Non mi sentivo a mio agio
nell’hackerare il codice di un Vero Programmatore.