Better safe than sorry или О иммутабельности
Сегодня с утра устроили с
artureg срачь на тему "почему мутабельные структуры данных это плохо".
Вообще все началось с того что он пишет некую хитрую штуку на кложури, но при этом использует ее не в идиоматическом стиле, в то с мысле, что вместо кошерных иммутабельных структур использует 100500 ref которые ссылаются на структуры внутри которых еще ref и в итоге у него это все автоматически не сериализуется в json. То есть закат солнца вручную и изготовление из кложури перла и цэ-с-крестиками и поселение там ядовитых жаб и пауков. И все это внутри Software Transactional Memory, т.е. (dosync ...)
Два дня на пару с
theiced пытались ему объяснить почему ему не нужно столько ref, особенно вложенных, и как кошерно пользоваться иммутабельными структурами данных. Но артурег отнекивается, не желая менять парадигму.
Впрочем, ему там и структуры такой сложности не нужны, посколько достаточно хранить обновления для этих структур в виде списка, а текущее состояние интегрировать исходя из них.
Аналогичным образом я спорил с канадскими линуксоидами, которые обвиняли меня в том, что я, используя статически типизированные языки и иммутабельные структуры данных, возвожу защитное программирование до уровня паранойи, ограничиваю себя в возможности отстрелить себе ногу, так как не верю даже себе.
То же самое и здесь: я использую языки с иммутабельностью, потому что НЕ верю сторонним либам, которые вызываю я, не верю сторонним фреймворкам, которые вызывают мой код, и более всего я не верю самому себе, когда я пишу код, который вызывает мой собственный код, написанный 10 лет назад. Потому что я помню, что всю жизнь писал код в чаду угара, в дедлайнах, на основе отсутствующих или неполных спек и вообще наугад.
Артурег же считает, что что-то полученное из черного ящика, будет хотя бы документировано, если его нельзя менять, а то что он отдает из своего кода, он нигде больше не использует и соответственно, дальше пользователи его либ могут делать с данными что хотят. Все бы хорошо, но только иммутабельные данные, ссылочная прозрачность и персистентные структуры данных - это и есть тот же самый принцип, но возведенный на уровень теоретического обоснования и реализации в языке.
Я не желаю ничего ни помнить, ни знать ни про свой код, ни про сторонние либы, кроме того, что они теоретически не способны сделать что-то плохое, а это автоматом означает иммутабельность и статические типы.
Есть некоторые узкие места, где мутабельные данные хороши, но их можно изолировать действительно в виде черного ящика, и снаружи видеть только иммутабельность.
В любом другом случае иммутабельность автоматически освобождает мозг от нагрузки по удерживанию в памяти лишней информации о состояния.
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
Вообще все началось с того что он пишет некую хитрую штуку на кложури, но при этом использует ее не в идиоматическом стиле, в то с мысле, что вместо кошерных иммутабельных структур использует 100500 ref которые ссылаются на структуры внутри которых еще ref и в итоге у него это все автоматически не сериализуется в json. То есть закат солнца вручную и изготовление из кложури перла и цэ-с-крестиками и поселение там ядовитых жаб и пауков. И все это внутри Software Transactional Memory, т.е. (dosync ...)
Два дня на пару с
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
Впрочем, ему там и структуры такой сложности не нужны, посколько достаточно хранить обновления для этих структур в виде списка, а текущее состояние интегрировать исходя из них.
Аналогичным образом я спорил с канадскими линуксоидами, которые обвиняли меня в том, что я, используя статически типизированные языки и иммутабельные структуры данных, возвожу защитное программирование до уровня паранойи, ограничиваю себя в возможности отстрелить себе ногу, так как не верю даже себе.
То же самое и здесь: я использую языки с иммутабельностью, потому что НЕ верю сторонним либам, которые вызываю я, не верю сторонним фреймворкам, которые вызывают мой код, и более всего я не верю самому себе, когда я пишу код, который вызывает мой собственный код, написанный 10 лет назад. Потому что я помню, что всю жизнь писал код в чаду угара, в дедлайнах, на основе отсутствующих или неполных спек и вообще наугад.
Артурег же считает, что что-то полученное из черного ящика, будет хотя бы документировано, если его нельзя менять, а то что он отдает из своего кода, он нигде больше не использует и соответственно, дальше пользователи его либ могут делать с данными что хотят. Все бы хорошо, но только иммутабельные данные, ссылочная прозрачность и персистентные структуры данных - это и есть тот же самый принцип, но возведенный на уровень теоретического обоснования и реализации в языке.
Я не желаю ничего ни помнить, ни знать ни про свой код, ни про сторонние либы, кроме того, что они теоретически не способны сделать что-то плохое, а это автоматом означает иммутабельность и статические типы.
Есть некоторые узкие места, где мутабельные данные хороши, но их можно изолировать действительно в виде черного ящика, и снаружи видеть только иммутабельность.
В любом другом случае иммутабельность автоматически освобождает мозг от нагрузки по удерживанию в памяти лишней информации о состояния.
no subject
no subject
no subject
PS Это я за ядовитых питонов скажу
no subject
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
Сарказм?
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
(no subject)
(no subject)
(no subject)
(no subject)
no subject
no subject
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
(Anonymous) 2012-03-06 07:41 pm (UTC)(link)(no subject)
(no subject)
no subject
Clojure?
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
no subject
no subject
(no subject)
(no subject)
no subject
Ударение на последний слог делает название изящным!
no subject
Видимо, память экономить..........
(ворчливо) ... Опять всякой фигни притащил ...
Про іммутабельність
no subject
Ну, а кто не просветился — тот сам себе злобный буратино, и ConcurrentModificationException ему в горбатую спину.
(no subject)
(no subject)
(no subject)
(no subject)
no subject
(no subject)
no subject
Конечно можно согласится, что это продуктивно использовать написанный в угаре 10 лет назад код, при этом заботливо окружив его try{}catch{} блоками.
Но с другой стороны, скелеты из шкафов желательно периодически вынимать и внимательно пересчитывать кости.
Я может уже изрядно подзаебал напоминанием того, что просто программист знает, что надо написать, а ХОРОШИЙ программист знает что нужно переписать.
Это как мне кажется Yet Another Good Reason (YAGR) чтобы ператрахивать свои байты.
(no subject)
(no subject)
(no subject)
(no subject)