Чтение исходного кода вслух
После наблюдения этого вопроса я добрался до размышления о различных проблемах, что слепые программисты сталкиваются, и как некоторые из них применимы даже к зрячим программистам. Особенно, проблема чтения исходного кода вслух дает мне паузу. Я программировал для большей части своей жизни и меня часто сокурсники обучающей программы в программировании, чаще всего в C++ или Java.
Это исключительно ухудшает, чтобы попытаться устно передать существенный синтаксис выражения C++. Динамик должен дать или идиоматический перевод на английский язык или полную спецификацию кода словесным обычным письмом, использовав явные все же медленные термины, такие как "вводная круглая скобка", "поразрядно и", и так далее. Ни одно из этих решений не оптимально.
С одной стороны, идиоматический перевод только полезен для программиста, который может de-translate назад в соответствующий код программы — который обычно не имеет место при обучении студента. В свою очередь образование (или просто получение кого-то до скорости на проекте) является наиболее распространенной ситуацией, в которой читается вслух источник, и существует очень маленькое поле для ошибки.
С другой стороны, литеральная спецификация является медленным aggravatingly. Это берет далеко намного дольше, чтобы сказать "фунт, включать, открывающая угловая скобка, iostream, правая угловая скобка, новая строка", чем это делает для простого ввода #include . Действительно, самые опытные программисты на C++ считали бы это просто, поскольку "включают iostream", но снова, неопытные программисты имеются в большом количестве, и литеральные спецификации иногда необходимы.
Таким образом, у меня была идея для потенциального решения этой проблемы.
В C++ существует конечное множество ключевых слов — 63 — и операторов — 54, обесценивая названный операторами и рассматривая составные операторы присваивания и префикс по сравнению с постфиксным автоинкрементом и декрементом как отличные. Существует всего несколько типов литерала, подобное количество группирующихся символов и точка с запятой. Если я не совершенно ошибаюсь, это об этом.
Таким образом, затем не было бы выполнимо просто приписать краткое, уникальное произношение каждому из этих отличных понятий (включая одного для пробела, где это требуется), и пойдите оттуда? Языки программирования являются намного более регулярными, чем естественные языки, таким образом, произношение могло быть стандартизировано. Динамики любого языка смогли бы устно передать код C++, и из-за регулярности и неподвижности языка, программное обеспечение речи в тексте могло быть оптимизировано для принятия речи C++ с высокой степенью точности.
Таким образом, мой вопрос является двукратным: во-первых, мое выполнимое решение; и во-вторых, у кого-либо еще есть другие потенциальные решения? Я намереваюсь взять предложения отсюда и использовать их для создания формальной статьи с реализацией в качестве примера моего решения.
3 ответа
Вместо того, чтобы создавать новые «слова», чтобы описать их, для таких вещей, как «включать», вы можете просто префиснуть его с «ключевым словом», когда это вслух. Вы можете использовать слова / фразы, широко известные, которые также говорят другие детали. Как и в любом новом программистом, вы должны буквально описать все в любом случае, поэтому я не думаю, что это требует особого внимания. Я думаю, что создание новых слов - это более сложный метод ...
Итак, например:
#include <iostream>;
int main()
{
if (1 < 2)
return 1;
else
return 0;
}
можно было бы счинить как:
(ключевое слово) включают в себя yostream New-line (ключевое слово) int main no params начать Блок, если номер 1 (оператор) меньше Number 2 New-Line (ключевое слово) возврат Number 1 New-Line (ключевое слово) остальное New-line (ключевое слово) Возврат номер 0 конец Блок
лечить слова в () в качестве дополнительных описательных слов, скорее всего, будет использоваться в более сложном коде. Вы можете использовать слово «буквальный», если вы хотите, чтобы они на самом деле написали описательное слово. Например
(ключевое слово), если буквальный номер (оператор) Менее, чем буквальное ключевое слово
if (number < keyword)
if (number < keyword)
Другими словами также могут быть даны определенные значения, такие как «разделение», когда вы хотите, чтобы они продолжали продолжить следующую строку, без закрытия в настоящее время открытых скобок и т. Д.
Я лично нашел этот метод довольно просто использовать и легко учить. YMMV, как всегда.
Конечно, это не решает проблему интернационализации, но в худшем случае приведет к тому, что «новые слова» используются на неанглийских языках, которые не хуже, чем предлагаемое решение, которое вы предлагали.
Так что бы не было бы возможно просто приписать краткое, уникальное произношение к каждому из этих различных концепций (включая один для пробела, где это требуется) и отправиться оттуда? Языки программирования гораздо более регулярны, чем натуральные языки, поэтому произношение может быть стандартизировано
, возможно, вы потеряли вид своей цели. Предпосылка заключалась в том, что человек слушает , уже знают язык. Если он сделает, мы можем просто сказать «включить ioStream», когда мы имеем в виду #include , или «Вектор INT», когда мы имеем в виду STD :: Vector .
Ваша предположение заключалась в том, что человек, слушая не достаточно знакомый с языком, чтобы понять, что вы читаете вслух, если вы не прочитаете , ровно , что он говорит.
Теперь, изобретав целый новый язык, просто чтобы описать примитивы, которые происходят в вашем исходном коде, не решают проблему. Вместо этого вам еще приходится прочитать каждый синтаксический токен (с проще, больше «стандартизированных» произношений, да, но они все еще должны быть зачитаны вслух), а лицо, слушающее еще Не поймете вас, потому что если они не знают C ++ достаточно хорошо, чтобы понять «включить ioStream», они не поймут ваше стандартизированное произношение. И если вы собираетесь научить их вашему произношению, зачем беспокоить, когда вы могли бы просто научить их понять синтаксис C ++ напрямую?
Также есть корневая проблема, которая имеет тенденцию C ++, как правило, состоит из синтаксических токенов. Возьмите строку так же просто, как это:
std::vector<int> v;
Я считаю 9 токенов. Ни один из них не может быть опущен. Если человек, слушая не понимает код и синтаксис достаточно хорошо, чтобы понять описание высокого уровня, такое как «объявить вектор INT, названного V», то вам придется прочитать все 9 токенов в какой-то форме. Даже если вы придумаете более простые имена, чем «Оператор разрешения пространства имен» и «меньше, чем знак», вам все еще нужно перечислить 9 токенов. Что много работы.
Короче говоря, нет, я не думаю, что это будет работать. Во-первых, это все еще слишком громоздкое, а во-вторых, это предполагает, что предыдущие знания со стороны человека, слушающего, когда мотивация за это было то, что человек, слушая которого был студентом без предыдущих знаний, которые позволили сделать возможным понять описание высокого уровня кода.
Как слепой разработчик, занимающийся программированием с 13 лет, я нашел этот вопрос действительно интересным. Во-первых, как упоминалось другими людьми, изучение нового языка для понимания кода не является практическим решением, поскольку, вероятно, потребуется больше времени для изучения устных высказываний, чем для изучения реального языка программирования.
Читая вопрос / ответы, я заметил еще два момента:
- Во-первых, вы удивитесь, насколько важно «время на обдумывание». Раньше я программировал на C / C ++ / Java, а теперь использую C # в качестве основного языка и считаю себя очень конкурентоспособным. Но когда я выполнил несколько проектов на Python, я обнаружил, что сокращение пунктуации лишило меня «времени на размышления» - подсознательно я использовал знаки препинания, чтобы переварить то, что я только что услышал - увлекательно ...Однако, когда дело доходит до идентификаторов, ситуация немного отличается, поскольку они не очень хорошо известны слушателю - мне лично трудно слушать код с переменными акронима (RGXRatio, RGVRatio), поскольку у меня нет времени на выяснить, что это значит. С другой стороны, венгерская нотация и начальные подчеркивания затрудняют прослушивание кода, поскольку длина переменных (с точки зрения времени, затрачиваемого на выступление) намного больше, чем более важные операции, выполняемые с этими переменными.
- Также следует учитывать, что длина аудиопотока является конечным результатом, а не основной причиной. Причина, по которой звук такой длинный, заключается в том, что звук - это одномерный носитель, тогда как чтение текста - это 2-мерный носитель с возможностью прыгать и пропускать релевантный / знакомый текст. Это не сработало бы для очной лекции, но что, если бы были клавиатурные команды для управления речью. В текстовых документах программа чтения с экрана позволяет мне перейти к следующей строке, но что, если бы это было адаптировано к семантике языка программирования. некоторые исследования, такие как Т. В. Раман из Google, включают использование разных голосов для выделения синтаксиса и звуковых сигналов для обозначения метаданных, таких как заглавные буквы.
Я знаю исходный вопрос, конкретно связанный с лекцией, прочитанной классу, но если вы, как и я, должны слушать целые файлы исходного кода, я также считаю, что структура кода имеет огромное значение. Я лично читаю код как рассказ - слева направо, сверху вниз. поэтому очень сложно отследить незнакомый код, когда он написан снизу вверх.