Forum libero

[edizione: TraduzioniMerda™ 2001]

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”.