10
votes

Lecture de code source à haute voix

Après avoir vu Cette question , je dois penser à la Divers défis auxquels les programmeurs aveugles sont confrontés et comment certains d'entre eux sont applicables même aux programmeurs axés. En particulier, le problème de la lecture du code source à haute voix me donne une pause. Je suis programmée depuis la majeure partie de ma vie et je fréquence des autres étudiants en programmation, le plus souvent en C ++ ou Java.

Il est de manière unique aggravant d'essayer de transmettre verbalement la syntaxe essentielle d'une expression C ++. L'enceinte doit donner soit une traduction idiomatique en anglais, soit une spécification complète du code dans la Longhande verbale, en utilisant des termes explicites mais lents tels que "parenthèse d'ouverture", "Bitwise et", et cetera. Aucune de ces solutions n'est optimale.

D'une part, une traduction idiomatique n'est utile qu'à un programmeur pouvant découvrir le code de programmation correspondant, ce qui n'est généralement pas le cas lors du tutorat d'un élève. À son tour, l'éducation (ou simplement une personne à la hauteur d'une personne à la hauteur d'un projet) est la situation la plus courante dans laquelle la source est lue à voix haute et il y a une très petite marge d'erreur.

D'autre part, une spécification littérale est aggravée lentement. Il faut beaucoup plus de temps à dire que la livre, inclure, le support d'angle gauche, iostream, support d'angle droit, nouvelle ligne "que pour taper #include . En effet, les programmeurs la plus expérimentés C ++ liraient cela simplement comme "incluent iostream", mais à nouveau, les programmeurs inexpérimentés abondent et les spécifications littérales sont parfois nécessaires.

Donc, j'ai eu une idée d'une solution potentielle à ce problème.

en C ++, il y a un ensemble fini de Mots-clés -63-et opérateurs -54, actualisation des opérateurs nommés et Traiter les opérateurs d'affectation du composé et le préfixe par rapport au postfix Auto-Incrément et décrémentez comme distinct. Il y a juste quelques types de types littéraux, un nombre similaire de symboles de regroupement et du point-virgule. Sauf si je me trompe complètement, c'est à ce sujet.

Alors ne serait-il pas possible de simplement attribuer une prononciation concise et unique à chacun de ces concepts distincts (y compris un pour WhitSpace, où il est requis) et aller de là? Les langages de programmation sont beaucoup plus réguliers que les langues naturelles. La prononciation pourrait donc être normalisée. Les haut-parleurs de tout langage serait capable de transmettre verbalement le code C ++ et due à la régularité et à la fixité de la langue, le logiciel de discours à texte pourrait être optimisé pour accepter le discours C ++ avec un degré de précision élevé. .

Donc, ma question est double: première, ma solution est réalisable; Et deuxièmement, quelqu'un d'autre a d'autres solutions potentielles? J'ai l'intention de prendre des suggestions d'ici et de les utiliser pour produire un papier formel avec un exemple de mise en œuvre de ma solution.


6 commentaires

Cela semble intéressant, une chose à garder à l'esprit: toutes les prononciations ne sont facilement prononcables dans tous les pays.


En raison de la petite langue, l'inventaire phonémique ne peut comprendre que des sons communs ou des sons faciles à approcher. Cinq voyelles pure et peu d'arrêts exprimés et inébranlables et des infrètes offrent plus que suffisamment de mots potentiels.


La vidéo suivante est absolument hilarante, mais convient parfaitement à ce sujet: YouTube.com/watch?v=peExpnype5s .


@Makis: Malheureusement, je suis coupable d'essayer cela.


Vous ne voyez rien de mal à suggérer que «à sauver l'étudiant devoir apprendre la langue mon code est écrit assez bien pour comprendre le code que je lis à voix haute, je propose de lui apprendre une autre < / i> langue dans laquelle je peux lire mon code source "? ;)


@jalf: Je suppose que ma pensée divergait en deux moitiés. La langue supplémentaire serait utile entre les programmeurs expérimentés et les débutants, mais oui, il impose une plus grande surcharge d'enseignement. Il ne convient donc pas comme un outil d'introduction. Au moins, ce serait générique et interlingual. Pour l'utilisation de l'anglais uniquement, des mots dérivés d'anglais tels que «LPAR» et «bande» pourraient être utilisés à la place des équivalents internationaux, auquel cas il serait beaucoup plus débutant.


3 Réponses :


4
votes

au lieu de créer de nouveaux "mots" pour les décrire, car des choses telles que "Inclure", vous pouvez simplement le préfixer avec "mot-clé" lorsque vous le disiez à voix haute. Vous pouvez utiliser des mots / des phrases communément connues pour dire d'autres parties également. Comme pour tout nouveau programmeur, vous devez littéralement tout décrire de toute façon, donc je ne pense pas que cela nécessite une attention particulière. Je pense que la création de nouveaux mots est la méthode plus difficile ...

Donc, par exemple: P>

if (number < keyword)


2 commentaires

Plus un parce que votre solution est pragmatique et optimale sans la contrainte d'internationalisation. Je ne vois pas pourquoi plus de langages de programmation ne prennent pas en charge la programmation localisée (python chinoise) ou neutre de langue (APL).


Merci. Aussi, oups. J'ai tapé "internalisation". Je n'ai pas je. haha. Vérification orthographique ne corrige pas tout :)



3
votes

Alors ne serait-il pas possible de simplement attribuer une prononciation concise et unique à chacun de ces concepts distincts (dont un pour WhitSpace, où il est requis) et aller de là? Les langages de programmation sont beaucoup plus réguliers que les langues naturelles. La prononciation pourrait donc être normalisée

Peut-être, mais vous avez perdu de vue votre objectif. Le principe était que l'écoute de la personne pas connaissait déjà la langue. S'il le fait, nous pouvons simplement dire "inclure iostream" lorsque nous voulons dire #include ou "vecteur d'int" lorsque nous voulons dire std :: vecteur .

Votre principe était que l'écoute de la personne n'était pas assez familière avec la langue pour comprendre ce que vous avez lu à voix haute, sauf si vous lisez exactement ce qu'il dit.

Maintenant, inventant une nouvelle langue entière pour décrire les primitives qui se produisent dans votre code source ne résout pas le problème. Au lieu de cela, vous toujours devez lire tous les jetons syntaxiques (avec des prononciations plus simples, plus "standardisées", oui, mais ils doivent encore être lus à haute voix) et la personne qui écoute toujours < / em> ne vous comprendra pas, car s'ils ne connaissent pas assez bien assez bien pour comprendre "Inclure iostream", ils ne comprendront pas votre prononciation standardisée non plus. Et si vous allez leur apprendre votre prononciation, pourquoi vous déranger, quand vous auriez pu simplement leur apprendre à comprendre la syntaxe C ++ directement à la place?

Il y a aussi le problème racine que C ++ Code a tendance à se composer de < em> beaucoup de jetons syntaxiques. Prenez une ligne aussi simple que ceci: xxx

i compte 9 jetons. Pas l'un d'entre eux ne peut être omis. Si l'écoute de la personne ne comprend pas le code et la syntaxe assez bien pour comprendre une description de haut niveau, telle que "déclarer un vecteur d'int, nommé V", vous devrez ensuite lire les 9 jetons sous une forme. Même si vous proposez des noms plus simples que «Opérateur de résolution de l'espace de noms» et «moins de signe», vous devez toujours répertorier 9 noms de jeton. Ce qui est beaucoup de travail.

En bref, non, je ne pense pas que cela fonctionnerait. Premièrement, il est encore trop lourd, et deuxièmement, il préalcule des connaissances antérieures de la part de l'écoute de la personne, lorsque la motivation à cet égard était que la personne écoute était un étudiant sans les connaissances antérieures qui ont permis de faire valoir la connaissance. comprendre une description de haut niveau du code.


1 commentaires

Je suppose que alors qu'il y a deux côtés à ce problème. Les descriptions de haut niveau sont mieux adaptées aux débutants et aux programmeurs de bas niveau à des programmes expérimentés. Ces huit jetons pourraient facilement correspondre à seulement autant de syllabes, à condition que la bibliothèque standard soit également indexée, comme, par exemple, "SA NA VE LA I GA LI V SE", où "LI" est une particule indiquant que ce qui suit c'est un littéral (dans ce cas un identifiant) dans la langue du locuteur natif. Même "Li STD NA LI Vector La I Ga Li v SE" n'est pas mauvais.



4
votes

En tant que développeur aveugle, programmation depuis que j'avais 13 ans, j'ai trouvé cette question vraiment intéressante. Tout d'abord, comme mentionné par d'autres piles, l'apprentissage d'une nouvelle langue pour pouvoir comprendre le code n'est pas une solution pratique, car elle prendrait probablement plus de temps pour apprendre les énoncés parlés comme pour apprendre le langage de programmation réel.

lire la question / réponses deux autres points se sont produits:

  • Tout d'abord, vous seriez surpris de savoir à quel point le "temps de pensée" est important. J'ai déjà programmé en C / C ++ / Java et utilisez maintenant C # comme langue principale et me considère très compétente. Mais quand j'ai fait quelques projets à Python, j'ai trouvé la ponctuation réduite me vola de mon "temps de pensée" - inconsciemment, j'utilisais la ponctuation pour digérer ce que je voudrais juste entendre - fascinant ... Cependant, la situation est Un peu différent lorsqu'il s'agit d'identifiants, car ils ne sont pas bien connus de l'auditeur - je trouve personnellement qu'il est difficile d'écouter le code avec acronyme variables (RGXRATIO, RGVRATIO) car je n'ai pas le temps de comprendre ce que cela signifie . Sur le côté bascule, la notation hongroise et les soulignements initiaux rendent du code difficile à écouter comme la durée des variables (en termes de temps pris pour parler) est beaucoup plus longue que les opérations les plus importantes étant effectuées sur ces variables.
  • Une autre chose à considérer est que la longueur du flux audio est un résultat final, mais pas la cause première. La raison pour laquelle l'audio est si longtemps, c'est parce que l'audio est un milieu unidimensionnel, alors que la lecture du texte est un milieu 2D avec la capacité de sauter et de passer au-delà du texte irelevant / familier. Cela ne fonctionnerait pas pour une conférence face à face, mais si s'il y avait des commandes de clavier pour contrôler le discours. Dans les documents texte, mon lecteur d'écran me permet de passer à la ligne suivante, mais que si cela était adapté à la sémantique d'un langage de programmation. Certaines recherches, telles que T V Raman sur Google, comprennent l'utilisation de différentes voix pour la mise en évidence de la syntaxe et des indices audio pour marquer des métadonnées comme des capitales.

    Je connais la question originale spécifiquement liée à une conférence donnée à une classe, mais si vous aimez moi-même, vous devez écouter des fichiers entiers de code source, je trouve également la structure du code fait une énorme différence. Je lis personnellement le code comme une histoire - de gauche à droite, de haut en bas. Il est donc très difficile de suivre un code inconnu quand il est écrit ascendant.


3 commentaires

Je suis curieux de savoir comment vous lisez le code. Vous tapez-vous alors puis-vous vous lire?


Pensez-vous que vous trouverez un langage de programmation plus en forme d'anglais, ou du moins une prononciation de langue plus anglaise d'une langue existante, d'être plus facile à analyser au courant?


Matthew: J'entends des personnages / mots écrits comme je les saisirai, puis peut revoir la première ligne ou le caractère de caractère ultérieur. Le lecteur d'écran lit également des éléments ciblés, et cela s'applique également à l'auto-répartition du code source. Jon: Une plus grande langue anglaise pourrait être bonne, mais vous risquez une abstraction fuite (pensez AppleScript). La lecture d'un langage de programmation normal de manière plus anglaise peut être intéressante, mais je pense que ce serait plutôt encombrant (mon professeur d'université a déclaré: "x devient 5" au lieu de "x = 5", "x est équivalent à 10". de "x == 10" et "ajouter 1 à la valeur de x" au lieu de "x ++")