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

I>Klapaucius говорит не про скорость. точнее основной его поинт не в скорости работы GC. А ты рассматриваешь GC исключительно со стороны перформанса.

Не не не, он как раз на эффективность GC и напирает в данном разговоре. Что мол в D хотя GC и есть, но дохленький и следовательно (по его логике) нормально использовать иммутабельные данные в D нельзя. На что я ему намекаю, что в системных языках есть множество разных инструментов для эффективной работы с памятью. И мы вполне можем использовать иммутабельные данные и поверх них...

I>Ну вот этого достаточно. Каким это образом подсчет ссылок вдруг поможет с освобождением памяти, в которой вагон циклических ссылок, что собтсвенно типичный случай ?

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

Ну как раз далеко не всё ручное. Основная часть вообще может через стек работать (т.е. сами данные естественно в динамической памяти, но выделяются/освобождаются через конструктор/деструктор объекта на стеке). Но даже если бы и ручное, то что? ) Это как-то принципиально мешает использовать иммутабельные объекты? )

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

I>Не надо ничего менять. Во первых, в ООП и так есть модули, хотя бы на уровне библиотеки.

Ага и для них в uml есть замечательная диаграммка пакетов... )

I>Во вторых, если в Хаскеле класть руками один АТД в один модуль, то получится тот самый класс.

Вот вот. Только соблюдая это дополнительное правило, мы начнём получать нечто отдалённо напоминающее (всё равно ещё есть набор нюансов) инкапсуляцию ООП. Но в любом случае останется непонятным как отображать такое в UML.

I>Более того, наследование в ООП используется
I>1. как уточнение типа
I>2. как расширение функционала как модуля

I>И то и другое требует вообще говоря разных стрелочек, но на практике обходятся одной. Более того, можно вообще все стрелочки заменить на стрелочка + её назначение, наприме 'use'. Собтсвенно именно это и видим.

Не, не выйдет, т.к. там есть и отношения времени исполнения и времени компиляции. Т.е. говоря ООП языком, там не только классы, но и объекты задаются. Собственно там даже их имена на стрелочках указываются... Это я про нормальный UML к ООП программе. А в случае Хаскеля явно надо придумывать новые значки и новые связи...

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

I>>Я уже показывал
I>>

I>>Node FirstLeaf(this IEnumerable<Node> items)
I>>{
I>>   return items.SelectMany(x => x.Children).First(x => x.Children != null);
I>>}
I>>

_>Ничего не понял. Где тут монада, где вычисления, а где побочные эффекты?

У тебя все перед носом

I>>Как видишь, задачи мягко говоря широко распространены.

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

И что это за "те самые инструменты" ?

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

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

_>Ну скажем promise/future из C++11 (в которых нет then) не имеют никакого отношения к монадам. Но тем не менее точно так же абстрагируют результат от задержки. )

Есди ты про те future, у которых есть метод then, то это они и есть. А другие, у которых такого метода нет, ничего не абстрагируют.

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

Не иногда, а всегда. Императивный код это явное управление эффектом. То же самое и делает монада, только при этом отделяет эффект от вычисления.

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

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

I>>Вообще, я немного погорячился. монады отделяют не просто побочные эффекты от вычислений, а эффекты, вообще, от вычислений.

NC>Что такое в данном контексте эффекты, вычисления и что значит "отделяют"?

Пример, промисы, эффект — временная задержка

Promise.race([httpGet(url), timeout(_(5).minutes())])
         .then(x => writeFile(x))
         .catch(x => logError(x))

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

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

_>Вот вот. Только соблюдая это дополнительное правило, мы начнём получать нечто отдалённо напоминающее (всё равно ещё есть набор нюансов) инкапсуляцию ООП. Но в любом случае останется непонятным как отображать такое в UML.

Точно так же. Представь, в джаваскрипте нет классов. Это не мешает клепать UML. B модулей нет. И это не мешает использовать модули на UML диаграммах. И наследования нет, и это не мешает рисовать стрелочки.

I>>И то и другое требует вообще говоря разных стрелочек, но на практике обходятся одной. Более того, можно вообще все стрелочки заменить на стрелочка + её назначение, наприме 'use'. Собтсвенно именно это и видим.

_>Не, не выйдет, т.к. там есть и отношения времени исполнения и времени компиляции. Т.е. говоря ООП языком, там не только классы, но и объекты задаются. Собственно там даже их имена на стрелочках указываются... Это я про нормальный UML к ООП программе. А в случае Хаскеля явно надо придумывать новые значки и новые связи...

Не надо ничего придумывать. см пример про джаваскрипт

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

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

Ага, весь спектр "задач с конвейерами данных, всегда имеющими одинаковое дополнительное действие на каждой стадии". Очень широко... )))

I>Есди ты про те future, у которых есть метод then, то это они и есть. А другие, у которых такого метода нет, ничего не абстрагируют.

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

I>Если тебе нужно такое отделение, то и в императивном языке ты изобретешь ровно такие же механизмы.

Только если потребуется именно конвейер. Иначе достаточно вынесения "эффекта" в библиотечную функцию. )

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

I>Точно так же. Представь, в джаваскрипте нет классов. Это не мешает клепать UML. B модулей нет. И это не мешает использовать модули на UML диаграммах. И наследования нет, и это не мешает рисовать стрелочки.

JS — это императивный язык с ООП (насчёт наследования ты загнул конечно). Так что как раз большинство uml диаграмм ему отлично подходят. А Хаскель — это декларативный язык без ООП и соответственно у него тут полный мрак.

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

I>>Точно так же. Представь, в джаваскрипте нет классов. Это не мешает клепать UML. B модулей нет. И это не мешает использовать модули на UML диаграммах. И наследования нет, и это не мешает рисовать стрелочки.

_>JS — это императивный язык с ООП (насчёт наследования ты загнул конечно).

Классов нет. Наследования классов, соответсвенно, тоже нет. А стрелочки обычные.

>Так что как раз большинство uml диаграмм ему отлично подходят. А Хаскель — это декларативный язык без ООП и соответственно у него тут полный мрак.

Как и джаваскрипт. В ём все ООП поддерживается на уровне библиотеки.

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

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

_>Ага, весь спектр "задач с конвейерами данных, всегда имеющими одинаковое дополнительное действие на каждой стадии". Очень широко... )))

Это мягко говоря заблуждение.

I>>Есди ты про те future, у которых есть метод then, то это они и есть. А другие, у которых такого метода нет, ничего не абстрагируют.

_>У них есть метод get (собственно если бы его не было, то эти future вообще не нужны были бы), который позволяет спокойно оперировать с результатом вычислений, не думая готов он уже или ещё нет.

Покажи как он отделяет вычисления от эффекта.

>Просто на его основе не построишь цепочку (тот самый конвейер), но само отделение "эффекта", как видишь, присутствует.

Цепочка == вычисления. Где отделение эффекта, если вычисления нереализуемы именно из за эффекта ? Опаньки !

I>>Если тебе нужно такое отделение, то и в императивном языке ты изобретешь ровно такие же механизмы.

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

Ты пока что показал, что вычисления у тебя возможны или только вместе с эффектом или невозможны вообще.

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

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

I>>Klapaucius говорит не про скорость. точнее основной его поинт не в скорости работы GC. А ты рассматриваешь GC исключительно со стороны перформанса.

_>Не не не, он как раз на эффективность GC и напирает в данном разговоре.

Нет, это ты рассматриваешь ГЦ исключительно со стороны перформанса.

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

Идейка в том, что в D GC приблизительно равен его отсутствию.

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

_>Ну как раз далеко не всё ручное. Основная часть вообще может через стек работать (т.е. сами данные естественно в динамической памяти, но выделяются/освобождаются через конструктор/деструктор объекта на стеке). Но даже если бы и ручное, то что? ) Это как-то принципиально мешает использовать иммутабельные объекты? )

Да, мешает. Ручной контроль резко меняет весь дизайн решения.

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

I>Классов нет. Наследования классов, соответсвенно, тоже нет. А стрелочки обычные.

Зато прототипы есть. ))) Да, в js ООП немного не такое, как в классических реализациях. Но там всё же именно ООП.

>>Так что как раз большинство uml диаграмм ему отлично подходят. А Хаскель — это декларативный язык без ООП и соответственно у него тут полный мрак.
I>Как и джаваскрипт. В ём все ООП поддерживается на уровне библиотеки.

О да, js такой весь из себя декларативный...

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


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

Да? ) Ну покажи мне монаду, которая не укладывается в эту формулировку...

I>Покажи как он отделяет вычисления от эффекта.

А то ты не представляешь... ) Пишем где-то наверху auto r=async(calculation); а потом где угодно в коде можем использовать результат вычислений с помощью r.get(), не думая, успел он там уже вычислиться или же нет.

>>Просто на его основе не построишь цепочку (тот самый конвейер), но само отделение "эффекта", как видишь, присутствует.
I>Цепочка == вычисления. Где отделение эффекта, если вычисления нереализуемы именно из за эффекта ? Опаньки !

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

Кстати, та же идиома RAII — это один из самых красивых примеров "отделения эффектов" в императивном коде. И опять же без всяких монад.

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

I>Да, мешает. Ручной контроль резко меняет весь дизайн решения.

Ну меняет и что? ) Как это мешает использовать иммутабельные структуры? )

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

I>>Классов нет. Наследования классов, соответсвенно, тоже нет. А стрелочки обычные.

_>Зато прототипы есть. ))) Да, в js ООП немного не такое, как в классических реализациях. Но там всё же именно ООП.

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

I>>Как и джаваскрипт. В ём все ООП поддерживается на уровне библиотеки.

_>О да, js такой весь из себя декларативный...

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

Вот это класс

var X = (function(){  ...  })();

Вот это модуль

var X = (function(){  ...  })();

Вот это неймспейс

var X = (function(){  ...  })();

Вот это скоп

(function(){  ...  })();

Ты видишь здесь декларативный код ? Его нет. Зато это не мешает говорить об этом коде как о классах, модулях, неймспейсах и тд

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

_>>О да, js такой весь из себя декларативный...

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

I>...

I>Ты видишь здесь декларативный код ? Его нет. Зато это не мешает говорить об этом коде как о классах, модулях, неймспейсах и тд

Ты похоже совсем не понял о чём речь. )

1. Про декларативный js — это была ирония. )))
2. А вот то, что Хаскель у нас декларативный, вызывает большие проблемы для него в uml. Только здесь уже речь шла не о диаграмме классов, а о других важнейших диаграммах (это всё обсуждалось где-то выше).

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

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

_>Да? ) Ну покажи мне монаду, которая не укладывается в эту формулировку...

Уже. Смотри внимательно пример про промисы. Там сходу сразу два действия паралельно.

I>>Покажи как он отделяет вычисления от эффекта.

_>А то ты не представляешь... ) Пишем где-то наверху auto r=async(calculation); а потом где угодно в коде можем использовать результат вычислений с помощью r.get(), не думая, успел он там уже вычислиться или же нет.

Нет, не представляю. Я вижу, что вызов get блокирует поток и вычисление приостанавливается. То есть, фактически эффект есть часть вычисления.

I>>Цепочка == вычисления. Где отделение эффекта, если вычисления нереализуемы именно из за эффекта ? Опаньки !

_>Вычисления == цепочка в монаде — это как раз только в декларативных языках.

То есть, цепочка вида

mov ax, bx
inc ax, 1
push ax

принадлежит декларативному языку ? Опаньки !!!

> А здесь мы можем спокойно задавать вычисления обычной последовательностью императивного кода.

Можно, но или вместе с эффектом или никак вообще.

_>Кстати, та же идиома RAII — это один из самых красивых примеров "отделения эффектов" в императивном коде. И опять же без всяких монад.

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

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

I>>Да, мешает. Ручной контроль резко меняет весь дизайн решения.

_>Ну меняет и что? ) Как это мешает использовать иммутабельные структуры? )

А что, для иммутабельных структур не надо память выделять ? Вот так новость.

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

I>Уже. Смотри внимательно пример про промисы. Там сходу сразу два действия паралельно.

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

I>Нет, не представляю. Я вижу, что вызов get блокирует поток и вычисление приостанавливается. То есть, фактически эффект есть часть вычисления.

Ну так нам же об этом беспокоиться не надо, оно всё автоматом происходит где-то там... )

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

Без строгих формул это всё слишком эфемерные понятия. Контекст, эффект... В самих монадах же всё совсем не так, гораздо проще и при этом строже. Я уже показывал тебе формулировку подходящую. Кстати, а для ко-монад у тебя есть формулировка? )))

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

I>А что, для иммутабельных структур не надо память выделять ? Вот так новость.

Надо, и будем выделять, без gc. Какие-то проблемы? )))

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

I>>А что, для иммутабельных структур не надо память выделять ? Вот так новость.

_>Надо, и будем выделять, без gc. Какие-то проблемы? )))

Покажи как ты собираешься освобождать памятью.