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

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

F>>При чём, он сам по себе отлично реализуется и в ФЯ.
EP>Как? Вот так? Через те самые монады и трёхэтажные замыкания?
F>> Да, и, в моём коде, на C# — много методов, которые можно было бы назвать чистыми функциями. Но, чистые функции — сами по себе не самоцель.
EP>Чистые где? Внутри или снаружи?
Я ж написал тоже самое. Ялгоритм сортировки in-place. Эрика зачем ты сюда призвал.
Мне лень разбираться в хаскеле, очевидно, и так, что для реализации quicksort нужны как минимум массивы и мутации.
Да и реализуется это как угодно. ! Там прямо сказано, что не везде это реализуемо в прямом смысле, о чём ты и говоришь. При этом, всё же, стоит отметить, что это ущербность ЯП, а не декларативно-функционального подхода как такового.

F>>>>При этом, в C/C++ — есть оператор , который выполняет туже роль, что и ; — но для выражений. Дублирование на лицо.
EP>>>Я не вижу причём тут expressions vs statements.
F>> Сомневаюсь. Итерирования, как такового в математике пожалуй нет.
EP>Есть. Итерирование, как и ИП в целом — чисто математическая концепция. Итерационные алгоритмы учат начиная с первых классов математики.
Ты про деление в стобик что-ли? Это не имеет отношения к итерированию.

EP>Другой пример — начала Евклида — книга по которой учат геометрию почти 2300 лет. В дословном переводе первые три постулата отличаются от того, как нас учат в школе "через две точки можно провести прямую ...". Например перевод Sir Thomas Heath:
Есть в математике масса алгоритмов вычислить одно и тоже, но как именно это ты будешь делать вообще никого не волнует. Есть конкретные операции (операторы). Начиная от суммы рядов, в том числе и бесконечных — заканчивая не знаю даже чем, пусть будет перемножением матриц самых разных размерностей.
Алгоритмы, появляются, когда мы переходим от аналитики к конкретным вычислениям. При чём попунктно оно как раз разложено для того, что бы в это могли въехать прежде всего люди.
Численные методы — это как раз тот раздел, который по-колхозному, можно назвать "сборник алгоритмов для ЭВМ".
Геометрию же любого рода — я лично за математику не считаю. Это она — основана на математике (аналитическая её часть). Я помню как ночами рисовал фигню всякую — ничего там от математики точно нет.

F>> Зачем монады и bind-ы я не понял. Что мешает иметь оператор ; в ФЯ, ну кроме научных комплексов? Кроме того, гибридные ФЯ именно это и позволяют.
EP>В том-то и дело что это будет гибрид. Я как раз за гибридный подход, и против фанатизма типа "всё должно быть объектом", "всё должно быть чистым" и т.п.
Ну так и пусть будет гибрид.

EP>Я не спорю что это удобно. Тем не менее итерации с явным мутированием данных это ИП, даже если это сделало на expressions вместо statements
Ты прав. Но, итерации тут не причём. Итерирование в ФП используется в полный рост (через рекурсию, через отрыв головы и рекурсию и т.п.). А вот мутации — да, согласен.

F>>>> Интерфейс чего? Я не понял. И что значит функциональный интерфейс?
EP>>>Интерфейс в смысле API. Функциональный интерфейс — это когда "снаружи" у нас функции, причём чистые настолько, насколько это целесообразно.
F>> Это уже закончилось прокачкой магических хэндлов в параметры любого API, от API OS до API библиотек.
EP>Я же прямым текстом сказал что ООП неплох в качестве поставщика типов для параметров функций.
Если я правильно понял, то разницы я не понял. Я понял только, что снаружи ООП-like — удобнее выходит.

F>>>> Если тебе кажется что все парадигмы — это лишь названия и об одном и том же, — то с философской точки зрения — это так и есть.
EP>>>В каком смысле?
F>> В том, что все парадигмы программирования — разные инструменты для достижения одной и той же цели.
EP>А что из этого следует? Нужно свернуть все обсуждения преимуществ той или иной парадигмы так как цель-то у них одна?
F>>В итоге — это выполняется на конкретном железе с ожидаемыми "сайд-эффектами".
EP>Да, но например что-то более эффективно ложится на реалии современного железа, а что-то нет. Это крайне объективный показатель.
Вовсе нет, напротив.
И делается то всё ради целевых платформ, и безбожно тормозящий софт использующий самые правильные парадигмы (пофигу какие) — он никому не нужен.

F>> Шаблонная магия (навроде shared_ptr), которая доступна исключительно внутри модулей, но без неё нормальный API тоже не получается.
EP>Конкретные воплощения шаблонов можно экспортировать из динамических библиотек. Если нужно дать возможность пользователю инстанциировать шаблоны со своими типами — то нужно распространять код/headers.
EP>Но только причём тут всё это? Я про C++, метапрограммирование и параметрический полиморфизм вроде ничего не говорил.
EP>Да и те же Generics спокойно гуляют по .NET и JVM
Можно, но — за пределами C++ — это использовать толком невозможно. Например из тех же .NET и JVM. Есть конечно разной извращенности способы, но это приседания вокруг одного и того же. Я как раз и написал "к сожалению стандартной компонентной модели не существует". Разумеется внутри .NET и внутри JVM проблем таких нет.
Я и написал, что, как по мне — это (отсутствие стандартной КОМ) — куда более существенно, чем всё остальное.