что хорошо по возможности смотреть на вещи детскими глазами, и восхищаться
В теории это бы хорошо, но мне кажется, что автор куда больше воображает себе, как это выглядело в прошлом, а не реконструирует реальную ситуацию.
Я споткнулся ещё на этапе "как, вы ещё не умерли на пути в Афганистан?" Европейский купец, конечно, ни в какой Афганистан не ехал. Ехал максимум в Испанию, где всё нужное покупалось у арабского торговца, который тоже ехал до ближайшей удобной для него точки и т.п. В Риме был китайский шёлк, но не ездили римские купцы в Китай.
Аналогично, тема про восхищение цветом плаща Девы Марии плохо одетым крестьянином. Было оно так или нет, вопрос открытый, но автору приятно воображать, что было ровно так.
По моему опыту, LLM хорошо работает в диалоговом режиме. Не надо рассчитывать на правильный ответ с первого тычка. Ну да, он выдал неработающий код. Надо ему объяснить, что этот код не работает потому-то и потому-то, давай переделаем. Обычно через пару итераций ответ находится, и это всё равно быстрее, чем любой другой способ.
Мне кажется, разговоры о скорой смерти Stack Overflow и аналогичных площадок опираются на изначально нереалистичные представления о пользовательской базе. Средний посетитель сайта хочет решить конкретную проблему, которая у него возникла, и идёт туда по сути от безысходности. Если решение гуглится в другом месте или решается запросом в ChatGPT, у такого человека даже не возникает желания как-то взаимодействовать с сообществом SO.
Так что логично, что когда появилась альтернатива, трафик упал. На SO самыми интересными всегда были обсуждения каких-то неочевидных тонкостей, куда нередко приходили сами авторы обсуждаемых технологий и объясняли, почему было сделано так, а не иначе. И в этом отношении более ядовит тренд "slow decline" -- видимо, затея потеряла свежесть, и реальные эксперты, наигравшись в вопросы-ответы, перестали тратить на это своё время.
Да меня, знаете ли, вообще не волнует мотивация автора. Допустим, он это сделал для того, чтобы срубить бабла. Мне-то что? Я считаю, что классификация и систематизация нужны и полезны, а если кто-то делает эту работу ради денег -- win/win.
Да я, в общем-то, с ним и не спорил :) Я ответил на другой коммент, не так ли? Но если уж вот про это --
Но мужик молодец — срубил бабло на ровном месте!
Моё скромное мнение состоит в том, что систематизация и периодика -- очень важная вещь в науке и технике. До Линнея тоже вроде было известно, что рыбы это не птицы, но спасибо, что озаботился.
Ну да, авторы об этом прямо пишут в предисловии, в чём проблема? Они предлагают каталог решений (неважно, чьих) и дают им стандартные имена. Очень важная работа. Пифагор не называл свою теорему "теоремой Пифагора", а мы пользуемся, удобно.
В STL нет контейнера std::visitor, ни в стандарте C++23, ни в стандарте C++26.
Если вы подходите с позиции пуриста, который называет словом "STL" библиотеку шаблонов, написанную Степановым до выхода книги GoF, то в чём аргумент? Степанов не знал паттернов из невышедшей книги?
Скажем, итератор -- это 100% пример паттерна проектирования, высокоуровневый концепт, и если в STL это слово используется несколько иначе, чем в книге GoF, сути дела это не меняет нисколько.
Смотрите, вы этим занимаетесь, допустим, в качестве хобби. А вот Visual Studio Code пишут программисты большой корпорации за деньги. И разницы никакой.
Если вы хоббиист, к вам вопросов нет. Может, вам нравится иметь открытые issues. Некоторые люди документы в корзине на десктопе хранят. Но если мы говорим о более-менее профессиональной работе, я ожидаю, что issues будут закрываться (с комментарием "это есть в документации", "усложнит жизнь остальным", "не могу воспроизвести") или как-то решаться.
Но не происходит ни первого, ни второго. Вот я читаю issue и вижу, то это описано в документации. Окей, что я делаю? Тут же пишу "описано в документации" и закрываю issue. Если этого не происходит, значит, ресурсов не хватает даже на то, чтобы эти конюшни разгрести.
В большинстве случаев над системой работает N человек не потому, что их хватает, а потому, что либо нет ресурсов нанять новых, либо команда тогда разрастётся так, что придётся менять сам подход к работе (понятно, что 5 человек и 25 человек -- это совершенно разные ситуации). Если же можно сохранить текущую команду и при этом повысить производительность, работы на всех хватит.
разберусь быстрее глядя в код, чем буду слушать чьё-то объяснение на пальцам про то, как каждая итерация сортировки манипулирует элементами.
Ну вы либо гений, либо себе льстите.
When Jon Bentley assigned binary search as a problem in a course for professional programmers, he found that ninety percent failed to provide a correct solution after several hours of working on it, mainly because the incorrect implementations failed to run or returned a wrong answer in rare edge cases.[62] A study published in 1988 shows that accurate code for it is only found in five out of twenty textbooks.[63] Furthermore, Bentley's own implementation of binary search, published in his 1986 book Programming Pearls, contained an overflow error that remained undetected for over twenty years. The Java programming language library implementation of binary search had the same overflow bug for more than nine years. (Wiki)
Многие из классических алгоритмов -- quicksort, binary search, алгоритим Дейкстры неочевидно устроены и, неочевидно почему работают (даже если цель предельно ясна), и даже если вы верите, что оно работает, всё равно доказать не сможете, а код в общую базу интегрировать надо. И что делать? Если вы знаете, что конкретно тут реализуется (quicksort), то сможете сравнить с доказанно работающей референсной реализацией.
Может вы встречали языки, в которых существует стандартная библиотека, реализующая десятки паттернов проектирования и в которой эти паттерны названы в соответствии с классификацией?
Разумеется, и вы сами её назвали -- STL. Напр, std::forward_iterator -- это, очевидно, Iterator pattern, std::visitor -- Visitor pattern, std::lock -- Lock (тоже в разделе patterns).
Но в целом паттернов там немного потому, что STL -- именно про алгоритмы/процедуры. Библиотека работает на уровне ниже паттернов, которые возникают на этаж выше. Вас же не смущает, что в STL нет понятия "учётная запись пользователя", хотя во фреймворках (Django, напр.) она уже есть. Это же не значит, что не нужны учётные записи. Просто не тот этаж.
Откройте любой попуярный репозиторий на гитхабе, увидите 100500 открытых issues. Не хватает ресурсов, чтобы их разгребать и закрывать. Даже если производительность в четыре раза повысится, работы на всех хватит.
А по наблюдениям, порог входа только вырастет. Потому что код из LLM прямо в продакшн нельзя. Ну, точнее, так: push идёт всё равно от вашего имени, а не от имени LLM, которым вы пользуетесь. И если будет ошибка, прилетит вам, а не AI системе. Значит, сгенерированный код вам придётся хотя бы понимать. А для LLM нет разницы между сложным и простым, она такого наколбасит, что без определённой квалификации точно не понять.
Программист использующий нейросети для написания кода в какой-то момент превратится в ненужную прокладку.
Вопрос в том, прокладку между чем и чем? Программист, использующий нейросеть, работает, условно, 8 часов в день 5 дней в неделю, чтобы пилить какую-то функциональность или исправлять ошибки. Если он не будет этим заниматься, то кто будет давать нейросети задание? Кому-то всё равно придётся брать на себя эту работу. В парадигме "уволим всех программистов" подразумевается какой-то совершенно магический сценарий, в котором вообще между моим желанием ("хочу игру, где будут грабить корованы") и готовым продуктом отсутствуют просто все звенья, и на основании одной этой фразы по щелчку всё создаётся в автономном режиме.
Если вам дать на код-ревью даже сортировку quicksort, вы НЕ разберётесь с тем, как она работает, если не знаете этого метода, а это всего лишь несколько строк. В лучшем случае вы поймёте, что подразумевается сортировка (ибо называется sort()), но как вы докажете, что это и вправду работает без ошибок? Так и здесь, если человек не знает, что такое абстрактная фабрика, он в принципе не врубится в то, что здесь подразумевается.
Но можно придумать мотивацию и попроще. Для программирования достаточно присваивания, ветвления и перехода (машина Тьюринга). Всё остальное -- это "кем-то придуманные термины". Но на машине Тьюринга писать слишком муторно, нужны абстракции. Цикл while, цикл do, цикл for, цикл foreach -- аж четыре варианта, хотя while универсально годится для всего.
Вы начинаете рассуждать в терминах более крупных юнитов. Вы хотите цикл не от точки А до точки Б, а по всей коллекции, вот и подвозят foreach, хотя зачем? Точно так же и так называемые "паттерны" -- это просто очень высокоуровневые строительные блоки, в терминах которых может быть удобнее думать, чем на более низком уровне.
Вот как бы это всё звучит интуитивно логично, но всё же.
Я недавно поймал себя на мысли, что в наш бытовой язык проникает огромное количество довольно-таки специальных словечек и понятий: "зловещая долина", "созависимые отношения", "прайминг", "эффект низкой базы", "клинические испытания" и тому подобное. Да, для основной массы это всё на уровне тиктоков и фейсбука, но всё же уровень дискуссии в среднем по больнице вырос. Стоит сказать какую-нибудь неаккуратную вещь, так тебя тут же макнут мордой в ссылку, пусть даже на Википедию; лет 20 назад максимум бы послали на статью в газете, которая считалась авторитетным источником потому что в газете.
Мы всегда жили в среде информационного мусора и фальшивых новостей, но их небольшое в процентах количество создавало эдакий постоянный радиоактивный фон, который нас отравлял, но при этом никто на него не обращал внимания. А ведь всё время было что-то в этом роде: то Бермудский треугольник, то нитраты в овощах, то снежный человек в Гималаях. Кому бы в голову пришло спросить в те времена, какие клинические испытания прошли горчичники?
Сейчас этот фон вырос настолько, что не замечать его уже нельзя, и да, возможно, кто-то воспринимает инфу "от ИИ" некритически, но мы и газеты читали некритически, до поры до времени. А потом попадётся пару раз такой человек на дипфейк и задумается. Так что есть и позитивный аспект. Мы осознаём проблему, уже хорошо.
Аналоги этим событиям, разумеется, есть. Если считать интеллектуальным трудом, например, актёрское мастерство и музицирование, то остаётся только гадать, сколько людей не имеют возможности этим жить из-за того, что есть кино/телевизор/айтюнс, и люди потребляют записи, а не творчество команды из соседнего двора.
Теперь про "замену". Мне кажется, это всё довольно абстрактные рассуждения, а личный опыт выглядит совсем по-другому. Я уже где-то с месяц активно пользуюсь LLM-инструментами, и пока это выглядит именно как инструмент в помощь.
Мы с ним долго обсуждаем чего нужно сделать, потом по шагам что-то делает он, что-то делаю я. Пишем, тестируем. Я ему ставлю задачи: делаем то, потом будем вот это. Если в теории заказчик захочет заняться этим вместо меня, ему придётся заниматься этим полный рабочий день, какой смысл? Для меня же очевиден буст продуктивности: что делал за два дня, делаю за пол-дня, красота же. И не то что бы это какой-то интеллектуальный труд, который отбирают, скорее, наоборот -- на откуп ИИ идёт самое скучное, то, что раньше долго и упорно вычитывалось в мануалах и на форумах. Ну можно, конечно, обсудить с ним архитектуру и всё такое, и очень хорошо.
По сути под угрозой самый низкий джун-слой на этой лестнице, но там тоже масса оговорок, кто именно под угрозой, и что с этим делать.
Код-ревью, очевидно. Сидим вместе, сморим на текст. Меня спрашивают: а как у тебя это реализовано? А там класс на 100 строк, допустим. И мне нет нужды объяснять смысл любой строки, я говорю -- это абстрактная фабрика, или посетитель, или ещё чего.
Но это вообще странное направление разговора. Зачем вообще любая терминология? Зачем выучивать придуманные названия вроде "метод Гаусса решения системы линейных уравнений"? Ведь по вашей логике, никому никогда не придётся объяснять, как у вас вот этот кусок работает. А если и придётся, вы прямо по строчкам объясните, что конкретно тут происходит и заодно докажете, что это действительно работает.
Меня немного припекает от вот этого избиения соломенного чучела без ссылок. Вполне вероятно, что понятие размыто до невозможности, но приведите хотя бы три определения из более-менее авторитетной литературы, чтобы проиллюстрировать тезис. Я вот открываю Гради Буча ("ОО анализ и проектирование"), где написано следующее:
"Объектно-ориентированное программирование - это методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования. "
Размыто? На мой вкус, не более чем нужно. Если вы пишете программу, которая состоит из объектов, принадлежащих некоторым классам, которые, в свою очередь, наследуются друг от друга (в современных условиях 90% наследования будет в недрах стандартной библиотеки, а не в вашем коде) -- значит, вы пишете ОО-программу, вот и всё.
Очевидным образом, я могу вам сказать, что вот в этой подсистеме применяется синглтон, а там визитор, и не надо объяснять в подробностях что имеется в виду. Аналогично, проектировщик БД интуитивно создаёт третью нормальную форму, но если я скажу, что конкретно моя БД в третьей нормальной форме, мне не надо ссылаться на интуицию -- сразу будет ясно, как примерно там всё устроено.
В статьях такого сорта мне непонятен адресат. Во времена IT бума (условные 90-е) вполне правдоподобно выглядела ситуация, когда стартаперу 20+ лет приходилось понимать как иметь дело с потенциальным сотрудником 40+. Сейчас же демография такова, что поколение 40+ банально куда больше, и на устоявшемся рынке именно эти люди занимают управленческие позиции.
Соответственно, средний начальник и так прекрасно понимает, что представляет собой его поколение. Если не хочет брать, значит, имеет на то причины, но вряд ли в непонимании дело.
В теории это бы хорошо, но мне кажется, что автор куда больше воображает себе, как это выглядело в прошлом, а не реконструирует реальную ситуацию.
Я споткнулся ещё на этапе "как, вы ещё не умерли на пути в Афганистан?" Европейский купец, конечно, ни в какой Афганистан не ехал. Ехал максимум в Испанию, где всё нужное покупалось у арабского торговца, который тоже ехал до ближайшей удобной для него точки и т.п. В Риме был китайский шёлк, но не ездили римские купцы в Китай.
Аналогично, тема про восхищение цветом плаща Девы Марии плохо одетым крестьянином. Было оно так или нет, вопрос открытый, но автору приятно воображать, что было ровно так.
Ну у тех же This is the Police / Rebel Cops есть издатель, и кто его знает, насколько он с дубиной над головой стоит.
По моему опыту, LLM хорошо работает в диалоговом режиме. Не надо рассчитывать на правильный ответ с первого тычка. Ну да, он выдал неработающий код. Надо ему объяснить, что этот код не работает потому-то и потому-то, давай переделаем. Обычно через пару итераций ответ находится, и это всё равно быстрее, чем любой другой способ.
Мне кажется, разговоры о скорой смерти Stack Overflow и аналогичных площадок опираются на изначально нереалистичные представления о пользовательской базе. Средний посетитель сайта хочет решить конкретную проблему, которая у него возникла, и идёт туда по сути от безысходности. Если решение гуглится в другом месте или решается запросом в ChatGPT, у такого человека даже не возникает желания как-то взаимодействовать с сообществом SO.
Так что логично, что когда появилась альтернатива, трафик упал. На SO самыми интересными всегда были обсуждения каких-то неочевидных тонкостей, куда нередко приходили сами авторы обсуждаемых технологий и объясняли, почему было сделано так, а не иначе. И в этом отношении более ядовит тренд "slow decline" -- видимо, затея потеряла свежесть, и реальные эксперты, наигравшись в вопросы-ответы, перестали тратить на это своё время.
Да меня, знаете ли, вообще не волнует мотивация автора. Допустим, он это сделал для того, чтобы срубить бабла. Мне-то что? Я считаю, что классификация и систематизация нужны и полезны, а если кто-то делает эту работу ради денег -- win/win.
Да я, в общем-то, с ним и не спорил :) Я ответил на другой коммент, не так ли? Но если уж вот про это --
Моё скромное мнение состоит в том, что систематизация и периодика -- очень важная вещь в науке и технике. До Линнея тоже вроде было известно, что рыбы это не птицы, но спасибо, что озаботился.
Ну да, авторы об этом прямо пишут в предисловии, в чём проблема? Они предлагают каталог решений (неважно, чьих) и дают им стандартные имена. Очень важная работа. Пифагор не называл свою теорему "теоремой Пифагора", а мы пользуемся, удобно.
Если вы подходите с позиции пуриста, который называет словом "STL" библиотеку шаблонов, написанную Степановым до выхода книги GoF, то в чём аргумент? Степанов не знал паттернов из невышедшей книги?
Скажем, итератор -- это 100% пример паттерна проектирования, высокоуровневый концепт, и если в STL это слово используется несколько иначе, чем в книге GoF, сути дела это не меняет нисколько.
Смотрите, вы этим занимаетесь, допустим, в качестве хобби. А вот Visual Studio Code пишут программисты большой корпорации за деньги. И разницы никакой.
Если вы хоббиист, к вам вопросов нет. Может, вам нравится иметь открытые issues. Некоторые люди документы в корзине на десктопе хранят. Но если мы говорим о более-менее профессиональной работе, я ожидаю, что issues будут закрываться (с комментарием "это есть в документации", "усложнит жизнь остальным", "не могу воспроизвести") или как-то решаться.
Но не происходит ни первого, ни второго. Вот я читаю issue и вижу, то это описано в документации. Окей, что я делаю? Тут же пишу "описано в документации" и закрываю issue. Если этого не происходит, значит, ресурсов не хватает даже на то, чтобы эти конюшни разгрести.
В большинстве случаев над системой работает N человек не потому, что их хватает, а потому, что либо нет ресурсов нанять новых, либо команда тогда разрастётся так, что придётся менять сам подход к работе (понятно, что 5 человек и 25 человек -- это совершенно разные ситуации). Если же можно сохранить текущую команду и при этом повысить производительность, работы на всех хватит.
Ну вы либо гений, либо себе льстите.
When Jon Bentley assigned binary search as a problem in a course for professional programmers, he found that ninety percent failed to provide a correct solution after several hours of working on it, mainly because the incorrect implementations failed to run or returned a wrong answer in rare edge cases.[62] A study published in 1988 shows that accurate code for it is only found in five out of twenty textbooks.[63] Furthermore, Bentley's own implementation of binary search, published in his 1986 book Programming Pearls, contained an overflow error that remained undetected for over twenty years. The Java programming language library implementation of binary search had the same overflow bug for more than nine years. (Wiki)
Многие из классических алгоритмов -- quicksort, binary search, алгоритим Дейкстры неочевидно устроены и, неочевидно почему работают (даже если цель предельно ясна), и даже если вы верите, что оно работает, всё равно доказать не сможете, а код в общую базу интегрировать надо. И что делать? Если вы знаете, что конкретно тут реализуется (quicksort), то сможете сравнить с доказанно работающей референсной реализацией.
Разумеется, и вы сами её назвали -- STL. Напр,
std::forward_iterator-- это, очевидно, Iterator pattern,std::visitor-- Visitor pattern,std::lock-- Lock (тоже в разделе patterns).Но в целом паттернов там немного потому, что STL -- именно про алгоритмы/процедуры. Библиотека работает на уровне ниже паттернов, которые возникают на этаж выше. Вас же не смущает, что в STL нет понятия "учётная запись пользователя", хотя во фреймворках (Django, напр.) она уже есть. Это же не значит, что не нужны учётные записи. Просто не тот этаж.
Откройте любой попуярный репозиторий на гитхабе, увидите 100500 открытых issues. Не хватает ресурсов, чтобы их разгребать и закрывать. Даже если производительность в четыре раза повысится, работы на всех хватит.
А по наблюдениям, порог входа только вырастет. Потому что код из LLM прямо в продакшн нельзя. Ну, точнее, так: push идёт всё равно от вашего имени, а не от имени LLM, которым вы пользуетесь. И если будет ошибка, прилетит вам, а не AI системе. Значит, сгенерированный код вам придётся хотя бы понимать. А для LLM нет разницы между сложным и простым, она такого наколбасит, что без определённой квалификации точно не понять.
Вопрос в том, прокладку между чем и чем? Программист, использующий нейросеть, работает, условно, 8 часов в день 5 дней в неделю, чтобы пилить какую-то функциональность или исправлять ошибки. Если он не будет этим заниматься, то кто будет давать нейросети задание? Кому-то всё равно придётся брать на себя эту работу. В парадигме "уволим всех программистов" подразумевается какой-то совершенно магический сценарий, в котором вообще между моим желанием ("хочу игру, где будут грабить корованы") и готовым продуктом отсутствуют просто все звенья, и на основании одной этой фразы по щелчку всё создаётся в автономном режиме.
Если вам дать на код-ревью даже сортировку quicksort, вы НЕ разберётесь с тем, как она работает, если не знаете этого метода, а это всего лишь несколько строк. В лучшем случае вы поймёте, что подразумевается сортировка (ибо называется sort()), но как вы докажете, что это и вправду работает без ошибок? Так и здесь, если человек не знает, что такое абстрактная фабрика, он в принципе не врубится в то, что здесь подразумевается.
Но можно придумать мотивацию и попроще. Для программирования достаточно присваивания, ветвления и перехода (машина Тьюринга). Всё остальное -- это "кем-то придуманные термины". Но на машине Тьюринга писать слишком муторно, нужны абстракции. Цикл while, цикл do, цикл for, цикл foreach -- аж четыре варианта, хотя while универсально годится для всего.
Вы начинаете рассуждать в терминах более крупных юнитов. Вы хотите цикл не от точки А до точки Б, а по всей коллекции, вот и подвозят foreach, хотя зачем? Точно так же и так называемые "паттерны" -- это просто очень высокоуровневые строительные блоки, в терминах которых может быть удобнее думать, чем на более низком уровне.
Вот как бы это всё звучит интуитивно логично, но всё же.
Я недавно поймал себя на мысли, что в наш бытовой язык проникает огромное количество довольно-таки специальных словечек и понятий: "зловещая долина", "созависимые отношения", "прайминг", "эффект низкой базы", "клинические испытания" и тому подобное. Да, для основной массы это всё на уровне тиктоков и фейсбука, но всё же уровень дискуссии в среднем по больнице вырос. Стоит сказать какую-нибудь неаккуратную вещь, так тебя тут же макнут мордой в ссылку, пусть даже на Википедию; лет 20 назад максимум бы послали на статью в газете, которая считалась авторитетным источником потому что в газете.
Мы всегда жили в среде информационного мусора и фальшивых новостей, но их небольшое в процентах количество создавало эдакий постоянный радиоактивный фон, который нас отравлял, но при этом никто на него не обращал внимания. А ведь всё время было что-то в этом роде: то Бермудский треугольник, то нитраты в овощах, то снежный человек в Гималаях. Кому бы в голову пришло спросить в те времена, какие клинические испытания прошли горчичники?
Сейчас этот фон вырос настолько, что не замечать его уже нельзя, и да, возможно, кто-то воспринимает инфу "от ИИ" некритически, но мы и газеты читали некритически, до поры до времени. А потом попадётся пару раз такой человек на дипфейк и задумается. Так что есть и позитивный аспект. Мы осознаём проблему, уже хорошо.
Аналоги этим событиям, разумеется, есть. Если считать интеллектуальным трудом, например, актёрское мастерство и музицирование, то остаётся только гадать, сколько людей не имеют возможности этим жить из-за того, что есть кино/телевизор/айтюнс, и люди потребляют записи, а не творчество команды из соседнего двора.
Теперь про "замену". Мне кажется, это всё довольно абстрактные рассуждения, а личный опыт выглядит совсем по-другому. Я уже где-то с месяц активно пользуюсь LLM-инструментами, и пока это выглядит именно как инструмент в помощь.
Мы с ним долго обсуждаем чего нужно сделать, потом по шагам что-то делает он, что-то делаю я. Пишем, тестируем. Я ему ставлю задачи: делаем то, потом будем вот это. Если в теории заказчик захочет заняться этим вместо меня, ему придётся заниматься этим полный рабочий день, какой смысл? Для меня же очевиден буст продуктивности: что делал за два дня, делаю за пол-дня, красота же. И не то что бы это какой-то интеллектуальный труд, который отбирают, скорее, наоборот -- на откуп ИИ идёт самое скучное, то, что раньше долго и упорно вычитывалось в мануалах и на форумах. Ну можно, конечно, обсудить с ним архитектуру и всё такое, и очень хорошо.
По сути под угрозой самый низкий джун-слой на этой лестнице, но там тоже масса оговорок, кто именно под угрозой, и что с этим делать.
Код-ревью, очевидно. Сидим вместе, сморим на текст. Меня спрашивают: а как у тебя это реализовано? А там класс на 100 строк, допустим. И мне нет нужды объяснять смысл любой строки, я говорю -- это абстрактная фабрика, или посетитель, или ещё чего.
Но это вообще странное направление разговора. Зачем вообще любая терминология? Зачем выучивать придуманные названия вроде "метод Гаусса решения системы линейных уравнений"? Ведь по вашей логике, никому никогда не придётся объяснять, как у вас вот этот кусок работает. А если и придётся, вы прямо по строчкам объясните, что конкретно тут происходит и заодно докажете, что это действительно работает.
Меня немного припекает от вот этого избиения соломенного чучела без ссылок. Вполне вероятно, что понятие размыто до невозможности, но приведите хотя бы три определения из более-менее авторитетной литературы, чтобы проиллюстрировать тезис. Я вот открываю Гради Буча ("ОО анализ и проектирование"), где написано следующее:
"Объектно-ориентированное программирование - это методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования. "
Размыто? На мой вкус, не более чем нужно. Если вы пишете программу, которая состоит из объектов, принадлежащих некоторым классам, которые, в свою очередь, наследуются друг от друга (в современных условиях 90% наследования будет в недрах стандартной библиотеки, а не в вашем коде) -- значит, вы пишете ОО-программу, вот и всё.
Очевидным образом, я могу вам сказать, что вот в этой подсистеме применяется синглтон, а там визитор, и не надо объяснять в подробностях что имеется в виду. Аналогично, проектировщик БД интуитивно создаёт третью нормальную форму, но если я скажу, что конкретно моя БД в третьей нормальной форме, мне не надо ссылаться на интуицию -- сразу будет ясно, как примерно там всё устроено.
В статьях такого сорта мне непонятен адресат. Во времена IT бума (условные 90-е) вполне правдоподобно выглядела ситуация, когда стартаперу 20+ лет приходилось понимать как иметь дело с потенциальным сотрудником 40+. Сейчас же демография такова, что поколение 40+ банально куда больше, и на устоявшемся рынке именно эти люди занимают управленческие позиции.
Соответственно, средний начальник и так прекрасно понимает, что представляет собой его поколение. Если не хочет брать, значит, имеет на то причины, но вряд ли в непонимании дело.
Спасибо. Берегите себя. Люди хотят справедливости, и это понятно, но крайним всегда оказывается кто-то другой :(