Una nota che dovremmo appenderci sul muro, secondo me, è che
per fare ottimizzazione (se volete, per rendere un'applicazione veloce,
scalabile e poco assetata di risorse) è fondamentale conoscere in
profondità il sistema con il quale abbiamo a che fare.
In fin dei conti una buona percentuale del software
che scriviamo richiama, in via diretta o indiretta, una API del sistema
operativo.
Se apriamo il Task Manager e osserviamo il tempo che il
nostro programma trascorre in modalità kernel, ci possiamo
rendere conto che avvengono tante (ma tante !) cose sotto il nostro naso.
Capire che cosa succede, al di là dell'interesse didattico o della
curiosità, è un buon punto di partenza per capire come mai non funziona
!
Questo non vuole essere un argomento contro i "framework"
che nascondono il vero funzionamento di un sistema.
Innanzitutto perchè lo scopo non è mai quello di nascondere
la realtà. Non dovrebbe, per lo meno !
Secondariamente
perchè un ambiente di esecuzione porta con sè una serie
di servizi, a volte imprescindibili.
Si può discutere se il meccanismo di garbage
collection sia rivolto esclusivamente a ridurre il plumbing o comporti anche
miglioramenti prestazionali. Ma credo che questioni come type-safety e sicurezza
del codice non si possano certo catalogare come "semplificazione per
astrazione".
Il punto è che, man mano che il livello di astrazione si
alza, le fondamenta su cui costruiamo sono sempre più distanti dal terreno,
che in fin dei conti è fatto da tante centinaia di migliaia di transistor (o
addirittura, se vogliamo, dalle leggi della fisica dello stato
solido).
Quando il nostro giovane programmatore scriveva listati in
Assembler, a parte il mal di stomaco che si portava a casa, aveva un controllo
molto maggiore sulla macchina.
O meglio, molto più esplicito.
Oggi quel controllo si esprime sotto forma di estrema
comprensione dei meccanismi del sistema e dell'interfaccia che abbiamo a
disposizione per controllarli.