Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 42
В общем-то программа пишется на языке программирования, а отнюдь не на английском.
Другое дело, что, как правило, для записи используется латиница.
Другое дело, что, как правило, для записи используется латиница.
Если вы обратите внимание на ключевые слова различных языков программирования и на названия функций многочисленных API, то они написаны не просто на латинице, а именно на английском языке: while, for, string, public, integer, double. Или эти слова для вас — просто латиница и они вовсе не на английском языке?
Наличие заимствованных слов английского происхождения не делает ни один язык программирования английским. То же самое касается и естественных языков. Язык языком делает в первую очередь его грамматика, а не лексика.
Очень хорошо. Если вы считаете этот момент принципиальным, то давайте фразу «использование английского языка» в языке программирования заменим на «использование заимствованных слов английского происхождения». Стало намного легче, а главное изменился смысл? От такой переформулировки мы разве перестанем использовать обязательные английские слова в языках программирования?
Странный способ заимствования однако. Полностью брать слово сохраняя его написание на языке источнике — довольное редкое, уникальное явление для русского языка. На мой взгляд тут ближе использование английского языка самого по себе, чем заимствование из него в русский.
Во-первых, причем тут именно русский язык? Я писал о естественных языках вообще. Что касается конкретно русского, то в нем огромное количество слов заимствованных 1-в-1, но записанных кириллицей вместо латиницы. Например, byte — байт, computer — компьютер и т.п.
Во-вторых, заимствованные слова в естественных языках приспосабливаются к уже существующей грамматике и фонетике. Если же язык искусственный, создающийся с нуля, то нет никакой необходимости в приспособлении.
В-третьих, само выражение «основной код программы пишется на английском языке» будет истинным только в том случае, если кто-нибудь напишет компилятор английского языка.
Здесь все-таки не гуманитарии собрались, поэтому стоит использовать более строгие и точные выражения.
Во-вторых, заимствованные слова в естественных языках приспосабливаются к уже существующей грамматике и фонетике. Если же язык искусственный, создающийся с нуля, то нет никакой необходимости в приспособлении.
В-третьих, само выражение «основной код программы пишется на английском языке» будет истинным только в том случае, если кто-нибудь напишет компилятор английского языка.
Здесь все-таки не гуманитарии собрались, поэтому стоит использовать более строгие и точные выражения.
#!/usr/bin/env python3
напечатать = print
приветствие = 'Hello, World'
напечатать(приветствие)
Python 3.5.2, работает без видимых проблем, документация разрешает не только латинские буквы.
А грамматические структуры самого Python тоже могут быть на русском если это нужно? Или получится англо-русская каша в коде?
Нет, не могут быть, они могут быть только на языке Python, но ведь у вас они тоже не могут быть на другом языке.
Я подробно описал, что в SPL нет никакой необходимости в латинице и привел примеры. Где вы там видите латино-русский микс в коде?
А где в моем комментарии вы видите что-то про латиницу?
но ведь у вас они тоже не могут быть на другом языке.
На каком «другом языке» не могут быть команды SPL? Другом по сравнению с каким? Я подробно описал, что в SPL ключевых слов нет совсем, ни на каком языке. Поэтому что вы имеете в виду под «другим языком»?
Очевидно, другом по сравнению с SPL. Например, у вас вместо ключевых слов странные закорючки вроде ?, но это тоже слово языка, непонятного, но тем не менее языка, не английского, но тем не менее языка. Заменить? на какую-нибудь другую произвольную закарючку не получится. Т. е. у вас «гараммтические конструкции» тоже не могут быть на «другом языке».
Вы правы. Но подобный «язык» позволяет легко избежать латино-нелатинского микса в коде. Это — одна из особенностей SPL.
- Python (и многие другие) тоже позволяет избежать микса — используйте только ланиницу и микса не будет;
- вы избегаете микса ценой замены слов известных довольно солидной части человечества на понятные только избранным закарючки.
«Особенность» — это очень хороше слово, чтобы описать данную ситуацию.
Вы невозможность выдаете за норму, а возможность — наоборот за недостаток. Зачем?
Невозможность чего я выдаю за норму?
Невозможность использовать не английский язык при написании кода, при этом не создавая латино-иностранный микс.
Я вам показал, что Python здесь не сравнить с SPL, потому что в SPL это возможно, а в Python — нет.
Я вам показал, что Python здесь не сравнить с SPL, потому что в SPL это возможно, а в Python — нет.
Так и я вам вроде вполне доходчиво объяснил, что не смотря на то, что вы не используете английский язык, вы используете другой язык, но это тоже язык и вы тоже не можете от него отойти в SPL.
Итого что мы имеем:
В вашем языке можно создать микс из закорючек и любого другого языка, в Python можно создать микс из английского и любого другого языка. В чем принципиальная разница? Вы одну невозможность заменили другой и что дальше-то?
Итого что мы имеем:
- Python со своей невозможностью отойти от одного из самых широко распространенных в мире языков;
- SPL с невозможностью отойти от одного из самых нероспрастраненных в мире языков.
В вашем языке можно создать микс из закорючек и любого другого языка, в Python можно создать микс из английского и любого другого языка. В чем принципиальная разница? Вы одну невозможность заменили другой и что дальше-то?
То, что вы называете «закорючками», присутствует в любом языке программирования. Или в Питоне нет этих знаков? Они точно так же есть. Но в Питоне есть ЕЩЕ и ОБЯЗАТЕЛЬНЫЕ английские слова, а в SPL в них нет надобности.
Важно ведь не только то, что эти знаки есть в языке, но и для чего они используются. Например, в вашем SPL есть ?, а в Python есть if, но если они обозначают похожие вещи, то какая разница, какую строчку вы для этого будете использовать? Или вам принципиально претит именно использованалие английских слов для таких конструкций, но при этом знаки препинания для таких вещей это ок?
Я нигде не писал, что мне что-то «претит». Статья о том, что в SPL возможно написание кода используя любой национальный язык, при этом не получая латино-иностранного микса. Подобную возможность вряд-ли можно встретить в других языках программирования. И я описал благодаря чему это достигается.
Вряд-ли в моей статье вы найдете осуждение чего-либо. Наоборот в ней описаны возможности.
Вряд-ли в моей статье вы найдете осуждение чего-либо. Наоборот в ней описаны возможности.
Вы достигли этого заменив английские слова на занки препинания, и таким образом заменили одну невозможность на другую, и я вам это уже выше объяснил.
Итого в остатке мы имеем просто замену слов известных большей части человечества, на непонятные знаки со смыслом не известным большей части человечаства только из соображения «избегания латино-иностранного микса».
Итого в остатке мы имеем просто замену слов известных большей части человечества, на непонятные знаки со смыслом не известным большей части человечаства только из соображения «избегания латино-иностранного микса».
Почему это не в "ненормальном программировании"? ;)
Считаю использование юникода в именах переменных совершенно непреемлемым. Программирование, и в особенности open source — это международное явление. И как например американскому или российскому программисту редактировать код с китайскими иероглифами вместо переменных? Если американец еще сможет визуально идентифицировать буквы русского алфавита, то китайские символы для европейца просто неотличимы друг от друга. Как их называть? «Такая вертикальная палочка с двумя горизонтальными палочками внизу, двумя по сторонам и тремя черточками сверху с хвостиком???».
А еще есть куча похожих символов. Русская и латинская 'a' например. И что если кому-то придет светлая мысль смещать символы разных языков в коде?
А еще есть куча спецсимволов. Математических, технических, смайлики наконец.
А еще есть управляющие символы, есть всякие хитрые пробелы и прочая муть.
Короче, я глубоко убежден, что использование юникода в идентификаторах языков программирования должно быть запрещено специальной резолюцией Организации Объединенных Наций.
А еще есть куча похожих символов. Русская и латинская 'a' например. И что если кому-то придет светлая мысль смещать символы разных языков в коде?
А еще есть куча спецсимволов. Математических, технических, смайлики наконец.
А еще есть управляющие символы, есть всякие хитрые пробелы и прочая муть.
Короче, я глубоко убежден, что использование юникода в идентификаторах языков программирования должно быть запрещено специальной резолюцией Организации Объединенных Наций.
А еще есть куча похожих символов. Русская и латинская 'a' например. И что если кому-то придет светлая мысль смещать символы разных языков в коде?
Уже сталкивался с таким, будучи студентом, кстати) Не вспомню сходу сайт, но там был фрагмент кода на C#, который после copy-paste упорно не компилировался с неадекватными ошибками. Оказалось, что буквы 'о' и 'а' рандомно то кириллица, то латиница.
До сих пор не пришел к выводу, это было сделано сеошниками для соблюдения уникальности, где-то прошло через ПО для обхода антиплагиат-систем, или просто следствие специфического чувства юмора автора
Рискну с Вами поспорить, так как далеко не весь код имеет отношение к международному явлению. В своей практике имел опыт разработки приложения, предназначенного исключительно для отечественного потребителя, которое должно было хранить большое количество текстовых данных, получаемых от пользователя. Так вот, названия полей для этих данных имели непонятные мне аббревиатуры и плохо переводимые термины. Между транслитерализацией и кириллицей, скрипя сердцем, было отдано предпочтение последней. В результате я получил имена переменных, методов и полей и таблиц БД на кириллице. О принятом тогда решении не жалею, так как читаемость кода, по сравнению с тем же транслитом, оказалась намного выше.
Однако, смею добавить, что делать так нужно только в самом крайнем случае.
Однако, смею добавить, что делать так нужно только в самом крайнем случае.
Еще со школы мы приучены писать
Ещё со школы мы приучены, что sin(x) — это латынь =) Сюда же стороны треугольника А(а) B(б) С (ц)
Странно, что никто до сих пор не упомянул 1С-Бухгалтерию. Технически в ней можно программировать на английском, но все пишут по-русски. И тут в общем всё оправданно, потому что наши ПБУ сильно отличаются от международных стандартов МСФО, и многие вещи в принципе не имеют переводов на английский, потому что в англоязычном мире их просто не существует.
называется happydebugging!
«Add».Length == «Add».Length
Забавно. Как только сообщество некоего языка узнаёт, что в нём нельзя использовать юникод в идентификаторах, начинаются дикие вопли. При этом то же сообщество считает плохим код с не-английскими идентификаторами, и даже транслит.
Вообще же, как по мне, ключевые слова и идентификаторы должны быть только латиницей, чувствительные к регистру, но при этом с запретом иметь два идентификатора, отличающиеся только регистром букв. А в идеале ещё и линт иметь, считающий расстояние Хэмминга.
У меня есть даже более простой тест. Делаем рендеринг текста в изображение, потом OCR. Если текстовая часть (за вычетом пробелов) различается, тест на адекватность используемых символов не пройден.
Можно использовать шрифты с явно различающимися нулями, 1/l/I, но это всё равно не поможет в условиях русского o на месте английского, так что тест будет разумным.
Можно использовать шрифты с явно различающимися нулями, 1/l/I, но это всё равно не поможет в условиях русского o на месте английского, так что тест будет разумным.
По мне, так эта возможность — шаг вперёд в развитии ЯП.
Постороннее замечание: господа программисты, прежде чем назвать что-либо трехбуквенным сокращением, трижды подумайте, не будет ли коллизии с уже существующими аббревиатурами!
Постороннее замечание: господа программисты, прежде чем назвать что-либо трехбуквенным сокращением, трижды подумайте, не будет ли коллизии с уже существующими аббревиатурами!
brainfuck не использует национальных алфавитов вообще, переносимость и читаемость кода специалистами не страдает :)
������.������ ~������������ ������������������������♂️; ~= [ ������♂️ ������_!; ������] ⊇ ℵ
Кажется, я только что доказал, что P ⊂ NP
UPD: Но хабр мои эмодзи злобно изуродовал, доказывая, что поддержки unicode до сих пор нет.
А ведь там было доказательство…
Не используйте юникод для важных вещей.
Кажется, я только что доказал, что P ⊂ NP
UPD: Но хабр мои эмодзи злобно изуродовал, доказывая, что поддержки unicode до сих пор нет.
А ведь там было доказательство…
Не используйте юникод для важных вещей.
При таком подходе, стоит ли вообще пользоваться компьютером для передачи настолько важной информации? Наскальная живопись в специально отведенных для этого местах уже прошла проверку временем и вполне подходит для записи доказательств с помощью эмодзи, разве нет?
Кстати нужно отметить, что хабр хорошо отобразил код и на русском, и на китайском языке.
Кстати нужно отметить, что хабр хорошо отобразил код и на русском, и на китайском языке.
Вы лучше посмотрите, какие буковки используют программисты на Agda!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Применение национальных языков в программировании на SPL