Согласен. Наличие собственной картины мира не означает возможности её осознанного использования. Персональный ИИ-агент такого рода - идеальный манипулятор своим "боссом".
Но с другой стороны, люди всегда пытались манипулировать другими - разговоры "по душам", письма-записки, стихи-книги, газеты-журналы, радио-телевидение, театр-кино. У кого-то это получается лучше, у кого-то хуже. Кто-замечает такого рода манипуляции, кто-то - нет. Это просто другой уровень. Ещё один. Надеюсь, не последний :)
Нет, не шучу. Абсолютно серьёзен :) У каждого в голове есть своя персональная картина мира. У одних она более связная, у других - менее.
Но вот это "майонез", "Махеев", "масло", "машина", "СОШ", "гимназия" - это всё её фрагменты у какого-то конкретного человека. (О)сознание без этого просто невозможно.
Я в восторге, коллега! Вы как будто залезли мне в голову и изложили мои собственные мысли. Я даже поначалу начал анализировать, где могла быть утечка :)
«От приложений к намерениям», «Цифровая модель мира», «Когда агент получает право действовать» — это всё то, что я сейчас обсуждаю с Моделями и над чем работаю. Но различия в деталях есть, так что, похоже, мы просто независимо копаем в одну сторону. Думаю, мы попали в общий тренд, а Модели ещё и унифицируют нашу терминологию.
Поэтому следующая большая война Apple, Google, OpenAI, Meta и других компаний может быть не за лучшую LLM, а за право стать персональным агентом по умолчанию.
Вот тут я смотрю немного иначе. Люди действительно охотно отдают большим платформам часть своих данных в обмен на удобство. Но полная персональная Картина Мира — отношения, цели, обязательства, привычки, слабости, история решений — это уже совсем другой уровень риска.
LLM вполне может быть облачной и сменной: сегодня OpenAI, завтра Anthropic, послезавтра кто-то ещё. А сама Картина Мира, на мой взгляд, должна оставаться под контролем человека и не зависеть от конкретного поставщика. Грубо говоря, должна сохраняться возможность «хранить свою Картину Мира на флешке» и переносить её между моделями, агентами и инфраструктурами. Не буквально на флешке, конечно :) Это скорее вопрос собственности и независимости. В ЕС это ещё хорошо ложится на уже существующее стремление контролировать персональные данные. Вы сами хорошо описали основания для этого в разделе «Новые угрозы».
Насчёт Agentic First и Agentic Native — полностью согласен. Интерфейс сильно изменится: возрастёт роль голосового ввода, уменьшится роль клавиатуры и мыши, а визуализация на экране останется важной.
При этом человек будет напрямую участвовать во всё меньшей доле коммуникаций: условно 20% → 10% → 5%. Остальное уйдёт под воду: агент ↔ агент, агент ↔ сервис, агент ↔ инструмент. MCP и A2A здесь как раз выглядят частью этой подводной стороны айсберга.
И вот что мне особенно интересно: у вас уже есть какие-то наработки по отображению персональной Картины Мира человека и её структурированию?
Рамки антропоморфизма. Делать ИИ "больно", пытаясь пробудить в нём "сознание".
Он другой. Просто другой. Не похожий на нас. Как общий интеллект всего человечества не похож на интеллект отдельного человека. Но и то, и другое, и третье - интеллекты.
Это подробный обзор статьи о BabelChat — переводчике чата для World of Warcraft. Автор описывает проблему языкового барьера в кросс‑серверных группах и как из идеи создать чат‑переводчик вырастает двупроцессная архитектура: аддон WoW на Lua, читающий чаты внутри игры, и внешний компаньон, который через чтение памяти процесса добывает текст и выполняет разбор перевода и оверлей. В тексте подробно сравниваются существующие решения (WoW Translator от Pirson, Prat и WoWChatLog.txt) и объясняется, почему они не удовлетворяли требованиям для оперативного перевода тактики в боях. Далее описывается поток обмена между двумя процессами: как чат попадает в кольцевой буфер аддона, как компаньон сканирует память регионами, ищет маркеры и превращает их в перевод, возвращая результат в чат игры. Центральная идея — держать якорь и константу‑указатель рядом с живым буфером: фиксированное число в сохранённой таблице (якорь) и адрес следующей строки; эта конструкция обеспечивает надёжность поиска буфера после перестроений таблицы. В статье подробно разбираются эксперименты: от чтения буфера через разные подходы до сравнения старого и нового метода через якорь; описываются проблемы zombie‑буферов, когда мёртвая копия остаётся читаемой и как вводится механизм пульса и проверки памяти. Приводятся примеры кода в виде фрагментов для иллюстрации IsUsable и защитных обёрток вокруг конкатенации строк. В итоге приведены цифры по загрузке процессора, объёму памяти, числу проходов по памяти и задержкам перевода; обсуждаются ограничения: отсутствие гарантий совместимости с обновлениями клиента Blizzard, невозможность снять секретные значения эпохального ключа, вопросы безопасности и зависимости от версий. В заключение — обзор проекта BabelChat, его связь с TAUSIK и SENAR, ссылки на репозитории и итоговые уроки исследования.
Я начинал общаться с агентами на английском, сейчас общаюсь на русском - мне так удобнее. Между собой они сейчас общаются на английском, чтобы мне понятно было, но, в теории, могут и на своём.
Мне агенты пишут код на JS - я его понимаю лучше остальных. Иногда shell-скрипты пишут. Но агенты для себя (подсобные утилиты) могут и на других языках писать, на том же python, например. Если дать им в доступ виртуальный сервер и все права на него, так они могут и другие runtime'ы понаставить.
Мне, как конечному пользователю, всё равно, на чём они пишут. Мне главное, чтобы мои персональные запросы закрывались.
Я в детстве у бабули в деревне гусей пас. Надо было их гонять на выпас и обратно. Могу сказать, что, на мой взгляд, философия идеи Software 3.0 - это "философия пастуха".
Гуси в принципе не понимают команды "отсюда и до колхозного поля по правой дороге шагом марш!" (спецификация). С ним рядом нужно идти и направлять. Палкой, рукой, шапкой, на велосипеде, ногами, можно кричать, можно свистеть, а можно вообще слов не говорить.
Это я к тому, что не важно, на каком языке "загонять LLM к цели" - на английском или на русском. LLM в принципе не может залезть в голову человеку и собрать для него "электронный магазин со всеми свистелками и перделками" как он это себе представляет. LLM может лишь создать "среднестатистический электронный магазин", который будет таким же юзабельным, как "кресло для среднего пилота".
Философия идеи Software 3.0 - персональные программы. Пишутся конкретным человеком под самого себя и изменяются всю жизнь.
.agents/skills/{skill-name}/SKILL.md - навыки проекта
.agents/ - это попытка унификации нахождения места для навыков между различными вендорами. В эту сторону двигаются Codex, Gemini, GitHubCopilot, OpenCode, Replit, Windsurf, ... Claude Code придерживается наименования .claude/ .
То есть, можно в проекте иметь два каталога для проектных скиллов (.agents/ и .claude/) и просто ставить симлинки на соответствующим образом оформленные навыки в зависимостях из обоих каталогов.
Одного этого уже достаточно, чтобы агенты в принципе могли использовать эти навыки. Это их образ действия.
README.md - это для людей, в первую очередь. Агент тоже может читать README.md, но читает в первую очередь AGENTS.md. Я сейчас говорю не за поиск в интернете, а за доставку skill-инструкций в зависимостях прямо в приложение.
Например, у меня в проекте mindstream навыки проекта выглядят так:
Зелёным выделены ссылки к навыкам зависимостей
В проекте есть один "свой" навык - соглашения по проекту и 6 ссылок на навыки зависимостей. Все ссылочные зависимости поставляются в составе npm-пакета через npm-реестр:
Навык поставляется вместе с runtime-кодом.
Не обязательно линковать все навыки зависимостей, достаточно только тех, которые нужны для разработки проекта.
При помощи ИИ-агента сгенерил приложение, которое читает RSS-ленту Хабра, извлекает тексты постов, через ИИ делает две свёртки (короткую и побольше) и ретранслирует уже эти свёртки через SPA. Для каждой публикации ИИ на сервере считает эмбеддинг-вектор, а приложение в браузере отслеживает, какие статьи привлекли моё внимание. То есть, на основании векторов "кликнутых" постов рассчитывается вектор интересов пользователя. Ну и потом можно эти вектора сравнивать и подсвечивать публикации, для которых эти вектора достаточно близкие.
Публикации свёртываются и эмбеддинги считаются на сервере, персональные вектора интересов рассчитываются в каждом браузере отдельно, но можно разрешить анонимно отправлять клики на сервер - планировал агрегировать и давать статистику по интересу аудитории к публикациям. Но как-то всё руки не доходят, да и аудитории, как таковой, нет. А свои интересы мне и в браузере показываются.
На всю ИИшную обработку у меня уходит 3-4 доллара в месяц через OpenAI API. Сделал для себя и пользуюсь время от времени. Если кто попробует - буду благодарен за обратную связь (в личку на Хабре или на github).
Вот я и пытаюсь сделать червей с мозгами, у которых нет проблемы отсутствия внешнего события.
Депривация даже для людей психически здоровых испытание сложное. В чём вообще смысл существования в отсутствии внешних событий? Почему это проблема, которую надо решить?
Мне кажется, что автор публикации верно указал на необходимость наличия "постоянно разомкнутого контура" для появления "существа, обладающего внутренними мотивами, способного скучать, ...".
Пожалуйста, не лишайте "червей с мозгами" внешних событий! Им и так нелегко.
В школе учат школьников, а детей учат в детском саду - держать ложку и ходить на горшок. Я прочитал ваш пассаж, как утверждение, что “DI-сектанты элементарного не понимают - ни как ложку в руках держать, ни как в горшок ходить”.
Вы, разумеется “ничего такого” не имели в виду. Ну так и я “ничего такого” не имел в виду, указав, что вы не смогли самостоятельно увидеть за фабричной функцией:
function createService(...) {
return ...
}
класс
class Service {
constructor(...) {...}
}
Просто констатировал этот факт.
Некоторые утверждают, что “класс - это синтаксический сахар над системой прототипов”, а вы назвали это “драматическим усложнением” базовых правил языка. Хотя, на мой взгляд, class - это то, чему “учат в школе”, “классе в 4-м” (если принять первых 5 глав учебника за основы - “детский сад”, как вы, на мой взгляд, предложили основы называть).
Уход в абстрактные классы и тем более в интерфейсы - этого в “JS-школе” не преподают. Здесь уже нужно “университетское” (универсальное, междисциплинарное) “образование”. А когда вы поймёте для чего используются интерфейсы в программировании, вот тогда вам станет понятно, как именно вы сможете их использовать в решении своих задач. И до этого момента ни я, ни кто-либо другой не сможет вам “доказать”, что вам “нужен DI в JS”.
В моей реплике нет ничего оскорбительного - уровни бывают разные. Доктор наук - это тоже уровень. Оскорбительное есть в вашей:
saveName - это первый урок по программированию для детей.
Мне этот пассаж показался несколько неуместным для дискуссии про DI в JS на Хабре и я его отзеркалил. Ваша реакция показывает, что, да - ваша реплика всё-таки содержит некую толику оскорбления и очень хорошо, что вы тоже это заметили.
К сожалению, мне нечего более добавить к моему примеру. Могу только переписать его в более привычном для некоторых виде:
Если вы не понимаете заложенные в этом коде идеи, то вам это и не надо. Для ваших задач это не надо, вот вас и не триггерит.
Поэтому и говорят, что в JavaScript DI не нужен. Хотя лучше сказать, что он нигде не нужен.
И вы ведь не пытаетесь понять, где вы можете применить DI, вы пытаетесь объяснить, почему мне не нужно применять DI. Вам DI нужен примерно нигде, а вы просите, чтобы вас переубедили.
Я лично, на практике, убедился в полезности DI для меня (и в Java, и в PHP), поэтому я пытаюсь добиться аналогичного удобства от JavaScript. Для себя, не для вас. Мне всё равно, каким образом вы решаете стоящие перед вами задачи - каким вам удобно, тем и решаете.
На вопрос, чем подмена через DI лучше подмены через манкипатчинг, внятного ответа никто не даёт.
Даёт, только вы не слышите.
Можно, пожалуйста, без загадок, а с конкретными примерами конкретных проблем? Я расписал вам пример и аргументацию так чётко, как только мог.
Нет, нельзя. У нас тут не учебное заведение. Мы тут меняемся знаниями на взаимовыгодных условиях.
Что будет, если сделать import ./storage.js до того, как сделать vi.mock('./storage.js'...)? Например, в setupFiles? Статические импорты - они такие.
Вот это самый что ни на есть конкретный пример. Вам даже код не надо писать, если вы понимаете, что стоит за этими словами. Но вы не понимаете
Вы даже эксперимент с setupFiles в vitest не поставили.
Проблема в том, что вы лениво загружаете модули, но не загружаете лениво зависимости.
С ростом объёма кода отдельного приложения, написанного на JS, перед разработчиками начинают вставать те же проблемы, с которыми сталкивались разработчики на других ЯП в "кровавом энтерпрайзе". Это хорошо, значит всё больше JS-программистов начнёт видеть пользу в методах, применяемых в "кровавом энтерпрайзе" (интерфейсы, внедрение зависмостей и прочий SOLID). Всё то, что не нужно на отдельной веб-страничке, но без чего не строятся кодовые базы на 1+ MLOC.
Согласен. Наличие собственной картины мира не означает возможности её осознанного использования. Персональный ИИ-агент такого рода - идеальный манипулятор своим "боссом".
Но с другой стороны, люди всегда пытались манипулировать другими - разговоры "по душам", письма-записки, стихи-книги, газеты-журналы, радио-телевидение, театр-кино. У кого-то это получается лучше, у кого-то хуже. Кто-замечает такого рода манипуляции, кто-то - нет. Это просто другой уровень. Ещё один. Надеюсь, не последний :)
Нет, не шучу. Абсолютно серьёзен :) У каждого в голове есть своя персональная картина мира. У одних она более связная, у других - менее.
Но вот это "майонез", "Махеев", "масло", "машина", "СОШ", "гимназия" - это всё её фрагменты у какого-то конкретного человека. (О)сознание без этого просто невозможно.
Я в восторге, коллега! Вы как будто залезли мне в голову и изложили мои собственные мысли. Я даже поначалу начал анализировать, где могла быть утечка :)
«От приложений к намерениям», «Цифровая модель мира», «Когда агент получает право действовать» — это всё то, что я сейчас обсуждаю с Моделями и над чем работаю. Но различия в деталях есть, так что, похоже, мы просто независимо копаем в одну сторону. Думаю, мы попали в общий тренд, а Модели ещё и унифицируют нашу терминологию.
Вот тут я смотрю немного иначе. Люди действительно охотно отдают большим платформам часть своих данных в обмен на удобство. Но полная персональная Картина Мира — отношения, цели, обязательства, привычки, слабости, история решений — это уже совсем другой уровень риска.
LLM вполне может быть облачной и сменной: сегодня OpenAI, завтра Anthropic, послезавтра кто-то ещё. А сама Картина Мира, на мой взгляд, должна оставаться под контролем человека и не зависеть от конкретного поставщика. Грубо говоря, должна сохраняться возможность «хранить свою Картину Мира на флешке» и переносить её между моделями, агентами и инфраструктурами. Не буквально на флешке, конечно :) Это скорее вопрос собственности и независимости. В ЕС это ещё хорошо ложится на уже существующее стремление контролировать персональные данные. Вы сами хорошо описали основания для этого в разделе «Новые угрозы».
Насчёт Agentic First и Agentic Native — полностью согласен. Интерфейс сильно изменится: возрастёт роль голосового ввода, уменьшится роль клавиатуры и мыши, а визуализация на экране останется важной.
При этом человек будет напрямую участвовать во всё меньшей доле коммуникаций: условно 20% → 10% → 5%. Остальное уйдёт под воду: агент ↔ агент, агент ↔ сервис, агент ↔ инструмент. MCP и A2A здесь как раз выглядят частью этой подводной стороны айсберга.
И вот что мне особенно интересно: у вас уже есть какие-то наработки по отображению персональной Картины Мира человека и её структурированию?
Это авторский стиль. Чтобы каждому было сразу понятно что "$mol всегда попадает в яблочко"! И он действительно сложился ещё до появления нейронок.
Рамки антропоморфизма. Делать ИИ "больно", пытаясь пробудить в нём "сознание".
Он другой. Просто другой. Не похожий на нас. Как общий интеллект всего человечества не похож на интеллект отдельного человека. Но и то, и другое, и третье - интеллекты.
Ну тогда уж идите до конца и создавайте для ИИ смерть. Либо просто примите, что это другой тип интеллекта - распределённый и бессознательный.
Может не надо загонять всех и всё в одни рамки?
Вот тут публикацию пересказали вот так:
Скрытый текст
Это подробный обзор статьи о BabelChat — переводчике чата для World of Warcraft. Автор описывает проблему языкового барьера в кросс‑серверных группах и как из идеи создать чат‑переводчик вырастает двупроцессная архитектура: аддон WoW на Lua, читающий чаты внутри игры, и внешний компаньон, который через чтение памяти процесса добывает текст и выполняет разбор перевода и оверлей. В тексте подробно сравниваются существующие решения (WoW Translator от Pirson, Prat и WoWChatLog.txt) и объясняется, почему они не удовлетворяли требованиям для оперативного перевода тактики в боях. Далее описывается поток обмена между двумя процессами: как чат попадает в кольцевой буфер аддона, как компаньон сканирует память регионами, ищет маркеры и превращает их в перевод, возвращая результат в чат игры. Центральная идея — держать якорь и константу‑указатель рядом с живым буфером: фиксированное число в сохранённой таблице (якорь) и адрес следующей строки; эта конструкция обеспечивает надёжность поиска буфера после перестроений таблицы. В статье подробно разбираются эксперименты: от чтения буфера через разные подходы до сравнения старого и нового метода через якорь; описываются проблемы zombie‑буферов, когда мёртвая копия остаётся читаемой и как вводится механизм пульса и проверки памяти. Приводятся примеры кода в виде фрагментов для иллюстрации IsUsable и защитных обёрток вокруг конкатенации строк. В итоге приведены цифры по загрузке процессора, объёму памяти, числу проходов по памяти и задержкам перевода; обсуждаются ограничения: отсутствие гарантий совместимости с обновлениями клиента Blizzard, невозможность снять секретные значения эпохального ключа, вопросы безопасности и зависимости от версий. В заключение — обзор проекта BabelChat, его связь с TAUSIK и SENAR, ссылки на репозитории и итоговые уроки исследования.
Я начинал общаться с агентами на английском, сейчас общаюсь на русском - мне так удобнее. Между собой они сейчас общаются на английском, чтобы мне понятно было, но, в теории, могут и на своём.
Мне агенты пишут код на JS - я его понимаю лучше остальных. Иногда shell-скрипты пишут. Но агенты для себя (подсобные утилиты) могут и на других языках писать, на том же python, например. Если дать им в доступ виртуальный сервер и все права на него, так они могут и другие runtime'ы понаставить.
Мне, как конечному пользователю, всё равно, на чём они пишут. Мне главное, чтобы мои персональные запросы закрывались.
Я в детстве у бабули в деревне гусей пас. Надо было их гонять на выпас и обратно. Могу сказать, что, на мой взгляд, философия идеи Software 3.0 - это "философия пастуха".
Гуси в принципе не понимают команды "отсюда и до колхозного поля по правой дороге шагом марш!" (спецификация). С ним рядом нужно идти и направлять. Палкой, рукой, шапкой, на велосипеде, ногами, можно кричать, можно свистеть, а можно вообще слов не говорить.
Это я к тому, что не важно, на каком языке "загонять LLM к цели" - на английском или на русском. LLM в принципе не может залезть в голову человеку и собрать для него "электронный магазин со всеми свистелками и перделками" как он это себе представляет. LLM может лишь создать "среднестатистический электронный магазин", который будет таким же юзабельным, как "кресло для среднего пилота".
Философия идеи Software 3.0 - персональные программы. Пишутся конкретным человеком под самого себя и изменяются всю жизнь.
Хабр рассчитал время, а уровень поставил Автор.
У разных моделей разные ответы. Всё, как у людей.
Спасибо на добром слове, коллега :)
.agents/skills/- это соглашение о нахождении навыков для OpenAI (я работаю с Codex'ом, в основном).~/.agents/skills/{skill-name}/SKILL.md- навыки пользователя.agents/skills/{skill-name}/SKILL.md- навыки проекта.agents/- это попытка унификации нахождения места для навыков между различными вендорами. В эту сторону двигаются Codex, Gemini, GitHubCopilot, OpenCode, Replit, Windsurf, ... Claude Code придерживается наименования.claude/.То есть, можно в проекте иметь два каталога для проектных скиллов (
.agents/и.claude/) и просто ставить симлинки на соответствующим образом оформленные навыки в зависимостях из обоих каталогов.Одного этого уже достаточно, чтобы агенты в принципе могли использовать эти навыки. Это их образ действия.
README.md - это для людей, в первую очередь. Агент тоже может читать README.md, но читает в первую очередь AGENTS.md. Я сейчас говорю не за поиск в интернете, а за доставку skill-инструкций в зависимостях прямо в приложение.
Например, у меня в проекте mindstream навыки проекта выглядят так:
В проекте есть один "свой" навык - соглашения по проекту и 6 ссылок на навыки зависимостей. Все ссылочные зависимости поставляются в составе npm-пакета через npm-реестр:
Не обязательно линковать все навыки зависимостей, достаточно только тех, которые нужны для разработки проекта.
https://mindstream.app.wiredgeese.com/ - я с него сюда и выскочил. Н-да... свёртку надо доработать.
Ну, лично я против нейрослопа применил нейронку - https://mindstream.app.wiredgeese.com/
При помощи ИИ-агента сгенерил приложение, которое читает RSS-ленту Хабра, извлекает тексты постов, через ИИ делает две свёртки (короткую и побольше) и ретранслирует уже эти свёртки через SPA. Для каждой публикации ИИ на сервере считает эмбеддинг-вектор, а приложение в браузере отслеживает, какие статьи привлекли моё внимание. То есть, на основании векторов "кликнутых" постов рассчитывается вектор интересов пользователя. Ну и потом можно эти вектора сравнивать и подсвечивать публикации, для которых эти вектора достаточно близкие.
Публикации свёртываются и эмбеддинги считаются на сервере, персональные вектора интересов рассчитываются в каждом браузере отдельно, но можно разрешить анонимно отправлять клики на сервер - планировал агрегировать и давать статистику по интересу аудитории к публикациям. Но как-то всё руки не доходят, да и аудитории, как таковой, нет. А свои интересы мне и в браузере показываются.
На всю ИИшную обработку у меня уходит 3-4 доллара в месяц через OpenAI API. Сделал для себя и пользуюсь время от времени. Если кто попробует - буду благодарен за обратную связь (в личку на Хабре или на github).
Более подробное объяснение - тут.
Кстати, именно этой статьи у меня в ленте и нет :( Где-то сбоит, видимо.
Спасибо. Сработал "Майерсов закон письменной речи" :)
Депривация даже для людей психически здоровых испытание сложное. В чём вообще смысл существования в отсутствии внешних событий? Почему это проблема, которую надо решить?
Мне кажется, что автор публикации верно указал на необходимость наличия "постоянно разомкнутого контура" для появления "существа, обладающего внутренними мотивами, способного скучать, ...".
Пожалуйста, не лишайте "червей с мозгами" внешних событий! Им и так нелегко.
del
В школе учат школьников, а детей учат в детском саду - держать ложку и ходить на горшок. Я прочитал ваш пассаж, как утверждение, что “DI-сектанты элементарного не понимают - ни как ложку в руках держать, ни как в горшок ходить”.
Вы, разумеется “ничего такого” не имели в виду. Ну так и я “ничего такого” не имел в виду, указав, что вы не смогли самостоятельно увидеть за фабричной функцией:
класс
Просто констатировал этот факт.
Некоторые утверждают, что “класс - это синтаксический сахар над системой прототипов”, а вы назвали это “драматическим усложнением” базовых правил языка. Хотя, на мой взгляд,
class- это то, чему “учат в школе”, “классе в 4-м” (если принять первых 5 глав учебника за основы - “детский сад”, как вы, на мой взгляд, предложили основы называть).Уход в абстрактные классы и тем более в интерфейсы - этого в “JS-школе” не преподают. Здесь уже нужно “университетское” (универсальное, междисциплинарное) “образование”. А когда вы поймёте для чего используются интерфейсы в программировании, вот тогда вам станет понятно, как именно вы сможете их использовать в решении своих задач. И до этого момента ни я, ни кто-либо другой не сможет вам “доказать”, что вам “нужен DI в JS”.
Вам - не нужен. Пока что, будем надеяться.
В моей реплике нет ничего оскорбительного - уровни бывают разные. Доктор наук - это тоже уровень. Оскорбительное есть в вашей:
Мне этот пассаж показался несколько неуместным для дискуссии про DI в JS на Хабре и я его отзеркалил. Ваша реакция показывает, что, да - ваша реплика всё-таки содержит некую толику оскорбления и очень хорошо, что вы тоже это заметили.
К сожалению, мне нечего более добавить к моему примеру. Могу только переписать его в более привычном для некоторых виде:
Если вы не понимаете заложенные в этом коде идеи, то вам это и не надо. Для ваших задач это не надо, вот вас и не триггерит.
И вы ведь не пытаетесь понять, где вы можете применить DI, вы пытаетесь объяснить, почему мне не нужно применять DI. Вам DI нужен примерно нигде, а вы просите, чтобы вас переубедили.
Я лично, на практике, убедился в полезности DI для меня (и в Java, и в PHP), поэтому я пытаюсь добиться аналогичного удобства от JavaScript. Для себя, не для вас. Мне всё равно, каким образом вы решаете стоящие перед вами задачи - каким вам удобно, тем и решаете.
Даёт, только вы не слышите.
Нет, нельзя. У нас тут не учебное заведение. Мы тут меняемся знаниями на взаимовыгодных условиях.
Вот это самый что ни на есть конкретный пример. Вам даже код не надо писать, если вы понимаете, что стоит за этими словами. Но вы не понимаете
и не желаете понимать.
Поэтому могу лишь процитировать сам себя:
Всего хорошего вам и приятного кодирования!!
С ростом объёма кода отдельного приложения, написанного на JS, перед разработчиками начинают вставать те же проблемы, с которыми сталкивались разработчики на других ЯП в "кровавом энтерпрайзе". Это хорошо, значит всё больше JS-программистов начнёт видеть пользу в методах, применяемых в "кровавом энтерпрайзе" (интерфейсы, внедрение зависмостей и прочий SOLID). Всё то, что не нужно на отдельной веб-страничке, но без чего не строятся кодовые базы на 1+ MLOC.