U>Проблема в том, что ежели пересоздавать вселенную при каждом изменении атома, то пупок может развязаться. Соответственно такое решение может работать только в задачах с легким состоянием, при тяжелом состоянии на пересоздание с нуля никаких ресурсов не хватит.

кстати gridsynchronizer работает именно на концепции "каждый раз мир пересоздается с нуля", и поэтому достаточно легко под него код писать.

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

DG>так в том-то и дело, что есть только надежда, что компилятор догадается и переиспользует память, а может не догадается и не переиспользует.
DG>и нет явного способа зафиксировать переиспользование памяти

В типичной реализации списка переиспользует точно.

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

U>Ссылочная прозрачность мне даром не нужна. Мне нужно 1) чтобы ссылок было минимально возможное количество, т.е. чтобы объекты не создавались без необходимости 2) чтобы по коду легко было определить какие ссылки по условию задачи являются неизменяемыми, а какие нет. Мутабельный подход легко позволяет создавать решения удовлетворяющие и первому, и второму условию, чисто иммутабельный подход противоречит обоим условиям.

Выше нам продемонстрировали уже это "легко".

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

DG>кстати gridsynchronizer работает именно на концепции "каждый раз мир пересоздается с нуля", и поэтому достаточно легко под него код писать.

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

U>Во-вторых, в чисто иммутабельном решении получается, что функции меняющей элемент коллекции надо давать права на пересоздание всей коллекции.

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

FR>В типичной реализации списка переиспользует точно.

если бы это было правдой, то не надо было бы извращаться при реализации quicksort

http://en.literateprograms.org/Quicksort_(Haskell)

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

не путай описание чистой концепции и ее реализацию в смешанном окружении.

то, что делается gridsynchronizer-ом каждый тик в runtime-е, в ФЯ делается один раз при компиляции.

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


FR>>В типичной реализации списка переиспользует точно.

DG>если бы это было правдой, то не надо было бы извращаться при реализации quicksort

DG>http://en.literateprograms.org/Quicksort_(Haskell)

Выше было отсекание головы спсика, в этом случае точно переиспользуется для qsort только отсекания недостаточно.

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

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

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

зы
и программисту вообще стоит отличать концепции от того, что в реальном коде происходит.
ФЯ, ООП, АОП, иммутабельность, sql, стековый исполнитель и т.д. — это все концепции, которые упрощают описание происходящего и которые никакого отношения не имеют к тому, что происходит при реальном выполнении

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

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

чистые академические языки (большая часть ФЯ, pascal, smalltalk, prolog и т.д.) они сдвинуты в сторону описания, и делание подгоняется под описание. mainstream(промышленные) языки — сдвинуты в сторону делания, и в них описание подгоняется под выполнение.

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

DG>smalltalk точно не имеет, потому что публично он был предоставлен в 80-м

Какая разница, когда он был представлен публично?

DG>а simula-у правильнее сравнивать с lisp-ом, чем с haskell-ем.
DG>simula — это одна из самых ранних попыток реализовать ОО-концепцию, lisp — ранная попытка реализовать ФЯ-концепцию.

А еще lisp — ранняя попытка реализовать ОО-концепцию.

DG>причем lisp появился на 10 лет ранее, чем simula, и тогда ФЯ-концепции вообще уже 50 лет.

Не важно, сколько лет ФЯ концепции. Мы говорим не просто о ФЯ, а о декларативных ФЯ. Это довольно новые языки. Самый старых их предок это какой-нибудь KRC, аналогичный по дальности предок ОО — это Sketchpad 63-го года. Для них более-менее нормальный способ осуществлять IO придумали и реализовали в начале 90-х — о каких 50-и годах тут может идти речь? А императивные ФЯ уже какое-то время в мейнстриме. Вот C#, например, императивный ФЯ.

DG>и соответственно сравнение haskell-я со smalltalk-ом, имхо, является справедливым, также как сравнение simula с lisp-ом.

Да, какой-нибудь haskell 2020 можно будет сравнивать со смолтоком 80.

DG>а тому же haskell-у уже 20 лет прошло.

Столько лет прошло со времен первых заседаний комитета. Первый стандарт Хаскеля вышел в 99, в нем даже FFI не было. Хаскель 98 вообще предназначен, в основном, для обучения. Все интересные языковые фичи Хаскеля в настоящий момент — это экспериментальные расширения, причем часто расширения одной единственной реализации. Естественно, они никак не стандартизированы.

DG>фундаментального закона, но скорость внедрения является индикатором преимуществ того или иного подхода (того или иного языка).

Без учета принципиальной новизны перехода от нового подхода к старому такой индикатор только введет в заблуждение.
Никаких прогнозных сроков для внедрения декларативных ФЯ из сроков внедрения ООЯ вывести не получится — это несопоставимые шаги в развитии языков. Я, в основном, старался просто указать на нелепость самой поставновки вопроса "а сколько сейчас проектов?". Потому, что в 1850-ом году электровозы перевезли 0 тонн груза, а в 1930-ом году ядерные электостанции произвели 0 киловатт-часов электроэнергии. И что, какой из этих этих фактов в то время должен был следовать вывод?

DG>Исходя из данного индикатора можно сделать вывод, что haskell может быть и хорош, но не настолько сильно, что необходимо все бросать и переходить на него. в тоже время раз он еще не умер, а развивается, то можно сделать вывод: что у него есть плюсы важные для определенного круга людей, но в тоже время — есть существенные минусы, которые не позволяют остальным на него перейти.

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

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

DG>1. всегда создается новый экземпляр, невозможно реализовать алгоритм, который переиспользует память.

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

DG>2. есть только ленивые вычисления, нет энергичных вычислений

Это заблуждение.

DG>3. язык строго типизированный

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

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

DG>так в том-то и дело, что есть только надежда, что компилятор догадается и переиспользует память, а может не догадается и не переиспользует.
DG>и нет явного способа зафиксировать переиспользование памяти

В этой ситуации обязательно использует. Всё таки ones — это конкретный идентификатор, ссылающийся на конкретный thunk. Это и есть явный способ.

Referential transparency гарантирует, что можно шарить не только переменную, но и выражения. Например, можешь почитать про cse.

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

DG>не путай описание чистой концепции и ее реализацию в смешанном окружении.

А ты уверен, что решением в рамках чистой концепции будет удобно пользоваться? Не окажется ли что все удобство как раз в возможности работать в смешанном окружении окажется?

DG>то, что делается gridsynchronizer-ом каждый тик в runtime-е, в ФЯ делается один раз при компиляции.

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

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

DG>есть только надежда, что компилятор догадается

В принципе, в этом вся суть языков высокого уровня.

DG> и переиспользует память, а может не догадается и не переиспользует.
DG>и нет явного способа зафиксировать переиспользование памяти

Но это не тот случай. Здесь как раз "переиспользование памяти" задано в коде явно.

FR>Выше было отсекание головы спсика, в этом случае точно переиспользуется для qsort только отсекания недостаточно.

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

утверждение вида: "в языке есть инструмент xxx" верно, только — если инструмент xxx позволяет решать широкий круг задач, а в идеале все задачи, требующие использование данного инструмента,
иначе верно утверждение — "в языке есть элементы инструмента xxx".
и соответственно верны следующие утверждения:
в C# есть переиспользование памяти,
в C/C++ — есть полный контроль над памятью,
в haskell-е есть очень редкие элементы переиспользования памяти (которых даже не хватает для описания алгоритма quicksort).

так же верно, что в:
в C/C++ и C# — есть элементы функциональщины, но не более (и которых даже не хватает на описание алгоритмов с хвостовой рекурсией)

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

DG>в haskell-е есть очень редкие элементы переиспользования памяти (которых даже не хватает для описания алгоритма quicksort).

В Хаскеле да, в ML семействе также как в Java/C#.

U>А ты уверен, что решением в рамках чистой концепции будет удобно пользоваться? Не окажется ли что все удобство как раз в возможности работать в смешанном окружении окажется?

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

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

DG>>то, что делается gridsynchronizer-ом каждый тик в runtime-е, в ФЯ делается один раз при компиляции.

U>Не понял. То есть в ФЯ не будет нужно крутить таймер? ФЯ не ленивый что ли и при изменении ссылки энергично перестраивает всех кто от этой ссылки зависит?

скажу про идеальный достижимый вариант для смешанного окружения:
1. программа спит все время пока нет изменений
2. все изменения склеиваются в единый пакет — который отрабатывается как единое целое. отработка идет в момент прихода внешнего сообщения

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

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

DG>в haskell-е есть очень редкие элементы переиспользования памяти (которых даже не хватает для описания алгоритма quicksort).

В целом верно. Но тут важно понимать, что переиспользование памяти — всего лишь техника. В случае чистых языков просто используют другие техники/алгоритмы. Например, для ленивых списков (которые по сути linked) используют mergesort. Для мутабельных же массивов вполне подойдёт quicksort — но код будет уже не чистым.

DG>>есть только надежда, что компилятор догадается

K>В принципе, в этом вся суть языков высокого уровня.

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

возьмем тот же .net — в нем есть только надежда, что один и тот же элемент будет всегда расположен в одном и тот же месте, и для большинства задач этого достаточно. но в ряде критических мест особенно при стыковке с legacy-кодом этого недостаточно, и в язык, и в движок введены понятия fixed, GlobalAlloc и т.д.

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

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

DG>есть чистая концепция (которая и реализована в ФЯ), а есть ее переосмысление и развитие на реальный код, который использует смешанные стратегии.

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

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

1) Для тяжелых входов вводим changeTick'и и проверку входов производим через них, а не через честное сравнение значений входов.
2) Используем только иммутабельные объекты, что позволяет вместо честного сравнения значений входов использовать сравнение ссылок.

Реализовать в gridSynchronizer'е хоть первую, хоть вторую оптимизацию означает испортить решение, т.к. решение прекрасно работает в рамках чистой концепции и отказа от чистоты ради оптимизаций не требует.

DG>чистая концепция использует допущение, что на этапе компиляции можно отследить все изменения данных, в реальном сложном приложение — выполнить это допущение нереально, поэтому используется смешанная концепция — которая фиксирует, что на этапе компиляции(разработки кода) можно отследить все изменения в отдельном участке кода (чем ты и занимаешься при развешивании кода, который меняет changetick)

Где ты в gridSynchronizer'е увидел changeTick'и?