Чтение исходного кода вслух

Question

Увидев этот вопрос , я задумался о различных проблемах, с которыми сталкиваются слепые программисты, и о том, как некоторые из них применимы даже для зрячих программистов. В частности, проблема чтения исходного кода вслух заставляет меня задуматься. Я программировал большую часть своей жизни, и я часто преподаю одноклассникам по программированию, чаще всего на C ++ или Java.

однозначно усугубляет попытку устно передать основной синтаксис выражения C ++. Говорящий должен дать либо идиоматический перевод на английский язык, либо полную спецификацию кода в словесной от руки, используя явные, но медленные термины, такие как «открывающая скобка», «побитовая и» и так далее. Ни одно из этих решений не является оптимальным.

С одной стороны, идиоматический перевод полезен только для программиста, который может отменить перевод обратно в соответствующий программный код - что обычно не происходит при обучении студента. В свою очередь, образование (или просто повышение квалификации по проекту) является наиболее распространенной ситуацией, когда источник читается вслух, и для ошибки существует очень небольшое поле.

С другой стороны, буквальная спецификация ухудшается медленно. Чтобы сказать «фунт, включить, левую угловую скобку, iostream, правую угловую скобку, новую строку», требуется гораздо больше времени, чем просто набрать #include <iostream>. Действительно, большинство опытных программистов на C ++ воспринимают это просто как «include iostream», но, опять же, неопытных программистов предостаточно, и иногда необходимы буквальные спецификации.

Итак, у меня была идея для потенциального решения этой проблемы.

В C ++ существует конечный набор ключевых слов - 63 - и операторов - 54, исключающих именованные операторы и обрабатывающих составные операторы присваивания и префикса по сравнению с постинфиксным автоинкрементом и декрементом в отличии. Есть только несколько типов литералов, одинаковое количество группирующих символов и точка с запятой. Если я не ошибаюсь, вот и все.

Так не будет ли тогда возможным просто приписать краткое, уникальное произношение каждому из этих различных понятий (включая одно для пробела, где это требуется) и перейти оттуда? Языки программирования гораздо более регулярны, чем естественные языки, поэтому произношение можно стандартизировать. Носители любого языка смогут устно передавать код C ++, а благодаря регулярности и неизменности языка программное обеспечение преобразования речи в текст может быть оптимизировано для приема речи C ++ с высокой степенью точности.

Итак, мой вопрос двоякий: во-первых, возможно ли мое решение; и во-вторых, есть ли у кого-нибудь еще потенциальные решения? Я собираюсь взять предложения и использовать их для подготовки формального документа с примером реализации моего решения.

Answer 1

Будучи слепым разработчиком, программируя с 13 лет, я нашел этот вопрос действительно интересным.Во-первых, как уже упоминалось другими людьми, изучение нового языка для понимания кода не является практическим решением, поскольку, вероятно, потребуется больше времени для изучения устных высказываний, чем для изучения реального языка программирования.

При чтении вопроса / ответов мне пришло в голову еще два момента:

• Во-первых, вы удивитесь, насколько важно «время мышления».Ранее я программировал на C / C ++ / Java и теперь использую C # в качестве основного языка и считаю себя очень конкурентоспособным.Но когда я сделал несколько проектов на Python, я обнаружил, что сокращение знаков препинания отнимает у меня «время на обдумывание» - подсознательно я использовал пунктуацию, чтобы переварить то, что я только что услышал, - удивительно ... Однако ситуация такованемного по-другому, когда дело доходит до идентификаторов, так как они не очень хорошо известны слушателю - мне лично трудно слушать код с переменными аббревиатур (RGXRatio, RGVRatio), так как у меня нет времени, чтобы понять, что это значит,С другой стороны, венгерская нотация и начальные подчеркивания затрудняют прослушивание кода, поскольку длина переменных (с точки зрения времени, необходимого для разговора) намного больше, чем более важные операции, выполняемые с этими переменными.
• Еще одна вещь, которую следует учитывать, это то, что длина аудиопотока является конечным результатом, но не основной причиной.Причина, по которой звук такой длинный, заключается в том, что звук - это одномерный носитель, а чтение текста - это двумерный носитель с возможностью прыгать и пропускать неактуальный / знакомый текст.Это не сработало бы для очной лекции, но что, если бы были команды клавиатуры для управления речью.В текстовых документах программа чтения с экрана позволяет мне перейти к следующей строке, но что, если это было адаптировано к семантике языка программирования.В некоторых исследованиях, таких как Т. В. Раман из Google, используются разные голоса для подсветки синтаксиса и звуковые подсказки для обозначения метаданных в виде заглавных букв.

Мне известен исходный вопрос, конкретно относящийся к лекции, данной длякласс, но если, как и я, вы должны слушать целые файлы исходного кода, я также считаю, что структура кода имеет огромное значение.Я лично читаю код как историю - слева направо, сверху вниз.поэтому очень трудно отследить незнакомый код, когда он написан снизу вверх.

Answer 2

Вместо того, чтобы создавать новые «слова» для их описания, для таких вещей, как «включить», вы могли бы просто поставить префикс «ключевое слово» при произнесении этого вслух. Вы можете использовать слова / фразы, обычно известные, чтобы произносить и другие части. Как и с любым новым программистом, вы все равно должны буквально описывать все, поэтому я не думаю, что это требует особого внимания. Я думаю, что создание новых слов является более сложным методом ...

Так, например:

#include <iostream>;

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

Может быть прочитано как:

(ключевое слово) включает новую строку iostream (ключевое слово) int main без параметров блок, если число 1 (оператор) меньше номер 2 новой строки (ключевое слово) возвращение номер 1 новая строка (ключевое слово) еще новая строка (ключевое слово) возвращаемое число 0 конец блок

Обрабатывать слова в () как необязательные описательные слова, которые, скорее всего, будут использоваться в более сложном коде. Вы можете использовать слово «буквальный», если хотите, чтобы они действительно написали описательное слово. Например

(ключевое слово), если буквальное число (оператор) меньше буквального ключевого слова

становится

if (number < keyword)

Другим словам также могут быть даны определенные значения, такие как «разделенная строка», когда вы хотите, чтобы они продолжались на следующей строке, не закрывая в данный момент открытую скобку и т. Д.

Лично я считаю этот метод довольно простым в использовании и легким в обучении. YMMV, как всегда.

Конечно, это не решает проблему интернационализации, но в худшем случае приведет к использованию «новых слов» в неанглийских языках, что не хуже, чем предлагаемое вами решение.

Answer 3

Так не будет ли тогда возможным просто приписать краткое, уникальное произношение каждому из этих различных понятий (включая одно для пробела, где это требуется) и перейти оттуда? Языки программирования гораздо более обычные, чем естественные языки, поэтому произношение можно стандартизировать

Возможно, но вы потеряли из виду свою цель. Предпосылка состояла в том, что человек, который слушал, не уже знал язык. Если он это делает, мы можем просто сказать «включить iostream», когда мы имеем в виду #include <iostream>, или «вектор int», когда мы имеем в виду std::vector<int>.

Ваша предпосылка заключалась в том, что слушающий недостаточно знаком с языком, чтобы понимать то, что вы читаете вслух, если вы не прочитали точно то, что он говорит.

Теперь, изобретение совершенно нового языка только для описания примитивов, встречающихся в вашем исходном коде, не решает проблему. Вместо этого вы все еще должны прочитать каждый синтаксический токен (с более простыми, более «стандартизированными» произношениями, да, но они все еще должны быть прочитаны вслух), а человек, слушающий все еще не поймет вас, потому что, если они не знают C ++ достаточно хорошо, чтобы понимать «включить iostream», они также не поймут ваше стандартизированное произношение. И если вы собираетесь научить их своему произношению, зачем беспокоиться, если бы вы могли просто научить их понимать синтаксис C ++ напрямую?

Существует также корневая проблема, связанная с тем, что код C ++ состоит из большого количества синтаксических токенов. Возьмем такую ​​простую строку:

std::vector<int> v;

Я считаю 9 жетонов. Ни один из них не может быть опущен. Если слушающий не достаточно хорошо понимает код и синтаксис, чтобы понять высокоуровневое описание, такое как «объявить вектор типа int с именем v», то вам придется прочитать все 9 токенов в некоторой форме. Даже если вы придумали более простые имена, чем «оператор разрешения пространства имен» и «меньше, чем знак», вам все равно придется перечислить 9 имен токенов. Что очень много работы.

Короче, нет, я не думаю, что это сработает. Во-первых, он все еще слишком громоздок, а во-вторых, он предполагает наличие предшествующих знаний со стороны слушающего, когда мотивировкой для этого было то, что слушающий был студентом без предшествующего знания, которое позволило понимать высокоуровневое описание кода.