2014 dxdy logo

Научный форум dxdy

Математика, Физика, Computer Science, Machine Learning, LaTeX, Механика и Техника, Химия,
Биология и Медицина, Экономика и Финансовая Математика, Гуманитарные науки




Начать новую тему Ответить на тему На страницу 1, 2, 3, 4, 5 ... 8  След.
 
 Слабость функциональной парадигмы
Сообщение18.05.2015, 12:14 


07/05/15

110
Сейчас много пиара ФП, оно и понятно, производителям компиляторов легче. Вместе с этим, рождается множество мифов, о том, например, что это "равноценная" ООП парадигма, и, даже, о том, что она мощней. Конечно, в частных случаях ФП годно, никто не спорит. Но диапазон задач, которые оно может решать весьма узко. Чем может быть полезен в проектировании язык, в котором нет абстракции состояния? Как я, к примеру, могу написать банковский счет? Банковский счет имеет состояние, не так ли?

Получается, что ФП бесполезно в подавляющем большинстве real задач, оно не годно для полноценного построения абстракций.

 Профиль  
                  
 
 Re: Слабость функциональной парадигмы
Сообщение18.05.2015, 12:28 
Заслуженный участник
Аватара пользователя


06/10/08
6422
Абстракция состояния обеспечивается монадой State. Берем тип "состояние банковского счета", делаем монаду "операция с банковским счетом". Все.

 Профиль  
                  
 
 Re: Слабость функциональной парадигмы
Сообщение18.05.2015, 13:16 


11/12/14
893
nondeterminism в сообщении #1016694 писал(а):
Чем может быть полезен в проектировании язык, в котором нет абстракции состояния? Как я, к примеру, могу написать банковский счет? Банковский счет имеет состояние, не так ли?


Простенький пример из этой серии - предположим мы хотим написать функцию реагирующую на нажатие клавиш. Допустим по "+" увеличивающую счётчик, по нажатию "-" уменьшающую счётчик и по нажатию на любую другую клавишу возвращающую итоговое значение. Очевидно, что нам нужна вспомогательная функция input_key, которая бы возвращала нажатую клавишу, но чистота функции не позволяет нам её оформить как int input_key() (в синтаксисе C), ибо разные значения функция может возвращать только если у неё разные входные параметры.
Делаем такой трюк - вводим в программу параметр world, который под собой подразумевает "состояние внешнего мира" и в частности он в себе как то инкапсулирует последовательность нажатий на клавиатуру (как тут уже неважно), тогда функцию input_key можно сделать совершенно чистой сделав её в таком виде (здесь что то джаваскриптное):
Код:
var (key, new_world) = input_key( world );

т.е. функция принимает world, а возвращает ПАРУ из считанной клавиши и нового состояния "мира" в котором эта клавиша уже считана и на очереди лежит другая.
тогда наша функция-считыватель может выглядеть так:
Код:
function input_counter( world )
{
     return input_count_implement( world, 0 );
};

function input_count_implement( world, counter )
{
    var (key, new_world ) = input_key( world );
    switch ( key )
    {
    case "+": return input_count_implement( new_world, counter+1 );
       break;
    case "-": return input_count_implement( new_world, counter-1 );
       break;
    else: return { counter, new_world };
    };
};

Т.е. что происходит - input_counter тоже по соглашению такого рода принимает в себя world и возвращает пару из результата и нового world.
Таким образом в программе таким образом написанной этот самый world надо "протаскивать" с самого верха до самого низа, который требует некоторого "стейта", при этом "нечистота" надёжно упрятана за фасадой вот этого world, который в принципе может быть реально просто списком заранее подготовленным, а может внутри быть реализован как считыватель из консоли - программе это уже становится неважно.
Такие дела.

 Профиль  
                  
 
 Re: Слабость функциональной парадигмы
Сообщение18.05.2015, 14:02 


07/05/15

110
aa_dav в сообщении #1016722 писал(а):
Делаем такой трюк - вводим в программу параметр world, который под собой подразумевает "состояние внешнего мира" и в частности он в себе как то инкапсулирует последовательность нажатий на клавиатуру (как тут уже неважно), тогда функцию input_key можно сделать совершенно чистой


А чем это отличается от того, если бы мы туда передавали объект, и возвращали бы новый объект? Это и есть монады чтоли? Выходит монады -- это обычные объекты?

 Профиль  
                  
 
 Re: Слабость функциональной парадигмы
Сообщение18.05.2015, 14:14 


11/12/14
893
nondeterminism в сообщении #1016739 писал(а):
А чем это отличается от того, если бы мы туда передавали объект, и возвращали бы новый объект?


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

nondeterminism в сообщении #1016739 писал(а):
Это и есть монады чтоли? Выходит монады -- это обычные объекты?


Я плохо дружу с этой терминологией, я не спец в ФП. Но да, это монады. Если не ошибаюсь в хаскеле это монада IO, т.е. ввод-вывод, ну или как то там оно тесно завязано.
В то же время что тут объект а что нет вопрос открытый. Вон тот же counter в конечном итоге свой "стейт" хранит опять таки лишь как аргумент в цепочке вызовов. Объект ли он? Ну в каком то смысле да, в каком то - нет.

 Профиль  
                  
 
 Re: Слабость функциональной парадигмы
Сообщение18.05.2015, 14:30 


07/05/15

110
aa_dav

Получается, что это чистая демагогия. Если мы возьмем язык, где все есть объект, у нас любой метод всегда берет объект, и возвращает объект, соответственно, все функции чисты по определению. LOL.

 Профиль  
                  
 
 Re: Слабость функциональной парадигмы
Сообщение18.05.2015, 14:37 


11/12/14
893
nondeterminism в сообщении #1016748 писал(а):
Получается, что это чистая демагогия. Если мы возьмем язык, где все есть объект, у нас любой метод всегда берет объект, и возвращает объект, соответственно, все функции чисты по определению. LOL.


Чистота в ФП выражается следующей фразой: результат, который возвращает функция зависит только от её параметров и вызов одинаковой комбинации параметров всегда должен возвращать один и тот же результат. В этом смысле чистые функции несомненно "stateless". Их легче отлаживать и прочая прочая прочая.
Как из "stateless" функций "приготовить" своеобразную имитацию стейтов - показано выше.
Вопрос тут не в том что функция что-то принимает и что-то возвращает, а в том что именно и как это что-то далее используется. =)

 Профиль  
                  
 
 Re: Слабость функциональной парадигмы
Сообщение18.05.2015, 14:54 


07/05/15

110
aa_dav в сообщении #1016751 писал(а):
результат, который возвращает функция зависит только от её параметров и вызов одинаковой комбинации параметров всегда должен возвращать один и тот же результат


Так оно и будет, за исключением, разве что случаев, когда мы сначала делаем myObject=<someObject here> а затем myObject=<anotherObject here>. Да и то еще вопрос. Наши функции манипулируют только объектами. Если не менять связи идентификаторов с объектами, так оно и будет.

 Профиль  
                  
 
 Re: Слабость функциональной парадигмы
Сообщение18.05.2015, 15:10 
Заслуженный участник


16/02/13
4195
Владивосток
nondeterminism, недопол. Вы тщитесь доказать, что возможности императивного программирования не уже функционального? Стоит ли трудиться?

-- 18.05.2015, 23:13 --

nondeterminism в сообщении #1016748 писал(а):
Получается, что это чистая демагогия
И таки ж да, вы действительно полагаете уместной столь явную демонстрацию своего плохого воспитания?

 Профиль  
                  
 
 Re: Слабость функциональной парадигмы
Сообщение18.05.2015, 15:44 
Заслуженный участник
Аватара пользователя


06/10/08
6422
nondeterminism в сообщении #1016739 писал(а):
А чем это отличается от того, если бы мы туда передавали объект, и возвращали бы новый объект? Это и есть монады чтоли? Выходит монады -- это обычные объекты?
Монады - это нечто более общее. Это конкретно монада State (точнее, IO, что то же самое, но вместо явно определенного типа состояния манипулирует некоторым "внешним миром", но суть та же)

nondeterminism в сообщении #1016748 писал(а):
Получается, что это чистая демагогия. Если мы возьмем язык, где все есть объект, у нас любой метод всегда берет объект, и возвращает объект, соответственно, все функции чисты по определению. LOL.
Проблема тут с тем, что инкапсуляция этому мешает. Допустим, у нас есть объект, например, random, который содержит изменяемое состояние и выдает нам псевдослучайные числа методом get. Проблема состоит в том, что на уровне синтаксиса мы не можем определить, одинаковы или различны значения объекта random - у него состояние инкапсулировано. Соответственно, если вызывать random.get(), он может выдать разные результаты на вроде бы одном и том же объекте (в том смысле, что средств различить random тремя строчками ранее и random тут у нас нет). Если у нас random иммутабельный и мы вызываем его как (result, new_random) = random.get(), то все нормально, это чистый интерфейс.

 Профиль  
                  
 
 Re: Слабость функциональной парадигмы
Сообщение18.05.2015, 16:48 


07/05/15

110
Xaositect в сообщении #1016786 писал(а):
Если у нас random иммутабельный и мы вызываем его как (result, new_random) = random.get(), то все нормально, это чистый интерфейс.


Ну, а если (new Random).get()?

 Профиль  
                  
 
 Re: Слабость функциональной парадигмы
Сообщение18.05.2015, 16:59 


11/12/14
893
nondeterminism в сообщении #1016805 писал(а):
Ну, а если (new Random).get()?


Ну так тут new есть просто функция возвращающая экземпляр Random.
Если она будет возвращать разные экземпляры (с разным seed) в зависимости от системного, например, таймера (внешний стейт), то это уже не чистая функция.

 Профиль  
                  
 
 Re: Слабость функциональной парадигмы
Сообщение18.05.2015, 17:22 
Заслуженный участник
Аватара пользователя


06/10/08
6422
nondeterminism в сообщении #1016805 писал(а):
Ну, а если (new Random).get()?
Тогда все замечательно. Но нет смысла - нам же нужны псевдослучайные числа.

 Профиль  
                  
 
 Re: Слабость функциональной парадигмы
Сообщение19.05.2015, 13:39 


07/05/15

110
aa_dav
Все ж таки, хотелось бы тогда определится. Что тут подразумевается под чистотой? Допустим, если я у вас взял, определенную сумму денег в долг, а затем вернул эту сумму, должны ли мы считать данную операцию нечистой по той причине, что я вам вернул другие купюры (другого номинала, года выпуска, etc). Или, скажем, являются ли программы (lambda(x) x) и (lambda(y) y) разными программами?

 Профиль  
                  
 
 Re: Слабость функциональной парадигмы
Сообщение19.05.2015, 14:42 


11/12/14
893
nondeterminism в сообщении #1017156 писал(а):
Все ж таки, хотелось бы тогда определится. Что тут подразумевается под чистотой?


Ну я же выше писал. Под чистотой в ФП понимают то, что результат функции зависит только от её параметров и при конкретной комбинации конкретных параметров функция всегда обязана вернуть одинаковый результат. Например функция без параметров может вернуть только одно и то же значение, фактически выступая в роли константы.
Никакого другого смысла тут нет, я не понимаю к чему ваши примеры про номиналы или равенство программ.

 Профиль  
                  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 106 ]  На страницу 1, 2, 3, 4, 5 ... 8  След.

Модераторы: Karan, Toucan, PAV, maxal, Супермодераторы



Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group