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

I>>Она появляется сама собой, как только ты добавляешь второе осмысленное значение. А как ты это моделируешь, кортежем-списком-массивом-классом-модулем-функцией, твоё личное дело. Используй что угодно, но связь, даже единственная, сложнее её отсутствия. И это нужно тащить от спецификации к UI до самой DB.
S>Второе осмысленное значение у было до того, как появился кортеж.

Именно! А всё остальное про кортежи ты додумал. Балтимор и Воронеж это просто примеры, что бы показать тебе необходимость согласования значений.
Можно подумать наличие кортежа как то запретит сунуть туда Россия+Балтимор

I>>Ты в курсе, что восстановить позицию в шахматах это скилл, довольно высокого уровня? Не любой игрок это умеет. А ты хочешь этого от ребенка
S>С точностью до долей миллиметра — конечно. Не каждому дано.

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

I>>Если бы люди рождались в встроеным знанием и умением cons-списков, да имели перед глазами повседневную наглядную модель, в такой реальности будут проще, т.к. до массивов придется освоить новое, чего в голове изначально нет. А пока что массивы(шкафчики) дети осваивают где то в 3 года, как детский сад идут.
S>Мне надоело обсуждать шафчики и детей со встроенным знанием массивов.

И чего ты пишешь сюда?

I>>Если ты не хочешь быть понятым, для чего ты пишешь ?
S>Я хочу быть понятым, но тут вышло что у тебя нет встроенного знания про удельные измерения. И я не могу с этим ничего поделать, ведь если попытаюсь объяснить, оно не будет встроенным, как шкафчик в 3-х летнем ребенке.

Мы говорим про вот этот огрызок:

Проверь удельную частоту "учится за неделю-две"

Как только начали уточнять условие, у тебя ожидаем какие то невнятные намёки Не можешь, не хочешь уточнять, пояснять — для чего ты сюда пишешь?

I>> Парадигма используется ради бенефитов, а не ради самой себя.
S>Да, конечно. Но мы же выяснили что у ФП нет бенефитов, а есть одни недостатки, выраженные в невозможности удалить элемент за O(1).

Вероятно это ты такое выяснил. Я пишу про границы применимости.

I>>Ты однобоко пишешь. В ФП точно так же есть вещи, которым приходится уделять слишком много внимания, и для которых ИП все это доступно искаропки.
S>Да, такие вещи есть.

Вопрос в том, где граница и от чего она зависит.

I>>Кое где легче, кое где наоборот сложнее. На каждый чих клонировать длинный буфер в драйвере тебе никто не даст.
S>Опять драйвер. Драйвера и числодробилки — твой профиль?

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

I>>Если у меня массив, то "само" ничего не схлопнется, главное не забыть в какой переменной индекс
S>Я не об этом. Обнули 5-ый элемент и 5-ым у тебя станет 6-ой, сохранив при этом свой индекс.

А я думаю, что по месту 5го индекса будет нуль, а 6й останется там где и был.

I>>Трудозатраты куда деть? Сборка — линейная операция, стоимость — размер всего списка. Изменения выше — стоимость от количества кривых кадров. Если кадров попортили много — выгоднее пересоздать. А если единичные — выгоднее скорректировать на месте.
S>Затрат труда программиста не стало больше. Но да, железо поработает немного дольше.

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

> Но когда ты выбираешь C#/Java вместо C, ты тоже изначально допускаешь что железу придется работать дольше и программа займет больше памяти. Для чего-то ведь люди отказываются от максимально высокого перфоманса?

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

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

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

ARK>>>Ну ты с этим согласен? Если нет, то почему? Потому что в доках хаскеля написано, что "результат — это computation", а в доках С++ этого не написано? Так?
S>>Нет, не согласен. Потому, что я могу отличить возврат значения без сайд-эффекта от выполнения сайд эффекта.

ARK>В хаскеле это тоже невозможно, ведь там в коде нет "выполнения сайд эффекта", не так ли? И здесь будет то же самое — везде в коде сплошной "возврат значения без сайд-эффекта". Теперь согласен?
В Хаскеле есть бэкдор unsafePerformIO, т.е. возможность принудительно выполнить IO есть. Но чистые программы его не используют.
Нет, не согласен.

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

ARK>Почему не обойтись? Вот в документации написано: "вместо вызова действий, производящих сайд-эффекты, С++ будет создавать их как строительные блоки, не выполняя, а выполнением займется что-то вне функции main. Это верно для любых функций". Все остальное — деталь реализации. Всё, С++ чист?
Чистота — это свойство кода, а не документации. Сайд-эффекты можно отследить не только лишь читая документацию.

S>>Как раз printf вызывает системные функции между началом своего вызова и возвратом вызывающему коду. putStr — создает действие, но не вызывает его. Неужели это так сложно?

ARK>Ну то есть если в документации к printf будет написано, что он "создает действие, но не вызывает его", то всё ОК? Системные функции printf сразу резко перестанет вызывать? Ведь как это реализовано в компиляторе — дело десятое.
Причем тут компилятор, если сайд-эффект будет возникать между передачей управления функции и возвратом?

S>>К performing I/O приводит запуск computation-а, построенного функцией main. И запуск этот выполняется не кодом программы.

ARK>В С++ (и вообще в любом языке) запуск функции main тоже выполняется не кодом программы.
Верно, но сайд-эффекты появляются после передачи управления в main и заканчиваются до возврата (как правило, но не обязательно).

S>>Здесь все верно. С поправкой на то, что мы рассуждаем не о чистоте машинного кода, а о чистоте кода в исходниках.

ARK>Тогда какой в этом смысл? Получается, что чистота программы следует не из объективных свойств, а из языка программирования, на котором она написана.
Конечно. А какой смысл говорить о чистой програмее в терминах машинных кодов? Такая программа только займет ресурсы, но не сможет ничего вернуть.
ARK>Меняя только лишь трактовку термина "функция", мы можем признать любую программу чистой и нечистой по своему желанию (все функции напрямую вызывают другие функции — программа нечистая; все функция только создают действия, но не выполняют их — программа чистая). Из этого прямо следует, что такое определение чистоты является бесполезным.
Это не вопрос одной лишь трактовки.
Но в целом, чистота конкретно функции main здесь не является принципиальной. Не она дает полезные качества программе. И конечно, всегда можно сделать свой pureMain, возвращающей лямбду, вызвать из main, спрятанной под капот инфраструктуры. И такая призрачная чистота pureMain ничего не даст полезного.

ARK>>>Если это не мастурбация вприсядку, то что это тогда?
S>>Это подход (один из), позволяющий писать абсолютно чистые программы.

ARK>Нет, это подход, заключающийся в назывании грязных программ чистыми.
Ок, объясни практический смысл чистой программы в терминах машинных кодов.

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

ARK>Пока разобрались, что можно по желанию левой пятки путем жонглирования терминами (evaluate/invoke) подгонять недостаточно формальные определения (pure function в википедии) под желаемый результат и называть любую программу хоть чистой, хоть нечистой.
Это обратное тому, что я пытаюсь продемонстрировать.

ARK>Ты согласен, что определение чистоты, не позволяющее однозначно судить, чиста функция/программа или нет, является бессмысленным? И что, пользуясь этим определением, нельзя утверждать что-либо относительно чистоты любой программы/функции?
У меня суждения вполне однозначны с точностью до заранее заданного перечня сайдэффектов. Заметь, терминами evaluate/invoke я не жонглирую и оперирую лишь обозримыми сайдэффектами (зафиксированными заранее).

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

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

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

I>Именно! А всё остальное про кортежи ты додумал. Балтимор и Воронеж это просто примеры, что бы показать тебе необходимость согласования значений.
Эта необходимость ортогональна тому, идут значения в функцию отдельно или кортежем.
I>Можно подумать наличие кортежа как то запретит сунуть туда Россия+Балтимор
Как не запретит сунуть туда Россия+Балтимор и отсутствие кортежа. Оттого и не понятно, к чему тут эта связь, что именно демонстрирует в примере с декартовым произведением областей определения.

I>>>Ты в курсе, что восстановить позицию в шахматах это скилл, довольно высокого уровня? Не любой игрок это умеет. А ты хочешь этого от ребенка
S>>С точностью до долей миллиметра — конечно. Не каждому дано.

I> И без долей милиметра не все с этим справляются. Ребенку, который начал играть в шахматы, только предстоить научиться этому.
Я же не настаиваю на том, что он впитал это с молоком матери, как в случае с массивами.
I>Сложность восстановления(и частота ошибок) почему то зависит от количества фигур. Странно, да ?
Что это меняет?

S>>Мне надоело обсуждать шафчики и детей со встроенным знанием массивов.

I>И чего ты пишешь сюда?
В надежде увидеть новые аргументы.

I>Мы говорим про вот этот огрызок:
I>

I>Проверь удельную частоту "учится за неделю-две"

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

I>>>Ты однобоко пишешь. В ФП точно так же есть вещи, которым приходится уделять слишком много внимания, и для которых ИП все это доступно искаропки.
S>>Да, такие вещи есть.

I>Вопрос в том, где граница и от чего она зависит.
Если она и есть, то вряд ли четкая.

S>>Опять драйвер. Драйвера и числодробилки — твой профиль?

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

S>>Я не об этом. Обнули 5-ый элемент и 5-ым у тебя станет 6-ой, сохранив при этом свой индекс.

I>А я думаю, что по месту 5го индекса будет нуль, а 6й останется там где и был.
Не все так думают.

I>Забавно — ты хотел привести пример удобной для тебя иллюстрации, но почему то вышла обычная картина, как только начали ручной труд считать. Изначально в этом примере у тебя вычислителем был ребенок и блокнот, не забыл ?
Помню, в этом примере ребенок и есть "железо".

>> Но когда ты выбираешь C#/Java вместо C, ты тоже изначально допускаешь что железу придется работать дольше и программа займет больше памяти. Для чего-то ведь люди отказываются от максимально высокого перфоманса?

I> Сначала — "благодаря чему", а уже потом — "ради чего". Например, конкретный кусок кода не является узким местом. То есть, благодаря этому у нас есть запас по перформансу. Его можно потратить на что угодно, с учетом приоритетов и требований. Это можно потратить, например, на нового студента — отказались от оптимизаций, сэкономили бюджет и его хватило на нового студента, который будет мелкие баги фиксить. Это вполне реальный кейс, из жизни

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

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

S>Чистота — это свойство кода, а не документации.

Пусть в документации написано: "свойством любой функции в С++ является то, что ее результатом является computation". Поясни, почему ты не согласен, что в этом случае любая функция в С++ будет чистой?

S>Сайд-эффекты можно отследить не только лишь читая документацию.

Можно. Берешь код на С++ и отслеживаешь все эффекты, вручную. Никто легкости этого процесса не обещал. Но сделать это можно.

S>Причем тут компилятор, если сайд-эффект будет возникать между передачей управления функции и возвратом?
S>Верно, но сайд-эффекты появляются после передачи управления в main и заканчиваются до возврата (как правило, но не обязательно).

В какой момент ФИЗИЧЕСКИ возникает сайд-эффект, мы не знаем, это деталь реализации. Никаких функций в машинном коде может вообще не быть, они могут быть оптимизированы неузнаваемым образом. Если мы откроем отладчиком скомпилированные exe от хаскеля и от С++, то увидим примерно одинаковую картину.

В каком момент ИДЕОЛОГИЧЕСКИ возникает сайд-эффект — написано в документации. Если написано, что "функция создает действие, но не вызывает его" — значит, идеологически сайд-эффект возникает где-то потом, во внешнем запускателе.

Итак, мы глядим на код и видим printf. В документации к С++ написано, что "любая функция, в том числе printf, создает действие, но не вызывает его". Функция printf чиста?

ARK>>Тогда какой в этом смысл? Получается, что чистота программы следует не из объективных свойств, а из языка программирования, на котором она написана.
S>Конечно. А какой смысл говорить о чистой програмее в терминах машинных кодов? Такая программа только займет ресурсы, но не сможет ничего вернуть.

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

ARK>>Меняя только лишь трактовку термина "функция", мы можем признать любую программу чистой и нечистой по своему желанию (все функции напрямую вызывают другие функции — программа нечистая; все функция только создают действия, но не выполняют их — программа чистая). Из этого прямо следует, что такое определение чистоты является бесполезным.
S>Это не вопрос одной лишь трактовки.

Именно, что, если взять определение чистоты из википедии за базу, то это вопрос только трактовки слов "evaluation"/"invoke". Меняя их значение, ты получаешь противоположные результаты.

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

S>>>Это подход (один из), позволяющий писать абсолютно чистые программы.
ARK>>Нет, это подход, заключающийся в назывании грязных программ чистыми.
S>Ок, объясни практический смысл чистой программы в терминах машинных кодов.

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

ARK>>Пока разобрались, что можно по желанию левой пятки путем жонглирования терминами (evaluate/invoke) подгонять недостаточно формальные определения (pure function в википедии) под желаемый результат и называть любую программу хоть чистой, хоть нечистой.
S>Это обратное тому, что я пытаюсь продемонстрировать.

Ты вроде сказал, что в С++ evaluation — это какой надо evaluation, а в хаскеле evaluation — это не evaluation ("можно считать computation результатом evaluation программы на хаскеле" (с) ).

Каким образом из википедийного определения читателю становится ясно, что evaluation в разных языках означает совершенно разные вещи и что чистота напрямую зависит от этого?

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

ARK>>Ты согласен, что определение чистоты, не позволяющее однозначно судить, чиста функция/программа или нет, является бессмысленным? И что, пользуясь этим определением, нельзя утверждать что-либо относительно чистоты любой программы/функции?
S>У меня суждения вполне однозначны с точностью до заранее заданного перечня сайдэффектов. Заметь, терминами evaluate/invoke я не жонглирую и оперирую лишь обозримыми сайдэффектами (зафиксированными заранее).

Ну вот есть обозримый сайд-эффект: печать "Hello, World". У тебя есть исполняемый файл, который печатает это предложение. У тебя есть код программы, который содержит в себе визуально видимое наименование системной функции печати с параметром "Hello, World". Что говорит твое суждение относительно чистоты данной программы, если: a) документация по языку говорит тебе, что все функции языка возвращают computation; б) документация по языку говорит тебе, что все функции языка "выполняются напрямую"?

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

I>>Именно! А всё остальное про кортежи ты додумал. Балтимор и Воронеж это просто примеры, что бы показать тебе необходимость согласования значений.
S>Эта необходимость ортогональна тому, идут значения в функцию отдельно или кортежем.

Это пример того, как второе значение увеличивает сложность.

I>>Можно подумать наличие кортежа как то запретит сунуть туда Россия+Балтимор
S>Как не запретит сунуть туда Россия+Балтимор и отсутствие кортежа. Оттого и не понятно, к чему тут эта связь, что именно демонстрирует в примере с декартовым произведением областей определения.

Ты путаешь контекст — это пример увеличения сложности. Если ты запихал это в кортеж, часть кода станет короче, но сложность никуда не денется — как была, так и осталась. Проявляется, например, в том, что на UI нужно бОльше тестов, на API нужно бОльше тестов. В разработке аналогично — всё равно надо валидировать, т.к. инпут вида Балтимор+Россия.

I>>Сложность восстановления(и частота ошибок) почему то зависит от количества фигур. Странно, да ?
S>Что это меняет?

Известно что — принципиально отсутствует возможность бесплатного отката.

I>>Мы говорим про вот этот огрызок:
I>>

I>>Проверь удельную частоту "учится за неделю-две"

I>>Как только начали уточнять условие, у тебя ожидаем какие то невнятные намёки Не можешь, не хочешь уточнять, пояснять — для чего ты сюда пишешь?
S>Есть соображение о том, что удельные показатели дадут более ясную картину, чем абсолютные, которые ты привел. Но значение слова удельный — тут лучше самому, поверь. Это уровень средней школы. Если ты прошел мимо этого, то лучше мне забыть о том, что я тут написал, чем пытаться объяснить. Когда писал тот огрызок, не думал, что с этим будут проблемы.

Итого — 1 ты согласен, что выдал огрызок и 2 пояснять отказываешься.

I>>Вопрос в том, где граница и от чего она зависит.
S>Если она и есть, то вряд ли четкая.

А кто утверждает обратное?

I>>А я думаю, что по месту 5го индекса будет нуль, а 6й останется там где и был.
S>Не все так думают.

А откуда на массиве будет иначе?

I>> Сначала — "благодаря чему", а уже потом — "ради чего". Например, конкретный кусок кода не является узким местом. То есть, благодаря этому у нас есть запас по перформансу. Его можно потратить на что угодно, с учетом приоритетов и требований. Это можно потратить, например, на нового студента — отказались от оптимизаций, сэкономили бюджет и его хватило на нового студента, который будет мелкие баги фиксить. Это вполне реальный кейс, из жизни

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

Совсем необязательно. Значительная часть типичного веб-приложения написана на самом православном функциональном языке — SQL, а другая — на декларативном CSS где вообще нет никакой императивщины. Что характерно, и там и там обычно багов пруд пруди. Одни заметны глазом, вызывают негатив и недоверие, а другие стоят огромных денег Что интересно — когда SQL писали руками, багов было еще больше.

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

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

S>>Чистота — это свойство кода, а не документации.

ARK>Пусть в документации написано: "свойством любой функции в С++ является то, что ее результатом является computation". Поясни, почему ты не согласен, что в этом случае любая функция в С++ будет чистой?
Определение чистоты построено на понятиях, отличных от документации. Потому для проверки чистоты я не будут руководствоваться документацией.

ARK>Можно. Берешь код на С++ и отслеживаешь все эффекты, вручную. Никто легкости этого процесса не обещал. Но сделать это можно.
Конечно.

S>>Причем тут компилятор, если сайд-эффект будет возникать между передачей управления функции и возвратом?
S>>Верно, но сайд-эффекты появляются после передачи управления в main и заканчиваются до возврата (как правило, но не обязательно).

ARK>В какой момент ФИЗИЧЕСКИ возникает сайд-эффект, мы не знаем, это деталь реализации. Никаких функций в машинном коде может вообще не быть, они могут быть оптимизированы неузнаваемым образом. Если мы откроем отладчиком скомпилированные exe от хаскеля и от С++, то увидим примерно одинаковую картину.
Меня не волнует чистота машинных кодов и я не собираюсь делать утверждений о чистоте в контексте машинных кодов. Мне это не интересно.

ARK>В каком момент ИДЕОЛОГИЧЕСКИ возникает сайд-эффект — написано в документации. Если написано, что "функция создает действие, но не вызывает его" — значит, идеологически сайд-эффект возникает где-то потом, во внешнем запускателе.
Если при этом тип результата функции будет int, а не Task<int> или IO int, то мне кашлять, что написано в документации.

ARK>Итак, мы глядим на код и видим printf. В документации к С++ написано, что "любая функция, в том числе printf, создает действие, но не вызывает его". Функция printf чиста?
О чистоте я сужу по наличию сайд эффектов, а не по документации. Потому, нет.

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

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

ARK>Именно, что, если взять определение чистоты из википедии за базу, то это вопрос только трактовки слов "evaluation"/"invoke". Меняя их значение, ты получаешь противоположные результаты.
Какая цель в этом? Это поможет выполнить оптимизацию или упростить рассуждения о программах?

ARK>Как раз поэтому я предложил свой вариант определения чистоты, который четко разграничивает понятия и хаскельный онанизм вприсядку сразу оказывается не у дел.
Хорошо, твоя чистота называет функции хаскеля грязными. Но это не отменяет рассуждения и возможности оптимизации хаскеля в терминах обычной чистоты. А что дает твой вариант кроме разоблачения хаскеля? Может быть он позволяет лучше заниматься оптимизацией в C++?

S>>Ок, объясни практический смысл чистой программы в терминах машинных кодов.

ARK>Чистые программы — редкий гость. Чистая программа — это чистая функция, которая принимает вход и возвращает выход. Насколько мне известно, в современных ОС написать такую программу невозможно, но теоретически в этом нет ничего противоестественного. Но обычно все программы грязные. Зато они могут иметь внутри чистые функции (число которых строго меньше общего числа функций в программе), практический смысл которых вроде бы очевиден — мемоизация, прозрачность по ссылкам и т.д.
Если в терминах машинных кодов рассуждения о чистоте не имеют практического смысла, то зачем мы обсуждаем это здесь на форуме?

ARK>>>Пока разобрались, что можно по желанию левой пятки путем жонглирования терминами (evaluate/invoke) подгонять недостаточно формальные определения (pure function в википедии) под желаемый результат и называть любую программу хоть чистой, хоть нечистой.
S>>Это обратное тому, что я пытаюсь продемонстрировать.

ARK>Ты вроде сказал, что в С++ evaluation — это какой надо evaluation, а в хаскеле evaluation — это не evaluation ("можно считать computation результатом evaluation программы на хаскеле" (с) ).
Только причем тут желания левой пятки назвать int continuation-ом(действием)? Хочешь чистоты в C++ — создай функцию, возвращающую действе-обертку над printf. Она будет чиста, если не будет до возврата действия производить сайд-эффекты. Но называя int действием ты ничего не достигаешь в плане возможностей оптимизации и уж точно ухудшаешь понимание программы.

ARK>Каким образом из википедийного определения читателю становится ясно, что evaluation в разных языках означает совершенно разные вещи и что чистота напрямую зависит от этого?
Да блин, почему они разные-то? Evaluation в С++ возвращает int и гадит в мир. В хаскле evaulation main вместо int возвращает композицию действий. Это одинаковые evaluation. Разница не в evaluation, а в организации кода.

ARK>Это и есть жонглирование. "А в моем языке evaluation означает совсем другое, поэтому у меня все функции чистые".
Это жонглирование словом "означает". И я не писал, что все функции в Хаскеле чистые, что именно поэтому и что он мой.

S>>У меня суждения вполне однозначны с точностью до заранее заданного перечня сайдэффектов. Заметь, терминами evaluate/invoke я не жонглирую и оперирую лишь обозримыми сайдэффектами (зафиксированными заранее).

ARK>Ну вот есть обозримый сайд-эффект: печать "Hello, World". У тебя есть исполняемый файл, который печатает это предложение. У тебя есть код программы, который содержит в себе визуально видимое наименование системной функции печати с параметром "Hello, World". Что говорит твое суждение относительно чистоты данной программы, если: a) документация по языку говорит тебе, что все функции языка возвращают computation;
Откуда это взялось? нет, не все функции языка возвращают computation и чисты только по этому.
ARK>б) документация по языку говорит тебе, что все функции языка "выполняются напрямую"?
Так они напрямую и выполняются. Но если в сигнатуре функции написано что она должна вернуть структуру данных, выполнение ее приведет к возврату структуры данных (либо ошибке). С пониманием этого есть проблемы?
main в C++ возвращает int. main в Haskell возвращает IO a. int и IO a здесь структуры данных.

S>Нечистая силу вспоминают обычно там, где нет возможности что-то осмыслить.

Про осмыслить и прочую философию начинают говорить люди, у которых аргументов нет. А про нечистую силу вспоминает именно Хаскель, а не я. Это не я притворяюсь, что IO в мире нет.

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

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

S>>Эта необходимость ортогональна тому, идут значения в функцию отдельно или кортежем.

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

I>Ты путаешь контекст — это пример увеличения сложности. Если ты запихал это в кортеж, часть кода станет короче, но сложность никуда не денется — как была, так и осталась. Проявляется, например, в том, что на UI нужно бОльше тестов, на API нужно бОльше тестов. В разработке аналогично — всё равно надо валидировать, т.к. инпут вида Балтимор+Россия.
Эта сложность появилась не от применения кортежа.

I>>>Сложность восстановления(и частота ошибок) почему то зависит от количества фигур. Странно, да ?
S>>Что это меняет?

I>Известно что — принципиально отсутствует возможность бесплатного отката.
Верно для неперсистентных структур данных.

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

I>Итого — 1 ты согласен, что выдал огрызок и 2 пояснять отказываешься.
Для тебя это огрызок. И если учителя в школе не смогли пояснить, то мне это зачем?

I>>>А я думаю, что по месту 5го индекса будет нуль, а 6й останется там где и был.
S>>Не все так думают.

I>А откуда на массиве будет иначе?
Я пояснил, смотри выше.

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

I>Совсем необязательно. Значительная часть типичного веб-приложения написана на самом православном функциональном языке — SQL, а другая — на декларативном CSS где вообще нет никакой императивщины. Что характерно, и там и там обычно багов пруд пруди. Одни заметны глазом, вызывают негатив и недоверие, а другие стоят огромных денег Что интересно — когда SQL писали руками, багов было еще больше.

А я и не писал что это обязательно. Наоборот, отметил что это субъективные ощущения.

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

S>>Нечистая силу вспоминают обычно там, где нет возможности что-то осмыслить.

M>Про осмыслить и прочую философию начинают говорить люди, у которых аргументов нет. А про нечистую силу вспоминает именно Хаскель, а не я. Это не я притворяюсь, что IO в мире нет.

Благодарю за аргументы о мастурбации.

S>Благодарю за аргументы о мастурбации.

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

S>main в C++ возвращает int. main в Haskell возвращает IO a. int и IO a здесь структуры данных.
S>Если при этом тип результата функции будет int, а не Task<int> или IO int, то мне кашлять, что написано в документации.

То есть программы на С++ являются чистым ФП, что и требовалось доказать.

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

S>>Благодарю за аргументы о мастурбации.

M>Про мастурбацию я не говорил. Что отлично показывает, как ты читаешь аргументы оппонентов.
http://rsdn.org/forum/philosophy/7571110.1

Автор: Mamut
Дата: 20.10.19

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


S>>main в C++ возвращает int. main в Haskell возвращает IO a. int и IO a здесь структуры данных.
S>>Если при этом тип результата функции будет int, а не Task<int> или IO int, то мне кашлять, что написано в документации.

M>То есть программы на С++ являются чистым ФП, что и требовалось доказать.
Из моих слов это не следует.

S>>>main в C++ возвращает int. main в Haskell возвращает IO a. int и IO a здесь структуры данных.
S>>>Если при этом тип результата функции будет int, а не Task<int> или IO int, то мне кашлять, что написано в документации.

M>>То есть программы на С++ являются чистым ФП, что и требовалось доказать.
S>Из моих слов это не следует.

Следует напрямую.

M>>Про мастурбацию я не говорил. Что отлично показывает, как ты читаешь аргументы оппонентов.
S>http://rsdn.org/forum/philosophy/7571110.1

Автор: Mamut
Дата: 20.10.19

А. Ты смотри. Таки говорил Как еще донести до тебя простую мысль, что Хаскель из кожи вон лезет, чтобы притвориться, что IO не существует. Если мы наугад назначим целые куски программы несуществующими, то любой ЯП является чистым функциональным языком. Но про это уже четыре раза сказал AlexRK.

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

M>>>Про мастурбацию я не говорил. Что отлично показывает, как ты читаешь аргументы оппонентов.
S>>http://rsdn.org/forum/philosophy/7571110.1

Автор: Mamut
Дата: 20.10.19

M>А. Ты смотри. Таки говорил Как еще донести до тебя простую мысль, что Хаскель из кожи вон лезет, чтобы притвориться, что IO не существует.
Повтори слово "мастурбация" еще раз 40 или больше.

Повтори еще раз, что IO, даты и генератор случайных чисел — это чистое ФП, если назвать их actions (то есть притвориться, что их нет).

Показываю на пальцах:

Ты:

Однако, контроль за главным (отсутствием сайд-эффетов) в чистом фя проще. В императивном языке (или в гибриде) есть риск что зайдет студент и вставит сайд-эффект. Все скомпилится, и даже может быть тесты пройдут. А где-то в продакшне вылезет.

Опять ты:

Грубо говоря, функция вида

Action main() = () => { Console.WriteLine("Hello"); }

чиста, т.к. не делает побочных эффектов

Легкое движение руки:

Action main() = () => { System.sudo.remove_all_files_k_chertyam(); }

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

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

M>Повтори еще раз, что IO, даты и генератор случайных чисел — это чистое ФП, если назвать их actions (то есть притвориться, что их нет).

M>Показываю на пальцах:

M>Ты:

M>

M>Однако, контроль за главным (отсутствием сайд-эффетов) в чистом фя проще.

чистый фя. Утверждение о чистом функциональном языке. Отметим это.

M>Опять ты:

M>

M>Грубо говоря, функция вида

M>

M>Action main() = () => { Console.WriteLine("Hello"); }
M>

M>чиста, т.к. не делает побочных эффектов

Да, верно, функция чиста.

M>Легкое движение руки:

M>

M>Action main() = () => { System.sudo.remove_all_files_k_chertyam(); }
M>

И эта функция чиста.

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

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

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

S>>>Чистота — это свойство кода, а не документации.
ARK>>Пусть в документации написано: "свойством любой функции в С++ является то, что ее результатом является computation". Поясни, почему ты не согласен, что в этом случае любая функция в С++ будет чистой?
S>Определение чистоты построено на понятиях, отличных от документации. Потому для проверки чистоты я не будут руководствоваться документацией.

Ты не можешь без документации по языку судить о чистоте написанных на нем функций. Если можешь, то скажи, является ли чистой вот эта функция: "funktion Main % print Hello World \ @Q". Что это за язык, неважно, ведь ты не будешь руководствоваться документацией при проверке чистоты.

ARK>>В каком момент ИДЕОЛОГИЧЕСКИ возникает сайд-эффект — написано в документации. Если написано, что "функция создает действие, но не вызывает его" — значит, идеологически сайд-эффект возникает где-то потом, во внешнем запускателе.
S>Если при этом тип результата функции будет int, а не Task<int> или IO int, то мне кашлять, что написано в документации.

А, то есть computation должно быть обязательно явно записанным, а неявно выражено оно быть не может? Это твое личное мнение?

ARK>>Именно, что, если взять определение чистоты из википедии за базу, то это вопрос только трактовки слов "evaluation"/"invoke". Меняя их значение, ты получаешь противоположные результаты.
S>Какая цель в этом? Это поможет выполнить оптимизацию или упростить рассуждения о программах?

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

ARK>>Как раз поэтому я предложил свой вариант определения чистоты, который четко разграничивает понятия и хаскельный онанизм вприсядку сразу оказывается не у дел.
S>Хорошо, твоя чистота называет функции хаскеля грязными. Но это не отменяет рассуждения и возможности оптимизации хаскеля в терминах обычной чистоты.

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

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

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

S>Но называя int действием ты ничего не достигаешь в плане возможностей оптимизации и уж точно ухудшаешь понимание программы.

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

ARK>>Каким образом из википедийного определения читателю становится ясно, что evaluation в разных языках означает совершенно разные вещи и что чистота напрямую зависит от этого?
S>Да блин, почему они разные-то? Evaluation в С++ возвращает int и гадит в мир. В хаскле evaulation main вместо int возвращает композицию действий. Это одинаковые evaluation. Разница не в evaluation, а в организации кода.

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

S>>>У меня суждения вполне однозначны с точностью до заранее заданного перечня сайдэффектов. Заметь, терминами evaluate/invoke я не жонглирую и оперирую лишь обозримыми сайдэффектами (зафиксированными заранее).
ARK>>Ну вот есть обозримый сайд-эффект: печать "Hello, World". У тебя есть исполняемый файл, который печатает это предложение. У тебя есть код программы, который содержит в себе визуально видимое наименование системной функции печати с параметром "Hello, World". Что говорит твое суждение относительно чистоты данной программы, если: a) документация по языку говорит тебе, что все функции языка возвращают computation;
S>Откуда это взялось? нет, не все функции языка возвращают computation и чисты только по этому.

Это взялось из семантики языка. Создатель определил семантику именно так — ВСЕ функции языка возвращают computation, при этом никаких синтаксических меток для этого нет.
Что говорит твое суждение, чиста программа или нет?

ARK>>б) документация по языку говорит тебе, что все функции языка "выполняются напрямую"?
S>Так они напрямую и выполняются. Но если в сигнатуре функции написано что она должна вернуть структуру данных, выполнение ее приведет к возврату структуры данных (либо ошибке). С пониманием этого есть проблемы?

Без документации по языку мы не знаем, что записывается в сигнатуре функции. И что вообще означает сигнатура функции. В сигнатуре может быть голый int, но компилятор будет создавать "computation" для каждой функции (аналогия — см. checked/unchecked exception).

S>main в C++ возвращает int. main в Haskell возвращает IO a. int и IO a здесь структуры данных.

ОК, функция возвращает структуру данных QWERTY. Что говорит твое суждение, эта функция чистая или нет?

M>>

M>>Action main() = () => { System.sudo.remove_all_files_k_chertyam(); }
M>>

S>И эта функция чиста.

Если она чиста, почему она приводит к сайд-эффектам?

S>Т.е. то, что ты подверг сомнению этим примером — не мои слова, а уровень своего восприятия моих слов.

Нет никакого уровня восприятия слов, кроме одного:

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

Это строго эквивалентно следующему:

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