Comments 153
Названа в честь магистра Йоды за инвертированный порядок слов.
Магистра Йоды в честь названа, слов порядок инвертированный за. (кажется, это ближе всего выходит к йода-спику, который, вроде, сложнее просто инверсии)
Очень полезный и неожиданный взгляд.
Читал с интересом
Большое вам спасибо, что оценили мою работу с такой стороны!
Я ни в коем случае не претендую на звание инженера, а лишь хотел поделиться своими наблюдениями и пообщаться с профессионалами в этой области. Поражен, что многие оказались настолько невосприимчивы.
Я сейчас работаю над продолжением цикла, буду признателен, если вы уделите время и прочитаете мою следующую статью! Она обещает быть ещё интереснее :)
В точку! ИТ-индустрия деградировала настолько, что программистами теперь считают себя не только технари, освоившие примитивный веб и погрязшие в теории, но даже филологи. А мы потом удивляемся, почему всё глючит и требует всё более мощного железа. Браво!
Мне кажется, это наоборот очень полезно. Сочетание программирования и филологии может как раз помочь в совершенствовании разработки новых, «ориентированных на человека» систем, а также улучшить существующие практики преподавания программной инженерии.
There are only two hard things in Computer Science: cache invalidation and naming things.
— Phil Karlton
Идеальный комментарий, спасибо! Вы привели вторую половину уравнения, которое я пытался решить в статье. Все знают, что именование — это сложно. Но ПОЧЕМУ?
Мне кажется, ответ как раз в том, что программисты пытаются решить лингвистическую проблему инженерными методами. А это как пытаться отладить сонет с помощью дебаггера.
Моя статья — это, по сути, попытка применить филологический инструментарий к этой «второй самой сложной вещи».
Это сложно потому, что наш "рабочих набор" слов и понятий довольно маленький (не общий словарный запас, а те слова, которые "под рукой"). Особенно на иностранном языке, всё же приличные люди используют в программах английскую лексику.
Кроме того, хочется выбрать короткое слово. Иначе задолбаешься его потом каждый раз вколачивать.
В хорошо написанной программе присутствует система наименования вещей, и она консистентна. Удобно, когда однородным объектам даются однородные имена. И, скажем, если я вижу класс по имени DeviceLocator, я вправе ожидать, что описан он будет в файле по имени devicelocator.xxx, а не discoveryservice.xxx - иначе как мне искать его реализацию среди нескольких сотен файлов?
Ну и наконец, хочется выбрать уместное слово с учётом контекста, а не просто прямой перевод по словарю - там будет много вариантов, которых я в жизни не встречал, и непонятно, подойдут ли они, если родной язык читателя не русский.
Всё это не упрощает выбор имен для сущностей.
В вашей статье есть один существенный недостаток: вы рассуждаете о наименовании понятий ("ошибка Гейзенберга"), но сказать пытаетесь о наименовании переменных и функций.
Никто не назовёт свой класс godObject или свою функцию SpaghettiCode (хотя с радостью используют эти слова, чтобы охарактеризовать, но не назвать, какое-либо место в программе).
Кроме того, название переменной tmp вполне выразительно, если время жизни этой переменной - три строчки, и фактически она возникла, чтобы разнести длинную строку на несколько более коротких, положив промежуточный результат во временную переменную.
Спасибо вам за такой невероятно глубокий и подробный комментарий! Это именно тот уровень дискуссии, на который я надеялся. Вы затронули несколько абсолютно ключевых моментов, которые заслуживают отдельного обсуждения.
Вы совершенно правы в своем главном тезисе: никто в здравом уме не назовет класс godObject. И здесь вы нащупали самый тонкий момент. Такие имена, как Heisenbug или spaghettiCode, — это не переменные, это прозвища, которые само сообщество дает определенным феноменам в коде. Скорее, я этим хотел показать, что когнитивный механизм, по которому мы даем эти прозвища феноменам, и механизм, по которому мы ищем удачное имя для переменной, — один и тот же. И там, и там мы пытаемся ухватить суть явления и упаковать ее в одно слово.
И ваши практические наблюдения — лучшее тому подтверждение:
«Маленький рабочий набор слов», «хочется короткое слово» — абсолютно! В лингвистике это называется диалектикой принципа экономии усилий и принципа ясности. И поиск идеального имени — это всегда компромисс между этими двумя силами.
«Система наименования... консистентна» (
DeviceLocatorвdevicelocator.xxx) — блестящий пример! По сути, вы описываете создание того, что в лингвистике называется проектным социолектом. Команда договаривается о своем внутреннем «языке», и следование ему — залог выживания.«...хочется выбрать уместное слово с учётом контекста, а не просто прямой перевод» — вы сейчас сформулировали главную задачу филологии! Работа с уместностью, коннотациями и контекстом — это и есть то, чем филологи занимаются всю жизнь.
И насчет tmp — вы на 100% правы. Для переменной, которая живет три строки, tmp — идеальное имя, потому что ее семантика полностью определяется из сверхблизкого контекста. Проблемы начинаются, когда этот «временный» tmp выживает на протяжении 50 строк и уходит в другую функцию, не так ли? :)
Спасибо еще раз за ваш комментарий. Вы дали мне огромную пищу для размышлений и, по сути, идеально дополнили статью с точки зрения практикующего инженера.
LLM-ки торчат уши из текста этого
В самое ближайшее время я планирую выпустить следующую часть своего авторского цикла, а именно: статью про контекстуальную вариативность и идиоматитчность. Буду весьма признателен, если вы будете и дальше следить за следующими публикациями, чтобы убедиться в ясности и естетсвенности моих мыслей, абсолютно лишенных каких-либо признаков цифрового следа. Более того, в своей кандидатской диссертации я критикую современные большие языковые модели за их семантические ошибки, так что мне нет нужды прибегать к их использованию для таких простых обсуждений :)
Вот да, странность: стили написания комментариев очень похож на одного тут философа, который и доцент, и управленец... Использование восклицательных знаков и похвал комментариям, избыточное выделение жирным шрифтом... Что это, эксперимент?
Всё гораздо проще — это была моя первая статья и первые комментарии, поэтому я старался сделать всё максимально аккуратно и качественно, затрачивая время на ответы каждому, принося благодарности и красиво оформляя текст. Я не учел одну вещь: здесь большинство общается «как придётся», абсолютно не заморачиваюсь по поводу вежливости и правил приличия.
Пожалуйста, покиньте мою страницу, вы дискутируете абсолютно не по теме моей публикации
Вы не учли не только одну вещь. Вы не учли также, что здесь в принципе не обязательно "дискутировать по теме публикации": обсуждения вполне могут зайти в сторону и в дебри. Как и на любом другом публичном ресурсе с комментариями.
Еще любопытно: сомнения высказали многие, указали на ваш стиль тоже, но покинуть "вашу страницу" вы просите именно меня — спорившего с тем философом. Тоже наводит на мысли.
Когда вы едете в лифте с соседями, вы просите их покинуть лифт, когда они дискутируют не по теме вашей диссертации?
Старинный обычай - разговор с копипастой LLM
Работа с уместностью, коннотациями и контекстом — это и есть то, чем филологи занимаются всю жизнь.
а программисты еще при этом код пишут. Причем работающий в виде каких-то приложений...
если я вижу класс по имени DeviceLocator, я вправе ожидать, что описан он будет в файле по имени devicelocator.xxx, а не discoveryservice.xxx - иначе как мне искать его реализацию среди нескольких сотен файлов?
Нажмите хоткей "перейти к классу по имени" в вашей любимой IDE.
Ну, ждал от кого-нибудь такого ответа.
Поверьте, это ОЧЕНЬ удобно в большом проекте, когда разные сущности, имеющие отношение к одной и той же вещи, названы консистентно между собой.
Что для вас "большой" проект? Я работал на проектах с десятками-сотнями тысяч файлов. Хоткей в IDE рулит.
И что это доказывает? Что вам достаточно хоткея в IDE? Ну, ОК.
Народная мудрость: чем круче джип, тем дальше бежать за трактором.
IDE, безусловно, выручает. Но только до какого-то предела. Испытывать границы возможностей среды при создании кода -- дело неблагодарное. Гораздо лучше не выделываться и помнить о гайдлайнах, конвенциях наименования, хороших практиках и т.д.
Мне больше нравится вариант "...две вещи - инвалидация кэша, придумывание названий и ошибки на единицу" )
Да уж, это точно ещё одна большая сложность, о которой все знают не понаслышке. Вы абсолютно правы!
Отличное дополнение к канону! :)
Да, это хороший вариант.
А не знаете, у него есть автор, или "музыка народная, слова тоже мои"?
Насколько мне известно, это как раз тот случай, когда «музыка народная». Исходная, каноническая цитата принадлежит легендарному программисту Филу Карлтону и звучит именно так, как ее привел первый комментатор: «There are only two hard things in Computer Science: cache invalidation and naming things». А вот добавление про «ошибки на единицу» (off-by-one errors) — это уже блестящий пример IT-фольклора.
Знаете, это напомнило мне забавную параллель, с которой я столкнулся, когда работал над диссертацией. Я пытался найти, кто и когда впервые ввел сам термин «язык программирования». И оказалось, что у этого фундаментального для всей IT-индустрии понятия, как и у вышеупомянутого афоризма, нет одного-единственного, общепринятого автора. Он так же органически вырос из самого сообщества, став «народным».
На мой взгляд, это лучшее доказательство того, что мы имеем дело с живым, исторически эволюционирующим культурным феноменом, который развивается по законам естественного человеческого языка.
Сюда же примыкают две основных ошибки.
Основная ошибка математики: где мы потеряли знак?
Основная ошибка физики: где надо поделить на два?
Нет, код, увы это не гуманитарная дисциплина. Нейминг внутри кода - может быть.
Для себя я определил очень простые пункты для понятного именования:
называть так, чтобы можно было понять в текущем контексте что это
текущий контекст - это модуль + класс + фя (в простом приближении)
не добавлять у именам название контекста - те Array.isArray - это очень плохо
имена формировать как "что" (существительное) + "делает" (глагол), например emailValidate
lowerCamelCase
Но вообще все ИМХО, главное чтобы был описанный стандарт, принятый в команде и все его придерживались.
Спасибо за такой развернутый и вдумчивый комментарий! Вы абсолютно правы в главном: ключ к успеху — это «описанный стандарт, принятый в команде». Моё исследование как раз и является попыткой заглянуть «под капот» такого стандарта и понять, на каких фундаментальных, почти интуитивных принципах он строится.
И ваши правила — блестящий тому пример. Смотрите:
«Называть так, чтобы можно было понять в текущем контексте» — это же и есть требование к созданию семантически прозрачного знака.
А ваша формула «"что" + "делает"» (emailValidate) — это классический пример того, что филологи называют именем с ясной «внутренней формой».
Возможно, я был слишком провокационен в заголовке :) Моя цель — не сказать, что код это гуманитарная дисциплина, а показать, что инструменты гуманитарных наук могут быть невероятно полезны для решения наших с вами инженерных задач. Ведь, по сути, любой стандарт, о котором вы пишете, — это и есть тот самый язык, на котором команда договаривается общаться.
Спасибо еще раз, что поделились своей системой. Очень интересно, это результат вашей личной практики или вы пришли к нему вместе с командой?
Но вообще все ИМХО, главное чтобы был описанный стандарт, принятый в команде и все его придерживались.
А еще лучше - инструментарий, который мягко но настойчиво навязывает этот стандарт.
Надо же!!! аша мысль про «инструментарий, который навязывает стандарт» — это просто в яблочко! Это именно та проблема, над решением которой я сейчас работаю.
Ведь главный вопрос — как создать такой стандарт, который не будет отторгаться командой, а станет ее «второй натурой»? Простые линтеры проверяют синтаксис, но не семантику.
Именно поэтому я сейчас разрабатываю целый междисциплинарный спецкурс для инженеров. Его главная цель — дать команде не программный, а ментальный инструментарий: общий язык и систему понятий (из филологии и риторики), которые позволяют создавать и поддерживать такие стандарты изнутри, на уровне мышления.
Так что спасибо вам огромное — вы идеально сформулировали миссию того, что я пытаюсь сделать!
Это не я придумал. Это стандартная практика в мире Go. Любой редактор, который понимает Go на уровне подсветки синтаксиса, заодно принудительно его форматирует.
Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.
Это в том смысле, что никому не нравится сам по себе стиль gofmt, но всем нравится иметь единый стиль.
Поначалу это раздражает, через неделю привыкаешь и понимаешь, что это именно то, чего так не хватало в других средах программирования.
Эти ребята не писали на эту тему умных статей, они это просто сделали (но надо понимать, что это не просто ребята, а те самые ребята, которые придумали UNIX, C и заложили основу контейнеров и много чего еще).
И получается, что нет нужды придумывать некий идеальный стиль, который понравится всем. Ценность возможностi использовать всемирно-общий стиль оправдывает неудобства индивидуальной подстройки под него каждого разработчика.
Тут есть, правда, одна тонкость. Синтаксис Go очень продуман в плане его автоматического анализа. Поэтому tooling очень хорош. Кроме того, стандартная библиотека включает в себя настоящий синтаксический анализатор языка - ровно тот же, которым пользуется компилятор. Т.е., это не угадайка на регулярках, инструменты действительно понимают язык. С более другими языками будет сложнее.
А разве программистам не интересно узнать о том, что они и так давно интуитивно применяют, но на уровне реального систематического знания?
Вся суть моей работы заключается не в том, чтобы вам «открыть Америку», но показать, что почти все принципы написания кода подчиняются законам и моделям естественного человеческого языка. При этом дело вовсе не в том, чтобы найти «идеальный стиль», а прийти к общему стандарту. Это и есть главная моя центральная идея. Однако инженеры неуклонно продолжают это отрицать :)
Я отвечал практическим примером на ваши же слова:
Ведь главный вопрос — как создать такой стандарт, который не будет отторгаться командой, а станет ее «второй натурой»? Простые линтеры проверяют синтаксис, но не семантику.
Моя цель была - ознакомить вас с весьма удачным примером a-priory work в той области, которой вы собираетесь заниматься.
Вы пишете, что «ребята не писали умных статей, они это просто сделали». И это правда. Но кто были эти люди?) Кен Томпсон, Роб Пайк — специалисты с колоссальным, почти сверхчеловеческим опытом, чье интуитивное чувство «хорошего кода» формировалось десятилетиями.
Стиль gofmt не был выбран случайно: это кодификация интуиции гениев. Они инстинктивно выбрали те правила форматирования и стиля, которые, как они чувствовали, лучше всего работают для человеческого восприятия.
Как я уже неоднократно уточнял, моя работа — это попытка сделать именно эту интуицию явной. Дать ей систему и язык. Показать, что интуитивное чувство «хорошего стиля», которое есть у великих и высококомпететных инженеров, на самом деле подчиняется тем самым лингвистическим законам, которые моя статья пытается описать.
Более того, при сравнении gofmt и rustfmt можно увидеть, что это лучшее доказательство моего тезиса. Вы ведь сами описали не технический, а социолингвистический феномен!
Go — это «корпоративный диалект», созданный закрытой группой авторитетных носителей (Google) со своим, немного авторитарным взглядом.
Rust — это «lingua franca», язык, который вырабатывался открытым сообществом и поэтому вобрал в себя более популярные и привычные «речевые обороты» (узус) из мира C++.
Разумеется, конечная цель — это не найти «идеальный стиль», а прийти к общему стандарту; предложить общий язык, на котором программисты могли бы обсуждать и создавать такие стандарты не только на основе интуиции, но и на основе понимания фундаментальных принципов, не говоря уже об очевидной лингвистической природе.
P.S. И да, даже поверх жесткого стандарта форматирования gofmt все равно возникает следующий, более высокий уровень — идиоматичность. И это как раз будет темой моей следующей статьи! Так что — stay tuned, как говорится в цифровом мире :)
Вы пишете, что «ребята не писали умных статей, они это просто сделали». И это правда. Но кто были эти люди?
Ну, я примерно это и сказал. И хотел обратить ваше внимание, что вот, такой опыт существует и успешно используется.
Стиль gofmt не был выбран случайно: это кодификация интуиции гениев.
Стиль gofmt не является чем-то волшебным и время от времени меняется.
Тут интуиция гениев проявила себя не в конкретном стиле, а в том, был реализован и внедрен стиль, который используется повсеместно.
Более того, при сравнении gofmt и rustfmt
Я думаю, что rustfmt родился под прямым влиянием gofmt.
Как, например, Plan9, исследовательская операционная система от тех же людей. Сама по себе не так уж и широко используется, но procfs, sysfs и Linux namespaces - прямое продолжение заложенных в ней идей.
Тут семантическая ошибка в 3 пункте. email не является субъектом валидации, он не делает ее. Это существительное в винительном падеже. Поэтому должен стоять после: validateEmail.
Существительное, которое отвечает на вопрос - "Что делает?" - это и есть контекст - класс. например: EmailValidator. И имя метода в таком случае, чтобы не дублировать контекст, будет просто validate:
validate(email: String)
Браво! Это абсолютно гениальный и стопроцентно точный комментарий. Спасибо вам огромное!
Вы сейчас на практике продемонстрировали главный тезис всей моей статьи. Вы провели безупречный лингвистический анализ имени, разложив его на падежи и части речи, и на основе этого пришли к абсолютно верному инженерному решению. Это и есть лучшее доказательство того, что глубокое, интуитивное чувство языка — ключ к чистому коду.
Вы совершенно правы насчет validateEmail — это действительно более естественный порядок для английского языка (глагол + объект). Мой пример был упрощением, и ваше замечание абсолютно справедливо.
А ваша мысль про EmailValidator.validate() — это уже уровень архитектурного мышления. Вы показали, как контекст(имя класса) берет на себя часть семантической нагрузки, позволяя сделать имя метода еще более лаконичным и точным. Для меня, как для филолога, а не инженера, невероятно ценно видеть, как эти теоретические принципы работают в реальной практике.
Спасибо, что вывели дискуссию на такой невероятный уровень глубины. Именно ради таких комментариев и стоило писать эту статью.
Кстати, а как надо? Array.is?
Тоже об этом подумал. Если Array - это объект, то проверять, что он isArray вообще смысла не имеет. А если это неймспейс, то тут вопрос, возможно что-то вроде Array.isTypeOf(), но если импортировали всё из неймспейса, то останется просто isTypeOf()... Думаю зависит от конкретного языка и того, как обычно это используют.
А что вы, собственно, сказать хотели? Что у людей существует некий ограниченный набор принципов, по которым они называют сущности? И что программисты тоже люди, которые следуют тем же принципам? В чём именно ваше «поразительное» открытие? Если в вашей статье убрать пафос и очевидные истины, то в ней почти ничего не останется.
В целом выводы по именованию переменных, конечно, правильные, но их и до вас придумали. Только я бы заменил соответствующую картинку: никто в здравом уме не назовёт переменные godObject, spaghettiCode или messyData. Это всё антипаттерны, которые характеризуют код, а не именованные сущности этого кода.
Вы абсолютно правы в своем главном наблюдении: никто в здравом уме не назовет класс godObject или функцию spaghettiCode. Это действительно антипаттерны, имена для феноменов в коде, а не для сущностей. И именно в этом, как мне кажется, и заключается самая суть моей гипотезы.
Я пытался сказать не то, что мы так называем переменные, а то, что когнитивный механизм, по которому сообщество дает прозвище уродливому коду (godObject), и механизм, по которому отдельный разработчик ищет удачное имя для переменной (validateEmail), — один и тот же. И там, и там мы пытаемся ухватить суть явления и упаковать ее в яркий, семантически мотивированный знак. godObject — это просто более яркий и гипертрофированный пример этого процесса.
Что касается «очевидных истин». Вы снова правы! Выводы по хорошему именованию не новы — лучшие инженеры приходили к ним интуитивно на протяжении десятилетий. Цель моей работы — не изобрести их заново, а попытаться дать им объяснение и систему через аппарат другой, неожиданной дисциплины. Показать, почему эти «очевидные» истины работают, и почему они так похожи на законы, по которым живет естественный язык.
через аппарат другой, неожиданной дисциплины
Почему неожиданной? Именование сущностей ведь делается на том же самом английском (чаще всего) языке.
Интересно, что невзирая на тот факт, что английский язык является так называемым основным языком-посредником для общения и взаимодействия с машиной посредством кода, никто и никогда не применял лингвистические принципы для его глубокого и детального сравнения и анализа в таком контексте. К тому же, многие до сих пор не согласны с неразрывностью связи языка и мышления в сфере программирования, поэтому это и может показаться неожиданным сравнением, на первый взгляд.
никто и никогда не применял лингвистические принципы для глубокого и детального сравнения и анализа
Вы абсолютно уверены в этом? В научной среде не приняты такие категоричные высказывания, иначе любая научная работа, о которой вы не знаете, тут же опровергнет ваш квантор всеобщности.
N. Amit, D. G. Feitelson. The Language of Programming: On the Vocabulary of Names. https://www.cs.huji.ac.il/w~feit/papers/NameVoc2022APSEC.pdf
P. Hilton, F. Hermans. Naming Guidelines for Professional Programmers. https://ppig.org/files/2017-PPIG-28th-hilton.pdf
Вы внимательно читали мою статью и те работы, что были предоставлены вами в качестве контр-аргумента? Во-первых, в их списке литературы нет ни одного известного лингвиста... Они разбирают и анализируют код чисто с формальной точки зрения.
А во-вторых, я использую методы и принципы отечественной языковедческой науки (при этом в каждом своём примере я с необходимостью ссылаюсь на великого филолога А.В Суперанскую). Так что да - я абсолютно точно уверен, что именно в таком ракурсе данное исследование проводится впервые :)
Эти те примеры, которые выдал мне Гугл буквально по первому запросу. Я не занимался глубоким исследованием prior art.
Во-первых, в их списке литературы нет ни одного известного лингвиста...
Если вы никого не знаете, это не означает, что их никто не знает. Как минимум, есть ссылки на:
E. A. Gibson (h=76)
S. T. Piantadosi (h=46)
H. Tily (h=20)
То, что вы ссылаетесь на Суперанскую, ещё не даёт вам права самостоятельно судить ни о качестве своей, ни о качестве чужих работ. Это не апелляция к авторитету в чистом виде, но расширенная ошибкой ассоциации. Тем более, вы здесь уже начали юлить и ссылаться на принципы исключительно отечественной лингвистики. Как минимум тогда ваше высказывание следовало бы переформулировать. Кроме того также стоило бы показать, чем это отечественная лингвистика лучше зарубежной при исследовании языков программирования.
Да, Gibson бесспорно является титаном лингвистики, я видимо не заметил ссылки на него там. Здесь спорить бессмысленно. Тем не менее, как я кратко сформулировал, в тех работах фокус был на количественных, статистических и психологических аспектах, тогда как я пытался подойти к коду с инструментарием чистой лингвистики: семасиологии (учение о значении) и ономастики (изучение имени).
Кроме того, я фокусировался на отечественной традиции не потому, что она в целом «лучше», а потому, что для этой конкретной, узкой задачи — анализа именования через концепцию внутренней формы слова и теорию прозвищ — именно эта школа (в своей расширенной работе я использую мощнейший аппарат нашей отечественной филологии: Потебня+Виноградов+Суперанская) предоставляет самый точный и разработанный методологический инструментарий. Таким образом, этот выбор представляется наиболее целесообразным и подходящеим для конкретной работы.
Однако хочу сказать вам большое и искреннее спасибо! Многие комментарии (в частности, от вас) всё-таки показали слабые места в моей аргументации, и я обязательно скорректирую некоторые фрагменты в своей диссертации на основе всей предоставленной информации! В конечном счёте, я сюда за этим и пришел!
Если в вашей статье убрать пафос и очевидные истины, то в ней почти ничего не останется.
Вспомнилось "Основание" А.Азимова
- Довольно просто. Для этого требуется то, на что вы не обращаете никакого внимания - здравый смысл. Видете ли, существует одна такая наука, известная под названием символической логики, которая позволяет отсортировать человеческую речь от всякого ненужного хлама, обнажая голую истину.
- Ну и что с того?- спросил Фулхэм.
- Я применил ее. Помимо всего прочего, я применил ее вот к этому документу. Мне самому это, конечно, ни к чему, потому что я прекрасно понимаю, о чем идет речь, но мне кажется я смогу скорее символами, чем словами, объяснить содержание этого документа пяти ученым физикам, то есть вам.
Хардин вынул несколько листов бумаги из папки, лежащей у него под рукой и разложил их.
- Между прочим это сделано не мной,- сказал он.- Мюллер Холк из отдела Логики подписался под этим анализом, как вы можете видеть.
Пирени наклонился через стол, чтобы лучше рассмотреть документы, а Хардин продолжал:
- письмо с Анакреона было, естественно, простой проблеммой, потому что люди, которые писали его, были скорее людьми дела, а не слов. В нем ясно, хотя и не совсем квалифицированно высказано одно утверждение. если смотреть на символы, то увидеть его не просто, но словами оно переводиться следующим образом: " Или вы в течении недели датите нам то, что мы хотим, или мы перебьем вас к чертовой матери и все равно возьмем то, что нам нужно".
Пока пять членов Комитета рассматривали строчки символов, была тишина, а потом Пирени уселся в кресло и неуверенно откашлялся.
- Так какой же выход вы видите, доктор Пирени?- спросил Хардин.
- Кажется, никакого.
- Прекрасно.
Хардин сложил листки.
- А теперь вы видите перед собой копию договора между Империей и Анакреоном, договора, между прочим, подписанного по поручению Императора лордом Дорвином, которы был здесь на прошлой неделе. Рядом с договором вы можете видеть его символический знак.
Договор заключал в себя пять страниц мелкого шрифта, а анализ был написан всего на поллиста.
- Как вы видите, господа, примерно около девяноста процентов выпало из анализа, как полная бессмыслица, а все важное можно описать весьма интересным способом: "Обязательства Анакреона по отношению к Империи: никаких! Власть Империи над Анакреоном: никакой!"
И вновь все пятеро внимательно следили за договором, тщательно сверяясь с доводами, и когда они оторвались от бумаг, Пирени обеспокоенно заявил:
- Кажется, все верно.
- В таком случае вы признаете, что договор этот не больше и не меньше, как декларация полной независимости Анакреона и признание этого статуса Императором?
- Кажется, да.
- И вы думаете, что Анакреон не понимает этого и не хочет усилить свою позицтю независимости - так что естественно стремится не обращать внимания, ни малейшего на намек, что им может чем-то грозить Империя? В особенности, если вполне очевидно, что Империя беспомощна и не может выполнить ни одну из своих угроз, так как в противном случае им никогда бы не была предоставлена независимость.
- Но тогда,- перебил его Сатт,- как мэр Хардин относится к утверждениям лорда Дорвина в том, что Империя окажет нам поддержку? Его гарантии были...- он пожал плечами.- они были удовлетворительными.
Хардин откинулся на спинку кресла.
- Вы знаете, это самое интересное из того, что только происходит. Я признаюсь, когда увидел его светлость, я решил, что он самый настоящий глупый осел, но в конце концов выяснилось, что он законченный дипломат и исключительно умен. Я взял на себя смелость записать на пленку все его утверждения.
Раздались протестующие крики, и Пирени в ужасе открыл рот.
- Что здесь такого? - требователтно спросил Хардин.- Да, конечно, нарушение правил гостеприимства и вообще то, чего не сделал бы ни один порядочный джентльмен. К тому же, если бы его светлость поймал меня за руку, это было бы не очень приятно, но ведь все обошлось, а пленка у меня. Я записал его,переписал на бумагу, потом так же послал Холку на анализ.
- И где же этот анализ? - спросил Ландин Краст.
- Вот это,- ответил Хардин,- и есть самое интересное. Это был самый трудный анализ из всех трех, проведенных в лаборатории. Когда после двух дней тяжелой работы Холку удалось устранить все бессмысленные утверждения, смутные намеки, бесполезные определения, короче, всю ерунду, оказаось, что у него не осталось ровным счетом ничего, ни единого слова. Лорд Дорвин, господа, за все пять дней обсуждения, не сказал ни одной определенной фразы, и причем так, что вы этого не заметили.
©
Я дам тебе имя --
Вот важнейший приём колдовства
И насчет колдовства — вы попали в самую точку. Урсула Ле Гуин была гениальна. Знать истинное имя вещи — значит иметь над ней власть. И когда мы даем коду точное, честное имя, мы, по сути, и занимаемся этим «колдовством» — превращаем хаос в порядок и получаем власть над сложностью.
Спасибо всем еще раз за то, что заставили меня сформулировать эти мысли еще четче.
Я уже как-то думал на эту тему вот здесь: https://habr.com/ru/articles/743114/ и пришел к выводу что не нужно так сильно заботиться о наименованиях.
Мы ведь пишем-таки для машин.
Текстовый код - это промежуточная стадия в трансляции техзадания в бинарник.
Без машины он бесполезен даже в качестве учебного пособия.
И заботиться надо не о людях, а о том, чтоб оно корректно работало.
Люди уйдут, придут, снова уйдут, а код останется отражать техзадание.
Поэтому слишком загружать себя правильными наименованиями смысла нет, только впустую время тратить.
Так что ваше исследование может и интересно с филологической точки зрения, но большинство программистов не филологи, поэтому если они побегут его применять, то сделают это максимально неправильно.
Мы ведь пишем-таки для машин.
Для людей.
Мы не пишем код для машин. Машины понимают практически любой код, даже такой https://www.ioccc.org/
Код, который существует в текстовом виде и тот, который исполняется машиной могут очень сильно отличаться после оптимизации, даже по алгоритму и характеру выполняемой работы.
Удивительным образом "хороший" код, понятный людям без подсказок в подавляющее большинстве случаев - корректный.
А отношение других людей к вашим мыслям и статьям достаточно отражено в комментариях и оценках.
Спасибо за то, что подняли, возможно, самый фундаментальный вопрос в нашей профессии. Ваша позиция — «мы пишем для машин, и главное — корректность» — абсолютно понятна и имеет под собой десятилетия инженерной практики.
Именно из этой парадигмы выросла вся мощь современного IT. Но, как вы верно заметили, «люди придут и уйдут, а код останется». И вот тут, мне кажется, и начинается самое интересное. Код остается не для машины (ей все равно, она получит свой бинарник), а для следующего человека. Для того, кто придет через год и будет пытаться понять, что здесь происходит.
Именно об этом и говорили «отцы-основатели» нашей индустрии, которых вы, конечно, знаете. Дональд Кнут ещё в 80-х ввел понятие «литературного программирования», сказав, что программы должны писаться в первую очередь для людей. А Роберт Мартин («дядюшка Боб») в своей книге «Чистый код» посвятил целые главы тому, почему ясность и читаемость для человека — это самый прямой путь к надежности и долгосрочной корректности системы.
И здесь я хочу сказать огромное спасибо комментатору, который ответил вам ниже. Он сформулировал гениально:
Удивительным образом "хороший" код, понятный людям без подсказок в подавляющем большинстве случаев - корректный.
Это и есть квинтэссенция моей статьи. Я пытаюсь доказать не то, что нужно писать красиво вместо того, чтобы писать правильно. Я пытаюсь доказать, что ясность мысли, выраженная через точный язык (именование), — это и есть самый надежный путь к корректности.
Спасибо еще раз за то, что начали эту важнейшую дискуссию.
.
Помните: программы читаются людьми.© Д. ВанТассел
Я уже как-то думал на эту тему вот здесь: https://habr.com/ru/articles/743114/ и пришел к выводу что не нужно так сильно заботиться о наименованиях.
И вы за два года так и не поняли в чём заблуждаетесь? Это печально.
Люди уйдут, придут, снова уйдут, а код останется отражать техзадание.Поэтому слишком загружать себя правильными наименованиями смысла нет, только впустую время тратить.
Придут и будут тратить кучу времени на понимание абы-как именованных переменных/функций/классов и сопоставление их с внешними требованиями.
Представляете, как нейтивам тяжело учиться программированию! Вот для вас команды и ключевые слова, формирующие синтаксис, функции - все в единственном экземпляре. "Const" и в Африке "const". А у нейтивов почти для каждого слова может оказаться по несколько синонимов. Попробуй запомнить, что из них команда, а что просто часть языка общения. Я уже молчу про написание: center vs centre. Если всю жизнь пишешь centre, то тяжело помнить, что именно тут надо писать "с ошибкой".
Какой блестящий и абсолютно неожиданный парадокс! Спасибо вам огромное, это, возможно, самое тонкое наблюдение во всей дискуссии.
Вы сейчас нащупали самый нерв всей проблемы. Ваш пример с center vs centre — это лучшее доказательство моего главного тезиса: программный код — это не английский язык. Это — совершенно другой, самостоятельный язык, который лишь заимствует лексику из английского, но подчиняет ее своей, абсолютно ригидной и формальной грамматике.
Именно поэтому нейтиву может быть даже сложнее! Его языковая интуиция, его чувство «живого» языка постоянно вступает в конфликт с неумолимой, прескриптивной нормой компилятора. Он ждет от слова const всего богатства коннотаций, а получает лишь формальный маркер.
По сути, вы сейчас описали то, что я в своей диссертации называю «онтологическим несоответствием» между естественным языком и кодом. Вы привели гениальный пример того, как носитель языка становится жертвой «ложных друзей переводчика» не между двумя иностранными языками, а между своим родным языком и «кодом».
Спасибо еще раз за этот взгляд с совершенно другой стороны. Это невероятно обогатило нашу дискуссию!
В ваших комментариях столько благодарностей и пафоса, будто это нейросетка пишет
Напротив, мне очень приятно получить такой фидбек от профессиональных инженеров. Именно поэтому я стараюсь отвечать максимально детально, подробно и с уважением. И не забивайте, что я филолог, поэтому инженерам может быть непривычно видеть такой стиль письма :)
Во-первых, дихотомия физиков и лириков ущербна. Например, вы как филолог должны знать об инженере Ф. Достоевском и медиках А. Чехове и М. Булгакове.
Во-вторых, подобный лестный стиль знаком сейчас всем пользователям нейросетей, о чём я уже упомянул.
Наконец, это смотрится просто фальшиво.
Это называется элементарная вежливость. Видимо, зря я подумал, что здесь будут образованные и мыслящие люди, которые воспримут такой стиль коммуникации за проявление уважения.
Я понял, больше не буду никого благодарить — всем от этого только плохо становится …
Однако, всё же поставлю лайк, за то что раскрыли мне глаза. Похоже, общаться здесь принято именно в пассивно-агрессивной манере.
Подключите нейросеть, чтобы не тратить время на благодарности и пафос. Пущай нейросеть тратит его за вас!
Похоже, общаться здесь принято именно в пассивно-агрессивной манере.
А вот переходить из крайности в крайность не надо. Такое поведение не красит вас. Да и к тому же, похожий паттерн присущ некоторым LLM (признаю, возможно я параноик)
А по существу, можно же просто отвечать более сухо. Тех. специалисты это любят
Вы этими словоблудиями во первых обесцениваете свои комментарии (у многих уже формируется "ллмнная слепота", когда характерные для ллм фразочки, обороты и общий стиль уже изучвны, знакомы и очень заметны), при чтении триггерится "а, это нейронка, это можно скипнуть не потеряв ничего, да к тому же ещё и галлюцинации нейронки могут быть в этом тексте, так что лучше это пропустить", а во вторых тратите зря как своё время (если и правда сами это набираете каждый раз), так и время читателей.
Если в статье эти фразочки ещё могут быть уместны, то в комментах такому.не место. Или вы в коде тоже пишете комментарии в таком стиле, по 5 строчек, из которых 4 - вежливые, а одна - ценная?
Я понял, больше не буду никого благодарить — всем от этого только плохо становится …
Плохо не от благодарности, а от отсутствие чувства меры.
Это как сахар в кофе. 2 ложки - норм, 10 - пить невозможно.
Он ждет от слова
constвсего богатства коннотаций, а получает лишь формальный маркер.
Программист как раз таки не ждёт этого богатства. Ему важна однозначность.
Нужно просто относиться к ключевым словам не как к "заклинаниям", а как к обычным словам-командам. И тогда становится как-то пофиг, на каком они языке.
А вот с именованием сущностей - тут сложнее. Тут и язык, и национальный контекст, и профессиональный.
Поэтому и есть гайдлайны. Про синонимы там тоже есть. Вот например для используемого мной PoSh
https://learn.microsoft.com/en-us/powershell/scripting/developer/cmdlet/approved-verbs-for-windows-powershell-commands?view=powershell-7.5
Названа в честь магистра Йоды за инвертированный порядок слов.
Магистра Йоды в честь названа, слов порядок инвертированный за. (кажется, это ближе всего выходит к йода-спику, который, вроде, сложнее просто инверсии)
Благодарю, что указали на это! Получил огромное удовольствие :) Это идеальный пример того, как глубоко культурный код проникает в мышление, являясь хорошо узнаваемой аллюзией (отсылкой).
Примечательно, что иногда культурная аллюзия сама может становиться исполняемым кодом. В своих исследованиях я как раз анализировал пример, где для демонстрации небезопасного режима шифрования в качестве ключа используется строка:
cipher.key = "ABANDON ALL HOPE YE WHO USE ECB!"
Здесь цитата из Данте — это не просто метафора для человека. Это реальные данные, которые исполняет машина. Предупреждение и есть уязвимость, то есть цитата из литературного произведения становится частью самого алгоритма, который она описывает. В этом и усматривается основное различие естественного языка и языков программирования.
Спасибо вам ещё раз! Я как раз хотел бы более детально это продемонстрировать в своих следующих публикациях.
Нет. Исполняемым кодом эта строка не становится. Это ключ шифрования. Отсылка к Данте здесь сделана исключительно в демонстрационных целях и никаких особых свойств не проявляет, поэтому частью алгоритма или его уязвимостью не является. Влияния культурного кода на мышление здесь тоже усмотреть нельзя.
Даже строка "polygenelubricants" для Java имеет бо́льшую показательность для алгоритма hashCode, но я бы всё равно не считал этот факт чем-то невероятным и знаковым.
Прошу прощения, вы здесь правы: моя формулировка была не самой удачной, и я благодарен вам за возможность её прояснить.
Скорее, на этом примере мы можем наблюдать уникальное явление, которое я в своих исследованиях называю «семантическим уплотнением».
Один и тот же текстовый элемент ("ABANDON ALL HOPE...") одновременно выполняет три абсолютно разные функции на трех разных уровнях:
Операциональный (для машины): Это просто массив байтов, который служит ключом для алгоритма.
Прагматический (для инженера): Это прямое и недвусмысленное предупреждение об опасности использования данного режима шифрования.
Культурный (для эрудированного инженера): Это интертекстуальная аллюзия, которая апеллирует к общему культурному коду.
Именно в этом «уплотнении», в этой способности одного знака работать в трех измерениях сразу, и проявляется, на мой взгляд, вся сложность и богатство кода как языка.
Так что спасибо вам огромное за это уточнение! С технической точки зрения, эта строка, правда, является данными (ключом), а не исполняемым кодом.
Если выйти за пределы того, что "нужно называть вещи своими именами" (что, в принципе, и так большинство людей понимает), можете привести пример, когда филологический взгляд реально помог вам в программировании? Например, придумали новый продвинутый способ называть переменные?
Я не думаю, что названия всех переменных должны быть пространными и всё объясняющими. Если в коде явно определён scope - например, функция уже имеет говорящее название, - то достаточно, чтобы имя было уникальным и понятным в пределах этой функции.
Когда дома говорят "Маша пришла из школы", то всем обычно понятно, о какой Маше идёт речь. Конечно, знатный Ономат мог бы назвать её "ДевочкаКоторуюМыЗачалиВПорывеСтрастиВСтогеСенаВоВремяПоследнихСтуденческихКаникул", но, как правило, до этого не доходит.
Просто отличное замечание! Вы попали в самую суть!
Цель филологического взгляда — не в том, чтобы придумать «новый продвинутый способ» и заставить всех писать монструозные имена. Ключевым здесь выступает ответ на вопрос «ПОЧЕМУ эти правила, которые интуитивно нащупали лучшие инженеры, работают именно так?»
Как вы правильно заметили, все решает контекст (scope). В лингвистике это называется прагматикой. Ваше наблюдение о том, что «достаточно, чтобы имя было уникальным и понятным в пределах этой функции» — это и есть главный закон коммуникативного акта. Вы интуитивно, как опытный носитель языка, используете ровно столько информации, сколько нужно собеседнику (читателю кода) в данном контексте, и не больше.
Так что филологический взгляд не предлагает «новый способ». Он предлагает систему для понимания тех гениальных интуитивных решений, к которым вы, как опытный инженер, уже пришли на практике.
P.S. Я, к сожалению, ещё не разобрался как здесь корректно вставлять цитаты из других комментариев для ответа на них, поэтому пока буду просто дублировать эти фразы :)
Осознайте свою роль. Вы — Ономат (name-giver).
Абанамат, я — ономат!
Ощущение, что общается жпт. Формулировки ответов один в один.
В лингвисте это называется «устойчивые словосочетания-клише». Я, как истинный филолог, могу общаться, используя абсолютно разные регистры речи. И я осознал свою ошибку — больше не буду отвечать всем и каждому на один и те же вопросы, чтобы не быть обвиненным в использовании одинаковых конструкций :)
Ну да, клише. Неужели вы разговариваете такими клише? Трудно поверить!
Часть ответов на комментарии пользователей содержит извинение и выговаривание своего последующего моделя поведения... Хмм, что же это напоминает?..
Безусловно, я понимаю, что ответ может фильтроваться, дорабатываться человеком. Однако применение LLM и отрицание этого не выглядит профессионально.
Возможно, я и некоторые коллеги здесь ошибаемся и у нас массовая паранойя. Хотелось бы верить, но верится с трудом. Уж извините
Весьма печально, что многие здесь действительно никогда не участвовали в настоящих научных дебатах/дискуссиях :)
Когда мы выступаем на кафедре или защищаем какую-либо работу, при ответе на вопрос от рецензента или коллеги — мы всегда благодарим за него, либо же приносим извинения за ошибки, причем делая это постоянно и нередко одними и теми же фразами. Да, нас научили в МГУ, что писать и говорить следует некоторыми клишированными выражениями, которые давно уже считаются «общим фондом фраз» и образованные люди никогда бы не посчитали это плагиатом или искусственным интеллектом.
И мне правда жаль, что большую часть времени вы проводите за общением с ИИ, а не с вежливыми, начитанными людьми, что любая речь на официальном языке кажется искусственно воссозданной :(
P.S. Простите, конечно, но у меня достаточно интеллекта, чтобы надеяться на свои исключительные знания, а не покупать дорогостоящие и бесполезные подписки ради ответов на комментарии или чтения их галлюцинаций, которым они подверженны.
На конференции есть 30 секунд на ответ. 20 секунд вы потратили на благодарность за вопрос. Как вам удаётся за оставшиеся 10 секунд изложить 5-минутный ответ?
Или смысл благодарностей в том, чтобы вообще не отвечать?
Не вижу смысла продолжать дискуссию, у нас разные уровни образования и опыт.
30 секунд нам никто не предоставляет: мы всегда стараемся отвечать максимально подробно, поэтому за все годы нас никто и никогда не ограничивал во времени. Впрочем, это уже совсем другая история.
Погодите, а какой же у вас регламент?
Обычно — 15 минут на доклад, 5 минут на вопросы, звучит 10 вопросов. Потом или ведущий говорит «хватит», или ведущий даёт ещё пять минут на вопросы.
Если отвечать на вопрос максимально подробно, вы не успеете ответить даже на один вопрос из аудитории и сорвёте распорядок конференции.
И мне правда жаль, что большую часть времени вы проводите за общением с ИИ, а не с вежливыми, начитанными людьми
Во-первых, вижу вы быстро перешли на пассивную агрессию. Это не радует и не красит вас.
Во-вторых, "говорить с ИИ" - это часть моей работы. Промт-инженеринг и разработка агентов входит в мою работу (в стороннем проекте, но не суть)
В-третьих, на конференциях, где я был бакалавром и магистром, обычно таки дано ограниченное время на ответ. Соглашусь, что это не отменяло вежливость. Но мы не на конференции сейчас.
Агрессии абсолютно не было, это чистая констатация фактов. Но пускай каждый останется при своём мнении :)
Агрессии абсолютно не было, это чистая констатация фактов.
Весьма печально, что многие здесь действительно никогда не участвовали в настоящих научных дебатах/дискуссиях :)
Поскольку мы тут тупые грубые нёрды, которые могут общаться только с ИИ, то вот что думает бесплатный ChatGPT о вашем комментарии:
Да, в такой фразе можно увидеть элементы пассивной агрессии. Вот почему:
Сарказм / снисходительный тон
– Автор не говорит напрямую «вы некомпетентны» или «вы не умеете дискутировать», но подразумевает это, прикрываясь якобы «печалью».
– Смайлик 🙂 на конце может звучать не как дружелюбие, а как саркастическое смягчение — «подкол» в вежливой упаковке.Обобщение и обезличивание
– «Многие здесь никогда не участвовали…» — критика направлена не на конкретного оппонента, а на «многих». Это позволяет избежать прямой конфронтации, но создаёт атмосферу упрёка и высокомерия.Скрытая агрессия под видом сожаления
– Формально выражается «печаль», то есть будто бы негативное чувство направлено не на людей, а на ситуацию. Но по сути это принижение оппонентов («вы не доросли до настоящих дискуссий»).Намёк на собственное превосходство
– Фраза противопоставляет говорящего («я-то участвовал в настоящих научных дебатах») остальным участникам, демонстрируя их «недостаток опыта». Это создаёт скрытую агрессивную иерархию.📌 В целом, это не открытая агрессия («вы ничего не понимаете»), а именно пассивная: под видом печали и вежливости прячется принижение и сарказм.
Как будто филолог в IT это редкость. Я его каждый день в зеркале вижу. КемГУ, начал в 1983-м, окончил в 2004-м, но окончил, в общем-то, просто "чтоб было".
Но я немного странный филолог, я 9-10 класс метался между физматом и филфаком, победил филфак, почти случайно. Да и поступать я собирался на прикладную лингвистику. Но кафедры оной были сильно далеко от Кемерова и стреманулся ехать черте куда.
В IT с 1991 года. Филфак сильно помогает составить текст, это да. Докладную написать красиво и без ошибок. Но язык программирования не живой язык, а всегда мертвый, ибо всегда-превсегда кодифицированный, довольно странно слышать от лингвиста мнение о кодифицированном языке, как о живом. Если уж есть охота сравнивать с каким-либо языковым феноменом, то сравните с пиджином. Да, пиджин может развиться в язык, суахили не даст соврать. Но это очень редкое явление. И суахили живет прежде всего в живой речи, ежедневно ломая рамки и правила. На любом из языков программирования вы не можете выйти за рамки принятого синтаксиса. И это признак мертвого языка. В контексте лингвистики.
Спасибо за ваш комментарий! Мне было очень интересно его прочитать! (надеюсь, вы не воспримете эту благодарность как «признак ИИ» ахах)
Мне кажется, что строгие ограничения синтаксиса — это не проблема. Например, в сонетах мы таким же образом сталкиваемся с жесткими ограничениями/рамками (строка, рифма), но это никак не мешает литературоведам выявлять в них различные пути и механизмы смыслотворчества. Аналогично, в коде присутствует прескриптивная грамматика, однако всё же представляется возможным исследовать и выявлять там семантические, стилистические и риторические возможности.
риторические возможности
Даа.. читал я код одного известного ардуинщика и удивлялся стилистике с риторикой. Вот есть у него функция. С параметром color и глобальной переменной thisColor. И внутри из 2 переменных вычисляется третья - letterColor . Прямо сонет, с рамками. И , как неожиданная рифма, функция в параметр color внезапно получает глобальною переменную thisMode. Читается как детектив, где до последней строчки непонятно, кто убийца, кто жертва, а кто садовник.
Ичсх, сей верлибр не только билдится но и работает. Лампочки мигают..
Филолог написал много букв (что не удивительно). В то время, как для доказательства своего утверждения должен был привести статистику. Сколько филологов стало программистами и каковы их достижения в сравнении с программистами, инженерами, математиками, физиками, систадминами, врачами, домохозяйками, которые тоже стали программистами? Статистики нет, но есть много бла-бла.
Моя статья абсолютно не об этом, название — это не более, чем «провокационный заголовок» (кликбейт).
Тем не менее, большое спасибо за ваш комментарий и такую реакцию, я обязательно учту на будущее, что такие заголовки работают против меня :) Первоначально, мне казалось, что здесь приветствуется публицистический стиль. Сейчас же (благодаря многим комментаторам) я понял свои ошибки, а в последующих изложениях при необходимости непременно буду делать акцент на статистические данные.
На Хабре лучше всего писать такой заголовок, какой вы пишете в рецензированной статье.
Вот это по-настоящему ценный комментарий, помогающий лучше узнать «внутреннюю кухню» и определенные правила сообщества. Большое вам спасибо за такое своевременное замечание!
С сожалением приходиться констатировать, что большинство, как правило, прибегают к тактике: «критикую и ничего не предлагаю/никак не помогаю».
Это не ценный комментарий, а так, походя.
Большинство аспирантов в РФ написали в диссертациях бессмысленную чепуху. А вы не смотрите на это большинство.
Мне, например, было ценно это узнать, поскольку я изначально не совсем правильно расценил некоторые вещи.
А что касается вас (исходя из всех ваших комментариев), я уже понял, что вы — нигилист, имманентно отрицающий всё, что ему незнакомо либо непонятно. Что ни скажи — будете подвергать сомнению. Всего хорошего! :)
Сколько филологов стало программистами
Как минимум 1. Тот что придумал perl ;)
Тут вопрос не в том, технарь человек или филолог, а в том насколько он умен и культурен. Вот Эллочка Щукина (aka Людоедочка) из "12 стульев" -- она технарь по-вашему?
При этом взгляд на вещи может быть с разных сторон. Мой знакомый филолог, работающий фронтэндером, поведал, что для него HTML -- существительное, CSS -- прилагательное, Javascript -- глагол. Не поспоришь :)
У Эллочки уровень абстрации очень высок!
Уровень абстракции у неё никакущий, там очень высок уровень зависимости от контекста: в контексте ситуации ещё можно если не понять, то хотя бы предположить, к чему сказано очередное "мрак", "блеск" или "парниша", но прочитать перед незнакомой аудиторией лекцию о своём соревновании с Вандербильдихой она на своей лексике не сможет никак.
Большое спасибо за.
Вы совершенно правы в. Попали в самую точку, в яблочко. Блестяще, блестяще. Браво.
Правда, ни*уя не понял, о чём это и зачем. Выглядит довольно натянутой и неуклюжей пост-рационализацией внезапно открывшегося г-ну Журдену знания, что он всю жизнь говорил прозой. Или ещё напоминает, как... один мой друг в юности "Кама Сутру" почитал, ожидая найти там новых бездн неслыханного разврата, а там всю дорогу было только "вот то-то называется так, а вот это-то называется сяк", вызывая у читателя резонный вопрос: да кому какое дело?!
Ещё раз огромное спасибо за.
Хотел спросить в комментарии, одного ли меня тошнит от авторских ответов с большими спасибами, нахваливанием прокомментировавшего с тоннами сахара и преобладанием превосходных степеней прилагательных, будто разговариваешь с нейросеткой. Но почитал комментарии, и понял, что не одного.
Ценность статьи невысокая, нет никакой острейшей необходимости привлекать в программирование филологию, важность проблемы с именами надумана.
Чё ребят. Откроем филологам Америку? Что код надо уметь читать двумя полушариями. Одним - как человек и там нам обычно плевать что и как называется, главное - какие комментарии написаны.
Вторым - читать код как компьютер. А ему 100% плевать что и как называется. Он там функцию увидел, параметры отсканировал из памяти значения достал и дальше по стеку плюнул.
Если бы компьютер думал над тем как мы там назвали переменную - с ума бы наверное сошёл. Пришлось бы программировать калькулятор на майнинг фермах.
Мне нравится из "Linux kernel coding style" (в контексте Си/Go):
C is a Spartan language, and your naming conventions should follow suit. Unlike Modula-2 and Pascal programmers, C programmers do not use cute names like ThisVariableIsATemporaryCounter. A C programmer would call that variable tmp, which is much easier to write, and not the least more difficult to understand.
...
GLOBAL variables (to be used only if you really need them) need to have descriptive names, as do global functions. If you have a function that counts the number of active users, you should call that count_active_users() or similar, you should not call it cntusr().
Очень полезный и неожиданный взгляд.
Читал с интересом
Большое вам спасибо, что оценили мою работу с такой стороны!
Я ни в коем случае не претендую на звание инженера, а лишь хотел поделиться своими наблюдениями и пообщаться с профессионалами в этой области. Поражен, что многие оказались настолько невосприимчивы.
Я сейчас работаю над продолжением цикла, буду признателен, если вы уделите время и прочитаете мою следующую статью! Она обещает быть ещё интереснее :)
Нормально так пообщались с ЛЛМкой в комментариях.
Аккаунт зарегистрирован вчера, одна статья, аватарка похоже сгенерирована, а никаких Артемов Лакомовых в списке преподавателей МИРЭА я не нашел.
В точку! ИТ-индустрия деградировала настолько, что программистами теперь считают себя не только технари, освоившие примитивный веб и погрязшие в теории, но даже филологи. А мы потом удивляемся, почему всё глючит и требует всё более мощного железа. Браво!
Мне кажется, это наоборот очень полезно. Сочетание программирования и филологии может как раз помочь в совершенствовании разработки новых, «ориентированных на человека» систем, а также улучшить существующие практики преподавания программной инженерии.
Зато в коде имена красивые :)
И что плохого, если в программисты попадает человек из другой дисциплины? То, что он может свежим вщглядом на код бородатого "программиста" ужаснуться безграмотности и нечитаемости? Так я ни разу не филолог а программист с 30 летним стажем, но тоже ужасаюсь некоторым исходникам, которые хотя и работают пока не трогаешь их, но если надо что то в них поправить , то проще самомоу написать порой.
Программистами теперь считают себя... даже филологи
Не диплом делает человека программистом, а умение формализовать задачи. Ничего не мешает филологу применять ЯП для решения NLP-задач (прикладное программирование).
Всё глючит и требует всё более мощного железа
Какое отношение филолог-программист будет иметь к этой проблеме, если его домен — естественные и/или формальные языки? Вы не задумывались, что проблема ухудшения оптимизации связанна, в том числе с увеличением производительности процессоров, скорости памяти и т. д. Причины более комплексные, чем Ваш неуместный вброс.
Касательно самой статьи, языки программирования (формальные) и естественные имеют много схожих черт. Почему бы не применить аналитические концепции естественных языков к формальным, чтобы потом получилась интересная статья? В статье вообще не затрагивается производительность программ, а только именование переменных. Или именование перменных — это навык, постичь азы которого сможет только технарь, освоивший системное программирование?
Заголовок говорит о другом. Он говорит, что лучшие программисты являются ещё и филологами. Это не о том, что филологи приходят в программирование, а о том, что программисты становятся ещё и филологами, когда придумывают названия.
Пишу примерно так код. В основном для себя, чтобы потом через месяц другой не смотреть на него как на нечто непонятное. Некоторые очевидные идентификаторы по имени говорят сами за себя. Не идеально, наверное, но стараюсь как могу называть правильными именами таблицы БД, встроенные процедуры и запросы.
// -------------поддержка коннектов -----------------------------------------
PROCEDURE CONNECT(SERVER :integer) ; // на входе S = номер сервера (0-тестовый 1 - рабочий, 2 - локальный)
PROCEDURE CLOSE_ALL_DATASET();
PROCEDURE CLOSE_ALL_TIMER() ;
PROCEDURE SetDataSets(ID_DATABASE: integer) ; // настройка датасетов на процедуры или запросы в зависмости от выбранной БД
PROCEDURE SaveDataSetToCSV(DataSet: TDataSet; dbgrid: TDBgrid; const FileName: string);
//-----статистика теста прибора, обнаружение Интегратора, -------------------
FUNCTION OPEN_TEST_STATISTIC(ID_DATABASE : integer ) : string ;
FUNCTION NAME_INTEGRATOR() : string;
FUNCTION GetColumnTitleByIndex(DBGrid: TDBGrid; FieldIndex: Integer): string; // получить имя заголовка колонки по индексу поля таблицы
//-----------открытие таблиц с данными -------------------------------------------------------------
FUNCTION OPEN_OPERATION_LOG( ID_DATABASE : integer ;ID_DEVICE : integer; sort : integer ) :string;
FUNCTION OPEN_DATA_TEST(ID_DATABASE : integer) :string;
FUNCTION OPEN_CURRENT_TEST_POOL(ID_CONNECT : integer) : string;
PROCEDURE OPEN_ALL_BOARD(ID_DATABASE: integer;Caterory_device: integer);
//---------- проверка статуса UPDATE\INSERT и дублирования записи SN-------------------
FUNCTION SQLITE_CHECK_STATUS_INSERT_UPDATE() :string;
FUNCTION CHECK_DUPLICATE_SN(SN : string) : boolean ;
FUNCTION SQLITE_CHECK_STATUS_INSERT_BULK(TEST_POOL: integer ; SN : string ) :string;
//----------загрузка настроек из БД и создание конфигурации теста ----------
FUNCTION CREATE_BOARD_CONFIG_TEMP_USER( ID_CONNECT: integer ) :string; // вход - номер подключения - выход статус операций = 'PASS'
FUNCTION LOAD_SYSTEM_SETTING_TABLE(ID_DATABASE: integer) :string; // ID_DATABASE - номер базы данных из CBConnection
//----------запись данных тестирования и выгрузка --------------------------------------------------------------------------------------------------------
FUNCTION WRITE_RAW_DATA_TEST_COMMON( ID_DATABASE : integer ; SN : string; VALID : string; TEST_POOL : integer ) : STRING ;
FUNCTION WRITE_INPUT_DATA_DOUBLE_CLICK_SQLITE(IDENT: integer; NAME_REGISTER :string ; CONFIRM_WO_INPUT_DATA : integer) : string;
FUNCTION WRITE_INPUT_DATA_REF_SQLite(MODE: integer ; IDENT :integer ) :string ;
FUNCTION WRITE_INPUT_DATA_DOUBLE_CLICK(IDENT: integer ; ID_DATABASE : INTEGER ) : string;
FUNCTION WRITE_DATA_TAG_CONFIG_TEMP_SQLite(IDENT : integer ; COLUMN : integer ;MODE : integer) : string;
FUNCTION WRITE_TAG_CODE_SQLite(tag_input : shortstring ) : string ;
FUNCTION WRITE_DATA_BOARD_CONFIG_TEMP_SQLite(IDENT :integer; COLUMN_INDEX : integer; ident_str :STRING) : string;
FUNCTION WRITE_DATA_BOARD_CONFIG_TEMP_MSSQL(IDENT :integer; COLUMN_INDEX : integer; ident_str :STRING) : string;
FUNCTION SaveStatusTest_SQLite() :string;
FUNCTION RESET_VALUE_SQLITE( IDENT : integer; INDEX_ID : integer; ident_str :string) : string;
FUNCTION WriteSettingToDatabase_common (ID_DATABASE: integer ; OPERATION: integer; SETTING: string; ACTION: string; NAME_ACTION: string) : string;
FUNCTION WRITE_OPERATION_LOG_SQLITE(TEST_POOL : integer ; NUMBER_OPERATION : integer ; PARAMETR : string) : string;
FUNCTION CLOSURE_TEST_POOL_COMMON( ID_DATABASE : integer ; TEST_POOL : Integer ; OPERATION : string ; ID_DEVICE :Integer ; ID_CONFIG : integer ) : string ;
// ---------------- функция фильтрации выполненных тестов --------------------
FUNCTION SHOW_ALL_TESTS_COMMON ( ID_DATABASE : integer ; PERIOD : integer ;
USER_STATE : boolean ;
USER_NAME_INDX : integer ;
USER_NAME_TEXT : string ;
Device :boolean ;
Defect :boolean ;
Arhive : boolean ;
ADD_COLMN :boolean ) : string;
// ------------------ Открытие списка протестированных изделий ----------
FUNCTION GETFILTER_ID1( DATE_START : tdatetime ; //начало периода
DATE_END : tdatetime; //конец периода
USER : string ; // пользователь
ID_DEVICE : integer ; // идентификатор изделия
id_config :integer ; // идентификатор конфигурации теста изделия
TEST_FAIL : integer ; // Брак
ARHIVE : boolean ; // признак архивной записи
ID1 : integer; // идентификатор первого вставленного в таблицу транспонированного стробца
ID2 : integer // идентификатор второго вставленного в таблицу транспонированного стробца
) : string ;
FUNCTION GET_BOARD_TEST_COMMON(ID_DATABASE : integer ;TEST_POOL: integer ; SN : string ) : string ;
FUNCTION GET_IMAGE_BOARD (ID_DATABASE : integer; ID_DEVICE :integer ; ID_CONFIG : Integer) : string ;
//---------системные функции для выгрузки и записи данных ------------------
FUNCTION GetSpecialPath(CSIDL: word): string; // переменные окружения по CSIDL
FUNCTION GetCurrentUserName() : string;
FUNCTION GetProcessByEXE(exename: string): THandle; // получить признак запуска программы по имени *.exe
FUNCTION HOST_NAME() : String;
PROCEDURE Delay(Value: Cardinal);
FUNCTION GET_FULL_PATH(RELATIVE_PATH : string) : string ; // возврат полного пути относительно текущей директории
// ---- Отметка строки как заголовка группы ---------------------------------
procedure Install_type_control( ident : integer);
//----------- добавление контрак-поставщиков ---------------------------------------
PROCEDURE GET_CONTRACT(); // получить список
PROCEDURE IMPORT_CONTRACT() ; // импортировать данныу поставщиков
PROCEDURE EXPORT_CONTRACT(); // экспорт данных в локальную БД
FUNCTION ADD_CONTRACT() : STRING;
FUNCTION ADD_DEVICE_CONTRACT(ID_CONTRACT: string ; ID_DEVICE : integer ;ID_CONFIG: Integer ; MESS : string ) : string ;
Статью, конечно, писала нейросеть, но одну логическую ошибку в ней разобрать всё-таки стоит: именование, основанное на культурном контексте, типа "Heisenbug" - большая ошибка, банально потому, что со временем контекст меняется. Сегодня ты пытаешься сделать отсылку на Гейзенберга, который сформулировал принцип неопределённости, а завтра твой код разбирает человек, для которого Гейзенберг - это "время варить!". Сегодня ты называешь переменную в честь автора Илиады, а завтра кто-то думает, причём здесь Гомер Симпсон.
со временем контекст меняется
Да. Так и получается legacy. Много кто помнит, почему HDD - винчестер ? Что означат иконка на кнопке Save?
Не вижу проблемы. Со временем все поменяется. Мы не замечаем изначальные значения, закладываемые в слова. Никто не пишет бессмертный код. Полагаю, что ваш код и набор инструментов, с помощью которых он написан и скомпилирован, умрут раньше, чем правильная ассоциация с Гейзенбергом. В любом случае такие найминги как правило даёт небольшая группа посвященных для самих себя. Так например слово "стушеваться" использовалось изначально только одногруппниками Достоевского.
Тут не такое простое дело. На высоком уровне абстракции объекты и их имена теряют семантическую привязку к предметной области. Для функции сортировки список - это просто список.
Со временем у разработчика появляется свой «словарь» для нейминга. Постоянное чтение чужого кода помогает понять, какие названия работают, а какие только запутывают.
Вот, например, переменная count. Опытный программист почти всегда назовёт её именно счётчиком. А у джунов встречаются самые разные варианты - total, inc, иногда даже что-то вроде counnnt.
Есть ещё и влияние самого языка. В Go нейминг обычно максимально короткий и лаконичный:
repo.Get(42)
repo.List(10, 0)
repo.Save(&u)
repo.Delete(42)
А в Java, особенно в Spring - наоборот, длинный и самодокументируемый:
userRepository.findUserEntityById(42L);
userRepository.findAllUserEntitiesWithPagination(10, 0);
userRepository.saveUserEntity(userEntity);
userRepository.deleteUserEntityById(42L);
В Go читаемость держится за счёт контекста, а в Java - за счёт длинных «говорящих» имён. Оба подхода рабочие, но философия разная.
Эта статья — часть большой научной работы.
Точно? На научную не похоже...
Есть одна проблема о которой очень интересно узнать, вы не могли бы в markdown вывести таблицу с ценами яблок в Эфиопии. Я очень люблю фиолетовые яблоки, а вы?
Картинки - боль. Мысли, конечно, интересные - но вы же просто перечисли то, что и так уже все знают. Где примеры других, никому не известных названий? Потому что вообще не факт, что попытки придумывать название "от притчи" поможет облегчить проблему нейминга больше, чем "от балды" (кстати, почему его нет в вашем списке).
я филолог из МГУ
боли в IT
уважаемый филолг из МГУ. вы знаете что такое штампы и клише ?
это устойчивые мерзкие слова и речевые обороты, кроме всего прочего подверженные моде.
я предполагаю что распространяются они методом подражания, как у обезъян.
раньше была мода на "вполне себе" (вполне тебе, вполне мене, вполне везде) и "чуть более чем",
сейчас уже года два как пошли "боли". и до того достали, что каждому болевику так и хочется предложить анальгин. или рауш-наркоз. препаратов из списка А предлагать не буду - не заслужили.
Так Domain Driven Design (DDD) чуть менее, чем полностью про язык ;) Прекрасно, если у вас будут объективные метрики для оценки качества.
В самом начале книги The Programmer's Brain хорошо рассматривают вопрос когнитивной нагрузки:
Lack of Knowledge, Lack of Information, Lack of Processing Power.
Самая жесть обычно со вторым, когда все наименования страдают от проклятья знания, то есть когда разработчик неосознанно использует контекст. Смотреть же на код глазами только что нанятого разработчика, который не в курсе, что и зачем, трудно.
Забавно, что техническая корректность у этого филолога на последнем месте.
Так она автору не очень нужна, всё равно с ним никто дискутировать не сможет: сообщество Хабра в целом не владеет понятийным аппаратом, но обладает опытом по проблеме, а научные оппоненты и коллеги не знакомы с предметом исследования. Это позволяет не заморачиваться с поиском и обработкой исследований по теме, просто заявляя, что «их нет» (зарубежные работы отсекаем как якобы нерелевантные по узкой теме, а значит автоматически получаем научную новизну), а также не заморачиваться с глубиной проработки проблемы: хватаем наиболее удобные слова и словосочетания и подбираем к ним подходящие термины из книжек по филологии. На выходе получаем довольно очевидные и никому не нужные рекомендации, а также научные статьи и диссертацию. Сплошной профит.
Слишком много комментариев уже написали, прошу простить если повторю кого.
Примеры с handler, manager не понравились. Как раз таки удобнее когда так пишут, чем что-то более экзоческое из двух-трёх слов придумают. Вспоминать их названия, и потом отыскивать в проектах, та ещё боль.
Utils/helpers - уже другое. Есть примеры где это более чем уместно, как лишний абстрактный слой в каком-то сервисе. Но как правило, в так названных директориях всегда твориться каша. Так что тут вполне согласен.
Я полагаю новички могут читать статью. Так что пожалуй стоило бы про items и list уточнить, что это для общего кода не уместно. Если у нас есть сервисы/методы обработки какого-то бы то не было конкретного списка, при правильном имени метода, это наоборот будет излишне расписывать суть в имени переменной.
Но в целом, спасибо за статью!
Дайте LLM молоток, и она везде будет видеть гвозди. Дайте LLM филолога, и они в программировании не увидят ничего, кроме наименований.
Я давно предлагал, надо сделать причину минуса - написано LLM.
Привет коллеге! Как филолог, называю по сути экшена или сути переменной. Иногда люблю пошалить и назвать функцию sub zero(int), которая возвращает цифру с ноликом перед ней, если она меньше 10.
Автор однозначно красавчик.
Описанное именование сущностей - только самое начало интереснейшей области.
И область эта называется DSL - предметно-ориентированные языки.
Есть такая старая шутка, что в каждой сложной программе на C - заложен кривой и недописанный интерпретатор LISP.
По факту, высокоуровневые разработчики в сложных проектах - создают собственный предметно-ориентированный язык, выражаемый через используемый язык программирования. Это еще иногда называют метапрограммированием, хотя термин и замусорен изрядно.
И сложный проект, по сути, пишется не совсем на языке программирования. А, скорее, на некоем языке более высокого уровня, но в синтаксисе базового языка программирования.
В этой статье автор краешком затронул вопрос именования сущностей. А есть же еще действия, и действующие лица. Да и сами сущности имеют таксономию - некие отношения, которые могут быть как иерархическими, так и не-иерархическими.
Я так понимаю, это должно стать предметом следующих статей. Поглядим. Если речь действительно пойдет о законах создания и развития DSL - это будет крайне интересно.
Этак и до семантики высших порядков дело дойдёт.
(Кстати, LLM в силу принципа своего построения не в состоянии генерировать правдоподобные суждения в семантике высших порядков).
попытка войти в IT в стиле "а что так можно было?"
Читал комментарии с великим удовольствием, портал в бездну.
"Если долго всматриваться в бездну, бездна начинает всматриваться в тебя"
Почему лучшие программисты — это филологи (сами того не подозревая). Что общего у переменной temp и прозвища «Очкарик»?