Diese Definition ist der in meiner vorherigen Antwort angegebenen überlegen, da sie prägnant und allgemeiner ist. Es kann jedoch schwieriger sein, etwas zu verstehen, da die Implikation der Unvollständigkeitssätze, die für die Programmierung und das Leben im Allgemeinen gelten, für den Menschen schwierig ist, sich Gedanken zu machen.
Deklarativ vs. Imperativ
Die deklarative Eigenschaft ist seltsam, stumpf und schwer in einer technisch präzisen Definition zu erfassen, die allgemein und nicht mehrdeutig bleibt, da es eine naive Vorstellung ist, dass wir die Bedeutung (auch bekannt als Semantik) des Programms deklarieren können, ohne dass unbeabsichtigte Nebenwirkungen auftreten. Es gibt eine inhärente Spannung zwischen dem Ausdruck von Bedeutung und der Vermeidung unbeabsichtigter Effekte, und diese Spannung ergibt sich tatsächlich aus den Unvollständigkeitssätzen der Programmierung und unseres Universums.
Es ist zu einfach, technisch ungenau und oft nicht eindeutig, deklarativ als „ was zu tun ist “ und zwingend als „ wie zu tun “ zu definieren . Ein mehrdeutiger Fall ist das „ Was “ ist das „ Wie “ in einem Programm, das ein Programm ausgibt - einen Compiler.
Offensichtlich ist die unbegrenzte Rekursion, die eine Sprache Turing vervollständigt , auch analog in der Semantik - nicht nur in der syntaktischen Struktur der Bewertung (auch bekannt als operative Semantik). Dies ist logischerweise ein Beispiel analog zu Gödels Theorem: „Jedes vollständige Axiomensystem ist auch inkonsistent. “ Denken Sie über die widersprüchliche Verrücktheit dieses Zitats nach! Es ist auch ein Beispiel , das zeigt , wie der Ausdruck der Semantik nicht beweisbar gebunden hat, so können wir nicht beweisen , 2 , dass ein Programm (und seine Semantik analog) halt auch bekannt als der Halting Satz.
Die Unvollständigkeitssätze leiten sich aus der fundamentalen Natur unseres Universums ab, die, wie im zweiten Hauptsatz der Thermodynamik angegeben, lautet: „ Die Entropie (auch bekannt als die Anzahl der unabhängigen Möglichkeiten) tendiert für immer zum Maximum “. Das Codieren und Entwerfen eines Programms ist nie abgeschlossen - es lebt! -, weil es versucht, auf ein Bedürfnis der realen Welt einzugehen, und die Semantik der realen Welt sich ständig ändert und zu mehr Möglichkeiten tendiert. Menschen hören nie auf, neue Dinge zu entdecken (einschließlich Fehler in Programmen ;-).
Um diesen oben erwähnten gewünschten Begriff innerhalb dieses seltsamen Universums, das keinen Rand hat (denken Sie darüber nach! Es gibt kein „Äußeres“ unseres Universums), präzise und technisch zu erfassen, ist eine knappe, aber täuschend nicht einfache Definition erforderlich, die falsch klingt, bis sie erklärt wird tief.
Definition:
In der deklarativen Eigenschaft kann es nur einen möglichen Satz von Anweisungen geben, die jede spezifische modulare Semantik ausdrücken können.
Die imperative Eigenschaft 3 ist das Duale, bei dem die Semantik unter der Zusammensetzung inkonsistent ist und / oder mit Variationen von Aussagen ausgedrückt werden kann.
Diese Definition von deklarativ ist im semantischen Bereich eindeutig lokal , was bedeutet, dass eine modulare Semantik ihre konsistente Bedeutung beibehalten muss, unabhängig davon, wo und wie sie im globalen Bereich instanziiert und verwendet wird . Daher sollte jede deklarative modulare Semantik inhärent orthogonal zu allen möglichen anderen sein - und kein unmöglicher (aufgrund von Unvollständigkeitssätzen) globaler Algorithmus oder Modell, um Konsistenz zu bezeugen , was auch der Punkt von „ Mehr ist nicht immer besser “ von Robert Harper, Professor, ist of Computer Science an der Carnegie Mellon University, einem der Designer von Standard ML.
Beispiele für diese modulare deklarative Semantik sind kategorietheoretische Funktoren, z. B. dieApplicative nominale Typisierung, Namespaces, benannte Felder und die Semantik auf operativer Ebene der Semantik, dann reine funktionale Programmierung.
So können gut gestaltete deklarative Sprachen die Bedeutung klarer ausdrücken , wenn auch mit einem gewissen Verlust an Allgemeinheit in dem, was ausgedrückt werden kann, und einem Gewinn in dem, was mit intrinsischer Konsistenz ausgedrückt werden kann.
Ein Beispiel für die oben genannte Definition ist der Satz von Formeln in den Zellen eines Tabellenkalkulationsprogramms, von denen nicht erwartet wird, dass sie dieselbe Bedeutung haben, wenn sie in verschiedene Spalten- und Zeilenzellen verschoben werden, dh die Zellkennungen werden geändert. Die Zellkennungen sind Teil der beabsichtigten Bedeutung und nicht überflüssig. Daher ist jedes Tabellenkalkulationsergebnis für die Zellkennungen in einer Reihe von Formeln eindeutig. Die konsistente modulare Semantik ist in diesem Fall die Verwendung von Zellkennungen als Eingabe und Ausgabe von reinen Funktionen für Zellformeln (siehe unten).
Die Hyper Text Markup Language alias HTML - die Sprache für statische Webseiten - ist ein Beispiel für eine hoch (aber nicht perfekt 3 ) deklarative Sprache, die (zumindest vor HTML 5) kein dynamisches Verhalten ausdrücken konnte. HTML ist vielleicht die am einfachsten zu erlernende Sprache. Für dynamisches Verhalten wurde normalerweise eine zwingende Skriptsprache wie JavaScript mit HTML kombiniert. HTML ohne JavaScript passt zur deklarativen Definition, da jeder nominelle Typ (dh die Tags) seine konsistente Bedeutung unter Komposition innerhalb der Regeln der Syntax beibehält.
Eine konkurrierende Definition für deklarativ sind die kommutativen und idempotenten Eigenschaften der semantischen Anweisungen, dh, Anweisungen können neu geordnet und dupliziert werden, ohne die Bedeutung zu ändern. Beispielsweise können Anweisungen, die benannten Feldern Werte zuweisen, neu angeordnet und dupliziert werden, ohne die Bedeutung des Programms zu ändern, wenn diese Namen in einer impliziten Reihenfolge modular aufgebaut sind. Namen implizieren manchmal eine Reihenfolge, z. B. enthalten Zellkennungen ihre Spalten- und Zeilenposition. Wenn Sie eine Summe in der Tabelle verschieben, ändert sich ihre Bedeutung. Andernfalls erfordern diese Eigenschaften implizit globalKonsistenz der Semantik. Es ist im Allgemeinen unmöglich, die Semantik von Anweisungen so zu gestalten, dass sie konsistent bleiben, wenn sie zufällig angeordnet oder dupliziert werden, da Reihenfolge und Duplizierung der Semantik eigen sind. Zum Beispiel die Aussagen "Foo existiert" (oder Konstruktion) und "Foo existiert nicht" (und Zerstörung). Wenn man zufällige Inkonsistenzen als endemisch für die beabsichtigte Semantik betrachtet, akzeptiert man diese Definition als allgemein genug für die deklarative Eigenschaft. Im Wesentlichen ist diese Definition als verallgemeinerte Definition leer, weil sie versucht, die Konsistenz orthogonal zur Semantik zu machen, dh der Tatsache zu trotzen, dass das Universum der Semantik dynamisch unbegrenzt ist und nicht in einem globalen Kohärenzparadigma erfasst werden kann .
Das Erfordernis der kommutativen und idempotenten Eigenschaften für die (strukturelle Bewertungsreihenfolge der) Betriebssemantik der unteren Ebene konvertiert die Betriebssemantik in eine deklarative lokalisierte modulare Semantik, z. B. reine funktionale Programmierung (einschließlich Rekursion anstelle von Imperativschleifen). Dann wirkt sich die Betriebsreihenfolge der Implementierungsdetails nicht auf die Konsistenz der übergeordneten Semantik aus (dh global verteilt ). Zum Beispiel spielt die Reihenfolge der Auswertung (und theoretisch auch der Vervielfältigung) der Tabellenkalkulationsformeln keine Rolle, da die Ausgaben erst in die Eingaben kopiert werden, nachdem alle Ausgaben berechnet wurden, dh analog zu reinen Funktionen.
C, Java, C ++, C #, PHP und JavaScript sind nicht besonders deklarativ. Die Syntax von Copute und die Syntax von Python sind deklarativer an die beabsichtigten Ergebnisse gekoppelt , dh an eine konsistente syntaktische Semantik, die das Fremde eliminiert, sodass man Code leicht verstehen kann, nachdem man ihn vergessen hat. Copute und Haskell erzwingen den Determinismus der operativen Semantik und ermutigen dazu, sich nicht zu wiederholen (DRY), weil sie nur das reine Funktionsparadigma zulassen.
2 Selbst wenn wir die Semantik eines Programms beweisen können, z. B. mit der Sprache Coq, ist dies auf die Semantik beschränkt, die in der Eingabe ausgedrückt wird , und die Eingabe kann niemals die gesamte Semantik eines Programms erfassen - nicht einmal für Sprachen, die es sind nicht vollständig, z. B. mit HTML + CSS, ist es möglich, inkonsistente Kombinationen auszudrücken, die somit eine undefinierte Semantik haben.
3 Viele Erklärungen behaupten fälschlicherweise, dass nur die imperative Programmierung syntaktisch geordnete Anweisungen enthält. Ich habe diese Verwechslung zwischen imperativer und funktionaler Programmierung geklärt . Beispielsweise verringert die Reihenfolge der HTML-Anweisungen nicht die Konsistenz ihrer Bedeutung.
in der funktionalen Programmierung ... ist der Variationsbereich einer Variablen ein Typ
Abhängig davon, wie man funktionale von imperativer Programmierung unterscheidet, kann Ihr 'zuweisbar' in einem imperativen Programm auch einen Typ haben, der seine Variabilität begrenzt.
Die einzige nicht durcheinandergebrachte Definition, die ich derzeit für die funktionale Programmierung schätze, ist a) Funktionen als erstklassige Objekte und Typen, b) Präferenz für Rekursion gegenüber Schleifen und / oder c) reine Funktionen - dh solche Funktionen, die die gewünschte Semantik nicht beeinflussen des Programms, wenn es gespeichert ist ( daher existiert aufgrund der Auswirkungen der Betriebssemantik, z . B. der Speicherzuweisung, keine vollkommen reine funktionale Programmierung in einer allgemeinen Denotationssemantik ).
Die idempotente Eigenschaft einer reinen Funktion bedeutet, dass der Funktionsaufruf für ihre Variablen durch ihren Wert ersetzt werden kann, was bei den Argumenten einer imperativen Prozedur im Allgemeinen nicht der Fall ist. Reine Funktionen scheinen für die nicht zusammengesetzten Zustandsübergänge zwischen den Eingabe- und Ergebnistypen deklarativ zu sein.
Die Zusammensetzung reiner Funktionen behält jedoch keine solche Konsistenz bei, da es möglich ist, einen Nebeneffektprozess (globaler Zustand) in einer rein funktionalen Programmiersprache, z. B. Haskells IOMonad, zu modellieren, und darüber hinaus ist es völlig unmöglich, dies zu verhindern jede Turing komplett reine funktionale Programmiersprache.
Wie ich 2012 schrieb, was dem ähnlichen Konsens der Kommentare in Ihrem letzten Blog entspricht , ist diese deklarative Programmierung ein Versuch, die Vorstellung zu erfassen, dass die beabsichtigte Semantik niemals undurchsichtig ist. Beispiele für undurchsichtige Semantik sind die Abhängigkeit von der Ordnung, die Abhängigkeit vom Löschen der Semantik höherer Ebenen auf der Ebene der operativen Semantik (z. B. Casts sind keine Konvertierungen und reifizierte Generika begrenzen die Semantik höherer Ebenen ) und die Abhängigkeit von variablen Werten, die nicht überprüft werden können (bewiesen) richtig) durch die Programmiersprache.
Ich bin daher zu dem Schluss gekommen, dass nur nicht-Turing-vollständige Sprachen deklarativ sein können.
Ein eindeutiges und eindeutiges Merkmal einer deklarativen Sprache könnte daher sein, dass nachgewiesen werden kann, dass ihre Ausgabe einer Reihe von generativen Regeln entspricht. Beispielsweise kann für ein bestimmtes HTML-Programm (das Unterschiede in der Art und Weise, wie Interpreter voneinander abweichen) ignoriert wird, das nicht mit Skripten versehen ist (dh nicht vollständig ist), die Ausgabevariabilität aufzählbar sein. Kurz gesagt, ein HTML-Programm ist eine reine Funktion seiner Variabilität. Ebenso ist ein Tabellenkalkulationsprogramm eine reine Funktion seiner Eingabevariablen.
Es scheint mir also, dass deklarative Sprachen das Gegenteil einer
unbegrenzten Rekursion sind , dh nach Gödels zweitem Unvollständigkeitssatz können selbstreferenzielle Sätze nicht bewiesen werden.
Lesie Lamport schrieb ein Märchen darüber, wie Euklid Gödels Unvollständigkeitssätze, die auf mathematische Beweise im Kontext der Programmiersprache angewendet wurden, um die Kongruenz zwischen Typen und Logik (Curry-Howard-Korrespondenz usw.) herum umgehen könnte.