Entombed è un gioco per Atari 2600 che nessuno sa come è stato programmato

Già, ma c'è una scarsa cultura dell'ottimizzazione perché ormai abbiamo valanghe di risorse a disposizioni, e... le si usa.

Anche perché non ti puoi più permettere di scrivere codice assembly (o addirittura in linguaggio macchina, quando ho iniziato), perché la produttività è scandalosamente bassa.

No, non è una questione di bravura, ma di adattamento alle esigenze dell'epoca.

Quando hai poche risorse a disposizione o ti sbatti o sei fuori (Briatore dixit).

Adesso ne hai a vagonate, e quindi l'ottimizzazione è l'ultimo dei tuoi problemi, anche perché ci sono le scadenze impellenti e soffocanti.

Sono due epoche completamente diverse, insomma, e gli sviluppatori si sono semplicemente adattati.

"E' l'ambiente che fa l'uomo" (cit.)

I giochi all'epoca in questione si programmavano per lo più in linguaggio macchina e non in assembly. Quindi ti armavi di opcode table del processore (anche se alla fine la maggior parte li conoscevi a memoria), e ti facevi a mente i calcoli dell'offset per i salti "brevi".

Gli assembler, se c'erano, erano roba da elite.

Non è certo la stessa cosa: i sorgenti assembly usavano label descrittive ed erano strapieni di commenti, anche un commento per riga per spiegare quello che si stava facendo.

Un conto è controllare il tuo stesso codice (che anche se disassemblato rimane "riconoscibile", e tutt'altra cosa prendere un binario sconosciuto, disassemblarlo, e cercare di capire cosa sta facendo il codice.

*

*

Io, invece, realizzai un disassemblatore / resourcer (si chiamavano così i programmi che generavano sorgenti assembly dal disassemblamento dei binari) proprio per il reverse engineering di quel gioco di poker in voga all'epoca (quello di CMC, col famoso "poker jollato" ).
Era basato su processore 65C02 e coprocessore grafico Motorola (non ricordo la sigla al momento), e il committente mi aveva fornito pure un paio di schede madri (una con tutti i componenti dissaldati per ricostruire lo schema del PCB e capire dove andavano i segnali e cosa facevano). Realizzai anche un mio assemblatore basato su un mio linguaggio assembly di alto livello, per rendere più facile la scrittura di codice assembly.
Un lavoro immane, insomma, che oggi con Python avrei realizzato in meno di decimo del tempo...

E pure io ho problemi a rivedere il codice che avevo scritto, pur spesso commentato, per capire cosa diavolo facevano certe parti...

Non è certo cosa facile: acquisire quella mentalità richiede parecchio tempo (e ovviamente una buona dose di creatività che non tutti possiedono).

Prendendo Arduino, qualche anno fa ho realizzato un progetto (inizialmente giusto per smanettare con qualcosa di nuovo. Poi è divenuto qualcosa di ben più serio) per il monitoraggio di certi dati, sfruttando la tecnologia LoRA / LoraWAN quale rete wireless a basso consumo per l'invio dei pacchetti.

Ebbene, usando la libreria standard di TheThingsNetwork (TTN) per LoRA il firmware occupava un sacco di spazio (usando uno schifoso Atmel AVR da due soldi con 28KB di Flash e appena 2,5KB di RAM), e non funzionava nemmeno bene. In particolare mi andava in blocco tutto con l'uso della funzionalità di adattamento automatico dello Spread Factor / Data Rate. Roba che mi ha fatto impazzire, e ho provato di tutto per farlo andare (compresi trucchetti sporchi. "Cose per cui il Dio della biomeccanica non mi farebbe entrare in paradiso".
Alla fine ho scaricato il manuale delle specifiche del chip LoRA (RN2483) e mi sono scritto da zero (in C) l'intero stack LoRa in un paio di settimane, implementando tutti comandi del chip, e creando una test suite di circa 200 test (se confronti i test del codice TTN sono semplicemente ridicoli: un paio che devi eseguire sulla scheda Arduino. Io ho ho scritto parzialmente un emulatore Arduino e i miei 200 test li eseguo da Visual Studio con le sue funzionalità di test).
Adesso funziona tutto alla perfezione (e il tutto vuol dire che dentro ci sta un parser ASCII per i sensori che usano questo formato, e uno SML/binario per gli altri. Più tutta la business logic necessaria, e una varietà di comandi per controllare lo stato della scheda), e tutto il firmware occupa circa l'80% dello spazio e dovrei avere anche più di 1KB di RAM libera.
Certo, c'è da dire che mi sono riscritto praticamente tutto (non uso nemmeno la classe String di Arduino né malloc/free varie, e mi sono scritto pure delle funzioni per il calcolo in fixed point), ma ne è valsa la pena.
D'altra parte son cose necessarie quando si lavora in ambito embedded: risparmiare anche un solo euro sui componenti può portare a risparmi (o guadagni, se sei tu a vendere le schede) notevoli, che compensano di gran lunga le settimane di lavoro di un programmatore.