Dans les collèges et dans des manuels scolaires à algorithme, il est assez courant que l'enseignant et l'auteur d'expliquer le flux de contrôle en pseudo-code. Avec l'avènement des langues plus expressives telles Python et HASKELL parmi d'autres, est-il raisonnable que les collèges basculent d'expliquer des algorithmes via l'une de ces langues?
Le seul avantage du pseudo-code, je peux penser, c'est que c'est prétendument linguistique-agnostique. Mais ce n'est pas. Certains pseudo-code utilisent une approche impérative, un autre pseudo-code semble fonctionnel. Les auteurs empruntent simplement une sémantique de tout langage de programmation qu'ils sont à l'aise en utilisant ou de décrire simplement la sémantique en langage naturel. Donc, si la pseudo-code n'est pas réellement linguistique-agnostique, quel est l'avantage de l'utiliser alors? Ne serait-il pas préférable d'utiliser une langue existante?
Non. Le point de pseudo-code est qu'il n'a pas à compiler. Je peux rapidement briller sur des détails non pertinents. En revanche, même des langues qui ressemblent à un pseudocode à la première vue d'avoir des détails très intuitifs qui perturbaient simplement de l'algorithme. Prenons par exemple Quicksort à Haskell:
qs :: Ord a => [a] -> [a]
qs [] = []
qs (pivot:xs) = (qs smaller) ++ pivot:(qs larger)
where smaller = [x | x <- xs, x <= pivot]
larger = [x | x <- xs, x > pivot]
ou le même en python:
def qs(array):
if not array:
return []
pivot = array[0]
xs = array[1:]
smaller = [x for x in xs if x <= pivot]
larger = [x for x in xs if x > pivot]
return qs(smaller) + [pivot] + qs(larger)
L'avantage dans les deux cas est qu'il s'agit de code exécutable et, en tant que tel, peut être testé, Tipechecked et joué avec des étudiants. Cependant, ils incluent tous les deux des détails syntaxiques qui distraient. Les étudiants seront généralement mieux servis par pseudocode qui illustre l'intention de l'algorithme, et non des détails de mise en œuvre:
algorithm QUICKSORT(array)
return [] if array is empty
pivot ← array[0]
xs ← array[1, ...] -- the rest of the array without the pivot
smaller ← [x | x ∈ xs, x <= pivot] -- all smaller or equal elements
larger ← [x | x ∈ xs, x > pivot] -- all larger elements
return [QUICKSORT(smaller)..., pivot, QUICKSORT(larger)...]
Différences notables:
Je peux simplement créer une syntaxe de compréhension de la liste qui ressemble à des mathématiques plutôt que de devoir expliquer pourquoi Python a un for
et if
ici.
Je n'ai pas besoin d'expliquer la syntaxe de cette langue pour la concaténation de la liste. Pourquoi Python utilise +
une addition? Quel est :
à Haskell? Je peux simplement choisir une syntaxe qui obtient le point sur plus clairement.
la signature de type Ord a => [a] -> [a]
est juste un détail de mise en œuvre. Tandis que possible dans ce cas, les signatures de type parfois requises par Haskell peuvent être absurdes.
Je n'ai pas à expliquer pourquoi Python considère que les collections vides doivent être fausses et quoi array[1:]
est censé vouloir dire.
J'évite les étudiants intelligents indiquant que je devrais vraiment utiliser yield
dans le Python exemple.
Haskell est nul pour expliquer des structures de données mutables telles que les tables de hachage, les arbres RB, ....
Les choses commencent à obtenir très spécifiques à la langue une fois que nous avons besoin d'enregistrements complexes pour exprimer nos algorithmes. Par exemple. Le système d'objet de Python a quelques surprises qui distraient simplement.
Cela dit, il peut être très utile d'utiliser l'une de ces langues en plus de la pseudocode, étiquetez simplement avec précaution ce qui est quoi.
Qu'est-ce qui est réel?
Parce que réel est uniquement en définition à un interpréteur.
Le mandarin est-il plus ou moins réel que l'anglais?
Si réel n'est même pas la question. Permet de reformuler:
Pourquoi le pseudo code est-il utilisé au lieu d'une langue formelle?
Un simple diagramme de Venn peut mettre en évidence le problème facilement. L'ensemble de tous les humains qui sont anglais et Les enceintes mandarin sont le sous-ensemble de l'anglais ou Haut-parleurs mandarin. Parce que cela prend des efforts pour obtenir des compétences dans une langue dans une langue, l'intersection est généralement beaucoup plus petite que l'Union.
Le manuel sur la programmation peut supposer que vous comprenez au moins une langue naturelle, la langue du manuel est écrite. C'est généralement sûr de la présumer que, sinon, un manuel plus lisible différent aurait été sélectionné. Après tout apprendre, une langue est assez difficile - deux sont plus difficiles.
Cela donne la première raison d'utiliser un pseudo code. Il optimise le public qui pourrait facilement lire le livre. Cela se fait en suivant des conventions de langage établies déjà trouvées dans la langue naturelle. Dites des recettes de la cuisson, des formules mathématiques, etc. Tout écart peut être comblé par une explication de langage naturelle rapide ou à défaut d'un recours final à notre système visuel avec des images.
Quant à la raison pour laquelle la langue commune ne pouvait pas être le langage de programmation. Je vous laisse pour déterminer combien de mandarin (ou de toute langue que vous ne parlez pas déjà) que vous avez appris en lisant un livre sur la programmation écrite avec des exemples donnés dans un langage de programmation familier.
Quel manuel atteint
Quant à la deuxième raison, considérez ce qu'un manuel doit atteindre:
Pourquoi programme
La plupart du livre doivent vous convaincre de la raison pour laquelle vous voudriez apprendre et utiliser cette langue extraterrestre, soit une langue similaire. Cela signifie discuter de l'essence de la programmation elle-même.
La majeure partie de cela n'a rien à voir avec les machines elles-mêmes, c'est principalement une discussion sur la manière dont la viande devrait fonctionner afin de créer un programme. C'est assez complexe car il doit montrer pourquoi nous allions relier nos objectifs de l'espace humain, pour programmer des problèmes d'espace et s'efforcer de les résoudre.
décrivant un programme
La deuxième réussite du manuel décrit une langue. Maintenant, la plupart des langues de programmation peuvent être décrites avec une grammaire et quelques règles sémantiques. Sur l'extrémité peu profonde figurent des langues comme [~ # ~] JSON [~ # ~ ~] qui peut être définie assez complètement dans trois ou deux pages. Des langues plus complexes nécessitent une spécification plus importante, mais la plupart n'ont pas besoin d'une compréhension totale afin d'être utiles. Ce que ces descriptions sont cependant sont pseudo-code. Ils spécifient la langue formelle en termes de langage naturel. La différence est que ces pseudo-codes sont spécifiés à l'avance.
Maintenant, étant donné que même des langues formelles sont elles-mêmes (exécutables) des pseudo codes, la question est la plus importante lorsque vous décrivez un algorithme? le contexte suivant.
À aucun moment, la langue que l'algorithme est écrit importante. Si quelque chose, seules quelques opérations clés sont essentielles pour le succès des algorithmes. Donc, la question devient alors:
Étant donné que l'apprentissage d'une langue est difficile et que le lecteur doit avoir appris/apprendre une langue afin de comprendre l'algorithme, comme l'auteur d'un manuel, que devriez-vous demander au lecteur?
J'irais contre le grain ici et affirmerais que oui, les livres et les tutoriels doivent utiliser pseudocode qui repose sur de véritables langues de haut niveau au lieu d'inventer une nouvelle syntaxe de pseudocode totalement nouvelle.
Cependant, j'avais également averti tous les auteurs et les lecteurs que lorsqu'ils sont utilisés dans ce contexte, cela devrait être pseudo-version de la langue réelle et les auteurs doivent être conscients de ne pas être trop stricts à la suite de la syntaxe et des limites de la langue. Au lieu de cela, les auteurs devraient réfléchir soigneusement à propos de ce qu'ils essaient de communiquer avec l'extrait de communiquer et de cacher des détails non pertinents derrière des appels de fonction et/ou des commentaires plutôt que de s'efforcer d'une implémentation ou d'un code complet, en réellement compilable, idiomatique pour la langue de base choisie pour la langue de base choisie. .
Les auteurs devraient prendre une liberté créatrice sur la langue pour que leur point de vue de manière à ce que même quelqu'un qui sait que les bases de la langue puissent toujours comprendre l'essentiel de l'extrait, tandis que ceux qui recherchent une sémantique plus précise peuvent faire référence à la documentation ou à la relèvement de la langue. leurs connaissances antérieures sur la langue pour remplir les détails.