In ordine di astrazione framework, api stratificate, driver.
Macchine come C64 e Amiga avevano hardware praticamente immutabile, con 4 righe di codice potevi accedere ad esso pienamente, senza dipendere da un solo byte di codice scritto da terzi.
Volevi disegnare un cerchio? lo disegnavi pixel per pixel nella bitmap della memoria, accedendo direttamente ad essa calcolando le coordinate dei pixel con un algoritmo tuo.
Oggi useresti una funzione del framework, che dialoga con un api dell'OS, che a sua volta dialoga con l'api del driver.
E scriveresti una roba tipo "mywindow.drawcircle(x,y,r,color)" senza avere la più pallida idea di quale sia il modo efficiente per calcolare le coordinate del cerchio.
Certo, è comodo e ti astrae dall'hardware: fingiamo di avere una scheda che disegna cerchi in hardware, zac! , se il driver è furbo, usa tale funzione e tu senza saperlo hai un metodo velocissimo per disegnare cerchi. Ottimo dirai.
Ma quando fai il deploy di un programma (immaginario) che si basa sulla velocità di disegno dei cerchi, devi:
-accertarti che chi scarica il tuo programma abbia installato il framework (magari esattamente la versione che usi tu), che a sua volta ha le sue dipendenze.
-accertarti che utilizzi un driver aggiornato che sfrutti l'eventuale accelerazione hardware della scheda
-pregare che le schede video che non hanno tale accelerazione siano comunque abbastanza veloci (quindi testare decine di combinazioni di configurazioni e stabilire caratteristiche minime/ottimali).
In pratica vengono introdotte tutta una serie di problematiche con l'aggravante che ogni step che ho riportato potrebbe avere bug (che non dipendono affatto da te) che magari capitano solo in alcune configurazioni e che sono tanto più probabili quanto è lungo questo processo di astrazione.
Le poche righe assembly sui vecchi computer invece, continuano e continueranno a girare perfettamente senza dipendere da nulla e nessuno, finché l'hardware non si guasterà.