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

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

I>>Опаньки ! И это, представь, не является препятствием для построения суперкомпьютера навроде evo online, который входит в top 500.

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

Я не знаю как проверить, раньше утверждалось что кластер eve входит в top500.

I>>Это показывает, что твои аргументы про С++ несостоятельны.

_>Ээээ какие аргументы?

Вот такие: "Речь конечно же про быстродействие кода."

Внезапно оказалось, что быстродействие кода вообще ни при чем. Питон недотягивает даже до джаваскрипта который заметно медленнее дотнета или джавы которые много медленее С++

>Тогда причём тут примеры с Питоном, который функциональный не более чем тот же C++?

Наоборот, он более функциональный относительно С++, например благодаря ленивости.

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

I>Я не знаю как проверить, раньше утверждалось что кластер eve входит в top500.

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

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

I>Вот такие: "Речь конечно же про быстродействие кода."

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

I>Внезапно оказалось, что быстродействие кода вообще ни при чем. Питон недотягивает даже до джаваскрипта который заметно медленнее дотнета или джавы которые много медленее С++

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

I>Наоборот, он более функциональный относительно С++, например благодаря ленивости.

Ленивость в Питоне? Ничуть не больше чем в C++, буквально тот же самый набор компонентов. Разве что генераторы в явном виде есть (в C++ тоже можно завести такие, но никто этим не занимается, т.к. используется другая техника, на базе итераторов).

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

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

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

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

Я думаю, если бы они взяли для решения проблем специалиста по Эрлангу, у них щас был бы вместо С++ эрланг.

I>>Внезапно оказалось, что быстродействие кода вообще ни при чем. Питон недотягивает даже до джаваскрипта который заметно медленнее дотнета или джавы которые много медленее С++

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

То есть, worldoftanks и eveonline это несложные проектики ?

I>>Наоборот, он более функциональный относительно С++, например благодаря ленивости.

_>Ленивость в Питоне? Ничуть не больше чем в C++, буквально тот же самый набор компонентов. Разве что генераторы в явном виде есть (в C++ тоже можно завести такие, но никто этим не занимается, т.к. используется другая техника, на базе итераторов).

Ленивость уже больше чем в С++. А еще всякие comprehension и тд

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

K>А если я в какой-нибудь вики напишу, что луна из сыра — вы поверите? Ну попробуйте тот же функциональный "хэллоуворлд" на C++ написать
K>

K>fibs = fix $ (1:) . (1:) . (zipWith (+) <*> tail)

>> fibs !! 100
K>573147844013817084101
K>

K>И расскажете потом, сильно ли вам помогло то, что в какой-то вики написано, что C++ поддерживает ФП.

Встроенной ленивости и ленивых списков естественно нет. Их нет не потому что C++ не поддерживает ФП — а потому что используются более эффективные техники (писать ФП ради самого ФП — нет смысла. есть смысл применять ФП там, где необходимы его полезные свойства). Да и вообще — ленивость не во всех функциональных языках есть.
Соответственно понадобится boilerplate для их определения: Lazy<T>, LazyList<T>, каррированные cons, zipWith, etc.
Пример выше запишется вот так:

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

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

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

EP>>Что означает "идиоматический ФП-код"?
K>Комбинирование комбинаторов.
EP>>Это синоним кода который тормозит?
K>Да. Чтоб такой код работал с более-менее приемлемой скоростью нужен специальный рантайм, заточенный под такие вещи и компилятор со специфическими оптимизациями. Поэтому в каком-нибудь гибриде, в который добавили функциональных фич потому, что это "модно" идиоматический ФП код (если его еще и получится написать) запросто может отличаться по производительности от кода а-ля фортран как скриптовый язык от компилируемого статтипизированного.

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

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

I>Я думаю, если бы они взяли для решения проблем специалиста по Эрлангу, у них щас был бы вместо С++ эрланг.

В смысле устроили бы компиляцию php в эрланг? %) Это очень сомнительная идея)

I>То есть, worldoftanks и eveonline это несложные проектики ?

Для начала, если взять их клиентскую часть, то там совсем не python приложение, использующее C++ библиотеки, а чистое C++ приложение, использующее python в качестве встроенного языка для небольших внутренних скриптов. Это принципиально другая архитектура и такое решение я полностью одобряю по всем параметрам. Мы и сами подобное делали.

Если же говорить про их серверную архитектуру, то лично я не знаю как там у них что устроено. На тех слайдах про танчики конечно было указано, что у них в качестве БД mysql, а код на python без GC и C++, но это как бы слишком неконкретно. Но если там, как ты говоришь, всё реализовано в виде одного большого приложения на python'е, то лично мне такое решение не очень нравится. Даже если забыть о быстродействие, то подобный сложный код на языке без статической типизации я бы не стал писать. Но это уже лично мой вкус.

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

I>>Я думаю, если бы они взяли для решения проблем специалиста по Эрлангу, у них щас был бы вместо С++ эрланг.

_>В смысле устроили бы компиляцию php в эрланг? %) Это очень сомнительная идея)

В смысле использовали эрланговский подход а не плюсовый.

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

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

Пусть будут характеристики — суть вопроса от этого не меняется.

I>>>Эрланг собтсвенно и начал с того, что порвал С++ в распределенных приложениях для телекоммуникаций.
EP>>Erlang рулит в первую очередь из-за инфраструктуры, а не из-за самого языка. Точно также как рулит и node.js за счёт инфраструктуры.
I>Это инфраструктуру без подобного языка заюзать невозможно, в принципе.

Что мешает использовать подобную архитектуру для C++/D?

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

I>Это тебе интересно обсуждать ислючительно мапинг в железо.

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

I>>>Я говорю про отношение часть-целое и характеристики составляющих. У узла узкое место процессор и система ввода-вывода, а у распределенной системы узким местом будет не процессоры и ввод-вывод,
EP>>У распределённых число-дробилок в большинстве случаев узким местом будет как раз процессор.
I>То есть, ты хочешь сказать, что некоторые распределенные системы есть множество всех распределенных систем ?

Нет, я говорю что выделенное твоё высказывание в общем случае не верно. Если ты имеешь ввиду какой-то конкретный нишевый use-case — то так и говори.

EP>>Что "вот-вот"? Я же говорю — использование элементов ФП это хорошо.
I>Ты почему то начал спрашивать, когда это ФП попало в нативный код

Ты сказал

Более того — ФП влазло и в нативный код.

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

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

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

EP>Пусть будут характеристики — суть вопроса от этого не меняется.

Меняется. Тормозной питон как то справляется с высоконагружеными приложениями

I>>Это инфраструктуру без подобного языка заюзать невозможно, в принципе.

EP>Что мешает использовать подобную архитектуру для C++/D?

Человеческий фактор, это очевидно. Нужно что бы язык страховал от большинства ошибок или позволял забесплатно и быстро найти их. В С++ ни того, ни другого нет.

EP>>>Что "вот-вот"? Я же говорю — использование элементов ФП это хорошо.
I>>Ты почему то начал спрашивать, когда это ФП попало в нативный код

EP>Ты сказал
EP>

EP>Более того — ФП влазло и в нативный код.

EP>Тут вроде все согласны, что в нативном коде, в C++ в частности, ФП элементы есть давно. Поэтому не сосем понятно к чему ты это сказал. Я попросил всего лишь раскрыть твою мысль, так как не совсем понятно к чему это.

Ты говорил про ФП на задворках империи. Это, внезапно, оказалось давно не так даже в С++.

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

I>>>2 Замыкания не теряют связь с локальными переменными, никогда, ни при каких случаях, до момента сборки мусора.
EP>>Допустим у нас такое определение — ОК.
EP>>Что делать в случае, когда захватываются ресурсы? (пусть это не относится к UFP по данному выше определению)
I>Контролировать ресурсы явно, руками.

Об этом и речь.

I>Проблема с ФП в том, что циклические ссылки это норма. Это поначалу просто убивает мозг.

Покажи пример циклической ссылки при использовании полностью immutable структур, и eager evaluation.

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

Да не надо "как в С++" — покажи хоть какое-то автоматическое решение этого варианта UFP.

I>В С++ придется следить за циклическими ссылками, приседать, обрезать и тд и тд и тд и всё это руками, но ресурсы будут освобождаться неявно.

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

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

EP>>ST не работает в Haskell 98, то есть требует расширение?
K>Haskell 98 — это подмножество языка, выделенное для того, чтоб гарантировать компилируемость кода в учебниках для начинающих.

Ок. А как контролируется зоопарк расширений? Через reference implementation? Или есть какой-то стандарт?

EP>>

import System.IO

main = do
    closure <- withFile "test.out" WriteMode $ \f -> do
        hPutStr f "ok"
        return $ \s -> do
            hPutStr f "logging: "
            hPutStrLn f s
    closure "fail" -- test.out: hPutStr: illegal operation (handle is closed)

EP>>как?
K>Я вам давал ссылку на монадические регионы.

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

EP>>В случае с C++ я знаю как и насколько он поддерживает functional programming. Относительно UFP — я вам приводил несколько вариантов решения, причём которые работают не только для памяти.
K>Гарантии на продлевание жизни захваченных языковых сущностей ни одно из этих "решений" не дает, а значит и UFP не решает.

Как минимум [=] даёт определённые гарантии.

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

EP>>>>И как это доказывает то, что он работает не медленнее чем аналогичный код на императивном языке?
I>>>Код никого не интересует. Интересуют выходные характеристики конечной системы.
EP>>Пусть будут характеристики — суть вопроса от этого не меняется.
I>Меняется. Тормозной питон как то справляется с высоконагружеными приложениями

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

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

От таких именно ошибок гарантированно страхует Erlang? (и от чего нельзя застраховаться в C++/D теми или иными спосабами)

EP>>Тут вроде все согласны, что в нативном коде, в C++ в частности, ФП элементы есть давно. Поэтому не сосем понятно к чему ты это сказал. Я попросил всего лишь раскрыть твою мысль, так как не совсем понятно к чему это.
I>Ты говорил про ФП на задворках империи. Это, внезапно, оказалось давно не так даже в С++.

Не просто ФП, а именно чистый ФП.

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

EP>>1. Изначально речь шла про автоматическое преобразование обычного кода в монадический.

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

Никакого монадического кода там не было, если конечно не считать тривиальную монаду.
Там не обработка пустого значения — а возвращение (причём возвращать пустое значение не обязательно). Это просто void. Я добавил if чтобы продемонстрировать что это именно монада, а не АФ.
call-with-current-continuation — позволяет завернуть остаток кода в continuation, и что-то сделать с результатом. Тут для результата делается просто монадический return, каким бы он не был. Примерно также работает await в C#, только там много разных ограничений.
Например вот тут есть статья на эту тему:

We show that any monad whose unit and extension operations are expressible as purely functional terms can be embedded in a call-by-value language with "composable continuations". As part of the development, we extend Meyer and Wand's characterization of the relationship between continuation-passing and direct style to one for continuation-passing vs. general "monadic" style. We further show that the composable-continuations construct can itself be represented using ordinary, non-composable first-class continuations and a single piece of state. Thus, in the presence of two specific computational effects -- storage and escapes -- any expressible monadic structure (e.g., nondeterminism as represented by the list monad) can be added as a purely definitional extension, without requiring a reinterpretation of the whole language. The paper includes an implementation of the construction (in Standard ML with some New Jersey extensions) and several examples.
...
The embedding result is also a strong argument for inclusion of firstclass continuations in practical eager languages especially ones like ML that already have mutable cells providing call/cc does not simply add yet another monadic effect it completes the language to all such effects Moreover a sophisticated module system like SMLs lets us expose as little or as much of this underlying raw power as we need by picking the appropriate monadic structure we can introduce effects ranging from simple exceptions to full composable continuations

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

Подробнее. В примере Scheme — никакой ленивости нет, но раннее завершение у maybe — есть.

EP>>В языках же с call-with-current-continuation: любой код можно сделать монадическим без модификаций (либо нужно сделать минимальные модификации, заменив "x" на "get(x)" — если нет перегрузки всего как в D.
K>Чего его делать — он и так уже монадический. Одну монаду на другую заменить можно (ряд монад с помощью Cont[inuation] можно заменить, правда не все).

Приведите тогда пример немонадического кода на Scheme.

EP>>

K>>>Мы вроде бы в соседней ветке выяснили, что без ленивости комбинирование функций теряет смысл из-за непрактичности.

EP>>Хотя ничего подобного мы не выясняли

K>Т.е. вычислять ненужное — это практично?

Ленивость позволяет не вычислять ненужное в тех случаях, когда функция/алгоритм описаны с ненужными вычислениями. Какое-то засилье ненужных вычислений в ФП, из-за которого ленивость необходима как пища, продемонстрировано не было. Более того, судя по Q&A на stackoverflow, когда нужна скорость — от этой ленивости бегут, точно также как и от GC.

K>Или непрактичность не делает комбинирование бессмысленным?

Непрактичность ленивости? Комбинирование обязательно влечёт за собой ленивость?

K>Или имеется в виду, что call-with-current-continuation тоже дает возможность получать комбинаторый код, который не делает бессмысленных действий?

Мы же вроде обсуждали монадический код?

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

С этим я не спорю. Я просто показал, как в языках с call/cc обычный код легко превращается в монадичный.

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

EP>>>>>>Про "неработающие" замыкания в C++ из-за UFP любители GC мне тут уже третий раз говорят, хотя "плюсисты" не имеют с этим проблем. На деле же оказывается что работают, и не только для памяти.
EP>>В выделенном разговор был не про ФП.
K>Ну а как можно не испытывать проблем с неработающими замыканиями, если только не пользоваться ими нормально, а рассказывать на форумах про то, что они якобы работающие?

Опять 25. Почему они не работающие? Они работают даже для ресурсов в отличии от.

EP>>На C++ как раз высокоуровневый код отлично мэппится в железо. The Standard Template Library
K>Высокоуровневый код — это когда можно делать вид, что языковые сущности — это математические объекты, содержательно рассуждать о них в таком ключе и получать нормально работающий код.

На C++ есть всякие DSL библиотеки, позволяющие писать высокоуровневый, который отлично мэппятся в железо. Например Eigen может во время компиляции выбрать оптимальный путь вычисления матричного выражения, и автоматически векторизовать.
Опять-таки высокоуровневый != огромное penalty.

EP>>То что где-то дорогие абстракции — не означает что они дорогие везде. Естественно, если использовать связанные списки которые плохо мэппятся в железо, thunk'и которые на ровном месте добавляют меж-потоковую синхронизацию и излишние циклы требующие GC — то всё будет тормозить.
K>Точно, а если копировать массивы, считать ссылки

В большинстве кода не то что shared_ptr нет, а даже unique_ptr.

K>и вычислять то, что вычислять ненужно все будет летать.

Где вычисляется то что ненужно?

K>Сравнимый по высокоуровневости код с такими подходами не то, что тормозить будет — он вообще никуда не поедет.

Выводы на основе ложных утверждений. Далеко не все абстракции дорогие.

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

См. Eigen.

K>В принципе, объявление всего, чего нет ненужным можно описать словами "все решено" — в каком-то смысле это решение.

Да — это именно то решение, которое вы описали для UFP с ресурсами: "ненужно, поэтому запретить".

EP>>В железе есть: изменяемая память(доступ к которой происходит большими порциями ~64B), многоуровневые кэши, синхронизация между кэшами, изменяемые регистры, стэк (с готовыми инструкциями для работы с ним), указатель на текущую инструкцию и разнообразные переходы. Само собой, если даже самые низкоуровневые абстракции в языке делают вид что ничего этого нет и вносят большое penalty сами по себе — то всё будет тормозить.
K>Самая низкоуровневая абстракция в плюсах — указатель — как раз делает вид, что ничего этого нет. Что память плоская, а не иерархичная, что она с произвольным доступом и т.д.

1. Какую abstraction penalty вносит указатель сам по себе? Хм, может быть межпоточную синхронизацию?
2. Да, у разных машин есть особенности которые нужно учитывать.

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

EP>>В смысле? Возможно одновременное изменение/чтение одних и тех же данных из нескольких потоков — поэтому и вводится синхронизация.
K>"на ровном месте" означает "без нужды". Тут может быть три варианта:

Встроенная абстракция языка, которая как вы говорите является "пищей ФП" и которая судя по всему используется повсеместно, даже в hello world, вводит меж-поточную синхронизацию (относительная цена которой с каждым годом только возрастает) — это и называется "на ровном месте".

K>1) Вы считаете, что ленивость не нужна.

Нужна ли такая абстракция или нет, приемлема ли такое penalty или нет — естественно зависит от прикладной области.

K>2) Вы не поняли зачем это нужно. (вычеркиваем)
K>3) У вас есть идея получше,

Я предполагаю что лучшего решения нет — мутабельные данные (модификация/чтение для которых может пересекаться) требуют синхронизации by-design, поэтому их и нужно избегать.

K>как обеспечить ту же функциональность.
K>Предполагаю, что правильный ответ — 1.

Решение аналогичных задач (но через другую функциональность) в других языках достигается куда более дешёвыми средствами.

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

I>>Меняется. Тормозной питон как то справляется с высоконагружеными приложениями

EP>Такими "высоконагруженными" что всё в IO упирается?

Есть разные примеры, например такие World of tanks, Eve online

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

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

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

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

EP>От таких именно ошибок гарантированно страхует Erlang? (и от чего нельзя застраховаться в C++/D теми или иными спосабами)

Ошибки с указателями, ошибки с изменением состояния, корректное взаимодействие и тд и тд.

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

I>>Ты говорил про ФП на задворках империи. Это, внезапно, оказалось давно не так даже в С++.

EP>Не просто ФП, а именно чистый ФП.

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

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

I>>Проблема с ФП в том, что циклические ссылки это норма. Это поначалу просто убивает мозг.

EP>Покажи пример циклической ссылки при использовании полностью immutable структур, и eager evaluation.

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

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

EP>Да не надо "как в С++" — покажи хоть какое-то автоматическое решение этого варианта UFP.

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

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

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

I>>В С++ придется следить за циклическими ссылками, приседать, обрезать и тд и тд и тд и всё это руками, но ресурсы будут освобождаться неявно.

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

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

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

_>Контролируемая (т.е. всякие там монады st/io) или же не явная, скрытая внутри языка?

И та и другая.

_>Если первое, то это не подходит.

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

_>А вот второе было бы классно

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

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

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

S.sum . S.map (+1) . S.takeWhile (<= 1.0e8) . S.iterate (+1)

loop_sum (acc :: Double#) (i :: Double#) =
    case i >## 1.0e8 of 
        True  -> acc
        False -> loop_sum (acc +## i +## 1.0) (i +## 1.0)

, а код

or = foldr (||) False

any p = or . map p

any = \t ds ds1 ->
    case ds1 of
      []     -> False
      x : xs ->
        case ds x of
          False -> any_naive t ds xs
          True  -> True

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

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

_>1. Я нигде не соглашался, что обобщённый код на C++ нетипизирован. Наоборот, я говорил что с этим никаких проблем нет.

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

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

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

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

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

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

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

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

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

Смысл в этом, разумеется, есть — куда же он делся?

_>Я и говорил, что семантической разницы нет. Разница в том что нам надо править для достижения результата. Базовые принципы или же оптимизацию.

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

_>Всё очень просто: если чистый функциональный язык полностью обходится в своей работе копированием (возможно оптимизированным) вверх/вниз, то C++, тоже имеющий оптимизированное копирование вверх/вниз, без проблем должен решать все задачи ФП.

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

_>Ну так это же используется только при передаче вверх (т.е. когда старая копия всё равно разрушается сразу). А передав вверх, мы можем уже дальше размножать как угодно обычным const&.

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

_>Как раз это всё без проблем работает, т.к. за исключением shared_ptr это всё встроенные средства самого языка (а не стандартной библиотеки) и соответственно удобно и красиво обрабатывается.

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

_>А вот при попытке поработать с неконстантной ссылкой в Хаскеле, мы действительно видим инвалидный код.

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

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

Про то, что он у вас вызывает какое-то отвращение (по всей видимости, полностью иррациональное потому, что вы так и не объяснили, что именно вам в нем не нравится) вы тут уже не раз писали. Для того, чтоб провозглашать, что в чистых ФЯ нет изменяемых ссылок такой аргументации, правда, не достаточно. "Зараженную" область, кстати, вполне можно изолировать средствами ST.

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	22.01.14 12:17
Оценка:

	От:	alex_public
	Дата:	22.01.14 13:24
	Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	22.01.14 13:52
Оценка:

	От:	Evgeny.Panasyuk
	Дата:	22.01.14 14:57
	Оценка:

	От:	Evgeny.Panasyuk
	Дата:	22.01.14 15:04
	Оценка:

	От:	Klapaucius
	Дата:	23.01.14 10:28
	Оценка:

	От:	Klapaucius
	Дата:	23.01.14 10:41
	Оценка:

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