Признаться, после чтения статей про атомы и проч я был заинтригован, и тайпскриптная часть была интересной. Поэтому я потратил некоторое время на изучение документации. Оно вроде как и не сильно сложно, но нет, мне не показалось очень мнемоничным. Т.е. когда читаешь доку, вроде понятна идея. Но, вернувшись через некоторое время, я понял, что практически ничего не запомнилось, и трудно по памяти восстановить, какая именно идея стояла за определённым синтаксисом. Т.е. ход "идея --> синтаксис" работает, а обратный ход "синтаксис --> идея" -- не очень.
У меня не сильно хорошая память, я, например, и вимом не пользуюсь поэтому -- слишком много клавиатурных жестов запоминать, потом мучительно вспоминать после пауз. Вдобавок, я фронтендом занимаюсь лишь эпизодически, поэтому паузы длинные. Так что я решил, что это не моя чашка чая. И, подозреваю, так решили многие (если не все).
ЗЫ. Я так же не люблю snake_case и yaml, и с большой неохотой пользуюсь всякими декораторами, атрибутами и проч, так как они создают паралельный язык, которым легко злоупотреблять (привет, ангуляр), получить проблемы с рефакторингом и проч. Но это личные загоны.
Это ответственность того, кто меняет данные. Обычно писателей мало, читателей много, поэтому забота о том, чтобы не создавать ложных псевдо-изменений ложится на писателей. Да, нужна определённая дисциплина -- либо библиотека, берущая это на себя.
есть такие штуки getters/setters ... Было изменение, вызывает реакции
Сделайте с сеттерами пачку из 100 изменений, вызвав эффект лишь один раз по окончании пачки. Например, в массиве 100 объектов нужно выставить у каждого "active = false" и не триггернуть 100 последовательных перерисовок. И, при этом желательно не делать 100 подписок на событие "onActiveChanged".
Да вы что, прям яваскрипт знает какая часть неизменной будет, а какая нет?)))
Тот, кто меняет -- знает, и должен соблюдать правило: "нет реальных изменений -- ничего не меняй"
Каждая манипуляция стоит времени, места и энергии.
Именно поэтому нужно избегать манипуляций, когда они не нужны. А не нужны они там, где ничего не поменялось. А чтобы в сложном композитном объекте эффективно определить, где именно ничего не поменялось, нужна иммутабельность, при которой проверка сводится к сравнению пары указателей, а не к обходу всего дерева состояний в поисках изменений.
У вас в эмбеде наверное нету развесистых деревьев состояний и их презентаций, как в пользовательском UI, вот вам и не нужно это всё. Вы с другой колокольни смотрите.
Оно читаемое -- сразу после момента когда прочитал документацию. Но через некоторое время, после работы с другими вещами, которые занимали мозг, большая часть знаний это птичьего языка улетучивается, и без заглядывания в доки опять ничего не понятно.
ПДД — гарантирует безопасное передвижение по дорогам общего пользования, в случае когда пользователи этих самых дорог САМИ же их и исполняют!
LOL ещё 3 раза. Я ещё помню времена, когда в ПДД до недавнего времени не было даже определённости, что называть "обгоном", и до сих пор имеются неоднозначные формулировки, которые можно интерпретировать по-разному. И это только ПДД РФ, в то время как в мире имеются ПДД других стран.
Плюс имеются best practices, не прописанные в ПДД, и даже есть рекомендации плохих практик (например, рекомендация перестраиваться заранее перед сужением вместо "zip merge", что приводит к растягиванию пробок).
У меня цель— прогрессивное развитие нашей Цивилизации.
Поздравляю, вы один такой белый рыцарь, все остальные -- жадные ублюдки, после которых хоть потоп. /s
Что конкретного Вы уже сделали для достижения этой цели, кроме уговаривания других?
Я предлагаю— хорошенчеко сесть т подумать над всем комплексом.
Ваш снисходительный совет специалистам "хорошенечко сесть, подумать и написать директивы" является настолько же бесполезным, насколько бесплатным. Проблема не в отсутствии статей и рекоменаций -- их написано тонны. Проблема в том, что панацей, серебрянных пуль и универсальных парадигм с гарантией успеха, не существует, как бы вам не хотелось.
самолетная отрасль полетов — полностью зарегулирована.
Иммутабельность даёт гарантии, что объект, который ты получил, не взорвётся у тебя в руках останется тем же всегда, и тебе не надо кропотливо и пристально следить, не поменялось ли что-то в его нутрях, или втыкать и таскать повсюду кучу флагов isModified, или перерисовывать весь UI на каждый чих.
Иммутабельность предоставляет простой способ детектирования наличия изменений: если ссылка на объект не поменялась, значит 100% изменений в нём нет, можно пропустить всю работу по проверке и обновлению данных и UI.
Полного копирования при изменениях не происходит -- для неизменённых частей копируются только ссылки верхнего уровня.
Как у любого решения, у этого есть своя цена, каждый сам должен решать, что выгоднее в его конкретном случае.
С каких пор полное копирование участка памяти(объекта) с целью его изменения
При правильном подходе новый объект создаётся не полным копированием всех данных, а путём копирования ссылок на неизменённые данные, плюс новые примитивы/ссылки в местах изменений. Т.е. копирование происходит только для части ссылок и части примитивов, но это достаточно дёшево, так как для них есть быстрые кучи/арены. Когда вы меняете строку "по месту", у вас точно так же есть шанс получить либо перераспределение памяти, либо её недоиспользование, поэтому строки в современных managed языках сплошь immutable, ибо так на круг выходит дешевле.
И как появились ПДД, все их выучили наизусть, и все нарушения немедленно кончились и воцарилось благоденствие?
удачи дальше спорить чей стек лучше.
Как будто в "Комитете по доктринам" споров не будет, ага. И с решениями Комитета все будут единогласно согласны, конечно же.
Я вам своми вопросом "в никуда" как бы намекнул, что у вас в голове какая-то детская вера в мудрость Больших Дядь в Комитетах и в магию Незыблемых Директив. Та же благословенная OSI, с которой вы носитесь, нарушается только пыль стоит.
В реальном мире (а не в воображаемом вами) вначале само сообщество разработчиков набивает шишки на реальных задачах (что означает баги!), потом публикует статьи по этим набитым шишкам и по лучшим практикам того, как избегать их набивания. Потом приходят новые люди, которое либо грамотны, но остались неудовлетворены существующими решениями, либо тупо ничего из всего этого написанного этого не читала, но имеет мнение -- и начинает изобретать свои велосипеды, набивая новые шишки.
Вы не предлагаете никаких инженерных решений, решающих реальные проблемы. Вы предлагаете административное ограничение -- обязать всех писать только по директиве. Это никогда не работало, и работать не будет. В списке ["физические ограничения", "технические ограничения", "административные ограничения"], административные -- самые слабые, ибо легко нарушаются/обходятся. Они же -- самые заманчивые для тех, кто не умеет в технические.
У меня как-то не связывается собственно тушение с передотвращением дальнейшего распространения и ожиданием, пока уже загоревшееся не выгорит.
Между тем это основная тактика тушения трудных пожаров, особенно при дефиците воды. Cкажем, при сильном возгорании деревянного дома (в который рискованно входить) эффективнее дать ему сгореть дотла, не давая загореться соседним -- причём это выгоднее даже пострадавшему, так как дом всё равно под снос и расчистку площадки под новый, а убрать пепел вместо вывоза кучи полуобгорелого мусора обойдётся намного дешевле. То же с горением батарей -- проще дать ей выгореть и не дать загореться остальному, чем тушить. Но если нужно тушить, то именно заливая большим количеством воды, не боясь сказок про литий или разряд через воду.
тащить тысячи тонн груза, используя не больше 20% массы под топливо
Для грузов это как раз не трудно, если грузы не скоропортящиеся -- есть ионники, есть очень экономичные орбиты, темп и непрерывность поставок достигается тем, что в пути находится сразу множество кораблей с разными временами прибытия. Это лишь человеческие тушки нужно доставлять быстро -- но ведь можно и не доставлять, а сразу по месту производить.
Справедливости ради, Старшип не делал тормозного импульса, тормозил он об атмосферу. Он наоборот делал второй разгонный, который поднял перигей до 50 км. Но там явно ничего, кроме задач миссии, не мешало сделать второй импульс чуть длиннее и поднять перигей выше 100 км.
В смысле "надо всё сделать без металлов"? Металлы с планеты куда-то исчезли?
Металлы в океане есть. Их труднее извлечь, чем кинув кусок руды в огонь, но даже ваши кровепродуцирующие клетки умеют эфффективно и селективно извлекать атомарное железо, чтобы строить гемоглобин, безо всякого огня, чисто на "нанотехнологиях" то бишь на белковых "машинах", и делают это в "промышленных масштабах". В биологии и геологи вообще происходит много всякой интересной и сложной химии, не требующей "всякого", хотя требующей "всякого другого".
Есть разные вещи, про которые я читал, но не пробовал (всего не перепробуешь), но степень их забывания почему-то разная.
Признаться, после чтения статей про атомы и проч я был заинтригован, и тайпскриптная часть была интересной. Поэтому я потратил некоторое время на изучение документации. Оно вроде как и не сильно сложно, но нет, мне не показалось очень мнемоничным. Т.е. когда читаешь доку, вроде понятна идея. Но, вернувшись через некоторое время, я понял, что практически ничего не запомнилось, и трудно по памяти восстановить, какая именно идея стояла за определённым синтаксисом. Т.е. ход "идея --> синтаксис" работает, а обратный ход "синтаксис --> идея" -- не очень.
У меня не сильно хорошая память, я, например, и вимом не пользуюсь поэтому -- слишком много клавиатурных жестов запоминать, потом мучительно вспоминать после пауз. Вдобавок, я фронтендом занимаюсь лишь эпизодически, поэтому паузы длинные. Так что я решил, что это не моя чашка чая. И, подозреваю, так решили многие (если не все).
ЗЫ. Я так же не люблю snake_case и yaml, и с большой неохотой пользуюсь всякими декораторами, атрибутами и проч, так как они создают паралельный язык, которым легко злоупотреблять (привет, ангуляр), получить проблемы с рефакторингом и проч. Но это личные загоны.
Это ответственность того, кто меняет данные. Обычно писателей мало, читателей много, поэтому забота о том, чтобы не создавать ложных псевдо-изменений ложится на писателей. Да, нужна определённая дисциплина -- либо библиотека, берущая это на себя.
Сделайте с сеттерами пачку из 100 изменений, вызвав эффект лишь один раз по окончании пачки. Например, в массиве 100 объектов нужно выставить у каждого "active = false" и не триггернуть 100 последовательных перерисовок. И, при этом желательно не делать 100 подписок на событие "onActiveChanged".
Тот, кто меняет -- знает, и должен соблюдать правило: "нет реальных изменений -- ничего не меняй"
Именно поэтому нужно избегать манипуляций, когда они не нужны. А не нужны они там, где ничего не поменялось. А чтобы в сложном композитном объекте эффективно определить, где именно ничего не поменялось, нужна иммутабельность, при которой проверка сводится к сравнению пары указателей, а не к обходу всего дерева состояний в поисках изменений.
У вас в эмбеде наверное нету развесистых деревьев состояний и их презентаций, как в пользовательском UI, вот вам и не нужно это всё. Вы с другой колокольни смотрите.
Оно читаемое -- сразу после момента когда прочитал документацию. Но через некоторое время, после работы с другими вещами, которые занимали мозг, большая часть знаний это птичьего языка улетучивается, и без заглядывания в доки опять ничего не понятно.
Да прямо завтра и начну. В самом-то деле, 35 лет код пишу, куда уже дальше откладывать?
Если хз, то подскажу более подходящий термин. и, соответственно, название склонности.
Take care.
LOL ещё 3 раза. Я ещё помню времена, когда в ПДД до недавнего времени не было даже определённости, что называть "обгоном", и до сих пор имеются неоднозначные формулировки, которые можно интерпретировать по-разному. И это только ПДД РФ, в то время как в мире имеются ПДД других стран.
Плюс имеются best practices, не прописанные в ПДД, и даже есть рекомендации плохих практик (например, рекомендация перестраиваться заранее перед сужением вместо "zip merge", что приводит к растягиванию пробок).
Поздравляю, вы один такой белый рыцарь, все остальные -- жадные ублюдки, после которых хоть потоп. /s
Что конкретного Вы уже сделали для достижения этой цели, кроме уговаривания других?
Ваш снисходительный совет специалистам "хорошенечко сесть, подумать и написать директивы" является настолько же бесполезным, насколько бесплатным. Проблема не в отсутствии статей и рекоменаций -- их написано тонны. Проблема в том, что панацей, серебрянных пуль и универсальных парадигм с гарантией успеха, не существует, как бы вам не хотелось.
Вы ошибаетесь насчёт "полностью".
Иммутабельность даёт гарантии, что объект, который ты получил, не
взорвётся у тебя в рукахостанется тем же всегда, и тебе не надо кропотливо и пристально следить, не поменялось ли что-то в его нутрях, или втыкать и таскать повсюду кучу флаговisModified, или перерисовывать весь UI на каждый чих.Иммутабельность предоставляет простой способ детектирования наличия изменений: если ссылка на объект не поменялась, значит 100% изменений в нём нет, можно пропустить всю работу по проверке и обновлению данных и UI.
Полного копирования при изменениях не происходит -- для неизменённых частей копируются только ссылки верхнего уровня.
Как у любого решения, у этого есть своя цена, каждый сам должен решать, что выгоднее в его конкретном случае.
При правильном подходе новый объект создаётся не полным копированием всех данных, а путём копирования ссылок на неизменённые данные, плюс новые примитивы/ссылки в местах изменений. Т.е. копирование происходит только для части ссылок и части примитивов, но это достаточно дёшево, так как для них есть быстрые кучи/арены. Когда вы меняете строку "по месту", у вас точно так же есть шанс получить либо перераспределение памяти, либо её недоиспользование, поэтому строки в современных managed языках сплошь immutable, ибо так на круг выходит дешевле.
И как появились ПДД, все их выучили наизусть, и все нарушения немедленно кончились и воцарилось благоденствие?
Как будто в "Комитете по доктринам" споров не будет, ага. И с решениями Комитета все будут единогласно согласны, конечно же.
Я вам своми вопросом "в никуда" как бы намекнул, что у вас в голове какая-то детская вера в мудрость Больших Дядь в Комитетах и в магию Незыблемых Директив. Та же благословенная OSI, с которой вы носитесь, нарушается только пыль стоит.
В реальном мире (а не в воображаемом вами) вначале само сообщество разработчиков набивает шишки на реальных задачах (что означает баги!), потом публикует статьи по этим набитым шишкам и по лучшим практикам того, как избегать их набивания. Потом приходят новые люди, которое либо грамотны, но остались неудовлетворены существующими решениями, либо тупо ничего из всего этого написанного этого не читала, но имеет мнение -- и начинает изобретать свои велосипеды, набивая новые шишки.
Вы не предлагаете никаких инженерных решений, решающих реальные проблемы. Вы предлагаете административное ограничение -- обязать всех писать только по директиве. Это никогда не работало, и работать не будет. В списке ["физические ограничения", "технические ограничения", "административные ограничения"], административные -- самые слабые, ибо легко нарушаются/обходятся. Они же -- самые заманчивые для тех, кто не умеет в технические.
Начинают?! LOL. Они начали когда вас ещё в проекте не было.
Просто люди не учат историю. И история не учит людей, ибо всякая старая глупость предстаёт перед ними в новом свете.
Откуда вы берётесь такие, любители доктрин?
В дополнение к сотворению календаря -- сотворение часов:
Где там HATEOAS?
Между тем это основная тактика тушения трудных пожаров, особенно при дефиците воды. Cкажем, при сильном возгорании деревянного дома (в который рискованно входить) эффективнее дать ему сгореть дотла, не давая загореться соседним -- причём это выгоднее даже пострадавшему, так как дом всё равно под снос и расчистку площадки под новый, а убрать пепел вместо вывоза кучи полуобгорелого мусора обойдётся намного дешевле. То же с горением батарей -- проще дать ей выгореть и не дать загореться остальному, чем тушить. Но если нужно тушить, то именно заливая большим количеством воды, не боясь сказок про литий или разряд через воду.
Для грузов это как раз не трудно, если грузы не скоропортящиеся -- есть ионники, есть очень экономичные орбиты, темп и непрерывность поставок достигается тем, что в пути находится сразу множество кораблей с разными временами прибытия. Это лишь человеческие тушки нужно доставлять быстро -- но ведь можно и не доставлять, а сразу по месту производить.
Справедливости ради, Старшип не делал тормозного импульса, тормозил он об атмосферу. Он наоборот делал второй разгонный, который поднял перигей до 50 км. Но там явно ничего, кроме задач миссии, не мешало сделать второй импульс чуть длиннее и поднять перигей выше 100 км.
Эдак нельзя говорить и о превосходстве полёта Гагарина, так как он на замкнутую орбиту не выходил, лишь неполный виток сделал.
1940 год -- никакого звоночка не звенит?
В смысле "надо всё сделать без металлов"? Металлы с планеты куда-то исчезли?
Металлы в океане есть. Их труднее извлечь, чем кинув кусок руды в огонь, но даже ваши кровепродуцирующие клетки умеют эфффективно и селективно извлекать атомарное железо, чтобы строить гемоглобин, безо всякого огня, чисто на "нанотехнологиях" то бишь на белковых "машинах", и делают это в "промышленных масштабах". В биологии и геологи вообще происходит много всякой интересной и сложной химии, не требующей "всякого", хотя требующей "всякого другого".