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

EP>>>Чистые где? Внутри или снаружи?
F>> Я ж написал тоже самое. Ялгоритм сортировки in-place.
EP>Так всё-таки, в твоём коде много каких чистых функций? У которых просто чистый интерфейс или и в реализации нет никакого мутирования?
Много и тех и других, как много и мутирующих (инфраструктура в основном, да и цель — состояние).
Но (по случайному совпадению) — сейчас ключевая функциональность сосредоточена там где вообще нет никакого мутирования.
А в другом небольшом проекте — логики считай вообще нет, одна инфраструктурщина, — и считай — везде одно состояние.

F>> Мне лень разбираться в хаскеле, очевидно, и так, что для реализации quicksort нужны как минимум массивы и мутации.
EP>Вот они и натягиваются на чистое ФП через через монады. При этом каждый последовательный statement это под капотом замыкание вложенное в замыкание предыдущего statement'а, которое в свою очередь вложено в в замыкание предыдущего, которое и т.п.
Т.е. ресурсы это может сожрать в один момент.

F>>При этом, всё же, стоит отметить, что это ущербность ЯП, а не декларативно-функционального подхода как такового.
EP>ФП это как раз про избегание явного мутирования, если же оно есть — то это отход от ФП.
Правильно. Я говорю о ЯП. Когда ЯП тебя ограничил, а тебе нужно именно так — получается взяли вилы (C/C++) в руки, накостыляли что нужно, и прибиндили чего-нибудь. Мне такой подход в ЯП (ограниченный) — решительно не нравится.


. . .

F>> Я помню как ночами рисовал фигню всякую — ничего там от математики точно нет.
EP>Это видимо не геометрия, а какое-нибудь черчение (начертательная геометрия) — но и там математики хоть отбавляй.
Она (начертательная). Ну математика есть везде, тут спорить смысла нет. Просто, мне казалось, её там и не так много (хотя может и забылось).

EP>Вот есть отрезок, на отрезке нужно построить равносторонний треугольник — например это можно сделать с помощью циркуля и линейки, воспользовавшись геометрическими свойствами.
Угу. Мне под математикой легче понимать аналитические её части (в том числе и геометрию). А с "обычной" геометрией, как-то не сложилось подружиться.

EP>Так и я о том же


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

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

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

F>> Я и написал, что, как по мне — это (отсутствие стандартной КОМ) — куда более существенно, чем всё остальное.
EP>Это действительно проблема, нет даже единого стандарта вызова функций (точнее их много разных), не то что стандартных компонентов.
EP>Да, это важно. Но разработка кода, то что "внутри функций" — это тоже важно.
EP>Причём без стандартных компонентов ещё можно создавать программы, но без непосредственно возможности создавать код — ничего интересного вообще не получится.
Тут ты прав конечно. Но из-за того, что, в наше время — мы в 99.9% становимся потребителями чужого кода / библиотек — мне это видится важным. Хотя, это ортогонально к парадигмам. Собственно говоря почему так оно всё понятно. Просто грустно.

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

EP>>>Чистые где? Внутри или снаружи?
F>> Я ж написал тоже самое. Ялгоритм сортировки in-place.
EP>Так всё-таки, в твоём коде много каких чистых функций? У которых просто чистый интерфейс или и в реализации нет никакого мутирования?
Много и тех и других, как много и мутирующих (инфраструктура в основном, да и цель — состояние).
Но (по случайному совпадению) — сейчас ключевая функциональность сосредоточена там где вообще нет никакого мутирования.
А в другом небольшом проекте — логики считай вообще нет, одна инфраструктурщина, — и считай — везде одно состояние.

F>> Мне лень разбираться в хаскеле, очевидно, и так, что для реализации quicksort нужны как минимум массивы и мутации.
EP>Вот они и натягиваются на чистое ФП через через монады. При этом каждый последовательный statement это под капотом замыкание вложенное в замыкание предыдущего statement'а, которое в свою очередь вложено в в замыкание предыдущего, которое и т.п.
Т.е. ресурсы это может сожрать в один момент.

F>>При этом, всё же, стоит отметить, что это ущербность ЯП, а не декларативно-функционального подхода как такового.
EP>ФП это как раз про избегание явного мутирования, если же оно есть — то это отход от ФП.
Правильно. Я говорю о ЯП. Когда ЯП тебя ограничил, а тебе нужно именно так — получается взяли вилы (C/C++) в руки, накостыляли что нужно, и прибиндили чего-нибудь. Мне такой подход в ЯП (ограниченный) — решительно не нравится.


. . .

F>> Я помню как ночами рисовал фигню всякую — ничего там от математики точно нет.
EP>Это видимо не геометрия, а какое-нибудь черчение (начертательная геометрия) — но и там математики хоть отбавляй.
Она (начертательная). Ну математика есть везде, тут спорить смысла нет. Просто, мне казалось, её там и не так много (хотя может и забылось).

EP>Вот есть отрезок, на отрезке нужно построить равносторонний треугольник — например это можно сделать с помощью циркуля и линейки, воспользовавшись геометрическими свойствами.
Угу. Мне под математикой легче понимать аналитические её части (в том числе и геометрию). А с "обычной" геометрией, как-то не сложилось подружиться.

EP>Так и я о том же


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

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

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

F>> Я и написал, что, как по мне — это (отсутствие стандартной КОМ) — куда более существенно, чем всё остальное.
EP>Это действительно проблема, нет даже единого стандарта вызова функций (точнее их много разных), не то что стандартных компонентов.
EP>Да, это важно. Но разработка кода, то что "внутри функций" — это тоже важно.
EP>Причём без стандартных компонентов ещё можно создавать программы, но без непосредственно возможности создавать код — ничего интересного вообще не получится.
Тут ты прав конечно. Но из-за того, что, в наше время — мы в 99.9% становимся потребителями чужого кода / библиотек — мне это видится важным. Хотя, это ортогонально к парадигмам. Собственно говоря почему всё оно именно так — понятно. Просто грустно.