Действительно, как-правило, программирование осуществляется на английском языке. И причин тому несколько.
Первая — это стандарт. И существует он не только в программировании. Еще со школы мы приучены писать:
y = sin(x)а вовсе не:
в = син(г)Поэтому, конечно, любая библиотечная функция должна иметь свое базовое обозначение, и оно, скорее всего, будет на английском языке.
Второе — это международность. Вряд-ли кто-то специально разрабатывает язык программирования для использования исключительно в одной стране мира и только на одном языке — русском, китайском, хинди… Это было бы крайне непрактично. Язык должен быть максимально доступен всем желающим, если, конечно, это не специальный мнемокод для ограниченного круга задач. Ну а раз международность, то это — английский, как самый простой и распространенный международный язык.
Третье — это, конечно, история создания языка. Не смотря на большое количество программистов как в России, так и из России, технологии программирования разрабатываются, как-правило, крупными международными корпорациями. И язык там выбирается, разумеется, английский.
Справедливости ради нужно отметить, что существуют разработки языков программирования, основой которых являются национальные языки, отличные от английского. То есть можно встретить и такие образцы кода:
(Тип1 Эл, Тип2 Зн, (Фн1) Фн):
_Примесь лТ___;
*лА=лТ___.Тип1;
лА=Эл;
лТ___._ЗнПримесь=Зн;
лТ___._ФнПримесь=Фн;
=лТ___;Вопрос удобства подобного кодирования оставим открытым.
Короче говоря, совершенно понятно и не удивительно, что за исключением комментариев, код программы будет англоязычным.
А вот теперь насчет того, может ли быть по-другому. Как разработчик языка, скажу сразу — возможность использования написания имен переменных, функций пользователя, библиотечных функций на произвольном языке должна закладываться в возможности языка, в его синтаксис изначально, в момент создания этого языка. То есть чтобы одновременная возможность как такой записи:
y = sin(x)так и такой записи:
в = син(г)была бы одинаково приемлемой как для компьютера, так и для программиста.
И тут есть хорошая новость: во-первых, давно уже изобрели Юникод, а во-вторых, продолжают изобретать новые языки программирования, например язык SPL.
В SPL нет ограничений на то, на каком языке называются имена переменных, функций, других объектов. Примеры допустимых имен:
N
x1
123k
текст
??Ладно, хорошо. Допустим с именами переменных проблем нет и их можно называть как угодно. Но как быть с конструкциями самого языка? Циклы, переходы, ключевые слова, которые есть в любом языке программирования — как быть с ними?
Элементарно. В SPL нет ключевых слов. Этот язык настолько прост, что они ему просто не нужны. Циклы и переходы? Вот цикл и переход:
>
'тело цикла
<
1 -> 'а это переход на метку с именем "1"
Символы вместо ключевых слов? Да, а почему бы и нет! Ведь вряд ли вы уже забыли, что "->" это переход на метку. То есть ничего сложного тут нет.
Ну а как быть с библиотечными функциями?
Тут все просто. Конечно, базовый вариант библиотечных функций имеет англоязычное написание. Функция синуса там именно привычный всем sin(). Но в SPL функции — это такие же объекты. И их можно присваивать другим объектам. То есть вы можете написать:
син = #.sinчто означает, что теперь объект «син» равен библиотечной функции «sin()», и, если хотите, то теперь запросто пишите:
в = син(г)В SPL очень просто организована вставка файлов программ в другие файлы — всего один символ "$":
$file.txtи файл «file.txt» будет вставлен в это место программы. А в этом файле может быть, к примеру, список ваших собственных переопределений библиотечных функций.
В заключение приведу пример одной и той же функции рекурсивного расчета факториала числа, записанной по-разному. Обратите внимание, что все эти варианты легко могут находиться в одном и том же коде программы. Так что писать код программы на английском, русском или любом другом языке — исключительно выбор самого пользователя, а не требование языка, если эта программа написана на SPL.
fact(n)=
? n!>1
<=1
.
<= n * fact(n-1)
.
#.output(fact(5))
печать=#.output
фактор(н)=
? н!>1
<=1
.
<= н * фактор(н-1)
.
печать(фактор(5))$??
??(?)=
? ?!>1
<=1
.
<= ? * ??(?-1)
.
?(??(5))где содержимое файла ??:
?=#.outputСпасибо за внимание!
Комментарии (42)
kmu1990
11.06.2017 18:19+1#!/usr/bin/env python3 напечатать = print приветствие = 'Hello, World' напечатать(приветствие)
Python 3.5.2, работает без видимых проблем, документация разрешает не только латинские буквы.
Mr_Kibernetik
11.06.2017 18:46-1А грамматические структуры самого Python тоже могут быть на русском если это нужно? Или получится англо-русская каша в коде?
kmu1990
11.06.2017 18:47+1Нет, не могут быть, они могут быть только на языке Python, но ведь у вас они тоже не могут быть на другом языке.
Mr_Kibernetik
11.06.2017 19:11-1Я подробно описал, что в SPL нет никакой необходимости в латинице и привел примеры. Где вы там видите латино-русский микс в коде?
kmu1990
11.06.2017 19:15+1А где в моем комментарии вы видите что-то про латиницу?
Mr_Kibernetik
11.06.2017 19:56но ведь у вас они тоже не могут быть на другом языке.
На каком «другом языке» не могут быть команды SPL? Другом по сравнению с каким? Я подробно описал, что в SPL ключевых слов нет совсем, ни на каком языке. Поэтому что вы имеете в виду под «другим языком»?kmu1990
11.06.2017 20:01Очевидно, другом по сравнению с SPL. Например, у вас вместо ключевых слов странные закорючки вроде ?, но это тоже слово языка, непонятного, но тем не менее языка, не английского, но тем не менее языка. Заменить? на какую-нибудь другую произвольную закарючку не получится. Т. е. у вас «гараммтические конструкции» тоже не могут быть на «другом языке».
Mr_Kibernetik
11.06.2017 20:28Вы правы. Но подобный «язык» позволяет легко избежать латино-нелатинского микса в коде. Это — одна из особенностей SPL.
kmu1990
11.06.2017 21:04- Python (и многие другие) тоже позволяет избежать микса — используйте только ланиницу и микса не будет;
- вы избегаете микса ценой замены слов известных довольно солидной части человечества на понятные только избранным закарючки.
«Особенность» — это очень хороше слово, чтобы описать данную ситуацию.Mr_Kibernetik
11.06.2017 21:12Вы невозможность выдаете за норму, а возможность — наоборот за недостаток. Зачем?
kmu1990
11.06.2017 21:16Невозможность чего я выдаю за норму?
Mr_Kibernetik
11.06.2017 21:24Невозможность использовать не английский язык при написании кода, при этом не создавая латино-иностранный микс.
Я вам показал, что Python здесь не сравнить с SPL, потому что в SPL это возможно, а в Python — нет.kmu1990
11.06.2017 21:34Так и я вам вроде вполне доходчиво объяснил, что не смотря на то, что вы не используете английский язык, вы используете другой язык, но это тоже язык и вы тоже не можете от него отойти в SPL.
Итого что мы имеем:
- Python со своей невозможностью отойти от одного из самых широко распространенных в мире языков;
- SPL с невозможностью отойти от одного из самых нероспрастраненных в мире языков.
В вашем языке можно создать микс из закорючек и любого другого языка, в Python можно создать микс из английского и любого другого языка. В чем принципиальная разница? Вы одну невозможность заменили другой и что дальше-то?Mr_Kibernetik
11.06.2017 21:39То, что вы называете «закорючками», присутствует в любом языке программирования. Или в Питоне нет этих знаков? Они точно так же есть. Но в Питоне есть ЕЩЕ и ОБЯЗАТЕЛЬНЫЕ английские слова, а в SPL в них нет надобности.
kmu1990
11.06.2017 21:47Важно ведь не только то, что эти знаки есть в языке, но и для чего они используются. Например, в вашем SPL есть ?, а в Python есть if, но если они обозначают похожие вещи, то какая разница, какую строчку вы для этого будете использовать? Или вам принципиально претит именно использованалие английских слов для таких конструкций, но при этом знаки препинания для таких вещей это ок?
Mr_Kibernetik
11.06.2017 22:01Я нигде не писал, что мне что-то «претит». Статья о том, что в SPL возможно написание кода используя любой национальный язык, при этом не получая латино-иностранного микса. Подобную возможность вряд-ли можно встретить в других языках программирования. И я описал благодаря чему это достигается.
Вряд-ли в моей статье вы найдете осуждение чего-либо. Наоборот в ней описаны возможности.kmu1990
11.06.2017 22:05+1Вы достигли этого заменив английские слова на занки препинания, и таким образом заменили одну невозможность на другую, и я вам это уже выше объяснил.
Итого в остатке мы имеем просто замену слов известных большей части человечества, на непонятные знаки со смыслом не известным большей части человечаства только из соображения «избегания латино-иностранного микса».Mr_Kibernetik
11.06.2017 23:04Рад, что подобная возможность SPL не оставила вас равнодушным и вы уделили ей столько внимания. Конечно та уникальная возможность, которая описана в статье, является не самоцелью, а просто следствием особенностей синтаксиса SPL.
NeoCode
11.06.2017 20:36+8Считаю использование юникода в именах переменных совершенно непреемлемым. Программирование, и в особенности open source — это международное явление. И как например американскому или российскому программисту редактировать код с китайскими иероглифами вместо переменных? Если американец еще сможет визуально идентифицировать буквы русского алфавита, то китайские символы для европейца просто неотличимы друг от друга. Как их называть? «Такая вертикальная палочка с двумя горизонтальными палочками внизу, двумя по сторонам и тремя черточками сверху с хвостиком???».
А еще есть куча похожих символов. Русская и латинская 'a' например. И что если кому-то придет светлая мысль смещать символы разных языков в коде?
А еще есть куча спецсимволов. Математических, технических, смайлики наконец.
А еще есть управляющие символы, есть всякие хитрые пробелы и прочая муть.
Короче, я глубоко убежден, что использование юникода в идентификаторах языков программирования должно быть запрещено специальной резолюцией Организации Объединенных Наций.algotrader2013
11.06.2017 22:03А еще есть куча похожих символов. Русская и латинская 'a' например. И что если кому-то придет светлая мысль смещать символы разных языков в коде?
Уже сталкивался с таким, будучи студентом, кстати) Не вспомню сходу сайт, но там был фрагмент кода на C#, который после copy-paste упорно не компилировался с неадекватными ошибками. Оказалось, что буквы 'о' и 'а' рандомно то кириллица, то латиница.
До сих пор не пришел к выводу, это было сделано сеошниками для соблюдения уникальности, где-то прошло через ПО для обхода антиплагиат-систем, или просто следствие специфического чувства юмора автора
Crandel
11.06.2017 23:37там была замена точки с запятой :)
картинка
r0ck3r
12.06.2017 11:52Рискну с Вами поспорить, так как далеко не весь код имеет отношение к международному явлению. В своей практике имел опыт разработки приложения, предназначенного исключительно для отечественного потребителя, которое должно было хранить большое количество текстовых данных, получаемых от пользователя. Так вот, названия полей для этих данных имели непонятные мне аббревиатуры и плохо переводимые термины. Между транслитерализацией и кириллицей, скрипя сердцем, было отдано предпочтение последней. В результате я получил имена переменных, методов и полей и таблиц БД на кириллице. О принятом тогда решении не жалею, так как читаемость кода, по сравнению с тем же транслитом, оказалась намного выше.
Однако, смею добавить, что делать так нужно только в самом крайнем случае.
Last_cat_in_universe
12.06.2017 00:40Еще со школы мы приучены писать
Ещё со школы мы приучены, что sin(x) — это латынь =) Сюда же стороны треугольника А(а) B(б) С (ц)
vanxant
12.06.2017 07:07Странно, что никто до сих пор не упомянул 1С-Бухгалтерию. Технически в ней можно программировать на английском, но все пишут по-русски. И тут в общем всё оправданно, потому что наши ПБУ сильно отличаются от международных стандартов МСФО, и многие вещи в принципе не имеют переводов на английский, потому что в англоязычном мире их просто не существует.
TargetSan
12.06.2017 10:57+1Забавно. Как только сообщество некоего языка узнаёт, что в нём нельзя использовать юникод в идентификаторах, начинаются дикие вопли. При этом то же сообщество считает плохим код с не-английскими идентификаторами, и даже транслит.
Вообще же, как по мне, ключевые слова и идентификаторы должны быть только латиницей, чувствительные к регистру, но при этом с запретом иметь два идентификатора, отличающиеся только регистром букв. А в идеале ещё и линт иметь, считающий расстояние Хэмминга.
amarao
12.06.2017 15:20У меня есть даже более простой тест. Делаем рендеринг текста в изображение, потом OCR. Если текстовая часть (за вычетом пробелов) различается, тест на адекватность используемых символов не пройден.
Можно использовать шрифты с явно различающимися нулями, 1/l/I, но это всё равно не поможет в условиях русского o на месте английского, так что тест будет разумным.
poznawatel
12.06.2017 12:19-1По мне, так эта возможность — шаг вперёд в развитии ЯП.
Постороннее замечание: господа программисты, прежде чем назвать что-либо трехбуквенным сокращением, трижды подумайте, не будет ли коллизии с уже существующими аббревиатурами!
Smorodov
12.06.2017 12:37brainfuck не использует национальных алфавитов вообще, переносимость и читаемость кода специалистами не страдает :)
amarao
12.06.2017 15:16??????.?????? ~???????????? ??????????????????????????>?; ~= [ ???????>? ??????_!; ??????] ? ?
Кажется, я только что доказал, что P ? NP
UPD: Но хабр мои эмодзи злобно изуродовал, доказывая, что поддержки unicode до сих пор нет.
А ведь там было доказательство…
Не используйте юникод для важных вещей.Mr_Kibernetik
12.06.2017 15:47При таком подходе, стоит ли вообще пользоваться компьютером для передачи настолько важной информации? Наскальная живопись в специально отведенных для этого местах уже прошла проверку временем и вполне подходит для записи доказательств с помощью эмодзи, разве нет?
Кстати нужно отметить, что хабр хорошо отобразил код и на русском, и на китайском языке.amarao
12.06.2017 16:03У меня есть значительная уверенность, что у ASCII проходимость и выживаемость значительно лучше, чем у всяких fancy unicodes.
novice2001
В общем-то программа пишется на языке программирования, а отнюдь не на английском.
Другое дело, что, как правило, для записи используется латиница.
Mr_Kibernetik
Если вы обратите внимание на ключевые слова различных языков программирования и на названия функций многочисленных API, то они написаны не просто на латинице, а именно на английском языке: while, for, string, public, integer, double. Или эти слова для вас — просто латиница и они вовсе не на английском языке?
novice2001
Наличие заимствованных слов английского происхождения не делает ни один язык программирования английским. То же самое касается и естественных языков. Язык языком делает в первую очередь его грамматика, а не лексика.
Mr_Kibernetik
Очень хорошо. Если вы считаете этот момент принципиальным, то давайте фразу «использование английского языка» в языке программирования заменим на «использование заимствованных слов английского происхождения». Стало намного легче, а главное изменился смысл? От такой переформулировки мы разве перестанем использовать обязательные английские слова в языках программирования?
novice2001
Да, смысл изменился. Мы используем кучу заимствованных слов английского происхождения, но от этого русский язык не перестает быть русским.
А программы пишутся исключительно на языках программирования.
teifo
Странный способ заимствования однако. Полностью брать слово сохраняя его написание на языке источнике — довольное редкое, уникальное явление для русского языка. На мой взгляд тут ближе использование английского языка самого по себе, чем заимствование из него в русский.
novice2001
Во-первых, причем тут именно русский язык? Я писал о естественных языках вообще. Что касается конкретно русского, то в нем огромное количество слов заимствованных 1-в-1, но записанных кириллицей вместо латиницы. Например, byte — байт, computer — компьютер и т.п.
Во-вторых, заимствованные слова в естественных языках приспосабливаются к уже существующей грамматике и фонетике. Если же язык искусственный, создающийся с нуля, то нет никакой необходимости в приспособлении.
В-третьих, само выражение «основной код программы пишется на английском языке» будет истинным только в том случае, если кто-нибудь напишет компилятор английского языка.
Здесь все-таки не гуманитарии собрались, поэтому стоит использовать более строгие и точные выражения.