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

[vit_r]

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

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

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

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

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

Comments

[juan_gandhi]

Трюки да, есть такая проблема, что пионеры любят трюки.

Но вообще-то вы что, против абстракций, что ли? ФП предоставляет кучу удобных абстракций. Просто надо так контекст устраивать, чтоб и народ не пугать, и фигни всякой, бойлерплейта, поменьше.

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

[gineer.livejournal.com]

\\ФП предоставляет кучу удобных абстракций.

Я вас там, в вашей теме и спрашиваю -- какие абстракции ФП и ЧЕМ,
удобны для представления объектов и процессов проблемной области?

Или вы имеете в виду какое-то другое удобство?

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

[juan_gandhi]

Абстракции там - функторы, монады, естественные преобразования. Объекты ж такие же, как и везде. Процессы излагаются через map, filter, flatmap, collect, fold, reduce.

Можно подумать, у вас редукции нету, в "процессах проблемной области".

[gineer.livejournal.com]

\\Абстракции там - функторы, монады, естественные преобразования.

Я разве об этом спрашивал? "Какие есть абстракции?"???

Вроде ж просто и ясно написано -- КАК абстракции ФП мЭплятся на абстракции проблемной области?

Вот в процедурном(модульном) и ООП программировании,
есть естественные программистские абстракции: процесса, файла и т.п. которые более-менее нормально мэплятся... когда нужно где-то и как-то сохранять данные проблемной области.
Но это ОЧЕНЬ примитивно.

Нужно бы какой-то диалоговый, визуальный желательно, интерфейс.
Процедурное тут может дать только командную строку... ну, "окошки" волков командера как максимум. %Р

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



\\Объекты ж такие же, как и везде.

С инкапсуляцией? %)



\\Процессы излагаются через map, filter, flatmap, collect, fold, reduce.

Какой у вас однако высокий штиль... "процессы излагаются". %)

Поди однако узнай чё оно значит...

по смыслу, так "обработка данных" вроде.

Только обработка данных не является проблемой программирования...
с времен допотопного Бэйсика.

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


\\Можно подумать, у вас редукции нету, в "процессах проблемной области".

Там написано "представления объектов и процессов проблемной области".

Процесс -- это тоже абстракция такая, понимаете? ;)
Не ТОТ который в компьютере.
А любо какой -- процесс ферментизации пива,
процесс доставки пиццы заказчику,
процесс покупки опцыона торговым ботом на биржЭ. %Р

Вот и покажите... вы ТАК уверенно об этом говорите,
значит у вас должна быть КУЧА-КУЧ готовых примеров...
так приведите ХОТЯ БЫ ОДИН?

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

[rdia.livejournal.com]

> удобны для представления объектов и процессов проблемной области?

Какая проблемная область? В ряде случаев нет ничего удобнее ассемблера, где-то make рулит и т.д.

Вполне возможно, что в вашей предметной области хорошо подходит ООП.

[gineer.livejournal.com]

\\Трюки да, есть такая проблема, что пионеры любят трюки.

Непионеры собственно тоже... или всех записывать в пионеры, тогда? %)


\\В программировании много неестественного.

Например?

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

Например вата утверждающая что "на Украине много пропаганды" -- должна бы легко указать, в чем именно эта пропаганда состоит. (тем не менее, например, еще НИ ОДИН ватник на подобное не ответил)


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

Думается мне... вы не совсем понимаете идею хибернейта. Чем ему поможет депенденси инжекшн?

Там есть желание иметь возможность восстановить полный стейт объекта.
Для персистентности.

И использование внешнего сервиса -- там совершенно не пробема.
А проблема -- восстановления/сохранения (корректного) связей между объектами.

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

[anonim_legion]

>\\В программировании много неестественного.

>Например?

https://t.me/geekshit/10322
https://t.me/geekshit/10323

[gineer.livejournal.com]

Там идет сравнение с хибернейтом.

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

[rdia.livejournal.com]

> Там есть желание иметь возможность восстановить полный стейт объекта.
> Для персистентности.

Ну тут очень удобны именно всякие Хаскели с прочей функциональщиной.

Примеры...

[gineer.livejournal.com]

в студию! (с) %)

Ну и... какие-то нетривиальные рассуждения по поводу,
почему жабисты/дотнетчики всего мира до сих пор не повыбрасывали свои ОРМы... и не лабают Ынтырпрайз на Хаскиле. %)))

[vit_r]

Трюки да, есть такая проблема, что пионеры любят трюки.

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

И тут важны как возможности технологии, так и окружающая её культура.

Но вообще-то вы что, против абстракций, что ли?

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

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

И, кстати, обработка ошибок тоже на том же уровне, а не бросание Null или Exception в неизвестность, где контекст и смысл потеряны.

Весь хибернейт, например,

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

[gineer.livejournal.com]

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

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

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

И чего вы хотите? Практикантам тоже надо на ком-то тренироватся. (тм) ;)


2. Пробьлема "функции в 500 строк" в том,
что в ней не содержится никакой архитектуры,
она физически не может решать никакую более-мене сложную разностороннюю инженерную задачу.

И... уровень "не бросает эксепшынов" -- это не уровень архитектуры.

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

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


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

А... знаю... вы счас скажете -- мыне Цукерберг НИУКАЗ... это ни наш уровен... я участвовал в ТАКИХ проектах, по сравнению с которыми Цукерберг -- пионЭр в коротких штанишках... %)))))))))))))

[rdia.livejournal.com]

> Индустриальная пригодность технологии зависит от защищённости от пионерства.

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

И как вы тут убережётесь? Хаскель или компилируемый Питон, ака Ocaml вам хотя бы программу не скомпилирует.

> И тут важны как возможности технологии, так и окружающая её культура.

Именно. И вот с культурой у функциональщиков относительно неплохо. Нет вебского говна, нет питоновского идиотизма, С++ной premature optimization и т.д.

[vit_r]

И как вы тут убережётесь?

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

[vit_r]

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

[gineer.livejournal.com]

И вам алаверды... Досточтимый Нэпианэр. %)

[gineer.livejournal.com]

Для абстрагирования ради абстрагирования свой термн есть -- архитектурный астронавтизм.

[jamhed]

Вас почитать так можно подумать фп в "реальных проектах" не применяется, а если и применяется, так "пионерами". Между тем запрос как писать программы которые гарантированно работают есть (aerospace, finance, etc), а вот ответа на этот запрос -- нет, но есть приближения, и эти приближения совсем не кодогенерация из моделей. На любителей моделировать в erwin я одно время насмотрелся (кончилось всё предсказуемо, модели не помогли).

Таки гыде можно скачать

[(Anonymous)]

браузер написаный на эрланге

игрушку написаную на Скале

или хотя бы операционную систему (ядро) налабаную на хаскиле?

[vit_r]

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

Re: Таки гыде можно скачать

[jamhed]

Когда в руках молоток, то всё вокруг похоже на гвоздь. Так и есть.

[vit_r]

но есть приближения, и эти приближения совсем не кодогенерация из моделей.

В каких именно из перечисленных областей благородный дон имел честь поработать, прежде чем утверждать, что мой опыт не соответствует действительности?

На любителей моделировать в erwin я одно время насмотрелся

Надо было смотреть на профессионалов.

[jamhed]

> имел честь поработать, прежде чем утверждать

Если вас мое cv интересует, так без труда можете найти. А утверждает благородный дон совсем не то что вы подумали, но другое, а именно: есть отрасли где есть спрос на безошибочное программирование, и спрос этот удовлетворять нечем, но работы идут (isabelle/hof, agda, idris, haskell, и т.д. и т.п., включая ocaml).

> смотреть на профессионалов.

Профессионал это тот кто за работу деньги получает, так что на них и смотрел.

[gineer.livejournal.com]

\\На любителей моделировать в erwin я одно время насмотрелся (кончилось всё предсказуемо, модели не помогли).

""AllFusion ERwin Data Modeler (ранее ERwin) — CASE-средство для проектирования и документирования баз данных""

В чем суть вашей претензии -- не понятно.
ГыДе там "кодогенерация из моделей"?