¿Qué quiso decir Bill Gosper al decir que una estructura de datos es solo un estúpido lenguaje de programación? [cerrado]

Hay una cita de Ralph William Gosper, Jr que dice:

Una estructura de datos es solo un estúpido lenguaje de programación.

¿Qué quiso decir con esto? Por desgracia, todo lo que puedo encontrar en Google al respecto son incesantes copias / pastas de la cita en sí, sin ningún contexto.

Bueno, parece que el corazón de la declaración es:

Una estructura de datos es solo un ... lenguaje de programación

Lo cual es bastante cierto si lo piensas. Después de todo, los compiladores confían en esta transitividad todo el tiempo; toman un lenguaje de programación, lo convierten en una estructura de datos, hacen algunas transformaciones en esos datos y luego convierten el resultado en otro lenguaje de programación.

De hecho, si quisieras, incluso podrías hacer algo loco como una estructura de datos C, que te permite escribir código C llamando a sus diversos métodos, por ejemplo (en C #, porque eso es lo que estoy usando ahora):

var C = new HorribleCObject ();
C.Función <int> ("main", typeof (char [] []), typeof (int))
  .Variable ("i", typeof (int), 0)
  .Mientras que ("i", Func (i) => i <10))
     .Call ("printf", "% d", "i")
     .PostIncrement ("i")
  .EndWhile ();
  .Volver (0)
 .FinFunción ();

Ahora, en cuanto a la cita completa: ¿por qué algo así sería estúpido en comparación con (digamos) escribir en C? Debería ser bastante obvio que esto es detallado y no tan legible como su equivalente en C (y, en la práctica, podría no ser compatible con todo el alcance de lo que C puede hacer; typedefs sería complicado); por lo tanto, esta estructura de datos es solo un lenguaje de programación "estúpido", incrustado en un lenguaje de programación "real". Esa misma lógica se puede generalizar a cualquier estructura de datos que se te ocurra; las listas enlazadas son solo una versión "estúpida" de Lisp, y los mapas hash son solo una versión "estúpida" de algún lenguaje teórico de programación Hash (¿Hasp?).

Sin embargo, la cuestión es que no siempre queremos escribir Hasp para interactuar con nuestros mapas hash. Es el problema que tienen todos los lenguajes específicos de dominio : por un lado, un DSL bien implementado es lo suficientemente potente como para expresar todo lo que el modelo subyacente puede hacer; por otro lado, debes implementar el DSL en primer lugar, y luego otras personas tienen que aprenderlo. Eso lleva tiempo y esfuerzo que probablemente no quieran gastar; después de todo, solo quiero poner cosas en mi mapa hash y luego verificar que hay otras cosas allí, no quiero aprender todas las complejidades de la programación orientada a Hash.

Entonces, casi sin pensarlo, tomamos estos lenguajes de programación teóricos altamente específicos y muy inteligentes y los resumimos en las pocas y estúpidas operaciones incorporadas en una estructura de datos. Una lista vinculada tiene una pequeña colección de métodos simples; un mapa hash tiene algunos otros. Ignoramos las otras operaciones más potentes que podría realizar sobre la estructura de datos (la mayoría de las implementaciones de LinkedList no tienen una función .Map o .ForEach, por ejemplo, y ni siquiera puedo imaginar lo que haría en Hasp), a favor de implementarlos explícitamente en el lenguaje de programación principal, que es con lo que la mayoría de los programadores estarán familiarizados.

Las estructuras de datos son, esencialmente, una estúpida extensión de su idioma principal en el espacio del problema que representan conceptualmente. Una extensión lo suficientemente inteligente requeriría un lenguaje de programación nuevo y específico, y la mayoría de las personas no querrán aprender eso.

Una estructura de datos es una REPRESENTACIÓN de un lenguaje de programación. Pero no uno particularmente "agudo".

Esto se puede ver en un "diagrama de nodos" como el del artículo wiki a continuación:

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

Sin embargo, una estructura de datos es INCOMPLETA como lenguaje de programación, porque carece de sintaxis y pensamientos completos que serían inteligibles para un programador. El "lenguaje" de una estructura de datos podría compararse con un niño que dijo algo como "yo, frío. Ponte el abrigo".

El "lenguaje" está fracturado, pero se puede entender. El niño dice que "él / ella tiene frío y le gustaría tener más ropa para cubrirse". El enunciado del niño es una versión "estúpida" del idioma inglés, y también la estructura de datos en relación con un lenguaje de programación.

Creo que lo que Bill Gosper pretendía es que todas las estructuras de datos son solo construcciones de programación con aplicabilidad limitada . Esto también está relacionado con la idea de que "el diseño del lenguaje es el diseño de la biblioteca y el diseño de la biblioteca es el diseño del lenguaje" [1].

Una forma de pensar sobre el tema es considerar las estructuras de datos simplemente sobre una base algorítmica. Olvídate de los requisitos de almacenamiento o escribe anotaciones por el momento porque son simplemente auxiliares.

Por ejemplo, podría codificar una matriz asociativa (llamada a mapen algunos idiomas) de dos maneras: mediante el uso de algún tipo de índice almacenado en la memoria o mediante una simple expresión de caso.

En Haskell, podría codificar una matriz asociativa como una estructura de datos ...

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

... o usando una expresión de caso ...

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

... o incluso más directamente ...

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

Es fácil ver que este tipo de reflejo entre las estructuras de datos y el código es posible al observar el cálculo lambda. Cualquier valor puede ser representado por una función en el cálculo lambda y el cálculo en sí es universal (turing completo).

[1] La cita es gracias a Bjarne Stroustrup.

Considere Javascript, donde todos los datos son código. Considere LISP, donde todos los datos son código y todos los códigos son datos.

Al principio, al final y en todas partes, los datos son solo bits. Que intentemos ontologizar bits con texto y símbolos para que sean fácilmente legibles y transformables por los humanos es una capa de abstracción que requiere a) Aprender el lenguaje de definición yb) aprender la filtración de la abstracción.

Por ejemplo, en C #, aprender la diferencia entre una estructura y una clase requiere que aprenda la diferencia en la comparación de igualdad entre tipos de valor y tipos de referencia. Cada ontología de datos requiere su propio conjunto de reglas que debe aprender y cumplir. Y, como cualquier lenguaje, le permite llegar rápidamente a la idea general, pero cuanto más cerca desee acercarse a la verdad real del asunto, más debe mirar el binario usted mismo.

Finalmente, cuando se considera un árbol B o una estructura de datos similar, navegar por la estructura del árbol y realizar otros tipos de operaciones en él requiere un tipo especializado de sintaxis que no es necesariamente transferible a través de árboles, estructuras o lenguajes.