Русский язык и программирование

Использование русского языка в программировании нередко становится темой дискуссий. И вправду, насколько русский язык применим в этой специфичной сфере деятельности? В средние века просвещенные умы задавались вопросом: «А можно ли петь оперу на чем-то еще, кроме итальянского?».

Ответ нашелся. В нашем отечестве стихи и прозу долго писали на французском. Лишь свет наш Александр Сергеевич переломил эту тенденцию. О применимости русского языка в программировании вполне убедительно ответил Язык Бухгалтерский Универсальный (1С). Бывало, что в общем перечне вакансий в разделе «ИТ» разыскиваемый «программист 1С» требовался чуть ли не в половине случаев! Однако, язык 1С – строго нишевый, на универсальность он не претендует и, судя по всему, претендовать не намерен.

А нужен ли вообще русский язык в программировании?

«. Существует тесная связь между способностью ясно выражать свои мысли и способностью составлять программы для ЭВМ. Характерно в связи с этим заявление руководителей японских программистов, сделанное на одной из конференций: «Наиболее важным языком, который необходимо знать программисту, является не JCL или PL/I. а японский язык». (Р. Лингер, Х. Миллс, Б. Уитт. «Теория и практика структурного программирования», стр. 28. Пер. с англ.-. Мир,1982.-406с.,ил.). Что японцу хорошо, то и русскому не смерть.

Почему, собственно возник такой вопрос? Программирование имеет много общего с математикой. Так почему в школе на уроках нам хватало «x, y,z», а в программировании нет? Да потому, что школьные задачи были достаточно просты: в задачах имелось лишь несколько переменных. Для решения таких задач хватало 45-ти минут. В программировании реализация большинства функций тоже весьма проста, локальным переменным можно по школьному давать однобуквенные идентификаторы (или использовать идентификаторы типа «src» и «dst»). Но этих функций (а так же классов и их членов) может иметься тысячи: так, сервис Jadeite обеспечивает поиск среди 35 000 методов и 4 100 классов, которые сейчас входят в библиотеку документированных интерфейсов Javadoc. Чтобы не затеряться в таком лесу, надо давать идентификаторам такие имена, которые бы исчерпывающе описывали сущность именуемого объекта. Чем длиннее становится программа, тем больше становится идентификаторов, тем тщательнее их необходимо именовать во избежание путаницы.

Т. к. родной язык априори лучше передает смысловые оттенки речи, то именовать все сущности программы желательно на родном языке. «На родном ли?» – возразят многие и будут по-своему правы. Английский язык в программировании – своего рода эсперанто, который дает ощутить себя членом многомиллионного сообщества программистов. Для понимания употребленных идентификаторов часто достаточно иметь весьма средний уровень знаний.

Русский язык в программировании: «за» и «против»

Преимущества программирования на русском очевидны: думаешь только над решаемой задачей, не отвлекаясь на перевод туда и обратно. Комментариев нужно значительно меньше, ибо идентификаторы и так много о себе говорят. Родной язык позволит выражаться четко и глубоко. Чтобы так выражаться на неродном, необходимо его глубоко знать, а это все-таки редкость. Кто может в нашей стране похвастать опытом общения с носителями английского языка? Наверное, доли процента населения. Даже у постоянно программирующих словарный запас английских слов достаточно ограничен. Автору этих строк однажды довелось услышать от своих коллег такие слова: «пуршасе» и «инвоице». Это было произнесено в ситуации, когда один русский программист называл другому русскому программисту идентификаторы в русской же программе, написанной для русского рынка. Но поскольку программа была написана на сами знаете каком языке, а с программой были проблемы, опытный программист диктовал своему коллеге побуквенно (а как иначе? ведь можно перепутать) на что надо обратить внимание.

Нередко именуемому объекту программы легко подобрать соответствующее английское слово или фразу. Но не всегда. Как перевести на английский слова «сторно», «ИНН», «ОКПО» или обросшее легендами слово «крыжить»? Если «сальдо» – это «balance», а «торговый баланс» – это «trade balance», то «сальдо торгового баланса» – это «balance of trade balance»? Чувствуете, какое масло масляное?

Но это не вся проблема. Написанную программу потом надо будет читать, т. е. сделать обратный перевод. Русское предложение «сквозь трамвай проходил оголенный провод», будучи правильно переведено на английский, а затем правильно переведено обратно, может потом звучать так: «Через трамвай шествовал голый кондуктор». Конечно, если вы читаете в подлиннике «Гамлета» и понимаете юмор фразы «Two beer or not two beer? That is the question», то вас не испугают эти трудности. Но неплохо помнить, что за программирование (абстрактное мышление) и знание иностранных языков(образное мышление) отвечают разные полушария головного мозга.

Ложка дегтя

Все аргументы в пользу «русского программирования» многочисленны и обоснованы, но все они хороши «в теории». На практике же – сплошное разочарование. Поддержку идентификаторов на кириллице имеют очень малое число языков/сред разработки (сразу оговорюсь: здесь не имеется в виду 1С и разработки энтузиастов-одиночек типа языка «Глагол». «Валентина». ПРОФТ и т. п.). Даже если такие идентификаторы возможны, то все равно придется постоянно переключаться с русского регистра на латинский: имена функций, классов – на латинице. При всем том, что в Visual Studio 2008 русифицирован, сей факт нисколько не отменяет необходимости переключаться с одного регистра на другой. Есть такое мнение, что «язык – ничто, а библиотеки – это все». Это «наше все» – это сплошная латиница. Рискнувшего писать по-русски ожидают постоянные нажатия «Alt+Shift». Не получается отделить зерна от плевел, агнцев от козлищ, мух от коктейлей.

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

Отмечу только, что «в центр» такой системы логично поместить язык, обеспечивающий «ортогональность» семантики и лишенный неоднозначностей. В теории, наилучший кандидат на эру роль – эсперанто. На практике этим языком опять окажется английский с его омонимами и неоднозначностями. Возможно, отечественное ИТ-сообщество дозреет до создания «русского языка программирования».

Будет, на мой взгляд, большой ошибкой, если такой язык будет ориентирован исключительно на русскоязычную аудиторию. Искусственное ограничение ареала обитания снизит шансы на популярность «языка светлого завтра». Ведь ему будут закрыты многие двери: он не заменит Javascript в браузерах, на нем не будут проводиться международные олимпиады по программированию. На нем не напишут Linux, Windows или MacOS. Его не будут изучать в Гарварде и Кембридже, о нем не напишет книгу Питер Нортон с в соавторстве с Василием Пупкиным. Но, самое главное, он не обрастет той инфраструктурой, которая есть вокруг всех мировых языков типа С или Java. Инфраструктурой, которая включает в себя не только компилятор с IDE и библиотеками, но и миллионы людей, готовых этот язык учить и использовать, популяризировать и развивать.

Какой язык программирования самый популярный?

C, C++, Java, C#, Python, Ruby? Ошибаетесь. Самый популярный язык в программировании – это английский. Какая разница, за какими названиями он прячется, Pascal или С, все равно все типы, функции, классы – это английские фразы, слова или сокращения.

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

Между тем, по оценкам экспертов производительность труда программистов в России примерно на 30% ниже такого же показателя программистов в США (не в деньгах, в строках написанного кода). Одна из возможных причин в том, что американские программисты работают только с родным языком. Нам же приходится сочетать русский в комментариях и английский в остальном при относительно невысокой роли комментариев (хорошая программа должна быть понятна без комментариев). Конечно, для умного и образованного человека выучить английский язык – задача посильная. Но он все равно будет не родной язык.

Из книги В. М. Пентковского об автокоде «Эльбрус».

В советское время не стеснялись программировать на русском.

Эргономика

Использование русского языка в программировании влечет за собой проблемы в эргономике из-за постоянных переключений с русской раскладки на латинскую и наоборот. Причин две:

1) имена функций, классов в тех же С/С++ никто не собирался переводить на русский: «fopen» или «printf» все равно надо писать латиницей; проблема постоянных переключений рус/лат решается полной русификацией всех имён функций, типов и т. д.

2) половина служебных символов отсутствует в русской раскладке клавиатуры: `

@ # $ ^ & [ ] | \ ‘ .

Это очень много. Кто виноват? С одной стороны, наш алфавит, в котором на 7 букв больше, чем в латинице. С другой, западные вендоры даже не подозревают, что у нас из-за этого есть проблемы. Им и в голову не могла прийти идея программы PuntoSwitch.

Что делать? IDE для потенциального «русского языка программирования» должна быть эффективно решать эргономические проблемы. В клавиатуре, которую мы имеем, нет переключателя «рус/лат». «Alt-Shift» или «Ctrl-Shift» неуклюжи. Для переключения должна использоваться одна клавиша, допустим, это будет «Ctrl». При этом надо оставить возможность временного переключения на латиницу. Например, печатаем по-русски, но необходимо набрать «[]», которых нет в русской раскладке. Нажимаем «Ctrl» и «хъ» – и получаем «[]». Отпускаем «Ctrl» и продолжаем печатать по-русски.

Безопасность

В преддверии запуска доменной зоны «.рф» при обсуждении проблем безопасности пришли к мнению, что одинаковые по начертанию буквы русского и латинского алфавитов могут при смешанном использовании вводить в заблуждение. Это открывает лазейки злоумышленникам. Было решено, что смешения букв из разных алфавитов в доменных именах быть не должно. Фокус с подменой букв одного алфавита на похожие по начертанию буквы другого может быть использован и в программировании, например:

Тут есть большой простор для фантазии, каким образом можно замаскировать свои замыслы и в каких целях это использовать. Между прочим, латиница тоже не защищена от такого рода проблем, буква «O» похожа на цифру «0», буква «l» — на цифру «1». Просто с началом использования кириллицы в программировании таких вариантов становится значительно больше. Возможно, трюки с подменами букв не применялись мошенниками. По крайней мере, это не получило широкую огласку. Но ведь были попытки внедрения «лазеек», хотя и не таким способом. И где гарантии, что все они стали известны? О безопасности надо думать заранее, а не в момент латания уже имеющихся дыр.

Что делать? Первый путь: запретить, как в домене «.рф», одновременное употребление в одном идентификаторе кириллицы и латиницы. Однако в вышеприведенном примере и это не поможет. Второй путь: ничего не запрещать, просто латинские буквы должны показываться в IDE одним цветом или шрифтом, а русские – другим. Третий путь: компилятор должен выдавать список идентификаторов, у которых графическое начертание одинаковое, а коды символов разные. А лучше всего, наверное, объединить второй и третий подходы. И баба с возу, и волки сыты.

Попытки приблизиться к естественному языку

На заре компьютерной эры, при появлении первых языков программирования считалось, что совсем скоро будут программировать если не на естественном языке, то на языке программирования, к нему близкому. Создатели языков старались сделать свои детища похожими на естественную речь. Вот пример из Кобола (в переводе на русский): «ПЕРЕМЕННОЙ X ПРИСВОИТЬ Y». Пресловутые «BEGIN» и «END» возникли в Алголе как раз в это время. Надо признать, что попытки приблизить искусственные языки, изобретенные для программирования, к языкам естественным провалились. Слишком сложны человеческие языки, а русский в особенности. Уместно вспомнить анекдот про суперкомпьютер, который сломался на диалоге: «– Ты будешь встречать старый Новый год? – Да нет, наверное».

«Я не удивлюсь, если программирование станет еще более формализованным и отодвинется от обычной человеческой речи еще дальше» – ответил Б. Страуструп на вопрос о будущих языках программирования. Можно так же вспомнить высказывание Дейкстры: «Проекты, предлагающие программирование на естественном языке, гибельны по своей сути».

Простота языка может быть самостоятельной ценностью. Это справедливо как для потенциального «русского языка программирования», так и для любого другого. Попытки же привнести в язык программирования особенности нашей речи приведут к чрезмерному усложнению языка. Во-первых, наш язык просто соткан из противоречий, зачем они нужны еще и в программировании? Во-вторых, результат будет все равно половинчатый: получившийся язык так и не станет похож на наш родной, однако от остальных языков программирования его будет отличать излишняя синтаксическая сложность.

Например, в языке «Кумир» частица «не» может вставляться вовнутрь идентификатора. Если объект «дверь открыта» имеет значение «ложь», то можно записать «дверь НЕ открыта», и это будет читаться значительно лучше, чем «НЕ дверь открыта», хотя последнее более «математично». Но как авторы языка учли двойные отрицания? Никак: если из объекта «никто НЕ закрыл дверь» удалить частицу «НЕ», то получится «никто закрыл дверь». Вывод: учесть все нюансы русского языка не только трудно, но и не нужно. Фраза «! дверь открыта» будет выглядеть как исковерканная речь. Но ведь англичане привыкли к «copy file», хотя правильнее было бы «to copy the file». И мы привыкнем и не будем в обычной речи сыпать фразами «если истинно затем учтем это конец если».

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

Зачем нам русский Кобол? Чем лаконичнее язык, чем ближе к математической записи, тем проще разобраться с написанной программой. А вот возможность использовать пробелы в идентификаторах (в «Кумире» и русификаторе С++ ) следует приветствовать. Традиция разделять слова пробелами существует почти во всех языках, это делает текст удобочитаемым. Согласитесь, что идентификатор «длина входной строки» выглядит предпочтительнее, чем «ДлинаВходнойСтроки» или «длина_входной_строки». Одиночные пробелы внутри идентификаторов сделали бы идентификаторы более естественными. Но в таком случае мы теряем право использовать одиночный пробел в качестве разделителя лексем (теоретически это все-таки возможно, но на практике приведет к усложнению синтаксиса и компилятора). Можно использовать обходной маневр: использовать не пробел с кодом 32, а пробел с кодом 160. Но второго пробела нет на клавиатуре. На помощь могла бы прийти IDE.

Например, при нажатии «Ctrl» + «пробел» формировать символ с кодом 160. Но лучше не стоит этого делать. По своему опыту скажу, что делать два пробела там, где раньше хватало одного – дело привычки. А IDE могла бы графическим образом подсказать, что воспринято в качестве идентификатора. При наличии синтаксической раскраски, особенно хорошей и заточенной под синтаксис конкретного языка программирования, эта проблема вообще уходит. Зато сколько появляется плюсов.

Постскриптум

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

Как вы относитесь к использованию русского языка в программировании?

Только «за»

██████████████████████████████████ 571 (80.3%)

Хотелось бы, но нет серьёзных языков программирования

██ 31 (4.36%)