Qu’est-ce que la programmation déclarative?

Je continue à entendre ce terme jeté dans plusieurs contextes différents. Qu’Est-ce que c’est?

La programmation déclarative est lorsque vous écrivez votre code de telle manière qu’il décrit ce que vous voulez faire, et non comment vous voulez le faire. Il est laissé au compilateur pour comprendre comment.

SQL et Prolog sont des exemples de langages de programmation déclaratifs.

Les autres réponses font déjà un travail fantastique en expliquant ce qu’est la programmation déclarative, alors je vais juste donner quelques exemples des raisons pour lesquelles cela pourrait être utile.

Indépendance du contexte

Les programmes déclaratifs sont indépendants du contexte . Comme ils ne déclarent que le but ultime, mais pas les étapes intermédiaires pour atteindre cet objective, le même programme peut être utilisé dans différents contextes. Cela est difficile à faire avec les programmes impératifs , car ils dépendent souvent du contexte (par exemple, état caché).

Prenez l’exemple de yacc . C’est un générateur de parseur aka. compilateur compilateur, un DSL externe déclaratif pour décrire la grammaire d’un langage, de sorte qu’un parsingur pour cette langue puisse être généré automatiquement à partir de la description. En raison de son indépendance par rapport au contexte, vous pouvez faire beaucoup de choses différentes avec une telle grammaire:

  • Génère un parsingur C pour cette grammaire (le cas d’utilisation d’origine pour yacc )
  • Générer un parsingur C ++ pour cette grammaire
  • Générer un parsingur Java pour cette grammaire (en utilisant Jay)
  • Générer un parsingur C # pour cette grammaire (en utilisant GPPG)
  • Générer un parsingur Ruby pour cette grammaire (à l’aide de Racc)
  • Générer une visualisation d’arborescence pour cette grammaire (à l’aide de GraphViz)
  • Faites simplement une jolie impression, un formatage sophistiqué et une mise en évidence de la syntaxe du fichier source yacc lui-même et incluez-le dans votre manuel de référence en tant que spécification syntaxique de votre langue

Et beaucoup plus …

Optimisation

Parce que vous ne prescrivez pas l’ordinateur les étapes à suivre et dans quel ordre, il peut réorganiser votre programme beaucoup plus librement, voire exécuter certaines tâches en parallèle. Un bon exemple est un planificateur de requêtes et un optimiseur de requêtes pour une firebase database SQL. La plupart des bases de données SQL vous permettent d’afficher la requête qu’elles exécutent réellement par rapport à la requête que vous leur avez demandé d’exécuter. Souvent, ces requêtes ne se ressemblent pas . Le planificateur de requêtes prend en compte les choses dont vous n’auriez même pas rêvé: la latence de rotation du disque, par exemple, ou le fait qu’une application complètement différente pour un utilisateur complètement différent exécutait une requête similaire et la table que vous êtes. se joindre à et que vous avez travaillé si dur pour éviter le chargement est déjà en mémoire de toute façon.

Il y a un compromis intéressant à faire ici: la machine doit travailler plus dur pour comprendre comment faire quelque chose que dans un langage impératif, mais quand il le comprend, il a beaucoup plus de liberté et beaucoup plus d’informations pour l’optimisation. étape.

Librement:

La programmation déclarative tend vers: –

  • Ensembles de déclarations ou déclarations déclaratives, chacune ayant un sens (souvent dans le domaine problématique) et pouvant être comprise indépendamment et isolément.

La programmation impérative tend vers: –

  • Séquences de commandes, chacune effectuant une action; mais qui peut ou non avoir un sens dans le domaine problématique.

En conséquence, un style impératif aide le lecteur à comprendre la mécanique de ce que le système est en train de faire, mais peut donner peu d’indications sur le problème qu’il est censé résoudre. D’un autre côté, un style déclaratif aide le lecteur à comprendre le domaine du problème et l’approche que le système prend pour résoudre le problème, mais il est moins informatif en matière de mécanique.

Les vrais programmes (même ceux écrits dans des langues qui favorisent les extrémités du spectre, telles que ProLog ou C) ont tendance à présenter les deux styles à des degrés divers, à divers points, pour satisfaire les complexités et les besoins de communication variables de la pièce. Un style n’est pas supérieur à l’autre; elles ne servent que des objectives différents et, comme pour beaucoup de choses dans la vie, la modération est essentielle.

Je suis désolé, mais je dois être en désaccord avec plusieurs autres réponses. Je voudrais arrêter cette incompréhension confuse de la définition de la programmation déclarative.

Définition

La transparence référentielle (RT) des sous-expressions est le seul atsortingbut requirejs d’une expression de programmation déclarative , car il s’agit du seul atsortingbut qui n’est pas partagé avec la programmation impérative.

D’autres atsortingbuts cités de la programmation déclarative découlent de cette RT. Veuillez cliquer sur le lien ci-dessus pour l’explication détaillée.

Exemple de feuille de calcul

Deux réponses mentionnent la programmation par tableur. Dans les cas où la programmation par tableur (aka formules) n’accède pas à l’ état global mutable, alors il s’agit d’une programmation déclarative. Cela est dû au fait que les valeurs de cellules mutables sont les entrées et sorties monolithiques de main() (le programme entier). Les nouvelles valeurs ne sont pas écrites dans les cellules après chaque exécution de la formule, elles ne sont donc pas modifiables pendant la durée du programme déclaratif (exécution de toutes les formules du tableur). Ainsi, les unes par rapport aux autres, les formules considèrent ces cellules mutables comme immuables. Une fonction RT est autorisée à accéder à un état global immuable (et à un état local mutable ).

Ainsi, la possibilité de muter les valeurs dans les cellules lorsque le programme se termine (en tant que sortie de main() ) ne les rend pas mutables dans le contexte des règles. La distinction clé est que les valeurs de cellule ne sont pas mises à jour après chaque formule de feuille de calcul, de sorte que l’ordre d’exécution des formules n’a pas d’importance. Les valeurs de cellule sont mises à jour après que toutes les formules déclaratives ont été effectuées.

La programmation déclarative est l’image, où la programmation impérative est des instructions pour peindre cette image.

Vous écrivez dans un style déclaratif si vous «dites ce que c’est», plutôt que de décrire les étapes que l’ordinateur doit suivre pour arriver là où vous le voulez.

Lorsque vous utilisez XML pour baliser des données, vous utilisez une programmation déclarative car vous dites “Ceci est une personne, c’est un anniversaire, et il y a une adresse postale”.

Quelques exemples où la programmation déclarative et impérative est combinée pour un plus grand effet:

  • Windows Presentation Foundation utilise la syntaxe XML déclarative pour décrire l’apparence d’une interface utilisateur et les relations (liaisons) entre les contrôles et les structures de données sous-jacentes.

  • Les fichiers de configuration structurés utilisent la syntaxe déclarative (aussi simple que les paires “clé = valeur”) pour identifier ce que signifie une chaîne ou une valeur de données.

  • HTML marque le texte avec des balises qui décrivent le rôle de chaque élément de texte par rapport à l’ensemble du document.

Imaginez une page Excel. Avec des colonnes remplies de formules pour calculer votre déclaration de revenus.

Toute la logique est faite déclarée dans les cellules, l’ordre du calcul est déterminé par la formule elle-même plutôt que par la procédure.

C’est une sorte de programmation déclarative. Vous déclarez l’espace problème et la solution plutôt que le stream du programme.

Prolog est le seul langage déclaratif que j’ai utilisé. Cela nécessite un autre type de reflection, mais il est bon d’apprendre si ce n’est que pour vous exposer à autre chose qu’un langage de programmation procédural typique.

Depuis que j’ai écrit ma réponse précédente, j’ai formulé une nouvelle définition de la propriété déclarative qui est citée ci-dessous. J’ai également défini la programmation impérative comme la propriété double.

Cette définition est supérieure à celle que j’ai fournie dans ma réponse précédente, car elle est succincte et plus générale. Mais cela peut être plus difficile à comprendre, car les implications des théorèmes d’incomplétude applicables à la programmation et à la vie en général sont difficiles à comprendre pour les humains.

L’explication citée de la définition traite du rôle joué par la functional programming pure dans la programmation déclarative.

Déclaratif vs. Impératif

La propriété déclarative est étrange, obtuse et difficile à saisir dans une définition techniquement précise qui rest générale et non ambiguë, car il est naïf que nous puissions déclarer le sens (sémantique) du programme sans provoquer d’effets secondaires inattendus. Il y a une tension inhérente entre l’expression du sens et l’évitement des effets involontaires, et cette tension dérive en réalité des théorèmes d’incomplétude de la programmation et de notre univers.

Il s’agit d’une simplification excessive, techniquement imprécise et souvent ambiguë pour définir le déclaratif comme « quoi faire » et comme impératif « comment faire » . Un cas ambigu est le « quoi » est le « comment » dans un programme qui produit un programme – un compilateur.

Evidemment, la récursivité sans limite qui rend un langage Turing complet , est également analogue dans la sémantique – pas seulement dans la structure syntaxique de l’évaluation (sémantique opérationnelle). C’est logiquement un exemple analogue au théorème de Gödel: « tout système complet d’axiomes est également incohérent ». Réfléchissez à l’étrangeté contradictoire de cette citation! C’est aussi un exemple qui démontre comment l’expression de la sémantique n’a pas de lien prouvable, nous ne pouvons donc pas prouver qu’un programme (et de manière analogue sa sémantique) arrête le théorème de Halting.

Les théorèmes d’incomplétude découlent de la nature fondamentale de notre univers, qui, comme indiqué dans la deuxième loi de la thermodynamic, est que « l’entropie (alias le nombre de possibilités indépendantes) tend vers toujours ». Le codage et la conception d’un programme ne sont jamais terminés – c’est vivant! – parce qu’il tente de répondre à un besoin réel, et la sémantique du monde réel évolue constamment vers plus de possibilités. Les humains ne cessent jamais de découvrir de nouvelles choses (y compris des erreurs dans les programmes ;-).

Pour capturer précisément et techniquement cette notion désirée dans cet univers étrange qui n’a pas de limite (pensez que! Il n’y a pas de “dehors” de notre univers), nécessite une définition concise mais trompeuse-pas-simple qui semblera incorrecte jusqu’à ce qu’elle soit expliquée profondément.

Définition:


La propriété déclarative est l’endroit où il ne peut exister qu’un ensemble possible d’instructions pouvant exprimer chaque sémantique modulaire spécifique.

La propriété impérative 3 est le dual, où la sémantique est incohérente sous la composition et / ou peut être exprimée avec des variations d’ensembles d’énoncés.


Cette définition de déclarative est distinctement locale dans la scope sémantique, ce qui signifie qu’une sémantique modulaire doit conserver sa signification cohérente, quel que soit le lieu et la manière dont elle est instanciée et utilisée dans un contexte global . Ainsi, chaque sémantique modulaire déclarative devrait être insortingnsèquement orthogonale à toutes les autres possibles – et non pas un algorithme ou modèle global impossible (dû aux théorèmes d’incomplétude) pour témoigner de la cohérence, qui est aussi le sharepoint Robert Harper, professeur. de l’informatique à l’Université Carnegie Mellon, l’un des concepteurs de la norme ML.

Des exemples de ces sémantiques déclaratives modulaires comprennent les foncteurs de théorie des catégories, par exemple, le type Applicative , le typage nominal, les espaces de noms, les champs nommés et, au niveau opérationnel de la sémantique, puis la functional programming pure.

Ainsi, des langages déclaratifs bien conçus peuvent exprimer plus clairement le sens , avec une certaine perte de généralité dans ce qui peut être exprimé, mais un gain dans ce qui peut être exprimé avec une cohérence insortingnsèque.

Un exemple de la définition mentionnée ci-dessus est l’ensemble de formules dans les cellules d’un tableur – qui ne sont pas censées donner le même sens lorsqu’elles sont déplacées dans des cellules de colonnes et de lignes différentes, c.-à-d. Les identifiants de cellule font partie de la signification voulue et ne sont pas superflus. Ainsi, chaque résultat de feuille de calcul est unique par rapport aux identificateurs de cellule dans un ensemble de formules. La sémantique modulaire cohérente dans ce cas est l’utilisation d’identifiants de cellule comme entrée et sortie de fonctions pures pour les formules de cellules (voir ci-dessous).

Hyper Text Markup Language aka HTML – le langage des pages Web statiques – est un exemple de langage déclaratif hautement (mais pas parfaitement) 3 qui (au moins avant HTML 5) ne permettait pas d’exprimer un comportement dynamic. HTML est peut-être le langage le plus facile à apprendre. Pour le comportement dynamic, un langage de script impératif tel que JavaScript était généralement combiné avec HTML. HTML sans JavaScript correspond à la définition déclarative car chaque type nominal (c’est-à-dire les balises) conserve sa signification cohérente sous la composition dans les règles de la syntaxe.

Une définition concurrente pour déclarative est les propriétés commutatives et idempotentes des déclarations sémantiques, c’est-à-dire que les instructions peuvent être réordonnées et dupliquées sans en changer la signification. Par exemple, les instructions affectant des valeurs à des champs nommés peuvent être réorganisées et dupliquées sans changer la signification du programme, si ces noms sont modulaires par rapport à un ordre implicite. Les noms impliquent parfois un ordre, par exemple les identifiants de cellule incluent leur position de colonne et de ligne – le déplacement d’un total sur une feuille de calcul change sa signification. Sinon, ces propriétés nécessitent implicitement une cohérence globale de la sémantique. Il est généralement impossible de concevoir la sémantique des instructions pour qu’elles restnt cohérentes si elles sont ordonnées ou dupliquées de manière aléatoire, car l’ordre et la duplication sont insortingnsèques à la sémantique. Par exemple, les déclarations «Foo existe» (ou construction) et «Foo n’existe pas» (et destruction). Si l’on considère une incohérence aléatoire endémique de la sémantique voulue, on accepte cette définition comme suffisamment générale pour la propriété déclarative. Essentiellement, cette définition est vide en tant que définition généralisée car elle tente de rendre la cohérence orthogonale à la sémantique, c’est-à-dire de défier le fait que l’univers de la sémantique ne soit pas lié à un paradigme de cohérence global .

Exiger les propriétés commutatives et idempotentes pour la sémantique opérationnelle de niveau inférieur (ordre d’évaluation structurelle) convertit la sémantique opérationnelle en une sémantique modulaire déclarative localisée , par exemple la functional programming pure (y compris la récursivité au lieu des boucles impératives). Ensuite, l’ordre opérationnel des détails de la mise en œuvre n’a pas d’impact (c.-à-d. Réparti globalement ) sur la cohérence de la sémantique de niveau supérieur. Par exemple, l’ordre d’évaluation (et théoriquement aussi la duplication) des formules de la feuille de calcul n’a aucune importance car les sorties ne sont pas copiées dans les entrées avant que toutes les sorties aient été calculées, c’est-à-dire analogues aux fonctions pures.

C, Java, C ++, C #, PHP et JavaScript ne sont pas particulièrement déclaratifs. La syntaxe de Copute et la syntaxe de Python sont couplées de manière plus déclarative aux résultats escomptés , c.-à-d. La sémantique syntaxique cohérente qui élimine les parasites afin que l’on puisse facilement comprendre le code après l’avoir oublié. Copute et Haskell imposent le déterminisme de la sémantique opérationnelle et encouragent « ne pas se répéter » (DRY), car ils ne permettent que le paradigme fonctionnel pur.


2 Même lorsque nous pouvons prouver la sémantique d’un programme, par exemple avec le langage Coq, cela se limite à la sémantique exprimée dans le typage , et le typage ne peut jamais capturer toute la sémantique d’un programme, même pour les langues pas Turing complet, par exemple avec HTML + CSS, il est possible d’exprimer des combinaisons incohérentes qui ont donc une sémantique non définie.

3 De nombreuses explications prétendent à tort que seule la programmation impérative comporte des instructions ordonnées syntaxiquement. J’ai clarifié cette confusion entre la programmation impérative et fonctionnelle . Par exemple, l’ordre des instructions HTML ne réduit pas la cohérence de leur signification.


Edit: J’ai posté le commentaire suivant sur le blog de Robert Harper:

en functional programming … la plage de variation d’une variable est un type

Selon la façon dont on distingue la functional programming de la programmation impérative, votre «assignable» dans un programme impératif peut aussi avoir un type lié à sa variabilité.

La seule définition non embrouillée que j’apprécie actuellement pour la functional programming est a) les fonctions d’objects et de types de première classe, b) la préférence pour les récursions sur les boucles et / ou c) les fonctions pures, c’est-à-dire du programme lorsqu’il est mémorisé ( la functional programming parfaitement pure n’existe donc pas dans une sémantique dénotationnelle générale due aux impacts de la sémantique opérationnelle, par exemple l’allocation de mémoire ).

La propriété idempotent d’une fonction pure signifie que l’appel de fonction sur ses variables peut être substitué par sa valeur, ce qui n’est généralement pas le cas pour les arguments d’une procédure impérative. Les fonctions pures semblent être déclaratives par rapport aux transitions d’état non composées entre les types d’entrée et de résultat.

Mais la composition des fonctions pures ne conserve pas une telle cohérence, car il est possible de modéliser un processus impératif d’effet secondaire (état global) dans un langage de programmation fonctionnel pur, par exemple l’IOMonad de Haskell et, de plus, tout langage de programmation purement fonctionnel Turing.

Comme je l’ai écrit en 2012, ce qui semble correspondre à un consensus similaire dans votre récent blog , cette programmation déclarative est une tentative de capturer l’idée que la sémantique prévue n’est jamais opaque. Des exemples de sémantique opaque sont la dépendance à l’ordre, la dépendance à l’effacement de la sémantique de niveau supérieur au niveau de la couche sémantique opérationnelle (par exemple, les convertisseurs ne sont pas des conversions et les génériques réifiés limitent la sémantique supérieure ). correct) par le langage de programmation.

J’ai donc conclu que seuls les langages complets non Turing peuvent être déclaratifs.

Ainsi, un atsortingbut non ambigu et distinct d’un langage déclaratif pourrait être que son résultat peut être prouvé comme obéissant à un ensemble énumérable de règles génératives. Par exemple, pour tout programme HTML spécifique (en ignorant les différences dans les manières dont les interpréteurs divergent) qui n’est pas scripté (c.-à-d. Qu’il n’est pas terminé), sa variabilité en sortie peut être énumérée. Ou plus succinctement, un programme HTML est une fonction pure de sa variabilité. Idem un tableur est une fonction pure de ses variables d’entrée.

Il me semble donc que les langages déclaratifs sont l’antithèse de la récursion sans limite , c’est-à-dire que, selon le second théorème d’incomplétude de Gödel, les théorèmes d’autoréférencement ne peuvent être prouvés.

Lesie Lamport a écrit un conte de fées sur la manière dont Euclid aurait pu contourner les théorèmes d’incomplétude de Gödel appliqués aux preuves mathématiques dans le contexte du langage de programmation par la congruence entre types et logique (correspondance Curry-Howard, etc.).

J’ai affiné ma compréhension de la programmation déclarative depuis décembre 2011, date à laquelle j’ai répondu à cette question. Ici suit ma compréhension actuelle.

La version longue de ma compréhension est détaillée sur ce lien , que vous devriez lire pour mieux comprendre le résumé que je vais vous fournir ci-dessous.

La programmation impérative est l’endroit où l’état mutable est stocké et lu, ainsi la commande et / ou la duplication des instructions du programme peuvent altérer le comportement (sémantique) du programme (et même provoquer un bogue, par exemple un comportement involontaire).

Dans le sens le plus naïf et extrême (que j’ai affirmé dans ma réponse précédente), la programmation déclarative (DP) évite tout état mutable stocké, ainsi la commande et / ou la duplication des instructions du programme NE peuvent PAS altérer le comportement (sémantique) du programme .

Cependant, une définition aussi extrême ne serait pas très utile dans le monde réel, car presque tous les programmes impliquent un état mutable stocké. L’ exemple de feuille de calcul est conforme à cette définition extrême de DP, car le code de programme complet est exécuté complètement avec une copie statique de l’état d’entrée, avant que les nouveaux états ne soient stockés. Ensuite, si un état est modifié, cela se répète. Mais la plupart des programmes du monde réel ne peuvent pas être limités à un modèle monolithique de changements d’état.

Une définition plus utile du DP est que la commande et / ou la duplication des instructions de programmation ne modifient aucune sémantique opaque. En d’autres termes, il n’y a pas de changements aléatoires cachés dans la sémantique: tout changement dans l’ordre des instructions du programme et / ou la duplication entraîne uniquement des modifications intentionnelles et transparentes du comportement du programme.

L’étape suivante consisterait à parler des modèles de programmation ou des paradigmes qui aident à la DP, mais ce n’est pas la question ici.

La programmation déclarative consiste à programmer avec des déclarations, c’est-à-dire des phrases déclaratives. Les phrases déclaratives ont un certain nombre de propriétés qui les distinguent des phrases impératives. En particulier, les déclarations sont:

  • commutative (peut être réorganisé)
  • associatif (peut être regroupé)
  • idempotent (peut répéter sans changement de sens)
  • monotone (les déclarations ne soustraient pas d’informations)

Un point pertinent est que ce sont toutes des propriétés structurelles et sont orthogonales au sujet. Déclaratif ne concerne pas “What vs. How” . Nous pouvons déclarer (représenter et contraindre) un “comment” aussi facilement que nous déclarons un “quoi” . La déclaration concerne la structure et non le contenu. La programmation déclarative a un impact significatif sur la façon dont nous réduisons et réorganisons notre code, et comment nous le modélisons en sous-programmes, mais pas tellement sur le modèle de domaine.

Souvent, nous pouvons convertir des impératifs en déclarations en ajoutant un contexte. Par exemple de “Tournez à gauche. (… attendez-le …) Tournez à droite.” à “Bob tournera à gauche à l’intersection de Foo et Bar à 11h01. Bob tournera à droite à l’intersection de Bar et Baz à 11h06.” Notez que dans ce dernier cas, les phrases sont idempotentes et commutatives, tandis que dans le premier cas, la réorganisation ou la répétition des phrases modifierait considérablement le sens du programme.

En ce qui concerne les monotones , les déclarations peuvent append des contraintes qui soustraient les possibilités . Mais les contraintes ajoutent encore des informations (plus précisément, les contraintes sont des informations). Si nous avons besoin de déclarations variant dans le temps, il est typique de modéliser cela avec une sémantique temporelle explicite – par exemple, de “la balle est plate” à “la balle est plate au temps T”. Si nous avons deux déclarations contradictoires, nous avons un système déclaratif incohérent, bien que cela puisse être résolu en introduisant des contraintes souples (priorités, probabilités, etc.) ou en exploitant une logique paraconsistante.

Voici un exemple.

En CSS (utilisé pour le style des pages HTML), si vous voulez qu’un élément d’image ait 100 pixels de haut et 100 pixels de large, vous déclarez simplement que c’est ce que vous voulez:

 #myImageId { height: 100px; width: 100px; } 

Vous pouvez considérer le CSS comme un langage déclaratif de “feuille de style”.

Le moteur de navigateur qui lit et interprète ce CSS est libre de faire apparaître l’image aussi grande et aussi large qu’elle le souhaite. Différents moteurs de navigateurs (par exemple, le moteur pour IE, le moteur pour Chrome) implémenteront cette tâche différemment.

Leurs implémentations uniques ne sont bien sûr pas écrites dans un langage déclaratif mais dans un langage procédural comme Assembly, C, C ++, Java, JavaScript ou Python. Ce code est un ensemble d’étapes à effectuer étape par étape (et peut inclure des appels de fonctions). Cela peut faire des choses comme interpoler les valeurs de pixels et effectuer un rendu à l’écran.

C’est une méthode de programmation basée sur la description de ce que quelque chose devrait faire ou être au lieu de décrire comment cela devrait fonctionner.

En d’autres termes, vous n’écrivez pas d’algorithmes faits d’expressions, vous ne faites que mettre en page comment vous voulez que les choses soient. Deux bons exemples sont HTML et WPF.

Cet article de Wikipedia est un bon aperçu: http://en.wikipedia.org/wiki/Declarative_programming

Décrire à un ordinateur ce que vous voulez, pas comment faire quelque chose.

Cela peut sembler étrange, mais j’appendais Excel (ou n’importe quel tableur) à la liste des systèmes déclaratifs. Un bon exemple de ceci est donné ici .

Je l’expliquerais comme DP est un moyen d’exprimer

  • Une expression de but , les conditions pour – ce que nous recherchons. Y a-t-il un, peut-être ou plusieurs?
  • Quelques faits connus
  • Règles qui étendent les faits connus

… et où un moteur de déduction fonctionne généralement avec un algorithme d’ unification pour trouver les objectives.

La programmation déclarative est “l’acte de programmation dans des langues conformes au modèle mental du développeur plutôt qu’au modèle opérationnel de la machine”.

La différence entre la programmation déclarative et impérative est bien illustrée par le problème de l’parsing syntaxique des données structurées.

Un programme impératif utiliserait des fonctions mutuellement récursives pour consumr des entrées et générer des données. Un programme déclaratif exprimerait une grammaire qui définit la structure des données pour pouvoir ensuite les parsingr.

La différence entre ces deux approches est que le programme déclaratif crée un nouveau langage plus proche du modèle mental du problème que son langage hôte.

Autant que je sache, il a commencé à être utilisé pour décrire des systèmes de programmation tels que Prolog, car prolog est censé (soit) dire déclarer les choses de manière abstraite.

Cela signifie de plus en plus peu, car il correspond à la définition donnée par les utilisateurs ci-dessus. Il devrait être clair qu’il existe un fossé entre la programmation déclarative de Haskell et la programmation déclarative de HTML.

Quelques autres exemples de programmation déclarative:

  • Marquage ASP.Net pour la liaison de données. Il dit simplement “remplissez cette grid avec cette source”, par exemple, et le laisse au système pour savoir comment cela se produit.
  • Expressions Linq

La programmation déclarative est intéressante car elle peut vous aider à simplifier votre modèle mental * et, à terme, elle pourrait être plus évolutive.

Par exemple, supposons que vous ayez une fonction qui fait quelque chose à chaque élément d’un tableau ou d’une liste. Le code traditionnel ressemblerait à ceci:

 foreach (object item in MyList) { DoSomething(item); } 

Pas grand chose là-bas. Mais que faire si vous utilisez la syntaxe plus déclarative et définissez à la place DoSomething () comme une action? Alors vous pouvez le dire de cette façon:

 MyList.ForEach(DoSometing); 

C’est bien sûr plus concis. Mais je suis sûr que vous avez plus de soucis que de simplement enregistrer deux lignes de code ici et là. Performance, par exemple. L’ancienne façon, le traitement devait être fait en séquence. Que se passe-t-il si la méthode .ForEach () vous permet de signaler qu’elle peut gérer le traitement en parallèle, automatiquement? Maintenant, tout à coup, vous avez rendu votre code multithread d’une manière très sûre et vous n’avez modifié qu’une seule ligne de code. Et, en fait, il existe une extension pour .Net qui vous permet de faire exactement cela.

  • Si vous suivez ce lien, cela vous amène à un article de blog d’un de mes amis. Le post entier est un peu long, mais vous pouvez faire défiler jusqu’à l’intitulé intitulé “Le problème” _et le reprendre sans problème. *

Cela dépend de la façon dont vous soumettez la réponse au texte. Dans l’ensemble, vous pouvez regarder le programme à un certain sharepoint vue, mais cela dépend de l’angle sous lequel vous regardez le problème. Je vais commencer avec le programme: bus, voiture, temps, hauteur

Encore une fois, cela dépend de la nature du problème. You might have to shorten it due to the programme. Hope this helps and need the feedback if it does not. Je vous remercie.