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?
literate-programmingbalise sur StackOverflow. Il y a plus de contenu, mais pas beaucoup.Réponses:
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.
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.
la source
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.
la source
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:
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):
la source
turn left then rightoupaint wall with red, green and yellow: docs.codehaus.org/display/GROOVY/…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.
la source