Vero. Ma sui social prima dei social, sui Newsgroup di Usenet, si potevano anche trovare cose così…

La storia di Mel

Postato su Usenet da Ed Nather (nather@astro.as.utexas.edu), il 21 maggio 1983.

Un’articolo recente, devoto
al lato più macho della programmazione,
faceva questa chiara e semplice dichiarazione:

I veri programmatori scrivono in FORTRAN.

Forse lo fanno oggi,
in questa decadente era di birra lite,
calcolatrici tascabili e software “user-friendly”.
Ma nei Bei Vecchi Tempi,
quando il termine “software” suonava comico
e i Comuputer Veri erano fatti con memorie
a tamburo¹ e valvole,
i Programmatori Veri scrivevano in codice macchina.

Non in FORTRAN.
Non in RATFOR.
Neanche in assembler.
Codice Macchina.
Crudi, disadorni, imperscrutabili
numeri esadecimali.
Direttamente.

Affinché un’intera nuova
generazione di programmatori
non cresca nell’ignoranza di questo
passato glorioso,
mi sento obbligato a descrivere,
attraversando come meglio posso
questo gap generazionale,
come un Vero Programmatore
scriveva codice.

Lo chiamerò Mel,
perché questo era il suo nome.

Incontrai per prima volta Mel
quando andai a lavorare per la
Royal McBee Computer Corp.,
un’ormai defunta sussidiaria della compagnia
di macchine da scrivere.

La ditta fabbricava LGP-30,
un piccolo, economico
(secondo i standard di quei giorni)
calcolatore con memoria a tamburo,
e aveva appena cominciato a fabbricare
RPC-4000, un perfezionato,
più grande,
migliore,
più veloce
calcolatore con memoria a tamburo.

Le memorie a ferrite² costavano troppo,
e comunque non erano disponibili.
(Ecco perché non avete mai sentito
di quella ditta, o di quel calcolatore.)

Ero stato assunto per scrivere
un 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
il suo stesso codice»,
chiedeva,
«può essere buono?»

Mel scrisse,
in esadecimale,
il programma più popolare
che la ditta possedeva.

Girava su LGP-30
e giocava a blackjack con i potenziali clienti
alle fiere di computer.
Il suo effetto era sempre teatrale.
Lo stand di LGP-30 era in ogni fiera,
e i venditori di IBM gli stavano attorno
parlando tra di loro.

Se abbiano realmente venduto qualche computer o no
è una questione che non abbiamo mai discusso.
Il lavoro di Mel era riscrivere
il programma blackjack per RPC-4000.
(Porting? Che significa?)

Il nuovo computer aveva uno schema
d’indirizzamento uno-più-uno,
in cui ogni istruzione macchina,
in aggiunta al codice operativo
e all’indirizzo dell’operando richiesto,
aveva un altro indirizzo che indicava dove,
sul tamburo rotante,
era collocata prossima istruzione.

Oggi diresti che
ogni singola istruzione era seguita da GO TO!
Mettetevi questo nella pipa di Pascal e fumatevelo.

Mel amava RPC-4000
perché poteva ottimizzare suo codice:
cioè, sistemare le istruzioni sul tamburo
così che appena una finiva il suo lavoro,
l’altra stava arrivando sotto la “testina”
ed era disponibile per l’esecuzione immediata.
C’era un programma per fare questo lavoro,
un “ottimizzatore assembler”,
ma Mel rifiutava di usarlo.

«Non sai mai dove va a mettere le cose»,
spiegava,
«così devi usare le costanti separate».

Solo molto tempo dopo ho capito questa osservazione.

Dato che Mel conosceva il valore numerico
di ogni istruzione operativa,
e assegnava loro gli indirizzi sul tamburo,
ogni istruzione che scriveva poteva essere vista
[anche] come costante numerica.

Poteva prendere la precedente istruzione di “somma”, per dire,
e moltiplicare per essa,
se aveva un 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 ripassato
dall’ottimizzatore assembler
e, sempre, quelli di Mel giravano più veloce.

Questo perché il metodo
di progettazione dei programmi
“top-down”
non era stato ancora inventato,
e comunque Mel
non lo avrebbe mai usato.

Scriveva per prima la parte interna
dei suoi cicli,
così che poteva scegliere
prima l’indirizzo migliore sul tamburo.

L’Ottimizzatore Assembler non era
abbastanza brillante per farlo in questo modo.

Mel non ha scritto mai un ciclo di attesa, mai,
persino quando la cocciuta Flexowriter³
richiedeva un ritardo tra i caratteri di output
per stamparli correttamente.

Egli semplicemente metteva le istruzioni sul tamburo
in modo che quella successiva aveva appena passato la testina
quando veniva chiamata;
così il tamburo doveva fare un altro giro completo
per trovare prossima istruzione.

Coniò un termine indimenticabile
per questa procedura.

Benchè “ottimo” sia un termine assoluto,
così come “unico”,
è diventata una prassi comune
di renderlo 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 l’inizializzatore è ottimizzato»,
diceva fieramente),
ricevette dal dipartimento vendite una
Richiesta di Cambiamento.

Il programma usava un elegante (e ottimizzato)
generatore di numeri casuali
per mischiare le “carte” e metterle sul “tavolo”,
ed alcuni del dipartimento vendite lo pensavano troppo onesto,
perché ogni tanto i clienti perdevano.

Volevano da Mel che cambiasse il programma
così, che azionando un interruttore sul pannello,
cambiasse comportamento
e lasciasse vincere il cliente.

Mel rifiutava.
Pensava che questo fosse palesemente disonesto,

e lo era,

e che questo violasse la sua integrità personale
come programmatore,

e la violava,

quindi rifiutò di farlo.

Il Capo Vendite parlò con Mel,
anche il Grande Capo e, su insistenza del capo,
alcuni Amici Programmatori.

Alla fine Mel cedette e scrisse il codice,
ma all’inverso,
e quando l’interruttore era nella posizione giusta,
il programma barava, vincendo ogni volta.

Mel era deliziato.
Sostenendo che suo subconscio
era incontrollabilmente etico,
rifiutò inflessibilmente di ripararlo.

Dopo che Mel lasciò la ditta
per pa$coli più verdi,
il Grande Capo mi chiese di rivedere il codice
e se potevo trovare il test e invertirlo.
Con qualche riluttanza accettai.

Attraversare codice di Mel fu vera avventura.

Ho spesso affermato che
la programmazione è una forma d’arte,
il cui reale valore può essere apprezzato solo
da un altro esperto in questa arte arcana;
ci sono incantevoli gemme
e mosse splendenti
nascoste allo sguardo e all’ammirazione umana,
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 misconosciuto.

Il mio choc più grande arrivò
quando trovai un ciclo innocente,
che non aveva alcun test dentro.

Nessun test. Niente.

Il senso comune dice che ciò
determina un loop infinito,
dove il programma gira per sempre,
senza fine.

Tuttavia, il programma passava
dritto attraverso questo ciclo,
e usciva in salvo dall’altro lato.

Mi ci sono volute due settimane
per scoprire come.

Il computer RPC-4000 aveva
una caratteristica veramente moderna
chiamata index register.

Permette al programmatore di scrivere un ciclo
che usa al proprio interno istruzioni indicizzate;
una volta dentro il ciclo, il valore di index register
era sommato con l’indirizzo di quella istruzione,
poteva così puntare
al prossimo dato della serie.

Si doveva solo incrementare l’index register,
ogni volta.

Mel non lo ha usato mai.

Invece, lui metteva l’istruzione
nel registro della macchina,
aggiungeva uno al suo indirizzo,
e la scriveva subito dietro.

Poteva eseguire l’istruzione modificata
direttamente dal registro.

Il ciclo era scritto in modo da prendere
in considerazione
il tempo di addizione:
appena l’istruzione finiva,
la prossima era sotto testina del tamburo,
pronta per uso.

Ma il ciclo non aveva nessun test dentro.

Notai l’indizio vitale quando capii che
l’index register bit,
il bit collocato tra indirizzo
e codice operazione nella istruzione,
era uno,
eppure Mel non usava mai index register,
lasciandolo a zero per tutto il tempo.

L’illuminazione era così forte da accecarmi.
Mel aveva messo i dati che elaborava
vicino alla fine dello spazio di memoria
(alle locazioni più alte
che le istruzioni potevano indirizzare)
così, quando l’ultimo dato era elaborato,
incrementando l’indirizzo dell’istruzione
andava in overflow⁴.

Il riporto aggiungeva uno al
codice dell’operazione,
cambiandola con la successiva
nella tabella delle istruzioni:
l’istruzione jump.

Bastava questo,
la prossima istruzione del programma era
sulla locazione zero,
e il programma felicemente
proseguiva su questa strada.

Non ho tenuto contatti con Mel,
quindi non so se abbia ceduto
al flusso di cambiamento
che ha ripulito le tecniche di programmazione
di quei giorni lontani.

Mi piace pensare che non l’abbia fatto.

In ogni caso,
ero così impressionato
che ho smesso di cercare
il test offensivo,
dicendo al Grande Capo
che non lo potevo trovare.

Non sembrò sorpreso.

Quando ho lasciato la ditta,
il programma blackjack barava ancora
quando giravate interruttore nel senso giusto,
e penso che fosse giusto così.

Non mi sentirei a mio agio
tagliando a pezzi il codice di un
Vero Programmatore.

postscriptum del 1992:

l’autore scrive:

L’autore ha aggiunto che la versione in ‘versi liberi’ gli piace più del suo originale in prosa …

Aggiornamenti

1999:

Cognome di Mel è adesso noto. Il manuale di LGP-30 riferisce che “Mel Kaye di Royal McBee che ha fatto la maggior parte della programmazione [...] del sistema ACT 1”.

2001:

Royal McBee LPG-30 ha un altro caso che ne accresce la fama. È emerso che il meteorologo Edward Lorenz faceva le simulazioni meteo su LGP-30 quando, nel 1961, scoprì il cosiddetto “Butterfly Effect” e il caos computazionale. Anche questo sembra, in qualche modo, appropriato.

2002:

La copia del manuale di programmazione per LGP-30 è disponibile ancora a questo indirizzo: http://ed-thelen.org/comp-hist/lgp-30-man.html

2011:

Dal 2011 “La storia di Mel” (Melvin Kaye) ha una pagina wikipedia.

Note