Was meinte Bill Gosper damit, dass eine Datenstruktur nur eine blöde Programmiersprache ist? [geschlossen]

Es gibt ein Zitat von Ralph William Gosper, Jr. , das besagt:

Eine Datenstruktur ist nur eine blöde Programmiersprache.

Was meinte er damit? Leider kann ich in Google nur unerbittliche Kopien / Pasten des Zitats selbst finden, ohne jeglichen Kontext.

Nun, es scheint, als wäre der Kern der Aussage:

Eine Datenstruktur ist nur eine ... Programmiersprache

Was ganz richtig ist, wenn Sie darüber nachdenken. Immerhin verlassen sich Compiler die ganze Zeit auf diese Transitivität. Sie nehmen eine Programmiersprache, konvertieren sie in eine Datenstruktur, wandeln diese Daten um und wandeln das Ergebnis in eine andere Programmiersprache um.

Wenn Sie möchten, können Sie sogar etwas Verrücktes wie eine C-Datenstruktur erzeugen, mit der Sie C-Code schreiben können, indem Sie die verschiedenen Methoden aufrufen.

var C = neues HorribleCObject ();
C.Funktion <int> ("main", typeof (char [] []), typeof (int))
  .Variable ("i", typeof (int), 0)
  .Während ("i", Func (i) => i <10))
     .Call ("printf", "% d", "i")
     .PostIncrement ("i")
  .EndWhile ();
  .Retoure (0)
 .EndFunction ();

Nun zum vollständigen Zitat: Warum wäre so etwas dumm im Vergleich zum Schreiben in C selbst? Es sollte ziemlich offensichtlich sein, dass dies ausführlich und nicht annähernd so gut lesbar ist wie das Äquivalent in C (und in der Praxis möglicherweise nicht den vollen Umfang dessen unterstützt, was C kann - typedefs wären schwierig). daher ist diese Datenstruktur nur eine "dumme" Programmiersprache, eingebettet in eine "echte" Programmiersprache. Dieselbe Logik kann auf jede denkbare Datenstruktur verallgemeinert werden. verknüpfte Listen sind nur eine "blöde" Version von Lisp, und Hash-Maps sind nur eine "blöde" Version einer theoretischen Hash-Programmiersprache (Hasp?).

Die Sache ist jedoch, dass wir nicht immer Hasp schreiben möchten, um mit unseren Hash-Maps zu interagieren. Dies ist das Problem, das alle domänenspezifischen Sprachen haben. Einerseits ist eine gut implementierte DSL leistungsfähig genug, um alles auszudrücken, was das zugrunde liegende Modell kann. Auf der anderen Seite muss man das DSL zuerst implementieren und dann müssen andere Leute es lernen. Das kostet Zeit und Mühe, die sie wahrscheinlich nicht ausgeben wollen. Schließlich möchte ich nur Dinge in meine Hash-Map einfügen und dann prüfen, ob andere Dinge darin enthalten sind. Ich möchte nicht alle Feinheiten der Hash-orientierten Programmierung kennenlernen.

Ziemlich ohne darüber nachzudenken, nehmen wir diese theoretischen hochspezifischen und sehr intelligenten Programmiersprachen und destillieren sie auf die wenigen, dummen Operationen herunter, die in einer Datenstruktur enthalten sind. Eine verknüpfte Liste enthält eine kleine Sammlung einfacher Methoden. Eine Hash-Map hat einige andere. Wir ignorieren die anderen, leistungsstärkeren Operationen, die Sie möglicherweise über die Datenstruktur ausführen könnten (die meisten LinkedList-Implementierungen haben beispielsweise keine .Map- oder .ForEach-Funktion, und ich kann mir nicht einmal vorstellen, was Sie in Hasp tun würden). zugunsten einer expliziten Implementierung in der übergeordneten Programmiersprache - mit der die meisten Programmierer vertraut sein werden.

Datenstrukturen sind im Wesentlichen eine blöde Erweiterung ihrer übergeordneten Sprache in den Problemraum, den sie konzeptionell darstellen. Eine ausreichend intelligente Erweiterung würde eine neue, spezifische Programmiersprache erfordern, und die meisten Leute werden das nicht lernen wollen.

Eine Datenstruktur ist eine Repräsentation einer Programmiersprache. Aber kein besonders "scharfer".

Dies kann aus einem "Knotendiagramm" wie dem im folgenden Wiki-Artikel ersehen werden:

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

Nichtsdestotrotz ist eine Datenstruktur als Programmiersprache UNVOLLSTÄNDIG, da es an Syntax und vollständigen Gedanken mangelt, die für einen Programmierer verständlich wären. Die "Sprache" einer Datenstruktur könnte mit einem Kind verglichen werden, das so etwas wie "Ich, Erkältung. Mantel holen" sagte.

Die "Sprache" ist gebrochen, aber verständlich. Das Kind sagt, dass es kalt ist und mehr Kleidung als Decke haben möchte. Die Äußerung des Kindes ist eine "dumme" Version der englischen Sprache und ebenso Datenstruktur in Bezug auf eine Programmiersprache.

Ich glaube, dass Bill Gosper beabsichtigt hat, dass alle Datenstrukturen nur Programmkonstrukte mit begrenzter Anwendbarkeit sind . Dies hängt auch mit der Idee zusammen, dass "Sprachdesign Bibliotheksdesign und Bibliotheksdesign Sprachdesign ist" [1].

Eine Möglichkeit, über das Problem nachzudenken, besteht darin, Datenstrukturen lediglich auf algorithmischer Basis zu betrachten. Vergessen Sie vorerst die Speicheranforderungen oder Typanmerkungen, da diese einfach nur eine Nebensache sind.

Sie können beispielsweise ein assoziatives Array ( mapin einigen Sprachen als "a" bezeichnet) auf zwei Arten kodieren: Entweder mithilfe eines im Speicher abgelegten Index oder mithilfe eines einfachen case-Ausdrucks.

In Haskell könnten Sie ein assoziatives Array als Datenstruktur codieren ...

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

... oder mit einem case Ausdruck ...

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

... oder noch direkter ...

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

Es ist leicht einzusehen, dass diese Art der Spiegelung zwischen Datenstrukturen und Code möglich ist, wenn man sich die Lambda-Rechnung ansieht. Jeder Wert kann durch eine Funktion im Lambda-Kalkül dargestellt werden, und der Kalkül selbst ist universell (vollständig).

[1] Das Zitat ist Bjarne Stroustrup zu verdanken.

Betrachten Sie Javascript, wo alle Daten Code sind. Betrachten Sie LISP, bei dem alle Daten Code und alle Codes Daten sind.

Am Anfang, am Ende und überall dazwischen sind Daten nur Bits. Dass wir versuchen, Bits mit Text und Symbolen zu ontologisieren, um sie für den Menschen leicht lesbar und umwandelbar zu machen, ist eine Abstraktionsschicht, die Folgendes erfordert: a) Sie lernen die Definitionssprache und b) Sie lernen die Undichtigkeit der Abstraktion.

Wenn Sie beispielsweise in C # den Unterschied zwischen einer Struktur und einer Klasse lernen möchten, müssen Sie den Unterschied beim Gleichheitsvergleich zwischen Werttypen und Referenztypen kennen. Für jede Datenontologie sind eigene Regeln erforderlich, die Sie erlernen und befolgen müssen. Und wie in jeder Sprache können Sie damit schnell zur allgemeinen Idee gelangen. Je näher Sie jedoch an die tatsächliche Wahrheit der Sache herangehen möchten, desto mehr sollten Sie sich selbst mit der Binärdatei befassen.

Wenn man schließlich einen B-Baum oder eine ähnliche Datenstruktur betrachtet, erfordert das Navigieren in der Struktur des Baums und das Ausführen anderer Arten von Operationen eine spezielle Art von Syntax, die nicht unbedingt über Bäume, Strukturen oder Sprachen hinweg übertragbar ist.