Esta definición es superior a la que proporcioné en mi respuesta anterior, porque es sucinta y es más general. Pero puede ser más difícil de asimilar, porque la implicación de los teoremas de incompletitud aplicables a la programación y la vida en general son difíciles de entender para los humanos.
La explicación citada de la definición discute el papel que juega la programación funcional pura en la programación declarativa.
Declarativo versus imperativo
La propiedad declarativa es extraña, obtusa y difícil de capturar en una definición técnicamente precisa que sigue siendo general y no ambigua, porque es una noción ingenua de que podemos declarar el significado (también conocido como semántica) del programa sin incurrir en efectos secundarios no deseados. Existe una tensión inherente entre la expresión del significado y la evitación de efectos no deseados, y esta tensión en realidad deriva de los teoremas de incompletitud de la programación y nuestro universo.
Es una simplificación excesiva, técnicamente imprecisa y, a menudo, ambigua definir declarativo como " qué hacer " e imperativo como " cómo hacerlo " . Un caso ambiguo es el " qué " es el " cómo " en un programa que genera un programa: un compilador.
Evidentemente, la recursión ilimitada que hace que un lenguaje Turing sea completo , también está análogamente en la semántica, no solo en la estructura sintáctica de la evaluación (también conocida como semántica operativa). Esto es lógicamente un ejemplo análogo al teorema de Gödel: " cualquier sistema completo de axiomas también es inconsistente ". ¡Reflexione sobre la rareza contradictoria de esa cita! También es un ejemplo que demuestra cómo la expresión de la semántica no tiene demostrable obligado, por tanto, no podemos probar 2 que un programa (y análogamente su semántica) detuvo también conocido como el teorema de Detención.
Los teoremas de incompletitud derivan de la naturaleza fundamental de nuestro universo, que como se establece en la Segunda Ley de la Termodinámica es " la entropía (también conocida como el # de posibilidades independientes) está tendiendo al máximo para siempre ". La codificación y el diseño de un programa nunca terminan, ¡está vivo! Porque intenta abordar una necesidad del mundo real, y la semántica del mundo real siempre está cambiando y tiende a más posibilidades. Los humanos nunca dejan de descubrir cosas nuevas (incluidos errores en los programas ;-).
Para capturar de manera precisa y técnica esta noción deseada antes mencionada dentro de este universo extraño que no tiene borde (¡piense que no hay "fuera" de nuestro universo), requiere una definición concisa pero engañosamente no simple que sonará incorrecta hasta que se explique profundamente.
Definición:
La propiedad declarativa es donde puede existir un solo conjunto posible de declaraciones que pueden expresar cada semántica modular específica.
La propiedad imperativa 3 es la dual, donde la semántica es inconsistente en la composición y / o puede expresarse con variaciones de conjuntos de enunciados.
Esta definición de declarativa es distintivamente local en el ámbito semántico, lo que significa que requiere que una semántica modular mantenga su significado coherente independientemente de dónde y cómo se instancia y emplea en el ámbito global . Por lo tanto, cada semántica modular declarativa debería ser intrínsecamente ortogonal a todas las demás posibles, y no un algoritmo o modelo global imposible (debido a teoremas de incompletitud) para presenciar la coherencia, que también es el punto de " Más no siempre es mejor " por Robert Harper, profesor de Informática en la Universidad Carnegie Mellon, uno de los diseñadores de Standard ML.
Ejemplos de estos incluyen semántica declarativa modulares categoría funtores teoría, por ejemplo, laApplicative , mecanografía nominal, espacios de nombres, los campos de nombre y WRT a nivel operativo de la semántica a continuación, la programación funcional pura.
Por lo tanto, los lenguajes declarativos bien diseñados pueden expresar más claramente el significado , aunque con cierta pérdida de generalidad en lo que se puede expresar, pero una ganancia en lo que se puede expresar con consistencia intrínseca.
Un ejemplo de la definición antes mencionada es el conjunto de fórmulas en las celdas de un programa de hoja de cálculo, que no se espera que den el mismo significado cuando se mueven a diferentes celdas de columna y fila, es decir, los identificadores de celda cambiaron. Los identificadores de celda son parte y no son superfluos para el significado pretendido. Por lo tanto, el resultado de cada hoja de cálculo es wrt único para los identificadores de celda en un conjunto de fórmulas. La semántica modular consistente en este caso es el uso de identificadores de celda como entrada y salida de funciones puras para fórmulas de celdas (ver más abajo).
Hyper Text Markup Language, también conocido como HTML, el lenguaje para páginas web estáticas, es un ejemplo de un lenguaje declarativo altamente (pero no perfectamente 3 ) que (al menos antes de HTML 5) no tenía capacidad para expresar un comportamiento dinámico. HTML es quizás el lenguaje más fácil de aprender. Para el comportamiento dinámico, un lenguaje de script imperativo como JavaScript generalmente se combinaba con HTML. HTML sin JavaScript se ajusta a la definición declarativa porque cada tipo nominal (es decir, las etiquetas) mantiene su significado consistente en la composición dentro de las reglas de la sintaxis.
Una definición competitiva para declarativa son las propiedades conmutativas e idempotentes de las declaraciones semánticas, es decir, que las declaraciones pueden reordenarse y duplicarse sin cambiar el significado. Por ejemplo, las declaraciones que asignan valores a campos con nombre pueden reordenarse y duplicarse sin cambiar el significado del programa, si esos nombres son modulares en cualquier orden implícito. Los nombres a veces implican un orden, por ejemplo, los identificadores de celda incluyen su posición de columna y fila; mover un total en la hoja de cálculo cambia su significado. De lo contrario, estas propiedades requieren implícitamente globalConsistencia de la semántica. En general, es imposible diseñar la semántica de las declaraciones para que permanezcan consistentes si se ordenan o duplican al azar, porque el orden y la duplicación son intrínsecos a la semántica. Por ejemplo, las declaraciones "Foo existe" (o construcción) y "Foo no existe" (y destrucción). Si uno considera que la inconsistencia aleatoria es endémica de la semántica prevista, entonces acepta esta definición como lo suficientemente general para la propiedad declarativa. En esencia, esta definición es vacía como una definición generalizada porque intenta hacer que la consistencia sea ortogonal a la semántica, es decir, desafiar el hecho de que el universo de la semántica es dinámicamente ilimitado y no puede ser capturado en un paradigma de coherencia global .
Requerir las propiedades conmutativas e idempotentes para la (orden de evaluación estructural de) la semántica operacional de nivel inferior convierte la semántica operacional en una semántica modular declarativa localizada , por ejemplo, programación funcional pura (incluyendo recursión en lugar de bucles imperativos). Luego, el orden operativo de los detalles de implementación no impacta (es decir, se extiende globalmente en) la consistencia de la semántica de nivel superior. Por ejemplo, el orden de evaluación de (y teóricamente también la duplicación de) las fórmulas de la hoja de cálculo no importa porque las salidas no se copian a las entradas hasta después de que todas las salidas se hayan calculado, es decir, de forma análoga a las funciones puras.
C, Java, C ++, C #, PHP y JavaScript no son particularmente declarativos. La sintaxis de Copute y la sintaxis de Python se asocian más declarativamente a los resultados esperados , es decir, una semántica sintáctica consistente que elimina lo extraño para que uno pueda comprender fácilmente el código después de haberlo olvidado. Copute y Haskell imponen el determinismo de la semántica operativa y alientan " no te repitas " (DRY), porque solo permiten el paradigma funcional puro.
2 Incluso cuando podemos probar la semántica de un programa, por ejemplo, con el lenguaje Coq, esto se limita a la semántica que se expresa en la tipificación , y la tipificación nunca puede capturar toda la semántica de un programa, ni siquiera para los idiomas que son No está completo, por ejemplo, con HTML + CSS es posible expresar combinaciones inconsistentes que tienen una semántica indefinida.
3 Muchas explicaciones afirman incorrectamente que solo la programación imperativa tiene sentencias ordenadas sintácticamente. Aclaré esta confusión entre la programación imperativa y funcional . Por ejemplo, el orden de las declaraciones HTML no reduce la coherencia de su significado.
en programación funcional ... el rango de variación de una variable es un tipo
Dependiendo de cómo se distinga la programación funcional de la imperativa, su 'asignable' en un programa imperativo también puede tener un tipo que pone un límite a su variabilidad.
La única definición no confusa que aprecio actualmente para la programación funcional es a) funciones como objetos y tipos de primera clase, b) preferencia por la recursión sobre bucles, y / o c) funciones puras, es decir, aquellas funciones que no afectan la semántica deseada del programa cuando se memoriza (por lo tanto, la programación funcional perfectamente pura no existe en una semántica denotativa de propósito general debido a los impactos de la semántica operativa, por ejemplo, la asignación de memoria ).
La propiedad idempotente de una función pura significa que la llamada a la función en sus variables puede ser sustituida por su valor, que generalmente no es el caso para los argumentos de un procedimiento imperativo. Las funciones puras parecen ser wrt declarativas para las transiciones de estado no compuestas entre los tipos de entrada y resultado.
Pero la composición de las funciones puras no mantiene tal consistencia, porque es posible modelar un proceso imperativo de efectos secundarios (estado global) en un lenguaje de programación funcional puro, por ejemplo, IOMonad de Haskell y, además, es completamente imposible evitar hacerlo. cualquier lenguaje de programación funcional puro completo de Turing.
Como escribí en 2012, que parece un consenso similar de comentarios en su blog reciente , esa programación declarativa es un intento de capturar la noción de que la semántica prevista nunca es opaca. Ejemplos de semántica opaca son la dependencia del orden, la dependencia del borrado de la semántica de nivel superior en la capa de semántica operativa (por ejemplo, los modelos no son conversiones y los genéricos reificados limitan la semántica de nivel superior ) y la dependencia de valores variables que no pueden verificarse (demostrarse correcto) por el lenguaje de programación.
Por lo tanto, he concluido que solo los idiomas completos que no son de Turing pueden ser declarativos.
Por lo tanto, un atributo inequívoco y distinto de un lenguaje declarativo podría ser que se puede demostrar que su salida obedece a un conjunto enumerable de reglas generativas. Por ejemplo, para cualquier programa HTML específico (ignorando las diferencias en las formas en que los intérpretes divergen) que no está programado (es decir, no está completo en Turing), entonces su variabilidad de salida puede ser enumerable. O más sucintamente, un programa HTML es una función pura de su variabilidad. Lo mismo ocurre con un programa de hoja de cálculo es una función pura de sus variables de entrada.
Por lo tanto, me parece que los lenguajes declarativos son la antítesis de la
recursión ilimitada , es decir, según el segundo teorema de incompletitud de Gödel, los teoremas autorreferenciales no se pueden probar.
Lesie Lamport escribió un cuento de hadas sobre cómo Euclides podría haber trabajado en torno a los teoremas de incompletitud de Gödel aplicados a las pruebas matemáticas en el contexto del lenguaje de programación por congruencia entre tipos y lógica (correspondencia de Curry-Howard, etc.).