Здравствуйте, varenikAA, Вы писали:

AA>Во-первых, любой код — овно. Тут важно с какой стороны смотреть.
AA>Во-вторых, нормальное определение. Плюсы прямой работы с памятью — скорость работы ПО. Плюсы монад в определенности вычислений.

Не устали вы эту чушь повторять? Определенность вычислений это свойство функции bind. ФП не построено только вокруг него и не только вокруг монад вообще. Скорость работы ПО так же не определяется пряностью доступа к памяти. В некоторых программах, есть некоторые места, в которых ручная оптимизация пока лучше, чем оптимизирующий компилятора, для примера, допустим, хаскеля. Но это 1% от объема общего кода. Ну хорошо, пусть 10%. Но остальные 90% никаких бутылочным горлышком не являются и никак не ускорятся от использования с или с++, не говоря уж о других языках. Да тут половина критиков ФП пишут на яве или c#.

AA>спагетти код не есть зло в чистом виде. Ценность программы не в изящном применении паттернов, а в том, выполняет ли она поставленную задачу.

Подход, в лучшем случае, какого-нибудь консультанта, которого наняли на полгода, а дальше трава не расти...

Здравствуйте, varenikAA, Вы писали:

AA>спагетти код не есть зло в чистом виде. Ценность программы не в изящном применении паттернов, а в том, выполняет ли она поставленную задачу.

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

Здравствуйте, varenikAA, Вы писали:


AA>идут по пути все большего ограничения возможностей (из книги "Чистая архитектура" Р.М.):
AA>1. Структурное программирование накладывает ограничение на прямую передачу управления.
AA>2. Объектно-ориентированное программирование накладывает ограничение на косвенную передачу управления.

А можно развернуть идею про енти 2 пункта, желательно с примерами?

AA>3. Функциональное программирование накладывает ограничение на присваивание.

Тут более-менее понятно, о чем речь.

Здравствуйте, Poopy Joe, Вы писали:

I>>Из того, что ты хочешь чаю, не совсем понятно, почему жена должна стараться.
I>>Гораздо чаще встречается вариант "Валя-Оля-Катя сделай мне пожалуйста чаю".

PJ>И это тоже не императивный запрос, действия по шагам ты так же не расписываешь. Не благодари.

Это императивный запрос. Кто расписывает действия — дело десятое. Скажем, файловое апи ты вызываешь ::CreateFile. И это считается императивным вариантом, хотя ты не пишешь детали типа "создай хэндл, свяжи его с тем объектом, выдели буфер и тд"

I>>В магазине "подайте мне вон тот чай"
I>>При этом ребенок сначала осваивает императивный язык. Ему только предстоит осознать "я хочу",без этого никак. А до этого "пить", "в туалет", "а-а-а".

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

Я про саму речь.

I>>И кстати, новоиспеченный менеджер именно так и разговаривает с девелоперами — "посмотри, погугли, напиши, отправь, сделай и тд". Называется микроменеджмент — явление распространено чуть более, чем повсеместно.

PJ>И опять по шагам ничего не расписано, то что что нужно сделать. Чистая функциональщина в твоем определении.

В таком случае вообще все есть функциональщина, начиная с CreateFile и подобных вещей. Тоже ведь не расписано

PJ>В голове императивного программиста происходит не описание действий, которые надо выполнить, как ты тут изображаешь, а жонглирования 100500 зависимостями и прочими побочными эффектами размазанными по программе. И получается ровно как в комиксе

Зависимости растут из желания реюзать готовый год. Побочные эффекты — из приемлемого решения задачи. Вот пример — православный хаскель
https://github.com/ixy-languages/ixy.hs/blob/master/src/Lib/Ixgbe.hs

И видим ровно то, что ты приписал императивщине — жонглирование зависимостями, побочными эффектами Вот жеж — Хаскель, а все как в императивщине.

I>>ИТ применяет функциональное сто лет в обед.

PJ>Конечно применяет. А кто с этим спорил?

Отсюда и высокомерие

Здравствуйте, varenikAA, Вы писали:

I>>Разница в том, что сеньору это все уже набило оскомину. А вот джуну и мидлу — нет. Соответсвенно, миддл это такой девелопер, который пишет почти весь рутинный код. Где брать миддлов, которые умеют ФП на раз лично мне не ясно. Единицы встречаются, но так что бы массов — это сильно вряд ли.

AA>Вообщем-то согласен, частично.
AA>Но с утра еще одна причина в голову пришла неиспользования ФП и других хороших ЯП — современные языки (и ФП — как будущее программирования)
AA>идут по пути все большего ограничения возможностей (из книги "Чистая архитектура" Р.М.):
AA>1. Структурное программирование накладывает ограничение на прямую передачу управления.

Структурное программирование это структуризация в определенном виде, в соответсвии с тем, как человек видит решение задачи. Эта устаревшая парадигма, которая прошла минимум две реинкарнации.

AA>2. Объектно-ориентированное программирование накладывает ограничение на косвенную передачу управления.

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

AA>3. Функциональное программирование накладывает ограничение на присваивание.

ФП позволяет организовать вычисления разделяя такие аспекты, как время, последовательность, конкаренси, состояние, изменения состояни, ввод-вывод и тд. В этом ёё смысл.

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

Это снова теория заговора.

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

И вот странно, куча приёмов, которые есть в функциональных языках, находят применение считай повсеместно. А вот доля ФЯ болтается на грани стат погрешности. Отсюда ясно, что проблема именно в ФЯ, которые накладывают слишком много ограничений на всё подряд.

Здравствуйте, GarryIV, Вы писали:

GIV>Чистое ФП не завоюет мир никогда, оно конечно математично но не практично.
Его просто ниасилит большая часть программистов. Если указатели C-е ниасилили и потому перешли на жаву, то что о лиспе говорить.

Здравствуйте, Ikemefula, Вы писали:

I>Это императивный запрос. Кто расписывает действия — дело десятое. Скажем, файловое апи ты вызываешь ::CreateFile. И это считается императивным вариантом, хотя ты не пишешь детали типа "создай хэндл, свяжи его с тем объектом, выдели буфер и тд"

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

I>Я про саму речь.
Сама речь именно, что функциональна. Пойти туда-то, сделай то-то. А не иди перебирай ногами, пока не "условие"...

PJ>>И опять по шагам ничего не расписано, то что что нужно сделать. Чистая функциональщина в твоем определении.

В моем "определении" императивщина это когда ты расписываешь последовательность действий, а в функциональном пишешь что хочешь получить и заполняешь пробелы "как", часто просто следую за ошибками компилятора. Если у тебя есть тип A, а нужен тип D, то ты ищешь кратчайший путь через типы. Например, если есть f (A -> B) g (B -> D) то решение будет h = g . f потому что это композиция удовлетворяет моему желанию получить A->D, и мне даже не надо смотреть внутрь, что оно там делает и не сломает ли чего... Это, конечно, крайне простой случай, и можно возразить, что и императивно можно сделать так же, но веселье начинается когда f (a -> Maybe b) и g ( b -> Either e d), при этом в функциональном подходе мало что измениться, а в императивном появится куча лапши, потому что все это придется распутывать пошагово.

PJ>>В голове императивного программиста происходит не описание действий, которые надо выполнить, как ты тут изображаешь, а жонглирования 100500 зависимостями и прочими побочными эффектами размазанными по программе. И получается ровно как в комиксе

I>Зависимости растут из желания реюзать готовый год. Побочные эффекты — из приемлемого решения задачи. Вот пример — православный хаскель
I>https://github.com/ixy-languages/ixy.hs/blob/master/src/Lib/Ixgbe.hs

I>И видим ровно то, что ты приписал императивщине — жонглирование зависимостями, побочными эффектами Вот жеж — Хаскель, а все как в императивщине.
где? все побочные эффекты изолированы и все сделано через композицию. если ты смотришь на do notation и думаешь, что это императивно, то ты глубоко ошибаешься.

I>Отсюда и высокомерие
Это вряд ли. Он выступал как критик скорее. Причем его имя не то, что бы, скажем мягко, известно, в мире фп и с чего такие понты совершенно непонятно.
Но и кроме него тут полно желающих высказать свое ценное мнение о том какие дебилы функциональщики. Так что твое утверждение попросту ложное.

Здравствуйте, Poopy Joe, Вы писали:

PJ>Скорость работы ПО так же не определяется пряностью доступа к памяти.

Как раз определяется в очень большой степени. Потому что оперативная память — это жуткий тормоз по сравнению с процессором (хуже неё только IO). В какой-то степени эти тормоза компенсирует кэш процессора, но только в том случае, если им правильно пользоваться. Так вот, ФП как раз приводит к максимально не правильному использованию кэша...

PJ>В некоторых программах, есть некоторые места, в которых ручная оптимизация пока лучше, чем оптимизирующий компилятора, для примера, допустим, хаскеля. Но это 1% от объема общего кода. Ну хорошо, пусть 10%. Но остальные 90% никаких бутылочным горлышком не являются и никак не ускорятся от использования с или с++, не говоря уж о других языках.

О, забавно. Ты тут умудрился в одном предложение и высказать абсолютно верное утверждение и наврать на 100%. В реальности практически любой канонический ФП код серьёзно ускорится при его умелом переписывание на императивном подмножестве C/C++. Однако в 90% случае это просто не нужно, как раз потому, что этот код не является бутылочным горлышком (это не означает что он такой же быстрый, как на C/C++, а означает что его быстродействия хватает для выполнения бизнес-задач — быстрее просто не нужно).

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, varenikAA, Вы писали:


AA>>идут по пути все большего ограничения возможностей (из книги "Чистая архитектура" Р.М.):
AA>>1. Структурное программирование накладывает ограничение на прямую передачу управления.
AA>>2. Объектно-ориентированное программирование накладывает ограничение на косвенную передачу управления.

S>А можно развернуть идею про енти 2 пункта, желательно с примерами?

1. оператор goto — усложняет понимание логики.
2. запрет на прямой изменение памяти — путем перемещения стека функции в кучу, т.е. создание объекта, который через вызовы функций по указателю(методы объекта) изменяет значения переменных связанных с этим объектом(его поля).

Как-то так. Нет?

Здравствуйте, Ikemefula, Вы писали:


AA>>2. Объектно-ориентированное программирование накладывает ограничение на косвенную передачу управления.

I>ООП это структуризация сложных систем и вытекающая из этого организация взаимодействия. Ничего другого здесь нет. Косвенно ты передаешь или напрямую, вообще никого не интересует.

и нарушаешь инкапсляцию?

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, Poopy Joe, Вы писали:

PJ>>Скорость работы ПО так же не определяется пряностью доступа к памяти.

_>Как раз определяется в очень большой степени. Потому что оперативная память — это жуткий тормоз по сравнению с процессором (хуже неё только IO). В какой-то степени эти тормоза компенсирует кэш процессора, но только в том случае, если им правильно пользоваться. Так вот, ФП как раз приводит к максимально не правильному использованию кэша...

Общая скорость определяется самым медленным элементом. Иногда это память, иногда процессор, но в 99% это IO. Именно оно и определяет в большей степени. Штука в том, что места где узкое место это числодробилка, они сами по себе небольшие, в сравнении с остальной частью, и часто имеют альтернативные решения в виде GPU или FPGA.

_>О, забавно. Ты тут умудрился в одном предложение и высказать абсолютно верное утверждение и наврать на 100%. В реальности практически любой канонический ФП код серьёзно ускорится при его умелом переписывание на императивном подмножестве C/C++.

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

_> Однако в 90% случае это просто не нужно, как раз потому, что этот код не является бутылочным горлышком (это не означает что он такой же быстрый, как на C/C++, а означает что его быстродействия хватает для выполнения бизнес-задач — быстрее просто не нужно).

Я ровно это и сказал. Хоть на ассемблере перепиши, если приложение ждет сетевой пакет, или просто реагирует на таймер, его общая скорость никак не изменится от переписывания. Где я тут чего наврал?

Здравствуйте, Poopy Joe, Вы писали:

PJ>Общая скорость определяется самым медленным элементом. Иногда это память, иногда процессор, но в 99% это IO. Именно оно и определяет в большей степени.

Это верно в очень редких случаях, более того, в тех случаях, когда это верно, функциональное программирование используется редко (приведите примеры программ на функциональном языке, которые бы обрабатывали огромные объёмы данных и затыкались бы именно на IO). (Поясню — я имею в виду современное железо, способное обеспечить гигабайты пропускной способности в секунду).

PJ>Смелое и бездоказательное утверждение. Я точно так же могу возразить, что в реальность практически любой кода останется примерно таким же. Какой-то, да, станет быстрее, какой-то сделать быстрее написать будет намного сложнее. И чем сложнее код, тем эта вероятность выше.

Вот, например тесты производительности. В них функциональщина сливает по производительности практически всегда. Из особо показательных тестов: C# vs F# — функциональный вариант уступает императивному, исполняющемуся в той же среде (net core).

PJ>Я ровно это и сказал. Хоть на ассемблере перепиши, если приложение ждет сетевой пакет, или просто реагирует на таймер, его общая скорость никак не изменится от переписывания. Где я тут чего наврал?

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

Здравствуйте, Ikemefula, Вы писали:
I>Разумные аргументы известны сто лет в обед. Императивное програмимрование
I>- соответсвует мышлению человека — сделай то, сделай это и тд. Точно таким же языком большинство общаются друг с другом — сделай то, сделай это. Ребенок только родился, а с ним вот так вот разговаривают.
Это, конечно же, чушь. Человек думает не функционально и не императивно. Обе абстракции придуманы искусственно.
Разум даёт нам возможность одновременно (или попеременно) использовать как закономерности (смешав селитру и серу с углём, получим порох), так и концепции изменчивости мира — можно сжечь дрова и они останутся сожжёнными назавтра.
I>- соответсвует тому, как работает процессор, а следовательно максимум перформанса выдают именно императивные языки
Вот это уже ближе к реальности.
I>Если взять функционалистов, то им вечно чтото мешает — то разрабы не те, то начальство, то требования, то железо. Типичный функционалист на обычных девелоперов смотрит свысока, называет "обезьяны", "дуболомы", "мухи" и тд.
Вообще, если так посмотреть, то императивные языки — скорее дань традиции. В начале истории никакие другие языки просто не работали — никого не интересует язык, программа на котором работает непредсказуемое время, и способов оптимизации в общем-то нет.
Гораздо проще начинать с языка, который предсказуемо отображается в инструкции процессора — ведь в конце концов, исполняются именно они (50 лет назад никаких 'CISC over RISC' процессоров не было).
Там, где компилятор выдаёт не тот ассемблер, который нам нужен, мы принудим его вызывать функции, которые мы прямо пишем на ассемблере (неважно, при помощи inline-вставок, или при помощи линковки к .obj полученным макроассемблером).
Благодаря жёсткой семантике ABI, обеспеченной устройством императивного языка, мы понимаем, что вызов "вот здесь" — это именно вызов; мы понимаем, в каких регистрах что будет передано, и как разложены в памяти вот эти наши struct mydata {int length, int[] data}.
Получаем некоторую предсказуемость.

Теперь императивные языки перекраивают код так, как ранним ФЯ и не приснится — конвертируют "инструкции" в SSA форму, вычисляют "реальные намерения", и устраняют всё, что считают лишним.
Вызов факториал(5) из рекурсивной функции превращается в push 120; всякие "скопируй это вот сюда, потом прибавь x, потом отними y, потом подели на 2" заменяются на подчас неожиданные на первый взгляд вещи.

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

ФП, на мой взгляд, проникает в мейнстрим не столько "сверху", как полностью-функциональный тулчейн, пригодный для чего угодно — хоть игростроения, хоть драйверописания, хоть оперденьщины и веб-верстки.
Оно лезет скорее сбоку — постепенно заставляя императивные языки отказываться вот от этого "вылейте воду из чайника, теперь вызывайте "заварить чай" с этим чайником в качестве параметра". Linq, который прямо нарошно сделан для того, чтобы программа делала не то, что написано; паттерн-матчинг; развитие возможностей по автовыводу типов; поддержка иммутабельности в языке и т.п. — это всё пятая колонна декларативщины в мейнстриме.

Совсем отказаться от императивщины не получится никак — из-за той же аппаратуры, которая не сводится к идее "абстрактного вычислителя без побочных эффектов". С другой стороны, сидеть в голой императивщине — очень невыгодно.
Хочется, чтобы там, где мне порядок изменения состояний не важен, кто-то тупой скрупулёзный и неутомимый занимался выбором наилучшей последовательности действий для достижения заказанного мной результата.
Хочется, чтобы можно было комбинировать разные решения разных кусков задачи друг с другом, чтобы не я руками выписывал, что итерация по массиву — это p++, а по списку это p=p->next; а компилятор.

Здравствуйте, Ikemefula, Вы писали:
I>Вот что бы был девелопер со слабой квалификацией и херачил на ФП — за двадцать лет такого ни разу не видел.
Вот что странно: значительная доля данных в мире ворочается через SQL. В том числе и девелоперами со слабой квалификацией. Безо всякой, надо сказать, императивщины. Это, конечно, не настоящее ФП, но тем не менее.
Значительная доля расчётов в мире делается в Excel. В основном — тётеньками, которые алгоритм Евклида даже под страхом смерти не смогут заучить и пересказать. Это, конечно, тоже не настоящее ФП, но тем не менее.

То есть я так думаю, что проблема не в непостижимости самого ФП, как такового, а в неготовности реальных ФП-языков к целевой аудитории.
Ну, то есть у нас же и в ИП всё не сразу зажглось — начиналось то всё вовсе не с шарпов и джавы, и даже не с С++, а со всяких там Кобола, Ады и Фортрана.
Это сейчас мы имеем этот офигенный ландшафт с понятными и удобными языками. А вы попробуйте написать современный сервер приложений на фортране-77, где даже поддержка строк сделана через ж. На её фоне даже сишный char* выглядит белым и пушистым.

Здравствуйте, alex_public, Вы писали:

_>Как раз определяется в очень большой степени. Потому что оперативная память — это жуткий тормоз по сравнению с процессором (хуже неё только IO). В какой-то степени эти тормоза компенсирует кэш процессора, но только в том случае, если им правильно пользоваться. Так вот, ФП как раз приводит к максимально не правильному использованию кэша...
За всё ФП не скажу, но декларативщина никак не противоречит "правильному использованию кэша" — например потому, что позволяет выполнять семантические оптимизации.
Грубо говоря, императивщина может быстро отсортировать массив, благодаря умелому использованию inplace операций и cache-friendly порядку обращений к массиву.
А декларативщина может определить, что только что отсортированный массив не нуждается в повторной сортировке, и выкинуть весь вызов сортировки целиком.

Здравствуйте, Somescout, Вы писали:

S>Это верно в очень редких случаях, более того, в тех случаях, когда это верно, функциональное программирование используется редко (приведите примеры программ на функциональном языке, которые бы обрабатывали огромные объёмы данных и затыкались бы именно на IO). (Поясню — я имею в виду современное железо, способное обеспечить гигабайты пропускной способности в секунду).

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

PJ>>Смелое и бездоказательное утверждение. Я точно так же могу возразить, что в реальность практически любой кода останется примерно таким же. Какой-то, да, станет быстрее, какой-то сделать быстрее написать будет намного сложнее. И чем сложнее код, тем эта вероятность выше.

S>Вот, например тесты производительности. В них функциональщина сливает по производительности практически всегда. Из особо показательных тестов: C# vs F# — функциональный вариант уступает императивному, исполняющемуся в той же среде (net core).

Сравнение f# и c# неверно в принципе, потому что f# ограничен возможностями oo clr. По сути это c# код с дополнительными конструкциями. Разумеется он будет медленнее. В остальном это не сравнение приложений, а сравнение алгоритмов, (неизвестно насколько оптимально реализованных), которые, возможно, вносят нулевую разницу в общую скорость. Разумеется есть места где надо максимальную производительность любой ценой, но обычно такое место очень ограничено и нет никаких проблем использовать там любой язык.

PJ>>Я ровно это и сказал. Хоть на ассемблере перепиши, если приложение ждет сетевой пакет, или просто реагирует на таймер, его общая скорость никак не изменится от переписывания. Где я тут чего наврал?

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

Питон сливает хаскелю, а то и f#, примерно всегда, тем не менее это мало кого останавливает от его использования.

Здравствуйте, Poopy Joe, Вы писали:

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

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

Мир вокруг тебя вообще мутабельный. Все вокруг тебя мутабельное. Именно отсюда это прочно сидит в голове и следовательно присутствует в речи.

I>>Я про саму речь.
PJ>Сама речь именно, что функциональна. Пойти туда-то, сделай то-то. А не иди перебирай ногами, пока не "условие"...

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

"делай шаг, делай еще " — такие вещи ребенку говоря до года. Дальше он научился этом.

PJ>>>И опять по шагам ничего не расписано, то что что нужно сделать. Чистая функциональщина в твоем определении.

PJ>В моем "определении" императивщина это когда ты расписываешь последовательность действий, а в функциональном пишешь что хочешь получить и заполняешь пробелы "как", часто просто следую за ошибками компилятора. Если у тебя есть тип A, а нужен тип D, то ты ищешь кратчайший путь через типы. Например, если есть f (A -> B) g (B -> D) то решение будет h = g . f потому что это композиция удовлетворяет моему желанию получить A->D, и мне даже не надо смотреть внутрь, что оно там делает и не сломает ли чего... Это, конечно, крайне простой случай, и можно возразить, что и императивно можно сделать так же, но веселье начинается когда f (a -> Maybe b) и g ( b -> Either e d), при этом в функциональном подходе мало что измениться, а в императивном появится куча лапши, потому что все это придется распутывать пошагово.

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

I>>Зависимости растут из желания реюзать готовый год. Побочные эффекты — из приемлемого решения задачи. Вот пример — православный хаскель
I>>https://github.com/ixy-languages/ixy.hs/blob/master/src/Lib/Ixgbe.hs

I>>И видим ровно то, что ты приписал императивщине — жонглирование зависимостями, побочными эффектами Вот жеж — Хаскель, а все как в императивщине.
PJ>где? все побочные эффекты изолированы и все сделано через композицию. если ты смотришь на do notation и думаешь, что это императивно, то ты глубоко ошибаешься.

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

I>>Отсюда и высокомерие
PJ>Это вряд ли. Он выступал как критик скорее. Причем его имя не то, что бы, скажем мягко, известно, в мире фп и с чего такие понты совершенно непонятно.
PJ>Но и кроме него тут полно желающих высказать свое ценное мнение о том какие дебилы функциональщики. Так что твое утверждение попросту ложное.

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

Я тебе страшное скажу — императивное и ФП так же не отменяют друг друга, а именно дополняют. Как только нужен перформанс — код резко становится императивным. Можешь потренироваться сам — покажи любой функциональный язык, на котором тот самый драйвер отработает не хуже языка Си или Си++.
Ну или обработка звука, видео и тд.

А вот функционалисты известны высказываниями вида "ФП понад усё": ООП не надо, потому что есть ФП; императивное не надо, потому что есть ФП. Ты сам именно это и утверждаешь, прямо в этом треде.

Здравствуйте, varenikAA, Вы писали:

AA>>>2. Объектно-ориентированное программирование накладывает ограничение на косвенную передачу управления.

I>>ООП это структуризация сложных систем и вытекающая из этого организация взаимодействия. Ничего другого здесь нет. Косвенно ты передаешь или напрямую, вообще никого не интересует.

AA>и нарушаешь инкапсляцию?

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

Здравствуйте, Sinclair, Вы писали:

I>>Разумные аргументы известны сто лет в обед. Императивное програмимрование
I>>- соответсвует мышлению человека — сделай то, сделай это и тд. Точно таким же языком большинство общаются друг с другом — сделай то, сделай это. Ребенок только родился, а с ним вот так вот разговаривают.
S>Это, конечно же, чушь. Человек думает не функционально и не императивно. Обе абстракции придуманы искусственно.
S>Разум даёт нам возможность одновременно (или попеременно) использовать как закономерности (смешав селитру и серу с углём, получим порох), так и концепции изменчивости мира — можно сжечь дрова и они останутся сожжёнными назавтра.

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

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

S>ФП, на мой взгляд, проникает в мейнстрим не столько "сверху", как полностью-функциональный тулчейн, пригодный для чего угодно — хоть игростроения, хоть драйверописания, хоть оперденьщины и веб-верстки.
S>Оно лезет скорее сбоку — постепенно заставляя императивные языки отказываться вот от этого "вылейте воду из чайника, теперь вызывайте "заварить чай" с этим чайником в качестве параметра". Linq, который прямо нарошно сделан для того, чтобы программа делала не то, что написано; паттерн-матчинг; развитие возможностей по автовыводу типов; поддержка иммутабельности в языке и т.п. — это всё пятая колонна декларативщины в мейнстриме.

Я про это и пишу — ФЯ не приживаются, а приживаются отдельные вещи. Фактически, императивное дополняет функциональное и наоборот. Аналогично с ФП и ООП.

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

В твоей картине отсутствует тот, кто пишет код. А вот тенденция такая, что все больше и больше людей идет в разработчики. Фактически, появляются каменщики, бетонщики, арматурщики, маляры, штукатуры и тд — люди, которые выполняют ровно одну задачу.
И что характерно, у них уже нет ни то классного инженерного образования или, ни, тем более, прикладной или теоретической математики. А чем же они могут пользоваться, если абстрактное мышление у них слабовато ?