La storia di Mel

Era postato su Usenet dal autore, Ed Nather (), 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]