Здравствуйте, fddima, Вы писали:
EEP>>Вообще мой поинт в следующем: EP>>* В теле функций лучше всего себя показывает императивное программирование вкупе с некоторыми элементами характерными ФЯ — функции высшего порядка, лямбды/замыкания, и т.п. Добавление таких элементов не делает такой код функциональным — это всё тоже ИП с явным мутированием и итерациями. F> Тут неясно тогда что такое императивный подход.
Это изменение данных inplace, изменение состояния, последовательности действий. Типичный пример ИП — это quicksort (настоящий, тот который inplace).
F> Вот в Немерле — нет стэйтментов в привычном их понимании, и они — все выражения.
А это тут причём?
F>При этом хоть в ФЯ хоть в математике,
Что значит "в математике"? Императивное программирование это вполне себе математика.
F>тебе никто не мешает определить оператор ; который будет выполнять туже самую роль, что и в императивных языках.
Как? Через монады, bind'ы и трёхэтажные замыкания под капотом do-сахара? Как это отображается в современное насквозь императивное железо?
А главное зачем? То есть мы решили — "внутри функций будем использовать ИП" — и для этого выбираем изначально чужеродный этой концепции язык и начинаем наворачивать монадический код, вместо того чтобы взять/сделать язык со встроенным, удобным и быстрым ;
F>При этом, в C/C++ — есть оператор , который выполняет туже роль, что и ; — но для выражений. Дублирование на лицо.
Я не вижу причём тут expressions vs statements.
EP>>* Интерфейсы же лучше всего делать функциональными и как можно более чистыми. F> Интерфейс чего? Я не понял. И что значит функциональный интерфейс?
Интерфейс в смысле API. Функциональный интерфейс — это когда "снаружи" у нас функции, причём чистые настолько, насколько это целесообразно.
EP>>То есть по сути — ФП снаружи, ИП с элементами ФЯ внутри, а ООП где-то сбоку. F> Если тебе кажется что все парадигмы — это лишь названия и об одном и том же, — то с философской точки зрения — это так и есть.
В каком смысле?
F>К сожалению стандартной компонентной модели не существует, и весь этот ниндзя-стайл кодинг в C++ остаётся возможным только внутри модулей
Здравствуйте, fddima, Вы писали:
Q>>>Небольшие классы-команды никогда не будут более легко читаемы, чем лямбды или локальные функции, если им надо захватывать замыкаемый контекст в конструкторе, или наоборот вытаскивать модифицируемые поля/свойства наружу, чтобы внешний скоуп их использовал вместо локальных переменных (как это происходит в коде, генерируемом компилятором из лямбд). ARK>>По-моему, все как раз наоборот — они всегда будут более легко читаемы, чем огромные функции с лямбдами или вложенными функциями. F> Забавно, но у вас — всё наоборот. Вы хоть с кем-нибудь согласны?
Конечно согласен, например с пользователями Sinix и Tesh.
Хотя к чему этот вопрос был, не очень понятно. Считаете свою точку зрения единственно верной?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Это изменение данных inplace, изменение состояния, последовательности действий. Типичный пример ИП — это quicksort (настоящий, тот который inplace).
В моем коде это довольно редкое явление. Большая часть функций получается чистыми.
Лично я предпочитаю ООП для дизайна системы в целом, плюс ФП для реализации. Ну, тоже без абсолютизма. Там где удобен ИП или он дает большую производительность, использую его.
EP>Что значит "в математике"? Императивное программирование это вполне себе математика.
Математика вообще не подразумевает изменения переменных. Так что ты совсем не верно понимаешь математику.
EP>А главное зачем? То есть мы решили — "внутри функций будем использовать ИП" — и для этого выбираем изначально чужеродный этой концепции язык и начинаем наворачивать монадический код, вместо того чтобы взять/сделать язык со встроенным, удобным и быстрым ;
А, какой язык ты называешь чужеродным ИП?
EP>Интерфейс в смысле API. Функциональный интерфейс — это когда "снаружи" у нас функции, причём чистые настолько, насколько это целесообразно.
Какой-то мало реалистичный подход. Первая коллекция разрушит этот интерфейс. Вот ФП внутри методов — это реалистично и используется на практике повсюду. Даже в C#.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AlexRK, Вы писали:
ARK>Конечно согласен, например с пользователями Sinix и Tesh. ARK>Хотя к чему этот вопрос был, не очень понятно. Считаете свою точку зрения единственно верной?
Вовсе нет. Просто хотелось понять.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>* В теле функций лучше всего себя показывает императивное программирование вкупе с некоторыми элементами характерными ФЯ — функции высшего порядка, лямбды/замыкания, и т.п. Добавление таких элементов не делает такой код функциональным — это всё тоже ИП с явным мутированием и итерациями. F>> Тут неясно тогда что такое императивный подход. EP>Это изменение данных inplace, изменение состояния, последовательности действий. Типичный пример ИП — это quicksort (настоящий, тот который inplace).
Понятно. quicksort — это не сколько ИП, а сколько алгоритм сортировки in-place. При чём, он сам по себе отлично реализуется и в ФЯ.
Да, и, в моём коде, на C# — много методов, которые можно было бы назвать чистыми функциями. Но, чистые функции — сами по себе не самоцель.
EP>А это тут причём? F>>При этом хоть в ФЯ хоть в математике, EP>Что значит "в математике"? Императивное программирование это вполне себе математика. F>>тебе никто не мешает определить оператор ; который будет выполнять туже самую роль, что и в императивных языках. EP>Как? Через монады, bind'ы и трёхэтажные замыкания под капотом do-сахара? Как это отображается в современное насквозь императивное железо? EP>А главное зачем? То есть мы решили — "внутри функций будем использовать ИП" — и для этого выбираем изначально чужеродный этой концепции язык и начинаем наворачивать монадический код, вместо того чтобы взять/сделать язык со встроенным, удобным и быстрым ; F>>При этом, в C/C++ — есть оператор , который выполняет туже роль, что и ; — но для выражений. Дублирование на лицо. EP>Я не вижу причём тут expressions vs statements.
Сомневаюсь. Итерирования, как такового в математике пожалуй нет.
Зачем монады и bind-ы я не понял. Что мешает иметь оператор ; в ФЯ, ну кроме научных комплексов? Кроме того, гибридные ФЯ именно это и позволяют.
Expressions vs statements — к тому, что statements заставляют код выглядить "императивным", даже где это не нужно. Весь привычный flow-control, кроме goto — отлично представляется ввиде выражений. Более того, опять же — практика Scala и Nemerle — показывает, что это очень удобно.
EP>>>* Интерфейсы же лучше всего делать функциональными и как можно более чистыми. F>> Интерфейс чего? Я не понял. И что значит функциональный интерфейс? EP>Интерфейс в смысле API. Функциональный интерфейс — это когда "снаружи" у нас функции, причём чистые настолько, насколько это целесообразно.
Это уже закончилось прокачкой магических хэндлов в параметры любого API, от API OS до API библиотек. При этом большинство API — именно, что объектно-ориентировано. Но, если API OS — в общем случае обусловлено историческими реалиями — то современный софт явно требует другого.
EP>>>То есть по сути — ФП снаружи, ИП с элементами ФЯ внутри, а ООП где-то сбоку. F>> Если тебе кажется что все парадигмы — это лишь названия и об одном и том же, — то с философской точки зрения — это так и есть. EP>В каком смысле?
В том, что все парадигмы программирования — разные инструменты для достижения одной и той же цели. В итоге — это выполняется на конкретном железе с ожидаемыми "сайд-эффектами".
F>>К сожалению стандартной компонентной модели не существует, и весь этот ниндзя-стайл кодинг в C++ остаётся возможным только внутри модулей EP>Какой ещё "ниндзя-стайл"?
Шаблонная магия (навроде shared_ptr), которая доступна исключительно внутри модулей, но без неё нормальный API тоже не получается.
Здравствуйте, VladD2, Вы писали:
EP>>Это изменение данных inplace, изменение состояния, последовательности действий. Типичный пример ИП — это quicksort (настоящий, тот который inplace). VD>В моем коде это довольно редкое явление. Большая часть функций получается чистыми.
Они чистые внутри или снаружи? И если снаружи, то что именно ты тут понимаешь под чистотой? Например std::transform — это чистая или нет? Тут могут быть разные трактовки, поэтому я и говорю "как можно более чистыми".
— изменяемые, и предназначаются для не чистого кода, так?
VD>Лично я предпочитаю ООП для дизайна системы в целом, плюс ФП для реализации. Ну, тоже без абсолютизма. Там где удобен ИП или он дает большую производительность, использую его.
А что ты понимаешь под "ФП для реализации"? ИП + некоторые элементы характерные ФЯ? Или именно настоящие ФП без изменения данных?
EP>>Что значит "в математике"? Императивное программирование это вполне себе математика. VD>Математика вообще не подразумевает изменения переменных. Так что ты совсем не верно понимаешь математику.
С чего ты взял что математика не подразумевает изменения данных во времени? Это миф распространяемый евангелистами чистого ФП.
Машина Тьюринга — это вполне себе математика
EP>>А главное зачем? То есть мы решили — "внутри функций будем использовать ИП" — и для этого выбираем изначально чужеродный этой концепции язык и начинаем наворачивать монадический код, вместо того чтобы взять/сделать язык со встроенным, удобным и быстрым ; VD>А, какой язык ты называешь чужеродным ИП?
Например Haskell — ИП на нём делается через монады и трёхэтажные замыкания.
EP>>Интерфейс в смысле API. Функциональный интерфейс — это когда "снаружи" у нас функции, причём чистые настолько, насколько это целесообразно. VD>Какой-то мало реалистичный подход. Первая коллекция разрушит этот интерфейс.
Ты отвечаешь на моё пояснения к вот этой фразе:
EP>* Интерфейсы же лучше всего делать функциональными и как можно более чистыми.
То есть если не получается сделать функциональный — ОК, делаем контейнер или что там нужно.
VD>Вот ФП внутри методов — это реалистично и используется на практике повсюду. Даже в C#.
Это никакое не ФП, а просто некоторые элементы которые исторически характерны ФЯ, но ФП не определяющие. Против которых я кстати ничего против не имею, буквально чуть выше по ветке:
EP>То есть по сути — ФП снаружи, ИП с элементами ФЯ внутри, а ООП где-то сбоку.
Здравствуйте, fddima, Вы писали:
EP>>Это изменение данных inplace, изменение состояния, последовательности действий. Типичный пример ИП — это quicksort (настоящий, тот который inplace). F> Понятно. quicksort — это не сколько ИП, а сколько алгоритм сортировки in-place.
Суть настоящего quicksort именно в перестановке элементов in-place, это даже упоминал Erik Meijer в одном из своих видео по Haskell.
F>При чём, он сам по себе отлично реализуется и в ФЯ.
Как? Вот так? Через те самые монады и трёхэтажные замыкания?
F> Да, и, в моём коде, на C# — много методов, которые можно было бы назвать чистыми функциями. Но, чистые функции — сами по себе не самоцель.
Чистые где? Внутри или снаружи?
F>>>При этом, в C/C++ — есть оператор , который выполняет туже роль, что и ; — но для выражений. Дублирование на лицо. EP>>Я не вижу причём тут expressions vs statements. F> Сомневаюсь. Итерирования, как такового в математике пожалуй нет.
Есть. Итерирование, как и ИП в целом — чисто математическая концепция. Итерационные алгоритмы учат начиная с первых классов математики.
Другой пример — начала Евклида — книга по которой учат геометрию почти 2300 лет. В дословном переводе первые три постулата отличаются от того, как нас учат в школе "через две точки можно провести прямую ...". Например перевод Sir Thomas Heath:
Let the following be postulated:
1. To draw a straight line from any point to any point.
2. To produce a finite straight line continuously in a straight line.
3. To describe a circle with any centre and distance.
Это же императивные процедуры в чистом виде, которые изменяют глобальное состояние. Далее, на основе этих процедур строятся более крупные:
Proposition 1.
On a given finite straight line to construct an equilateral triangle.
F> Зачем монады и bind-ы я не понял. Что мешает иметь оператор ; в ФЯ, ну кроме научных комплексов? Кроме того, гибридные ФЯ именно это и позволяют.
В том-то и дело что это будет гибрид. Я как раз за гибридный подход, и против фанатизма типа "всё должно быть объектом", "всё должно быть чистым" и т.п.
F> Expressions vs statements — к тому, что statements заставляют код выглядить "императивным", даже где это не нужно. Весь привычный flow-control, кроме goto — отлично представляется ввиде выражений. Более того, опять же — практика Scala и Nemerle — показывает, что это очень удобно.
Я не спорю что это удобно. Тем не менее итерации с явным мутированием данных это ИП, даже если это сделало на expressions вместо statements
EP>>>>* Интерфейсы же лучше всего делать функциональными и как можно более чистыми. F>>> Интерфейс чего? Я не понял. И что значит функциональный интерфейс? EP>>Интерфейс в смысле API. Функциональный интерфейс — это когда "снаружи" у нас функции, причём чистые настолько, насколько это целесообразно. F> Это уже закончилось прокачкой магических хэндлов в параметры любого API, от API OS до API библиотек.
Я же прямым текстом сказал что ООП неплох в качестве поставщика типов для параметров функций.
EP>>>>То есть по сути — ФП снаружи, ИП с элементами ФЯ внутри, а ООП где-то сбоку. F>>> Если тебе кажется что все парадигмы — это лишь названия и об одном и том же, — то с философской точки зрения — это так и есть. EP>>В каком смысле? F> В том, что все парадигмы программирования — разные инструменты для достижения одной и той же цели.
А что из этого следует? Нужно свернуть все обсуждения преимуществ той или иной парадигмы так как цель-то у них одна?
F>В итоге — это выполняется на конкретном железе с ожидаемыми "сайд-эффектами".
Да, но например что-то более эффективно ложится на реалии современного железа, а что-то нет. Это крайне объективный показатель.
F>>>К сожалению стандартной компонентной модели не существует, и весь этот ниндзя-стайл кодинг в C++ остаётся возможным только внутри модулей EP>>Какой ещё "ниндзя-стайл"? F> Шаблонная магия (навроде shared_ptr), которая доступна исключительно внутри модулей, но без неё нормальный API тоже не получается.
Конкретные воплощения шаблонов можно экспортировать из динамических библиотек. Если нужно дать возможность пользователю инстанциировать шаблоны со своими типами — то нужно распространять код/headers.
Но только причём тут всё это? Я про C++, метапрограммирование и параметрический полиморфизм вроде ничего не говорил.
Да и те же Generics спокойно гуляют по .NET и JVM
Так, пожалуй надо закругляться (я изначально лишь задал уточняющие вопросы, часть которых ты и так уже уточнил, а мои фантазирования — пошли не в то русло). Поэтому, если будешь отвечать, то можно покороче.
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 проблем таких нет.
Я и написал, что, как по мне — это (отсутствие стандартной КОМ) — куда более существенно, чем всё остальное.
Здравствуйте, 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> Я и написал, что, как по мне — это (отсутствие стандартной КОМ) — куда более существенно, чем всё остальное.
Это действительно проблема, нет даже единого стандарта вызова функций (точнее их много разных), не то что стандартных компонентов.
Да, это важно. Но разработка кода, то что "внутри функций" — это тоже важно.
Причём без стандартных компонентов ещё можно создавать программы, но без непосредственно возможности создавать код — ничего интересного вообще не получится.
Здравствуйте, 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% становимся потребителями чужого кода / библиотек — мне это видится важным. Хотя, это ортогонально к парадигмам. Собственно говоря почему всё оно именно так — понятно. Просто грустно.
EP>>>А почему для лямбд это трудно, а для local functions нет? В чём разница? Лямбды завязаны на какое-то ABI jit'а? S>>Неа, потому что лямбды — это делегаты, их значение может меняться в рантайме. EP>В каком смысле? Что это даёт по сравнению с локальными функциями?
void Do(Action a)
{
a(); // вызываемый метод неизвестен при компиляции
}
Вперёд, оптимизируйте на здоровье
И не забыть про a.Target, a.BeginInvoke() etc.
Тут разве что .net native поможет, там всё как раз в один бинарник собирается. Но до оптимизации .net native руки дойдут ооочень не скоро. Как минимум не в следующем релизе.
S>>Локальные функции ничем не отличаются от вызова приватного метода, для них отдельных приседаний делать не надо. EP>Насколько я понял по форме отличий мало, отличаются реализации. Что мешает для старой формы сделать быструю реализацию?
Возможнось передать лямбду в чужой код.
EP>Тут просто часто говорят что лямбды в C# медленные, постоянные аллокации и т.п. — по сути стоит выбор между удобством и скоростью — я вот и не понимаю почему их не оптимизировать в компиляторе, чтобы не было такой дилеммы там где её быть не должно.
Вы их больше слушайте. Чтобы уткнуться в лямбды — надо оччень сильно постараться, причём писать код не включая мозг там будет обязательным условием. Тынц
Здравствуйте, Sinix, Вы писали:
S>Возможнось передать лямбду в чужой код.
А для замыкающей вложенной функции не предполагается передача в чужой код?
(Дайте мне просто вложенные функции как сахар для лямбд, а то придумали оптимизации-шмоптимзации.)
EP>>Тут просто часто говорят что лямбды в C# медленные, постоянные аллокации и т.п. — по сути стоит выбор между удобством и скоростью — я вот и не понимаю почему их не оптимизировать в компиляторе, чтобы не было такой дилеммы там где её быть не должно. S>Вы их больше слушайте. Чтобы уткнуться в лямбды — надо оччень сильно постараться, причём писать код не включая мозг там будет обязательным условием. Тынц
Здравствуйте, Qbit86, Вы писали:
S>>Возможнось передать лямбду в чужой код. Q>А для замыкающей вложенной функции не предполагается передача в чужой код?
Только как делегат
Q>(Дайте мне просто вложенные функции как сахар для лямбд, а то придумали оптимизации-шмоптимзации.)
Давайте с ломающими изменениями в какой-нибудь другой язык
EP>>>А создание лямбды дорогое? S>>2.31*108 calls per sec. Хватит? Q>В дотнетовском мемори-трафике, как обычно, всё-таки не так страшны аллокации, как сборка мусора.
Угу, при неправильном использовании вполне можно отхватить вот такое
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Вообще мой поинт в следующем: EP>* В теле функций лучше всего себя показывает императивное программирование вкупе с некоторыми элементами характерными ФЯ — функции высшего порядка, лямбды/замыкания, и т.п. Добавление таких элементов не делает такой код функциональным — это всё тоже ИП с явным мутированием и итерациями. EP>* Интерфейсы же лучше всего делать функциональными и как можно более чистыми.
Функциональные интерфейсы?
EP>* Функции имеют больший приоритет нежели методы объектов. Акцент нужно делать на "ООП это один из поставщиков типов для параметров функций и их реализаций", а не на "реализации методов объектов используют статические-методы-помощники" (на что в своё время сделала акцент Java).
EP>То есть по сути — ФП снаружи, ИП с элементами ФЯ внутри, а ООП где-то сбоку.
Теперь понятно, что смущает в твоих рассуждениях. Фактически ты одни ФП фишки низводишь до уровня некоторых элементов характерных ФЯ, а другие возносишь до уровня определяющего парадигму и дальше делаешь далеко идущие выводы. В принципе, так можно договориться до того, что ФП — это ООП, а ООП — это ФП, т.к., например, достаточно выдержать средствами ООП или императивщиной чистоту функции и вот у нас уже не ООП, а чистейший ФП.
Давай подойдём к впоросу с другой стороны. Любая парадигма сопровождается практическими подходами, набором паттернов и инструментов. Если разобраться где это всё рулит лучше всего, то окажется, что:
* Императив внутри метода, как я уже говорил, рулит только говнокодом. Бедность императивных конструкций и подходов можно наблюдать в том же C# до 3-й версии. Объём некоторого императивного кода на следующих версиях шарпа иногда сокращается в разы при использовании новых языковых конструкций.
* Настоящее счастье внутри метода достигается только использованием инструментов и подходов из функционального программирования.
* Компоновка методов в более крупные образования делается с помощью ООП. Им же достигается усоверщенствование некоторых функциональных вещей типа АДТ. Сравни АДТ и ПМ в F# и Немерле. В F# это выглядит как убогая пародия. Надеюсь ПМ в C# будет похож более на Немерле, чем на C#.
Здравствуйте, desco, Вы писали:
IT>>* Сравни АДТ и ПМ в F# и Немерле. В F# это выглядит как убогая пародия. D>А можно расписать по пунктам, в чем состоит убогость PM в F#?
АТД потенциально может быть довольно сложной структурой, например, такой как Expression Tree в .NET. Т.е. полноценной плоской иерархией классов со всеми блекжеками и шлюхами в виде наследования как базовой функциональности, так и данных. Ничего этого в F# нет. К тому же я не понял, что за косяк у них там с именованными полями. Получается, если я объявляю именованные поля, то должен всегда использовать имена, позиционирование не работает?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
EP>>* Интерфейсы же лучше всего делать функциональными и как можно более чистыми. IT>Функциональные интерфейсы?
Что смущает? У слова "интерфейс" более широкое значение нежели у "interface" в ООП
EP>>То есть по сути — ФП снаружи, ИП с элементами ФЯ внутри, а ООП где-то сбоку. IT>Теперь понятно, что смущает в твоих рассуждениях. Фактически ты одни ФП фишки низводишь до уровня некоторых элементов характерных ФЯ,
Каковыми они и являются. Отсутствие тех или иных фишек в языках которые называют функциональными, плюс присутствие таких фишек даже в старых императивных языках, как раз и говорит о том что эти фишки не определяющие для ФП.
IT>а другие возносишь до уровня определяющего парадигму и дальше делаешь далеко идущие выводы
Что поделать если они действительно определяют ФП. Да хотя бы посмотри определение ФП в той же wiki.
Мысли типа "я вот тут лямбду добавил и PM, теперь тело метода ФП!!11" — не более чем заблуждение. На что указывают даже евангелисты ФП:
K>Вообще, какие-то функциональные фишечки эпизодически используются почти везде. Но использование ПМ делает подход функциональным не в большей степени, чем использование иммутабельных строк, например. ФП — это комбинирование комбинаторов как основной способ решения задач программирования, а не "я тут как-то раз фильтр использовал вместо цикла".
IT>В принципе, так можно договориться до того, что ФП — это ООП, а ООП — это ФП, т.к., например, достаточно выдержать средствами ООП или императивщиной чистоту функции и вот у нас уже не ООП, а чистейший ФП.
Если ты сделаешь чистые функции без мутирования данных — то как раз и получишь ФП в чистом виде
IT>Давай подойдём к впоросу с другой стороны. Любая парадигма сопровождается практическими подходами, набором паттернов и инструментов.
Которые опираются на конкретные возможности языка. Есть ФП языки вообще без лямбд, и в которых естественно не может быть никаких практических подходов на этих самых лямбдах.
IT>Если разобраться где это всё рулит лучше всего, то окажется, что: IT>* Императив внутри метода, как я уже говорил, рулит только говнокодом.
Какая аргументация?
IT>Бедность императивных конструкций и подходов можно наблюдать в том же C# до 3-й версии.
C# это изначально бедный язык, причём в первых версиях копирующий другой бедный язык. Что тем не менее не что означает всё ИП бедное.
IT>* Настоящее счастье внутри метода достигается только использованием инструментов и подходов из функционального программирования.
Эпизодическое смешивание императивного кода с элементами характерными ФЯ, или даже с элементами определяющими ФП — не делают тела методов функциональными
IT>* Компоновка методов в более крупные образования делается с помощью ООП.
Во внутрь объектов имеет смысл "компоновать" только код который не может быть эффективно реализован через публичный интерфейс — остальное удобнее и даже лучше с точки зрения инкапсуляции делать как обычные внешние функции (которых так стесняются Java и C#).
В итоге получаем функции + классы. А компоновка происходит в namespace'ы и модули.
IT>Итого: ФП рулит внутри, ООП снаружи.
Да нет же. ИП приправленное щепоткой фишек ФЯ (по всей видимости это то о чём ты говоришь) не делает превращает его в ФП
IT>Правильные подходы и практики рулят везде.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
IT>>Функциональные интерфейсы? EP>Что смущает? У слова "интерфейс" более широкое значение нежели у "interface" в ООП
У детерминированности и отсутствии побочных эффектов тоже более широкое значение чем pure function в фукциональном программировании. Тем не менее тебе это не мешает делать вывод, что если функция удовлетворяет этим двум условиям, то мы однозначно имеем дело с ФП
IT>>Теперь понятно, что смущает в твоих рассуждениях. Фактически ты одни ФП фишки низводишь до уровня некоторых элементов характерных ФЯ, EP>Каковыми они и являются. Отсутствие тех или иных фишек в языках которые называют функциональными, плюс присутствие таких фишек даже в старых императивных языках, как раз и говорит о том что эти фишки не определяющие для ФП.
Тем не менее до недавнего времени они встречались только либо в ФЯ, либо в гибридах.
IT>>а другие возносишь до уровня определяющего парадигму и дальше делаешь далеко идущие выводы EP>Что поделать если они действительно определяют ФП. Да хотя бы посмотри определение ФП в той же wiki.
Под определение в вики подходит даже ассемблер.
EP>Мысли типа "я вот тут лямбду добавил и PM, теперь тело метода ФП!!11" — не более чем заблуждение. На что указывают даже евангелисты ФП:
Больших коньюнктурщиков чем всякого рода проповедников не существует. За последние 10 лет евангелисты ФП перекрасились уже во все цвета радуги. А ведь когда-то у них был один простой ответ на все вопросы про ФП — "Вы ничего не понимаете!". А теперь оказывается "функциональные фишечки эпизодически используются почти везде". А 10 лет назад почему они не использовались почти везде?
IT>>В принципе, так можно договориться до того, что ФП — это ООП, а ООП — это ФП, т.к., например, достаточно выдержать средствами ООП или императивщиной чистоту функции и вот у нас уже не ООП, а чистейший ФП. EP>Если ты сделаешь чистые функции без мутирования данных — то как раз и получишь ФП в чистом виде
А мужики-то и не знают. Оказывается я с самого первого дня писал в функциональном стиле. Особенно на Фортране и PL/1. Ага. Достаточно написать метод, который умножет два на три и вот уже оно ФП в полный рост.
IT>>* Императив внутри метода, как я уже говорил, рулит только говнокодом. EP>Какая аргументация?
Какая?
IT>>Бедность императивных конструкций и подходов можно наблюдать в том же C# до 3-й версии. EP>C# это изначально бедный язык, причём в первых версиях копирующий другой бедный язык. Что тем не менее не что означает всё ИП бедное.
Видимо у нас с тобой разное ИП. Богатого ИП я пока не видел. Разбавленное функциональными фишками видел. Богатое — не видел.
IT>>* Настоящее счастье внутри метода достигается только использованием инструментов и подходов из функционального программирования. EP>Эпизодическое смешивание императивного кода с элементами характерными ФЯ, или даже с элементами определяющими ФП — не делают тела методов функциональными
Но, как я понимаю выдерживание принципов ФП снаружи не взирая на любое ИП внутри легко делают методы функциональными?
EP>остальное удобнее и даже лучше с точки зрения инкапсуляции делать как обычные внешние функции (которых так стесняются Java и C#).
При чём здесь стесняются? Код традиционно удобнее компоновать в классы. В C# для того о чём ты говоришь существуют статические классы. Можешь их объявлять хоть по одному на каждую такую внешнюю функцию. Только какой в этом смысл?
IT>>Итого: ФП рулит внутри, ООП снаружи. EP>Да нет же. ИП приправленное щепоткой фишек ФЯ (по всей видимости это то о чём ты говоришь) не делает превращает его в ФП
Я нигде ни разу не сказал про превращения. Мне вообще больше всего импонирует смешанный стиль и возможность выбирать по месту по потребностям и не парить себе мозг бредом типа насколько мой код соответствует или не соответствует той или иной парадигме.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>>>Функциональные интерфейсы? EP>>Что смущает? У слова "интерфейс" более широкое значение нежели у "interface" в ООП IT>У детерминированности и отсутствии побочных эффектов тоже более широкое значение чем pure function в фукциональном программировании. Тем не менее тебе это не мешает делать вывод, что если функция удовлетворяет этим двум условиям, то мы однозначно имеем дело с ФП
У детерминированности и отсутствии побочных эффектов действительно более широкое значение чем у pure function. Тем не менее, когда наш код целиком состоит из pure functions — то да, мы имеем дело с ФП, как минимум с чем-то крайне близким к ФП — это следует из самого определения ФП.
IT>>>Теперь понятно, что смущает в твоих рассуждениях. Фактически ты одни ФП фишки низводишь до уровня некоторых элементов характерных ФЯ, EP>>Каковыми они и являются. Отсутствие тех или иных фишек в языках которые называют функциональными, плюс присутствие таких фишек даже в старых императивных языках, как раз и говорит о том что эти фишки не определяющие для ФП. IT>Тем не менее до недавнего времени они встречались только либо в ФЯ, либо в гибридах.
Лямбды-замыкания были в ООП-шном Smalltalk, а ФВП были даже в императивном C.
IT>>>а другие возносишь до уровня определяющего парадигму и дальше делаешь далеко идущие выводы EP>>Что поделать если они действительно определяют ФП. Да хотя бы посмотри определение ФП в той же wiki. IT>Под определение в вики подходит даже ассемблер.
Крайне ограниченное подмножество.
IT>>>В принципе, так можно договориться до того, что ФП — это ООП, а ООП — это ФП, т.к., например, достаточно выдержать средствами ООП или императивщиной чистоту функции и вот у нас уже не ООП, а чистейший ФП. EP>>Если ты сделаешь чистые функции без мутирования данных — то как раз и получишь ФП в чистом виде IT>А мужики-то и не знают. Оказывается я с самого первого дня писал в функциональном стиле. Особенно на Фортране и PL/1. Ага.
Если не было никакого явного мутирования данных (в чём я сомневаюсь), функции были чистыми — то да, это был функциональный стиль.
IT>Достаточно написать метод, который умножет два на три и вот уже оно ФП в полный рост.
А что смущает?
IT>>>* Императив внутри метода, как я уже говорил, рулит только говнокодом. EP>>Какая аргументация? IT>Какая?
Несколько раз повторяешь что ИП внутри метода плох. Хотелось бы услышать аргументы, так как по моим представлением именно ИП (пусть и разбавленный фишками исторически характерными скорее ФЯ) сейчас лучше всего подходит для тел функций.
IT>>>* Настоящее счастье внутри метода достигается только использованием инструментов и подходов из функционального программирования. EP>>Эпизодическое смешивание императивного кода с элементами характерными ФЯ, или даже с элементами определяющими ФП — не делают тела методов функциональными IT>Но, как я понимаю выдерживание принципов ФП снаружи не взирая на любое ИП внутри легко делают методы функциональными?
Думаю что нет — для полного ФП нужны и ФП интерфейсы и ФП внутренности.
IT>>>* Компоновка методов в более крупные образования делается с помощью ООП. EP>>Во внутрь объектов имеет смысл "компоновать" только код который не может быть эффективно реализован через публичный интерфейс — остальное удобнее и даже лучше с точки зрения инкапсуляции делать как обычные внешние функции (которых так стесняются Java и C#). EP>>В итоге получаем функции + классы. А компоновка происходит в namespace'ы и модули. EP>>остальное удобнее и даже лучше с точки зрения инкапсуляции делать как обычные внешние функции (которых так стесняются Java и C#). IT>При чём здесь стесняются? Код традиционно удобнее компоновать в классы.
А при том что компоновка это про модули и namespace'ы, а не про ООП и классы.
IT>В C# для того о чём ты говоришь существуют статические классы. Можешь их объявлять хоть по одному на каждую такую внешнюю функцию. Только какой в этом смысл?
Я как раз об этом и говорю, из-за своего врождённого стеснения функций, вместо "функций namespace'ов", получаются уродцы типа "статические методы статических классов namespace'ов" — Костыль Воркэраундович От того что namespace'ы по сути обозвали статическими классами — это не делает такую компоновку ООП-шной.
Кстати, эти статические классы ведь даже импортировать нельзя в C#
IT>>>Итого: ФП рулит внутри, ООП снаружи. EP>>Да нет же. ИП приправленное щепоткой фишек ФЯ (по всей видимости это то о чём ты говоришь) не делает превращает его в ФП IT>Я нигде ни разу не сказал про превращения.
Насколько я понял под "ФП рулит внутри" — ты понимаешь именно ИП приправленное щепоткой фишек ФЯ — так?
Или ты имеешь в виду именно "ФП внутри" в чистом "Haskell'овском" смысле?
IT>Мне вообще больше всего импонирует смешанный стиль и возможность выбирать по месту по потребностям и не парить себе мозг бредом типа насколько мой код соответствует или не соответствует той или иной парадигме.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
IT>>У детерминированности и отсутствии побочных эффектов тоже более широкое значение чем pure function в фукциональном программировании. Тем не менее тебе это не мешает делать вывод, что если функция удовлетворяет этим двум условиям, то мы однозначно имеем дело с ФП
EP>У детерминированности и отсутствии побочных эффектов действительно более широкое значение чем у pure function. Тем не менее, когда наш код целиком состоит из pure functions — то да, мы имеем дело с ФП, как минимум с чем-то крайне близким к ФП — это следует из самого определения ФП.
pure function накладывает ограничение на наблюдаемое извне поведение функции, а не на то, в какой парадгиме она написана внутри. Ровно поэтому "когда наш код целиком состоит из pure functions" — не гарантирует близости к ФП, т.к. тела функций могут быть 100% императивны.
Пример
int main()
{
// 1000 строк кода ЧИСТОГО императива, вычисляющего число корней уравнения f(x)=1, и возвращающая его.return n;
}
IT>>А мужики-то и не знают. Оказывается я с самого первого дня писал в функциональном стиле. Особенно на Фортране и PL/1. Ага.
EP>Если не было никакого явного мутирования данных (в чём я сомневаюсь), функции были чистыми — то да, это был функциональный стиль.
Чистота функций накладывает ограничение на наличие явного мутирования данных только в том случае, когда данные могут быть восприняты в качестве побочного эффекта.
IT>>Но, как я понимаю выдерживание принципов ФП снаружи не взирая на любое ИП внутри легко делают методы функциональными?
EP>Думаю что нет — для полного ФП нужны и ФП интерфейсы и ФП внутренности.
То есть выходит что разница между полным ФП и "чем-то крайне близким к ФП" во внутренностях? Выходит, что внутренности крайне незначительны? Какую ширину имеет эта крайняя близость?
Если нам не помогут, то мы тоже никого не пощадим.
От того что namespace'ы по сути обозвали статическими классами — это не делает такую компоновку ООП-шной.
