Il codice e i dati devono essere trattati separatamente?

No, non è assolutamente necessario. L'architettura di Van Neumann, sulla quale si basano praticamente tutti i computer di oggi, è stata pioniera dell'idea di un programma memorizzato , che non è altro che un codice memorizzato come dati.

Tuttavia è a livello di hardware; a livello di software, i paradigmi differiscono da quanto strettamente i dati e il codice sono mescolati (o, al contrario, quanto devono essere nettamente divisi).

A un'estremità dello spettro c'è una programmazione imperativa, in particolare i gusti procedurali: pensa Pascal, C, FORTRAN, BASIC (BASIC attuale, non VB.NET o qualcosa del genere). In questi linguaggi, i dati e il codice sono concettualmente separati; puoi prendere i puntatori per gestire gli indirizzi e passarli in giro, ma a parte questo, il codice è codice e i dati sono dati. Se si desidera trattare i dati come codice, è necessario eseguire alcuni trucchi, ad es. iniettando un codice assembler per passare a un indirizzo che contiene i tuoi dati.

Dall'altra parte, troverai la programmazione funzionale, dove le funzioni sono (in un linguaggio FP super-hardcore, le funzioni sono anche il tipo di solo Puoi avere); ma anche programmazione logica (si pensi a Prolog), in cui l'intero programma è per lo più solo una struttura di dati che descrive fatti sul dominio del problema. E naturalmente c'è il campo dinamico, che ti offre tecniche come patch per scimmia, digitazione di anatre, introspezione / riflessione, ecc. Per fare in modo che il tuo codice venga ispezionato e modificato in tempo reale. Lisp (qualsiasi Lisp, davvero) è un candidato particolarmente interessante qui, perché combina la programmazione funzionale e le funzionalità dinamiche.

Nel mezzo, c'è la programmazione orientata agli oggetti; questo idioma eredita principalmente la mentalità imperativa di dati e codice separati, ma al suo interno, si allontana un po 'dal raggruppamento del comportamento (codice) e dello stato (dati) correlati in unità (oggetti). Avanzando rapidamente fino al punto in cui l'idioma si è completamente svelato, e si vedono emergere "modelli di progettazione", molti dei quali praticamente replicano le funzionalità di codice-come-dati trovate in altri idiomi.

Tutto ciò che in realtà non risponde alla tua domanda: dovrebbe codice e dati essere separati? Bene, il fatto che anche i più maturi separatori di codice-dati utilizzino occasionalmente generatori di codice, tabelle di ricerca e tecniche simili che li mescolano dovrebbero dirvi che essere religiosi riguardo a tale separazione è ridicolo. Ci sono alcuni vantaggi nel trattarli come regni separati, e spesso è l'approccio più diretto. Spesso, ma non sempre. In molti casi, lasciare la separazione può portare a un codice più pulito, meno cruft e soluzioni più eleganti.

Prendi questo esempio:

interface Fooable {
    function  run();
}

function foo(Fooable f) {
    f.run();
}

// ...

myF = new Fooable() { function run() { print "Hello, world!"; } }
foo(myF);

vs:.

function foo(f) {
    f();
}

myF = function () { print "Hello, world!"; }
foo(myF);

In ogni caso, ritengo importante tenere a mente che una separazione di codice e dati è solo un modo per affrontare un problema, e che a livello di macchina, la distinzione è discutibile nel migliore dei casi.

Nei dialetti Lisp, il codice e i dati sono entrambi rappresentati come elenchi e ciò facilita la manipolazione del codice come dati, perché si tratta di dati. Ma è anche utile tenere a mente la distinzione: se si tenta di eseguire una lista che non è un codice, si otterrà un errore, piuttosto che un output utile. A volte è più utile considerarli come la stessa cosa, a volte è più utile pensarli come diversi.

Ad esempio, un elenco di numeri interi da 1 a 5 dovrebbe apparire come questo in Lisp: (1 2 3 4 5) . Se si tenta di eseguirlo, si riceverà un errore che si lamenta che il numero 1 non è una funzione. Potresti pensare a quella lista come a un pezzo di codice spezzato, ma sarebbe più utile pensarla come dati, non come codice. Se hai scritto (+ 2 3 4 5) , allora questo è un richiamo di funzione della funzione '+' sugli argomenti 2, 3, 4 e 5. Se lo hai scritto in questo modo '(+ 2 3 4 5) (nota la citazione singola in primo piano), quindi sarebbe un pezzo di codice trattato come dati, e non sarebbe stato ancora eseguito (sebbene potessi eseguirlo in seguito).

Il vero problema che deve essere considerato è "l'integrità dei dati". Codice segregazione & i dati lasciano ancora uno aperto ai dati corrotti tramite sovraccarichi del buffer.

Segregating code & i dati sono una soluzione all'estremità di uno spettro e molto appropriati per le lingue (come C) che consentono modifiche indiscriminate ai dati (e, per estensione, al codice se non segregati dai dati). È una soluzione estrema e necessaria a un problema fondamentale in tali lingue. Si noti che non sto suggerendo in alcun modo che C sia difettoso: è stato progettato con una funzionalità del genere per il lavoro di "basso livello" per il quale è stato concepito. È stato originariamente progettato per essere a metà strada tra il linguaggio assembly e "linguaggi di alto livello".

Sì. La corretta separazione del codice e dei dati è molto importante.

Il codice è scritto in anticipo ed eseguito, generalmente con un livello di fiducia piuttosto elevato. I dati provengono da fonti esterne e non necessariamente da una fonte che dovrebbe essere attendibile. E il più distruttivo degli hack (come i buffer overflow e le iniezioni SQL) proviene da un utente inaffidabile che trova un modo per far sì che il computer tratti i dati come codice.

Alcuni linguaggi di programmazione, per lo più quelli influenzati da Lisp, come notato da World Engineer, amano confondere i due. Questo è quasi come il progettista di linguaggi che dice "qui, non è necessario scrivere i propri buchi di sicurezza, ti abbiamo dato un gratuito vulnerabilità di esecuzione di codice arbitrario come caratteristica fondamentale della lingua! "