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
*** kmeaw [2024-10-28 00:05]:
>Проблема действительно существует, но как мне кажется, докладчик ищет её
>не там. Всё то, что он перечисляет среди того, что мы не можем больше
>"просто сделать" существует по определённым причинам - в большинстве
>случаев попытка использовать более простой подход приведёт к
>возникновению сложности
Я не уверен что в "большинстве" случаев, но в целом согласен.
>Например, на C очень сложно писать большие [...]
>Для маленьких и простых вещей это
>нормально, для более сложных и больших нужны другие подходы. SOLID
>придумали не просто так.
И проблема в том, что очень часто берут инструмент не под стать задаче.
Сколько раз я слышал как брали всякие Zookeeper+Kafka+Whatever для
задач (с учётом объёма данных) где какой-нибудь одной PostgreSQL можно
обойтись, если не SQLite3. Когда берут экскаватор вместо лопаты, чтобы
вырыть ямку для одуванчика. SOLID, ООП и прочее придумали не просто так,
но и не для того чтобы на каждом шагу их слепо использовать.
>Не вижу никакого подтверждения того, что программы развиваются только
>благодаря развитию аппаратного обеспечения [...]
Кстати после просмотра я про этот его тезис совсем забыл. Да, тоже не
вижу тут корреляции.
>Реальная проблема есть в мотивации людей. [...]
Со всем вышесказанным согласен!
>Отчасти лишняя сложность возникает ещё и из-за того, что некоторые вещи
>просто тяжело изучить. Я слабо представляю, какую я могу дать
>рекомендацию "с чего начать?" тому, кто не застал появления всего того,
>что я мог изучать прямо в процессе развития.
Тоже солидарен со сказанным.
>Часть проблем можно решить, если делать другие машины. [...]
Согласен, поддерживаю.
>Причиной происходящего также является ограниченность человека
>воспринимать информацию. [...]
Именно это одно из первых у меня в голове возникает как объяснение тому,
почему не все могут всё знать в своей области. Знаний слишком много,
плюс ещё и растут. Было бы неплохо 10+ лет потратить на получение массы
академических знаний и умений, щёлкать как орешки "art of programming" и
всё в таком духе, но при этом всё это время ничего не делать на практике.
А можно и говнокодить после "программист за пару недель, найм
гарантирован" и удовлетворяться только этим, никак дальше не развиваясь.
>Могу порекомендовать доклад "Simple Made Easy" от Rich Hickey, автора
>языка Clojure. В нём он подробно рассказывает о разнице между simple и
>easy, и почему часто использование easy-подходов приводит к росту
>complexity.
Беру на заметку, спасибо! Но уже где-то читал и понимал про разницу
между "easy vs simple" и что, очевидно, easy может легко делать более
сложные системы.