Какие синтаксические особенности языков программирования проблематичны для слепых программистов?
Какие синтаксические особенности современных языков являются проблематичными для программ чтения с экрана или Брайля? Какие символы и конструкции раздражают слышать или чувствовать? Для слепых программистов, если бы вы разработали язык программирования, с которым другим слепым было бы легче работать, на что бы он был похож?
1 ответ
Хотя это очень интересный вопрос, это вопрос личных предпочтений и предпочтений, поэтому я отвечу так, как если бы вы спросили меня лично.
Примечание. Моя рабочая система - Windows, поэтому я сосредоточусь на ней. Конечно, я могу писать кроссплатформенные приложения, но я делаю это на компьютере с Windows.
Отступы, пробелы
Все вещи, связанные с отступами, более или менее раздражают, особенно если отступ сделан несколькими пробелами, а не табуляцией (да, я знаю всю "священную войну" вокруг этого!). Python научил меня правильно делать отступы в коде даже в тех языках, которые в нем не нуждаются, но мне все еще больно писать правильный Python из-за этих пробелов. Почему так? Ответ прост: моя программа чтения с экрана сообщает мне количество пробелов, а фактический уровень вложенности в четыре раза меньше. Каждая такая операция (20 пробелов, ага, деление на 4, это пятый уровень вложенности) приносит некоторые накладные расходы и заставляет меня тратить свои внутренние ресурсы "ЦП", которые я мог бы освободить для отладки или других причудливых вещей. Вы сказали бы, что это крошечная мелочь, и вы были бы правы, но эти накладные расходы находятся на каждой отдельной строке моего (или другого человека!) Кода, который я должен прочитать или отладить! Это довольно много.
Вкладки намного лучше: 5 вкладок, пятый уровень вложенности, красиво и хорошо. Дисплей Брайля здесь также будет проблемой, потому что, как вы, наверное, знаете, дисплей Брайля (несмотря на название) представляет собой одну строку текста, обычно длиной от 14 до 40 символов. То есть, представьте себе крошечный монитор с одной строкой текста, которую вы перемещаете (т.е. прокручиваете), и ничего кроме этого. Если 20 символов являются пробелами, у вас остается только 20 символов для кода. Чуть больше, если вы читаете во втором классе Брайля, но я не знаю, будет ли это уместно для кодирования, я в основном использую для этого речь, за исключением некоторых случаев.
Еще более болезненными являются некоторые стандарты стиля кода, в которых вы должны выровнять код в строке. Например, это было в случае с тестами в moment.js. Там ожидаемые значения и сообщения должны соответствовать их позиции в строке, поэтому, например, открывающая кавычка будет в столбце 55 каждой строки (это прекрасно, я признаю). Я не мог принять мой запрос на получение более чем на неделю, пока не понял, что пытается сказать мне Искрен (спасибо ему за его терпение!), Один из главных разработчиков. Как вы можете догадаться, это было бы совершенно очевидно для зрячего человека.
Конец блока
Проблема, смежная с предыдущей: лично для меня это очень изящно, когда я знаю, что определенный блок кода заканчивается. Правая скобка (как в C) или слово end (как в Ruby) хороши, изменение уровня отступа (как в Python) - нет: все еще есть некоторые издержки, связанные с осознанием того, что уровень вложенности резко изменился.
Иды
Извините, что признаю это, но практически нет удобной IDE для слепых. Наиболее близкой к такой IDE является Microsoft Visual Studio, особенно последняя версия ( боже, благослови Дженни Лей-Флурри!), Android Studio, похоже, также движется к доступности, начиная с версии 2. Однако они не так удобны в использовании, изящны и удобны, как для зрячих пользователей. Так, например, я использую текстовые редакторы и инструменты командной строки для написания, компиляции и отладки своего кода, как и многие слепые люди вокруг меня.
Баллада о змее, или Другая священная война
Еще одна вещь, в которой виноват Python: с camelCase гораздо удобнее иметь дело, чем с snake_case или даже с PascalCase. Обычно программы чтения с экрана разделяют слова, написанные в camelCase, как если бы они были разделены пробелами, поэтому мне не сложно читать ThisPartOfSentence.
Когда вы пишете код, вы должны включить пунктуацию, иначе вы пропустите что-то действительно крошечное и "неважное", такое как цитата, точка с запятой или скобка. Затем, если ваша пунктуация включена, и вы читаете my_very_cool_descriptive_variable_name вы слышите следующее: "мое подчеркивание очень подчеркивает прохладное подчеркивание.... подчеркивание подчеркивает подчеркивание!!!" (плохой язык и ругается цензурой). Я даже пытался заменить подчеркивания звуками (да, моя программа чтения с экрана дает такую возможность), но звуки не могут быть так хорошо синхронизированы из-за более высокой скорости речи, которую я использую. И это настоящий кошмар, когда дело касается таких методов и свойств, как __proto__ (ага, с обеих сторон есть два подчеркивания, а не одно, не три - ну, я думаю, правильно, я думаю!), __repr__ и так далее и тому подобное. Да, вы могли бы сказать, что я могу заменить слово "подчеркивание" чем-то действительно коротким, как "un" (это также возможно), но некоторые накладные расходы все еще здесь, как с пробелами и вложением кода.
PascalCase намного лучше, но это подразумевает немного большую концентрацию, также, поскольку мы должны помнить, что нужно вводить первую заглавную букву (о, я слишком привередливый, пусть это будет PascalCase, но не те, кто под... о, хорошо, вы получил уже). Это была причина, по которой я отказался от Rust, кстати.
В поисках функций
Как я уже говорил вам, IDE не подходят для нас, поэтому текстовый редактор - наш лучший друг. и затем вам нужно искать функции и методы, а также классы и блоки кода. В некоторых языках (не на Python на этот раз) нет ключевых слов, которые бы запускали функцию (см., Например, C или Java-код). Поиск функций в этих условиях становится довольно болезненным, если, например, вы знаете, что у вас есть логическая ошибка где-то в третьей или четвертой функции в файле, но вы точно не помните ее имя или просматриваете чей-то код... ну, вы знаете, есть много причин для этого. В этом конкретном контексте Python хорош, а C - нет.
Несколько повторяющихся и похожих персонажей
Это не проблема как таковая, но обстоятельство, которое усложняет отладку, например, регулярных выражений или сильно вложенных операций, таких как ((((a + ((b * c) - d) ** e) / f) + g) - h, этот конкретный пример действительно синтетический, но вы понимаете, что я имею в виду: вложенные троичные операторы (которые мне нравятся, кстати!), условные блоки и так далее. И снова регулярные выражения.
Идеальный язык
Наиболее близким к идеалу языком, дружественным к слепым, для меня является язык D. Единственный недостаток - отсутствие слова. function кроме анонимных функций. PHP и Javascript также хороши, но, к сожалению, у них есть множество других, не связанных слепыми недостатков.
Обновление о Go
В одном из своих выступлений Роб Пайк, главный разработчик языка Go, сказал, что никому не нравится стиль кода, навязанный утилитой Gofmt. Наверное, никто - кроме меня! Мне это нравится, мне это очень нравится, каждый файл в Go настолько лаконичен и хорош для чтения, что мне очень нравится этот язык. Единственное, что немного раздражает слепого кодера, - это когда в определении функции есть несколько пар скобок, например, если это на самом деле метод struct. <- Оператор канала все еще дает мне время подумать о том, что я делаю, отправляю или получаю, но я считаю, что это привычка.