Lendo o código-fonte em voz alta

Question

Depois de ver essa questão, comecei a pensar sobre os vários desafios que os programadores cegos enfrentam e como alguns deles são aplicáveis ​​até mesmo aos programadores com visão.Particularmente, o problema de ler o código-fonte em voz alta me faz pensar.Tenho programado durante a maior parte da minha vida e frequentemente dou aulas de programação para outros alunos, geralmente em C++ ou Java.

Isso é unicamente É agravante tentar transmitir verbalmente a sintaxe essencial de uma expressão C++.O falante deve fornecer uma tradução idiomática para o inglês ou uma especificação completa do código em manuscrito verbal, usando termos explícitos, porém lentos, como "parênteses de abertura", "bit a bit e", etc.Nenhuma dessas soluções é ideal.

Por um lado, uma tradução idiomática só é útil para um programador que pode destraduzir de volta para o código de programação relevante – o que normalmente não é o caso quando se dá aulas particulares a um aluno.Por sua vez, a educação (ou simplesmente atualizar alguém sobre um projeto) é a situação mais comum em que a fonte é lida em voz alta e há uma margem de erro muito pequena.

Por outro lado, uma especificação literal é extremamente lenta.Demora muito mais tempo para dizer "librar, incluir, colchete angular esquerdo, iostream, colchete angular direito, nova linha" do que simplesmente digitar #include <iostream>.Na verdade, a maioria dos programadores C++ experientes leriam isso apenas como "incluir iostream", mas, novamente, há muitos programadores inexperientes e especificações literais às vezes são necessárias.

Então, tive uma ideia para uma solução potencial para esse problema.

Em C++, existe um conjunto finito de palavras-chave—63—e operadores—54, descontando operadores nomeados e tratando operadores de atribuição compostos e incremento e decremento automático de prefixo versus pós-fixo como distintos.Existem apenas alguns tipos de literais, um número semelhante de símbolos de agrupamento e ponto e vírgula.A menos que eu esteja completamente enganado, é isso.

Então, não seria viável simplesmente atribuir um texto conciso e único pronúncia para cada um desses conceitos distintos (incluindo um para espaço em branco, onde for necessário) e partir daí?As linguagens de programação são muito mais regulares que as linguagens naturais, portanto a pronúncia poderia ser padronizada.Palestrantes de qualquer A linguagem seria capaz de transmitir verbalmente o código C++ e, devido à regularidade e fixidez da linguagem, o software de conversão de fala em texto poderia ser otimizado para aceitar a fala C++ com um alto grau de precisão.

Portanto, minha pergunta é dupla:primeiro, minha solução é viável;e segundo, alguém mais tem outras soluções potenciais?Pretendo aproveitar sugestões daqui e utilizá-las para produzir um artigo formal com um exemplo de implementação da minha solução.

Answer 1

Em vez de criar novas "palavras" para descrevê-las, para coisas como "incluir", você poderia simplesmente prefixá-las com "palavra-chave" ao pronunciá-las em voz alta.Você pode usar palavras/frases comumente conhecidas para dizer outras partes também.Como acontece com qualquer novo programador, você precisa descrever literalmente tudo de qualquer maneira, então não acho que isso exija atenção especial.Acho que criar novas palavras é o método mais difícil...

Então, por exemplo:

#include <iostream>;

int main()
{
   if (1 < 2)
     return 1;
   else
     return 0;
}

Poderia ser lido como:

(Palavra-chave) Incluir iostream nova linha (palavra-chave) int principal não params iniciar bloco se número 1 (operador) menor que o número 2 nova linha (palavra-chave) devolver número 1 nova linha (palavra-chave) else nova linha (palavra-chave) retornar Número 0 Bloco final

Trate as palavras em () como palavras descritivas opcionais, com maior probabilidade de serem usadas em códigos mais complexos.Você poderia usar a palavra 'literal' se quiser que eles realmente escrevam a palavra descritiva.Por exemplo

(palavra -chave) Se o número literal (operador) menos que a palavra -chave literal

torna-se

if (number < keyword)

Outras palavras também podem receber significados definidos, como 'linha dividida' quando você deseja que continuem na próxima linha, sem fechar nenhum parêntese atualmente aberto, etc.

Pessoalmente, acho esse método bastante simples de usar e fácil de ensinar.YMMV, como sempre.

É claro que isso não resolve a questão da internacionalização, mas, na pior das hipóteses, resultaria no uso de “novas palavras” em idiomas diferentes do inglês, o que não é pior do que a solução proposta que você ofereceu.

Answer 2

Como desenvolvedor cego, programando desde os 13 anos, achei essa questão muito interessante.Em primeiro lugar, como mencionado por outras pessoas, aprender uma nova linguagem para poder compreender o código não é uma solução prática, pois provavelmente demoraria mais tempo a aprender as expressões faladas do que a aprender a linguagem de programação propriamente dita.

Lendo as perguntas/respostas, mais dois pontos me ocorreram:

• Em primeiro lugar, você ficaria surpreso com o quão importante é o “tempo para pensar”.Já programei em C/C++/Java e agora uso C# como linguagem principal, e me considero muito competente.Mas quando fiz alguns projetos em Python, descobri que a pontuação reduzida roubou meu "tempo para pensar" - inconscientemente, eu estava usando a pontuação para digerir o que tinha acabado de ouvir - fascinante...No entanto, a situação é um pouco diferente quando se trata de identificadores, pois estes não são bem conhecidos pelo ouvinte - eu pessoalmente acho difícil ouvir código com variáveis ​​de siglas (RGXRatio, RGVRatio), pois não tenho tempo para descobrir o que isso significa.Por outro lado, a notação húngara e os sublinhados iniciais tornam o código difícil de ouvir, pois o comprimento das variáveis ​​(em termos de tempo necessário para falar) é muito maior do que as operações mais importantes executadas nessas variáveis.
• Outra coisa a considerar é que a duração do fluxo de áudio é um resultado final, mas não a causa raiz.A razão pela qual o áudio é tão longo é porque o áudio é um meio unidimensional, enquanto a leitura de texto é um meio 2D com a capacidade de pular e pular textos irrelevantes/familiares.Não funcionaria para uma palestra presencial, mas e se houvesse comandos de teclado para controlar a fala.Em documentos de texto, meu leitor de tela me permite pular para a próxima linha, mas e se isso fosse adaptado à semântica de uma linguagem de programação?algumas pesquisas, como a de T V Raman do Google, incluem o uso de diferentes vozes para realce de sintaxe e dicas de áudio para marcar metadados como letras maiúsculas.

Conheço a pergunta original relacionada especificamente a uma palestra dada a uma turma, mas se, como eu, você tiver que ouvir arquivos inteiros de código-fonte, também acho que a estrutura do código faz uma enorme diferença.Pessoalmente, leio o código como uma história - da esquerda para a direita, de cima para baixo.portanto, é muito difícil rastrear código desconhecido quando ele é escrito de baixo para cima.

Answer 3

Então, não seria viável simplesmente atribuir uma pronúncia concisa e única a cada um desses conceitos distintos (incluindo um para espaços em branco, onde for necessário) e partir daí?As linguagens de programação são muito mais regulares que as linguagens naturais, então a pronúncia poderia ser padronizada

Talvez, mas você perdeu de vista o seu objetivo.A premissa era que a pessoa que estava ouvindo não já conhece o idioma.Se o fizer, podemos simplesmente dizer "incluir iostream" quando queremos dizer #include <iostream>, ou "vetor de int" quando queremos dizer std::vector<int>.

Sua premissa era que a pessoa que está ouvindo não está familiarizada o suficiente com o idioma para entender o que você lê em voz alta, a menos que você leia em voz alta. exatamente o que diz.

Agora, inventar uma linguagem totalmente nova apenas para descrever os primitivos que ocorrem no seu código-fonte não resolve o problema.Em vez disso, você ainda tem que ler cada token sintático (com pronúncias mais simples e "padronizadas", sim, mas ainda precisam ser lidas em voz alta), e a pessoa que está ouvindo ainda não entenderão você, porque se eles não conhecerem C++ bem o suficiente para entender "include iostream", também não entenderão sua pronúncia padronizada.E se você vai ensinar-lhes sua pronúncia, por que se preocupar, quando você poderia simplesmente ensiná-los a entender a sintaxe C++ diretamente?

Há também o problema raiz de que o código C++ tende a consistir em bastante de tokens sintáticos.Pegue uma linha tão simples quanto esta:

std::vector<int> v;

Conto 9 fichas.Nenhum deles pode ser omitido.Se a pessoa que está ouvindo não entende o código e a sintaxe bem o suficiente para entender uma descrição de alto nível, como "declarar um vetor de int, chamado v", então você terá que ler todos os 9 tokens de alguma forma.Mesmo se você criar nomes mais simples do que "operador de resolução de namespace" e "menor que sinal", ainda precisará listar 9 nomes de tokens.O que dá muito trabalho.

Resumindo, não, não acho que funcionaria.Primeiro, ainda é muito complicado e, segundo, é presumir conhecimento prévio por parte de quem ouve, quando a motivação para isso era que quem ouvia era um estudante sem o conhecimento prévio que possibilitou a compreensão de uma descrição de alto nível do código.