Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, samius, Вы писали:
S>>Либо на доверии. Вот для того и придумали отделять грязь от чистоты на уровне типов, что бы разметка чистоты торчала из каждой функции. Конечно, возможность сунуть грязь в любую чистую (по разметке) функцию, ломает всю прелесть разметки. Но при определенном доверии к источнику можно даже документацию не смотреть.
ARK>То есть мы таки плавно возвращаемся назад к "декларируемой" чистоте, а не "реальной". А декларируемая чистота от чего зависит — от сигнатуры функции и, как следствие, от спецификации языка, верно?
Естественно, речь идет о первом приближении, но не о гарантии. И конечно, о степени доверия источнику деклараций.
S>>main из кода никто не зовет. Ну и потом, кто-то же должен "вызывать" скобки у указателя на printf. Вот тот метод сразу станет грязным.
ARK>А почему, кстати. Ведь ты можешь вызвать в хаскеле unsafePerformIO внутри функции, и, пока ты не вызовешь эту функцию, грязи ведь никакой не будет?
Именно. Но функцию делает грязной не сам вызов, а уже упоминание грязи в контексте ее выполнения. Речь не про putStr, выполнение которой приводит к созданию грязного экшна без его выполнения.
ARK>То есть — в твоем понимании функция, содержащая внутри вызов unsafePerformIO, является чистой или грязной?
Это зависит от. Как в твоем примере с функцией test, которая напрямую звала unsafePerformIO — тут сразу ясно что и test грязная. Но если функция использует unsafePerformIO в рамках правильного IO (такое возможно, но смысл теряется), то она будет чиста. Здесь содержать != применять, вызывать.
S>>Немного не то, но похоже. А делает он это ровно для того, что бы затаскивать ввод-вывод в любую функцию было бы неудобно, что бы весь ввод-вывод байндился бы в одном месте. Иначе lazy с неконтролируемым вводом-выводам выбесит любого программиста. Как я понимаю, именно ленивость плохосовместима с IO в неожиданных местах.
ARK>Ну... Я бы сказал, не просто похоже, а вообще то же самое. А чтобы запретить затаскивать ИО куда попало, есть и более простые способы — скажем, явное деление на чистые и грязные функции. Впрочем, если я правильно понял, ты вроде бы сейчас согласен с тем, что в хаскеле есть грязные функции? Помеченные как IO — это "декларируемо грязные", а еще есть "реально грязные", но их мы никак опознать не можем. Но мы знаем, что они есть. Правда для нас толку с этого знания нет. Так?
Да, в хаскеле есть грязные функции. То же топорное FFI без заворачивания в IO — грязь. Помеченные как IO — это чистые функции, которые создают грязные action-ы, которые будут лить грязь исключительно при передачи управления им вместе с RealWorld.
Отличить чистые от грязных мы сможем. Но только через залезание в исходники, либо проводя некий эксперимент, надеясь, что его не придется выполнять до окончания существования вселенной, что бы гарантировать чистоту. Либо на чуйке, т.е. когда мы доверяем тому, что функция вычисляет длину списка и полагаем, что для этого нет нужды спамить в файл.
Здравствуйте, samius, Вы писали:
ARK>>То есть мы таки плавно возвращаемся назад к "декларируемой" чистоте, а не "реальной". А декларируемая чистота от чего зависит — от сигнатуры функции и, как следствие, от спецификации языка, верно? S>Естественно, речь идет о первом приближении, но не о гарантии. И конечно, о степени доверия источнику деклараций.
Разве есть вариант лучше? "Истинная чистота" это, конечно, хорошо, но что с нее толку.
ARK>>А почему, кстати. Ведь ты можешь вызвать в хаскеле unsafePerformIO внутри функции, и, пока ты не вызовешь эту функцию, грязи ведь никакой не будет? S>Именно. Но функцию делает грязной не сам вызов, а уже упоминание грязи в контексте ее выполнения.
Это не очень понял.
S>Да, в хаскеле есть грязные функции. То же топорное FFI без заворачивания в IO — грязь. Помеченные как IO — это чистые функции, которые создают грязные action-ы, которые будут лить грязь исключительно при передачи управления им вместе с RealWorld.
|-----------------------------------------------------|-----------------|-----------------|
| | Haskell | С |
|-----------------------------------------------------|-----------------|-----------------|
| Объявление IO-функции | f IO | typename f() |
|-----------------------------------------------------|-----------------|-----------------|
| Встраивание IO-функции в цепочку IO-вызовов | f >>= | f(); |
|-----------------------------------------------------|-----------------|-----------------|
| Встраивание IO-функции в цепочку любых вызовов | unsafePerformIO | отсутствует |
|-----------------------------------------------------|-----------------|-----------------|
| Объявление обычной функции | f | отсутствует |
|-----------------------------------------------------|-----------------|-----------------|
| Встраивание обычной функции в цепочку любых вызовов | f | отсутствует |
|-----------------------------------------------------|-----------------|-----------------|
Видишь разницу между printf и putStr? Ее нет. Мы можем правомочно рассматривать обе функции как декларируемо чистые функции, возвращающие декларируемо грязное действие. И даже функцию main в С — тоже.
Разница между языками есть в том, что в хаскеле есть декларируемо чистые функции, возвращающие декларируемо чистое действие (это не что иное, как "обычные" ленивые не-IO функции).
Здравствуйте, samius, Вы писали:
I>>Например, если вы уверены, что у вас баги с прода идут раз в месяц-два-полгода, то можете переформулировать гарантии качества в другом виде — гарантировано исправим любой найденый косяк или компенсируем деньгами.
S>В таком контексте восприятия слова "гарантии" мне не совсем ясно, как наличие кадра, занимающегося 100% поиском багов, влияет на возможность раздавать обещания компенсации? Контроль качества в виде систематической деятельности вообще напрямую с такими обещаниями не связан. Это ясно из твоего определения.
Не всё следует из определения Эта систематическая деятельность нужна именно для того, что бы проблемы по максимуму выявлялись и исправлялись на стороне разработки.
А далее нам нужна модель надежности, например, классификация, динамика, паттерны появления багов и тд. Собтсвенно это вероятностные методы, см. теория надежности.
Например, если ты видишь, что наработка на отказ, условно, несколько лет, то даешь гарантию от себя "год обслуживаем за свой счет".
I>>Цель это обязательный результат, если все прошло успешно. Если неуспешно — цель недостижима. И это тоже результат, те же самые гарантии. S>Я покупаю газпром, что бы разбогатеть завтра на 100 рублей. Т.е. завтра мы узнаем, была ли цель обязательным результатом этой покупки, или недостижимым? Но если я завтра, разбогатев на 100 рублей, захочу еще раз купить газпром. То послезавтра эта же цель будет недостижимой, при том, что сегодня она была обязательным результатом.... Прям, кот Шредингера на ровном месте.
Нет здесь никакого кота. Цель — разбогатеть — достигнута. А далее у тебя другая цель и она становится недостижимой, т.к. ты покупаешь газпром сам у себя.
I>>А я выделил ответ на твой вопрос. Нет способа заскриптовать "а проверь, есть ли нечто новое, неизвестное, подозрительное, что может повалить весь прод" S>Поверь, нет способа это гарантированно выполнить и вручную за конечное время. Проблему останова знаешь?
Простой пример — твой скрипт проверяет все имеющиеся счетчики производительности. А что на счет неучтенных факторов ? Как твой скрипт проверяет неучтенные факторы ?
I>>Требует. "Гарантированое подтверждение" включает в себя много всего S>Гарантированное подтверждение соответствия требованиям — это цель. И кстати, подтверждение соответствию требований не равно обещанию компенсировать.
Конечно же не равно. Давать обещание, если у теб нет никаких оснований, крайне странно.
I>>Разработчик совмещая роль тестировщика находится в постоянном конфликте интересов. Цели противоположные — вместо "быстрее написать" появляется "тщательнее протестировать" I>>В простых случаях совмещение работает. Но только в простых. Кроме того, в общем случае до кучи к конфликту интересов это совершенно разные знания, умения, подходы и методологии.
S>Тень на плетень. Твой ответ на тезис о том, что один единственный разработчик может обеспечить контроль качества в условиях, когда он занимается кроме поиска багов чем-то еще. Согласен или нет?
Я же прямо сказал — в простых случаях один разработчик справится. Что тут непонятно?
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, samius, Вы писали:
S>>Естественно, речь идет о первом приближении, но не о гарантии. И конечно, о степени доверия источнику деклараций.
ARK>Разве есть вариант лучше? "Истинная чистота" это, конечно, хорошо, но что с нее толку.
Именно лишь с истинной можно брать какой-то толк. Декларируемая (при расхождении с истинной) будет приносить лишь вред.
ARK>>>А почему, кстати. Ведь ты можешь вызвать в хаскеле unsafePerformIO внутри функции, и, пока ты не вызовешь эту функцию, грязи ведь никакой не будет? S>>Именно. Но функцию делает грязной не сам вызов, а уже упоминание грязи в контексте ее выполнения.
ARK>Это не очень понял.
функция с unsafePerformIO внутри может быть как чистой (если unsafe внутри IO), так и грязной — при прямом вызове unsafe.
S>>Да, в хаскеле есть грязные функции. То же топорное FFI без заворачивания в IO — грязь. Помеченные как IO — это чистые функции, которые создают грязные action-ы, которые будут лить грязь исключительно при передачи управления им вместе с RealWorld.
ARK>ОК. Введем терминологию: ARK>1) IO-функция — декларируемо чистая функция, возвращающая декларируемо грязный action.
Функция, возвращающая грязный action может быть и грязной (если помимо возвращения она еще и пачкает), и чистой, причем, не декларируемо, а вполне. ARK>1) Обычная функция — декларируемо чистая функция, возвращающая декларируемо чистый action.
Что такое "декларируемо чистый action", если в типе уже заложена трансформация мира?
ARK>Смотрим (синтаксис примерный, для иллюстрации):
ARK>
ARK>|-----------------------------------------------------|-----------------|-----------------|
ARK>| | Haskell | С |
ARK>|-----------------------------------------------------|-----------------|-----------------|
ARK>| Объявление IO-функции | f IO | typename f() |
ARK>|-----------------------------------------------------|-----------------|-----------------|
ARK>| Встраивание IO-функции в цепочку IO-вызовов | f >>= | f(); |
ARK>|-----------------------------------------------------|-----------------|-----------------|
ARK>| Встраивание IO-функции в цепочку любых вызовов | unsafePerformIO | отсутствует |
ARK>|-----------------------------------------------------|-----------------|-----------------|
ARK>| Объявление обычной функции | f | отсутствует |
ARK>|-----------------------------------------------------|-----------------|-----------------|
ARK>| Встраивание обычной функции в цепочку любых вызовов | f | отсутствует |
ARK>|-----------------------------------------------------|-----------------|-----------------|
ARK>
ARK>Видишь разницу между printf и putStr? Ее нет. Мы можем правомочно рассматривать обе функции как декларируемо чистые функции, возвращающие декларируемо грязное действие. И даже функцию main в С — тоже.
Разница есть. bind в хаскеле — чист. Вызов f() в C — дает немедленную грязь.
ARK>Разница между языками есть в том, что в хаскеле есть декларируемо чистые функции, возвращающие декларируемо чистое действие (это не что иное, как "обычные" ленивые не-IO функции).
что такое декларируемо чистое действие?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, samius, Вы писали:
S>>В таком контексте восприятия слова "гарантии" мне не совсем ясно, как наличие кадра, занимающегося 100% поиском багов, влияет на возможность раздавать обещания компенсации? Контроль качества в виде систематической деятельности вообще напрямую с такими обещаниями не связан. Это ясно из твоего определения.
I>Не всё следует из определения Эта систематическая деятельность нужна именно для того, что бы проблемы по максимуму выявлялись и исправлялись на стороне разработки. I>А далее нам нужна модель надежности, например, классификация, динамика, паттерны появления багов и тд. Собтсвенно это вероятностные методы, см. теория надежности. I>Например, если ты видишь, что наработка на отказ, условно, несколько лет, то даешь гарантию от себя "год обслуживаем за свой счет".
Это лирика. Ты привел определение. Если ты с ним не согласен, то чего его привел? Если согласен — почему у меня нет контроля качества? Ведь он следует из наличия любой систематической деятельности обусловленного направления по определению.
I>>>Цель это обязательный результат, если все прошло успешно. Если неуспешно — цель недостижима. И это тоже результат, те же самые гарантии. S>>Я покупаю газпром, что бы разбогатеть завтра на 100 рублей. Т.е. завтра мы узнаем, была ли цель обязательным результатом этой покупки, или недостижимым? Но если я завтра, разбогатев на 100 рублей, захочу еще раз купить газпром. То послезавтра эта же цель будет недостижимой, при том, что сегодня она была обязательным результатом.... Прям, кот Шредингера на ровном месте.
I>Нет здесь никакого кота. Цель — разбогатеть — достигнута. А далее у тебя другая цель и она становится недостижимой, т.к. ты покупаешь газпром сам у себя.
Что значит, сам у себя? Я так не умею. Я тебе говорю про две одинаковых покупки. У одной, выходит, результат гарантированный, в то время, как у другой — недостижимый. Ничего не смущает?
S>>Поверь, нет способа это гарантированно выполнить и вручную за конечное время. Проблему останова знаешь?
I> Простой пример — твой скрипт проверяет все имеющиеся счетчики производительности. А что на счет неучтенных факторов ? Как твой скрипт проверяет неучтенные факторы ?
Сколько тебе обычно нужно времени, что бы проверить ВСЕ неучтенные факторы вручную? Те, которые тебе взбредут в голову — можно заскриптовать. Которые не взбредут — как ты их проверишь вручную?
S>>Гарантированное подтверждение соответствия требованиям — это цель. И кстати, подтверждение соответствию требований не равно обещанию компенсировать.
I>Конечно же не равно. Давать обещание, если у теб нет никаких оснований, крайне странно.
Ты не с Марса? Вокруг меня все дают обещания, при отсутствии оснований их сдержать. Сдерживать обещание — лишь хороший тон, не более того. Взять деньги и не написать ни строчки кода — сплошь и рядом.
S>>Тень на плетень. Твой ответ на тезис о том, что один единственный разработчик может обеспечить контроль качества в условиях, когда он занимается кроме поиска багов чем-то еще. Согласен или нет?
I>Я же прямо сказал — в простых случаях один разработчик справится. Что тут непонятно?
Непонятно — насколько простых. Где грань? Где об этом в определении? Что за отсебятина? Покажи определение, где бы упоминались "простые случаи".
Здравствуйте, samius, Вы писали:
S>>>Естественно, речь идет о первом приближении, но не о гарантии. И конечно, о степени доверия источнику деклараций. ARK>>Разве есть вариант лучше? "Истинная чистота" это, конечно, хорошо, но что с нее толку. S>Именно лишь с истинной можно брать какой-то толк. Декларируемая (при расхождении с истинной) будет приносить лишь вред.
Истинную чистоту ты никак не определишь, поэтому толка с нее ровно ноль. Во всех известных мне языках под чистыми функциями понимаются "декларируемо чистые". Вред принести можно, безусловно. Но есть очень много способов для этого, не только расхождение декларируемой чистоты с реальной.
S>>>Да, в хаскеле есть грязные функции. То же топорное FFI без заворачивания в IO — грязь. Помеченные как IO — это чистые функции, которые создают грязные action-ы, которые будут лить грязь исключительно при передачи управления им вместе с RealWorld.
ARK>>ОК. Введем терминологию: ARK>>1) IO-функция — декларируемо чистая функция, возвращающая декларируемо грязный action. S>Функция, возвращающая грязный action может быть и грязной (если помимо возвращения она еще и пачкает), и чистой, причем, не декларируемо, а вполне.
Может. Это моим словам не противоречит.
ARK>>1) Обычная функция — декларируемо чистая функция, возвращающая декларируемо чистый action. S>Что такое "декларируемо чистый action", если в типе уже заложена трансформация мира?
Какая еще трансформация мира? "2 + 2" — это трансформация мира?
Func<int> MyFunc()
{
return (() => 2 + 2);
}
ARK>>Смотрим (синтаксис примерный, для иллюстрации): ARK>>
ARK>>|-----------------------------------------------------|-----------------|-----------------|
ARK>>| | Haskell | С |
ARK>>|-----------------------------------------------------|-----------------|-----------------|
ARK>>| Объявление IO-функции | f IO | typename f() |
ARK>>|-----------------------------------------------------|-----------------|-----------------|
ARK>>| Встраивание IO-функции в цепочку IO-вызовов | f >>= | f(); |
ARK>>|-----------------------------------------------------|-----------------|-----------------|
ARK>>| Встраивание IO-функции в цепочку любых вызовов | unsafePerformIO | отсутствует |
ARK>>|-----------------------------------------------------|-----------------|-----------------|
ARK>>| Объявление обычной функции | f | отсутствует |
ARK>>|-----------------------------------------------------|-----------------|-----------------|
ARK>>| Встраивание обычной функции в цепочку любых вызовов | f | отсутствует |
ARK>>|-----------------------------------------------------|-----------------|-----------------|
ARK>>
ARK>>Видишь разницу между printf и putStr? Ее нет. Мы можем правомочно рассматривать обе функции как декларируемо чистые функции, возвращающие декларируемо грязное действие. И даже функцию main в С — тоже. S>Разница есть. bind в хаскеле — чист. Вызов f() в C — дает немедленную грязь.
Разницы нет. Смотри таблицу. "f();" — это и есть bind.
UPD. Кстати, а с чего ты вообще взял, что "bind в хаскеле — чист"? Тебе кто-то сказал об этом, ты где-то прочитал об этом или, может, ты сам пытался проверить? Если пытался, то поясни, пожалуйста, каким образом ты заключил, что bind чист — вдруг он чист первые 100500 миллиардов вызовов, а потом дает грязь?
ARK>>Разница между языками есть в том, что в хаскеле есть декларируемо чистые функции, возвращающие декларируемо чистое действие (это не что иное, как "обычные" ленивые не-IO функции). S>что такое декларируемо чистое действие?
Здравствуйте, samius, Вы писали:
S>>>В таком контексте восприятия слова "гарантии" мне не совсем ясно, как наличие кадра, занимающегося 100% поиском багов, влияет на возможность раздавать обещания компенсации? Контроль качества в виде систематической деятельности вообще напрямую с такими обещаниями не связан. Это ясно из твоего определения.
I>>Не всё следует из определения Эта систематическая деятельность нужна именно для того, что бы проблемы по максимуму выявлялись и исправлялись на стороне разработки. I>>А далее нам нужна модель надежности, например, классификация, динамика, паттерны появления багов и тд. Собтсвенно это вероятностные методы, см. теория надежности. I>>Например, если ты видишь, что наработка на отказ, условно, несколько лет, то даешь гарантию от себя "год обслуживаем за свой счет".
S>Это лирика. Ты привел определение. Если ты с ним не согласен, то чего его привел? Если согласен — почему у меня нет контроля качества? Ведь он следует из наличия любой систематической деятельности обусловленного направления по определению.
Очевидно, что одним только определением всех проблем не решить. Факт в том, что для тебя в новинку связь качества и надежности.
I>>Нет здесь никакого кота. Цель — разбогатеть — достигнута. А далее у тебя другая цель и она становится недостижимой, т.к. ты покупаешь газпром сам у себя. S>Что значит, сам у себя? Я так не умею. Я тебе говорю про две одинаковых покупки. У одной, выходит, результат гарантированный, в то время, как у другой — недостижимый. Ничего не смущает?
Из твоего примера следует, что ты купил нечто существующее в единственном экземпляре. Далее ты покупаешь это же. Где тут две одинаковые покупки?
При правильном подходе результат вполне определен — цель или достигается, или есть нечто неучтенное в условии. Другого быть не может. И цель это никак не отменяет.
Ты путаешь постановку цели и конкретный результат.
I>> Простой пример — твой скрипт проверяет все имеющиеся счетчики производительности. А что на счет неучтенных факторов ? Как твой скрипт проверяет неучтенные факторы ? S>Сколько тебе обычно нужно времени, что бы проверить ВСЕ неучтенные факторы вручную? Те, которые тебе взбредут в голову — можно заскриптовать. Которые не взбредут — как ты их проверишь вручную?
Достаточно одного единственного, о котором стало известно в момент тестирования и который не отражен в скриптах. Тебе похоже даже в голову не приходит, как такое возможно
I>>Конечно же не равно. Давать обещание, если у теб нет никаких оснований, крайне странно. S>Ты не с Марса? Вокруг меня все дают обещания, при отсутствии оснований их сдержать. Сдерживать обещание — лишь хороший тон, не более того. Взять деньги и не написать ни строчки кода — сплошь и рядом.
Я уже понял, что слово гарантии у тебя является синонимом их отсутствия.
I>>Я же прямо сказал — в простых случаях один разработчик справится. Что тут непонятно? S>Непонятно — насколько простых. Где грань? Где об этом в определении? Что за отсебятина? Покажи определение, где бы упоминались "простые случаи".
Ты хочешь, что бы я изложил тебе теоретические основы качества, тестирования и надежности в одном определении. Может лучше сразу все тайны мироздания да в трех словах?
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, samius, Вы писали:
S>>>>Естественно, речь идет о первом приближении, но не о гарантии. И конечно, о степени доверия источнику деклараций. ARK>>>Разве есть вариант лучше? "Истинная чистота" это, конечно, хорошо, но что с нее толку. S>>Именно лишь с истинной можно брать какой-то толк. Декларируемая (при расхождении с истинной) будет приносить лишь вред.
ARK>Истинную чистоту ты никак не определишь, поэтому толка с нее ровно ноль. Во всех известных мне языках под чистыми функциями понимаются "декларируемо чистые". Вред принести можно, безусловно. Но есть очень много способов для этого, не только расхождение декларируемой чистоты с реальной.
Что значит, "никак не определишь"? Есть довольно большое кол-во функций, в чистоте которых просто не приходится сомневаться. Например, кому может в голову прийти засовывать грязь в вычисление синуса или проекцию последовательности? Мы и пользуемся ими, исходя из предположения, что использование таких функций не несет отражение в мире. Вот скажи, тебе нужны исходники логарифма или его документация, что бы убедиться в его чистоте?
S>>>>Да, в хаскеле есть грязные функции. То же топорное FFI без заворачивания в IO — грязь. Помеченные как IO — это чистые функции, которые создают грязные action-ы, которые будут лить грязь исключительно при передачи управления им вместе с RealWorld.
ARK>>>1) IO-функция — декларируемо чистая функция, возвращающая декларируемо грязный action. S>>Функция, возвращающая грязный action может быть и грязной (если помимо возвращения она еще и пачкает), и чистой, причем, не декларируемо, а вполне.
ARK>Может. Это моим словам не противоречит.
Противоречит. Ты обозначил что все функции IO декларируемо чистые, но я могу привести пример грязной функции, которая декларируемо чистая. Если оно не противоречит, то я не понимаю намерения от ввода декларируемой чистоты.
ARK>>>1) Обычная функция — декларируемо чистая функция, возвращающая декларируемо чистый action. S>>Что такое "декларируемо чистый action", если в типе уже заложена трансформация мира?
ARK>Какая еще трансформация мира? "2 + 2" — это трансформация мира?
Это не трансформация мира. Но и action-а тут никакого нет.
ARK>
Мы по-разному понимаем action.
ARK>>>Смотрим (синтаксис примерный, для иллюстрации): ARK>>>
ARK>>>|-----------------------------------------------------|-----------------|-----------------|
ARK>>>| | Haskell | С |
ARK>>>|-----------------------------------------------------|-----------------|-----------------|
ARK>>>| Объявление IO-функции | f IO | typename f() |
ARK>>>|-----------------------------------------------------|-----------------|-----------------|
ARK>>>| Встраивание IO-функции в цепочку IO-вызовов | f >>= | f(); |
ARK>>>|-----------------------------------------------------|-----------------|-----------------|
ARK>>>| Встраивание IO-функции в цепочку любых вызовов | unsafePerformIO | отсутствует |
ARK>>>|-----------------------------------------------------|-----------------|-----------------|
ARK>>>| Объявление обычной функции | f | отсутствует |
ARK>>>|-----------------------------------------------------|-----------------|-----------------|
ARK>>>| Встраивание обычной функции в цепочку любых вызовов | f | отсутствует |
ARK>>>|-----------------------------------------------------|-----------------|-----------------|
ARK>>>
ARK>>>Видишь разницу между printf и putStr? Ее нет. Мы можем правомочно рассматривать обе функции как декларируемо чистые функции, возвращающие декларируемо грязное действие. И даже функцию main в С — тоже. S>>Разница есть. bind в хаскеле — чист. Вызов f() в C — дает немедленную грязь.
ARK>Разницы нет. Смотри таблицу. "f();" — это и есть bind.
Вызов грязной функции не может быть bind-ом, т.к. bind не вызывает ничего, только связывает.
ARK>UPD. Кстати, а с чего ты вообще взял, что "bind в хаскеле — чист"? Тебе кто-то сказал об этом, ты где-то прочитал об этом или, может, ты сам пытался проверить? Если пытался, то поясни, пожалуйста, каким образом ты заключил, что bind чист — вдруг он чист первые 100500 миллиардов вызовов, а потом дает грязь?
Ему нет нужды делать грязь, ровно как и синусу. Ну и исходники его на каждом углу. IO в хаскеле реализуется через монаду State, которая чиста как слеза.
ARK>>>Разница между языками есть в том, что в хаскеле есть декларируемо чистые функции, возвращающие декларируемо чистое действие (это не что иное, как "обычные" ленивые не-IO функции). S>>что такое декларируемо чистое действие?
ARK>См. выше.
Что такое действие, почему ты обычные функции называешь действием? Синус — это действие?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, samius, Вы писали:
S>>Это лирика. Ты привел определение. Если ты с ним не согласен, то чего его привел? Если согласен — почему у меня нет контроля качества? Ведь он следует из наличия любой систематической деятельности обусловленного направления по определению.
I>Очевидно, что одним только определением всех проблем не решить. Факт в том, что для тебя в новинку связь качества и надежности.
Я не пытаюсь решать проблемы. Я пытаюсь понять, что ты мне пытаешься донести, ссылаясь на определение и делая выводы, противоречащие определению?
S>>Что значит, сам у себя? Я так не умею. Я тебе говорю про две одинаковых покупки. У одной, выходит, результат гарантированный, в то время, как у другой — недостижимый. Ничего не смущает?
I>Из твоего примера следует, что ты купил нечто существующее в единственном экземпляре. Далее ты покупаешь это же. Где тут две одинаковые покупки?
Ну ладно, про финансовые инструменты ты не слышал. Пусть я купил хлебушка.
I>При правильном подходе результат вполне определен — цель или достигается, или есть нечто неучтенное в условии. Другого быть не может. И цель это никак не отменяет.
Согласно твоим словам, цель либо гарантирована процессом, если процесс привел к успеху, либо недостижима, если не привел. Вот тебе процесс (если с газпромом так сложно): я покупаю хлебушка что бы набить брюхо. Почему сегодня результат может быть гарантированным, а завтра — недостижимым? Что я должен учесть?
I>Ты путаешь постановку цели и конкретный результат.
Ну так объясни мне! Поесть хлебушка — гарантирует набить брюхо, или делает цель недостижимой принципиально?
I>>> Простой пример — твой скрипт проверяет все имеющиеся счетчики производительности. А что на счет неучтенных факторов ? Как твой скрипт проверяет неучтенные факторы ? S>>Сколько тебе обычно нужно времени, что бы проверить ВСЕ неучтенные факторы вручную? Те, которые тебе взбредут в голову — можно заскриптовать. Которые не взбредут — как ты их проверишь вручную?
I>Достаточно одного единственного, о котором стало известно в момент тестирования и который не отражен в скриптах. Тебе похоже даже в голову не приходит, как такое возможно
А тебе не приходит в голову, что это фактор можно отразить в скриптах.
I>>>Конечно же не равно. Давать обещание, если у теб нет никаких оснований, крайне странно. S>>Ты не с Марса? Вокруг меня все дают обещания, при отсутствии оснований их сдержать. Сдерживать обещание — лишь хороший тон, не более того. Взять деньги и не написать ни строчки кода — сплошь и рядом.
I> Я уже понял, что слово гарантии у тебя является синонимом их отсутствия.
А у тебя гарантией отсутствия гарантий является отсутствие кадра, занимающегося 100% времени поиском.
I>>>Я же прямо сказал — в простых случаях один разработчик справится. Что тут непонятно? S>>Непонятно — насколько простых. Где грань? Где об этом в определении? Что за отсебятина? Покажи определение, где бы упоминались "простые случаи".
I> Ты хочешь, что бы я изложил тебе теоретические основы качества, тестирования и надежности в одном определении. Может лучше сразу все тайны мироздания да в трех словах?
Конечно, не хочу. У тебя лишь один вывод из определения опрокидывает уже это определение. Куда уж до тайн мироздания?
Здравствуйте, samius, Вы писали:
I>>Очевидно, что одним только определением всех проблем не решить. Факт в том, что для тебя в новинку связь качества и надежности.
S>Я не пытаюсь решать проблемы. Я пытаюсь понять, что ты мне пытаешься донести, ссылаясь на определение и делая выводы, противоречащие определению?
Часть вещей следует из определения, а именно "деятельность для гарантированного подтверждения"
Вот как эти самые гарантии получать и какие на их основе можно или нельзя делать обещания, на это отвечает в т.ч. теория надежности.
I>>Из твоего примера следует, что ты купил нечто существующее в единственном экземпляре. Далее ты покупаешь это же. Где тут две одинаковые покупки?
S>Ну ладно, про финансовые инструменты ты не слышал. Пусть я купил хлебушка.
Ок. Теперь покажи т.н. анализ ожиданий, логическую цепочку.
I>>При правильном подходе результат вполне определен — цель или достигается, или есть нечто неучтенное в условии. Другого быть не может. И цель это никак не отменяет. S>Согласно твоим словам, цель либо гарантирована процессом, если процесс привел к успеху, либо недостижима, если не привел. Вот тебе процесс (если с газпромом так сложно): я покупаю хлебушка что бы набить брюхо. Почему сегодня результат может быть гарантированным, а завтра — недостижимым? Что я должен учесть?
Нужно учесть все необходимые факторы, размер брюха, количество хлеба и тд и тд. То есть, построить адекватную модель. Если ты следуешь этой модели и процессу на её основе, то у тебя или будет достигнута цель, или будет выявлено нечто неучтенное в модели.
I>>Ты путаешь постановку цели и конкретный результат. S>Ну так объясни мне! Поесть хлебушка — гарантирует набить брюхо, или делает цель недостижимой принципиально?
См выше.
I>>Достаточно одного единственного, о котором стало известно в момент тестирования и который не отражен в скриптах. Тебе похоже даже в голову не приходит, как такое возможно S>А тебе не приходит в голову, что это фактор можно отразить в скриптах.
Ок, покажи пример, как заскриптовать нечто неизвестное на момент написания скрипта, включая все сорта расширений — база знаний и тд и тд и тд. Скажем, сегодня ты пишешь скрипт, а завтра мы узнаем скажем, неожиданные требования и не сразу, а во время работы этого самого скрипта.
Или так — ты заскриптуешь тот самый фактор, который случился у меня 8 лет назад во время прогона перформанс тестов, когда я только-только начал подогревать энвайрмент. Всё шло штатно, штанее некуда — все счетчики идеально ложились на ожидаемые результаты. Но прогон пришлось принудительно остановить. Вот покажи, пример скрипта. Потом мы вместе проверим, насколько хорош твой скрипт
Можешь иначе, текстом — сегодня или завтра, на крайняк до конца сего месяца, напиши сюда нечто, о чем ты ни разу не слышал, не видел, не подозревал с начала жизни и будешь ни видеть, ни слышать, ни подозревать вплоть до начала 2020
Здравствуйте, samius, Вы писали:
ARK>>Истинную чистоту ты никак не определишь, поэтому толка с нее ровно ноль. Во всех известных мне языках под чистыми функциями понимаются "декларируемо чистые". Вред принести можно, безусловно. Но есть очень много способов для этого, не только расхождение декларируемой чистоты с реальной. S>Что значит, "никак не определишь"?
То и значит. Ты ее не определишь никак, от слова совсем. Причем принципиально, фундаментально, не определишь. Можно взять одну и ту же программу на хаскеле и запустить ее сперва в виртуальной машине, которая выводит на принтер хоста каждое изменение регистров. А потом запустить в другой виртуальной машине, которая блокирует на хосте все запросы на ввод-вывод. В первом случае КАЖДАЯ функция в программе будет грязной. Во втором случае КАЖДАЯ функция в программе будет чистой. Вопрос: каковы же функции в этой программе, грязные или чистые? Программа одна и та же.
S>Есть довольно большое кол-во функций, в чистоте которых просто не приходится сомневаться. Например, кому может в голову прийти засовывать грязь в вычисление синуса или проекцию последовательности? Мы и пользуемся ими, исходя из предположения, что использование таких функций не несет отражение в мире.
Предлагаешь перейти к вере? Представляешь, пишет Пифагор тьфу ты, какой нафиг Пифагор, Евклид конечно на своих скрижалях: я верю, что параллельные прямые не пересекаются. Мамой клянусь, сам видел. Нарисовал километр — не пересеклись. Значит, не пересекаются.
Увы, это так не работает. Есть только два варианта: либо ты постулируешь что-то аксиоматически, либо доказываешь на основе существующих аксиом и теорем. Все, третьего не дано. С чистотой аналогично: либо ты постулируешь чистоту функции, либо доказываешь ее. Вера и чуйка — это не инженерный подход.
S>Вот скажи, тебе нужны исходники логарифма или его документация, что бы убедиться в его чистоте?
"Истинную" чистоту (чистоту в твоем понимании) не определить никак, ни по исходникам, ни по документации. И лично мне она не нужна. Мне нужна декларативная чистота (обещание компилятора или стандарта языка): либо ключевое слово в исходниках, либо текст в документации. На веру я ничего не принимаю.
ARK>>>>1) IO-функция — декларируемо чистая функция, возвращающая декларируемо грязный action. S>>>Функция, возвращающая грязный action может быть и грязной (если помимо возвращения она еще и пачкает), и чистой, причем, не декларируемо, а вполне. ARK>>Может. Это моим словам не противоречит. S>Противоречит. Ты обозначил что все функции IO декларируемо чистые, но я могу привести пример грязной функции, которая декларируемо чистая. Если оно не противоречит, то я не понимаю намерения от ввода декларируемой чистоты.
Не противоречит. Декларируемая чистота нужна для одного: для постулирования и понимания того, что компилятор будет с функцией обращаться как с чистой, невзирая на ее "истинную" чистоту. Это указание компилятору на возможность оптимизации и помощь программисту при чтении исходников. Что там на самом деле происходит — всем пофиг (см. пример выше с виртуальными машинами).
ARK>>>>Смотрим (синтаксис примерный, для иллюстрации): ARK>>>>
ARK>>>>|-----------------------------------------------------|-----------------|-----------------|
ARK>>>>| | Haskell | С |
ARK>>>>|-----------------------------------------------------|-----------------|-----------------|
ARK>>>>| Объявление IO-функции | f IO | typename f() |
ARK>>>>|-----------------------------------------------------|-----------------|-----------------|
ARK>>>>| Встраивание IO-функции в цепочку IO-вызовов | f >>= | f(); |
ARK>>>>|-----------------------------------------------------|-----------------|-----------------|
ARK>>>>| Встраивание IO-функции в цепочку любых вызовов | unsafePerformIO | отсутствует |
ARK>>>>|-----------------------------------------------------|-----------------|-----------------|
ARK>>>>| Объявление обычной функции | f | отсутствует |
ARK>>>>|-----------------------------------------------------|-----------------|-----------------|
ARK>>>>| Встраивание обычной функции в цепочку любых вызовов | f | отсутствует |
ARK>>>>|-----------------------------------------------------|-----------------|-----------------|
ARK>>>>
ARK>>>>Видишь разницу между printf и putStr? Ее нет. Мы можем правомочно рассматривать обе функции как декларируемо чистые функции, возвращающие декларируемо грязное действие. И даже функцию main в С — тоже. S>>>Разница есть. bind в хаскеле — чист. Вызов f() в C — дает немедленную грязь. ARK>>Разницы нет. Смотри таблицу. "f();" — это и есть bind. S>Вызов грязной функции не может быть bind-ом, т.к. bind не вызывает ничего, только связывает.
Ну а если абстрагироваться и представить, что "f();" — это не вызов, а связывание?
ARK>>UPD. Кстати, а с чего ты вообще взял, что "bind в хаскеле — чист"? Тебе кто-то сказал об этом, ты где-то прочитал об этом или, может, ты сам пытался проверить? Если пытался, то поясни, пожалуйста, каким образом ты заключил, что bind чист — вдруг он чист первые 100500 миллиардов вызовов, а потом дает грязь? S>Ему нет нужды делать грязь, ровно как и синусу. Ну и исходники его на каждом углу. IO в хаскеле реализуется через монаду State, которая чиста как слеза.
"Вера" и "чуйка"? Исходники тебе ничего не дадут. Про чистоту монады State тоже вопрос открытый. Ты рассуждаешь о чистоте отдельных функций и понятий аксиоматически, не так ли? Это то, с чего я начал разговор, кстати.
ARK>>>>Разница между языками есть в том, что в хаскеле есть декларируемо чистые функции, возвращающие декларируемо чистое действие (это не что иное, как "обычные" ленивые не-IO функции). S>>>что такое декларируемо чистое действие? S>Что такое действие, почему ты обычные функции называешь действием? Синус — это действие?
ОК, действие не очень хороший термин, пусть будет просто "функция". Одна декларируемо чистая функция возвращает другую декларируемо чистую функцию.
Здравствуйте, AlexRK, Вы писали: ARK>То и значит. Ты ее не определишь никак, от слова совсем. Причем принципиально, фундаментально, не определишь. Можно взять одну и ту же программу на хаскеле и запустить ее сперва в виртуальной машине, которая выводит на принтер хоста каждое изменение регистров. А потом запустить в другой виртуальной машине, которая блокирует на хосте все запросы на ввод-вывод. В первом случае КАЖДАЯ функция в программе будет грязной. Во втором случае КАЖДАЯ функция в программе будет чистой. Вопрос: каковы же функции в этой программе, грязные или чистые? Программа одна и та же.
Погодите, погодите. А что, интуитивно очевидный способ уже не работает?
Делаем очень просто:
1. Функция является грязной, если она принимает IO среди своих аргументов.
2. Функция, вызывающая грязную, является грязной.
Всё. Все остальные функции — чистые. (Исправил оговорку)
А, ну можно ещё делать так:
2.1. Функция, возвращающая тот же IO, что передан в аргументах, является чистой.
Но это — факультативно.
Всё получается очень просто: к примеру, функция синуса является чистой ровно до тех пор, пока она работает только со своими аргументами:
public number sin(number x) => exp(ImaginaryOne()*x)-exp(-ImaginaryOne()*x))/2/ImaginaryOne();
Для того, чтобы знать, что она чистая, нам достаточно посмотреть на сигнатуру. Потому, что у неё нет доступа к IO, так что она не может зависеть ни от чего, кроме своих аргументов.
Чтобы испортить мир, ей нужна ссылка на мир:
Всё, мы сразу видим даже по сигнатуре, что sin согрешила. Теперь любая функция, захотевшая использовать синус, должна где-то взять IO, и тоже стать грязной.
Но! Мы можем построить функцию sinsquared двумя способами:
public (number, IO) sinsquared((number x, IO world))
{
(var y, var world2)=sin(x, world);
(var r, var world3)=sin(x, world2);
return (r*y, world3);
});
public Function<IO, (number, IO)> sinsquared(number x)=>(IO world)=>
{
(var y, var world2)=sin(x, world);
(var r, var world3)=sin(x, world2);
return (y*r, world3);
});
В первом случае мы получаем грязную функцию, т.к. она обращается к IO. Во втором — чистую, т.к. сама она к IO не обращается, но строит функцию, которая обращается к IO.
Разница между разными версиями синуса (ака "полезность определения чистой функции") — в том, как ей можно пользоваться.
Вот мы строили sinsquared — пришлось дважды вызывать синус с разными версиями мира. А для обычного, простого синуса, достаточно было бы
public number sinsquared(number x) =>
{
var y = sin(x);
return y*y;
}
Разница была бы ещё более заметна, попробуй мы обобщить понятие squared. Скормить "грязный" синус в функцию
public number square(Function<number, number> core, number x) =>
{
var y = core(x);
return y*y;
}
нам не удастся. Придётся делать специальную версию, умеющую возводить в квадрат грязные функции:
public (number, IO) squared(Function<(number, IO), (number, IO)> core, (number x, IO world))
{
(var y, var world2)=core(x, world);
(var r, var world3)=core(x, world2);
return (r*y, world3);
});
Если бы мы работали с языком типа C, где мир доступен неявно — через static, global, и прочую аппаратуру, то нам пришлось бы подправить определения:
1. Грязной является функция, которая обращается "к миру".
2. Функция, вызывающая грязную, является грязной.
Всё, все остальные функции чистые. Разница между языками — в том, что теперь нам необходимо изучать исходники для понимания того, какая функция грязная, а какая — нет.
Альтернативой может стать включение ключевого слова pure в декларацию функции, а компилятор бы следил за выполнением п.1 и п.2.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
ARK>>То и значит. Ты ее не определишь никак, от слова совсем. Причем принципиально, фундаментально, не определишь. Можно взять одну и ту же программу на хаскеле и запустить ее сперва в виртуальной машине, которая выводит на принтер хоста каждое изменение регистров. А потом запустить в другой виртуальной машине, которая блокирует на хосте все запросы на ввод-вывод. В первом случае КАЖДАЯ функция в программе будет грязной. Во втором случае КАЖДАЯ функция в программе будет чистой. Вопрос: каковы же функции в этой программе, грязные или чистые? Программа одна и та же.
S>Погодите, погодите. А что, интуитивно очевидный способ уже не работает? S>Делаем очень просто: S>1. Функция является грязной, если она принимает IO среди своих аргументов. S>2. Функция, вызывающая грязную, является грязной. S>Всё. Все остальные функции — грязные. S>Если бы мы работали с языком типа C, где мир доступен неявно — через static, global, и прочую аппаратуру, то нам пришлось бы подправить определения: S>1. Грязной является функция, которая обращается "к миру". S>2. Функция, вызывающая грязную, является грязной. S>Всё, все остальные функции грязные. Разница между языками — в том, что теперь нам необходимо изучать исходники для понимания того, какая функция грязная, а какая — нет. S>Альтернативой может стать включение ключевого слова pure в декларацию функции, а компилятор бы следил за выполнением п.1 и п.2.
Абсолютно верный, правильный и единственно разумный способ. Увы, мой собеседник не принимает такого подхода, поэтому я играю на его поле и пытаюсь продемонстрировать, что его подход является бессмысленным.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, Sinclair, Вы писали:
S>>Погодите, погодите. А что, интуитивно очевидный способ уже не работает? S>>Делаем очень просто: S>>1. Функция является грязной, если она принимает IO среди своих аргументов. S>>2. Функция, вызывающая грязную, является грязной. S>>Всё. Все остальные функции — грязные.
ARK>Абсолютно верный, правильный и единственно разумный способ. Увы, мой собеседник не принимает такого подхода, поэтому я играю на его поле и пытаюсь продемонстрировать, что его подход является бессмысленным.
Я абсолютно согласен с таким подходом. Если функция обращается к миру — она грязная. Но тут есть нюанс. putStr не обращается к миру, следовательно она сама не грязная в соответствии с таким подходом. Обращается к миру функция, возвращенная putStr-ом в качестве результата. Она — грязная.
Здравствуйте, samius, Вы писали:
S>>>Погодите, погодите. А что, интуитивно очевидный способ уже не работает? S>>>Делаем очень просто: S>>>1. Функция является грязной, если она принимает IO среди своих аргументов. S>>>2. Функция, вызывающая грязную, является грязной. S>>>Всё. Все остальные функции — грязные.
ARK>>Абсолютно верный, правильный и единственно разумный способ. Увы, мой собеседник не принимает такого подхода, поэтому я играю на его поле и пытаюсь продемонстрировать, что его подход является бессмысленным.
S>Я абсолютно согласен с таким подходом. Если функция обращается к миру — она грязная.
Не "если функция обращается к миру", а "если функция принимает IO среди своих аргументов" (из чего следует аксиоматически заданная грязь для встроенных функций). Ты согласен с этим подходом? По-моему, ты все это время настаиваешь на подходе "функция грязная, если она _реально_ выполняет ввод-вывод".
S>Но тут есть нюанс. putStr не обращается к миру, следовательно она сама не грязная в соответствии с таким подходом. Обращается к миру функция, возвращенная putStr-ом в качестве результата. Она — грязная.
Мы это уже много раз проходили. Можно применить такую же модель для языка С и утверждать, что "printf не обращается к миру, а обращается к миру функция, возвращенная printf'ом в качестве результата".
Если бы ты мог в коде на хаскеле "оторвать" саму putStr от функции, которую она возвращает (вызвать putStr, но не вызывать то, что она возвращает, или вызвать этот action потом и из другого места), то разница с С была бы. Но ты не можешь.
S>Что же в этом бессмысленного?
Бессмысленно не это, а такое определение чистоты, которое невозможно проверить ("чистая функция не делает ввода-вывода"). Точнее, не оно само по себе бессмысленно, а бессмысленно его прямое применение в языках программирования.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, samius, Вы писали:
I>>>Очевидно, что одним только определением всех проблем не решить. Факт в том, что для тебя в новинку связь качества и надежности.
S>>Я не пытаюсь решать проблемы. Я пытаюсь понять, что ты мне пытаешься донести, ссылаясь на определение и делая выводы, противоречащие определению?
I> Часть вещей следует из определения, а именно "деятельность для гарантированного подтверждения"
Любая плановая и систематическая. I>Вот как эти самые гарантии получать и какие на их основе можно или нельзя делать обещания, на это отвечает в т.ч. теория надежности.
В определении нет речи об обещаниях. Освежи-ка его. Подтверждение соответствия требованиям. Все.
I>>>Из твоего примера следует, что ты купил нечто существующее в единственном экземпляре. Далее ты покупаешь это же. Где тут две одинаковые покупки?
S>>Ну ладно, про финансовые инструменты ты не слышал. Пусть я купил хлебушка.
I>Ок. Теперь покажи т.н. анализ ожиданий, логическую цепочку.
Твой критерий не требует анализа. Он основывался на успехе. Если успех есть — то есть гарантия, нет успеха — значит, он недостижим.
S>>Согласно твоим словам, цель либо гарантирована процессом, если процесс привел к успеху, либо недостижима, если не привел. Вот тебе процесс (если с газпромом так сложно): я покупаю хлебушка что бы набить брюхо. Почему сегодня результат может быть гарантированным, а завтра — недостижимым? Что я должен учесть?
I>Нужно учесть все необходимые факторы, размер брюха, количество хлеба и тд и тд. То есть, построить адекватную модель. Если ты следуешь этой модели и процессу на её основе, то у тебя или будет достигнута цель, или будет выявлено нечто неучтенное в модели.
Перечитай определение. В нем нет учета и анализа. В нем есть деятельность, реализуемая для гарантированного подтверждения соответствия требованиям. Остальное ты выдумал.
I>>>Достаточно одного единственного, о котором стало известно в момент тестирования и который не отражен в скриптах. Тебе похоже даже в голову не приходит, как такое возможно S>>А тебе не приходит в голову, что это фактор можно отразить в скриптах.
I> Ок, покажи пример, как заскриптовать нечто неизвестное на момент написания скрипта, включая все сорта расширений — база знаний и тд и тд и тд. Скажем, сегодня ты пишешь скрипт, а завтра мы узнаем скажем, неожиданные требования и не сразу, а во время работы этого самого скрипта.
Про неизвестное — ты тоже выдумал. "что производимые товары, услуги, выполняемые процессы соответствуют установленным требованиям". Установленным здесь в прошедшем времени. Нет никаких гарантий соответствия неизвестным и неожиданным требованиям. И быть не может.
I>Или так — ты заскриптуешь тот самый фактор, который случился у меня 8 лет назад во время прогона перформанс тестов, когда я только-только начал подогревать энвайрмент. Всё шло штатно, штанее некуда — все счетчики идеально ложились на ожидаемые результаты. Но прогон пришлось принудительно остановить. Вот покажи, пример скрипта. Потом мы вместе проверим, насколько хорош твой скрипт
Когда будут известны требования
I>Можешь иначе, текстом — сегодня или завтра, на крайняк до конца сего месяца, напиши сюда нечто, о чем ты ни разу не слышал, не видел, не подозревал с начала жизни и будешь ни видеть, ни слышать, ни подозревать вплоть до начала 2020
И часто ты гарантированно подтверждаешь нечто, "о чем ты ни разу не слышал, не видел, не подозревал с начала жизни и будешь ни видеть, ни слышать, ни подозревать вплоть до начала 2020 "
Ты вообще уверен, что это имеет отношение к контролю качества? Мне кажется что это про хрустальный шар.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, samius, Вы писали:
ARK>>>Истинную чистоту ты никак не определишь, поэтому толка с нее ровно ноль. Во всех известных мне языках под чистыми функциями понимаются "декларируемо чистые". Вред принести можно, безусловно. Но есть очень много способов для этого, не только расхождение декларируемой чистоты с реальной. S>>Что значит, "никак не определишь"?
ARK>То и значит. Ты ее не определишь никак, от слова совсем. Причем принципиально, фундаментально, не определишь. Можно взять одну и ту же программу на хаскеле и запустить ее сперва в виртуальной машине, которая выводит на принтер хоста каждое изменение регистров. А потом запустить в другой виртуальной машине, которая блокирует на хосте все запросы на ввод-вывод. В первом случае КАЖДАЯ функция в программе будет грязной. Во втором случае КАЖДАЯ функция в программе будет чистой. Вопрос: каковы же функции в этой программе, грязные или чистые? Программа одна и та же.
Я понял. Ты предлагаешь один и тот же "синус" выполнить грязно и чисто. Но причем тут "синус"? Ты переключился с чистоты кода на чистоту исполнения.
S>>Есть довольно большое кол-во функций, в чистоте которых просто не приходится сомневаться. Например, кому может в голову прийти засовывать грязь в вычисление синуса или проекцию последовательности? Мы и пользуемся ими, исходя из предположения, что использование таких функций не несет отражение в мире.
ARK>Предлагаешь перейти к вере? Представляешь, пишет Пифагор тьфу ты, какой нафиг Пифагор, Евклид конечно на своих скрижалях: я верю, что параллельные прямые не пересекаются. Мамой клянусь, сам видел. Нарисовал километр — не пересеклись. Значит, не пересекаются.
Причем тут вера? В евклидовой геометрии параллельными прямыми на плоскости называются непересекающиеся прямые.
ARK>Увы, это так не работает. Есть только два варианта: либо ты постулируешь что-то аксиоматически, либо доказываешь на основе существующих аксиом и теорем. Все, третьего не дано. С чистотой аналогично: либо ты постулируешь чистоту функции, либо доказываешь ее. Вера и чуйка — это не инженерный подход.
Согласен, по-строгому надо доказывать. Но это может работать в обе стороны. Утверждаешь, что putStr грязная — докажи.
S>>Вот скажи, тебе нужны исходники логарифма или его документация, что бы убедиться в его чистоте?
ARK>"Истинную" чистоту (чистоту в твоем понимании) не определить никак, ни по исходникам, ни по документации. И лично мне она не нужна. Мне нужна декларативная чистота (обещание компилятора или стандарта языка): либо ключевое слово в исходниках, либо текст в документации. На веру я ничего не принимаю.
Дак как же не определить? что с синусом-то не понятно?
Ну что, ты на верну ничего не принимаешь, но что если документацию писал человек верующий? Компилятор разрешит unsafe и ты попался со своей декларативной чистотой.
S>>Противоречит. Ты обозначил что все функции IO декларируемо чистые, но я могу привести пример грязной функции, которая декларируемо чистая. Если оно не противоречит, то я не понимаю намерения от ввода декларируемой чистоты.
ARK>Не противоречит. Декларируемая чистота нужна для одного: для постулирования и понимания того, что компилятор будет с функцией обращаться как с чистой, невзирая на ее "истинную" чистоту. Это указание компилятору на возможность оптимизации и помощь программисту при чтении исходников. Что там на самом деле происходит — всем пофиг (см. пример выше с виртуальными машинами).
А раз всем пофиг, то вообще какая ТЕБЕ разница, чистая функция или нет?
S>>Вызов грязной функции не может быть bind-ом, т.к. bind не вызывает ничего, только связывает.
ARK>Ну а если абстрагироваться и представить, что "f();" — это не вызов, а связывание?
Связывание, которое в момент вызова гадит в мир? Давай просто абстрагируемся от того, что f() гадит в мир и скажем, что всем пофиг?
S>>Ему нет нужды делать грязь, ровно как и синусу. Ну и исходники его на каждом углу. IO в хаскеле реализуется через монаду State, которая чиста как слеза.
ARK>"Вера" и "чуйка"? Исходники тебе ничего не дадут. Про чистоту монады State тоже вопрос открытый. Ты рассуждаешь о чистоте отдельных функций и понятий аксиоматически, не так ли? Это то, с чего я начал разговор, кстати.
Ну да почему исходники ничего не дадут? Ты их открывал? Вот открой код манады State и покажи мне в ней грязь.
ARK>>>>>Разница между языками есть в том, что в хаскеле есть декларируемо чистые функции, возвращающие декларируемо чистое действие (это не что иное, как "обычные" ленивые не-IO функции). S>>>>что такое декларируемо чистое действие? S>>Что такое действие, почему ты обычные функции называешь действием? Синус — это действие?
ARK>ОК, действие не очень хороший термин, пусть будет просто "функция". Одна декларируемо чистая функция возвращает другую декларируемо чистую функцию.
Допустим. И?
ARK>Мы это уже много раз проходили. Можно применить такую же модель для языка С и утверждать, что "printf не обращается к миру, а обращается к миру функция, возвращенная printf'ом в качестве результата".
Я же показал вроде, в чём разница между функциями, которые работают с миром, и функциями, которые работают с функциями, которые работают с миром.
Функция square по-прежнему является чистой, даже когда она возводит в квадрат грязную функцию. Например, результат square(sin, 10) можно кэшировать.
ARK>Если бы ты мог в коде на хаскеле "оторвать" саму putStr от функции, которую она возвращает (вызвать putStr, но не вызывать то, что она возвращает, или вызвать этот action потом и из другого места), то разница с С была бы. Но ты не можешь.
S>>Что же в этом бессмысленного? ARK>Бессмысленно не это, а такое определение чистоты, которое невозможно проверить ("чистая функция не делает ввода-вывода"). Точнее, не оно само по себе бессмысленно, а бессмысленно его прямое применение в языках программирования.
Это определение проверить очень легко: если у функции нет в аргументах IO, то она никак не может делать ввода-вывода.
Наличие unsafePerformIO — это специальная штука, которая на наше понимание чистоты не влияет.
Примерно так же, как то, что глагол GET в HTTP является безопасным: он по дизайну не может иметь побочных эффектов.
На практике это работает несколько наоборот: иметь-то он эти эффекты, конечно же, может (а кто ему запретит?), вот только полагаться на них мы не можем.
То есть, к примеру, если, допустим, мы сделаем так, что GET возвращает нам JS-объект {"name":"sinclair", "visitCount":42}, и будем инкрементировать visitCount при каждом исполнении, то не надо плакать, когда от нажатия F5 в браузере счётчик не растёт. Потому, что инфраструктура считает глагол безопасным, и имеет право брать результат из кэша.
Так и тут — если мы хотим сделать версию синуса, которая логгирует все вызовы, то можно либо сделать внутри неё unsafePerformIO — и тогда у нас количество и порядок строчек лога не будет детерминировано, либо по-честному вмешать в её сигнатуру IO, и тогда придётся честно выписывать порядок вычислений при её использовании.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, samius, Вы писали:
S>>Я абсолютно согласен с таким подходом. Если функция обращается к миру — она грязная.
ARK>Не "если функция обращается к миру", а "если функция принимает IO среди своих аргументов" (из чего следует аксиоматически заданная грязь для встроенных функций). Ты согласен с этим подходом? По-моему, ты все это время настаиваешь на подходе "функция грязная, если она _реально_ выполняет ввод-вывод".
Нет, не согласен. См. определение. Принимать IO — еще не грязь. Тем более, что putStr не принимает IO.
S>>Но тут есть нюанс. putStr не обращается к миру, следовательно она сама не грязная в соответствии с таким подходом. Обращается к миру функция, возвращенная putStr-ом в качестве результата. Она — грязная.
ARK>Мы это уже много раз проходили. Можно применить такую же модель для языка С и утверждать, что "printf не обращается к миру, а обращается к миру функция, возвращенная printf'ом в качестве результата".
ARK>Если бы ты мог в коде на хаскеле "оторвать" саму putStr от функции, которую она возвращает (вызвать putStr, но не вызывать то, что она возвращает, или вызвать этот action потом и из другого места), то разница с С была бы. Но ты не можешь.
Ну так может быть это и можно. Я просто курил Хаскель лет 10 назад последний раз. Судя по типу — они именно оторваны, т.к. putStr не принимает IO, не принимает RealWorld. Она принимает string.
S>>Что же в этом бессмысленного?
ARK>Бессмысленно не это, а такое определение чистоты, которое невозможно проверить ("чистая функция не делает ввода-вывода"). Точнее, не оно само по себе бессмысленно, а бессмысленно его прямое применение в языках программирования.
Ты намекаешь что не можешь им проверить даже чистоту оператор "+" в условиях выполнения, где сохраняется состояние процессора?
Тогда тебе нужно спуститься до определения сайд-эффекта, в частности, до понятия обозримого сайд-эффекта. Здесь нам приходится постулировать то, что высокоуровневый язык не обладает средствами для наблюдения за состоянием регистров процессора при исполнении своего оператора +.
Здравствуйте, samius, Вы писали:
ARK>>То и значит. Ты ее не определишь никак, от слова совсем. Причем принципиально, фундаментально, не определишь. Можно взять одну и ту же программу на хаскеле и запустить ее сперва в виртуальной машине, которая выводит на принтер хоста каждое изменение регистров. А потом запустить в другой виртуальной машине, которая блокирует на хосте все запросы на ввод-вывод. В первом случае КАЖДАЯ функция в программе будет грязной. Во втором случае КАЖДАЯ функция в программе будет чистой. Вопрос: каковы же функции в этой программе, грязные или чистые? Программа одна и та же. S>Я понял. Ты предлагаешь один и тот же "синус" выполнить грязно и чисто. Но причем тут "синус"? Ты переключился с чистоты кода на чистоту исполнения.
Это то, что следует из твоего подхода. Выполняет ли фактически функция ввод-вывод или нет — от нее вообще не зависит.
Так что же тогда такое "чистая функция", по-твоему? Чистых функций, получается, не бывает?
ARK>>Предлагаешь перейти к вере? Представляешь, пишет Пифагор тьфу ты, какой нафиг Пифагор, Евклид конечно на своих скрижалях: я верю, что параллельные прямые не пересекаются. Мамой клянусь, сам видел. Нарисовал километр — не пересеклись. Значит, не пересекаются. S>Причем тут вера? В евклидовой геометрии параллельными прямыми на плоскости называются непересекающиеся прямые.
Да. Это задано аксиоматически. То же самое и с чистотой (как минимум на уровне встроенных функций).
ARK>>Увы, это так не работает. Есть только два варианта: либо ты постулируешь что-то аксиоматически, либо доказываешь на основе существующих аксиом и теорем. Все, третьего не дано. С чистотой аналогично: либо ты постулируешь чистоту функции, либо доказываешь ее. Вера и чуйка — это не инженерный подход. S>Согласен, по-строгому надо доказывать. Но это может работать в обе стороны. Утверждаешь, что putStr грязная — докажи.
Либо доказывать, либо постулировать.
Чтобы утверждать что-либо о putStr, необходимо формализовать определения. Что есть "чистая", что есть "грязная", что есть "вызов", как отделить одно от другого. Иначе можно, жонглируя словами, спорить бесконечно.
ARK>>"Истинную" чистоту (чистоту в твоем понимании) не определить никак, ни по исходникам, ни по документации. И лично мне она не нужна. Мне нужна декларативная чистота (обещание компилятора или стандарта языка): либо ключевое слово в исходниках, либо текст в документации. На веру я ничего не принимаю. S>Дак как же не определить? что с синусом-то не понятно?
Ты знаешь постулированную кем-то (декларативную) чистоту синуса. Реальную ты не знаешь. Я могу легко написать свою грязную реализацию синуса.
S>Ну что, ты на верну ничего не принимаешь, но что если документацию писал человек верующий? Компилятор разрешит unsafe и ты попался со своей декларативной чистотой.
Это нормально и этого никак не избежать. И это не отменяет полезности декларативного разделения. И твое "правильное" определение не дает никакого лекарства от этого, потому что мы не можем им воспользоваться.
ARK>>Не противоречит. Декларируемая чистота нужна для одного: для постулирования и понимания того, что компилятор будет с функцией обращаться как с чистой, невзирая на ее "истинную" чистоту. Это указание компилятору на возможность оптимизации и помощь программисту при чтении исходников. Что там на самом деле происходит — всем пофиг (см. пример выше с виртуальными машинами). S>А раз всем пофиг, то вообще какая ТЕБЕ разница, чистая функция или нет?
Разница такая, что я с ней обращаюсь в коде как с чистой. Я считаю, что ввода-вывода в ней нет, и строю код, исходя из этого предположения. То же самое делает и компилятор, видя флаг "pure" (или отсутствие параметра "IO"). Мой код корректен относительно заданных этой функцией инвариантов. Есть там внутри реально ввод-вывод или нет — меня не интересует. Это слой абстракции. Абстракция позволяет справиться со сложностью и писать корректный код. Если инвариант, предоставляемый функцией, нарушается, то это проблема этой функции, а не моего кода. Я или заменю эту функцию на корректную, или перепишу код иным образом. Проверять контракты всех функций — нелепо. Чистота — это один из контрактов.
S>>>Вызов грязной функции не может быть bind-ом, т.к. bind не вызывает ничего, только связывает. ARK>>Ну а если абстрагироваться и представить, что "f();" — это не вызов, а связывание? S>Связывание, которое в момент вызова гадит в мир? Давай просто абстрагируемся от того, что f() гадит в мир и скажем, что всем пофиг?
Оно не гадит в момент связывания. А гадит, когда "внешний вычислитель" это запустит. В точности, как в хаскеле.
S>>>Ему нет нужды делать грязь, ровно как и синусу. Ну и исходники его на каждом углу. IO в хаскеле реализуется через монаду State, которая чиста как слеза. ARK>>"Вера" и "чуйка"? Исходники тебе ничего не дадут. Про чистоту монады State тоже вопрос открытый. Ты рассуждаешь о чистоте отдельных функций и понятий аксиоматически, не так ли? Это то, с чего я начал разговор, кстати. S>Ну да почему исходники ничего не дадут? Ты их открывал? Вот открой код манады State и покажи мне в ней грязь.
Что такое "грязь" в коде? Это вызов функций, которые ты считаешь грязными? А почему ты их считаешь грязными? Потому что это написано в документации?
Эта систематическая деятельность нужна именно для того, что бы проблемы по максимуму выявлялись и исправлялись на стороне разработки. 
Простой пример — твой скрипт проверяет все имеющиеся счетчики производительности. А что на счет неучтенных факторов ? Как твой скрипт проверяет неучтенные факторы ?
Ок, покажи пример, как заскриптовать нечто неизвестное на момент написания скрипта, включая все сорта расширений — база знаний и тд и тд и тд. Скажем, сегодня ты пишешь скрипт, а завтра мы узнаем скажем, неожиданные требования и не сразу, а во время работы этого самого скрипта. 
