по какой-то причине оба погибли в драке — вероятно, из-за внезапной песчаной бури или обвала породы.
Зачем натягивать палеоиндюка на глобус и придумывать ВНЕЗАПНЫЕ! (tm) бури и обвалы, когда есть более банальные причины: один схватил другого за конечность и начал методично наносить травмы, несовместимые с жизнью, другой, защищаясь, вспорол первому брюхо, у обоих обильное кровоизлияние и критическая потеря крови, "в общем, все умерли" (с).
Если все станочники города месяц работали и месяц бухали, создавая дефицит станочников и поднимая ставки, то их едино-месячные выплаты нужно делить пополам, чтобы получить эффективную средне-месячную зарплату. Ведь если бы они не бухали, то не было бы дефицита, и не было бы таких ставок.
Это обычно из-за агрегации: частицы летают, сталкиваются между собой, объединяются в более крупные и начинают выпадать, переставая быть аэрозолями. Либо прилипают к поверхностям при контакте.
Таких, что броуновское движение в данных условиях (плотность, температура) перестаёт быть пренебрежимо малым, поэтому взвесь никогда не выпадает в осадок.
Вы слово "фактически" пропустили? На бумаге была небесплатная, в мозгах патриотов СССР -- вообще обдираловка. По факту же вернули 25% -- причём без учёта того, что было уничтожено в боях и списано (это было 100% бесплатно).
Ну так СССР тоже щедро отсыпал невозвратных кредитов.
Угу, по принципу "мы на горе всем буржуям мировой пожар раздуем".
Именно американцы кредитовали большинство стран антигитлеровской коалиции, снабжали их оружием, продовольствием и амуницией. Разумеется, не за просто так.
А фактически -- за просто так. Потому что тот же лендлиз предполагал возврат лишь неуничтоженной техники, но её так и не вернули. Кредиты по лендлизу СССР так никогда до конца и не выплатил, США в конце концов просто простил остаток долга (75%). Процентов по долгу не начислялось.
США с самого начала программы предполагали, что почти ничего не будет возвращено, а что будет -- будет бесполезным в мирное время хламом, поэтому в договор заложили "совместные усилия по созданию либерализованного международного экономического порядка", т.е. режима свободной мировой торговли, который бы позволил всем участникам быстрее восстановиться. Вот только СССР не захотел ни совместных усилий, ни либерализации торговли -- идеология не позполяла, ибо капитализьм был "харам". Вместо этого он предпочёл всё тырить.
Это обязательное условие для выполнения иммутабильности.
Нет, не обязательное. Просто, читая "Объект не может быть изменён. Если нужно новое состояние, создаётся новый объект, исходный остаётся неизменным", вы упёрлись в единственную трактовку, что "не может" означает якобы техническую невозможность ("должно быть невозможно поменять"), и не допускаете, что это может быть нормативным требованием "не надо менять".
Structural sharing не меняет старый объект, и он создаёт новый объект на основе старого. Если вы сами злонамеренно не меняете старый объект, то все условия иммутабельности выполнены.
Глубокое клонирование точно так же никак не защищает старый объект от злонамеренного изменения, какой-нибудь уникум всегда может написать:
-- и всё, приехали. Тогда каким образом structuralClone является "настоящей иммутабельностью", по-вашему?
Иммутабельность -- это в первую очередь дисциплина, принцип, паттерн. Если есть дополнительные safeguards через средства языка (вроде Object.freeze или opt-in mutability как в Расте) или через библиотеки типа ImmutableJS -- отлично, но если нет, то вы всё равно можете использовать её, просто избегая прямых мутаций состояния.
Про tradeoff "производительность vs фишки"я в четвёртый раз одно и то же писать не буду, если с трёх раз не дошло, то я пас.
Как бы да, копирование ПОЛНОЕ) Иначе вы иммутабильность путаете с мутабильностью. Если копирование не полное, то вы НАРУШАЕТЕ иммутабильность, они больше иммутабильностью не является.
Похоже, у вас понятие "полное" какое-то совершенно отличное от моего. Для меня полное копирование -- это глубокое клонирование, т.е. создание полного клона объекта, с клонированием всех полей, включая детей, и внуков, правнуков и т.д.
Structural sharing не клонирует всех детей до последнего колена -- те объекты, что не поменялись, остаются на месте, их никто не удаляет, они шарятся между обоими копиями стейта (и при хорошем дизайне это бОльшая часть стейта). Никакого нарушения иммутабельности при этом нет, хотя клонирование тут частичное (в том смысле, что не для всех данных производятся дубликаты).
Чушь несете вы, не понимая принципов работы процессора, материнской платы и оперативной памяти.
Умерьте пыл, телепат вы наш, есть немалый шанс, что принципы процессора и проч я изучил, когда вы ещё под стол пешком ходили.
И уж тем более не понимаете принципе иммутабильнсти.
Судя по тому, что вы называете structuredClone "настоящей иммутабельностью", принципов не понимаете вы. Я даже не знаю откуда вы эту чушь берёте, клонирование и иммутабельность -- это концептуально разные вещи, хоть и идут рука об руку рядом. Может быть клонирование без иммутабельности, может быть иммутабельность без клонирования (любая константа вам скажет)
Вот вам, бенчмарк
Если у вас весь стейт -- это один огромный плоский массив/мапа на тысячи элементов, то да, будут проблемы с производительностью, потому что основными затратами будет перекладывание одних и тех же ссылок. Да, такие структуры плохо подходят для immutability, если стейт надо часто менять, кто бы спорил. И никто не спорит, что лазить в структуры напрямую и "пачкать" данные "по-живому" эффективнее с т.з. скорости. Ну так горе-админы тоже считают, что лазить на прод и что-то там менять напрямую -- это быстрее и эффективнее. До первого падения прода и люлей.
Иммутабельность имеет свою цену -- я это могу вам повторить ещё раз, если первые два раза не поняли. Точно так же, как запрет лазить на прод руками имеет свою цену. Вопрос в том, готовы ли вы платить эту цену за отсутствие головняка с гонками данных, неконсистентностью, откатами и прочими ништяками.
Если у вас стейт -- не огромный плоский массив, а более-менее глубокое дерево, то выигрыш прямый изменений уже становится не такой уж значительный:
Что именно вы разоблачили? На ваши комменты c разоблачениями были ответы, простое повторение тех же комментов не является разоблачением, заявы "Ппц, на полном серьезе такую брехню нести" ими тоже не являются -- я тоже умею такие заявы кидать.
Я вижу вы ярый апологет MobX. Я ничего против MobX не имею, я спорю только с вашим аргументом, что иммутабельность -- супердорогая штука, которая якобы приводит к ПОЛНОМУ копированию всего состояния на каждый чих. Это просто чушь, выкурите structural sharing уже.
Ну и, к слову о розовых очках и реальности: тот же MobX под капотом приводит к аллокациям и диффам на каждый пересчёт каждого derivation, с целью отслеживания [новых] зависимостей, с дедупликацией оных. "С каких это пор постоянный копирование объектов трекинг зависимостей на каждый чих это оптимизация?" (с) алаверды
Т.е. проблема аллокаций просто перемещается на другой уровень. То, что в вашем коде их нет, не значит, что их нет вообще. "А может ещё это бесплатно и память не кушает?)))" (с) алаверды-2
https://mol.hyoo.ru/ -- английской документации, как я понимаю, нет -- индикатор языка слева внизу показывает "English", но вся документация, кроме меню -- на русском. Переключение языка переключает только язык навигации. Ну да ладно, в гитхабе доки есть, это не глюк, а ограничение целевой аудитории.
https://page.hyoo.ru/#!=6leyma_5ks814 -- примеры втиснуты в милипиздрические фреймы, на экране лаптопа превращающиеся в горизонтально-скроллируемые бронещели танка; зато куча экранной ширины щедро отдана под бесполезную и неубираемую/неизменяемую панель закладок и боковые поля
При всём этом аттракционе щедрости, весьма полезный вертикальный скроллбар тоже миллипиздрический, словно от сердца оторванный. И если зажать ползунок и потащить его мышкой, то мышка отрывается от ползунка, и тот скроллится со своей скоростью. Да, я помню ваш аргумент, что это ограничение виртуального скроллинга, где размеры элементов заранее не известны и параметры скроллера вычисляется динамически -- вот только то же самое случается на коротких статических страницах где виртуальный скроллинг не нужен, и нет динамически подгружаемого контента. Но у вас он впихнут везде, как я понимаю. Поэтому выходит, что скроллер прыгает даже на жалких 2-3-х экранах статического текста: https://page.hyoo.ru/#!=3498sy_ioyx6t . Можно очень много, долго и убедительно рассказывать про борьбу за производительность, но видя такое хочется закрыть вкладку и забыть немедленно, потому что возникает впечатление, эта это борьба ради борьбы (впрочем, это почти про все фреймворки можно сказать).
Даже если проблему пересчёта не обойти, почему бы не сделать изменение размера скроллера более незаметным, через плавное изменение высоты, например?
Это только то, что бросилось в глаза за первые 5 минут чтения.
Этот прокси а) опциональный "сахар", б) создаётся на стороне писателя (которых мало), в) создаётся на короткое время, пока правится "черновик" изменений, а не висит постоянно в сторе (движок может оптимизировать это через escape anaysis и аллокации на стеке или в nursery).
После создания объекта с измениями он (объект) остаётся простым иммутабельным POJO до самого уничтожения.
учить новый непопулярный синтаксис с жёсткими правилами на форматирование и невидимые символы (табы, переносы строк и проч),
тащить в проект кодогенерацию (бррр),
тащить в проект непопулярный билдер с неясными проблемами совместимости с либами,
и проч
-- т.е. повышаете уровень входа до уровня ангуляра. Это значит, что мелкие проекты не возьмут ваш фреймворк практически никогда -- слишком много возни. А крупные проекты не возьмут ваш фреймворк вообще никогда -- из-за рисков, глючной документации с плохим/отсутствующим/нерабочим английским, attitude issues и т.п.
Но вы продолжайте считать несогласных говноедами, а ваш фрейморк самым правильным, это так успокаивает.
Класс, рекурсивный обход 2х объектов и сравнение полей)
Или Immer, например.
Но, вообще говоря, писатель обычно не просто так меняет данные, и вероятность, что он постоянно меняет данные на точно такие же, мала.
У MobX есть такая штука
Я, вообще-то, спрашивал про голые JS проперти, без того чтобы вместо POJO втаскивать прокси на каждый объект в сторе и на его собаку, развесистый реактивный граф коллбэков (и системой, поощряющей делать его как можно развесистей), c потенциалом налететь на утечки, циклические зависимости и бесконечный цикл, N+1, чувствительность к порядку апдейтов, который мы не выбираем явно. Проблем, конечно, можно избежать -- но вы же требуете полной беззаботности со стороны девов, а сами её предложить не можете.
А ещё боремся за почетное звание «Дома высокой культуры и быта!» (с)
Правда в том, что борясь за одно, приходится жертвовать другим.
вы путаетесь в показаниях и включаете заднюю
Или у вас есть фантазия, что вы будто бы прокурор, а я будто бы даю вам какие-то показания.
Я с первого коммента сказал, что иммутабельность -- не панацея, и что для получения гарантий нужна дисциплина со стороны писателя. Вы же, судя по вашей бурной реакции, почему-то предположили, что я топлю за иммутабельность как за серебрянную пулю и отчаянно бьюсь с вами.
Представляете, есть люди, которые занимаются разными вещами в разное время, и как-то время им чем-то приходится не пользоваться. Поэтому скорость забывания значение имеет.
Зачем натягивать палеоиндюка на глобус и придумывать ВНЕЗАПНЫЕ! (tm) бури и обвалы, когда есть более банальные причины: один схватил другого за конечность и начал методично наносить травмы, несовместимые с жизнью, другой, защищаясь, вспорол первому брюхо, у обоих обильное кровоизлияние и критическая потеря крови, "в общем, все умерли" (с).
Если все станочники города месяц работали и месяц бухали, создавая дефицит станочников и поднимая ставки, то их едино-месячные выплаты нужно делить пополам, чтобы получить эффективную средне-месячную зарплату. Ведь если бы они не бухали, то не было бы дефицита, и не было бы таких ставок.
Но очень удобно не гибли? Или, если гибли не от рук немцев, то нещитово?
Вы всерьёз считаете что кроме немцев во ВМВ не с кем было рубится, и Европа была единственным театром боевых действий?
Это обычно из-за агрегации: частицы летают, сталкиваются между собой, объединяются в более крупные и начинают выпадать, переставая быть аэрозолями. Либо прилипают к поверхностям при контакте.
Как сказать, что не знаешь истории, не говоря, что не знаешь истории.
А с японцами тогда кто бы воевал? Что-то СССР не торопился открывать второй фронт на востоке. /s
Таких, что броуновское движение в данных условиях (плотность, температура) перестаёт быть пренебрежимо малым, поэтому взвесь никогда не выпадает в осадок.
Вы слово "фактически" пропустили? На бумаге была небесплатная, в мозгах патриотов СССР -- вообще обдираловка. По факту же вернули 25% -- причём без учёта того, что было уничтожено в боях и списано (это было 100% бесплатно).
Угу, по принципу "мы на горе всем буржуям мировой пожар раздуем".
А фактически -- за просто так. Потому что тот же лендлиз предполагал возврат лишь неуничтоженной техники, но её так и не вернули. Кредиты по лендлизу СССР так никогда до конца и не выплатил, США в конце концов просто простил остаток долга (75%). Процентов по долгу не начислялось.
США с самого начала программы предполагали, что почти ничего не будет возвращено, а что будет -- будет бесполезным в мирное время хламом, поэтому в договор заложили "совместные усилия по созданию либерализованного международного экономического порядка", т.е. режима свободной мировой торговли, который бы позволил всем участникам быстрее восстановиться. Вот только СССР не захотел ни совместных усилий, ни либерализации торговли -- идеология не позполяла, ибо капитализьм был "харам". Вместо этого он предпочёл всё тырить.
В общем, жить можно вроде.
Нет, не обязательное. Просто, читая "Объект не может быть изменён. Если нужно новое состояние, создаётся новый объект, исходный остаётся неизменным", вы упёрлись в единственную трактовку, что "не может" означает якобы техническую невозможность ("должно быть невозможно поменять"), и не допускаете, что это может быть нормативным требованием "не надо менять".
Structural sharing не меняет старый объект, и он создаёт новый объект на основе старого. Если вы сами злонамеренно не меняете старый объект, то все условия иммутабельности выполнены.
Глубокое клонирование точно так же никак не защищает старый объект от злонамеренного изменения, какой-нибудь уникум всегда может написать:
-- и всё, приехали. Тогда каким образом
structuralCloneявляется "настоящей иммутабельностью", по-вашему?Иммутабельность -- это в первую очередь дисциплина, принцип, паттерн. Если есть дополнительные safeguards через средства языка (вроде
Object.freezeили opt-in mutability как в Расте) или через библиотеки типаImmutableJS-- отлично, но если нет, то вы всё равно можете использовать её, просто избегая прямых мутаций состояния.Про tradeoff "производительность vs фишки"я в четвёртый раз одно и то же писать не буду, если с трёх раз не дошло, то я пас.
Похоже, у вас понятие "полное" какое-то совершенно отличное от моего. Для меня полное копирование -- это глубокое клонирование, т.е. создание полного клона объекта, с клонированием всех полей, включая детей, и внуков, правнуков и т.д.
Structural sharing не клонирует всех детей до последнего колена -- те объекты, что не поменялись, остаются на месте, их никто не удаляет, они шарятся между обоими копиями стейта (и при хорошем дизайне это бОльшая часть стейта). Никакого нарушения иммутабельности при этом нет, хотя клонирование тут частичное (в том смысле, что не для всех данных производятся дубликаты).
Умерьте пыл, телепат вы наш, есть немалый шанс, что принципы процессора и проч я изучил, когда вы ещё под стол пешком ходили.
Судя по тому, что вы называете
structuredClone"настоящей иммутабельностью", принципов не понимаете вы. Я даже не знаю откуда вы эту чушь берёте, клонирование и иммутабельность -- это концептуально разные вещи, хоть и идут рука об руку рядом. Может быть клонирование без иммутабельности, может быть иммутабельность без клонирования (любая константа вам скажет)Если у вас весь стейт -- это один огромный плоский массив/мапа на тысячи элементов, то да, будут проблемы с производительностью, потому что основными затратами будет перекладывание одних и тех же ссылок. Да, такие структуры плохо подходят для immutability, если стейт надо часто менять, кто бы спорил. И никто не спорит, что лазить в структуры напрямую и "пачкать" данные "по-живому" эффективнее с т.з. скорости. Ну так горе-админы тоже считают, что лазить на прод и что-то там менять напрямую -- это быстрее и эффективнее. До первого падения прода и люлей.
Иммутабельность имеет свою цену -- я это могу вам повторить ещё раз, если первые два раза не поняли. Точно так же, как запрет лазить на прод руками имеет свою цену. Вопрос в том, готовы ли вы платить эту цену за отсутствие головняка с гонками данных, неконсистентностью, откатами и прочими ништяками.
Если у вас стейт -- не огромный плоский массив, а более-менее глубокое дерево, то выигрыш прямый изменений уже становится не такой уж значительный:
https://stackblitz.com/edit/stackblitz-starters-c2hsjkty?file=src%2Findex.tsx
Особенно если программист не идиот и не складывает быстро-меняющиеся данные в общий стейт.
Что именно вы разоблачили? На ваши комменты c разоблачениями были ответы, простое повторение тех же комментов не является разоблачением, заявы "Ппц, на полном серьезе такую брехню нести" ими тоже не являются -- я тоже умею такие заявы кидать.
Я вижу вы ярый апологет MobX. Я ничего против MobX не имею, я спорю только с вашим аргументом, что иммутабельность -- супердорогая штука, которая якобы приводит к ПОЛНОМУ копированию всего состояния на каждый чих. Это просто чушь, выкурите structural sharing уже.
Ну и, к слову о розовых очках и реальности: тот же MobX под капотом приводит к аллокациям и диффам на каждый пересчёт каждого derivation, с целью отслеживания [новых] зависимостей, с дедупликацией оных. "С каких это пор постоянный
копирование объектовтрекинг зависимостей на каждый чих это оптимизация?" (с) алавердыТ.е. проблема аллокаций просто перемещается на другой уровень. То, что в вашем коде их нет, не значит, что их нет вообще. "А может ещё это бесплатно и память не кушает?)))" (с) алаверды-2
Возвращайтесь, я не против.
Конкретных разоблачений "брехни", конечно же, не дождёмся.
https://mol.hyoo.ru/ -- английской документации, как я понимаю, нет -- индикатор языка слева внизу показывает "English", но вся документация, кроме меню -- на русском. Переключение языка переключает только язык навигации. Ну да ладно, в гитхабе доки есть, это не глюк, а ограничение целевой аудитории.
https://page.hyoo.ru/#!=6leyma_5ks814 -- примеры втиснуты в милипиздрические фреймы, на экране лаптопа превращающиеся в горизонтально-скроллируемые бронещели танка; зато куча экранной ширины щедро отдана под бесполезную и неубираемую/неизменяемую панель закладок и боковые поля
При всём этом аттракционе щедрости, весьма полезный вертикальный скроллбар тоже миллипиздрический, словно от сердца оторванный. И если зажать ползунок и потащить его мышкой, то мышка отрывается от ползунка, и тот скроллится со своей скоростью. Да, я помню ваш аргумент, что это ограничение виртуального скроллинга, где размеры элементов заранее не известны и параметры скроллера вычисляется динамически -- вот только то же самое случается на коротких статических страницах где виртуальный скроллинг не нужен, и нет динамически подгружаемого контента. Но у вас он впихнут везде, как я понимаю. Поэтому выходит, что скроллер прыгает даже на жалких 2-3-х экранах статического текста: https://page.hyoo.ru/#!=3498sy_ioyx6t . Можно очень много, долго и убедительно рассказывать про борьбу за производительность, но видя такое хочется закрыть вкладку и забыть немедленно, потому что возникает впечатление, эта это борьба ради борьбы (впрочем, это почти про все фреймворки можно сказать).
Даже если проблему пересчёта не обойти, почему бы не сделать изменение размера скроллера более незаметным, через плавное изменение высоты, например?
Это только то, что бросилось в глаза за первые 5 минут чтения.
Этот прокси а) опциональный "сахар", б) создаётся на стороне писателя (которых мало), в) создаётся на короткое время, пока правится "черновик" изменений, а не висит постоянно в сторе (движок может оптимизировать это через escape anaysis и аллокации на стеке или в nursery).
После создания объекта с измениями он (объект) остаётся простым иммутабельным POJO до самого уничтожения.
Вы уже предлагаете
учить новый непопулярный синтаксис с жёсткими правилами на форматирование и невидимые символы (табы, переносы строк и проч),
тащить в проект кодогенерацию (бррр),
тащить в проект непопулярный билдер с неясными проблемами совместимости с либами,
и проч
-- т.е. повышаете уровень входа до уровня ангуляра. Это значит, что мелкие проекты не возьмут ваш фреймворк практически никогда -- слишком много возни. А крупные проекты не возьмут ваш фреймворк вообще никогда -- из-за рисков, глючной документации с плохим/отсутствующим/нерабочим английским, attitude issues и т.п.
Но вы продолжайте считать несогласных говноедами, а ваш фрейморк самым правильным, это так успокаивает.
Или Immer, например.
Но, вообще говоря, писатель обычно не просто так меняет данные, и вероятность, что он постоянно меняет данные на точно такие же, мала.
Я, вообще-то, спрашивал про голые JS проперти, без того чтобы вместо POJO втаскивать прокси на каждый объект в сторе и на его собаку, развесистый реактивный граф коллбэков (и системой, поощряющей делать его как можно развесистей), c потенциалом налететь на утечки, циклические зависимости и бесконечный цикл, N+1, чувствительность к порядку апдейтов, который мы не выбираем явно. Проблем, конечно, можно избежать -- но вы же требуете полной беззаботности со стороны девов, а сами её предложить не можете.
А ещё боремся за почетное звание «Дома высокой культуры и быта!» (с)
Правда в том, что борясь за одно, приходится жертвовать другим.
Или у вас есть фантазия, что вы будто бы прокурор, а я будто бы даю вам какие-то показания.
Я с первого коммента сказал, что иммутабельность -- не панацея, и что для получения гарантий нужна дисциплина со стороны писателя. Вы же, судя по вашей бурной реакции, почему-то предположили, что я топлю за иммутабельность как за серебрянную пулю и отчаянно бьюсь с вами.
Представляете, есть люди, которые занимаются разными вещами в разное время, и как-то время им чем-то приходится не пользоваться. Поэтому скорость забывания значение имеет.