Programmation alphabétisée, bonne / mauvaise méthodologie de conception


10

J'ai récemment trouvé le concept de programmation alphabétisée . Et je l'ai trouvé plutôt intrigant. Pourtant, je n'ai pas été confronté à des affirmations selon lesquelles c'est une mauvaise façon de structurer un programme. Il ne semble pas avoir couvert beaucoup d'endroits. Pas même ici, je ne pouvais trouver de questions à ce sujet.

Ma question ne porte pas sur ses défauts ni sur la manière de gérer la documentation. Je considère la documentation comme un effet secondaire de ce que cela signifierait pour le flux de programmation alphabétisée. Je sais que la conception était à l'origine destinée à faciliter la documentation ainsi que le concept de flux de programmation avant .

Le concept de diviser le problème en problèmes basés sur de petites phrases semble être vraiment une idée brillante. Il facilitera ainsi la compréhension du déroulement du programme.

Une conséquence de la méthode de conception lettrée est également que le nombre de fonctions requises sera limité à l'imagination du programmeur. Au lieu de définir une fonction pour une certaine tâche, elle pourrait être créée en tant que scrapdans la méthode lettrée. Cela produirait l'insertion automatique du code, au lieu d'une compilation de fonctions distinctes et la nécessité ultérieure d'une étape d'optimisation de compilation inter-procédurale pour obtenir la vitesse équivalente. En fait, la première tentative de Donald E. Knuth a montré un temps d'exécution inférieur, de ce fait même. Je sais que des compilateurs peuvent être faits pour beaucoup de cela, mais ce n'est pas ma préoccupation.

Je voudrais donc obtenir des commentaires sur la raison pour laquelle on devrait considérer cela comme une mauvaise / bonne méthodologie de conception?


2
Zeroth, j'ai créé la balise de programmation alphabétisée et ajouté un résumé basé sur l'article Wikipedia. Aidez-nous à développer le wiki du tag avec des informations pertinentes.
yannis

@YannisRizos Je vais l'ajouter ici, je n'ai pas de privilèges d'édition.
zeroth

1
Eh bien, moi non plus :) J'ai ajouté quelques ressources (l'article wikipedia et les liens dans votre question), elles apparaîtront lorsque la modification sera révisée par les pairs et acceptée (?!). C'est une approche intrigante, et puisque vous êtes déjà en train de l'explorer, revenez et améliorez le wiki des balises chaque fois que vous trouvez quelque chose que vous pensez qu'il vaut la peine d'y mentionner.
yannis

1
Je recommanderais à l'auteur du site Literate Programming de visiter le site UX stackexchange - les couleurs sont vraiment mauvaises pour la lecture.
Danny Varod

1
Pour info, il y a aussi une literate-programmingbalise sur StackOverflow. Il y a plus de contenu, mais pas beaucoup.
Ross Patterson

Réponses:


9

Cela entraînerait l'insertion automatique du code, au lieu d'une compilation de fonctions distinctes et la nécessité ultérieure d'une étape d'optimisation de compilation inter-procédurale pour obtenir la vitesse équivalente

Ce n'est pas pertinent. Cela fait des décennies. Vous pouvez le supprimer de la question, car cela n'a aucun sens avec les compilateurs modernes de renverser leurs optimiseurs.

Je voudrais donc obtenir des commentaires sur la raison pour laquelle on devrait considérer cela comme une mauvaise / bonne méthodologie de conception?

Il n'y a aucun inconvénient à l'alphabétisation. (Je m'attends à des dizaines de -1 voix pour ce sentiment.) En tant que pratiquant, je n'ai jamais vu de problèmes.

Il y a certains arguments contre lesquels tous reviennent à "programmer dans un langage de plus haut niveau peut être renversé en modifiant le code résultant". Droite. De la même manière que la programmation en C ++ est renversée en ajustant le .ofichier qui est produit. C'est vrai, mais hors de propos.

Écrire des programmes alphabétisés signifie simplement combiner une conception détaillée et détaillée (au niveau du code) dans un seul document, écrit avec un ensemble d'outils approprié qui produit des fichiers conviviaux pour le compilateur et des fichiers conviviaux.

Lorsque Knuth a inventé la programmation alphabétisée, les langages OO traditionnels n'existaient pas. Par conséquent, une grande partie des outils Web et tissage d'origine lui ont permis de créer des définitions de classe pour les types de données abstraits.

Une grande partie de cela n'est plus pertinente de nos jours. Les outils de programmation lettrés peuvent être assez simples s'ils se concentrent sur des langages de programmation orientés objet (ou fonctionnels) de haut niveau modernes. Il y a moins besoin de solutions de contournement élaborées en raison des limitations de C (ou Pascal ou Assembleur).

L'approche de l'écriture de programmes alphabétisés n'est pas différente de l'approche de l'écriture de programmes analphabètes. Cela nécessite toujours une conception soignée, des tests unitaires et un codage soigné. Le seul travail supplémentaire est d'écrire des explications en plus d'écrire du code.

Pour cette seule raison - la nécessité d'écrire des explications cohérentes - la programmation alphabétisée est difficile pour certains programmeurs. Il y a un bon nombre de programmeurs qui réussissent (leur code passe tous les tests unitaires, est soigné et facile à comprendre) mais ne semble pas écrire une phrase cohérente dans leur langue maternelle. Je ne sais pas pourquoi c'est vrai.

Il y a un très grand nombre de programmeurs qui semblent ne réussir que marginalement et seulement par accident. (Il y a suffisamment de mauvaises questions dans Stack Overflow qui indiquent que de nombreux programmeurs ont du mal à saisir même les principes fondamentaux.) Pour les programmeurs qui posent des questions de débordement de pile largement incohérentes, nous savons qu'ils ne peuvent pas vraiment faire un bon travail de programmation alphabétisée, car ils peuvent ne fais pas un bon travail de programmation.


7
Un grand nombre de programmeurs sont à peine cohérents lorsqu'ils expliquent quelque chose sur n'importe quel support, formel ou informel, qu'il s'agisse de programmation alphabétisée, d'écriture de commentaires ou même d'un e-mail. C'est un logiciel miracle qui fonctionne du tout :)
Andres F.

3

L'aspect le plus important de la programmation lettrée (ou même juste de bons commentaires) pour moi n'est pas tant qu'il fournit de la documentation, mais plutôt qu'il indique l'intention du programmeur. En connaissant l'intention déclarée, vous pouvez immédiatement juger si le code qui le suit fait vraiment ce qu'il devrait. Sans intention, vous devez partir de l'hypothèse que le code est correct, puis prouver qu'il est vrai ou faux par induction - ce qui est plus épuisant et prend plus de temps car il nécessite souvent de se familiariser également avec tout le code environnant.

Ainsi, l'intention déclarée permet souvent à d'autres personnes peu familières avec le code de se lancer rapidement et de trouver des erreurs sans avoir à connaître le contexte plus large qui l'entoure.

Et bien sûr, cela vous aide à apprendre plus rapidement le flux de base et la conception du code, car un anglais simple est souvent plus intuitif que l'arithmétique des pointeurs pour la plupart des gens.


1

Bien que relativement nouveau au concept de programmation littéraire moi-même (et il est donc probable que je manque complètement le bateau), il semble très bien s'aligner sur le concept d'une DSL .

L'idée derrière une DSL est de distiller un domaine de problèmes en une grammaire simple, orientée vers le langage naturel, qui peut être utilisée pour construire des algorithmes pour résoudre ces problèmes.

Pour moi, cette même idée, ou du moins son fondement, est la même ou du moins étroitement liée à la programmation alphabétisée.

Dans le monde groovy, par exemple, il y a une forte pression pour utiliser les DSL plus régulièrement et pour créer de nouveaux DSL pour résoudre les problèmes courants. Cette poussée provient à la fois des outils du langage (constructeurs faciles), ainsi que des bibliothèques principales prenant en charge une API basée sur DSL.

Étant donné que la tendance, au moins dans ce coin du monde, est vers la programmation alphabétisée, je dirais que c'est une bonne méthodologie à rechercher.

Malheureusement, le niveau de réflexion nécessaire pour créer un bon dsl dépasse souvent la plupart des programmeurs, d'après ce que j'ai vu. Je sais que je me bats personnellement avec certains des concepts nécessaires de temps en temps. C'est peut-être cette difficulté qui a empêché de telles techniques de gagner une adoption plus large.

C'est votre cas classique lorsque l'utilisation de l'outil est une chose, mais sa création est à un tout autre niveau.


Pour développer un peu mon point de vue, ce n'est pas beaucoup que les DSL sont la même chose que la programmation alphabétisée, mais plutôt qu'ils rendent la programmation alphabétisée beaucoup plus possible . Surtout quand ce sont des DSL en langage naturel .

Dans la version 1.8 de groovy, la capacité DSL en langage naturel a été considérablement améliorée avec l'ajout de chaînes de commande plus puissantes.

Par exemple, les lignes de code suivantes sont de la programmation , pas seulement des pseudo-phrases:

drink tea with sugar and milk
move left by 30.centimeters
sendFrom "Guillaume" to "Jochen"
send from: "Jochen" to "Lidia"
Email.from "Lidia" to "Guillaume" withBody "how are you?"
contact.name "Guillaume" age 33
move left by 30.centimeters
sell 100.shares of MSFT
take 2.pills of chloroquinine in 6.hours
blend red, green of acrylic
artist.paint "wall" with "Red", "Green", and: "Blue" at 3.pm
wait 2.seconds and execute { assert true }
concat arr[0] with arr[1] and arr[2]
developped with: "Groovy" version "1.8-beta-2"

Remarque: l'exemple de code provient du blog de Guillaume Laforge

L'idée centrale de la programmation alphabétisée est que le langage naturel est plus compréhensible pour les humains et c'est ce qui compte. Les capacités DSL en langage naturel de Groovy en font une réalité beaucoup plus proche, à mon avis. Surtout lorsque ces DSL sont utilisées pour créer des règles métier pour une application.

Être capable de «coder» les composants critiques d'un système en utilisant le langage naturel est l'essence même de la programmation alphabétisée. Devoir entremêler le langage naturel avec des morceaux de code est une forme bâtarde de programmation lettrée. Bien qu'utile, je pense que les DSL en langage naturel qui vous permettent d'utiliser le langage naturel comme code lui - même sont un énorme bond en avant.

L'élargissement de la capacité de programmation en général est la prochaine étape du processus, mais dans une large mesure, les outils pour le faire sont déjà en place. Oui, il n'y a pas encore de DSL "générale", mais pour les petits domaines, la capacité est là.

Pour plus d'exemples de ceci en action (sans ordre particulier):


2
Point de vue intéressant. De mon point de vue, cela ne correspond pas du tout très bien à une DSL. Étant donné que la programmation alphabétisée est dans un langage non DSL. Et les outils ne ressemblent pas non plus à une DSL. Ils ne sont pas orientés vers le domaine problématique. Pourriez-vous donner un exemple de la façon dont vous pensez que la programmation alphabétisée est comme une DSL? Un lien ou une référence à un exemple pourrait aider à clarifier votre réponse.
S.Lott

Un exemple de ceci est les chaînes de commandes dans Groovy 1.8 qui vous permettent de "programmer" avec des choses comme turn left then rightou paint wall with red, green and yellow: docs.codehaus.org/display/GROOVY/…
cdeszaq

@ S.Lott - Je conviens qu'il y a certainement une différence entre les DSL et la programmation alphabétisée, mais je pense que les DSL peuvent être un outil pour réaliser une véritable programmation alphabétisée où vous pouvez taper un langage naturel et le faire exprimer l'algorithme souhaité. Pour moi, mélanger langage naturel et code est une forme d'alphabétisation bâtarde.
cdeszaq

"vous pouvez taper un langage naturel et le faire exprimer l'algorithme souhaité" est peu probable au mieux. Il y a des antécédents, une justification, une preuve d'exactitude, des assertions de complexité (big- O ) et beaucoup de documentation de support non alogrithmique qui ne fait pas partie d'un schéma DSL. Je ne suis pas sûr d'être d'accord avec le parallèle maintenant que vous l'avez clarifié.
S.Lott

1
msgstr "explication de la logique du programme". Pas la logique elle-même. Mais une explication. La logique est rarement explicite. Il ne contient jamais de preuve d'exactitude (c'est difficile et parfois impossible). Il contient rarement une justification de la complexité du big-O. Et cela explique rarement les alternatives qui sont soit des performances plus faibles soit plus de mémoire. Donc, je dirais que DSL est bien loin de "l'explication".
S.Lott

-2

Je pense que c'est une erreur de penser que LP est une sorte de DSL. Parce que LP est - un journal (avec des diagrammes, des schémas, des fragments de pseudo-code, c'est-à-dire des morceaux) du programme développé, c'est l'architecture et ainsi de suite ... C'est absolument analogue au cahier papier - beaucoup de développeurs les utilisent mais après avoir fini le programme - abandonnez vos cahiers, papiers ...

Il y a longtemps, chaque physicien, astonome, chimiste / alchimiste, mathématicien a ses propres cahiers, manuscrits avec de nombreux schémas, informations nécessaires, tableaux, et sans eux, vous pouvez comprendre ou répéter leur expérience réussie, ses résultats. Et toujours entre de tels peuples, il existe des chasseurs de carnets / carnets.

Aujourd'hui, de nombreux programmeurs écrivent du code, et parfois ils ajoutent des commentaires! Le programme Byt n'est pas seulement du code - ce sont des pensées, des idées, de l'imagination, des concepts et lorsque le nouveau développeur hérite du code étranger - il brise souvent toutes les idées et les concepts, crée différentes "failles" et "portes dérobées", j'espère que vous me comprenez :)

Donc, la principale exigence pour LP (comme outil!) Est aussi de permettre à tous ces éléments avec une syntaxe simple, légère et lisible. J'ai essayé de nombreux outils LP, mais aujourd'hui je développe moi-même - NanoLP ( http://code.google.com/p/nano-lp/ ) qui vise à répondre à cette demande.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.