О допустимой сложности
Jul. 15th, 2012 04:56 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassОчередной раз уткнулся на работе в безумие.
Безумие заключается в том, что теоретически правильные методики работы приводят к разрастанию непонятного кода.
Теоретическая правильность заключается в DRY. Т.е. куски кода и данных, являющиеся отражением одних и тех же сущностей или потоков данных предметной области выносятся в отдельные модули, обобщаются, делаются универсальными и прочее.
Причем тут именно что не натягивание совы на глобус, когда "похожие" функции и данные насильственно обобщаются, а только те, где написание двух раздельных заведомо приведет к необходимости синхронной правки двух и более разных мест кода.
А возникающая непонятность - это то, что в результате один конечный результат работы зависит от десятков модулей, в каждом из которых функции высшего порядка посылают другие функции третим функциям, возвращающим функции, которые обрабатывают списки функций.
Это условно говоря, на практике там ничего сложнее "передать функцию-конвертор и параметры в обобщенную функцию и получить результат" нету. В паре мест есть reduce внутри reduce для сложной группировки, все это занимает 10-20 строк кода и спокойно целиком вмещается на экран.
Подобные вещи для меня являются достаточно простыми и самоочевидными. Даже в чужом коде (нормально написанном) понятно, как с таким работать: открываешь самую верхнюю функцию и начинаешь от нее идти по дереву вызовов, постепенно отсекая неинтересные ветки, пока не доберешься до нужной. Это даже в крестиках-жабах-дотнетах-питонах просто, а в функциональных языках с их лаконичностью и того проще.
А проблема в том, что потом это нужно объяснить коллегам. И тут начинается какая-то знатная хрень, потому что я объяснить не могу.
Для меня очевидно, что map/filter/reduce - это как 2+2, обработка последовательностей, на которой вообще вся эта функциональщина стоит, и что структура данных определяет вызываемые для нее функции и что общие функции и данные нужно выносить в отдельные модули, а не писать каждый раз заново одно и тоже. Но процесс раскладывания в уме ТЗ на эти базовые блоки и обратной сборки конечного результата из блоков - объяснению не поддается.
Писать же код в "понятном стиле", в том смысле, чтобы минимизировать сложность за счет написания в лоб, без зависимостей, не выделять отдельные функции для удобства чтения - это, по моему, какой-то совсем уже бред.
Безумие заключается в том, что теоретически правильные методики работы приводят к разрастанию непонятного кода.
Теоретическая правильность заключается в DRY. Т.е. куски кода и данных, являющиеся отражением одних и тех же сущностей или потоков данных предметной области выносятся в отдельные модули, обобщаются, делаются универсальными и прочее.
Причем тут именно что не натягивание совы на глобус, когда "похожие" функции и данные насильственно обобщаются, а только те, где написание двух раздельных заведомо приведет к необходимости синхронной правки двух и более разных мест кода.
А возникающая непонятность - это то, что в результате один конечный результат работы зависит от десятков модулей, в каждом из которых функции высшего порядка посылают другие функции третим функциям, возвращающим функции, которые обрабатывают списки функций.
Это условно говоря, на практике там ничего сложнее "передать функцию-конвертор и параметры в обобщенную функцию и получить результат" нету. В паре мест есть reduce внутри reduce для сложной группировки, все это занимает 10-20 строк кода и спокойно целиком вмещается на экран.
Подобные вещи для меня являются достаточно простыми и самоочевидными. Даже в чужом коде (нормально написанном) понятно, как с таким работать: открываешь самую верхнюю функцию и начинаешь от нее идти по дереву вызовов, постепенно отсекая неинтересные ветки, пока не доберешься до нужной. Это даже в крестиках-жабах-дотнетах-питонах просто, а в функциональных языках с их лаконичностью и того проще.
А проблема в том, что потом это нужно объяснить коллегам. И тут начинается какая-то знатная хрень, потому что я объяснить не могу.
Для меня очевидно, что map/filter/reduce - это как 2+2, обработка последовательностей, на которой вообще вся эта функциональщина стоит, и что структура данных определяет вызываемые для нее функции и что общие функции и данные нужно выносить в отдельные модули, а не писать каждый раз заново одно и тоже. Но процесс раскладывания в уме ТЗ на эти базовые блоки и обратной сборки конечного результата из блоков - объяснению не поддается.
Писать же код в "понятном стиле", в том смысле, чтобы минимизировать сложность за счет написания в лоб, без зависимостей, не выделять отдельные функции для удобства чтения - это, по моему, какой-то совсем уже бред.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-07-15 02:01 pm (UTC)no subject
Date: 2012-07-15 02:11 pm (UTC)Еще 2.5 года назад это можно было сделать нормально - т.е. взять обычного программиста на C#/Delphi/SQL, то сейчас уже все, поезд ушел - с непрерывно нарастающей рабочей нагрузкой я смог справиться, только используя сначала кодогенерацию на F#, затем DSL на Clojure.
no subject
Date: 2012-07-15 02:16 pm (UTC)no subject
Date: 2012-07-15 03:04 pm (UTC)Проблемы начинаются, когда надо придумать структуру нового документа, или разобраться, пригодна ли старая структура к повторному использованию, и вообще при изучении внутренностей.
no subject
Date: 2012-07-15 03:06 pm (UTC)Как только тебя перекупит Айсед, дети ребе Б начнут кушать картофельные очистки. :)no subject
Date: 2012-07-15 03:21 pm (UTC)no subject
Date: 2012-07-15 03:30 pm (UTC)no subject
Date: 2012-07-15 03:36 pm (UTC)no subject
Date: 2012-07-15 03:47 pm (UTC)no subject
Date: 2012-07-15 09:22 pm (UTC)no subject
Date: 2012-07-16 03:13 am (UTC)Кто на него полезет-то!
;-)
no subject
Date: 2012-07-16 08:12 am (UTC)no subject
Date: 2012-07-15 08:56 pm (UTC)no subject
Date: 2012-07-16 04:15 am (UTC)no subject
Date: 2012-07-16 07:34 am (UTC)no subject
Date: 2012-07-16 07:35 am (UTC)no subject
Date: 2012-07-16 07:45 am (UTC)no subject
Date: 2012-07-16 08:38 am (UTC)Ну может быть.
no subject
Date: 2012-07-15 02:52 pm (UTC)Вообще, имхо, даже безотносительно к фп, у народа явные заструднения с пониманием того, что структура рождается из функционального предназначения. Что при любой парадигме пограммирования сначала идет FA, a уже потом всяческие SA. Говоришь вроде самоочивидные вещи, а на тебя непонимающими глазенками хлопают и опяь за старое, а что если сделать так, а можно сделать так. Да, так а что вы делать-то собрались? Для чего это предназначено, какие функции выполнять будет? А в ответ- хлоп-хлоп.
no subject
Date: 2012-07-15 02:58 pm (UTC)no subject
Date: 2012-07-15 06:06 pm (UTC)no subject
Date: 2012-07-15 06:25 pm (UTC)Если у вас разделение на функции нелогично - тушите свет.
no subject
Date: 2012-07-16 02:28 pm (UTC)Отсюда и попытка писать общие модули/обработки везде, где они хотя бы немного общие.
no subject
Date: 2012-07-15 07:05 pm (UTC)no subject
Date: 2012-07-15 08:36 pm (UTC)no subject
Date: 2012-07-15 07:13 pm (UTC)Твоя программа набрала уже такую сложность что для ее дальнейшего функционирования нужно уже создавать сообщество.
no subject
Date: 2012-07-15 07:16 pm (UTC)no subject
Date: 2012-07-15 07:17 pm (UTC)no subject
Date: 2012-07-15 07:24 pm (UTC)no subject
Date: 2012-07-16 02:28 pm (UTC)Таки да, плюсую.
no subject
Date: 2012-07-16 07:15 pm (UTC)А такое вообще бывает? Можно примеры?
no subject
Date: 2012-07-17 06:53 am (UTC)В моей практике интересные случаи c "потому что группа" сводились в основном к факторизации. Вся линейная алгебра, кстати, построена на "потому что группа", правда, там связка из нескольких групп, часть из которых абелевы.
no subject
Date: 2012-07-15 08:52 pm (UTC)И коллег подбирать способных к абстракции.
И это относится не только к сведению всего к тензорному произведению моноидов, а просто к осознанию сути вещей, прежде чем кодировать байтики.
no subject
Date: 2012-07-16 03:17 am (UTC)"Теорию категорий вспоминать не нужно" —
metaclass.livejournal.com/710583.html
no subject
Date: 2012-07-16 01:21 am (UTC)Если же объяснять map/filter/reduce людям безграмотным, то я бы, пожалуй, только через linq смог бы :)
Такое чувство, что им нужен ликбез, но фирма ликбез не спонсирует, если я правильно понял.
no subject
Date: 2012-07-16 09:19 am (UTC)no subject
Date: 2012-07-16 02:31 pm (UTC)А вот это кстати хитрый момент, 100% согласен, что на этом функциональщина стоит, но сам так думать не умею. Более высокий уровень абстракции, так думать ещё научить надо.
В идеале - ещё в универе на модельных задачах, но тут Вы понимаете...
UPD: Это я всё к тому, что дело не в допустимой сложности (который для меня, скажем, связан с количеством объектов, которыми надо одновременно оперировать), а в допустимом для индивида уровне абстракции.
no subject
Date: 2012-07-16 07:20 pm (UTC)