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
4214
Владивосток
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, Супермодераторы



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

Сейчас этот форум просматривают: Someone


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

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