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

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

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

Инструменты полегче можно использовать и так, зачем еще какие-то аналоги? Их и используют, правда редко. Вот, вполне популярный пакет lens у которого в документации UML-диаграмма, построенная во вполне "готовом инструменте" creately.com

_>Мы же уже обсуждали, что реальность (и исполнитель программы и задачи) у нас на самом деле совсем не чистые.

Это зависит от модели реальности. Волновые функции, операторы импульса/координат и гамильтониан совсем чистые.

_>Без проблем подобным образом обычно можно записать только небольшую часть программы (логику на самом высшем уровне абстракции),

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

_>а остальное приходится записывать с помощью извращений.

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

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

Нет, конечно. Удобно — наоборот — на чистом ФЯ.

_>А что собственно демонстрировать? )

А что собственно демонстрировать уже неоднократно написано. Например здесь:

1) Более-менее полноценная поддержка для комбинирования комбинаторов.
2) Возможность рассуждать об этих комбинаторах как о математических объектах (с оговорками).

Для этого нужна более-менее нормальная система типов, полноценная поддержка ленивости, специальные оптимизации, и контроль за эффектами как сам по себе, так и для нормальной работы ленивости и оптимизатора.

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

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

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

Этот действительно небольшой шум следовало бы сделать и еще меньше. Но вот что он не нужен D вовсе не демонстрирует, потому что, как мы выяснили, ничего аналогичного в D нет.

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

Очевидно затем, что писать, читать, поддерживать и тестировать код, который работает с иммутабельными структурами данных обычно легче, чем тот, что работает с мутабельными.

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

Вполне приемлемый, как раз за счет "ненужных" оптимизаций.

_>- более эффективный, но с кучей лишнего мусорного кода

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

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

Эффективно на некоторых можно (список очень короткий), а красиво, конечно, не получится.

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

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

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

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

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

_>В Питоне много возможностей за счёт мультипарадигменности,

И это пока евангелисты еще ультрапарадигменность не открыли: какая бездна возможностей откроется после этого — страшно даже представить.

_>но в своей основе он весьма прост. Я бы сказал, что это идеальный язык для освоение программирования неспециалистами.

Это потому, что за такое

>>> i = 42
>>> [i for i in xrange(10)]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> i
9

специалист будет бить канделябром, а неспециалист смириться, потому что слаще питона ничего не пробовал?

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

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

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

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

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

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

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

Кстати говоря, про классику. Martin Odersky в курсах functional programming и principles of reactive programming внятно объясняет, что это и почему это. Например см Functions and State. Он использует термин rewriting, а с тз лямбда счисления все переписывания которе завершаются должны давать один и тот же результат, например

factorial(x) => x == 0 ? factorial(x -1) : 1

factorial(0) => 0 == 0 ? factorial(0 - 1) : 1

factorial(1) => 1 == 0 ? (0 == 0 ? factorial(0 - 1) : 1) : 1

factorial(2) => 2 == 0 ? (1 == 0 ? (0 == 0 ? factorial(0 - 1) : 1) : 1) : 1

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

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

То есть, за объяснениями надо идти не в языки программирования, а втыкать в лямбда счисление.

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

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

Ну и как эти вещи могут помочь в гарантии иммутабельности локальной переменной, передаваемой в чистую функцию? )

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

Ещё раз: "чистые функции в ФП" — это крайне сомнительной понятие, т.к. практически все языки с ФП не имеют прямой поддержки данной возможности. Её имеет один чисто функциональный язык (Хаскель) и один мультипарадигменный (D). Так что проводить какие-то подобные сравнения очень странно. Более того, с учётом того, что в Хаскеле по сути нет мутабельных данных, указателей и т.п., то определения этих функций в Хаскеле и D совпадают — D просто расширяет это определение уже на ту область, которой в Хаскеле вообще нет.

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

Тот факт, что результат действия функции зависит исключительно от переданных параметров, является более чем достаточным для любых оптимизаций вызовов данной функции.

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

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

_>>С такой точки зрения и константность вообще не нужна...
I>Правильно. Константность нужна именно из-за своих свойств, а не просто так.

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

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

K>Инструменты полегче можно использовать и так, зачем еще какие-то аналоги? Их и используют, правда редко. Вот, вполне популярный пакет lens у которого в документации UML-диаграмма, построенная во вполне "готовом инструменте" creately.com

Диаграмма классов в Хаскеле?

Мдаа, и чего только не сделаешь от бедности инструментов...

K>Это зависит от модели реальности. Волновые функции, операторы импульса/координат и гамильтониан совсем чистые.

Ага, ага... Т.е. электрон будет всегда пролетать только через левое отверстие (детерминизм чистой функции) и никогда через правое?

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

Как раз если бы я привёл полный код той фильтрации, то его аналог на Хаскеле выглядел бы полным страхом (естественно при условии, что мы попытались бы сохранить приемлемое быстродействие).

K>Нет, конечно. Удобно — наоборот — на чистом ФЯ.

Ага, ага... Популярность Хаскеля это очень хорошо демонстрирует...

Причём я даже не о популярности относительно главных монстров с огромным наследием (типа C++ и т.п.) — можем сравнить и с самыми новичками (типа какого-нибудь Go) и всё равно увидим отставание Хаскеля от них.

K>А что собственно демонстрировать уже неоднократно написано. Например здесь:
K>

K>1) Более-менее полноценная поддержка для комбинирования комбинаторов.
K>2) Возможность рассуждать об этих комбинаторах как о математических объектах (с оговорками).

K>Для этого нужна более-менее нормальная система типов, полноценная поддержка ленивости, специальные оптимизации, и контроль за эффектами как сам по себе, так и для нормальной работы ленивости и оптимизатора.

А причём тут это всё, если в данном контексте мы говорили только про чистоту? )

K>Нет, надо бы, как минимум, продемонстрировать какие-то осмысленные гарантии, потому что смысл проверки показанной по ссылке выше, может и есть, но лежит не в практической плоскости, а в плоскости карго-культа: Говорят, что лучших домах Филадельфии популярен контроль за эффектами. Что это такое мы не совсем понимаем, но что-нибудь проконтролируем и галочку поставим, а духи предков в награду за это нам пришлют бразиллионы сэкономленных мифических человекомесяцев.

Я вроде как показал конкретный пример кода, который компилятор не разрешает. Что не так то? )

K>Этот действительно небольшой шум следовало бы сделать и еще меньше. Но вот что он не нужен D вовсе не демонстрирует, потому что, как мы выяснили, ничего аналогичного в D нет.

Потому что он реально не нужен при наличие в языке нормальных мутабельных данных.

K>Очевидно затем, что писать, читать, поддерживать и тестировать код, который работает с иммутабельными структурами данных обычно легче, чем тот, что работает с мутабельными.

Так с реально иммутабельными данными в D тоже всё нормально. Та оптимизация в Хаскеле возникла при потребности эффективной (т.е. без копирования) модификации вроде как иммутабельных данных — в D такой проблемы просто не существует, т.к. есть и такие данные и такие.

K>Каким образом то, что нечто изобретенное в 60-х, например, используется и даже популярно сейчас опровергает то, что оно изобретено в 60-х? Вот если бы кто-то сказал, что что-то появилось сейчас, а вы бы доказали, что оно и в 60-х применялось — вот тогда это утверждение было бы опровергнуто.

Ааа так речь шла исключительно о времени изобретения концепции?) Тогда ладно. Но только тогда совершенно непонятно что плохого в этом.

K>Это потому, что за такое
K>

>>>> i = 42
>>>> [i for i in xrange(10)]
K>[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>>> i
K>9
K>

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

А что тут собственно не так? ) Подобный код в принципе на очень многих языках пишется (разве что не везде так кратко, т.к. не везде есть генераторы).

K>Наоборот, как раз это сложность языка в первую очередь и определяют. И если в том же C++ обычно приходится сделать сложно именно потому, что нормально сделать нельзя из-за дизайнерского решения "не используешь — не платишь", которое как раз может быть оправдано, то в питонах и яваскриптах сделано сложно из-за узкого кругозора, воинствующего антиинтеллектуализма и общей склонности к халтуре.

Хм, возможно я и частично согласен со всем этим... Но всё же не стал бы называть подобное сложностью. Хотя бы потому, что очень многие пользователи данных языков могут долго долго программировать на них и при этом никогда не столкнуться с подобными UB и т.п.

K>Это сделать невозможно. Статьи про популярные языки являются уютными гнездами специфических комьюнити, которые все невеликое множество реально существующих достоинств этих языков уже перечислили и давно заняты высасыванием из пальца достоинств несуществующих. Длинные списки "парадигм" как раз и иллюстрируют это в наиболее яркой и гротескной форме. И любая попытка адекватно представить язык неминуемо приведет к тотальной войне правок с интересными личностями, которые это воспримут как преступное покушение на всемогуторность их любимого 256-ипарадигменного языка, особенно если авторами 255 из этих "парадигм" являются лично они.
K>Исправить тут ничего нельзя, это нужно просто иметь в виду.

Я просто намекаю, что данная позиция уж очень напоминает некого Д'Артаньяна...

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

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

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

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

_>Я тебе уже несколько раз писал, что чистые функции в определение D являются вполне себе детерминированными. Если ты за столько раз не можешь воспринять эту информацию, то я не вижу смысла продолжать разговор.

Этот "детерминизм" D не имеет никакого отношения к детерминизму в лямбда-счислении. Просто автор решил реализовать слово pure.

A a = new A();

x = f(a);
...
y = f(a);

Лямбда-счисление говорит, что независимо от того, что было на месте троеточия, x и y будут эквивалентны. Это и есть детерминизм.

Проверяем, вместо троеточия подставляем x.mutate(); и получаем, что x и y не эквивалентны.
Все, детерминизм закончился.

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

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

_>Ну и как эти вещи могут помочь в гарантии иммутабельности локальной переменной, передаваемой в чистую функцию? )

Не надо вилять — мы говорили про иммутабельность объетов-значений, а не про локальные переменные

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

_>Ещё раз: "чистые функции в ФП" — это крайне сомнительной понятие, т.к. практически все языки с ФП не имеют прямой поддержки данной возможности.

При чем здесь языки, если это растет из лямбда-счисления ?

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

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

Разумеется не является. Для оптимизацией необходимо следующее:
x = f(a);
y = f(a);
В любой момент времени x и y должны быть эквивалентны, это основы лямбда-счисления. Ты хорошо понимаешь, что если a это мутабельный объект, то это условие невыполнимо ?

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

Рассматривай это как домашнее задание.

I>>Правильно. Константность нужна именно из-за своих свойств, а не просто так.

_>Ага. Причём это свойство во многих случаях никак не связано с оптимизацией, а связано с гарантиями на код. Точно так же может действовать и модификатор pure в D.

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

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

I>Этот "детерминизм" D не имеет никакого отношения к детерминизму в лямбда-счислении. Просто автор решил реализовать слово pure.

I>

I>A a = new A();

I>x = f(a);
I>...
I>y = f(a);
I>

I>Лямбда-счисление говорит, что независимо от того, что было на месте троеточия, x и y будут эквивалентны. Это и есть детерминизм.

I>Проверяем, вместо троеточия подставляем x.mutate(); и получаем, что x и y не эквивалентны.
I>Все, детерминизм закончился.

С чего это x и y должны быть одинаковыми, если ты передаёшь в функцию разные данные? Твоё сомнительное "определение" детерминизма ещё можно переделать к корректному приблизительно так:

A a();
const A t=a;

x = f(a);
...
if(a==t) y = f(a);

Вот при таком раскладе x и y действительно должны быть всегда (когда x и y вообще вычисляются) равны... )

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

I>Не надо вилять — мы говорили про иммутабельность объетов-значений, а не про локальные переменные

Мы говорили про чистые функции вообще то.

I>При чем здесь языки, если это растет из лямбда-счисления ?

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

I>Разумеется не является. Для оптимизацией необходимо следующее:
I>x = f(a);
I>y = f(a);
I>В любой момент времени x и y должны быть эквивалентны, это основы лямбда-счисления. Ты хорошо понимаешь, что если a это мутабельный объект, то это условие невыполнимо ?

Мутабельный это объект или нет:

1. Является внешним фактом относительно самой функции.
2. Полностью находится по контролем компилятора.

Так что ОТ ФУНКЦИИ компилятору нужно именно такое определение чистоты, как в D. А далее он уже может смотреть как её вызывают и соответственно решать какие оптимизации тут можно применять.

I>Рассматривай это как домашнее задание.

Слился значит, ну понятно... )

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

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

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

I>>Проверяем, вместо троеточия подставляем x.mutate(); и получаем, что x и y не эквивалентны.
I>>Все, детерминизм закончился.

_>С чего это x и y должны быть одинаковыми, если ты передаёшь в функцию разные данные?

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

>Твоё сомнительное "определение" детерминизма ещё можно переделать к корректному приблизительно так:

Оно не мое. Ты проигнорировал мой пример, это азы лямбда-счисления.

_>

_>

Код я скипнул — ты изобретаешь свою собственную версию лябда-счисления.

_>Вот при таком раскладе x и y действительно должны быть всегда (когда x и y вообще вычисляются) равны... )

Это в твоей версии лямбда-счислении. А вообще вот так

A a();

y = f(a)
...
x = f(a)

x должно быть эквивалентно y всегда, в любой момент времени.

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

I>>Не надо вилять — мы говорили про иммутабельность объетов-значений, а не про локальные переменные

_>Мы говорили про чистые функции вообще то.

В данном контексте речь была пр объекты значения, цитирую " ты хочешь иметь мутабельные объекты-значения в то время, как во всех языках без исключения объекты значения стараются делать иммутабельными"

I>>При чем здесь языки, если это растет из лямбда-счисления ?

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

Вообще то есть. ссылки, индексы, эквивалентность, идентичность объектов это математика в чистом виде.

I>>Разумеется не является. Для оптимизацией необходимо следующее:
I>>x = f(a);
I>>y = f(a);
I>>В любой момент времени x и y должны быть эквивалентны, это основы лямбда-счисления. Ты хорошо понимаешь, что если a это мутабельный объект, то это условие невыполнимо ?

_>Мутабельный это объект или нет:

_>1. Является внешним фактом относительно самой функции.

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

_>2. Полностью находится по контролем компилятора.

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

_>Так что ОТ ФУНКЦИИ компилятору нужно именно такое определение чистоты, как в D. А далее он уже может смотреть как её вызывают и соответственно решать какие оптимизации тут можно применять.

Не сможет он ничего сделать. Мутабельность сразу исключает ссылочную прозрачность, а раз так, то никакие оптимизации неприменимы.

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

_>Да млин, ты не понимаешь что ли, что здесь речь не об оптимизации, а о гарантиях компилятора, что данная функция не имеет побочных эффектов? )

Ну так гарантий нет. Если понимать чистоту согласно лямбда-счислению, то все в порядке. А иначе твои слова требуют формальных доказательств, прямо как у Чёрча или Тьюринга.

>Так же как и скажем модификатор const позволяет компилятору давать определённые гарантии корректности кода, даже если при этом оптимизатор вообще не затрагивается.

const вообще говоря не нужен ,если брать за основу лямбда-счисление. Ручные подсказки компилятору вообще не нужны, компилятор сможет сам выяснить, где есть чистота, а где её нет.

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

I>Это в твоей версии лямбда-счислении. А вообще вот так
I>

I>A a();

I>y = f(a)
I>...
I>x = f(a)
I>

I>x должно быть эквивалентно y всегда, в любой момент времени.

И с чего ты взял подобную чушь? Под такое определение не подходит даже функция вида

int f(int v){return v;}

Т.е. получается что она у тебя тоже не чистая? )

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

I>В данном контексте речь была пр объекты значения, цитирую " ты хочешь иметь мутабельные объекты-значения в то время, как во всех языках без исключения объекты значения стараются делать иммутабельными"

Правильно. И речь шла о передаче подобных объектов в качестве параметров функции. Так как там перечисленные языки обеспечивают подобную возможность? )

Или вдруг неожиданно окажется, что императивный C++ (не говоря уже про D) имеет тут возможностей больше, чем вроде как языки с налётом функциональности?

I>Вообще то есть. ссылки, индексы, эквивалентность, идентичность объектов это математика в чистом виде.

Речь не о математическом моделирование подобных сущностей, а о наличие их в самой математике.

I>Неверно. f(a) в любой момент времени обязано быть эквивалентно f(a). Если мутабельность это внешний факт, то и эквивалетность, внезапно, так же становится внешним фактом.

О, наконец то дошло...

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

Чего чего? ) Речь идёт не об оптимизации кода функции (она вообще может быть в DLL некой), а об оптимизации её вызова (кэширование, ленивость и т.п.). И для этой задачи нам как раз достаточно знать, что функция чистая в определение D. После этого компилятор смотрит на её параметры (мы же оптимизируем вызов — все параметры у нас перед глазами, под полным контролем) и решает возможно ли применить подобную оптимизацию (если параметры иммутабельные) или нет.

I>Не сможет он ничего сделать. Мутабельность сразу исключает ссылочную прозрачность, а раз так, то никакие оптимизации неприменимы.

Ну так а кто тебе мешает использовать иммутабельные параметры то? ) Но при этом код будет спокойно работать и с мутабельными, просто без дополнительной (!) оптимизации.

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

Эээ что? ) Я не пойму, ты сомневаешься, что компилятор будет гарантировать отсутствие побочных эффектов у функций помеченных модификатором pure? )

I>const вообще говоря не нужен ,если брать за основу лямбда-счисление. Ручные подсказки компилятору вообще не нужны, компилятор сможет сам выяснить, где есть чистота, а где её нет.

Угу, угу... Может и статическая типизация тогда тоже не нужна? )

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

_>Диаграмма классов в Хаскеле?

Мдаа, и чего только не сделаешь от бедности инструментов...

Мне даже интересно, чего бы вы ожидали от "специального инструмента для хаскеля" вместо диаграммы классов. Гаплограмму сепулек?

_>Ага, ага... Т.е. электрон будет всегда пролетать только через левое отверстие (детерминизм чистой функции) и никогда через правое?

Нет, конечно. Тем не менее волновая функция именно "чистая". Других функций-то не бывает.

_>Как раз если бы я привёл полный код той фильтрации, то его аналог на Хаскеле выглядел бы полным страхом (естественно при условии, что мы попытались бы сохранить приемлемое быстродействие).

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

_>Ага, ага... Популярность Хаскеля это очень хорошо демонстрирует...

Удобство никак не связано с популярностью. Те же C++ и Java в числе самых популярных, а практически любой язык (кроме специально придуманных неудобными вроде Интеркола) удобнее, чем они.

_>Причём я даже не о популярности относительно главных монстров с огромным наследием (типа C++ и т.п.) — можем сравнить и с самыми новичками (типа какого-нибудь Go) и всё равно увидим отставание Хаскеля от них.

Смотрим какой-нибудь langpop и видим, что наблюдаемой разницы в популярности между Go и Haskell нет. Хотя, конечно, можно подобрать какую-нибудь метрику (частота встречаемости в новостной ленте любителя Го) где какая-то разница будет.

_>А причём тут это всё, если в данном контексте мы говорили только про чистоту? )

При том, что именно для этого всего чистота и нужна.

_>Я вроде как показал конкретный пример кода, который компилятор не разрешает. Что не так то? )

Ну а D. Mon показал конкретный пример кода, который компилятор разрешает. И никакой практически значимой разницы между примерами нет, т.е. ценность неразрешения компилятора нулевая.

K>>Этот действительно небольшой шум следовало бы сделать и еще меньше. Но вот что он не нужен D вовсе не демонстрирует, потому что, как мы выяснили, ничего аналогичного в D нет.

_>Потому что он реально не нужен при наличие в языке нормальных мутабельных данных.

Поддерживать в языке мутабельные данные как раз просто, для этого вообще ничего не нужно. Контроль за эффектами нужен, чтоб нормально поддерживать ФП. Если это не нужно, то и контроль за эффектами, в основном, не нужен — разве что для дрессировки программиста.

_>Так с реально иммутабельными данными в D тоже всё нормально.

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

_>Та оптимизация в Хаскеле возникла при потребности эффективной (т.е. без копирования) модификации вроде как иммутабельных данных — в D такой проблемы просто не существует, т.к. есть и такие данные и такие.

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

_>Но только тогда совершенно непонятно что плохого в этом.

Да ничего плохого, как нет ничего плохого в том, чтоб использовать в 2014-ом году калькулятор HP-35 и ездить на Ford Falcon, например.

K>>Это потому, что за такое
K>>

>>>>> i = 42
>>>>> [i for i in xrange(10)]
K>>[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>>>> i
K>>9
K>>

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

_>А что тут собственно не так?

Тяжелый случай.

_>Подобный код в принципе на очень многих языках пишется

Это точно, только вот этот код "на очень многих языках" выдает совсем другой результат.

> let i = 42
> [i | i <- [0..9]]
[0,1,2,3,4,5,6,7,8,9]
> i
42

или

> let i = 42;;
> [for i in {0..9} -> i];;
val it : int list = [0; 1; 2; 3; 4; 5; 6; 7; 8; 9]
> i;;
val it : int = 42

_>Я просто намекаю, что данная позиция уж очень напоминает некого Д'Артаньяна...

Позиция придумывающего 257-ю парадигму, чтоб украсить вики-статью про любимый язык (и таким образом показать всем у кого гм... Д'Артаньян длиннее) не просто напоминает "позицию Д'Артаньяна", а является хрестоматийным ее примером.

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

I>>В данном контексте речь была пр объекты значения, цитирую " ты хочешь иметь мутабельные объекты-значения в то время, как во всех языках без исключения объекты значения стараются делать иммутабельными"

_>Правильно. И речь шла о передаче подобных объектов в качестве параметров функции. Так как там перечисленные языки обеспечивают подобную возможность? )

Я уже перечислил.

_>Или вдруг неожиданно окажется, что императивный C++ (не говоря уже про D) имеет тут возможностей больше, чем вроде как языки с налётом функциональности?

Не больше. Вспотеешь описывать const все возможные параметры.

I>>Вообще то есть. ссылки, индексы, эквивалентность, идентичность объектов это математика в чистом виде.

_>Речь не о математическом моделирование подобных сущностей, а о наличие их в самой математике.

То есть, ты сомневаешься что лямбда-счисление и подобные вещи это математика ?

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

_>Чего чего? ) Речь идёт не об оптимизации кода функции (она вообще может быть в DLL некой), а об оптимизации её вызова (кэширование, ленивость и т.п.). И для этой задачи нам как раз достаточно знать, что функция чистая в определение D. После этого компилятор смотрит на её параметры (мы же оптимизируем вызов — все параметры у нас перед глазами, под полным контролем) и решает возможно ли применить подобную оптимизацию (если параметры иммутабельные) или нет.

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

I>>Не сможет он ничего сделать. Мутабельность сразу исключает ссылочную прозрачность, а раз так, то никакие оптимизации неприменимы.

_>Ну так а кто тебе мешает использовать иммутабельные параметры то? ) Но при этом код будет спокойно работать и с мутабельными, просто без дополнительной (!) оптимизации.

Если нет ссылочной прозрачности, то компилятор про иммутабельность ничего не узнает.

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

_>Эээ что? ) Я не пойму, ты сомневаешься, что компилятор будет гарантировать отсутствие побочных эффектов у функций помеченных модификатором pure? )

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

I>>const вообще говоря не нужен ,если брать за основу лямбда-счисление. Ручные подсказки компилятору вообще не нужны, компилятор сможет сам выяснить, где есть чистота, а где её нет.

_>Угу, угу... Может и статическая типизация тогда тоже не нужна? )

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

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

I>>x должно быть эквивалентно y всегда, в любой момент времени.

_>И с чего ты взял подобную чушь? Под такое определение не подходит даже функция вида
_>

_>int f(int v){return v;}
_>

_>Т.е. получается что она у тебя тоже не чистая? )

Подходит. f(5) всегда будет равно 5 и так все всегда будет f(5).

В лямбда счислении нет никаких присваиваний, поэтому f(x) всегда и везде будет f(x), и если x равно 5, то это эквивалентно f(5) и 5, и так независимо ни от чего.

Это в С++ ты можешь объявить переменную и переприсвоить, поэтому f(x) != f(x), но это говорит не о том, что функция не чистая, а о том, что твой код не имеет никакого отношения к лямбда-счислению. Чистота функции это растет из лямбда счисления. Нет лямбда-счисления -> чистота не имеет никакого смысла.

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

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

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

Получается, что pure нужен не только для дополнительных оптимизаций, а скорее для:
1) облегчения чтения кода программистом (не надо анализировать груду кода, достаточно взглянуть на сигнатуру функции);
2) облегчения модификации кода программистом (не получим — случайно — побочных эффектов там, где это не ожидается);
3) создания модульных систем, когда у нас исходников соседнего модуля нет, а есть только бинарник (правда, к D это не факт, что имеет отношение).

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


int pure OuterFunc<T>(T param) where T : IMyInterface
{
    param.Modify();   // можно ли вызывать? а черт его знает

    var result = InnerFunc(param);    // InnerFunc тоже "чистая"

    ...
}

То есть модификатор pure в D далеко не так полезен, как мог бы быть.

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

K>Мне даже интересно, чего бы вы ожидали от "специального инструмента для хаскеля" вместо диаграммы классов. Гаплограмму сепулек?

В том то и дело, что я не знаю как должен выглядеть подобный инструмент для Хаскеля, т.к. не видел вообще ни одного реального примера. Фанаты ФП конечно пытаются искать какие-то замены... Например вот http://habrahabr.ru/post/211871/ наша статья на эту тему, а вот http://stackoverflow.com/questions/2457903/can-uml-be-used-to-model-a-functional-program обсуждение на SO по этой теме. Но как видно, ничего серьёзного так и не предлагается. Максимум наколенные инструменты из 70-ых годов прошлого века.

K>Удобство никак не связано с популярностью. Те же C++ и Java в числе самых популярных, а практически любой язык (кроме специально придуманных неудобными вроде Интеркола) удобнее, чем они.

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

K>Смотрим какой-нибудь langpop и видим, что наблюдаемой разницы в популярности между Go и Haskell нет. Хотя, конечно, можно подобрать какую-нибудь метрику (частота встречаемости в новостной ленте любителя Го) где какая-то разница будет.

Хы, данный рейтинг вообще ни о чём, т.к. на гитхабе живёт весьма специфическая аудитория. Лучше смотреть например здесь http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html или в других подобных более менее серьёзных ресурсах. Но в любом случае, даже если бы они были в точности равны, то это всё подтверждает мою мысль — достаточно взглянуть на дату рождения Хаскеля и Го...

K>Ну а D. Mon показал конкретный пример кода, который компилятор разрешает. И никакой практически значимой разницы между примерами нет, т.е. ценность неразрешения компилятора нулевая.

А что не так с тем примером? Он позволяет функции иметь побочные эффекты? )

K>Поддерживать в языке мутабельные данные как раз просто, для этого вообще ничего не нужно. Контроль за эффектами нужен, чтоб нормально поддерживать ФП. Если это не нужно, то и контроль за эффектами, в основном, не нужен — разве что для дрессировки программиста.

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

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

Если есть сомнения в быстродействие работы с иммутабельными данными в D, то можем сравнить на каком-нибудь тесте...

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

Ничего подобного. С иммутабельными данными тоже всё нормально. Не нужны именно оптимизации, позволяющие Хаскелю работать с иммутабельными данными в стиле мутабельных — в таком случае в D используем нормальные мутабельные.

И не надо думать, что если что-то использовать необязательно, то это не будут использовать. К примеру const в C++ можно не использовать вообще. Но весь нормальный код кругом в этих const'ах и т.п.

K>Да ничего плохого, как нет ничего плохого в том, чтоб использовать в 2014-ом году калькулятор HP-35 и ездить на Ford Falcon, например.

Ага, ага... Вот теорема Пифагора тоже в общем то устарела — не учитывает искривление пространства. Но что-то большинство народа по прежнему использует именно её, а не продвинутый вариант.

K>Это точно, только вот этот код "на очень многих языках" выдает совсем другой результат.
K>

>> let i = 42
>> [i | i <- [0..9]]
K>[0,1,2,3,4,5,6,7,8,9]
>> i
K>42
K>

K>или
K>

>> let i = 42;;
>> [for i in {0..9} -> i];;
K>val it : int list = [0; 1; 2; 3; 4; 5; 6; 7; 8; 9]
>> i;;
K>val it : int = 42
K>

Это всего лишь вопрос области видимости. Скажем вариант на C++/Java/C# опять же покажет другое.

K>Позиция придумывающего 257-ю парадигму, чтоб украсить вики-статью про любимый язык (и таким образом показать всем у кого гм... Д'Артаньян длиннее) не просто напоминает "позицию Д'Артаньяна", а является хрестоматийным ее примером.

Хыхы, википедию пишут Д'Артаньяны? ) Типа каждому выделяется по статье и больше никто на свете не способен её править? ))) Мда, это уже шедевр форумного спора...

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	01.04.14 16:51
Оценка:

	От:	Klapaucius
	Дата:	03.04.14 11:26
	Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	05.04.14 09:31
Оценка:

	От:	alex_public
	Дата:	05.04.14 20:09
	Оценка:

	От:	alex_public
	Дата:	05.04.14 20:52
	Оценка:

	От:	AlexRK
	Дата:	07.04.14 13:49
	Оценка: