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

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

О чем и речь. Чистота базовых функций просто постулируется, "проверить" ее нельзя.

ARK>>Если да, то все программы на хаскеле — грязные, ведь их evaluation имеет side effects. Верно?
S>Нет, здесь ошибка. main на Хаскеле определяет computation/action. Можно считать computation результатом evaluation программы на хаскеле.

ОК, тогда main на С++ тоже определяет computation/action, и все программы на С++ — чистые, как слеза младенца. Верно?

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

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

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

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

ARK>>>Если да, то все программы на хаскеле — грязные, ведь их evaluation имеет side effects. Верно?
S>>Нет, здесь ошибка. main на Хаскеле определяет computation/action. Можно считать computation результатом evaluation программы на хаскеле.

ARK>ОК, тогда main на С++ тоже определяет computation/action, и все программы на С++ — чистые, как слеза младенца. Верно?
Нет. Тип main на C++ известен. Результатом его выполнения будет int, а не computation. Провозглашать чистоту всех программ на C++ — явно перебор. Но для определенного подмножества всех программ — не возражаю.

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

ARK>>>>Если да, то все программы на хаскеле — грязные, ведь их evaluation имеет side effects. Верно?
S>>>Нет, здесь ошибка. main на Хаскеле определяет computation/action. Можно считать computation результатом evaluation программы на хаскеле.

ARK>>ОК, тогда main на С++ тоже определяет computation/action, и все программы на С++ — чистые, как слеза младенца. Верно?
S>Нет. Тип main на C++ известен. Результатом его выполнения будет int, а не computation.

Почему же? Результатом будет тоже computation. А потом этот computation выполнит процессор. Все то же самое, что и с хаскелем.

И, кстати, получается, что определение из википедии неполное, ведь термин "evaluation" можно трактовать разными способами и, в зависимости от выбранного варианта, получать противоположные результаты? Где "общепринятая" трактовка термина "evaluation"? Ее не существует? Тогда как можно вообще утверждать что-то о чистоте функций?

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

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

S>>Нет. Тип main на C++ известен. Результатом его выполнения будет int, а не computation.

ARK>Почему же? Результатом будет тоже computation. А потом этот computation выполнит процессор. Все то же самое, что и с хаскелем.
Ну что, теперь будем тереть, чем int отличается от computation?

ARK>И, кстати, получается, что определение из википедии неполное, ведь термин "evaluation" можно трактовать разными способами и, в зависимости от выбранного варианта, получать противоположные результаты? Где "общепринятая" трактовка термина "evaluation"? Ее не существует? Тогда как можно вообще утверждать что-то о чистоте функций?
Есть же отсылка к определению side effect без evaulation. https://en.wikipedia.org/wiki/Side_effect_(computer_science)
с примерами.

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

S>>>Нет. Тип main на C++ известен. Результатом его выполнения будет int, а не computation.
ARK>>Почему же? Результатом будет тоже computation. А потом этот computation выполнит процессор. Все то же самое, что и с хаскелем.
S>Ну что, теперь будем тереть, чем int отличается от computation?

И чем же int отличается от computation? Кстати, в C++ результатом выполнения main является не int, а побочные эффекты. Программа вообще может не завершаться никогда и никаких интов не возвращать.

ARK>>И, кстати, получается, что определение из википедии неполное, ведь термин "evaluation" можно трактовать разными способами и, в зависимости от выбранного варианта, получать противоположные результаты? Где "общепринятая" трактовка термина "evaluation"? Ее не существует? Тогда как можно вообще утверждать что-то о чистоте функций?
S>Есть же отсылка к определению side effect без evaulation. https://en.wikipedia.org/wiki/Side_effect_(computer_science)
S>с примерами.

Это маскировка той же двусмысленности под другими терминами. Чистая функция — это функция "БЕЗ побочных эффектов"? Подменили двусмысленность слова "evaluation" двусмысленностью слова "без"? ОК, в таком случае нет никаких оснований утверждать, что любая IO-функция в хаскеле является функцией БЕЗ побочных эффектов.

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

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

S>>Ну что, теперь будем тереть, чем int отличается от computation?

ARK>И чем же int отличается от computation? Кстати, в C++ результатом выполнения main является не int, а побочные эффекты. Программа вообще может не завершаться никогда и никаких интов не возвращать.
Программа может так же не дать и побочных эффектов. Но я говорил о сигнатуре. О типе результата.

ARK>>>И, кстати, получается, что определение из википедии неполное, ведь термин "evaluation" можно трактовать разными способами и, в зависимости от выбранного варианта, получать противоположные результаты? Где "общепринятая" трактовка термина "evaluation"? Ее не существует? Тогда как можно вообще утверждать что-то о чистоте функций?
S>>Есть же отсылка к определению side effect без evaulation. https://en.wikipedia.org/wiki/Side_effect_(computer_science)
S>>с примерами.

ARK>Это маскировка той же двусмысленности под другими терминами. Чистая функция — это функция "БЕЗ побочных эффектов"? Подменили двусмысленность слова "evaluation" двусмысленностью слова "без"? ОК, в таком случае нет никаких оснований утверждать, что любая IO-функция в хаскеле является функцией БЕЗ побочных эффектов.
Как это? Лично я затрудняюсь назвать побочные эффекты IO-функций в хаскеле, глядя на их сигнатуры. Ну вот, например, putStr принимает строку и возвращает IO(), который в свою очередь есть тип данных. В чем может заключаться её побочный эффект?

M>>Да-да. Console.WriteLine является чистым. Потому что IO — это миф.
S>Что за чушь?

Ну ты ее пишешь

S>Т.е. если я покажу чистую программу целиком на хаскеле, то это будет примером невозможного?

Такая программа не будет выполнять IO и/или работать с временем. Поэтому с практической точки зрения она будет чуть менее, чем бесполезна.

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

main = putStrLn "Hello World!"

Run this code and you'll see that it miraculously makes text appear on your screen. A pure function can't do that -- it cannot have side effects!

So what's happening here? Haskell runtime evaluates main (it's really just an expression). The trick is that main evaluates not to a simple value but to an action. The runtime then executes this action.

So the program itself has no side effects, but the action does.

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


M>>>Да-да. Console.WriteLine является чистым. Потому что IO — это миф.
S>>Что за чушь?

M>Ну ты ее пишешь
Я такого не писал.

S>>Т.е. если я покажу чистую программу целиком на хаскеле, то это будет примером невозможного?

M>Такая программа не будет выполнять IO и/или работать с временем. Поэтому с практической точки зрения она будет чуть менее, чем бесполезна.

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

M>

M>

M>main = putStrLn "Hello World!"
M>

M>Run this code and you'll see that it miraculously makes text appear on your screen. A pure function can't do that -- it cannot have side effects!

M>So what's happening here? Haskell runtime evaluates main (it's really just an expression). The trick is that main evaluates not to a simple value but to an action. The runtime then executes this action.

M>So the program itself has no side effects, but the action does.

M>

Сам-то прочитал, что процитировал? Если да, то с чем не согласен?

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

ARK>>И чем же int отличается от computation? Кстати, в C++ результатом выполнения main является не int, а побочные эффекты. Программа вообще может не завершаться никогда и никаких интов не возвращать.
S>Программа может так же не дать и побочных эффектов. Но я говорил о сигнатуре. О типе результата.

Вполне можно считать сигнатурой и типом результата функции main в С++ тем же computation<int>. Нет никаких оснований так не считать.

ARK>>>>И, кстати, получается, что определение из википедии неполное, ведь термин "evaluation" можно трактовать разными способами и, в зависимости от выбранного варианта, получать противоположные результаты? Где "общепринятая" трактовка термина "evaluation"? Ее не существует? Тогда как можно вообще утверждать что-то о чистоте функций?
S>>>Есть же отсылка к определению side effect без evaulation. https://en.wikipedia.org/wiki/Side_effect_(computer_science)
S>>>с примерами.

ARK>>Это маскировка той же двусмысленности под другими терминами. Чистая функция — это функция "БЕЗ побочных эффектов"? Подменили двусмысленность слова "evaluation" двусмысленностью слова "без"? ОК, в таком случае нет никаких оснований утверждать, что любая IO-функция в хаскеле является функцией БЕЗ побочных эффектов.
S>Как это? Лично я затрудняюсь назвать побочные эффекты IO-функций в хаскеле, глядя на их сигнатуры. Ну вот, например, putStr принимает строку и возвращает IO(), который в свою очередь есть тип данных. В чем может заключаться её побочный эффект?

В соответствии с определением, побочным эффектом является вызов системных функций ввода-вывода:

In computer science, an operation, function or expression is said to have a side effect if it modifies some state variable value(s) outside its local environment, that is to say has an observable effect besides returning a value (the main effect) to the invoker of the operation. State data updated "outside" of the operation may be maintained "inside" a stateful object or a wider stateful system within which the operation is performed. Example side effects include modifying a non-local variable, modifying a static local variable, modifying a mutable argument passed by reference, performing I/O or calling other side-effect functions.

То, что записано в сигнатуре хаскелевой функции — "IO" — это не "performing I/O", это просто метка. "Performing I/O" — это фактическое выполнение системных функций. И если вследствие "invoke" функции произойдет performing I/O, то эта функция — с побочными эффектами и, как следствие из предыдущего определения, нечистая. Таким образом, двусмысленное слово "evaluation" заменено на ровно такое же двусмысленное слово "invoke". По-прежнему различная трактовка слова "evaluation"/"invoke" приводит к противоположным результатам при попытке применить определение чистоты, данное в википедии.

Кстати, а вот есть черный ящик. Исполняемый файл. Он при запуске выводит на экран "Hello, World!". Программа, результатом компиляции которой стал этот файл, — чистая или нет?

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

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

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

ARK>Вполне можно считать сигнатурой и типом результата функции main в С++ тем же computation<int>. Нет никаких оснований так не считать.
Раз, нет оснований, тогда считай. От меня нужно разрешение?

S>>Как это? Лично я затрудняюсь назвать побочные эффекты IO-функций в хаскеле, глядя на их сигнатуры. Ну вот, например, putStr принимает строку и возвращает IO(), который в свою очередь есть тип данных. В чем может заключаться её побочный эффект?

ARK>В соответствии с определением, побочным эффектом является вызов системных функций ввода-вывода:
putStr не вызывает системных функций ввода-вывода.

ARK>То, что записано в сигнатуре хаскелевой функции — "IO" — это не "performing I/O", это просто метка. "Performing I/O" — это фактическое выполнение системных функций. И если вследствие "invoke" функции произойдет performing I/O, то эта функция — с побочными эффектами и, как следствие из предыдущего определения, нечистая. Таким образом, двусмысленное слово "evaluation" заменено на ровно такое же двусмысленное слово "invoke". По-прежнему различная трактовка слова "evaluation"/"invoke" приводит к противоположным результатам при попытке применить определение чистоты, данное в википедии.
invoke функции putStr не приводит к performing I/O.

ARK>Кстати, а вот есть черный ящик. Исполняемый файл. Он при запуске выводит на экран "Hello, World!". Программа, результатом компиляции которой стал этот файл, — чистая или нет?
Может быть чистой, как в случае с Haskell, может быть нет. В общем случае чистый исходный код программы не обязан компилироваться в чистый исполняемый файл. Как и наоборот.

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

S>>>Программа может так же не дать и побочных эффектов. Но я говорил о сигнатуре. О типе результата.
ARK>>Вполне можно считать сигнатурой и типом результата функции main в С++ тем же computation<int>. Нет никаких оснований так не считать.
S>Раз, нет оснований, тогда считай. От меня нужно разрешение?

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

А если я форкну С++, назову язык "C++PURE" и изменю одну-единственную строчку в описании типа "функция", которая будет говорить, что "результат любой функции в С++ — это computation", то ты согласишься, что любые функции на этом языке будут совершенно чистыми, не грязнее хаскелевых? Компиляторы, я само собой, писать не буду, достаточно и текущих — ведь главное в документации сказать, что функция возвращает computation, и чистота придет сама собой.

S>>>Как это? Лично я затрудняюсь назвать побочные эффекты IO-функций в хаскеле, глядя на их сигнатуры. Ну вот, например, putStr принимает строку и возвращает IO(), который в свою очередь есть тип данных. В чем может заключаться её побочный эффект?
ARK>>В соответствии с определением, побочным эффектом является вызов системных функций ввода-вывода:
S>putStr не вызывает системных функций ввода-вывода.

Тогда printf в С++ тоже не вызывает системных функций ввода-вывода.

ARK>>То, что записано в сигнатуре хаскелевой функции — "IO" — это не "performing I/O", это просто метка. "Performing I/O" — это фактическое выполнение системных функций. И если вследствие "invoke" функции произойдет performing I/O, то эта функция — с побочными эффектами и, как следствие из предыдущего определения, нечистая. Таким образом, двусмысленное слово "evaluation" заменено на ровно такое же двусмысленное слово "invoke". По-прежнему различная трактовка слова "evaluation"/"invoke" приводит к противоположным результатам при попытке применить определение чистоты, данное в википедии.
S>invoke функции putStr не приводит к performing I/O.

А что тогда приводит к performing I/O? И почему "то, что приводит к performing I/O", не является "invoke"?

ARK>>Кстати, а вот есть черный ящик. Исполняемый файл. Он при запуске выводит на экран "Hello, World!". Программа, результатом компиляции которой стал этот файл, — чистая или нет?
S>Может быть чистой, как в случае с Haskell, может быть нет. В общем случае чистый исходный код программы не обязан компилироваться в чистый исполняемый файл. Как и наоборот.

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

Если это не мастурбация вприсядку, то что это тогда?

S>Сам-то прочитал, что процитировал? Если да, то с чем не согласен?

Я уже говорил:

из кожи вон лезет, чтобы притвориться, что он не делает сайд-эффектов. И притворяется, что IO — это не Хаскель. Это всего лишь вызов нечистой силы, которая к Хаскелю не имеет отношения.

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

I>>У тебя чтото выходит, да. "Откуда взялись связи при построении кортежа"
I>>Делаешь вид, что типа не понял про связь страны и города.
S>Про связь понял. Не понял, почему до построения кортежа ее не было, а после — появилась.

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

I>>Разумеется. Только восстановить старое может не выйдет вовсе. А если задаться целью восстановить идеально, до долей миллиметра, то и вовсе будет невозможным.
S>Города и страны ниоткуда, доли миллиметра в идеальном восстановлении шахматной позиции... Продолжай в том же духе!

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

I>>Именно. Тут нет какого то чуда, с опытом "не получилось" это довольно редкий кейс. Другого то варианта и не было — пока периферия не работает, пока не сможешь прогнать пуско-наладочные тесты, у тебя вобщем ничего другого и не было.
S>И это мне говорит человек, который считает что конс-списки сложные.

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

I>>Не понятен вопрос.
S>Удельный вес/объем не слышал?

Если ты не хочешь быть понятым, для чего ты пишешь ?

I>>Это ты перевираешь мои слова. Я всего лишь неприемлю чистое ФП. Ровно как и чистое ИП.
S>Я ровно об этом и говорю, что нет мотивации переступать через "неприемлю".

Парадигма используется ради бенефитов, а не ради самой себя.

I>>Я дудкой называю всё, во что дудеть можно: труба, гобой, саксофон
S>Трезвучия извлекать будешь сразу тремя инструментами в один рот?

То есть, снова сказать нечего

S>>>Ты в пол шаге от того, что ФП или ИП — не имеет значения.

I>>Последние две недели я именно это и говорю — парадигма это всего лишь средство перевода имеющегося решения в код.
I>>Решил — запиши. А у тебя парадигма это эдакий всемогутор, в котором всё само, легко и просто, и куда входит весь имеющийся computer science.
S>Передернул. Я писал о конкретных вещах, которым в ИП приходится уделять внимание, а в ФП не требуется.

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

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

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

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

Кое где легче, кое где наоборот сложнее. На каждый чих клонировать длинный буфер в драйвере тебе никто не даст.

I>>Вот конкретный язык, фремворк — это учится от недели до года.
S>Учится от недели до года, но времени попортить может очень много, при этом, ничему новому больше не научит.

Я об этом и говорю — и язык, и фремворк сам по себе ничего новому не научит.

I>>Со структурами данных все зависит от задач, которыми ты занимаешься. Разные области требуют разные знания. Многие до графов и за десятки лет недобираются. Другие там сидят денно и нощно.
S>У меня был начальник отдела (программистов), который на C++ к 50и годам не добрался до указателя. Приходил ко мне, что бы я ему ткнул пальцем, куда звездочку поставить.

Вот еще одно объяснение

I>>Вопрос в том, что ты хочешь делать с этим ДОМ. Если только рисовать HTML, хватит и дерева, а если не html, а что то другое — может и граф понадобиться. Фактически, это хитрый такой сторадж, который унутре может быть каким угодно.
S>С графом тут есть органичения. В персистентных структурах не может быть циклов, поэтому всегда дерево. Либо вводить лишнюю косвенность. Два узла не могут хранить ссылки друг на друга, но могут хранить идентификаторы друг друга.

Вот-вот. А вот в императивном такое ограничение побоку — когда есть существенный бенефит, можно и убрать эту косвенность, и навводить циклов. Собтсвенно, не "можно", а "нужно".

I>>Именно. Допустим, ты номера знаешь. Раскрыл на нужном месте и думаешь, что же делать — править или не править, если править, то как.
S>Вот-вот. Думать, как удалением не сломать нумерацию, которой ты воспользовался, что бы раскрыть на нужном месте.

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

I>>На самом деде это разные операции — валидирование и коррекция. Мы можем просто этим воспользоваться. Если мы знаем, что кривые кадры 5 и 8, то надо обработать только их и не надо ничего копировать.
S>Так в ФП тоже можно обработать только их, после чего собрать новый блокнот с новыми страницами.

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

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

S>Слабаки. У меня мама фиксила баги прямо ножницами в перфокартах.

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

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

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

ARK>>>Вполне можно считать сигнатурой и типом результата функции main в С++ тем же computation<int>. Нет никаких оснований так не считать.
S>>Раз, нет оснований, тогда считай. От меня нужно разрешение?

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

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

S>>putStr не вызывает системных функций ввода-вывода.

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

S>>invoke функции putStr не приводит к performing I/O.

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

S>>Может быть чистой, как в случае с Haskell, может быть нет. В общем случае чистый исходный код программы не обязан компилироваться в чистый исполняемый файл. Как и наоборот.

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

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

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

S>>Сам-то прочитал, что процитировал? Если да, то с чем не согласен?

M>Я уже говорил:

M>

M>из кожи вон лезет, чтобы притвориться, что он не делает сайд-эффектов. И притворяется, что IO — это не Хаскель. Это всего лишь вызов нечистой силы, которая к Хаскелю не имеет отношения.

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

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

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

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

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

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

I>>>Не понятен вопрос.
S>>Удельный вес/объем не слышал?

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

I>>>Это ты перевираешь мои слова. Я всего лишь неприемлю чистое ФП. Ровно как и чистое ИП.
S>>Я ровно об этом и говорю, что нет мотивации переступать через "неприемлю".

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

I>>>Я дудкой называю всё, во что дудеть можно: труба, гобой, саксофон
S>>Трезвучия извлекать будешь сразу тремя инструментами в один рот?

I>То есть, снова сказать нечего
Именно. Нет слов.

S>>Передернул. Я писал о конкретных вещах, которым в ИП приходится уделять внимание, а в ФП не требуется.

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

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

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

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

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

S>>С графом тут есть органичения. В персистентных структурах не может быть циклов, поэтому всегда дерево. Либо вводить лишнюю косвенность. Два узла не могут хранить ссылки друг на друга, но могут хранить идентификаторы друг друга.

I>Вот-вот. А вот в императивном такое ограничение побоку — когда есть существенный бенефит, можно и убрать эту косвенность, и навводить циклов. Собтсвенно, не "можно", а "нужно".
Да, верно.

S>>Вот-вот. Думать, как удалением не сломать нумерацию, которой ты воспользовался, что бы раскрыть на нужном месте.

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

I>>>На самом деде это разные операции — валидирование и коррекция. Мы можем просто этим воспользоваться. Если мы знаем, что кривые кадры 5 и 8, то надо обработать только их и не надо ничего копировать.
S>>Так в ФП тоже можно обработать только их, после чего собрать новый блокнот с новыми страницами.

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

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

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

S>>Слабаки. У меня мама фиксила баги прямо ножницами в перфокартах.

P>Ножницами — это и правда очень круто. Я фиксил лезвием. А иногда клеем и кусочком такой же карты, что намного сложнее. Потому что если не очень аккуратно заклеить, карта могла застрять в считывателе. А с появлением новых, вакуумных считывателей, заклеивать дырки стало бесполезно. Правда, мой опыт в этих делах невелик. Лаптев с этим намного больше сталкивался.

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

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

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

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

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

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

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

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

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

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

S>>>Может быть чистой, как в случае с Haskell, может быть нет. В общем случае чистый исходный код программы не обязан компилироваться в чистый исполняемый файл. Как и наоборот.
ARK>>То есть есть два абсолютно одинаковых файла, при запуске вызывающих абсолютно одинаковые системные функции, и даже скомпилированных в одинаковый машинный код, но при этом программа на хаскеле — чистая, а программа на С++ — нечистая. Всё верно?
S>Здесь все верно. С поправкой на то, что мы рассуждаем не о чистоте машинного кода, а о чистоте кода в исходниках.

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

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

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

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

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

Ты согласен, что определение чистоты, не позволяющее однозначно судить, чиста функция/программа или нет, является бессмысленным? И что, пользуясь этим определением, нельзя утверждать что-либо относительно чистоты любой программы/функции?

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

S>Может и лезвием. Точно знаю, что у нее был скальпель. Но чем она там конкретно дырки била — могу уточнить.

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