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

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

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

S>1) Взять массив значений нужной нам величины в разные моменты времени
S>2) Преобразовать его через дискретное преобразование Фурье в массив фаз/интенсивностей по частотам
S>3) Свернуть этот массив с массивом 111111....10......000000, где "ненужная" нам часть спектра занулена
S>4) Преобразовать массив обратно через дискретное преобразование Фурье в значения-во-времени.
S>Если массив у нас длиной N, то этот наивный подход даст нам O(N^2). Ну, потому, что школьная формула для DFT это X[k] = sum[n=0..N-1](x[n]*exp(-2*Pi*I*n*k/N)).

Вообще то даже в таком случае будет что-то вроде O(N), т.к. подобный фильтр естественно применяется не ко всему массиву (кстати, частенько "бесконечному" во времени), а к некоторому окну (размер которого зависит от требуемых частот). Просто в случае использования ДПФ будет приличное время обработки одного окна. Соответственно в случае требования реального времени (частая задача в обработке сигналов), может не получиться уложиться...

S>Конечно же, никто в здравом уме не применяет "естественный способ" для вычисления ДФТ. Применяют "эмуляцию" — Fast Fourier Transform, пользуясь некоторыми свойствами комплексной экспоненты.
S>Таким образом, нам удастся снизить асимптоту стоимости до NlogN.

И БПФ точно так же работает на массиве. ) И будет отличаться от примера выше только константой.

S>Но ведь и это — вовсе не идеальный способ. Правильное решение поставленной задачи работает за O(N). Вот только сможете ли вы его найти, если вам поставить задачу "через массив"?

В случае отсутствия массива, о каком собственно N будет идти речь? )

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

K>Так я и продемонстрировал.

И где был какой-то вменяемый код и диаграмма к нему? )

K>Я вам задаю вопросы, вы не них не отвечаете, но требуете от меня код подтверждающий мою точку зрения.
K>Но у меня ее по этому вопросу нет. Вы утверждаете, что для использования с ФЯ в UML 1) Нужно что-то добавить, но что — не говорите. 2) Много такого, что в ФЯ не востребовано. Тут во-первых, не понятно, что в этом является проблемой. Во-вторых, это очень сомнительное утверждение, которое вы пытались подтвердить примерами, что в хаскеле якобы нет привязки словаря методов, хотя на самом деле она есть.

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

K>Моя позиция тут заключается в том, что я не вижу, в чем проблема использовать UML с ФЯ, с учетом того, что UML используется с другими языками, в которых тот ООП, который вы классическим считаете, расширен. Собственно, других ООП языков — не расширенных — и нет. Каким образом я должен "подтверждать" свой скепсис тут?

Разве не очевидна разница? ) Если мы возьмём обычный популярный редактор UML и постараемся применить его к такому "расширенному" языку, то у нас возникнут только незначительные затруднения с придумыванием отображения небольшой части кода. В случае же попытки использовать такой редактор с Хаскелем, то нам собственно говоря придётся придумывать как нам отобразить хоть что-нибудь. И не уверен, что это получится без модификации редактора.

K>Легким является скорее только построение легкой иерархической архитектуры. Утверждения о том, что ООП и UML подходят для описания/визуализации сложной иерархической архитектуры мне кажутся сомнительными.

Можете назвать инструменты получше? )

K>Про заточенность диаграммы классов под ООП вы тоже все повторяете и повторяете, но вот только никак не можете сформулировать, в чем же эта заточенность проявляется?

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

K>Про 0 примеров — это явная неправда, я в самом начале дал ссылку на UML-диаграмму для кода на хаскеле http://hackage.haskell.org/package/lens , в которой как раз симула-лайк инструментарий не используется, а то, что используется, в ООЯ отсутствует.

Речь шла про ваши примеры, а не сторонние. Но тот кстати тоже весьма показателен. )))

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

Тогда сложится интересная ситуация... В диаграммке задумка архитектора будет видна, а вот в коде ничего подобного не будет... )

Это ещё раз подчеркнёт несовместимость UML и Хаскеля. Причём из этого примера виден характер несовместимости: UML нормально задаёт такие архитектурные вещи, а Хаскель нет.

_>>то в обычно в ООП функции принадлежащие классу и не принадлежащие классу, видят его очень по разному... И именно в этом заключается основной смысл, а не просто в принятие скрытого параметра определённого типа.
K>Да, включение функции в прямоугольник так же показывает доступ к приватным полям. Но как я уже не один раз говорил, доступ в разных языках регулируется разными способами.

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

K>...

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


_>>А зачем обязательно сразу Qt повторять? ) Это же собственно не просто GUI библиотека, а жирный фреймворк. Нормальные GUI библиотеки на порядки легче и пишутся очень быстро.
K>Ну да, наверное какие-нибудь GTK и WPF-ы на "порядки легче". Но на самом деле нет.

Это тоже довольно жирные. Речь скорее про какой-нибудь FLTK и т.п. ) Только в распиаренном функциональном стиле...

_>>Действительно существует множество языков с гораздо более мощным метапрограммированием, чем в C++. Только вот все они где-то в области маргинальных. А если мы хотим что-то из мейнстрима и при этом с МП, то... )

K>Это никак не делает C++ не убогим. Это только говори о том, что в мейнстриме убогость — норма. В числе прочего — и метапрограммирование.

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

Кстати, вот интересный вопрос у меня появился, хотя и не совсем по теме. А существует ли на ваш взгляд какой-то не убогий системный (т.е. позиционируемый на замену C/C++ — такие же задачи всё равно надо решать и сейчас) язык программирования? Пускай даже и совсем совсем не мейнстримный и с убогой инфраструктурой.

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

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

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

Не только (см. выше).

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

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

_>>Что касается лямбд в C++... http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc — с нынешними темпами развития, боюсь что это Хаскелю скоро придётся догонять. )))
K>Ни какой язык без ГЦ по части лямбд никогда догонять не придется.

Ну ну))) Пример то глянули? ) Кстати, как у Хаскеля обстоят дела с функциями произвольного числа аргументов? ) И как это сочетается с лямбдами? )

_>>Никаких dsl нет — просто пишется код на этом языке. И собственно зачем dsl, если этот язык приблизительнo такого же уровня как C++? )
K>Затем, чтоб писать код на языке более высокого уровня, очевидно же.

В данном случае уровень языка отлично сочетается с задачей. ) Да, и вы так и не пояснили как мне применить конвейеры тут...

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

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

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

_>>У нас уже есть прямо в языке std::thread, соответственно добавив к ним шаблонные функции типа send и receive и договорившись не использовать другие способы обмена данными (типа общей памяти) между потоками, мы уже получим полноценный вариант модели акторов.
K>Спасибо, подозрения о уровне полноценности подтвердились.

И что по вашему ещё должно обязательно входить в реализацию модели акторов? )

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

Копирование только в случае если это не последняя версия. А при расширение от последней (собственно только этот случай и происходил в той нашей задачке) никакого копирования.

K>Опять двадцать пять.

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

K>1) Для хоть сколько-нибудь нетривиальных иммутабельных структур данных вы стеком не обойдетесь.

Смотря что называть стеком. Скажем vector<Struct> лежащий в стеке (но при этом сами данные естественно где-то в динамической памяти) — это у нас как считается? )

K>2) С какой стати пул эффективнее ГЦ на сценариях использования иммутабельных объектов? Вы не сможете освободить большинство пулов, в каждом останется 5% живых объектов. Эффективность, конечно, лучше некуда.

Мы используем пул не в качестве сборщика мусара (некой универсальной штуки, работающей со всей памятью в программе), а используя знания о конкретной задаче. Т.е. используется точное "внешнее" знание о времени жизни объектов, а не отслеживание их системой. Собственно пример выше уже был, но т.к. там пул был всего один, это не было особо очевидно. Ну могу привести ещё простейший пример... Вот допустим у нас программа работает с некоторыми документами. Мы можем заводить по пулу на каждый документ, размещать в нём всё связанное с документом и соответственно убивать его при закрытие. Понятна идея? )

Но вообще говоря это всё требуется только для очень специфических задач (которые однако частенько приводят любители Java и т.п. при сравнение быстродействия с C++). А для подавляющего большинства обычный RAI в C++ является эффективнее любых сборщиков мусора.

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

_>Так а лицензия на винду то входит в эту цену или нет? )
Конечно. Windows Server 2012 R2/2008 R2
_>P.S. Цена по ссылке 10 баксов, хотя это и не принципиально тут. )))

Cheap Windows VPS Hosting / Hyper-V Hosting — $7.99/m

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

_>Вообще то даже в таком случае будет что-то вроде O(N), т.к. подобный фильтр естественно применяется не ко всему массиву (кстати, частенько "бесконечному" во времени), а к некоторому окну (размер которого зависит от требуемых частот). Просто в случае использования ДПФ будет приличное время обработки одного окна. Соответственно в случае требования реального времени (частая задача в обработке сигналов), может не получиться уложиться...
Ну вы если передёргиваете, то делайте это последовательно. Если вы зафиксировали N, то, естественно, никакой асимптотики по нему не будет. Но откуда тогда O(N)? Будет тупо O(1). И c БПФ будет О(1). Но это жульничество вам ничем не поможет — потому что тем асимптотика и отличается, что при увеличении размера окна "наивная" программа быстро вылетит за пределы применимости.
_>В случае отсутствия массива, о каком собственно N будет идти речь? )
Я говорю не про отсутствие массива, а о способе постановке задачи.
Вот у нас по прежнему есть массив в N отсчётов. Нужно вырезать из данных колебания с частотой выше некоторой f0.
Если вы будете настаивать на постановке в стиле "преобразовать массив" и "умножить массив на массив", то получите на выходе фигню, а не решение.

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

_>>Так а лицензия на винду то входит в эту цену или нет? )
S>Конечно. Windows Server 2012 R2/2008 R2

Хех, интересно с чего это они такие щедрые... В обычных местах за неё платят приличные деньги. )

_>>P.S. Цена по ссылке 10 баксов, хотя это и не принципиально тут. )))
S>

S>Cheap Windows VPS Hosting / Hyper-V Hosting — $7.99/m

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

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

S>Ну вы если передёргиваете, то делайте это последовательно. Если вы зафиксировали N, то, естественно, никакой асимптотики по нему не будет. Но откуда тогда O(N)? Будет тупо O(1). И c БПФ будет О(1). Но это жульничество вам ничем не поможет — потому что тем асимптотика и отличается, что при увеличении размера окна "наивная" программа быстро вылетит за пределы применимости.

N (размер данных для обработки) мы не фиксируем. Фиксируется (на основание данных о необходимых частотах) размер окна W. Далее, наши данные делятся на окна, каждое из которых обрабатывается с помощью ДПФ или БПФ или ещё чем-то. От выбора алгоритма соответственно зависит время обработки окна T(W). А общее время обработки нашего набора данных будет равно N*T(W)/W, т.е. O(N). Кстати, если взять например для ДПФ значение T(W) в виде C*W^2, то можно увидеть упрощённое значение для всего набора данных в виде N*W*C, которое интуитивно очевидно.

S>Я говорю не про отсутствие массива, а о способе постановке задачи.
S>Вот у нас по прежнему есть массив в N отсчётов. Нужно вырезать из данных колебания с частотой выше некоторой f0.
S>Если вы будете настаивать на постановке в стиле "преобразовать массив" и "умножить массив на массив", то получите на выходе фигню, а не решение.

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

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

_>>>P.S. Цена по ссылке 10 баксов, хотя это и не принципиально тут. )))
S>>

S>>Cheap Windows VPS Hosting / Hyper-V Hosting — $7.99/m

_>Это скидка при оплате сразу целого года вперёд — тогда и у хостинга из моего примера надо было аналогичную цену смотреть. )
Смотрите. Даже если вы будете настаивать на помесячной оплате (потому что у вашего хостинга другой нету), то $10 всё равно меньше E8, и характеристики машинки там значительно лучше.

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

_>N (размер данных для обработки) мы не фиксируем. Фиксируется (на основание данных о необходимых частотах) размер окна W.
Частота среза — это параметр задачи, меняется от запуска к запуску. Давайте, расскажите мне о выборе окна на основе частоты среза.

_> Далее, наши данные делятся на окна, каждое из которых обрабатывается с помощью ДПФ или БПФ или ещё чем-то. От выбора алгоритма соответственно зависит время обработки окна T(W). А общее время обработки нашего набора данных будет равно N*T(W)/W, т.е. O(N). Кстати, если взять например для ДПФ значение T(W) в виде C*W^2, то можно увидеть упрощённое значение для всего набора данных в виде N*W*C, которое интуитивно очевидно.
Это вы сейчас всё ещё о постановке задачи, или уже о вашем решении?
Если о постановке — то она как бы ущербна в самом начале, т.к. вы добавляете в неё отсутствующие в формулировке задачи подробности.

S>>Я говорю не про отсутствие массива, а о способе постановке задачи.
S>>Вот у нас по прежнему есть массив в N отсчётов. Нужно вырезать из данных колебания с частотой выше некоторой f0.
S>>Если вы будете настаивать на постановке в стиле "преобразовать массив" и "умножить массив на массив", то получите на выходе фигню, а не решение.

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

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

_>>N (размер данных для обработки) мы не фиксируем. Фиксируется (на основание данных о необходимых частотах) размер окна W.
S>Частота среза — это параметр задачи, меняется от запуска к запуску. Давайте, расскажите мне о выборе окна на основе частоты среза.

Выбор окна происходит не по параметрам фильтра, а по параметрам входного сигнала. К примеру если речь идёт о звуковом сигнале, то мы сразу вспоминаем, что человек слышит его только в пределах 16-22000 Гц, и это тут же однозначно даёт нам предельные параметры как для частоты дискретизации, так и для размера окна преобразования Фурье. Естественно можно задрать эти параметры и выше, но это будет бессмысленной тратой ресурсов. А вот скажем если мы работает с речью, то диапазон становится вообще всего 300-4000 Гц и работать ещё намного проще (успевать в реальном времени).

S>Это вы сейчас всё ещё о постановке задачи, или уже о вашем решении?
S>Если о постановке — то она как бы ущербна в самом начале, т.к. вы добавляете в неё отсутствующие в формулировке задачи подробности.

Это было пояснение почему на практике и ДПФ и БПФ являются О(N) по входному сигналу. Другое дело, что в технике обработки сигналов важен как раз коэффициент при N, т.к. частенько подобная обработка идёт в реальном времени (а N соответственно является вообще "бесконечным"). В этом кстати большое отличие от классических научных числодробилок, где никаких ограничений по времени нет, но зато имеются гигабайты модельных данных (значения величин на решётках и т.п.). И кстати говоря в данной темке именно о распараллеливание таких вещей шла речь.

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

Я так и не понял пока к чему вы влезли в тему про распараллеливание числодробилок с этим своим примером. Вы хотели как-то опровергнуть мой тезис о том, что эти задачи покрывает сочетание mpi+openmp или собственно что? )

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

_>И где был какой-то вменяемый код и диаграмма к нему? )

Я переписал один класс на хаскель. Что изменится если переписать три? Диаграмма будет отличаться заменой наследования на имплементацию.
Вот полное переписывание, один-в-один:

data MyView = MyView {
    drawView :: UI () -- рисуем что-то в окне
}
instance View MyView where onDraw = drawView

data MyWindow = MyWindow {
    menu :: Menubar,
    tools :: Toolbar,
    view :: MyView,
    status :: Statusbar,
    onViewClear :: UI () -- реакция на меню/тулбар/хоткей
}
instance Window MyWindow
myWindow :: MyWindow -- установка элементов по местам и настройка реакций на события

data MyApp = MyApp {
    window :: MyWindow
    withMyApp :: (MyApp -> UI r) -> UI r -- Инициализация/деинициализация каких-нибудь библиотек
}
instance App MyApp

main = runUI $ withMyApp mainLoop

хотя на хаскеле это скорее иначе напишут.

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

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

_>знаем позиции друг друга, но это ни к чему конструктивному не привело.

Нет, содержательную часть вашей позиции я не знаю. Вы ее не озвучили.

_>Поэтому я предложил перейти к примерам с конкретным кодом

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

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

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

_>Разве не очевидна разница? ) Если мы возьмём обычный популярный редактор UML и постараемся применить его к такому "расширенному" языку, то у нас возникнут только незначительные затруднения с придумыванием отображения небольшой части кода. В случае же попытки использовать такой редактор с Хаскелем, то нам собственно говоря придётся придумывать как нам отобразить хоть что-нибудь.

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

K>>Легким является скорее только построение легкой иерархической архитектуры. Утверждения о том, что ООП и UML подходят для описания/визуализации сложной иерархической архитектуры мне кажутся сомнительными.
_>Можете назвать инструменты получше?

Могу, конечно. Это ФП.

_>Уже обсуждалось, не буду повторяться. Но если вы считаете, что никаких проблем у Хаскеля нет, то я по прежнему жду тот пример кода и диаграмму к нему —

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

_>это будет хорошим аргументом, что никакой заточенности нет. )))

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

K>>Про 0 примеров — это явная неправда, я в самом начале дал ссылку на UML-диаграмму для кода на хаскеле http://hackage.haskell.org/package/lens , в которой как раз симула-лайк инструментарий не используется, а то, что используется, в ООЯ отсутствует.

_>Речь шла про ваши примеры, а не сторонние. Но тот кстати тоже весьма показателен. )))

Вы эту показательность можете как-нибудь раскрыть?

_>Тогда сложится интересная ситуация... В диаграммке задумка архитектора будет видна, а вот в коде ничего подобного не будет... )
_>Это ещё раз подчеркнёт несовместимость UML и Хаскеля. Причём из этого примера виден характер несовместимости: UML нормально задаёт такие архитектурные вещи, а Хаскель нет.

Почему? Где в хаскеле непонятна связь функции с типом, на котором она определена? Лично мне даже понятнее, с чем работает хаскельная функция, чем функция в каком-нибудь ООЯ.

_>>>то в обычно в ООП функции принадлежащие классу и не принадлежащие классу, видят его очень по разному... И именно в этом заключается основной смысл, а не просто в принятие скрытого параметра определённого типа.
K>>Да, включение функции в прямоугольник так же показывает доступ к приватным полям. Но как я уже не один раз говорил, доступ в разных языках регулируется разными способами.

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

K>>...

_>Здесь пропустил кучу отмазок от предложения продемонстрировать тот тривиальный код и диаграммку к нему. Вообще говоря я не вижу смысла в дальнейшем продолжение дискуссии на тему UML в таком стиле (я прошу показать пример, а в ответ получаю некие пространные рассуждения и отмазки).

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

_>Это тоже довольно жирные. Речь скорее про какой-нибудь FLTK и т.п. )

Возможно какие-то такие поделки и существуют, не интересовался таким вопросом, так что ничего про них сказать не могу.
Общий подход к такой проблеме для хаскеля такой: EDSL для построения / интерпретации дерева. Deep или shallow embedding, интерпретация дерева — сворачиванием моноидами какими-нибудь.

_>Только в распиаренном функциональном стиле...

Не сказал бы, что функциональный стиль "распиарен". В лучшем случае кое-кому известен в узких кругах.

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

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

_>Кстати, вот интересный вопрос у меня появился, хотя и не совсем по теме. А существует ли на ваш взгляд какой-то не убогий системный (т.е. позиционируемый на замену C/C++ — такие же задачи всё равно надо решать и сейчас) язык программирования? Пускай даже и совсем совсем не мейнстримный и с убогой инфраструктурой.

Нет конечно, не существует и не может существовать. Потому, что неубогость требует жертв, которые в этой области применения позволить себе нельзя. (Т.е. можно, конечно, сделать язык несколько менее убогий чем C++, но не принципиально, так что перламутровые пуговицы не перевесят труда, который уже вложен в C++). Единственный способ каким можно решить проблему убогости в этой области, это разве что генерация C из EDSL в высокоуровневых языках. В этом направлении кое-какие работы ведутся.

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

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

_>Ну ну))) Пример то глянули? )

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

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

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

_>В данном случае уровень языка отлично сочетается с задачей. )

Да ну?

_>Да, и вы так и не пояснили как мне применить конвейеры тут...

Чего тут объяснять? Вместо фортранолапши с циклами — комбинаторы комбинируете.

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

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

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

_>И что по вашему ещё должно обязательно входить в реализацию модели акторов? )

Что бы там по-моему не должно было быть, все вами будет, конечно, отметено как ненужное.

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

_>Копирование только в случае если это не последняя версия.

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

_>А при расширение от последней (собственно только этот случай и происходил в той нашей задачке) никакого копирования.

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

_>Да да, мы это уже обсуждали и вы приводили в точности такие же аргументы. Правда я не пойму как вы их повторяете сейчас, после того, как я продемонстрировал как раз пример основанный на стеке и пуле.

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

K>>1) Для хоть сколько-нибудь нетривиальных иммутабельных структур данных вы стеком не обойдетесь.
_>Смотря что называть стеком. Скажем vector<Struct> лежащий в стеке (но при этом сами данные естественно где-то в динамической памяти) — это у нас как считается? )

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

K>>2) С какой стати пул эффективнее ГЦ на сценариях использования иммутабельных объектов? Вы не сможете освободить большинство пулов, в каждом останется 5% живых объектов. Эффективность, конечно, лучше некуда.
_>Мы используем пул не в качестве сборщика мусара (некой универсальной штуки, работающей со всей памятью в программе), а используя знания о конкретной задаче. Т.е. используется точное "внешнее" знание о времени жизни объектов, а не отслеживание их системой.

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

_>Собственно пример выше уже был, но т.к. там пул был всего один, это не было особо очевидно. Ну могу привести ещё простейший пример... Вот допустим у нас программа работает с некоторыми документами. Мы можем заводить по пулу на каждый документ, размещать в нём всё связанное с документом и соответственно убивать его при закрытие. Понятна идея? )

А если 90% данных между документами разделяются? Вот иммутабельная структура данных — это набор таких документов. Понятна идея?

_>Но вообще говоря это всё требуется только для очень специфических задач (которые однако частенько приводят любители Java и т.п. при сравнение быстродействия с C++). А для подавляющего большинства обычный RAI в C++ является эффективнее любых сборщиков мусора.

Это естественно, потому что то, что могут позволить себе программисты на более-менее высокоуровневом языке — программисты на низкоуровневом позволить себе не могут. Разумеется, все что позволить себе нельзя объявляется ненужным и вообще "специфическим" — сегодня в колбасе потребности нет. Программисты на Java могут позволить себе работу с иммутабельными структурами, программисты на D — не могут. Ну и под "поддержкой иммутабельности" вы всю дорогу понимаете осознанную необходимость иммутабельность не использовать.

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

K>Я переписал один класс на хаскель. Что изменится если переписать три? Диаграмма будет отличаться заменой наследования на имплементацию.
K>Вот полное переписывание, один-в-один:
K>...

Эмм, имплементация? А что тогда будет в случае, если мы продолжим эту диаграммку выше (к примеру понятно, что View, Menubar, Toolbar и т.п. наследованы от одного общего класса, тоже библиотечного)? T.e. имплементация подходит для случая интерфейс->реализаций, но это ровно один уровень иерархии, а в любой GUI библиотеке их намного больше.

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

K>хотя на хаскеле это скорее иначе напишут.

С удовольствием познакомлюсь как пишут подобное в Хаскеле. Я серьёзно. ) Потому как пока-что я видел на Хаскеле только использование чужих GUI библиотек с соответствующей (и давно привычной мне) архитектурой.

K>Нет, содержательную часть вашей позиции я не знаю. Вы ее не озвучили.

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

K>Поправка: вы предложили мне перейти к примерам с конкретным кодом. Сами же ни разбора проблем со "страшними монадами" на конкретном коде, ни реализации для моей задачки про поддержку иммутабельности так и не привели.

А чем не понравилась та последняя реализация на D? ) Там же даже цикла нет — рекурсией заменил. )))

Да, кстати, самое забавное, что решение со 100% настоящей имммутабельностью было у меня давным давно — я его первым опубликовал. И оно работало действительно очень долго (за счёт постоянного копирования всего массива). И великолепно ускорялось переходом к мутабельному коду (заменой соответствующего оператора). Я бы на вашем месте сразу же уцепился за него в качестве доказательства отсутствия оптимизации под иммутабельность и собственно говоря никто бы и не смог возразить. Но вы почему-то не увидели, что там всё по честному, и захотели чтобы для иммутабельных данных применялась специальная структура (а не стандартный массив с модификатором immutable). Ну захотели — получите. Только уже с добавленной оптимизацией и соответственно заметно быстрее версии на Хаскеле. )))

_>>Разве не очевидна разница? ) Если мы возьмём обычный популярный редактор UML и постараемся применить его к такому "расширенному" языку, то у нас возникнут только незначительные затруднения с придумыванием отображения небольшой части кода. В случае же попытки использовать такой редактор с Хаскелем, то нам собственно говоря придётся придумывать как нам отобразить хоть что-нибудь.
K>Непонятно, откуда вы выводите незначительные затруднения с одной стороны и значительные с другой.
K>Вы эту свою мысль как-то развить можете?

Эмм, разве не очевидно? Обычный UML редактор очевидно не умеет никаких методов выходящих за стандарт. Соответственно если мы будем с помощью него рисовать диаграммку для "расширенного ООП языка", то нам надо будет как-то придумать отображение для эти расширений. Но только для них (сколько то там процентов кода), а основная часть прорисуется вполне канонически. Собственно говоря частенько (когда на расширения приходятся всякие мелкие сервисные вещи, типа переопределения операторов для удобства и т.п.) мы можем вообще полностью описать архитектуру приложения даже и без придумывания нестандартных отображений — просто их не будет на диаграммке и всё (мы же не собираемся генерировать по ней код). В случае же Хаскеля грубо говоря вся программка целиком состоит только из таких "расширений", так что путь только один — придумывать и ещё раз придумывать. Причём даже если и сможем что-то сваять для себя, то другому программисту на Хаскеле такую диаграммку так просто и не покажешь — он же не знает "нотацию". Или что ещё хуже, у него уже есть своя, другая. )))

_>>Можете назвать инструменты получше?
K>Могу, конечно. Это ФП.

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

K>Возможно какие-то такие поделки и существуют, не интересовался таким вопросом, так что ничего про них сказать не могу.
K>Общий подход к такой проблеме для хаскеля такой: EDSL для построения / интерпретации дерева. Deep или shallow embedding, интерпретация дерева — сворачиванием моноидами какими-нибудь.

EDSL? В Хаскеле появилось нормальное метапрограммирование?

_>>Только в распиаренном функциональном стиле...
K>Не сказал бы, что функциональный стиль "распиарен". В лучшем случае кое-кому известен в узких кругах.

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

_>>Кстати, вот интересный вопрос у меня появился, хотя и не совсем по теме. А существует ли на ваш взгляд какой-то не убогий системный (т.е. позиционируемый на замену C/C++ — такие же задачи всё равно надо решать и сейчас) язык программирования? Пускай даже и совсем совсем не мейнстримный и с убогой инфраструктурой.

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

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

Кстати, а для не требующих мощности (низкоуровневой) C++ проектов (и если они не особо крупные) мне в последнее время нравится применять вообще Питон. Очень быстро получается результат.

А вот для Хаскеля я что-то не вижу такой однозначной ниши.

K>Да, не понял, что там выдающегося по части лямбд. Там вроде обобщенная работа с кортежами демонстрируется.

Ну демонстрировалась там собственно новинка C++ — те самые полиморфные лямбды. В общем то ничего особенного, просто лямбдам разрешили поведение как и у обычных шаблонных функций (которые могут иметь произвольное число параметров произвольных типов). Однако такой простой и очевидный шаг дал много интересных техник (через возврат замыкания и т.п.), которые частично и демонстрировались в этом коде на примере реализации классических приёмов ФП.

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

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

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

K>Чего тут объяснять? Вместо фортранолапши с циклами — комбинаторы комбинируете.

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

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

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

Так вот прямо же по той моей ссылке theron-library.com/index.php?t=page&p=performance график, а под ним таблица с цифрами. А в самом начале страницы идут ссылки на описание каждого теста: постановка задачи и полный исходный код. Типа такого theron-library.com/index.php?t=page&p=threadring.

Хм, сейчас заметил, что форум работает некорректно и портит ссылки: заменяет & на &amp;. Поменял ссылки на просто текст.

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

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

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

С чего бы это? Как раз мутабельной копирование не требуется.

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

А что там этим примером? Ответ выдаёт неправильный или работает не быстро? )

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

Ну так если в дополнение к стеку будет разрешено делать ещё new/delete (только для больших данных) внутри классов (т.е. наружу не выходит и управляется через RAII и тот же стек), то уже будет достаточно для подавляющего числа задач.

K>Так в этом и проблема. В общем случае, в высокоуровневом коде знания о времени жизни нет.

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

K>А если 90% данных между документами разделяются? Вот иммутабельная структура данных — это набор таких документов. Понятна идея?

Идея понятна. Но не понятен пример реальных разделяемых данных в каких-то редакторах. Я вот вспоминаю что Word, что Excel (про программистские редакторы вообще молчу), что графические, везде максимум ссылки между документами встречаются и никакого разделения. Может быть такие вот иммутабельные структуры решают очередную виртуальную академическую проблему? )

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

_>Эмм, имплементация? А что тогда будет в случае, если мы продолжим эту диаграммку выше (к примеру понятно, что View, Menubar, Toolbar и т.п. наследованы от одного общего класса, тоже библиотечного)? T.e. имплементация подходит для случая интерфейс->реализаций, но это ровно один уровень иерархии, а в любой GUI библиотеке их намного больше.

Ну так иерархия "интерфейсов"-то многоуровневая. Т.е. все основные средства доступные в UML задействованы.

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

Да какая разница? Спецификаторы видимости из UML задействовать можно.

_>С удовольствием познакомлюсь как пишут подобное в Хаскеле. Я серьёзно. ) Потому как пока-что я видел на Хаскеле только использование чужих GUI библиотек с соответствующей (и давно привычной мне) архитектурой.

Полностью хаскельного GUI я не знаю, но есть библиотеки родственные всякому лайауту виджетов — вроде http://projects.haskell.org/diagrams/ — вот это полностью идиоматичная хаскельная библиотека. Основной принцип устройства описан здесь: http://www.cis.upenn.edu/~byorgey/pub/monoid-pearl.pdf

_>Основной мой тезис в этой части нашей дискуссии был такой: UML (как пример одного из важных промышленных инструментов) не адаптирован к ФП вообще и к Хаскелю в особенности (т.к. там не только ФП, но и ещё ленивость).

Интересный поворот. А почему ленивость важна в этом аспекте?

_>Причём похоже никто и не шевелится что-то исправлять в данном направление. И понятно почему: хотя ФП методы активно проникают в промышленное программирование, но к построению общей архитектуры приложения (каркаса так сказать) это отношения не имеет — там царит ООП.

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

_>А чем не понравилась та последняя реализация на D? ) Там же даже цикла нет — рекурсией заменил. )))

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

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

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

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

Я не увидел, что там "все по честному" потому, что там не все "по честному". И для иммутабельных данных должна применяться не "специальная" мутабельная структура, а структура иммутабельная. насколько она будет "специальной" уже не важно.

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

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

_>Эмм, разве не очевидно? Обычный UML редактор очевидно не умеет никаких методов выходящих за стандарт.

Что, "обычный UML редактор" не поддерживает стереотипы и подписи к отношениям? А других точек расширения и не нужно.

_>В случае же Хаскеля грубо говоря вся программка целиком состоит только из таких "расширений"

На самом деле нет.

_>Причём даже если и сможем что-то сваять для себя, то другому программисту на Хаскеле такую диаграммку так просто и не покажешь — он же не знает "нотацию". Или что ещё хуже, у него уже есть своя, другая. )))

Да, то, что программист на хаскеле вообще не знает UML — вполне вероятно. Если же он знает, то вполне сможет разобраться.

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

По-моему, "толстые тома" — это как раз верный признак, что проектирование с помощью ООП совсем нетривиально.
Впрочем, все наработки ООП дизайна применимы в ФП в полном объеме.

_>А чего-то подобного на тему ФП я что-то не видел.

Действительно, таких текстов для ФП все равно что нет, ну так это понятно, учитывая ничтожное количество текстов по ФП вообще. Тем не менее, кое-что на эту тему есть, как начального уровня вроде
http://www.haskellforall.com/2012/08/the-category-design-pattern.html
http://www.haskellforall.com/2012/09/the-functor-design-pattern.html
http://www.haskellforall.com/2014/04/scalable-program-architectures.html
так и более продвинутого вроде
http://conal.net/papers/type-class-morphisms/

_>EDSL? В Хаскеле появилось нормальное метапрограммирование?

Для EDSL метапрограммирование не нужно. Но вообще оно в хаскеле появилось больше 10 лет назад. Насколько оно нормальное — отдельная история, думаю нормальнее, чем у 95% языков.

_>Имелась в виду наша дискуссия. ))) Ну а так на самом деле отдельные методы ФП сейчас весьма активно проникают в промышленное программирование. Но именно как отдельные техники, применяемые императивными языками внутри ООП каркасов. )))

Это как раз понятно, потому что никаких выразительных средств кроме ООП инструментария в промышленных языках фактически нет. Впрочем, все равно требуется широкое толкование термина "ООП", потому что те же иммутабельные "объекты" — это, по-моему, никакое не ООП, это совсем другие подходы, которые просто энкодятся ООП средствами (единственно доступными в языках).

_>Т.е. по сути вы согласны что C++ — это сейчас оптимальный выбор для определённого класса задач?

Оптимальный выбор между чем и чем? C++ и C++?

_>Тогда наши споры приобретают несколько другой характер: обсуждения собственно границ применимости. )))

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

_>Кстати, а для не требующих мощности (низкоуровневой) C++ проектов (и если они не особо крупные) мне в последнее время нравится применять вообще Питон. Очень быстро получается результат.

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

K>>Да, не понял, что там выдающегося по части лямбд. Там вроде обобщенная работа с кортежами демонстрируется.

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

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

_>Однако такой простой и очевидный шаг дал много интересных техник (через возврат замыкания и т.п.), которые частично и демонстрировались в этом коде на примере реализации классических приёмов ФП.

Ну так возврат замыкания все равно без GC останется инвалидным.

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

Нормально в хаскеле с динамикой развития. Те же концепты обещают еще с тех времен, когда хаскеля в современном понимании можно сказать что и не было еще, так что довольно странно представлять C++ как "динамично развивающийся". По сравнению с явой или фортраном — возможно.

_>Такой ответ уже был. После чего я попросил уточнить на конкретном примере моей конкретной задачи, т.к. я не увидел как применить такое к ней. И теперь мы снова вернулись сюда же? )

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

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

_>Ну так в отличие от довольно мутного понятия "поддержка иммутабельности в языке" модель акторов имеет подробные описания... )

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

_>С чего бы это? Как раз мутабельной копирование не требуется.

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

_>А что там этим примером? Ответ выдаёт неправильный или работает не быстро? )

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

_>Ну так если в дополнение к стеку будет разрешено делать ещё new/delete (только для больших данных) внутри классов (т.е. наружу не выходит и управляется через RAII и тот же стек), то уже будет достаточно для подавляющего числа задач.

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

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

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

_>Идея понятна. Но не понятен пример реальных разделяемых данных в каких-то редакторах. Я вот вспоминаю что Word, что Excel (про программистские редакторы вообще молчу), что графические, везде максимум ссылки между документами встречаются и никакого разделения.

10 правок дают 11 версий документов, разделяющих 90% данных. Речь, впрочем, была не про пользовательские документы, а про структуры данных, с которыми программист работает.

_>Может быть такие вот иммутабельные структуры решают очередную виртуальную академическую проблему? )

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

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

_>>Эмм, имплементация? А что тогда будет в случае, если мы продолжим эту диаграммку выше (к примеру понятно, что View, Menubar, Toolbar и т.п. наследованы от одного общего класса, тоже библиотечного)? T.e. имплементация подходит для случая интерфейс->реализаций, но это ровно один уровень иерархии, а в любой GUI библиотеке их намного больше.
K>Ну так иерархия "интерфейсов"-то многоуровневая. Т.е. все основные средства доступные в UML задействованы.

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

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

K>Да какая разница? Спецификаторы видимости из UML задействовать можно.

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

K>Полностью хаскельного GUI я не знаю, но есть библиотеки родственные всякому лайауту виджетов — вроде http://projects.haskell.org/diagrams/ — вот это полностью идиоматичная хаскельная библиотека. Основной принцип устройства описан здесь: http://www.cis.upenn.edu/~byorgey/pub/monoid-pearl.pdf

Да, любопытно. Кстати, такие "dsl" же легко и на C++ делаются. Правда для вывода графики не помню подобных решений. Помню для других целей. Но в любом случае, это всё немного не то. Потому как главное в GUI библиотеке всё же не просто удобная обёртка над API вывода на экран, а ещё и удобная система обработчиков событий (и соответственно куча уже написанных обработчиков в библиотечных виджетах). И именно тут ООП ложится особенно логично. А для просто вывода на экран действительно ООП совсем не обязательно — эту проблему умеет решать вообще какой-нибудь postscript. )))

_>>Основной мой тезис в этой части нашей дискуссии был такой: UML (как пример одного из важных промышленных инструментов) не адаптирован к ФП вообще и к Хаскелю в особенности (т.к. там не только ФП, но и ещё ленивость).
K>Интересный поворот. А почему ленивость важна в этом аспекте?

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

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

Так у меня там собственно и конвейера нет. ) А с чего это он обязательно должен быть? ) У нас вроде как была просто задачка на простые числа в контексте разговора о поддержки иммутабельности. Данная задачка не требует обязательного конвейера.

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

Ну так с вашей точки зрения "immutable int[]" в D является иммутабельной структурой или нет? )

K>Прямой обман, никакой наблюдаемой разницы с аналогом на хаскеле получить не удалось.

Да, да, я помню эти ваши тесты. С отказом запускать присланный exe, выборами подходящих компиляторов и т.п. )))

K>Что, "обычный UML редактор" не поддерживает стереотипы и подписи к отношениям? А других точек расширения и не нужно.

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

_>>Причём даже если и сможем что-то сваять для себя, то другому программисту на Хаскеле такую диаграммку так просто и не покажешь — он же не знает "нотацию". Или что ещё хуже, у него уже есть своя, другая. )))
K>Да, то, что программист на хаскеле вообще не знает UML — вполне вероятно. Если же он знает, то вполне сможет разобраться.

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

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

K>По-моему, "толстые тома" — это как раз верный признак, что проектирование с помощью ООП совсем нетривиально.
K>Впрочем, все наработки ООП дизайна применимы в ФП в полном объеме.

Ну тома то там больше для разъяснения. Хотя сами принципы (речь про такие https://ru.wikipedia.org/wiki/SOLID_%28%D0%BE%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%29 вещи) довольно простые.

K>Действительно, таких текстов для ФП все равно что нет, ну так это понятно, учитывая ничтожное количество текстов по ФП вообще. Тем не менее, кое-что на эту тему есть, как начального уровня вроде
K>http://www.haskellforall.com/2012/08/the-category-design-pattern.html
K>http://www.haskellforall.com/2012/09/the-functor-design-pattern.html
K>http://www.haskellforall.com/2014/04/scalable-program-architectures.html
K>так и более продвинутого вроде
K>http://conal.net/papers/type-class-morphisms/

Интересно. Но снова всё вращается вокруг конвейеров. В то время как в реальных задачах они мне встречаются весьма редко.

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

Всё же на Питоне получится заметно быстрее. Если речь о "проектах" на несколько страничек кода.

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

Ааа, ну да))) Я просто не понял, что вы кортежем обозвали собственно параметры. Тогда да, об этом и речь. Просто там в примере ещё вводится и собственно отдельная сущность tuple... )))

K>Ну так возврат замыкания все равно без GC останется инвалидным.

Мы же это уже обсуждали. Это не было инвалидным даже в старом стандарте, т.к. банальное копирование полностью решает этот вопрос. Просто получается не эффективный код. Ну а с приходом нового стандарта (и move semantics в нём) вопрос эффективной передачи данных вверх по стеку вполне решён.

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

C++ и не был динамично развивающимся. Где-то до последних 5 лет. А сейчас пошёл такими темпами, что некоторые даже пугаются. ))) А другие наоборот радуются и даже перестают планировать переход на альтернативы (типа D и т.п.).

K>Не понимаю, какая тут может быть специфика задачи. Любой цикл можно переписать в виде более понятной комбинации комбинаторов. Что бывают какие-то задачи "безциклового программирования"?

Эммм, я же вроде как ясно описал, что основные циклы закодированы в спец. языке, который гарантирует их распараллеливание (в смысле SIMD). Так что там нужны именно циклы в явном виде. Ну и с какими-то там механизмами абстракций там дела ничуть не лучше голого C. ))) Как туда вставить какие-то конвейеры? Ну а в остальной части кода, которая написана на C++ и в достаточно абстрактном виде (в классических традициях ООП), каких-то подобных циклов вообще не наблюдается.

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

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

Ну можно тогда увидеть ссылку (скажем в той же Википедии) на определение "поддержки иммутабельности в языке"? ) Ссылку на описание модели акторов я естественно без проблем предоставлю. )

_>>С чего бы это? Как раз мутабельной копирование не требуется.
K>Разумеется требуется. Создать версию мутабельной структуры без копирования не получится.

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

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

Всё правильно, речь про RAII. Так вот мы же говорим о практике, а не о теории, не так ли? И соответственно если через RAII получается реализовать скажем 90% задач работы с памятью (а остальное реализуем скажем через подсчёт ссылок и т.п.), то уже получим суперэффективный код. Который будет заметно превосходить все замечательные универсальные сборщики мусора.

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

Возможно. Но такова цена настоящего быстродействия. Но опять же замечу главное — это ситуация для весьма редкого класса задач. А большую часть обычных задач C++ решает эффективнее всех и без написания какого-то специального кода (стандартные методы типа RAII на стеке).

K>Иммутабельные структуры решают реальную проблему, которая называется "удобство программиста". Работать с персистентной версией структуры данных удобнее, чем с эфемерной как раз за счет версионности.

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

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

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

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

K>>Да какая разница? Спецификаторы видимости из UML задействовать можно.
_>Ну вот как раз потому что подобной определённости нет, UML и нельзя по нормальному использовать для Хаскеля. Опять же я говорю про текущий момент, а не про какую-то принципиально неразрешимую проблему.

Не вижу, чем тут хаскель выделяется на фоне других языков, у которых есть некоторые особенности определения видимости. Например, нужно как-то договариваться как friend class в UML обозначить, означает ли это, что использовать UML с C++ нельзя?

_>Кстати, такие "dsl" же легко и на C++ делаются.

Ну да, как и в большинстве языков.

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

Ну так с этого мы и начали, в самом начале разговора я пример такого кода приводил. Библиотеки на которых идиоматичная работа с событиями для хаскеля есть, https://hackage.haskell.org/package/reactive-banana-wx
например.

_>И именно тут ООП ложится особенно логично.

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

_>Мы же это уже подробно обсуждали раньше. Речь про применимость диаграмм деятельности и последовательности — двух самых используемых диаграмм поведения в UML.

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

_>Так у меня там собственно и конвейера нет. ) А с чего это он обязательно должен быть? ) У нас вроде как была просто задачка на простые числа в контексте разговора о поддержки иммутабельности. Данная задачка не требует обязательного конвейера.

Нет, задачка была другая, а именно:

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

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

_>Ну так с вашей точки зрения "immutable int[]" в D является иммутабельной структурой или нет? )

Это зависит от того, какие операции определены на нем и какая у них асимптотика.
С любой точки зрения "immutable int[]" практиченой иммутабельной стрктурой не является, потому что создание версии всегда эквивалентно полному копированию. "Практичность" иммутабельности тут имеет значение потому, что речь о поддержке.

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

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

_>выборами подходящих компиляторов и т.п. )))

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

_>Естественно поддерживает. Но этого недостаточно чтобы отображать скажем вложенные классы и т.п.

Т.е. все языки программирования в которых они есть (а они почти везде есть) с UML не совместимы?

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

Непонятно, почему это не проблема.

_>А в том же Хаскеле, если вы захотите (как вы говорили) отображать модули на диаграмме классов, это сломает весь смысл отображения.

Так ведь не сломает.

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

Какую сущность обозначает квадратик можно написать в стереотипе.

K>>По-моему, "толстые тома" — это как раз верный признак, что проектирование с помощью ООП совсем нетривиально.
_>Ну тома то там больше для разъяснения.

Об этом я и говорю.

_>Хотя сами принципы (речь про такие https://ru.wikipedia.org/wiki/SOLID_%28%D0%BE%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%29 вещи) довольно простые.

Большинство этих принципов никакой ООП специфики не имеют.

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

Вы редко используете более одной функции на всю программу?

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

Сомневаюсь.

K>>Ну так возврат замыкания все равно без GC останется инвалидным.

_>Мы же это уже обсуждали. Это не было инвалидным даже в старом стандарте, т.к. банальное копирование полностью решает этот вопрос. Просто получается не эффективный код.

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

_>Ну а с приходом нового стандарта (и move semantics в нём) вопрос эффективной передачи данных вверх по стеку вполне решён.

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

_>C++ и не был динамично развивающимся. Где-то до последних 5 лет. А сейчас пошёл такими темпами, что некоторые даже пугаются. )))

Для многих языков, особенно с малым числом пользователей и след. малой "инерцией" вроде хаскеля — это вообще-то медленные темпы. (тут должна быть ссылка на то сообщение "эта фича поддерживается уже 11 дней — у вас слишком старая версия Rust")

_>А другие наоборот радуются и даже перестают планировать переход на альтернативы (типа D и т.п.).

Да, для языков, являющихся копиями С++ с перламутровыми пуговицами — это проблема. Хотя понятно, что всех удобств D в C++ скорее всего не будет.

K>>Не понимаю, какая тут может быть специфика задачи. Любой цикл можно переписать в виде более понятной комбинации комбинаторов. Что бывают какие-то задачи "безциклового программирования"?

_>Эммм, я же вроде как ясно описал, что основные циклы закодированы в спец. языке, который гарантирует их распараллеливание (в смысле SIMD). Так что там нужны именно циклы в явном виде.

Зачем они нужны в явном виде? Их надо из комбинаторного DSL генерировать. Именно потому, что...
_>с какими-то там механизмами абстракций там дела ничуть не лучше голого C

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

_>Ну можно тогда увидеть ссылку (скажем в той же Википедии) на определение "поддержки иммутабельности в языке"? ) Ссылку на описание модели акторов я естественно без проблем предоставлю. )

Определение иммутабельных структур данных и в википедии есть: http://en.wikipedia.org/wiki/Persistent_data_structure я пробежал по диагонали первый абзац, вроде все правильно, также написано зачем для поддержки нужен ГЦ, и какимим свойствами должны обладать версии.
"Поддержка" же понимается в общеупотребимом смысле, а не в вашем, когда она означает то же, что и "отсутствие поддержки".

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

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

_>Всё правильно, речь про RAII. Так вот мы же говорим о практике, а не о теории, не так ли?

Да мы говорим о практике, когда попробовали писать идеоматический высокоуровневый код без ГЦ, но с выводом регионов (что дает строго больше возможностей, чем стек). Выяснилось, что для написания высокоуровневого кода — даже по меркам не слишком-то высокоуровневого языка вроде ML — без ГЦ не обойтись.

_>И соответственно если через RAII получается реализовать скажем 90% задач работы с памятью (а остальное реализуем скажем через подсчёт ссылок и т.п.),

С помощью RAII можно решить 100% задач, решаемых с помощью RAII, это точно. А вот работа с иммутабельными структурами, например, не получится, если вы памятью с помощью RAII управляете.

_>то уже получим суперэффективный код. Который будет заметно превосходить все замечательные универсальные сборщики мусора.

Да, есть, конечно, такие сценарии, на которых ГЦ покажет результат хуже. Но на типичных сценариях выделения памяти для высокоуровневых языков вообще и работы с иммутабельными данными в частности ГЦ покажет большую производительность. Потому на низкоуровневых языках и пишут совсем не так, как на высокоуровневых.

_>Возможно. Но такова цена настоящего быстродействия.

Да, конечно.

_>Но опять же замечу главное — это ситуация для весьма редкого класса задач. А большую часть обычных задач C++ решает эффективнее всех и без написания какого-то специального кода (стандартные методы типа RAII на стеке).

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

_>Если сама задача требует версионности, то безусловно. Вопрос опять же в том насколько это часто встречающаяся на практике задача.

Еще раз. Версионности требует задача "удобство для программиста". На практике встречается всегда.