La Lettura Del Codice Sorgente Ad Alta Voce

Question

Dopo aver visto questa domanda, Ho avuto modo di pensare le varie sfide che i non vedenti programmatori faccia, e di come alcuni di loro sono applicabili anche ai vedenti programmatori.In particolare, il problema della lettura del codice sorgente ad alta voce mi dà una pausa.Sono stato in programmazione per la maggior parte della mia vita, e mi capita spesso di tutor compagni di corso in programmazione, più spesso in C++ o Java.

È in modo univoco aggravanti per cercare di trasmettere verbalmente essenziali di sintassi del C++ espressione.L'oratore deve dare sia una traduzione idiomatica in inglese, o una specificazione completa del codice verbale, longhand, l'utilizzo esplicito di sicurezza lento termini come "parentesi", "bit a bit "e", et cetera.Nessuna di queste soluzioni è ottimale.

Da un lato, una traduzione idiomatica è utile solo per un programmatore che può de-tradurre di nuovo nel relativo codice di programmazione che di solito non è il caso quando il tutoraggio di uno studente.A sua volta, l'istruzione (o semplicemente qualcuno fino a velocità su un progetto) è la situazione più comune in cui la sorgente viene letto ad alta voce, e c'è un piccolo margine di errore.

D'altra parte, un letterale specifica è aggravatingly lento.Ci vuole molto, molto più tempo per dire "pound, includere, parentesi angolare sinistra, iostream, staffa ad angolo retto, newline" che fa semplicemente il tipo di #include <iostream>.Infatti, la maggior parte esperti programmatori C++ vorresti leggere questo semplicemente come "include iostream", ma, di nuovo, inesperto programmatori abbondano e letterale specifiche a volte sono necessari.

Così ho avuto un'idea per una possibile soluzione a questo problema.

In C++, c'è un insieme finito di parole chiave—63—e gli operatori-54, attualizzazione denominato operatori e il trattamento composto operatori di assegnazione e il prefisso contro postfix auto-incremento e decremento distinti.Ci sono solo alcuni tipi di letterale, un numero simile di raggruppamento simboli, e il punto e virgola.A meno che io sono del tutto sbagliata, che su di esso.

Così, non sarebbe fattibile semplicemente attribuiscono un conciso, unico pronuncia per ciascuno di questi concetti distinti (di cui uno per gli spazi vuoti, dove è richiesto) e passare da lì?I linguaggi di programmazione sono molto più regolare rispetto lingue naturali, in modo che la pronuncia può essere standardizzato.Altoparlanti di qualsiasi la lingua sarebbe in grado di trasmettere verbalmente codice C++, e grazie per la regolarità e la fissità della lingua, speech-to-text software potrebbe essere ottimizzati per accettare il C++ discorso con un alto grado di precisione.

Quindi la mia domanda è duplice:in primo luogo, è la mia soluzione fattibile;e in secondo luogo, qualcun altro ha altre possibili soluzioni?Ho intenzione di prendere suggerimenti da qui e li usa per produrre formale di carta con un esempio di implementazione della mia soluzione.

Answer 1

Invece di creare nuove "parole" per descrivere, ad esempio, per le "includere" si potrebbe semplicemente farlo con il prefisso "parola chiave", quando si dice ad alta voce.Si potrebbe usare parole/frasi comunemente noto che dicono gli altri componenti.Come con qualsiasi nuovo programmatore, è letteralmente descrivere tutto comunque, quindi non credo che richiedono una particolare attenzione.Penso che la creazione di nuove parole è il metodo più difficile...

Così, per esempio:

#include <iostream>;

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

Potrebbe essere letto come:

(parola chiave) include iostream nuova linea di (parola chiave) int main non params inizio blocco se il numero 1 (operatore) a meno di il numero 2 di nuova riga (parole chiave) ritorno numero 1 di nuova riga (parole chiave) altro new-line (parole chiave) restituisce il numero 0 fine blocco

Il trattamento di parole (), come optional, le parole descrittive, più suscettibili di essere utilizzati in un codice più complesso.Si potrebbe usare la parola 'letterale' se si vuole loro di scrivere la parola descrittiva.Per esempio

(parola chiave) se il numero letterale (operatore) meno letterale parola chiave

diventa

if (number < keyword)

Altre parole poteva essere definito un significato, come "split-line' quando si desidera loro di continuare sulla riga successiva, senza chiudere alcun attualmente aperta parentesi, etc.

Personalmente trovo questo metodo molto semplice da usare e facile da insegnare.YMMV, come sempre.

Naturalmente, questo non risolve il internazionalizzazione problema, ma nel peggiore dei casi, sarebbe risultato in 'parole nuove' essere utilizzato nelle lingue diverse dall'inglese, che non è peggio la soluzione proposta è offerto.

Answer 2

Come sviluppatore cieca, la programmazione da quando avevo 13, ho trovato questa domanda davvero interessante. Prima di tutto, come detto da altri peple, imparare una nuova lingua per essere in grado di capire il codice non è una soluzione pratica, come sarebbe probabilmente necessario più tempo per imparare le espressioni pronunciate come sarebbe per imparare il linguaggio di programmazione vero e proprio.

La lettura della domanda / risposte altri due punti venne in mente:

• In primo luogo, sareste sorpresi di quanto sia importante "il tempo di pensare" è. Ho già programmato in C / C ++ / Java e ora utilizzare C # come la mia lingua principale, e mi considero molto competant. Ma quando ho fatto un paio di progetti in Python, ho trovato la punteggiatura ridotta mi ha derubato del mio "tempo a pensare" - inconsciamente, stavo usando la punteggiatura per digerire quello che avevo appena sentito - affascinante ... Tuttavia, la situazione è un po 'diverso quando si tratta di identificatori, in quanto questi non sono ben conosciute da chi ascolta - personalmente trovo difficile ascoltare codice con variabili acronimo (RGXRatio, RGVRatio) e non ho il tempo di capire che cosa significa . Il rovescio della medaglia, la notazione ungherese e sottolineature iniziali rende il codice difficile da ascoltare come la lunghezza delle variabili (in termini di tempo impiegato per dire) è molto più lungo delle operazioni più importanti in corso di esecuzione in queste variabili.
• Un altro aspetto da considerare è che la lunghezza del flusso audio è un risultato finale, ma non la causa principale. La ragione per cui l'audio è così tanto tempo è perché l'audio è un mezzo unidimensionale, mentre la lettura del testo è un mezzo 2d con la possibilità di saltare e saltare irelevant passato / testo familiare. Essa non avrebbe funzionato per una lezione faccia a faccia, ma se ci fossero i comandi da tastiera per controllare il discorso. Nei documenti di testo il mio lettore di schermo mi permette di saltare alla riga successiva, ma che cosa se questo fosse adattato alle semantica di un linguaggio di programmazione. alcune ricerche, come ad esempio da T V Raman a Google, include l'utilizzo di voci differenti per l'evidenziazione della sintassi, e segnali audio per marcare i metadati come capitali.

So che la domanda iniziale specificamente connessi ad una conferenza tenuta ad una classe, ma se come me si deve ascoltare interi file di codice sorgente, ho anche trovare le struttura del codice fa una differenza enorme. Personalmente leggere il codice come una storia - da sinistra a destra, dall'alto verso il basso. quindi è molto difficile rintracciare tramite codice sconosciuto quando è scritto bottom-up.

Answer 3

  

Quindi sarebbe poi non essere possibile semplicemente attribuire una concisa, pronuncia unica per ognuno di questi concetti distinti (di cui una per spazio bianco, dove è richiesto) e passare da lì? I linguaggi di programmazione sono molto più regolare rispetto a linguaggi naturali, per cui la pronuncia potrebbe essere standardizzato

Forse, ma avete perso di vista il vostro obiettivo. La premessa è che la persona che ha fatto l'ascolto non già conoscere la lingua. Se lo fa, possiamo semplicemente dire "includono iostream" quando si intende #include <iostream>, o "vettore di int" quando si intende std::vector<int>.

Il presupposto è che l'ascolto persona non è sufficiente familiarità con la lingua per capire ciò che si legge ad alta voce a meno di leggere il esattamente quello che dice.

Ora, inventando un nuovo linguaggio per descrivere solo le primitive che si verificano nel codice sorgente non risolve il problema. Al contrario, è ancora devono leggere ogni gettone sintattica (con, più pronunce semplici "standardizzati", sì, ma hanno ancora da leggere ad alta voce), e la persona che ascolta ancora non ti capiranno, perché se non sanno C ++ abbastanza bene per capire "includere iostream", non capiranno la tua pronuncia standardizzata sia. E se avete intenzione di insegnare loro la tua pronuncia, perché preoccuparsi, quando si potrebbe hai appena li ha insegnato a capire il C ++ sintassi direttamente invece?

C'è anche il problema principale che il codice C ++ tende a consistere di molto di gettoni sintattiche. Prendere una linea semplice come questo:

std::vector<int> v;

Conto 9 gettoni. Nessuno di loro può essere omesso. Se l'ascolto persona non capisce il codice e sintassi abbastanza bene per capire una descrizione di alto livello come ad esempio "dichiara un vettore di int, di nome V", allora dovrete leggere tutti i 9 gettoni in una qualche forma. Anche se si arriva con i nomi più semplici di "operatore di risoluzione dello spazio dei nomi" e "segno di minore", si devono ancora elencare 9 nomi dei token. Che è un sacco di lavoro.

In breve, no, non credo che sarebbe lavorare. In primo luogo, è ancora troppo ingombrante, e in secondo luogo, è presumendo conoscenza preventiva da parte della ascolto persona, quando la motivazione per questo è stato che la persona che l'ascolto era uno studente di senza la preventiva conoscenza che ha reso possibile per comprendere una descrizione di alto livello del codice.