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

[vit_r]

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

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

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

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

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

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

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

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

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

Comments

[phoonzang.livejournal.com]

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

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

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

[vit-r.livejournal.com]

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

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

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

[shur-ik.livejournal.com]

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

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

[vit-r.livejournal.com]

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

[shur-ik.livejournal.com]

Совершенно верно.

Проблема же с ООП (обыденная проблема) и с ФП (заведомая) именно в заведомой невозможности представить не вполне компетентному в разработке заказчику фактическое поведение системы.

Как Вы совершенно и заметили.

В случае с ООП эта проблема нерешаема вовсе. Да, осмеливаюсь утверждать именно так.

В случае с ФП теоретически решаема путём обучения заказчика предлагаемой парадигме. Что само по себе ещё та задачка.

Третий случай (Дракон) лишь предлагает дикарский, пещерный, но очень наглядный для некоторых категорий клиентов вариант ясного изложения поведений и структур системы. Что, конечно, не выход, лишь наблюдение.

[vanderdecken-lj.livejournal.com]

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

[vit-r.livejournal.com]

в заведомой невозможности представить не вполне компетентному в разработке заказчику фактическое поведение системы.

Почему программисты такие зазнайки? Финансовые аналитики прекрасно понимают всё, что им важно. Инженеры понимают абсолютно всё, включая зависимости по времени.

[vit-r.livejournal.com]

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

[shur-ik.livejournal.com]

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

А вот среда инженерии куда причудливей. Неоднократно сталкивался с большой трудностью объяснить -- а, например, вот конструктору-ракетчику матмеханизм и логику функционирования нашей программы БЦЭВМ. У него не только не хватало понятийного аппарата воспринять блок-схемы, матрицы состояний и потоки событий -- они просто не желали этого делать. Им подавай, буквально, мультик. Заверения "вот эта теорема с этими наблюдениями учтены" для них пустой звук. "Хочу видеть", и всё тут. А "видеть" -- извините, на полигоне. Стенд дороже изделия, и "в рамках ОКР денег нет". И как объясняться? Трудно. Но у меня обычно получалось хорошо. Хотя бы потому что я-то их понимал, а это уже две трети успеха.

[shur-ik.livejournal.com]

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

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

[vit-r.livejournal.com]

С местными спецами в этой области общался - всё без проблем. Или это советская школа, где в Военмехе задание на вступительных было по типу "Не правда ли, сила тока определяется в амперах?"

[vit-r.livejournal.com]

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

[shur-ik.livejournal.com]

Совершенно верно, именно другая школа. Она ни плоха, ни хороша -- она иная.

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

Про это ходит много анекдотов в рамках темы "извилина одна, да и та от фуражки", и большинство этих хохмочек глупы. Да, такая школа мешает прогрессу. Но она же сильна надёжностью в серии и в режиме.

Впрочем, в российском ракетостроении эта школа уже почти исчезла (по причинам естественной смертности её носителей и огромном разрыве поколений на производстве), так что теперь, может быть, и выйдет что-то иное.

Пока же жду катастроф на РЖД. Там пока школа "одной извилины" ещё сильна. Как вымрут -- пойдут отказы СЦБ и диспетчеры начнут играть на смарфоне за пультом одноколейки (говррят, демократия это позволяет и одобряет).

Это ни хорошо, ни плохо. Это другая школа. Отличных специалистов в своих областях. Которым нет нужды учить Бэйсик и пытаться понять основы задвигов Страуструпа. Они очень хорошо делают своё дело, и им по долгу службы приходится иногда общаться с т.н. "программистами". Что порой вызывает проблемы.

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

Вот. Именно.

[gineer.livejournal.com]

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

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

[shur-ik.livejournal.com]

Я, кстати, тоже.

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

А вот вся промэлектроника, которую видел -- либо чистая алгоритмика: даже плюсы скорее исключение; если не "чистый Си", то как правило разновидность ассемблера с визуализатором алгоритмов в рамках фирменной IDE; либо, наконец, ПЛИС (что само по себе отдельная тематика).

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

[vit-r.livejournal.com]

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

[gineer.livejournal.com]

\\В случае с ООП эта проблема нерешаема вовсе.

П*ж.

Обычное текстовое описание, с последовательным исползованием лексических денеиц,
легко (ну, отностельно, это уже от программиста зависит, да) переводится в ООП,
по принцыпу:
существительные -- объекты,
глаголы -- взаимодействия между ними.

[phoonzang.livejournal.com]

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

[vit-r.livejournal.com]

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

Страструп - это не то, на что стоит равняться, если поглядеть, во что превратился С++.

Насчёт катастроф - это общая болезнь. Специалистов для DB не найти. Просто нет людей с достаточно глубокой подготовкой по базовым предметам.

[permea-kra.livejournal.com]

Эрланговский телеком отлично представляется деревом владения процессов и стрелочками передачи сообщений. И он, если что, создавался скорее под влиянием пролога, чем ФП. Лисп к ФП прямого отношения не имеет.

[shur-ik.livejournal.com]

Эта проблема нерешаема вовсе.

Просто исходя из того, что только что употреблённый Вами термин "пиздёж" в рамках типичной ООП-программы вполне может выражать "бурные, продолжительные апплодисменты сопровождали речь докладчика". Что бы Вы ни пытались мне сейчас эмоционально выразить -- а вот у меня просто библиотека другая. И всё. Доклад был хорош, но реализация слита в унитаз.

Это изначальная фича ООП.

[shur-ik.livejournal.com]

Ну вот, наконец-то появились специалисты.
Приятно слышать.

[vit-r.livejournal.com]

Эрланг прекрасен. Но, именно, в тех местах, где отличается от "правильного FP". Стрелочки передачи сообщений - это, вообще, язык телекома.

[permea-kra.livejournal.com]

Я вообще не программист. А хаскелем я пользуюсь вместо перла и авка для анализа данных, потому что хаскель у меня в голове помещается, а перл/авк - нет.

[vit-r.livejournal.com]

Ту часть Перла, которая не помещается в голове, можно просто обрезать. Как впечатления от Хаскеля не в смысле преобразования, а в смысле нахождения ошибок в данных?