terminology - ¿Qué significa "Los datos son solo código tonto, y el código solo son datos inteligentes"?
sicp (5)
Acabo de encontrar una idea en La estructura e interpretación de los programas de computadora :
Los datos son solo códigos tontos, y los códigos son solo datos inteligentes.
No logro entender lo que significa. ¿Puede alguien ayudarme a entenderlo mejor?
El código es definitivamente datos, pero los datos definitivamente no siempre son códigos. Tomemos un ejemplo básico - nombre del cliente. No tiene nada que ver con el código, es un aspecto funcional (esencial), a diferencia de un aspecto técnico (accidental) de una aplicación.
Probablemente podría decir que cualquier información técnica / accidental es un código y que la información funcional / esencial no lo es.
En el contexto de la seguridad: debido a los desbordamientos del búfer, lo que usted consideraba como datos y, por lo tanto, inofensivo (como una imagen) puede ejecutarse como código y convertirse en su máquina.
En el contexto del desarrollo de software: muchos desarrolladores tienen mucho miedo de las cosas de "codificación" y están muy interesados en extraer parámetros que podrían tener que convertirse en archivos de configuración. A menudo, esto se basa en la idea de que los archivos de configuración son solo "datos" y, por lo tanto, se pueden cambiar fácilmente (por parte de los clientes) sin plantear los problemas (compilación, implementación, prueba) que cambiaría cualquier cosa en el código.
Lo que estos desarrolladores no se dan cuenta es que, dado que estos "datos" influyen en el comportamiento del programa, realmente es un código; podría romper el programa y la única razón para no requerir una prueba completa después de tal cambio es que, si se realiza correctamente, los valores configurables tienen un efecto muy específico y bien documentado, y cualquier valor no válido o una estructura de archivos rota será capturada por el programa.
Sin embargo, lo que sucede con demasiada frecuencia es que la estructura del archivo de configuración se convierte en un lenguaje de programación en sí mismo, completo con flujo de control y todo, uno que está mal documentado, tiene una sintaxis y un analizador extravagantes y que solo los desarrolladores más experimentados del equipo Se puede tocar sin romper la aplicación completamente.
Entonces, en un lenguaje como Scheme, incluso el código se trata como datos de primera clase. Puede tratar las funciones y expresiones lambda como lo hace con otro código, por ejemplo, pasarlas a otras funciones y expresiones lambda. Recomiendo continuar con el texto ya que todo esto quedará bastante claro.
Esta es una de las lecciones fundamentales del SICP y una de las ideas más poderosas de la informática. Funciona así:
Lo que pensamos como "código" en realidad no tiene el poder de hacer nada por sí mismo. El código define un programa solo dentro de un contexto de interpretación; fuera de ese contexto, es solo un flujo de caracteres. (Realmente es un flujo de bits, que en realidad es un flujo de impulsos eléctricos. Pero seamos sencillos.) El significado del código lo define el sistema dentro del cual lo ejecuta, y este sistema simplemente trata su código como información que indica Es lo que querías hacer. El código fuente de C es interpretado por un compilador de C como datos que describen un archivo de objeto que desea crear. Un archivo objeto es tratado por el cargador como datos que describen algunas instrucciones de la máquina que desea poner en cola para su ejecución. La CPU interpreta las instrucciones de la máquina como datos que definen la secuencia de las transiciones de estado a las que debe someterse.
Los lenguajes interpretados a menudo contienen mecanismos para tratar los datos como código, lo que significa que puede pasar el código a una función de alguna forma y luego ejecutarlo, o incluso generar código en tiempo de ejecución:
#!/usr/bin/perl
# Note that the above line explicitly defines the interpretive context for the
# rest of this file. Without the context of a Perl interpreter, this script
# doesn''t do anything.
sub foo {
my ($expression) = @_;
# $expression is just a string that happens to be valid Perl
print "$expression = " . eval("$expression") . "/n";
}
foo("1 + 1 + 2 + 3 + 5 + 8"); # sum of first six Fibonacci numbers
foo(join('' + '', map { $_ * $_ } (1..10))); # sum of first ten squares
Algunos lenguajes como esquema tienen un concepto de "funciones de primera clase", lo que significa que puede tratar una función como datos y pasarla sin evaluarla hasta que realmente lo desee.
El resultado es que la división entre "código" y "datos" es bastante arbitraria, una función de perspectiva solamente. Cuanto más bajo sea el nivel de abstracción, más "inteligente" debe ser el código: debe contener más información sobre cómo debe ejecutarse. Por otro lado, cuanta más información proporcione el intérprete, más tonto será el código, hasta que empiece a parecerse a los datos sin ninguna inteligencia.
Una de las formas más poderosas de escribir código es como una simple descripción de lo que necesita: Datos que se convertirán en código que describe cómo obtener lo que necesita por el contexto interpretativo. A esto lo llamamos "programación declarativa" .
Para un ejemplo concreto, considere HTML. HTML no describe un lenguaje de programación completo de Turing. Es meramente datos estructurados. Su estructura contiene algunas inteligencia que le permiten controlar el comportamiento de su contexto interpretativo, pero no mucha inteligencia. Por otro lado, contiene más inteligencia que los párrafos de texto que aparecen en una página web promedio: esos son datos bastante tontos.
Esto es algo que debes entender al escribir en un compilador.
Un paso común en los compiladores es transformar el programa en un árbol de sintaxis abstracta. La representación a menudo será como árboles como [+, 2, 3] donde + es la raíz, y 2, 3 son los hijos.
Los lenguajes Lisp simplemente tratan esto como sus datos. Por lo tanto, no hay separación entre los datos y el código, que son listas que parecen árboles AST.