Про ёжика в тумане, зазнайство, языки программирования и вериги

[vit_r]

В связи со вчерашней дискуссией всплыла интересная тема. В принципе, надо бы спросить гуру функционального подхода, вроде juan_gandhi, но вопрос, скорее, на общую сообразительность.

Как кудесники монад и эндофункторов объясняют нормальным людям работу их софта? «Иди читай код, болван!» работает только на программистах. Да и то, только на тех, которые не умеют правильно посылать.

Устаревшие методы позовляют нормально коммуницировать если не с обитателями отдела маркетинга, то с людьми, способными думать.

- Идентификатор заказа состоит из полей Число, Время, Источник Запроса, Путь Получения и Уникальный Номер. Для таблицы мы группируем записи по времени с интервалом час и подсчитываем среднее для Пути Получения.

- Менеджер Задач ожидает прихода сигналов. Если сигнал А приходит раньше Б, выполнение продолжается. Если Б не приходит в течении заданного промежутка времени, ситсема снова посылает запрос. Если Б приходит раньше А, Менеджер Задач выдаёт ошибку и переходит в состояние ожидания перезапуска.

- Когда пользователь нажимает на кнопку, окно получает фокус ввода и меняет цвет на синий.
...

Примеры не очень красивые, но для демонстрации принципа сойдут и такие. Главное, всё, что происходит в софте, можно пояснить на простом человеческом языке, причём терминами, понятными специалистами в пердметной области.

Если что-то сложное для простого текста, то это можно нарисовать. И поток управления, и структуру классов, и пути ветвления в зависимости от различных условий для бизнес-процессов.

Чтобы не усложнять задачу, представим, что мы руководим группой Очень Крутых функциональных программистов, которые сделали Крутую Программу. Теперь мы сидим в переговорной комнате вместе с заказчиками и пытаемся всеми доступными средствами объяснить, что же такое замечательное они от нас получат. При этом, заказчики должны во-первых, понять, а во-вторых, заметить те мелочи, которые не соответствуют требованиям и особенностям конкретного применения.

Comments

[phoonzang.livejournal.com]

Я не претендую на роль кудесника.

Но по-моему так же и объясняют - "когда пользователь нажимает на кнопку, окно получает фокус ввода и меняет цвет на синий". Логика программы остается такой же, просто в коде она выражена другими идиомами.

Ну 60 лет назад заметили, что при работе с массивами очень часто возникает паттерн "изменить индекс, и если меньше N, то поделать дела, если нет, остановиться" и оформили его в виде конструкции for.

[vit-r.livejournal.com]

Логика программы остается такой же, просто в коде она выражена другими идиомами.

"Всё сделано точно также, только через жопу"

Вопрос был именно про логику выполнения в коде. Потому что у программистов часто программа делает не то, что они думают, она делает.

[shur-ik.livejournal.com]

Причём, если в ООП это скорее полагается "естественным багом", то в ФП -- "исходной фичей".

В этом отношении т-щ Паронджанов с его "иконами" и прочей примитивной визуаплизацией прямой алгоритмики выступает просто аватором божества. Уже потому что прямая алгоритмика обычно лучше воспринимается ЛПР. А уж в графической форме тем более.

[vit-r.livejournal.com]

Задача не представить парадигму в красивых картинках, а объяснить происходящее. Визуализация просто способ удобно сделать это для некоторых аспектов.

[phoonzang.livejournal.com]

А чей-то через жопу?

[vanderdecken-lj.livejournal.com]

Холмс красовался перед Ватсоном просто не озвучивая некие промежуточные этапы своих рассуждений.
В представленной ситуации придется умалчивать о функциональной специфике, переводя ее на человеческий.
Какая-нибудь проверка на непустоту результата пересечения двух множеств будет озвучена как "если А входит в Б"

[vit-r.livejournal.com]

Почему сразу не написать в коде "Если А входит в Б"? тем более, что это гораздо ближе к тому, что выйдет в результате компиляции.

[shur-ik.livejournal.com]

К этому функциональщина и идёт.

Просто (к вопросу о зазнайках) именно в области ФП зазнаек сегодня фатально много. Подавляющее большинство.

Вот. Именно.

[gineer.livejournal.com]

Но я и так знаю ответ -- "это нинужна".
"Мэнеджэры... ну, тупые-е-е!".
Заказчики? А, это те кто не хотят платить мнохо денех на развитие ФП.
Конечные пользователи... а это вообще кто такие?

И вообще... если вы не знаете что такое "монада", хотя они везде... с таким недоумком даже разговаривать не о чем. %)))

Re: Вот. Именно.

[vit-r.livejournal.com]

Потому я и написал: мы не с функциональщиками общаемся, а продаём их работу.

[veremeenko-alex.livejournal.com]

>При этом, заказчики должны во-первых, понять, а во-вторых, заметить те мелочи, которые не соответствуют требованиям и особенностям конкретного применения.

Даже в OOП это проблема, а в ФП максимум делают проверку входных данных.
А обратная задача - по ФП коду понять требования практически не реализуемая, уровень абстракций убивает все конкретику напрочь.

[gineer.livejournal.com]

+1

[vit-r.livejournal.com]

Понятно, что в ООП - это проблема. Но проблема решаемая. Даже пути решения понятны.

[theaspect.livejournal.com]

>При этом, заказчики должны во-первых, понять, а во-вторых, заметить те мелочи, которые не соответствуют требованиям и особенностям конкретного применения.

Для этого же и пишут разные DSL-и. Главное чтобы был адекватный начальник, который не позволит скатиться ему в веселые мап-редьюсы, а будет держать в скучнычных императивных рамках

[vit-r.livejournal.com]

Затраты на создание DSL не всегда оправданы. И для технических задач прямое применение того, что предоставляют старые технологии, вполне достаточно. Плюс, в свете обсуждаемого мостика в реальный мир для функциональщины без разницы, говорить ли со специалистами о создании системы или о DSL для создания системы.

[theaspect.livejournal.com]

есть инструменты, которые позволяют убирать синтаксический мусор и доменный язык получается естественным образом

[alexott.livejournal.com]

я обычно объясняю начиная с крупноблочных диаграмм - use case/component/sequence, и постепенно переходя к более подробным диаграммам, и документам с описанием шагов в больших деталях...

Одно плохо - мало кто это все читает :-(

[vit-r.livejournal.com]

Люди хотят знать то, что им знать нужно, и не хотят тратить время на левые подробности. И вопрос был об общении, то есть, что говорить и что рисовать на доске в процессе диалога.

[ufm.livejournal.com]

Меня, конечно, "настоящие программисты" распнут, но упоминавшийся выше "Дракон" - очень близко подошёл к тому, что нужно. Ему, к сожалению, нехватает обтёсывания в "боевых" условиях больших проектов.

[metaclass.livejournal.com]

У меня отчетность на функциональщине (clojure). Это достаточно простой вариант - поток данных всегда в одну сторону "параметры запроса ->их обработка и генерация sql -> десяток sql запросов->преобразования на функциональщине->сериализация в json и отдача клиенту в виде http-ответа".
Исходя из предположения, что заказчики не цепляются к синтаксису и вопросам вида "почему вы не взяли Java, ведь все пишут на ней), то я описываю работу программы так же, как она декомпозируется на функции - тут мы грузим из SQL данные в список хэшмапов, тут их группируем-фильтруем-объединяем, тут добавляем параметры. Рисуется это в виде последовательности преобразований над наборами данных.

В принципе, я вместе с бухгалтерией их отчеты так и проектировал. переводя то что они рассказывают - в наборы правил в коде.

Меня больше интересует вопрос - что именно хотят узнать заказчики, заглядывая в кишки программы? Обычно границы применимости и соответствие ТЗ должны бизнес-аналитики записывать и прочие тестеры проверять, зачем результат потом описывать заказчику, если он ТЗ соответствует?

[vit-r.livejournal.com]

Data Flow Diagram - это старые добрые структурные методы разработки и процедурное программирование. При чём тут новомодные функциональные монады?

Насчёт же магических бизнес-аналитиков... Во-первых, такие звери в природе не водятся, а во-вторых, заказчиком вполне может быть человек, способный поставить задачу и разобраться в софте.

[metaclass.livejournal.com]

А зачем заказчику обязательно объяснять про монады? Это примерно как рассказывать "мы тут используем паттерн Visitor потому нам нужно один и тот же сложный объект обработать одинаковым по структуре алгоритмом но с десятком разных обработчиков результатов".
Если подобная заменяемость - это важная фича софта, то да, можно объяснить, что мы используем некий обобщенный алгоритм, меня его конкретные реализации.

[akuklev.livejournal.com]

Очень просто: общение с непрограммистами следует вести на русском/английском/немецком/ином человеческом языке, а не на языке программирования. В общем, кудеснические термины просто не имеют отношения к содержательной части, и не упоминаются при обсуждении содержательных аспектов софтины.

Монады и любые другие высокоуровневые абстракции у меня там внутре в конце концов всегда для структурирования кода и прозрачной инфраструктуры хендлинга недефолтных (или дефолтных, но чрезвычайно сложных) сценариев. Специалисту по программированию постараюсь объяснить как есть, чтобы было понятно как это потом развивать, модифицировать и сопровождать, и почему именно такой способ организации кода позволяет существенно уменьшить количество неудобосопровождаемого кода (конечно, в ущерб низкому порогу вхождения, но мы не поп-музыкой занимаемся, чтобы низкий порог вхождения ставить превыше всего). Всем остальным это не нужно и, как правило, не интересно.

[vit-r.livejournal.com]

В общем, кудеснические термины просто не имеют отношения к содержательной части

Тогда это свистки и колокольчики, которые надо выкидывать, потому что они будут мешать дизайну высокого уровня.

инфраструктуры хендлинга недефолтных (или дефолтных, но чрезвычайно сложных) сценариев.

Пардон, это был человеческий русский? :-D

Фигня в том, что именно в этих преобразованиях из человеческий в "способ организации кода" и прячутся самые мерзкие ошибки.

[akuklev.livejournal.com]

Глупости вы какие-то говорите, ей богу. Вы давно последний раз предлагали водопроводчику выкидывать уплотнители и редукторы, потому что они не имеют отношения к содержательной части “провести водопровод оттуда туда, чтобы вода хорошо шла”?

> Пардон, это был человеческий русский? :-D
Нет, это было объяснение тому, кого я счёл за специалиста по программированию.

> Фигня в том, что именно в этих преобразованиях из человеческий в "способ организации кода" и прячутся самые мерзкие ошибки.

Разумеется. Потому что в преобразовании из “человеческий” в “программа” спрятана вся нетривиальная работа программиста. За пределами этого только ремесленная часть на стороне кода и коммуникативная часть, на стороне заказчика. Вопрос не в том переводить ли с человеческого на тот или иной формальный, а в том, на какой и как. Мне, если честно, глубоко непонятно, почему именно вы против какого-то одного конкретного класса абстракций. Вам же не приходит в голову критиковать меня за то, что когда я пишу код для регулирования подачи смазки, я пользуюсь бесовскими методом Чебышева и теоремой Хана-Банаха? Бесовское использование циклов вместо православных меток тоже вроде как вам не претит, а от слова функтор почему-то корёжит, будто это что-то существенно другое. Странно, ей богу.