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

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

Как получится Это же форум, тут необязательно отвечать на всё и сразу, причём ответить можешь и не только ты.

F>>> Да, и, в моём коде, на C# — много методов, которые можно было бы назвать чистыми функциями. Но, чистые функции — сами по себе не самоцель.
EP>>Чистые где? Внутри или снаружи?
F> Я ж написал тоже самое. Ялгоритм сортировки in-place.

Так всё-таки, в твоём коде много каких чистых функций? У которых просто чистый интерфейс или и в реализации нет никакого мутирования?

F> Мне лень разбираться в хаскеле, очевидно, и так, что для реализации quicksort нужны как минимум массивы и мутации.

Вот они и натягиваются на чистое ФП через через монады. При этом каждый последовательный statement это под капотом замыкание вложенное в замыкание предыдущего statement'а, которое в свою очередь вложено в в замыкание предыдущего, которое и т.п.

F>При этом, всё же, стоит отметить, что это ущербность ЯП, а не декларативно-функционального подхода как такового.

ФП это как раз про избегание явного мутирования, если же оно есть — то это отход от ФП.

F>>> Сомневаюсь. Итерирования, как такового в математике пожалуй нет.
EP>>Есть. Итерирование, как и ИП в целом — чисто математическая концепция. Итерационные алгоритмы учат начиная с первых классов математики.
F> Ты про деление в стобик что-ли?

В том числе.

F>Это не имеет отношения к итерированию.

Ярко выраженное итерирование с изменением состояния типа "текущий разряд".

EP>>Другой пример — начала Евклида — книга по которой учат геометрию почти 2300 лет. В дословном переводе первые три постулата отличаются от того, как нас учат в школе "через две точки можно провести прямую ...". Например перевод Sir Thomas Heath:
F> Есть в математике масса алгоритмов вычислить одно и тоже, но как именно это ты будешь делать вообще никого не волнует.

Математику саму по себе вообще ничего не волнует. Но построение алгоритмов, как и сами алгоритмы — это математика в чистейшем виде.

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

Конкретные вычисления — это та же математика. Даже более того — математика изначально была как раз про конкретные вычисления, и про то как совершать их быстрее.

F> Геометрию же любого рода — я лично за математику не считаю.

Геометрия — со всеми этими постулатами, аксиомами, леммами, теоремами — это математика в дистиллированном виде.

F>Это она — основана на математике (аналитическая её часть).

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

F> Я помню как ночами рисовал фигню всякую — ничего там от математики точно нет.

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

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

Так и я о том же

EP>>Я же прямым текстом сказал что ООП неплох в качестве поставщика типов для параметров функций.
F> Если я правильно понял, то разницы я не понял. Я понял только, что снаружи ООП-like — удобнее выходит.

Взять например STL — алгоритмы и контейнеры. Контейнеров-классов — десятки, алгоритмов-функций их использующих — сотни. По-твоему это ООП-like?

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

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

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

Внутри нет, но они точно также встают в полный рост "снаружи".

F> Я и написал, что, как по мне — это (отсутствие стандартной КОМ) — куда более существенно, чем всё остальное.

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