2014 dxdy logo

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

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




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


11/12/14
893
arseniiv в сообщении #1017289 писал(а):
(Но он мне не нравится из-за динамических типов, а не «грязноты».)


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

-- 19.05.2015, 18:42 --

arseniiv в сообщении #1017284 писал(а):
Не вышло, потому что разные результаты — у выполнения атрибута foo уже готового результата функции, а не у неё.


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

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


07/05/15

110
aa_dav в сообщении #1017285 писал(а):
там сперва дифирамбы поются немутабельности и чистоте


Там эти дифирамбы только в том контексте, что подстановочная модель легка для анализа. Никто не говорит там о ее мощности.
aa_dav в сообщении #1017285 писал(а):
Так а что мешает
Код:
func(f(arg),g(arg))


аргументы рассматривать за два шага сразу?
я не знаю, может в какой то конкретной реализации конечного автомата прохода по дереву чего то там Барендрегт критикует - но не вижу проблемы для произвольного.


то, что в формальной модели, ф-ция func "ждет" результатов вычисления f(arg), g(arg). А следующая ф-ция, будет ждать исполнения всего этого выражения. И т.д. Каждая ф-ция обязана возвращать результат вызову, она не может асинхронно отправить что-то куда-то стороннему шедуллеру, арбитру и пр.

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


11/12/14
893
nondeterminism в сообщении #1017305 писал(а):
то, что в формальной модели, ф-ция func "ждет" результатов вычисления f(arg), g(arg). А следующая ф-ция, будет ждать исполнения всего этого выражения. И т.д. Каждая ф-ция обязана возвращать результат вызову, она не может асинхронно отправить что-то куда-то стороннему шедуллеру, арбитру и пр.


пффф. ну так речь и идёт лишь о том, что в ФП усилены возможности к распараллеливанию, но они не безграничны естественно!
но в императивщине как раз вы не можете даже это расспараллелить:
Код:
func(f(arg),g(arg))

потому что нет никаких гарантий, что f и g не пересекаются. В императивном подходе вообще такой возможности нет!
а в ФП - есть. Сразу же. Если чистое.
Речь же не о том что всё возможно, а о том что появляются логичные и определенные возможности.
Но и естественно, что поток вычисления ограничен сразу же. И если вы перечитаете мой первый пост в теме, то заметите, что модель:
Код:
var (key, new_world) = input_key( world );

сразу же вовлекает что? =))))))
действительно обязательство передавать new_world в функции ниже сразу же "стягивает" поток вычисления конкретными узами.
т.е. попытка "имитировать стейт" приводит к тому, что.... возникают те же проблемы что у стейта!
логично?

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


07/05/15

110
aa_dav в сообщении #1017300 писал(а):
Мне он сильно не нравится из-за того что можно где то точечно в одном месте вот так залелезть в proto, а потом кто-то сопровождающий на другом конце вселенной будет искать "что же здесь происходит то вообще???".


Это происходит исключительно из-за непонимания семантики языка. Проблема в том, что большинство пишуших на нем, это вчерашние java/++ синие воротнички, мягко говоря, или фп-фанбои. В смоллтоке, руби, селфе, ио, луа, во всех "правильных" языках на это никто не жалуется. А все потому, что на этих языках программируют инженеры архитекторы, а не сброд.
Эта ситуация весьма негативно сказалась на JS. Он постепенно превращается в помойку, к сожалению. Адаптируется, так сказать, под массы.

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


11/12/14
893
P.S.
Т.е. если f и g у нас функции "имитирующие стейт", то мы уже не может написать:
Код:
func(f(world),g(world));

мы в соответствии с идиомой должны писать:
Код:
var (arg1,world1)=f(world);
var (arg2,world2)=g(world1);
func(arg1,arg2);

налицо "сцепленность результатов" и "важность порядка вычисления" и прочая.

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


07/05/15

110
aa_dav в сообщении #1017310 писал(а):
но в императивщине как раз вы не можете даже это расспараллелить:


Единственно возможная модель параллелизма -- это модель акторов, которая, внезапно, императивна, и на которой, внезапно, реализован параллелизм современных машин.

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


27/04/09
28128
nondeterminism в сообщении #1017298 писал(а):
Ровно то же самое и тут:
Давайте вы будете оформлять код на языке, подсветка синтаксиса которого поддерживается тегом syntax, тегом syntax? Тем более, он легко вставляется.

код: [ скачать ] [ спрятать ]
Используется синтаксис Javascript
Account = function() {}
Account.prototype = {
    balance: 0,
    deposit: function(amount) { this.balance += amount }
}

var account = new Account;

account.name = "this account"

deposit = function(amount, account) { account.deposit(amount); return account }

function something(account)
{
    return function() { return deposit(10, account); };
};

subfunc = something(account);

deposit(10, account);
console.log(subfunc())

console.log(subfunc());
deposit(10, account);

console.log(subfunc());

// ::: { name: 'this account', balance: 20 }
// ::: { name: 'this account', balance: 30 }
// ::: { name: 'this account', balance: 50 }


Так, тут много функций.
Account чистая, потому что вообще ничего не делает.
Account.prototype.deposit грязная, потому что присваивает this.
deposit потому тоже грязная.
something чистая.
subfunc грязная из-за deposit.

Не понял, какую именно тожесть вы имели в виду.

-- Вт май 19, 2015 20:04:57 --

nondeterminism в сообщении #1017321 писал(а):
Единственно возможная модель параллелизма -- это модель акторов, которая, внезапно, императивна, и на которой, внезапно, реализован параллелизм современных машин.
А языку по барабану, как там реализован его рантайм.

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


07/05/15

110
aa_dav в сообщении #1017320 писал(а):
налицо "сцепленность результатов" и "важность порядка вычисления" и прочая.


В ваших обеих примерах порядок вычислений есть. Его не будет только тут:
Код:

foo async(bar)
async(baz)
bar async(smth)


Это Ъ-параллельный код. Единственно возможный.

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


27/04/09
28128
aa_dav в сообщении #1017300 писал(а):
Так это сразу же и говорит что в данном контексте функция вернула мутабельную вещь, а значит всё это уже нечисто.
Хм, про чистоту значений вообще я особо не слышал, только значений-функций. Может, неспроста.

-- Вт май 19, 2015 20:12:22 --

aa_dav в сообщении #1017300 писал(а):
А то что динамические типы - так язык скриптовый же, для него более чем естественно.
Для такого языка трудно сделать вменяемую IDE, а это несомненный минус.

nondeterminism в сообщении #1017318 писал(а):
В смоллтоке, руби, селфе, ио, луа, во всех "правильных" языках на это никто не жалуется. А все потому, что на этих языках программируют инженеры архитекторы, а не сброд.
Эта ситуация весьма негативно сказалась на JS. Он постепенно превращается в помойку, к сожалению. Адаптируется, так сказать, под массы.
Он не мог бы так «адаптироваться» если бы не был устроен так «свободно». Известно, на любом языке можно написать write-only код, но не менее известно, что для этого надо приложить разные старания. Тут то же самое: в одном языке проще написать правильный код, чем в другом (в данном случае, в JS), и это не зависит от того, какими словами назван тот, кто на нём будет писать.

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


07/05/15

110
arseniiv в сообщении #1017322 писал(а):
А языку по барабану, как там реализован его рантайм.


говорим о семантике. Если семантика ЯП не позволяет, а сахар позволяет -- это другой вопрос. Я с этим не спорю. с этой точки зрения, параллелизм возможен вообще в любом языке.
arseniiv в сообщении #1017322 писал(а):
какую именно тожесть вы имели в виду.

Вы сказали, что функция sum чистая, несмотря на то, что объект, возвращаемый ей -- муттабелен. С функцией deposit -- ровно то же самое. Она всегда возвращает один и тот же объект, при одинаковых параметрах.

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


11/12/14
893
arseniiv в сообщении #1017325 писал(а):
Хм, про чистоту значений вообще я особо не слышал, только значений-функций. Может, неспроста.


Не не. Всё просто на самом деле. Не должно быть "side-effect"-ов.
Если в выражении
Код:
func(f(a),g(a))

ВСЁ чисто, то f и g можно запустить параллельно... А можно вообще не запускать до тех пор пока их результат не понадобится. В случае если не понадобится - незапуск не значит отказ логики программы. И прочая.
Как только появляются "сцепки" в виде глобальных переменных, ссылочных мутабельных параметров и т.п., это всё уже нечистота.

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


06/10/08
6422
nondeterminism в сообщении #1017282 писал(а):
Именно то, что там строго последовательная модель вычислений. Один шаг -- одна редукция.
Где Вы прочитали эту глупость? Суть как раз в том, что разные стратегии редукции приводят к одному и тому же результату, в частности, непересекающиеся редексы можно редуцировать параллельно.

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


27/04/09
28128
nondeterminism в сообщении #1017333 писал(а):
С функцией deposit -- ровно то же самое. Она всегда возвращает один и тот же объект, при одинаковых параметрах.
Импликацию развернули. Возвращает-то возвращает, но при этом ещё и меняет. А sum ничего не меняет, и именно потому она чистая.

-- Вт май 19, 2015 20:19:02 --

Вообще я не зря сослался на Disciple (жалко, проект на глазах не развивается). Если правильно обобщить чистоту, можно получить бонусы и от неё, и от мутабельности.

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


07/05/15

110
Xaositect в сообщении #1017336 писал(а):
Где Вы прочитали эту глупость?


В нескольких местах. В частности -- в фундаментальном -- Барендрегт" лямбда исчисление - его синтаксис и семантика"
Xaositect в сообщении #1017336 писал(а):
Суть как раз в том, что разные стратегии редукции приводят к одному и тому же результату, в частности, непересекающиеся редексы можно редуцировать параллельно.


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

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


20/08/14
11778
Россия, Москва
arseniiv в сообщении #1017322 писал(а):
something чистая.
Не понял, разве грязь не наследуется вверх по стеку вызовов? Как может быть чистой функция, вызывающая грязные методы и соответственно зависящая от побочных эффектов?!

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

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



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

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


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

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