Re[129]: Есть ли вещи, которые вы прницпиально не понимаете... - Философия программирования

Здравствуйте, Ikemefula, Вы писали:

I>Иммутабельность позволяет реализовать детерминизм. Без иммутабельности его нет и быть не может.

Что за бред? ) Уже несколько раз тут говорилось, что если мы модицифицируем объект, передаваемый в качестве параметра в функцию, между двумя вызовами этой функции, то это просто равносильно вызовам этой нашей функции с РАЗНЫМИ параметрами. И соответственно будут возвращаться разные результаты, как и положено. И это совершенно детерминировано.

I>Вот есть у нас обычная функция memoize, возвращает кеширующую функцию для своего параметра.
I>Теперь фокус
I>

I>var f = (A a) => return a.x; // по твоей логике это чистая функция
I>var f1 = memoize(f);
I>var a = new A();

I>f1(a); //вычисляем
I>f1(a); //возвращаем кешированое значение
I>a.mutate(); // модифицируем
I>f1(a); // ОПАНЬКИ ! получаем отстой в силу отсутствия детерминизма
I>

I>Парадокс — чистая функция не может быть мемоизирована.
I>Отсюда ясно, почему нужен детерминизм.

D. Mon уже подробно ответил на это выше. Детерминизм есть, это очевидно.

Здравствуйте, AlexRK, Вы писали:

ARK>Такие функции чистыми называть нельзя, ИМХО. Вопрос терминологии — что понимать под "чистыми функциями". Я всегда считал это эквивалентностью ссылочной прозрачности и для меня стало большой неожиданностью, что Брайт сделал такую кривизну в весьма грамотно спроектированном языке.

Я думаю это сделано для того, чтобы использовать pure не столько для оптимизации, сколько для уменьшения ошибок в кодирование. По типу того же const, только более сильного.

Здравствуйте, D. Mon, Вы писали:

DM>Не, если содержимое а изменилось, то новое значение не будет равно старому (хоть адрес и тот же), f1 пересчитает заново, все ок.
DM>Но вот если меняется не содержимое а, а один из объектов, на которые а ссылается, тогда оппа.
DM>Вот с иммутабельным а было бы все ок.

Не, если у A определён правильный оператор сравнения, то должно корректно работать в любом случае.

Здравствуйте, AlexRK, Вы писали:

ARK>Термин "побочный эффект" — неформальный. Нагрев процессора или своп на диск — это побочный эффект?
ARK>Вот referential transparency — другое дело, тут все однозначно.

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

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, Ikemefula, Вы писали:

I>>Иммутабельность позволяет реализовать детерминизм. Без иммутабельности его нет и быть не может.

_>Что за бред? ) Уже несколько раз тут говорилось, что если мы модицифицируем объект, передаваемый в качестве параметра в функцию, между двумя вызовами этой функции, то это просто равносильно вызовам этой нашей функции с РАЗНЫМИ параметрами.

Это равносильно исключительно для объектов-значений. А как быть со ссылочными структурами ?

I>>Вот есть у нас обычная функция memoize, возвращает кеширующую функцию для своего параметра.
I>>Теперь фокус
I>>

I>>f1(a); // ОПАНЬКИ ! получаем отстой в силу отсутствия детерминизма
I>>

I>>Парадокс — чистая функция не может быть мемоизирована.
I>>Отсюда ясно, почему нужен детерминизм.

_>D. Mon уже подробно ответил на это выше. Детерминизм есть, это очевидно.

Нет в примере никакого детерминизма. Вот простой пример — A состоит исключительно из ссылок на другие объекты, то, вообще говоря, не ясно, где границы этого того объекта что в параметре пришел. Более того, не ясно, как именно делать кеширование.

Теперь обратный фокус- делаем структуру значением или просто иммутабельной. Внезапно оказывается так, что не надо думать, что же считать тем самым объектом и совершенно не важно, из чего он состоит. А для кеширования, внезапно, достаточно всего лишь Identity.

Здравствуйте, alex_public, Вы писали:

_>D. Mon уже подробно ответил на это выше. Детерминизм есть, это очевидно.

Мне кажется ты в любом тексте стараешься вычитать только то, что тебе нравится. Цитирую:

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

Как видишь, здесь указывается разница между мутабельной и иммутабельной структурой. То есть, "оппа" и означает что нет никакого детерминизма.

Здравствуйте, alex_public, Вы писали:

DM>>Но вот если меняется не содержимое а, а один из объектов, на которые а ссылается, тогда оппа.
DM>>Вот с иммутабельным а было бы все ок.

_>Не, если у A определён правильный оператор сравнения, то должно корректно работать в любом случае.

Перевожу — ты стесняешься, но хочешь сказать, что А должен вести себя как значение. Для развесистых структур, навроде деревьев, это утопия — придется сранивать практически все внутренние и внешние свойства на всю глубину вложенности.

Теперь осталось совсем немного. Представь себе, А кладется в кеш не только при мемоизации, а везде где это надо. Поскольку экземпляр А ведет себя как значение, то его не получится достать из кеша. Опаньки ! То есть, после модифицирования А кеш смысла не имеет. Более того — удалить из кеша по ключу так же не выйдет. Опаньки !

Подозреваю, проблему выше ты захочешь решить с помощью уникального идентификатора специально для таких кешей. То есть, объект-значение должен обладать еще и Identity. В общем случае это не решает проблему(оппа!), но в частных — поможет.
И вот у тебя для одного и того же класса понадобилось целых два оператора сравнения. Это, в кратце, означает, что вызывающий код должен быть в курсе того, как устроен объект А.

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

Здравствуйте, alex_public, Вы писали:

K>>Ну я и говорю: тут без метапрограммирования, как правило, не обойтись.
_>Это только в случае C++, потому как у него обобщённое программирование реализовано через метапрограммирование (что мы и обсуждали здесь). А во многих других языках достаточно именно просто обобщённое программирования

Сильно сомневаюсь. Точнее, какие-то вырожденные случаи ООП-паттернов проектирования может на одном параметрическом полиморфизме и можно реализовать, но вряд ли что-то нетривиальное. В вашем примере метапрограммирование присутствует. Если будете искать другие примеры на C#, имейте в виду, что констрейнт new тоже не "просто обобщённое программирование", а сахар для Activator.CreateInstance со всеми вытекающими.

_>Это про математику и теорию категорий в частности? ) Ну так можно мне увидеть какой-нибудь профессиональный инструмент для проектирования архитектуры ПО, основанный на этом? )

А, вы имеете в виду софт для архитекторов вроде IBM-овского? Нет, такого, конечно, нет.

_>Нет, это как раз добавление возможности. А ограничением будет требование иметь в коде только pure функции.

С какой стати это ограничение, если все, что можно сделать в императивном языке можно делать и одними только чистыми (причем по построению) функциями? Ограниченным будет как раз язык, в котором полноценными функциями, о которых можно рассуждать и которые можно оптимизировать являются не все.

_>Я же уже вроде несколько раз объяснял. Ну могу ещё раз, на примере той же самой чистоты:
_>- в C++: нет возможности, нет ограничений
_>- в D: есть возможность, нет ограничений

А возможность точно есть? А то вы их пока не продемонстрировали. Да и судя по тому, что здесь написано, никакой системы контроля за эффектами в D и нет.

_>- в Haskell: есть возможность, есть ограничения (все функции должны быть такие).

Под ограничениями, я так понял, все еще имеется в виду небольшой синтаксический шум, компенсируемый отсутствием шума в других местах?

_>Насколько я помню, в том примере лишние копирования устранял не сам оптимизатор, а библиотечный код.

Что значит не сам оптимизатор, а код? Ну да, для того, чтоб что-то оптимизировалось нужен оптимизатор и код, который этот оптимизатор может оптимизировать.

_>Думаю, что на D такое тоже без проблем организуется.

Реализуется или реализовано?

_>Но фокус в том, что оно там не нужно!

А, понятно. Т.е. поддержкой чего-то в языке опять называется отсутствие потребности в такой колбасе. Чего-то такого я и ожидал.

_>Ведь о чём мы собственно говорили тогда? О типичном не чистом коде, работающем с неконстантными данными (это если мы говорим про эффективную реализацию). И именно из-за этого у нас были сложности с записью подобного на Хаскеле.

Какие еще сложности?

_>Ну так а на D мы можем записать это прямо в явном виде, без всяких дополнительных ухищрений. У нас же здесь нет ограничения (!) в виде обязательной чистоты всего кода. И при этом никто нам не мешает использовать в соседнем коде чистые функции, пользуюсь всеми бонусами от них.

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

_>Только что-то основной расцвет подобных языков наблюдается как раз сейчас, в 21-ом веке... )

Что же в этом хорошего?

_>Причём чем проще, тем популярнее. Мой любимый простенький Питончик на фоне остальных является ещё довольно серьёзным и сложным. ))) А если мы возьмём какой-нибудь JavaScript, который пролез уже и на серверы (node.js) и в десктоп (metro api win8)...

Это питон-то с яваскриптом со всеми их фокусами — простые языки? Не смешите.

_>На мой взгляд, задавать на подобном форуме вопросы, имеющие ответы в википедии или школьных учебниках — это как раз троллизм и есть. ))) Ну если есть желание говорить на таком уровне, то пожалуйста:

_>http://en.wikipedia.org/wiki/C%2B%2B хотя тут забыли метапрограммирование,
_>http://en.wikipedia.org/wiki/Python_%28programming_language%29 а здесь забыли АОП.

Смотрим С++:

procedural, functional, object-oriented, generic

"процедурная" парадигма вообще никакого инструментария для написания хоть сколько-нибудь нетривиальных программ не дает и является красивым названием для "ничего нет". Функциональная парадигма, как мы выяснили в соседних ветках, в C++ не поддерживается. Обобщенное программирование парадигмой не является — это просто базворд для обозначаения средств для нормального типизирования ФП и ООП кода в языках, где таких средств изначально не было. Метапрограммирование также парадигмой не является. Таким образом, имеем поддержку ООП и необоснованные заявления о поддержке ФП — вот и вся мультипарадигменность.

Смотрим питон: object-oriented, imperative, functional, procedural, reflective
Про процедурное уже сказано, object-oriented и imperative — это, фактически, одно и то же, ФП в питоне поддерживается на игрушечном уровне, хоть и не так плохо как в C++, reflective — очередное выдавание фичи за парадигму.

Вообще, выдаванием фичь за парадигмы, либо просто высасыванием парадигм из пальца как здесь, можно обосновать мультипарадигменность любого языка программирования.

Здравствуйте, alex_public, Вы писали:

K>>Это просто достаточно компактный пример, демонстрирующий полиморфную рекурсию, а не какую-то бессмысленную "защиту".

_>Это точное решение конкретной задачки в полном соответствие с её изначальной формулировкой автором: http://www.linux.org.ru/forum/development/4300872. Причём показанное мною простейшее решение на C++ ещё и короче, эффективнее и функциональнее вариантов, предложенных на других языках.

Что там изначально формулировал какой-то там автор, в данном случае значения не имеет. Я сослался на пример, как демонстрацию конкретной фичи, которая в хаскеле, яве, сишарпе (и, скорее всего, хотя проверять мне лень, окамле) есть, и которой в С++ (и, насколько я знаю, хотя проверять опять таки лень — в Аде и SML без расширений) наоборот нет. Исключительно как пример того, что полиморфизм в C#/Java хотя и убогий — по возможностям подмножеством плюсового не является.

Здравствуйте, Klapaucius, Вы писали:

_>>Причём чем проще, тем популярнее. Мой любимый простенький Питончик на фоне остальных является ещё довольно серьёзным и сложным. ))) А если мы возьмём какой-нибудь JavaScript, который пролез уже и на серверы (node.js) и в десктоп (metro api win8)...

K>Это питон-то с яваскриптом со всеми их фокусами — простые языки? Не смешите.

Они на самом деле простые. Хаскель и С++ на порядок-другой сложнее. Скажем Питон я изучил даже не отвлекаясь на чтение мануалов. Увидел код, полез править и как то все само пошло. По моим наблюдением Питон большей частью так и изучают.
А вот Хаскель очень непростой язык. Большинство тех, кто пишут на питоне и джаваскрипте даже генераторы из хаскеля воспринимают с большим скрипом.

Здравствуйте, Ikemefula, Вы писали:

I>Перевожу — ты стесняешься, но хочешь сказать, что А должен вести себя как значение. Для развесистых структур, навроде деревьев, это утопия — придется сранивать практически все внутренние и внешние свойства на всю глубину вложенности.

I>Теперь осталось совсем немного. Представь себе, А кладется в кеш не только при мемоизации, а везде где это надо. Поскольку экземпляр А ведет себя как значение, то его не получится достать из кеша. Опаньки ! То есть, после модифицирования А кеш смысла не имеет. Более того — удалить из кеша по ключу так же не выйдет. Опаньки !

I>Подозреваю, проблему выше ты захочешь решить с помощью уникального идентификатора специально для таких кешей. То есть, объект-значение должен обладать еще и Identity. В общем случае это не решает проблему(оппа!), но в частных — поможет.
I>И вот у тебя для одного и того же класса понадобилось целых два оператора сравнения. Это, в кратце, означает, что вызывающий код должен быть в курсе того, как устроен объект А.

Что за ерунда? ) Как ты вообще собираешься производить кэширование объектов не имеющих корректных операторов сравнения? Посмотри хотя бы тривиальные требования в том же std::map. А если такой оператор есть, то в чём тогда проблема? И никаких двух версий естественно не требуется.

I>А теперь, на секундочку, предположим, что детерминизм у нас самый что ни есть православный — а именно на иммутабельных структурах.
I>Внезапно оказывается, что нужен всего один оператор сравнения и нет никаких проблем с кешем, вообще, и нет нужды сравнивать все свойства на всю глубину.

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

Здравствуйте, Klapaucius, Вы писали:

K>А, вы имеете в виду софт для архитекторов вроде IBM-овского? Нет, такого, конечно, нет.

Ну не обязательно сразу прямо таких монстров вспоминать. Есть множество инструментов полегче. Для начала хотелось бы увидеть какой-то аналог того же UML (а вот для него имеются уже тысячи готовых инструментов любого уровня монструозности) для разработки, которую предполагается вести с помощью чистого функционального языка. Бывает же очень удобно набросать соответствующие диаграммки при продумывание архитектуры нового приложения. А что у нас служит заменой этого при работе в функциональной парадигме? )

K>С какой стати это ограничение, если все, что можно сделать в императивном языке можно делать и одними только чистыми (причем по построению) функциями? Ограниченным будет как раз язык, в котором полноценными функциями, о которых можно рассуждать и которые можно оптимизировать являются не все.

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

Собственно тезис выше в чём-то аналогичен общеизвестному из императивного мира. "На ассемблере без проблем можно написать абсолютно любой софт." Вопрос в том удобно ли это...

K>А возможность точно есть? А то вы их пока не продемонстрировали. Да и судя по тому, что здесь написано, никакой системы контроля за эффектами в D и нет.

А что собственно демонстрировать? ) Есть определённые критерии для чистых функций в D и гарантии компилятора на их исполнение. Надо показать, что компилятор работает без ошибок что ли? )))

K>Под ограничениями, я так понял, все еще имеется в виду небольшой синтаксический шум, компенсируемый отсутствием шума в других местах?

Главный нюанс в том, что этот "небольшой" шум на самом деле не нужен, если позволить иметь в языке несколько парадигм. Что и демонстрирует D.

K>А, понятно. Т.е. поддержкой чего-то в языке опять называется отсутствие потребности в такой колбасе. Чего-то такого я и ожидал.

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

K>Какие еще сложности?

На Хаскеле у нас было два вида решения той задачки:
— красивый, но не эффективный
— более эффективный, но с кучей лишнего мусорного кода

А на любом языке, разрешающем нечистые функции (т.е. практически на всех языках) это можно записать и красиво и эффективно.

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

Как только на Хаскеле можно будет спокойно использовать нечистые функции, я с этим полностью соглашусь. )))

_>>Только что-то основной расцвет подобных языков наблюдается как раз сейчас, в 21-ом веке... )
K>Что же в этом хорошего?

Насчёт хорошего — это сложный вопрос... Но в любом случае это полностью опровергает ваши предыдущие слова об эпохах и типизациях... )

K>Это питон-то с яваскриптом со всеми их фокусами — простые языки? Не смешите.

В Питоне много возможностей за счёт мультипарадигменности, но в своей основе он весьма прост. Я бы сказал, что это идеальный язык для освоение программирования неспециалистами.

JS же вообще очень маленький и простенький язык. Правда в нём при этом уместилось множество неоднозначностей (типа C++ UB), но к сложности языка это вообще никакого отношения не имеет.

K>Смотрим С++:

K>procedural, functional, object-oriented, generic

K>"процедурная" парадигма вообще никакого инструментария для написания хоть сколько-нибудь нетривиальных программ не дает и является красивым названием для "ничего нет". Функциональная парадигма, как мы выяснили в соседних ветках, в C++ не поддерживается. Обобщенное программирование парадигмой не является — это просто базворд для обозначаения средств для нормального типизирования ФП и ООП кода в языках, где таких средств изначально не было. Метапрограммирование также парадигмой не является. Таким образом, имеем поддержку ООП и необоснованные заявления о поддержке ФП — вот и вся мультипарадигменность.

K>Смотрим питон: object-oriented, imperative, functional, procedural, reflective
K>Про процедурное уже сказано, object-oriented и imperative — это, фактически, одно и то же, ФП в питоне поддерживается на игрушечном уровне, хоть и не так плохо как в C++, reflective — очередное выдавание фичи за парадигму.

K>Вообще, выдаванием фичь за парадигмы, либо просто высасыванием парадигм из пальца как здесь, можно обосновать мультипарадигменность любого языка программирования.

Хыхы, ну так если там всё так неверно, то может подредактируете данные статьи в википедии до верного состояния?

Здравствуйте, Klapaucius, Вы писали:

K>Что там изначально формулировал какой-то там автор, в данном случае значения не имеет. Я сослался на пример, как демонстрацию конкретной фичи, которая в хаскеле, яве, сишарпе (и, скорее всего, хотя проверять мне лень, окамле) есть, и которой в С++ (и, насколько я знаю, хотя проверять опять таки лень — в Аде и SML без расширений) наоборот нет. Исключительно как пример того, что полиморфизм в C#/Java хотя и убогий — по возможностям подмножеством плюсового не является.

Что за фича? )

Здравствуйте, alex_public, Вы писали:

I>>Подозреваю, проблему выше ты захочешь решить с помощью уникального идентификатора специально для таких кешей. То есть, объект-значение должен обладать еще и Identity. В общем случае это не решает проблему(оппа!), но в частных — поможет.
I>>И вот у тебя для одного и того же класса понадобилось целых два оператора сравнения. Это, в кратце, означает, что вызывающий код должен быть в курсе того, как устроен объект А.

_>Что за ерунда? ) Как ты вообще собираешься производить кэширование объектов не имеющих корректных операторов сравнения?

Не я, а ты. Это ведь ты хочешь иметь мутабельные объекты-значения в то время, как во всех языках без исключения объекты значения стараются делать иммутабельными, хоть джаваскрипте, хоть в С#, хоть Java.

>Посмотри хотя бы тривиальные требования в том же std::map. А если такой оператор есть, то в чём тогда проблема? И никаких двух версий естественно не требуется.

Я описал в чем проблема. Если непонятно, покажи где именно, а то я пока склоняюсь к тому, что ты не осилил.

I>>А теперь, на секундочку, предположим, что детерминизм у нас самый что ни есть православный — а именно на иммутабельных структурах.
I>>Внезапно оказывается, что нужен всего один оператор сравнения и нет никаких проблем с кешем, вообще, и нет нужды сравнивать все свойства на всю глубину.

_>Хм, а я разве где-то говорил, что вариант с иммутабельными данными хуже? ) Как раз наоборот, я везде подчёркивал, что именно наличие иммутабельных параметров для чистых функций и позволяет делать дополнительную оптимизацию. Т.е. очевидно что это лучше. Но это не значит, что другой вариант вообще невозможен.

Я и говорю — в твоей теории не хватает одного понятия — абсолютно чистые функции. А то неудобно говорить "чистые функции с иммутабельными параметрами".

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

Вот ради таких свойств и есть смысл вводить понятие чистоты. Без этих свойств чистота никому не нужна.

Здравствуйте, Ikemefula, Вы писали:

I>Не я, а ты. Это ведь ты хочешь иметь мутабельные объекты-значения в то время, как во всех языках без исключения объекты значения стараются делать иммутабельными, хоть джаваскрипте, хоть в С#, хоть Java.

О как забавно... Ну расскажи какие средства есть в перечисленных языках для этих целей. )

I>Я и говорю — в твоей теории не хватает одного понятия — абсолютно чистые функции. А то неудобно говорить "чистые функции с иммутабельными параметрами".

Эммм, а как мы можем внести в определение вида функции (которое должно зависеть только от самой функции) то, каким образом мы её вызываем? ) Ведь если мы возьмём чистую функцию в определение языка D и передадим ей иммутабельные данные (не меняя её прототип!), то все оптимизации можно исполнять по полной.

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

Что ещё за классическое понимание? ) Сколько у нас собственно языков поддерживающих чистые функции, чтобы можно было выводить некое общее определение? И сколько из них допускают использование мутабельных данных (не обязательно в таких функциях, а вообще)?

I>Вот ради таких свойств и есть смысл вводить понятие чистоты. Без этих свойств чистота никому не нужна.

С такой точки зрения и константность вообще не нужна...

Здравствуйте, alex_public, Вы писали:

I>>Не я, а ты. Это ведь ты хочешь иметь мутабельные объекты-значения в то время, как во всех языках без исключения объекты значения стараются делать иммутабельными, хоть джаваскрипте, хоть в С#, хоть Java.

_>О как забавно... Ну расскажи какие средства есть в перечисленных языках для этих целей. )

Самые разные: замыкания, свойства только для чтения и тд

I>>Я и говорю — в твоей теории не хватает одного понятия — абсолютно чистые функции. А то неудобно говорить "чистые функции с иммутабельными параметрами".

_>Эммм, а как мы можем внести в определение вида функции (которое должно зависеть только от самой функции) то, каким образом мы её вызываем? )

Здесь D повторяет особенности С++. Чистые функции в D это совсем не то же, что и чистые функции в функциональном программировании.

>Ведь если мы возьмём чистую функцию в определение языка D и передадим ей иммутабельные данные (не меняя её прототип!), то все оптимизации можно исполнять по полной.

Мулька в том, что ты должен знать "кака унутре неонка" что бы применять оптимизации. Чистота функций для того и нужна, что бы не знать про такие детали.

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

_>Что ещё за классическое понимание? )

То самое, которое ты боишься для себя открыть. Нет смысла говорить про чистоту, если распробовать её можно только при определенных условиях.

>Сколько у нас собственно языков поддерживающих чистые функции, чтобы можно было выводить некое общее определение?

Ты в самом деле думаешь, что понятия выводятся по имеющимся языкам программирования ?

>И сколько из них допускают использование мутабельных данных (не обязательно в таких функциях, а вообще)?

Практически все

I>>Вот ради таких свойств и есть смысл вводить понятие чистоты. Без этих свойств чистота никому не нужна.

_>С такой точки зрения и константность вообще не нужна...

От:	D. Mon	http://thedeemon.livejournal.com
Дата:	26.03.14 17:16
Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	26.03.14 17:22
Оценка:

	От:	AlexRK
	Дата:	26.03.14 17:29
	Оценка:

	От:	alex_public
	Дата:	26.03.14 18:29
	Оценка:

	От:	alex_public
	Дата:	26.03.14 18:35
	Оценка:

	От:	Klapaucius
	Дата:	27.03.14 11:25
	Оценка:

	От:	Klapaucius
	Дата:	27.03.14 11:40
	Оценка:

	От:	Darooma
	Дата:	31.03.14 10:24
	Оценка: