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

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

EP>Встроенной ленивости и ленивых списков естественно нет. Их нет не потому что C++ не поддерживает ФП

Ну да, логичнее было бы сказать, что C++ не поддерживает ФП потому, что их (в числе прочего, более важного) там нет.

EP>а потому что используются более эффективные техники (писать ФП ради самого ФП — нет смысла. есть смысл применять ФП там, где необходимы его полезные свойства).

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

EP>Да и вообще — ленивость не во всех функциональных языках есть.

Какая-то поддержка ленивости как раз почти во всех ФЯ есть, выбор дизайнера языка там обычно между "ленивость по умолчанию" и "аннотации ленивости". Хотя, о чем говорить, второй вариант сильно мотивирует разработчика имплементации сделать реализацию ленивости "для галочки", убогую в техническом смысле.

EP>Соответственно понадобится boilerplate для их определения: Lazy<T>, LazyList<T>, каррированные cons, zipWith, etc.
EP>Пример выше запишется вот так:
EP>

EP>auto fibs = fix(cons(0) * cons(1) * (zipWith(plus) <ap> tail));
EP>

Где * это композиция функций, а <ap> — это соответствующий named operator.

Когда я говорил "попробуйте написать" — имелся в виду работающий код, а не псевдокод.

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

EP>Нет, я о том, что этот "идиоматичный" пример тормозит даже со специальным runtime'ом. Например на ровном месте вводятся межпоточная синхронизации и медленные списки.

Тормозит по сравнению с чем? Вот когда предоставите для сравнения control-structure для связывания комбинаторов с комбинаторами с аналогичной функциональностью (поддержка раннего завершения, циклов, автомемоизации, потокобезопасность и т.д.) тогда и сравним. Сразу говорю, что заявляемая ненужность комбинирования комбинаторов равноценной заменой для такого средства не является.

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

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

Второе крайнее положение есть — type-erasure, но оно достигается специальным кодом, а не компилятором.
Например можно сделать так:

template<typename F>
int foo(F f)
{
    return f(1.1);
}

а можно так:

int bar(std::function<int(double)> f)
{
    return f(1.1);
}

Оба варианта работают с "callable" типа int(double), без всякого наследоавния. Но в первом случае код шаблона должен быть виден в месте использования (хотя конкретные специализации можно компилировать отдельно), а во втором — раздельная компиляция.

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

EP>А как контролируется зоопарк расширений? Через reference implementation?

Да.

EP>Как они помогут в примере выше? Запретив использование такого замыкания?

Да.

EP>Это не интересно.

Конечно не интересно. У вас же вся аргументация о том, что плюсолямбды UFP не решают строится так:
1) Да у вас самих ничего не решается! Уже на этом этапе не понятно, как (не)поддержка UFP в плюсах зависит от того, что где-то там негров линчуют, ну да ладно.
2) Обосновывается неподдержка закрыванием файла с использованием средства, которое как раз для этого и предназначено (решение проблемы prompt finalization). Полностью игнорируется то, что без использования этого средства (using, брекеты и т.д.) доступность файла гарантируется, примерно как и доступность объекта, но несколько слабее. По независимым от ГЦ причинам. Например потому, что у объекта нет метода "освободить память", а метод "закрыть файл" наоборот есть, как и у его плюсового аналога. Т.е. гарантия доступности точно не хуже плюсовой.
3) Подразумевается, но не говориться (и даже явно отрицается), что претензия к prompt finalization. Действительно, такой гарантии нет ни для освобождения памяти, ни для закрытия файла. Первое считается приемлемым, а для второго есть другие средства (using, брекеты, регионы etc.), которые не поддерживают UFP (потому что гарантия на доступность не сочетается с гарантией на неотложное освобождение).

При этом пример, который предлагается повторить, демонстрирует систему, которая не гарантирует ни доступность, ни неотложенную финализацию. Первое потому, что UFP не решена. Второе потому, что возвращая откуда-то замыкание, вы делегируете ответственность за время жизни "пользователю" функции, который может продлевать время ее жизни неограниченно. Естественно при разработке систем дающих гарантии на prompt finalization с такой лазейкой будут наоборот бороться.

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

_>Ну покажи как ты решаешь данную задачу, если у тебя допустим есть такая функция. )
Так и решается: функции вида Monad<A> F(B b) лифтятся до Monad<A> F(Monad<B> b) при помощи bind, а функции вида A G(B b) лифтятся до Monad<A> G(Monad<B>) в два приёма: сначала строится функция Monad<A> G'(B b) при помощи unit, а уже потом bind.

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

EP>Что мешает использовать подобную архитектуру для C++/D?
Ничего. Но когда вы используете "подобную архитектуру" для C++/D, вы получите интерпретатор Erlang на C++/D. В рамках языка добиться тех же успехов не выйдет. Мы как-то уже обсуждали эту тему; оказалось, что написать "Эрланг.Net" невозможно — не тот рантайм.

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

I>Кроме того, есть всякие разные вычисления, где, казалось бы, нужен перформанс, перформанс, перформанс, о оказывается все не так просто
I>http://www.adass.org/adass/proceedings/adass99/O3-02/

Ты читал что там написано?

Scripting languages have become a powerful tool for the construction of flexible scientific software because they provide scientists with an interpreted programming environment, can be easily interfaced with existing software written in C, C++, and Fortran, and can serve as a framework for modular software construction.

В таком контексте я и сам Python использую — библиотека на C++ вызывается из Python'а, в котором только всякий обвес. C++ API можно автоматически warp'ать через SWIG.

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

I>Есть одно правило — дешевле, проще, быстрее сделать корректное медленное быстрым, чем некорректное корректным.

Ты утверждаешь что это правило работает всегда?

http://stackoverflow.com/a/145559/1762344
"The going word at Facebook is that 'reasonably written C++ code just runs fast,' which underscores the enormous effort spent at optimizing PHP and Java code. Paradoxically, C++ code is more difficult to write than in other languages, but efficient code is a lot easier [to write in C++ than in other languages]."
– Herb Sutter at //build/, quoting Andrei Alexandrescu

I>>>>>Это инфраструктуру без подобного языка заюзать невозможно, в принципе.
EP>>>>Что мешает использовать подобную архитектуру для C++/D?
I>>>Человеческий фактор, это очевидно. Нужно что бы язык страховал от большинства ошибок или позволял забесплатно и быстро найти их. В С++ ни того, ни другого нет.
EP>>От таких именно ошибок гарантированно страхует Erlang? (и от чего нельзя застраховаться в C++/D теми или иными спосабами)
I>Ошибки с указателями,

Предупреждаются правильной инфраструктурой.

I>ошибки с изменением состояния,

Какое состояние, глобальное?

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

Какой взаимодействие? Где? Сделай те же акторы или csp, и будет тебе корректное взаимодействие

I>>>Ты говорил про ФП на задворках империи. Это, внезапно, оказалось давно не так даже в С++.
EP>>Не просто ФП, а именно чистый ФП.
I>Абсолютно чистого ФП в природе пока что нет, так что всё в порядке.

Что ты конкретно имеешь ввиду? unsafePerformIO, или что-то более фундаментальное?

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

K>Отлично подходит. Вы, конечно, можете выдумать какое-то специальное убогое ФП, принципам которого такая контролируемая мутабельность не соответствует, а потом его критиковать, но к реальности это никакого отношения не имеет.

Речь не про убогое ФП, а про чистый код. Да, я помню, что вы считаете код внутри монад равноправным обычному коду в Хаскеле. Но на мой взгляд это совсем не так. И не только на мой (могу привести цитаты из хороших книг по Хаскелю).

K>Ну вот ленивость — это "неявная, скрытая" мутабельность, что продемонстрировано по соседству.

Не, это не то совсем. Вот хорошая скрытая мутабельность реализуется например при превращение рекурсии в цикл.

K>Конкретный пример — это код.
K>Я же говорю, оптимизации, которые устраняют промежуточные массивы, списки и т.д. в комбинации функций, каждая из которых по по отдельности копирует, а не меняет по месту существуют и вполне работают. Как и все оптимизации, работают они не всегда, но объем копирования существенно сокращают. Т.е. компилятор оптимизирующий код вида:
K>...
K>существует. Понятно, что без таких оптимизаций было бы затруднительно комбинировать комбинаторы более-менее безнаказанно.

Ну ок, пускай будет код. Мне интересно, в коде типа такого

f1 True x=map(+1) x
f1 False x=x
f2 True x=map(+2) x
f2 False x=x
f3 True x=map(+3) x
f3 False x=x

f o1 o2 o3 x=f1 o1 $ f2 o2 $ f3 o3 x
 
main = print (f True True True [1, 10, 100, 1000])

сколько будет произведено выделений памяти? В C++ аналоге этого кода будет ровно 0 выделений памяти.

Это такая моделька той самой фильтрации видео. Естественно подразумевается, что булевы значения вводятся пользователем (а не известны на время компиляции), вместо map(+1) что-то сложное, а список у нас не из 4 элементов, а из пары миллионов.

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

I>>>Проблема с ФП в том, что циклические ссылки это норма. Это поначалу просто убивает мозг.
EP>>Покажи пример циклической ссылки при использовании полностью immutable структур, и eager evaluation.
I>А при чем здесь "полностью immutable" ? Функциональщина это отделение сайдэффектов в отдельную коробочку, а не когда всё абсолютно иммутабельное. Если всё абсолютно иммутабельное, то надо как то обеспечить бесконечную память.

Например есть иммутабельная структура данных типа rope — где там взяться циклам?

I>>>Итого — если делать "как в С++" то надо бороться с циклическими ссылками и желательно что бы эти циклические ссылки искал компилятор, а вот компилятор этого как раз и не умеет. То есть, в итоге пришли к ручному управлению, когда, казалось бы, нужна была автоматизация. Все чего добились — ручная неявная работа с ресурсами.
EP>>Да не надо "как в С++" — покажи хоть какое-то автоматическое решение этого варианта UFP.
I>C UFP всё в порядке — передача лямбды наверх не разрушает связь с экземпляром и здесь не надо ничего автоматизировать, всё и так работает автоматически.

Это демагогия, с тем же успехом можно сказать что [&] решает UFP — сама ссылка-то жива, это просто объект уже уничтожен. Толку-то от мёртвого ресурса?

I>Если ты про управление ресурсами, а не UFP, то можешь заметить, я пишу о том, что ни там, ни там нет автоматического управления. В обоих случаях ручное управление, только вызов освобождения в одном случае делается явно, в другом неявно. То есть, разница только в местах, где ты раскладываешь подсказки компилятору что бы он вовремя вызвал нужный метод как ::close, .Dispose или delete .

В случае C++ — достаточно указать что использовать при захвате, в остальных N местах компилятор либо сам всё расставит, либо выдаст error.
В C# — нужно расставлять во всех N местах подсказки руками, причём происходит транзитивное заражение, таких мест много, и далеко не ко всем есть доступ.
То есть разница существенная: O(1) vs O(N)

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

Да называй как хочешь. Только это "ручное" позволяет упростить код с O(N) до O(1)

I>>>В С++ придется следить за циклическими ссылками, приседать, обрезать и тд и тд и тд и всё это руками, но ресурсы будут освобождаться неявно.
EP>>Нет, не придётся следить за циклическими ссылками — представь что в этом примере их нет (да и вообще в C++ они редко встречаются).
I>Как минимум придется руками обеспечивать разделяемое владение.

"Руками" это добавить make_shared? Беда.

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

K>То, что он нетипизирован (точнее, опционально типизирован) — это объективная реальность, тут от согласия ничего не зависит.

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

K>Почему нельзя? Можно достигать высокие степени "раздельности" с помощью линктайм кодогенерации или AOT/JIT-компилятора, например.

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

K>Тем не менее, раздельность компиляции и типизированность — вообще ортогональные понятия. Параметрический полиморфизм и параметризованные модули могут (и являются в ряде языков) генеративными, а не аппликативными, и тем не менее полностью типизированы. Существует также достаточно близкий родственник плюсовых шаблонов — F#-ные инлайн-функции, которые также полностью типизированы.

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

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

I>>Кроме того, есть всякие разные вычисления, где, казалось бы, нужен перформанс, перформанс, перформанс, о оказывается все не так просто
I>>http://www.adass.org/adass/proceedings/adass99/O3-02/

EP>Ты читал что там написано?
EP>

EP>Scripting languages have become a powerful tool for the construction of flexible scientific software because they provide scientists with an interpreted programming environment, can be easily interfaced with existing software written in C, C++, and Fortran, and can serve as a framework for modular software construction.

В таком контексте я и сам Python использую — библиотека на C++ вызывается из Python'а, в котором только всякий обвес. C++ API можно автоматически warp'ать через SWIG.

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

I>>Есть одно правило — дешевле, проще, быстрее сделать корректное медленное быстрым, чем некорректное корректным.

EP>Ты утверждаешь что это правило работает всегда?
EP>

EP>http://stackoverflow.com/a/145559/1762344
EP>"The going word at Facebook is that 'reasonably written C++ code just runs fast,' which underscores the enormous effort spent at optimizing PHP and Java code. Paradoxically, C++ code is more difficult to write than in other languages, but efficient code is a lot easier [to write in C++ than in other languages]."
EP> – Herb Sutter at //build/, quoting Andrei Alexandrescu

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

I>>Ошибки с указателями,

EP>Предупреждаются правильной инфраструктурой.

Правильная инфраструтукра это такая, в которую глянув на минуту можно понять все подряд. С++ здесь уже сливает.

Я например на С++ писал в продакшн в общей сумме где то 6 лет. На питоне — меньше года. На С++ я не писал всерьез в продакшн с 2007го, на питоне — с 2003го. При этом Питон я до сих пор читаю как книгу, а С++ только ту часть, что без шаблонов, хотя в свое время всякие подобия буста и "александреску стайл" были моей любимой областью.

I>>ошибки с изменением состояния,

EP>Какое состояние, глобальное?

Любое.

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

EP>Какой взаимодействие? Где? Сделай те же акторы или csp, и будет тебе корректное взаимодействие

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

Вот смотри boost.phoenix или boost.spirit — будет такой же мрак. Кроме того, для корректного взаимодейтсвия в общем случае придется изобрести GC. Гугл со своим движком браузера зашел в тупик и капитулировал — щас пилит GC для плюсов.

I>>Абсолютно чистого ФП в природе пока что нет, так что всё в порядке.

EP>Что ты конкретно имеешь ввиду? unsafePerformIO, или что-то более фундаментальное?

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

Все языки они хотя бы чуточку грязные

Из за того, что память конечна.

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

EP>>Что мешает использовать подобную архитектуру для C++/D?
S>Ничего. Но когда вы используете "подобную архитектуру" для C++/D, вы получите интерпретатор Erlang на C++/D. В рамках языка добиться тех же успехов не выйдет.

Подробнее.
Основа для зелёных потоков есть и там и там — в C++ stackful coroutine, в D — fiber. Нужна инфраструктура в виде библиотек/фреймворков. Но это всё-таки нельзя назвать интерпретатором.

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

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

I>>>>Проблема с ФП в том, что циклические ссылки это норма. Это поначалу просто убивает мозг.
EP>>>Покажи пример циклической ссылки при использовании полностью immutable структур, и eager evaluation.
I>>А при чем здесь "полностью immutable" ? Функциональщина это отделение сайдэффектов в отдельную коробочку, а не когда всё абсолютно иммутабельное. Если всё абсолютно иммутабельное, то надо как то обеспечить бесконечную память.

EP>Например есть иммутабельная структура данных типа rope — где там взяться циклам?

У меня ощущение, что ты давно перестал читать

Извини, я не могу сделать это за тебя.

I>>C UFP всё в порядке — передача лямбды наверх не разрушает связь с экземпляром и здесь не надо ничего автоматизировать, всё и так работает автоматически.

EP>Это демагогия, с тем же успехом можно сказать что [&] решает UFP — сама ссылка-то жива, это просто объект уже уничтожен. Толку-то от мёртвого ресурса?

Никакого, но с UFP всё в порядке.

I>>Если ты про управление ресурсами, а не UFP, то можешь заметить, я пишу о том, что ни там, ни там нет автоматического управления. В обоих случаях ручное управление, только вызов освобождения в одном случае делается явно, в другом неявно. То есть, разница только в местах, где ты раскладываешь подсказки компилятору что бы он вовремя вызвал нужный метод как ::close, .Dispose или delete .

EP>В случае C++ — достаточно указать что использовать при захвате, в остальных N местах компилятор либо сам всё расставит, либо выдаст error.

Не надо никаких N мест

EP>В C# — нужно расставлять во всех N местах подсказки руками, причём происходит транзитивное заражение, таких мест много, и далеко не ко всем есть доступ.

Хватает одного места.

EP>То есть разница существенная: O(1) vs O(N)

Покажи где ты собираешься O(N) получить, если отбросить случай намеренного дублирования кода.

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

EP>Да называй как хочешь. Только это "ручное" позволяет упростить код с O(N) до O(1)

У меня в коде нет никаких O(N)

I>>Как минимум придется руками обеспечивать разделяемое владение.

EP>"Руками" это добавить make_shared? Беда.

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

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

K>Код с IO/ST как раз чистый, для того, чтоб он был таковым они и нужны. Чтоб сделать из них "нечистый" нужно воспользоваться каким-нибудь unsafePerformIO.

Он может стать чистым где-то далеко выше, при применение чего-то типа runSt для отрезания данной области от остального кода. А так это не нормальный код на хаскеле, а императивный монадный подъязык.

Ну так что, покажете как выглядит мутабельная ссылка в чистом хаскеле (а не императивном монадном подъязыке) или же признаем что такого просто нет в чистом ФП? )

K>Во-первых, не обходится. Во вторых, то что вы называете "оптимизированным копированием" в языках с решенной UFP и в C++ существенно отличаются.

Реализации различные, а результат один.

K>А если мы возвращаем пару или вовсе список замыканий?

Да без проблем. Какая разница сколько объектов перемещать? )

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

Про циклы не понял о чём вообще речь.

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

K>Видим полностью рабочий код, который перечисленных выше недостатков не имеет.

Кстати, сам то код функции с ссылкой выглядит не так уж и страшно. Только вот это уже не та функция (по сравнению с C++ аналогом) — в ней мы имеем дело уже не int'ом, а с некой другой сущностью, не имеющей его свойств (в отличие от int& в большинстве императивных языков). И вследствие этого, код использующий данную функцию будет уже выглядеть совсем адски.

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

I>>>Кроме того, есть всякие разные вычисления, где, казалось бы, нужен перформанс, перформанс, перформанс, о оказывается все не так просто
I>>>http://www.adass.org/adass/proceedings/adass99/O3-02/
EP>>Ты читал что там написано?
EP>>

EP>>Scripting languages have become a powerful tool for the construction of flexible scientific software because they provide scientists with an interpreted programming environment, can be easily interfaced with existing software written in C, C++, and Fortran, and can serve as a framework for modular software construction.

В таком контексте я и сам Python использую — библиотека на C++ вызывается из Python'а, в котором только всякий обвес. C++ API можно автоматически warp'ать через SWIG.
I>И что тебя смущает ?

Привёл ссылку где рассказывается как Python может вызывать C/C++/Fortran библиотеки. Что сказать-то хотел?

I>Посмотри какие либы используются для научных вычислений. Там довольно часто код пишется дольше чем работает.

Какой-нибудь FEM (которых только в РФ штуки 4 из известных) — требует много вычислительных ресурсов.
Причём аппетит приходит во время еды — более мелкая сетка, разные сочетания нагрузок, нелинейные материалы, динамика, mesh optimization, progressive collapse analysis и т.д и т.п. При добавлении какого-либо нового свойства — время расчёта увеличивается на порядок, а то и несколько.

I>>>корректное взаимодействие и тд и тд.
EP>>Какой взаимодействие? Где? Сделай те же акторы или csp, и будет тебе корректное взаимодействие

I>И в итоге, все суммировав, получится в лучшем случае как-бэ-функциональный-дсл,

Да нет никакого DSL — просто библиотека, в худшем случае — framework.

I>>>Абсолютно чистого ФП в природе пока что нет, так что всё в порядке.
EP>>Что ты конкретно имеешь ввиду? unsafePerformIO, или что-то более фундаментальное?
I>Разумеется. Такие методы нарушают чистоту хаскеля, так что, по честному, его нельзя назвать чистым

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

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

S>Так и решается: функции вида Monad<A> F(B b) лифтятся до Monad<A> F(Monad<B> b) при помощи bind, а функции вида A G(B b) лифтятся до Monad<A> G(Monad<B>) в два приёма: сначала строится функция Monad<A> G'(B b) при помощи unit, а уже потом bind.

Не забываем, что задачка у нас: "добавить optional в старый код, вообще не меняя его". Т.е. разговор вообще то был не о том как делать собственно преобразование (это думаю всем давно очевидно), а как его автоматически добавить в код.

P.S. Кстати, bind осуществляет не лифтинг (создание новой функции), а непосредственно применяет функцию к монаде. Хотя это на суть дела не влияет.

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

S>Ничего. Но когда вы используете "подобную архитектуру" для C++/D, вы получите интерпретатор Erlang на C++/D. В рамках языка добиться тех же успехов не выйдет. Мы как-то уже обсуждали эту тему; оказалось, что написать "Эрланг.Net" невозможно — не тот рантайм.

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

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

EP>>Например есть иммутабельная структура данных типа rope — где там взяться циклам?
I>У меня ощущение, что ты давно перестал читать

Извини, я не могу сделать это за тебя.

На вопрос ответь.

I>>>C UFP всё в порядке — передача лямбды наверх не разрушает связь с экземпляром и здесь не надо ничего автоматизировать, всё и так работает автоматически.
EP>>Это демагогия, с тем же успехом можно сказать что [&] решает UFP — сама ссылка-то жива, это просто объект уже уничтожен. Толку-то от мёртвого ресурса?

I>Никакого, но с UFP всё в порядке.

Отличный подход. "С UFP всё в порядке, поэтому исходную задачу решать не будем"

EP>>То есть разница существенная: O(1) vs O(N)

I>Покажи где ты собираешься O(N) получить, если отбросить случай намеренного дублирования кода.

Было:

class Foo
{
    // ...
};

Foo используется в N местах (включая транзитивные зависимости), в том числе у клиентов, к коду которых доступа нет.
Стало:

class Foo
{
    Resource deficit;
    // ...
};

Удачной O(N) охоты на IDisposable

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

EP>>>Например есть иммутабельная структура данных типа rope — где там взяться циклам?
I>>У меня ощущение, что ты давно перестал читать

Извини, я не могу сделать это за тебя.

EP>На вопрос ответь.

Отвечаю — "полностью immutable" к обсуждаемому вопросу никаким боком не относятся. То есть, вообще.

EP>>>Это демагогия, с тем же успехом можно сказать что [&] решает UFP — сама ссылка-то жива, это просто объект уже уничтожен. Толку-то от мёртвого ресурса?

I>>Никакого, но с UFP всё в порядке.

EP>Отличный подход. "С UFP всё в порядке, поэтому исходную задачу решать не будем"

Скажи пожалуйста, а бросание исключения из лямбды тоже UFP нарушает ?

I>>Покажи где ты собираешься O(N) получить, если отбросить случай намеренного дублирования кода.

EP>Было:
EP>

EP>class Foo
EP>{
EP>    // ...
EP>};
EP>

Foo используется в N местах (включая транзитивные зависимости), в том числе у клиентов, к коду которых доступа нет.

EP>Стало:
EP>

EP>class Foo
EP>{
EP>    Resource deficit;
EP>    // ...
EP>};
EP>

Удачной O(N) охоты на IDisposable

То есть, под O(N) ты имеешь ввиду аггрегирование, которое я уже упоминал.

Вероятно, у тебя есть чудесный способ узнать что ресурс корректно захватывается, освобождается и разрушается во всех N случаях ? Покажи этот чудесный способ.

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	23.01.14 11:19
Оценка:

	От:	Klapaucius
	Дата:	23.01.14 11:29
	Оценка:

	От:	Klapaucius
	Дата:	23.01.14 11:34
	Оценка:

	От:	Evgeny.Panasyuk
	Дата:	23.01.14 11:56
	Оценка:

	От:	Klapaucius
	Дата:	23.01.14 12:35
	Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	23.01.14 16:31
Оценка: