Cosa intendeva Bill Gosper dicendo che una struttura di dati è solo uno stupido linguaggio di programmazione? [chiuso]

C'è una citazione di Ralph William Gosper, Jr che dice:

Una struttura di dati è solo uno stupido linguaggio di programmazione.

Cosa voleva dire con questo? Purtroppo, tutto ciò che posso trovare su Google a riguardo è la copia / incessante copia della citazione stessa, senza alcun contesto.

Bene, sembra che il cuore della frase sia:

Una struttura di dati è solo un ... linguaggio di programmazione

Il che è abbastanza vero se ci pensi. Dopotutto, i compilatori si affidano sempre a questa transitività; prendono un linguaggio di programmazione, lo convertono in una struttura di dati, fanno alcune trasformazioni su quei dati e poi trasformano il risultato in un altro linguaggio di programmazione.

In effetti, se lo volessi, potresti persino far impazzire qualcosa come una struttura di dati C, che ti consente di scrivere il codice C chiamando i suoi vari metodi - ad esempio (in genere C #, perché è quello che sto usando in questo momento):

var C = new HorribleCObject ();
C.Function <int> ("main", typeof (char [] []), typeof (int))
  .Variable ("i", typeof (int), 0)
  .While ("i", Func (i) => i <10))
     .Call ("printf", "% d", "i")
     .PostIncrement ( "i")
  .EndWhile ();
  .Return (0)
 .EndFunction ();

Ora, per quanto riguarda la citazione completa: perché qualcosa del genere dovrebbe essere stupido rispetto a (diciamo) scrivere in C stesso? Dovrebbe essere abbastanza ovvio che questo è dettagliato e non così leggibile come il suo equivalente in C (e, in pratica, potrebbe non supportare l'intera portata di ciò che C può fare - i typedef sarebbero difficili); quindi, questa struttura di dati è solo uno "stupido" linguaggio di programmazione, incorporato in un "vero" linguaggio di programmazione. Quella stessa logica può essere generalizzata a qualsiasi struttura di dati ti venga in mente; le liste collegate sono solo una versione "stupida" di Lisp, e le mappe hash sono solo una versione "stupida" di alcuni teorici Hash Programming Language (Hasp?).

Il fatto è, tuttavia, che non vogliamo sempre scrivere Hasp per interagire con le nostre mappe hash. È il problema che hanno tutte le lingue specifiche del dominio : da un lato, un DSL ben implementato è abbastanza potente da esprimere tutto ciò che il modello sottostante può fare; d'altra parte, devi implementare il DSL in primo luogo, e poi altre persone devono impararlo. Ciò richiede tempo e sforzi che probabilmente non vogliono spendere; dopo tutto, voglio solo mettere le cose nella mia mappa hash e poi controllare che ci siano altre cose lì dentro, non voglio imparare tutte le complessità della programmazione orientata all'hash.

Quindi, praticamente senza pensarci, prendiamo questi linguaggi di programmazione teorici altamente specifici e molto intelligenti e li distilliamo nelle poche, stupide operazioni incorporate in una struttura di dati. Un elenco collegato ha una piccola raccolta di metodi semplici; una mappa hash ne ha altre. Ignoriamo le altre operazioni più potenti che potresti potenzialmente eseguire sulla struttura dei dati (la maggior parte delle implementazioni di LinkedList non hanno una funzione .Map o .ForEach, per esempio, e non riesco nemmeno a immaginare cosa faresti in Hasp), a favore di implementarli esplicitamente nel linguaggio di programmazione principale, che è ciò con cui la maggior parte dei programmatori avrà familiarità.

Le strutture di dati sono essenzialmente una stupida estensione della loro lingua madre nello spazio problematico che rappresentano concettualmente. Un'estensione sufficientemente intelligente richiederebbe un nuovo linguaggio di programmazione specifico e la maggior parte delle persone non vorrà impararlo.

Una struttura di dati è una RAPPRESENTAZIONE di un linguaggio di programmazione. Ma non particolarmente "acuto".

Questo può essere visto da un "diagramma dei nodi" come quello nell'articolo wiki di seguito:

http://en.wikipedia.org/wiki/Root_node#Terminology

Tuttavia, una struttura di dati è INCOMPLETA come linguaggio di programmazione, perché manca di sintassi e pensieri completi che sarebbero comprensibili per un programmatore. Il "linguaggio" di una struttura di dati potrebbe essere paragonato a un bambino che ha detto qualcosa del tipo: "Io, freddo. Ottieni cappotto".

Il "linguaggio" è fratturato, ma può essere compreso. Il bambino sta dicendo che "ha freddo, e vorrebbe più vestiti come copertura". L'enunciato del bambino è una versione "stupida" della lingua inglese, e allo stesso modo la struttura dei dati in relazione a un linguaggio di programmazione.

Credo che ciò che Bill Gosper intendesse sia che tutte le strutture di dati sono solo costrutti di programmazione con applicabilità limitata . Ciò è anche legato all'idea che "il design del linguaggio è il design delle biblioteche e il design delle biblioteche è il design del linguaggio" [1].

Un modo di pensare al problema è quello di considerare le strutture di dati solo su una base algoritmica. Dimentica i requisiti di archiviazione o digita le annotazioni per il momento perché sono semplicemente accessorie.

Ad esempio, è possibile codificare un array associativo (chiamato a mapin alcune lingue) in due modi: utilizzando un qualche tipo di indice archiviato in memoria o usando una semplice espressione maiuscola.

In Haskell potresti codificare un array associativo come una struttura di dati ...

let assocArray = [("a", 1),("b", 2),("c", 3)]
let key = "b"
lookup key assocArray

... o usando un'espressione case ...

let key = "b"
case key of 
  "a" -> 1
  "b" -> 2
  "c" -> 3

... o ancora più direttamente ...

let key = "b"
if key == "a" 
  then 1 
  else if key == "b"
    then 2
    else if key == "c"
      then 3
      else undefined

È facile capire che questo tipo di mirroring tra strutture dati e codice è possibile osservando il calcolo lambda. Qualsiasi valore può essere rappresentato da una funzione nel calcolo lambda e il calcolo stesso è universale (turing completo).

[1] La citazione è grazie a Bjarne Stroustrup.

Considera Javascript, dove tutti i dati sono codice. Considera LISP, dove tutti i dati sono codici e tutti i codici sono dati.

All'inizio, alla fine e ovunque nel mezzo, i dati sono solo bit. Il fatto che cerchiamo di ontologizzare i bit con testo e simboli per renderli facilmente leggibili e trasformabili dall'uomo è uno strato di astrazione che richiede a) impari il linguaggio di definizione eb) impari la perdita dell'astrazione.

Ad esempio, in C #, l'apprendimento della differenza tra una struttura e una classe richiede di apprendere la differenza nel confronto di uguaglianza tra tipi di valore e tipi di riferimento. Ogni ontologia dei dati richiede un proprio insieme di regole che è necessario apprendere e rispettare. E, come qualsiasi lingua, ti consente di arrivare rapidamente all'idea generale, ma più ti avvicini alla verità effettiva della questione, più dovresti guardare tu stesso al binario.

Infine, quando si considera un albero B o una struttura di dati simile, navigare nella struttura dell'albero ed eseguire altri tipi di operazioni su di esso richiede un tipo specializzato di sintassi che non è necessariamente trasferibile attraverso alberi, strutture o lingue.