Ответ на »сообщение 2281« (AVC)
___________________________
Но типичная современная программа -- это система объектов, реагирующая на события и сохраняющая свое состояние между событиями.
Абсолютно тоже самое можно сказать и о функциональной программе.
Поражает просто как императивщики подряд одно и то же талдычат про ОТСУТСТВИЕ состояния в ФЯ.

Любую программу можно условно разбить на 4 части.
1. Данные (глобальные обьекты), которые хранят состояние. Неважно в памяти или в БД
2. Код реагирующий на события (events)
3. Код преобразующий данные.
4. Код сохраняющий изменения.

Разберем каждую часть и посмотрим как они представлены в ИЯ и в ФЯ

1. Данные - представлены практически одинаково в обоих случаях.
Это глобальные обьекты, в которых в течении длительного времени хранится состояние.
Здесь разницы никакой нет.

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

3. Код преобразующий данные
Здесь основное отличие ИЯ от ФЯ.
В ИЯ вы просто вызываете процедуру, которая имеет доступ к глобальным данным. Поэтоум передавать этой процедуре ничего не надо. В случае ООП роль такой процедуры играет метод глобального обьекта, который понятное дело имеет доступ к полям обьекта через указатель this. А потому ему ничего передавать не надо.

MyObject.DoSomething

В ФЯ чистые функции не имеют доступа к изменяемым данным, а потому эти данные надо передавать им явно.
То есть

MyObject <- DoSomething(MyObject);

Как видите чистая функция не только не имеет доступа к изменяемым данным, но и не может ничего наружу записать. Может только вернуть результат.
Уже снаружи этой функции происходит запись данных в переменную. То есть императивная операция.
Отсюда разница в 4-й части. Код сохраняющий изменения.

В ИЯ 4-я и 3-я часть совмещены внутри процедуры преобразовывающей данные. Одна и та же процедура преоборазовывает данные и их же сохраняет.

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

Типичный код ИЯ выглядит вот так:

Реакция на событие -> Процедура Преобразования Данных (Сохранение данных)

В ФЯ:

Реакция на событие -> Чтение данных и передача их функции преобразования -> Возврат новых данных из Функции преобразования -> Замена старых данных на новые.

Почему это должно быть настолько принципиально трудным для императивщиков остается для меня непонятным.

Чем отличается
myObject.DOSomething
от
myObject <- DoSomething(MyObject)

В плане сложности реализации ?

Ответ на »сообщение 2278« (Владимир Лось)
___________________________

>>>Вы стремитесь к максимальной обобщённости описания? Всё равно вы придёте к ФП! :о)

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

Ответ на »сообщение 2277« (Jack Of Shadows)
___________________________

>>>Где ЗАПРЕТИТЬ спрашиваю ?

В принципе, можно и запретить.
К примеру, в Аде функции не могут иметь побочных эффектов.

Ответ на »сообщение 2278« (Владимир Лось)
___________________________

Ответ на »сообщение 2276« (Илья Ермаков)
Вы стремитесь к максимальной обобщённости описания? Всё равно вы придёте к ФП! :о)
Я понимаю, что Вы имеете в виду. Естественно, в обобщенных, продуманных описаниях алгоримтов стиль кодирования приближается к ФП. К ФП в смысле чистоты функций, уходу от обильного "жонглирования" с переменными, активного использования рекурсии.
Но не обязательно к ФП в смысле перечисленных чуть ранее "наворотов" :-) Я подозрительно отношусь к усложнениям инструмента. STL вот, например, тоже позиционируется как "обобщенная, декларативная, математичная". В итоге имеем столько проблем в стиле обильных талмудов про то, что "вот этого лучше не делать, а это надо делать так, а вот если вы забудете про это, то..", что ну ее нафиг, такую обобщенность и гибкость :-) Простой и строгий "скелет" дороже...

Ответ на »сообщение 2276« (Илья Ермаков)
___________________________
А почему не может быть столь же естественным итерационное описание последовательности действий/событий? "Функционально=императивный дуализм", так сказать...
Потому, что цикл изначально - лишь отображение одного из аспектов задачи (из предметки) на средство реализации (архитектура проца). А, в ходе решения, вы опять вынуждены громоздить "переход" на сущности предметки, но уже средствами "не знакомыми" с рекурсивностью.
Вы стремитесь к максимальной обобщённости описания? Всё равно вы придёте к ФП! :о)

Ответ на »сообщение 2275« (Илья Ермаков)
___________________________
Не используя глобальные переменные и внутреннее состояние объектов...
И где здесь ЗАПРЕТИТЬ ?!
Не я понял, конечно - посоветовать там, правильно проектировать :))
Где ЗАПРЕТИТЬ спрашиваю ?

Ответ на »сообщение 2272« (Владимир Лось)
___________________________

Ответ на »сообщение 2270« (Илья Ермаков)
___________________________
Циклы, в принципе, явно никак не ограждают от "побочных эхвектов". Более того, их, сосбтвенно, для этих эффектов и организуют... Они (циклы) - частное выражение, средствами имеющейся архитектуры, рекурсивных (по самой своей природе и изначальному естеству) определений процессов и отношений.
Владимир, а не слишком ли категоричное утверждение?
А почему не может быть столь же естественным итерационное описание последовательности действий/событий? "Функционально=императивный дуализм", так сказать...

Ответ на »сообщение 2271« (Jack Of Shadows)
___________________________

Ответ на »сообщение 2270« (Илья Ермаков)
___________________________
А с какого, пардон, перепоя вместе с запрещением побочных эффектов нужно запрещать циклы?
Ну нельзя быть наполовину беременным :))
Как вы запретите побочные эффекты у функций, оставив при это оператор присваивания (а с ним и циклы) ?

Не используя глобальные переменные и внутреннее состояние объектов...

Ответ на »сообщение 2270« (Илья Ермаков)
___________________________

А с какого, пардон, перепоя вместе с запрещением побочных эффектов нужно запрещать циклы?
Функция может не иметь побочных эффектов, а у ж на чем она там внутри - это всем глубоко параллельно...

Ну уж извините! Хотите ФП - извольте отказаться от побочных эффектов и циклов, которые невозможны без этих самых побочных эффектов, пусть даже и локализованных внутри отдельных процедур.

Как только Вы ступаете на тонкий лёд побочности, Вы теряете твёрдую основу чистого ФП...

Вот и получается, что (чистое) ФП противоречит самому духу Оберонов...

Ответ на »сообщение 2265« (info21)
___________________________

А как же по-Вашему x86 реализует вычисление функции Аккермана?

Известно как - с помощью рекурсии.