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

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

1. Нет встроенных ленивых списков, но они реализуются библиотечно То есть их нет, точно также как нет и встроенных в язык хэштаблиц — хотя std::unodered_map элементарно реализуется средствами самого языка.
2. Какого "прочего, более важного" нет?

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

Разница между высокоуровневым языком и низкоуровневым это наличие ФП?

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

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

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

Я говорю что использовать ФП ВЕЗДЕ нет смысла, так как в ряде случаев есть более эффективные и зачастую более понятные техники. Использование ФП там где оно добавляет тормозов на ровном месте, затрудняет понимание и не даёт никаких преимуществ — это и есть "писать ФП ради самого ФП".
Каким образом вы решили что аргумент "писать ФП ради самого ФП — нет смысла" применим только при доказательстве ненужности всего ФП — для меня остаётся загадкой

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

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

Тормозит по сравнению с простейшей итеративной версией, которую можно объяснить даже ребёнку.

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

Зачем всё это при вычислении простейших задач типа чисел Фибоначчи?

K>Сразу говорю, что заявляемая ненужность комбинирования комбинаторов равноценной заменой для такого средства не является.

А зачем замена? Ваш пример с числами Фибоначчи с точностью до минимальных синтаксических различий (скобки вместо $, * вместо . , <ap> вместо <*> и т.п.) переписывается на C++:

fibs = fix $ (0:) . (1:) . (zipWith (+) <*> tail)
fibs !! 100

versus

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

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

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

_>Что за иная архитектура?

Управление от потока данных.

_>И откуда оно возьмётся в задачах числодробилок, если вот тот мой пример полностью соответствует реальной задаче учёных (массив — это некая физическая величина, заданная на решётке)?

Не пойму логики. Из существования задачи решаемой через массивом как то следует невозможность использования другой архитектуры ?

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

I>>Если Адъ и Израиль это без проблем, то всё в порядке, можно согласиться. Щас вот закомые пилят решение для виртуализации на С++. Это такой трэш, не передать словамаи.

_>С интересом посмотрю на решение этой задачи на другом языке...

Я знаю два случая, где почти аналогичные проекты пилятся один на джаве, второй на дотнете

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

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

1. Я вам привёл уже несколько вариантов решения UFP в C++, в том числе GC. О чём тут ещё спорить?
2. Дефолтное средство управление ресурсами, RAII, работает и для памяти и для ресурсов в отличии от GC.
3. Вариант решения UFP с ресурсами (называйте как хотите — UFP не UFP, но то что проблема подобная это факт) в языках (с позиции которых был наезд "даже Upward Funarg Problem не решена") продемонстрирован не был. Запрет — это не решение.

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

Это касается не только возвращения ресурсов в замыканиях, а вообще в любых объектах, что я является нормальной практикой. Если же требуется запретить передвижение, то делают non-copyable&non-movable.

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

EP>>>>Это демагогия, с тем же успехом можно сказать что [&] решает UFP — сама ссылка-то жива, это просто объект уже уничтожен. Толку-то от мёртвого ресурса?
I>>>Никакого, но с UFP всё в порядке.
EP>>Отличный подход. "С UFP всё в порядке, поэтому исходную задачу решать не будем"
I>Скажи пожалуйста, а бросание исключения из лямбды тоже 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
I>То есть, под O(N) ты имеешь ввиду аггрегирование, которое я уже упоминал.

Ты также упоминал "Не надо никаких N мест". Покажи как в примере выше у тебя не будет никаких N мест.

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

А при чём тут это? "плохие" вещи доступны во всех обсуждаемых здесь языках.

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

I>>>И что тебя смущает ?
EP>>Привёл ссылку где рассказывается как Python может вызывать C/C++/Fortran библиотеки. Что сказать-то хотел?
I>Спасибо, капитан, а я то думал, что Питон в 100% случаев именно так и работает, а оказывается, так оно и есть.

Ээ. Так это ты привёл эту ссылку. Зачем?

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

Покажи такой генератор.

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

Так я и говорю, что оно не для фон-Неймановских машин. С чем ты споришь?

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

Он заруливает даже тогда, когда нужно гонять код на многих ядрах/машинах. Да, в диспетчере могут быть полезны элементы ФП (типа примитивных map+reduce), но от того что код работает на нескольких машинах, сами машины не перестали быть фон-Неймановскими, а весь код не стал внезапно чистым ФП.

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

S>Подобное возможно в С#, в виде Lifted Operators для Nullable.

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

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

S>К сожалению, нет никакого способа убедиться в том, что некоторый код "следует правилам библиотечки". Специально стараться никуда не нужно — я не представляю себе способа написать минимально безопасную библиотеку на С++. Потому что в языке нет никакого способа запретить штуки типа char*, которые могут указывать буквально куда угодно.

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

S>Дело не в модели акторов, а в том, чтобы иметь гарантии. На всякий случай напомню, что безо всякой распределёнщины С++-ный проект для эриксоновского свитча так и не взлетел. Несмотря на то, что там не самые тупые девелоперы писали, уж наверное могли "легко написать просто в лоб". А потом пришёл Эрланг, и внезапно оказалось, что всё можно написать не только языком на форуме, и оно даже работает.

Вообще то, насколько я помню, они потом отказались от всего этого и вернулись к обычному классическому коду, написанному другой компанией. Именно благодаря этому Эрланг и попал в open source.

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

_>>Без проблем это всё делается на C++. Например вот http://www.theron-library.com/index.php?t=page&amp;p=tour1 интересное решение. Ну т.е. конечно небольшая разница есть. В том смысле, что т.к. C++ позволяет иметь самый низкий уровень доступа, то при желание можно без проблем обмануть библиотеку и сломать модель. Но это если специально стараться (в Эрланге такое даже при этом не выйдет), а если следовать правилам библиотечки, то получается абсолютно такой же быстродействующий и надёжный код.
S>К сожалению, нет никакого способа убедиться в том, что некоторый код "следует правилам библиотечки". Специально стараться никуда не нужно — я не представляю себе способа написать минимально безопасную библиотеку на С++. Потому что в языке нет никакого способа запретить штуки типа char*, которые могут указывать буквально куда угодно.

В языке нет, но при необходимости можно сделать внешний верификатор который запретит "плохие" конструкции в тех или иных модулях. То есть это скорее инфраструктурный вопрос.
Другой вопрос насколько это необходимо. В том же Node.js можно точно также отстрелить себе ногу. Да и вообще, как только у нас есть while или аналог — то "можно делать плохие вещи".

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

S>Вы так пишете, как будто это хорошо. Это, по факту, означает, что компилятор никак не помогает авторам таких библиотек.

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

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

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

EP>С чего бы? Ресурс-то уничтожится когда уничтожится само замыкание

Ресурс

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

EP>Ты также упоминал "Не надо никаких N мест". Покажи как в примере выше у тебя не будет никаких N мест.

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

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

EP>А при чём тут это? "плохие" вещи доступны во всех обсуждаемых здесь языках.

Код покажи для начала, а не огрызок.

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

I>Управление от потока данных.

И как это реализуется в случае числодробилок? )

I>Не пойму логики. Из существования задачи решаемой через массивом как то следует невозможность использования другой архитектуры ?

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

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

I>>Спасибо, капитан, а я то думал, что Питон в 100% случаев именно так и работает, а оказывается, так оно и есть.

EP>Ээ. Так это ты привёл эту ссылку. Зачем?

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

EP>Покажи такой генератор.

Все нормальные математические тулы умеют такое.

EP>Он заруливает даже тогда, когда нужно гонять код на многих ядрах/машинах. Да, в диспетчере могут быть полезны элементы ФП (типа примитивных map+reduce), но от того что код работает на нескольких машинах, сами машины не перестали быть фон-Неймановскими, а весь код не стал внезапно чистым ФП.

Если одно ядро это фон-Неймановская архитектура, то вовсе не значит, что и вся система будет подходить под эту архитектуру.

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

I>>Управление от потока данных.

_>И как это реализуется в случае числодробилок? )

Если я скажу, что в таком процессоре нет счетчика текущей инструкции, типа регистра IP, ты сильно удивишься ?

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

То есть, ты хочешь что бы я искал какие то варианты в твоем половинчатом решении ?

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

S>>Подобное возможно в С#, в виде Lifted Operators для Nullable.
_>Бррр, ну вроде бы уже несколько раз обсудили, что подобное мы не рассматриваем. Т.е. вот если бы в C# был механизм реализовать подобное для любой монады, тогда да, это было бы по теме...

Насколько я понял, эти Lifted Operators для Nullable тоже не являются аналогом монады Maybe, так как не останавливают вычисления. Это скорее аппликативный функтор Maybe, чем монада — то есть толку от него мало.

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

I>Если я скажу, что в таком процессоре нет счетчика текущей инструкции, типа регистра IP, ты сильно удивишься ?

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

I>То есть, ты хочешь что бы я искал какие то варианты в твоем половинчатом решении ?

Причём тут какое-то моё решение? Это методика численных вычислений в науке вообще. Или ты хочешь и это как-то переделать? )

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

EP>Насколько я понял, эти Lifted Operators для Nullable тоже не являются аналогом монады Maybe, так как не останавливают вычисления. Это скорее аппликативный функтор Maybe, чем монада — то есть толку от него мало.

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

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

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

?

I>>>То есть, под O(N) ты имеешь ввиду аггрегирование, которое я уже упоминал.
EP>>Ты также упоминал "Не надо никаких N мест". Покажи как в примере выше у тебя не будет никаких N мест.
I>Я пока не вижу никакого внятного кода, есть код добавления одного мембера. Надо полагать я должен додумать весь недостающий код ,что бы угадать твои мысли ?

Код чего? Как класс Foo может использоваться в разных местах? Хотя бы:

class Bar
{
    Foo x;
// ...
};
class Baz
{
    Bar x;
// ...
};
// ...
{
    Baz x;
    // ...
}

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

I>>>Спасибо, капитан, а я то думал, что Питон в 100% случаев именно так и работает, а оказывается, так оно и есть.
EP>>Ээ. Так это ты привёл эту ссылку. Зачем?
I>Что бы ты убедился, что такие проекты пишутся в т.ч. на питоне.

Так я и сам подобные вещи иногда пишу, причём именно на Python
То есть вот это:

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

ты сказал только для того, чтобы показать что Python может вызывать быструю библиотеку на C/C++/Fortran? Круто

EP>>Покажи такой генератор.
I>Все нормальные математические тулы умеют такое.

И доступ к памяти, нарезку по кэшам, кластеризацию, векторизацию, comiple-time полиморфизм, распределение по потокам, за-оптимизируют? Чудеса!
Пример покажи.

EP>>Он заруливает даже тогда, когда нужно гонять код на многих ядрах/машинах. Да, в диспетчере могут быть полезны элементы ФП (типа примитивных map+reduce), но от того что код работает на нескольких машинах, сами машины не перестали быть фон-Неймановскими, а весь код не стал внезапно чистым ФП.
I>Если одно ядро это фон-Неймановская архитектура, то вовсе не значит, что и вся система будет подходить под эту архитектуру.

Дальше-то что? Чистый ФП код внезапно станет оптимальным для каждого из ядер?