Что: b2b9421e5db7f7c181f6b61315c0e6045569d832
Когда: 2024-10-27 15:15:46+03:00
Предотвращая коллапс цивилизации https://www.youtube.com/watch?v=ZSRHeXYDLko Очень понравилось данное выступление! Не могу оценить действительно ли всё так упирается в передачу умений/знаний другим поколениям. Но очень понравились примеры постоянно глючащего софта, при этом большинство считает это допустимым и нормальным. Вот почему сама мысль об использовании смартфонов или JS-based приложений просто омерзительна и безумна для меня? Потому что я вижу со стороны насколько это всё паршиво сделано, насколько сбоит и ведёт ненадёжно. Мне, как человеку не "обитающему" в мире "современных ИТ-технологий", просто бьёт в глаза как всё паршиво и ненадёжно сделано. Всегда считал что это "на отвали" подход к работе, но понимаю что нет -- просто люди по другому не то что не умеют, но даже не задумываются о том, что это просто не нормально когда программа ведёт себя насколько ненадёжно и некачественно. Свои страхи о том, что непонятно а много ли где можно работать программистом (34780e342dd2489e684bab3bc927c1eae632d554), у меня как-раз именно, из-за ставшей нормой, переусложнённостью (на пустом месте) софта. Как в выступлении показывается: вместо того, чтобы установить/перенести приложение просто копированием .exe файла, теперь люди просто не в состоянии даже подумать как можно обойтись без какого-нибудь docker. Написать pure-HTML страничку без JS+CSS+IDE-ramework-ов. Не раз в выступлении произносится слово "безумие". А также "переусложнённость". А также "простота", за которые в этом году я топлю, похоже, особенно много. Мне хочется просто передать звук из одного места в другое -- это лютое безумие использовать для этого WebRTC, исходный код который я вдоль и поперёк смотрел и даже правил. Это безумное по сложности решение для простой VoIP задачи. Поэтому родился мой VoRS клиент, где я даже от X.509+TLS избавился как от ненужной сложности (хотя это скорее уже just-for-fun было). Недавно я YAC формат сделал, тоже, можно сказать как ответ на переусложнённый CBOR. BASS систему сборки, в которой и CI часть есть. Всё это про тему борьбы с переусложнённостью.
From: kmeaw
Date: 2024-10-28 00:05:58Z
Проблема действительно существует, но как мне кажется, докладчик ищет её
не там. Всё то, что он перечисляет среди того, что мы не можем больше
"просто сделать" существует по определённым причинам - в большинстве
случаев попытка использовать более простой подход приведёт к
возникновению сложности (причём часто скрытой, плохо измеряемой и
изучаемой) в других местах. Например, на C очень сложно писать большие
программы - в нём нет нормальных средств для обобщённого
программирования (void* и макросы я такими не считаю), нет возможности
эффективно реализовывать стандартные алгоритмы (qsort vs C++ std::sort)
и структуры данных (часто вижу if (!strcmp(str,...)) { ... } else if...
вместо hashtable[str]->run()). Для маленьких и простых вещей это
нормально, для более сложных и больших нужны другие подходы. SOLID
придумали не просто так.
Не вижу никакого подтверждения того, что программы развиваются только
благодаря развитию аппаратного обеспечения - по крайней мере в мире
системного ПО. Появляются новые алгоритмы, новые подходы - те же
проблемы распределённых систем уже гораздо лучше изучены, компании
научились строить кластера из условно "обычного" железа.
Реальная проблема есть в мотивации людей. Плохо, когда сложность растёт
из-за того, что кому-то нужно создать новую систему, чтобы, например,
получить повышение, или обойти какое-то бюрократическое препятствие, но
не для того, чтобы решать ранее неразрешимые задачи. Да и сами
коммерческие предприятия часто ставят краткосрочные выгоды важнее
долгосрочных планов по планомерному развитию. Это вынуждает линейного
разработчика концентрироваться на том, чтобы быстро решить задачу прямо
сейчас, а не изучать то, как устроено всё вокруг, чтобы правильно это
использовать и не приводить к росту сложности. Кто-то вообще не
заинтересован в достижении результата, а просто хочет прыгать между
работами, повышая свой грейд, зарплату и обрастая всё более
впечатляющими записями в резюме. А это в свою очередь приводит к
появлению всё новых барьеров при найме, для преодоления которых нужно
специально готовиться.
Когда-то Rob Pike пришёл в Google и был крайне опечален тем, что
система, которая выглядит такой простой снаружи (пустая страница с
текстовым полем, куда нужно просто ввести запрос и нажать Enter)
выглядит такой сложной внутри (один из поисковых бинарей принимал argv
на тысячи флагов). Он заявил, что будет пытаться бороться со сложностью.
Когда он увольнялся, то кто-то из сотрудников спросил его - "ну как там
борьба со сложностью", и ему пришлось признать, что не получилось.
Отчасти лишняя сложность возникает ещё и из-за того, что некоторые вещи
просто тяжело изучить. Я слабо представляю, какую я могу дать
рекомендацию "с чего начать?" тому, кто не застал появления всего того,
что я мог изучать прямо в процессе развития.
Часть проблем можно решить, если делать другие машины. Одно из важных на
мой взгляд свойств, которое мы потеряли - иметь одно место, которое
управляет всеми ресурсами непосредственно. Сейчас совремнный компьютер -
это сеть множества маленьких компьютеров, каждый из которых исполняет
свою операционную систему, причём один из них выделен отдельно. Я не
могу единообразно обновить ПО везде, измерить потребляемые ресурсы и так
далее. Более того, отдельные части этой сложной системы существуют с
целью скрыть что-то или даже обмануть другую часть. Было бы здорово
иметь ОС, которая бы умела залезать в самые далёкие части этой
запутанной системы, показывать и давать управлять всем состоянием.
Причиной происходящего также является ограниченность человека
воспринимать информацию. И чем больше вокруг нас всякого мусора, тем
больше приходится тратить когнитивных ресурсов на его фильтрацию,
оставляя меньше возможностей для совершения "полезной" работы. И
оставить некоторый запас на непредвиденный случай, ведь как говорит
Brian Kernighan, нельзя писать код настолько умно, насколько возможно,
ведь тогда его будет невозможно отладить.
Могу порекомендовать доклад "Simple Made Easy" от Rich Hickey, автора
языка Clojure. В нём он подробно рассказывает о разнице между simple и
easy, и почему часто использование easy-подходов приводит к росту
complexity.
From: Sergey Matveev Date: 2024-10-28 16:29:30Z
Сгенерирован: SGBlog 0.34.0