Ai - per fortuna - pochi che hanno avuto il piacere di conoscere il più eclatante assemblerista ad oggetti della storia, posso ora dire con certezza che "l'assembler ad oggetti" (inteso come metodologia di sviluppo) non esiste. Sono giunto a questa conclusione dopo il refactoring del firmware di un device embedded, che mi ha procurato notti quasi insonni, e pochi momenti di sonno disturbati da un incubo ricorrente (una voce cavernosa che dal profondo di una gola oscura urlava "perchè iooooo....").
Strutturare un software poco più che banale in linguaggio macchina richiede capacità di concentrazione talmente elevate che risulta un compito praticamente impossibile a qualunque umano (solo un compilatore può farcela); è troppo difficile non introdurre bachi assurdi e indebuggabili in migliaia di linee di codice pseudo-organizzato, privo di controlli semantici, privo di vincoli strutturali... ogni tentativo di introdurre struttura (documentata peraltro a piu' non posso, con mooolte più linee di commenti che di istruzioni) introduce una probabilità in più di bachi. Fare binding dinamico in assembly è troppo error-prone, e al di fuori di qualche piccolo esperimentuccio, diventa impossibile riuscire sia a strutturare il software che renderlo efficiente (per efficiente intendo: terribilmente efficiente, sfruttando fino all'ultimo le risorse modeste dell'hardware).
L'uso indiscriminatamente ottimizzato dei registri (solo 16) su un processore RISC che sembra morire ad ogni accesso in memoria, il windowing virtuale (3 finestre da 4 registri) implementato per la chiamata ricorsiva (dalla 4 ricorsione in poi, i registri vengono dumpati sullo stack)... no, è troppo. L'assembly è fatto per programmarci in assembly, poi c'e' il C++. E quando si esce dal mondo embedded ci sono i vari Java e C#.
L'assembly ad oggetti è morto.
Lunga vita all'assember ad oggetti, e ai gloriosi pionieri dell'informatica.
Nessun commento:
Posta un commento