И руби, и хаскеля, и…
Зачем было упоминать этот тезис, если изначально автор акцентировал внимание — не ясно.
(Питон кстати хорошая параллель для ноды на беке, нода сейчас нужна в основном для SSR)
40+ человек добавили в закладки. На момент среза статистики 1.5к просмотров, что вполне неплохо, статья нашла своих читателей.
Все дело в том, что я не вижу проблемы в приведенном выше кейсе.
И как изначально начался тред, императивно код писать лучше в нижних слоях приложения, либо выносить это в отдельные слои.
Почему вы думаете, что я не приемлю императивного кода ВЕЗДЕ я не знаю, я такого не говорил.
Понятиями «интерактивного кода» и «инвариантов», я не владею, сорри.
Под императивным я понимаю код формата
this.props.someStore.myCounter += 1
И этот метод описания прямо таки форсят, подавая как фичу технологии, используя такой стиль практически в каждой статье официальной доки.
Можно и с mobx писать декларативно, но тогда по сути, это ничем не будет отличаться от тех же редаксоподобных стейт-менеджеров, на самом низшем уровне получая функцию с сайд эффектом, либо интерцепторы, которые будут аналогами локальных редьюсеров.
По моему, я достаточно определил свою точку зрения выше)
Если инструмент пропагандирует подход, который либо трусы, либо крестик, то может проблема в инструменте?
Упаси Бог)
Много проектов использует такой подход?
Даже в официальной доке про то, что это бест практис по использованию ни слова
Да и количество бойлерплейта которое придется писать переплюнет любой редакс, провоцируя в разы больше ошибок, чем использование либы в «голом» виде
¯\_(ツ)_/¯
Думаю, не мне Вас учить, как в декларативном программировании обыгрываются сайд-эффекты, проблему которых Вы описали)
Я не пропагандирую табу любой императивщины, ибо ИТ, в своем корне — чистый императив, но говорю, что подход mobx, Vuex,… — заранее настраивает разработчиков писать императивный код. Хорошие программисты вынесут в нижние слои абстракций и не будут знать проблем, но ведь суть технологии свести проблемы проектирования приложения, архитектуры, кода к минимуму, и желательно для любого уровня программиста)
Тот мизер эдж-кейсов, где императивность могла бы быть оправдана подтверждает правило, что декларативность (ВНЕЗАПНО) декларативнее, нагляднее, читабельней. Это позволяет сконцентрироваться на том, что происходит, а не как происходит. Никто не мешает написать императивно любую из низкоуровневых функций, я не накладывал на это табу в своем сообщении)
Однако, опять же, на своей памяти в реальной жизни не встречал ни одного подобного кейса)
Да, только поинт про утечку памяти, если писать код декларативно — не я привел)
Чьи утверждения после этого более голословны нужно бы проверить)
Декларативность кода заключается не только в каррировании функций, да и даже в них нет никакой особой проблемы. Даже при вызове в 100 раз, хотя тут опять же проблема архитектурного масштаба, не случится ничего криминального. С большой долей уверенности, скажу — то что жрет память как не в себя в декларативном виде, отожрет ее с той же прожорливостью и в императивном, пусть даже и немного меньше. Кроме того, сильно зависит от того, как написать
Тут это не причем, оно может быть реактивным и без мутаций основанных на магических геттерах и сеттерах, которые как раз таки усложняют чтение кода и дебаг.
Пример
С ростом проекта, возможность держать граф мутаций в голове стремится к уровню «импоссибюро», и проецируя этот кейс на приведенный пример, можно прикинуть, насколько болезненными такие концепции могут быть
Ну для кого не пару, волен искать себе направление деятельности внутри своего стека в таком случае, вакансий хватает на самый разный вкус фломастеров)
Дискриминации по стейт-менеджерам благо нет, да и парадигм всего 2 (в общем случае), если работал по обе стороны, хотя бы раз, без труда разберешься и в остальных (та же суть, другое апи)
Все таки свичнуть стейт менеджер — не менять фреймворк со всей экосистемой вместе)
Окей, тогда фан факт: предельное количество петель определяется банальным счетчиком, и когда он прощёлкивается, то система считает, что луп бесконечный и скипает остальные обновления
Отсюда можем получить стейт-специфик баги и прочее)
Таки да, есть такой минус
Но тут вопрос в том, что больнее — юзать неудобный инструмент, или при смене части стека потратить пару дней на вливание в новую технологию
Когда одна мутация вызывает другую, которая вызывает третью, которая..., которая вызывает первую.
В итоге, пока найдешь, кто где что триггерит, пройдёшь все круги ада и собственно этих самых мутаций.
С мутированием переменных код получается императивным, а не декларативным
Так что, склонен думать, что да, плохое :D
Зачем было упоминать этот тезис, если изначально автор акцентировал внимание — не ясно.
(Питон кстати хорошая параллель для ноды на беке, нода сейчас нужна в основном для SSR)
40+ человек добавили в закладки. На момент среза статистики 1.5к просмотров, что вполне неплохо, статья нашла своих читателей.
И как изначально начался тред, императивно код писать лучше в нижних слоях приложения, либо выносить это в отдельные слои.
Почему вы думаете, что я не приемлю императивного кода ВЕЗДЕ я не знаю, я такого не говорил.
Понятиями «интерактивного кода» и «инвариантов», я не владею, сорри.
Под императивным я понимаю код формата
И этот метод описания прямо таки форсят, подавая как фичу технологии, используя такой стиль практически в каждой статье официальной доки.
Можно и с mobx писать декларативно, но тогда по сути, это ничем не будет отличаться от тех же редаксоподобных стейт-менеджеров, на самом низшем уровне получая функцию с сайд эффектом, либо интерцепторы, которые будут аналогами локальных редьюсеров.
Если инструмент пропагандирует подход, который либо трусы, либо крестик, то может проблема в инструменте?
Много проектов использует такой подход?
Даже в официальной доке про то, что это бест практис по использованию ни слова
Да и количество бойлерплейта которое придется писать переплюнет любой редакс, провоцируя в разы больше ошибок, чем использование либы в «голом» виде
¯\_(ツ)_/¯
Я не пропагандирую табу любой императивщины, ибо ИТ, в своем корне — чистый императив, но говорю, что подход mobx, Vuex,… — заранее настраивает разработчиков писать императивный код. Хорошие программисты вынесут в нижние слои абстракций и не будут знать проблем, но ведь суть технологии свести проблемы проектирования приложения, архитектуры, кода к минимуму, и желательно для любого уровня программиста)
Тот мизер эдж-кейсов, где императивность могла бы быть оправдана подтверждает правило, что декларативность (ВНЕЗАПНО) декларативнее, нагляднее, читабельней. Это позволяет сконцентрироваться на том, что происходит, а не как происходит. Никто не мешает написать императивно любую из низкоуровневых функций, я не накладывал на это табу в своем сообщении)
Однако, опять же, на своей памяти в реальной жизни не встречал ни одного подобного кейса)
Чьи утверждения после этого более голословны нужно бы проверить)
Декларативность кода заключается не только в каррировании функций, да и даже в них нет никакой особой проблемы. Даже при вызове в 100 раз, хотя тут опять же проблема архитектурного масштаба, не случится ничего криминального. С большой долей уверенности, скажу — то что жрет память как не в себя в декларативном виде, отожрет ее с той же прожорливостью и в императивном, пусть даже и немного меньше. Кроме того, сильно зависит от того, как написать
Приведите пример кода, который в декларативном виде отъедает много памяти, а в императивном — нет)
До этого, кейс слишком космический)
UPD: увидел, с этим стало понятнее)
В большинстве кейсов, затык в производительности, при замене императивного на декларативное — траблы с архитектурой.
(даже если убрать луп)
С ростом проекта, возможность держать граф мутаций в голове стремится к уровню «импоссибюро», и проецируя этот кейс на приведенный пример, можно прикинуть, насколько болезненными такие концепции могут быть
Дискриминации по стейт-менеджерам благо нет, да и парадигм всего 2 (в общем случае), если работал по обе стороны, хотя бы раз, без труда разберешься и в остальных (та же суть, другое апи)
Все таки свичнуть стейт менеджер — не менять фреймворк со всей экосистемой вместе)
Отсюда можем получить стейт-специфик баги и прочее)
Но тут вопрос в том, что больнее — юзать неудобный инструмент, или при смене части стека потратить пару дней на вливание в новую технологию
В итоге, пока найдешь, кто где что триггерит, пройдёшь все круги ада и собственно этих самых мутаций.
С мутированием переменных код получается императивным, а не декларативным
Так что, склонен думать, что да, плохое :D