me encontré con una idea en The Structure And Interpretation of Computer Programs:¿Qué significa "Los datos son solo código tonto y el código es solo datos inteligentes"?
de datos es sólo código mudo, y el código es sólo datos inteligentes
llego a entender lo que significa. ¿Puede alguien ayudarme a entenderlo mejor?
Esta es una de las lecciones fundamentales de SICP y una de las ideas más poderosas de la informática. Funciona así:
Lo que consideramos 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 una secuencia de caracteres. (Realmente una secuencia de bits, que en realidad es una corriente de impulsos eléctricos. Pero seamos simples). El que significa del código está definido por el sistema dentro del cual lo ejecuta, y este sistema solo trata su código como datos eso le dice lo que quería hacer. El código fuente C es interpretado por un compilador C como datos que describen un archivo objeto que usted quiere que cree. 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. Las instrucciones de la máquina son interpretadas por la CPU como datos que definen la secuencia de transiciones de estado a las que debe someterse.
lenguajes interpretados a menudo contienen mecanismos para el tratamiento de datos como código, lo que significa que puede pasar el código en una función en 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 idiomas Como el esquema tiene 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 menor 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, mientras más información suministre el intérprete, más tonto puede ser el código, hasta que comienza a parecerse a los datos sin ninguna inteligencia.
Una de las formas más potentes de escribir código es como una simple descripción de lo que necesita: datos que se convertirán en código que describirá cómo obtener lo que necesita según el contexto interpretativo. Llamamos a esto "declarative programming".
Para un ejemplo concreto, considere HTML. HTML no describe un lenguaje de programación completo de Turing. Es meramente datos estructurados. Su estructura contiene algunos conocimientos 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.
por cierto ... http://stackoverflow.com/questions/2497146/is-css-turing-complete – n611x007
Su respuesta es excelente para explicar lo que significa la oración en un nivel teórico, pero creo que hay algo de espacio para cubrir lo que significa en términos de modificar prácticamente la forma en que tratas los programas. Es posible que desee también cubrir ideas sobre cómo esta máxima es la idea central de OOP. es decir, el poder de encapsular juntos códigos y datos relevantes, tratando semánticamente a los usuarios como si fueran los datos subyacentes del POV del contexto de llamada, etc. – Racheet
Por lo tanto, en un lenguaje como Scheme, incluso el código se trata como datos de primera clase. Puede tratar funciones y expresiones lambda de manera similar a como trata a otros códigos, digamos pasándolos a otras funciones y expresiones lambda. Recomiendo continuar con el texto ya que todo quedará bastante claro.
Esto es algo que deberías entender al escribir en un compilador.
Un paso común en los compiladores es transformar el programa en un árbol de sintaxis abstracto. La representación a menudo será como árboles como [+, 2, 3] donde + es la raíz y 2, 3 son los hijos.
Lisp languages simplemente trata 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.
En el contexto de la seguridad: Debido a los desbordamientos del búfer, lo que usted pensó que era un dato y, por lo tanto, inofensivo (como una imagen) se puede ejecutar como código y poner su máquina.
En el contexto del desarrollo de software: Muchos desarrolladores tienen mucho miedo de "hardcoding" cosas y muy interesado en la extracción de parámetros que pueden tener que cambiar en archivos de configuración. Esto a menudo se basa en la idea de que los archivos de configuración son solo "datos" y, por lo tanto, pueden cambiarse fácilmente (perhapy por los clientes) sin plantear 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 código; podría romper el programa y la única razón para no requerir pruebas completas 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 archivo rota será atrapada por el programa.
Sin embargo, lo que ocurre con demasiada frecuencia es que la estructura del archivo de configuración se convierte en un lenguaje de programación completo, con flujo de control y todo, uno que está mal documentado, tiene una sintaxis y un analizador los desarrolladores en el equipo pueden tocar sin romper completamente la aplicación.
+1. Actualmente, existe una preocupante tendencia mundial a almacenar todo en feos archivos XML, que con el tiempo se vuelven cada vez más complicados y difíciles de comprender. Como dijiste, expone la falta de conocimiento de un programador promedio sobre las diferencias entre el código y los datos. –
Tienes un buen punto allí, estaré pensando en eso cuando diseñe mi próximo sistema súper increíble increíble de can-do-all ;-) –
El código es definitivamente datos, pero los datos son definitivamente código no siempre. Tomemos un ejemplo básico: nombre del cliente. No tiene nada que ver con el código, es un funcional (esencial), a diferencia de un aspecto técnico (accidental) de una aplicación.
Probablemente pueda decir que cualquier dato técnico/accidental es código y que los datos funcionales/esenciales no lo son.
¿Cómo se puede decir que está "redactado elegantemente" si no sabes lo que significa? – sykora
Primero pensé que era un quiasma, pero ahora creo que es una antimetabole. – tuinstoel
http://en.wikipedia.org/wiki/Von_Neumann_architecture –