Comments 42
казалось бы, причём здесь 1С :)
бывает еще и код латиницей в каком-нибудь испанском языке, даже со словарем непросто работать
Ну не правда же, получаюСообщение будет receivingMessage
А вы состояние и методы не путаете?
mailClient.receiveMessages() — метод
mailClient.receivingMessages — состояние объекта.
mailClient.receiveMessages() — метод
mailClient.receivingMessages — состояние объекта.
А английский по вашему не национальный язык? Для Великобритании — вполне себе национальный, для остального мира — де факто международный. И смешивать парадигму (процедурный подход, функциональный, оо) с разговорным языком — странно.
английский стал латынью для электроники, любое сообщение закодированные в ASCII или английской части UTF-8 будет корректно отображаться практически в любых условиях, а вот с другими языками такого нет. Поэтому он на особом положении, а почему это так я как раз и попытался сформулировать в заметке.
А где связь между UTF-8 и электроникой?
вы причину и следствие не путаете?
Во-первых: если для человека, код написанный на национальном языке выглядит «говнецом», независимо от качества кода/ эффективности решения, то проблема может быть в человеке, а не в национальном языке. Потому что завтра этот же человек код написанный на (допустим) java посчитает «говнецом». Всю корпоративную систему переписывать, чтобы ему угодить?
Во-вторых, по поводу кода на нац. языке вообще. Я как 1С-ник, считаю (и книги по DDD со мной косвенно согласны), что как минимум, при использовании национального языка удобно работать, если основной язык общения в команде (а соответственно документация, технические задания и комментарии в коде) национальный. ИМХО, совпадение названий терминов предметной области («доменной логики») и объектов/методов/переменных в коде — это удобно. Явно лучше, чем придумывать или переводить со словарем в обе стороны или писать транслитом. При этом, когда заказчики были из Польши удобнее оказалось использовать английский язык (благо у 1С есть варианты).
Ну и в-третьих. Невозможность использовать нац.языки из-за неполной поддержки utf в конкретных средах разработки, например, это повод исправлять ошибки поддержки utf, а не отказываться от использования нац. языка там, где это удобно.
Я не настоящий сварщик, но была необходимость немного поработать с java ee. И я словил проблемы с настройкой tomcat и glassfish, из-за того что у меня имя учетки в Windows кириллическое (на SO в том числе рекомендовали еще и не использовать пути с пробелами, но с этим пронесло). И вот мне кажется, что проблема в программе, потому что точно такие же проблемы с ней может потом словить и пользователь, который не знал, что нельзя хранить данные в папках с названиями не на английском или не дай бог вносил в корпоративную систему информацию на национальном языке (это ведь «говнецо» с точки зрения разработчика).
Во-вторых, по поводу кода на нац. языке вообще. Я как 1С-ник, считаю (и книги по DDD со мной косвенно согласны), что как минимум, при использовании национального языка удобно работать, если основной язык общения в команде (а соответственно документация, технические задания и комментарии в коде) национальный. ИМХО, совпадение названий терминов предметной области («доменной логики») и объектов/методов/переменных в коде — это удобно. Явно лучше, чем придумывать или переводить со словарем в обе стороны или писать транслитом. При этом, когда заказчики были из Польши удобнее оказалось использовать английский язык (благо у 1С есть варианты).
Ну и в-третьих. Невозможность использовать нац.языки из-за неполной поддержки utf в конкретных средах разработки, например, это повод исправлять ошибки поддержки utf, а не отказываться от использования нац. языка там, где это удобно.
Я не настоящий сварщик, но была необходимость немного поработать с java ee. И я словил проблемы с настройкой tomcat и glassfish, из-за того что у меня имя учетки в Windows кириллическое (на SO в том числе рекомендовали еще и не использовать пути с пробелами, но с этим пронесло). И вот мне кажется, что проблема в программе, потому что точно такие же проблемы с ней может потом словить и пользователь, который не знал, что нельзя хранить данные в папках с названиями не на английском или не дай бог вносил в корпоративную систему информацию на национальном языке (это ведь «говнецо» с точки зрения разработчика).
ну есть термин «говнокод» и я просто хотел его даже сгладить, пожалуй поправлю.
Насчет языка, разработка ПО штука очень международная, а языков национальных очень много и проще всем выучить какой-то один дополнительный язык хотя бы до уровня со словарем (вот я учу китайский еще полгода и пока не достиг такого и близко), и так исторически сложилось, что это английский, но это оказалось правильным потому что английский подходит для записи кода.
Насчет языка, разработка ПО штука очень международная, а языков национальных очень много и проще всем выучить какой-то один дополнительный язык хотя бы до уровня со словарем (вот я учу китайский еще полгода и пока не достиг такого и близко), и так исторически сложилось, что это английский, но это оказалось правильным потому что английский подходит для записи кода.
Да тут как слово не меняй, смысл претензии-то не меняется. Вы оцениваете код исходя из своих представлений о прекрасном. Табы против пробелов и все такое.
Насчет международного языка. Да, так вышло что английский это международный язык и исторически сложилось, что ЯП тоже на английском. Но вот «удобство» в данном случае это не причина и не следствие. Это «подгонка под ответ», т.е. попытка убедить себя что выбор языка был сделан правильно и поиск для этого аргументов.
Пример утрированный: для ООП с множественным наследованием, вполне хорошо бы подошел немецкий, с их любовью к многокоренным словам. Каждый корень слова — название класса. Написал какое-нибудь «VerkehrsInfrastrukturFinanzierUngSgesellschaft» и сразу разработчику понятна вся иерархия классов.
А вот для реализации паттернов, возможно, было бы удобно иероглифами с помощью «манипулятора типа кисть» пользоваться. Этакая UML + код в одном флаконе. Толщиной кисти варьировать типы связей между классами.
Про эсперанто я вообще молчу. Все те же бонусы что и в английском, а язык проще и никому не «обидно».
Насчет международного языка. Да, так вышло что английский это международный язык и исторически сложилось, что ЯП тоже на английском. Но вот «удобство» в данном случае это не причина и не следствие. Это «подгонка под ответ», т.е. попытка убедить себя что выбор языка был сделан правильно и поиск для этого аргументов.
Пример утрированный: для ООП с множественным наследованием, вполне хорошо бы подошел немецкий, с их любовью к многокоренным словам. Каждый корень слова — название класса. Написал какое-нибудь «VerkehrsInfrastrukturFinanzierUngSgesellschaft» и сразу разработчику понятна вся иерархия классов.
А вот для реализации паттернов, возможно, было бы удобно иероглифами с помощью «манипулятора типа кисть» пользоваться. Этакая UML + код в одном флаконе. Толщиной кисти варьировать типы связей между классами.
Про эсперанто я вообще молчу. Все те же бонусы что и в английском, а язык проще и никому не «обидно».
ну код это как раз об прекрасном, точнее есть понятие элегантный код и есть противоположные ему. Вот немецкий в вашем примере как раз совсем не подходит под понятие элегантность. Понятно, что практические соображения можно какие-то придумать, но исходить только из удобства это недальновидно когда речь идет о разработке ПО, именно сиюминутное удобство (быстрота решения задачи) часто становится причиной плохо читаемого и также плохо работающего кода, который может еще обрасти костылями и стать пугалом на проекте, даже если тот восновном ничего.
Ну вы же понимаете, что если человек пишет говнокод, то он его будет писать хоть на русском, хоть на английском? Т.е. причина вообще не в языке?
конечно, последнее предложение в заметке как раз об этом, если вы придерживаетесь некоторых рекомендаций к которым относится использование латиницы и английского, то некоторый шанс получить объективно элегантный код есть, а иначе вряд ли
Не так. «Если в команде принято писать код на английском и в определенном стиле — надо писать его на английском и в определенном стиле». Не более.
«Элегантность» и «объективность» в одном предложении ставить нельзя. Это субъективная оценка, все-таки. И уж точно она не зависит только от языка (что английского, что ЯП).
«Элегантность» и «объективность» в одном предложении ставить нельзя. Это субъективная оценка, все-таки. И уж точно она не зависит только от языка (что английского, что ЯП).
Кстати, с помощью эсперанто на одном из проектов решили проблему конфликта имён/суффиксов/префиксов в доменной области и технической. Технические типа репозитории, сервис, модель, контроллер и т. п. — на английском, а доменные — на эсперанто. Вся команда, включая БА, ПО, ПМ называла их на эсперанто (каждый со своим "акцентом", но понятно в принципе)
А еще раньше был ASM и перфокарты. Проблем с национальными языками в принципе не было.
Коллега если вы профессионал, то какая разница, на чем делать ПО?
Коллега если вы профессионал, то какая разница, на чем делать ПО?
Даже если предположить, что мысль хорошая, вот такое её изложение полноценным постом считаться не может.
поэтому код который пишут на национальный языках практически всегда выглядит «говнокодом» в глазах смотрящего, а на английском есть шанс, что он будет воспринят благодушно в независимости от того в какой парадигме думает каждый программист.
Божественно. Это первый шаг к тому, чтобы считать достойными писать код только представителей англоговорящих стран и лиц к ним примазавшихся, а затем и только коренных носителей языка. Вот почему народ так тянет в расизм, неужели всё настолько плохо в самоутверждении без этого?..
Проблема с использованием русского языка в коде ИМХО таится в нескольких вещах:
- С советских времён всё (абсолютно ВСЕ) забили на локализацию терминологии и поэтому всё кажется вымученным и не естественным, поскольку является либо подстрочным переводом либо транслитерацией в кириллицу английских терминов.
- Начитавшись литературы и документации на английском языке, народ начинает воспринимать код с точки зрения английского, и этот код кажется пародией и «говнокодом». Начитаться всего этого на родном языке сложно, с переводами у нас всё плохо. Даже документацию легко найти на немецком китайском и японском. Бывает даже польский. С русским всегда какая-то хрень, либо он отсутствует.
- Все языки программирования спроектированы под английскую раскладку, и набирать код на русской не удобно.
Все эти проблемы легко решаются, если стоит такая задача, однако легче признать русский отстоем и им не пользоваться. А потом на конференции Яндекса процент употребления русского по отношению к английскому в выступлении иностранца и носителей языка получается равным. Но иностранец язык знает не совершено, а носители знать не хотят…
коренных носителей английского среди разработчиков как раз не так то много, гораздо больше каких-нибудь филипинцев или индусов с китайцами, этот факт только подчеркивает значимость английского в коде, т.к. даже программируя в узкой нише не использовать их наработки будет только сложнее
Все языки программирования спроектированы под английскую раскладку, и набирать код на русской не удобно.
Это должно идти первым пунктом.
Но тут проблема не столько в том, что язык "спроектирован под раскладку", сколько в том что в русской раскладке просто нету столько небуквенных символов, сколько есть в английской. А ведь зачастую именно они больше всего влияют на читаемость программы.
UFO just landed and posted this here
В английском свои странности:
© Eeyore
I
And all your friends
Sends--
I mean all your friend
Send--
(Very awkward this, it keeps
going wrong)
Well, anyhow, we send
Our love
END
© Eeyore
Sign up to leave a comment.
Английский код