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

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

Это неверная аналогия.

Согласно определению

Контроль качества – любая плановая и систематическая деятельность, проводимая на производственном предприятии (в производственной системе), которая реализуется для гарантированного подтверждения того, что производимые товары, услуги, выполняемые процессы соответствуют установленным требованиям

Итого — цель именно гарантии. Если гарантии необязательны, то и контроль необязателен. В таком случае нечего и парадигму тащить сюда

S>Мы их не ищем, они нас сами находят ))) На самом деле, часть будущих проблем видно на этапе разработки.

Задачи тестирования —
1 сделать эту долю максимально возможной
2 проверить, что все это решено, учтено и тд

Этим и обеспечиваются гарантии

I>>Именно так это и делается — ктото улучшает продукт фиксами, а ктото улучшает продукт обнаруженными проблемами. Кому интереснее пилить код продукта — пилит продукт, кому интереснее пилить код тестов, пилит тесы, кому интересны сценарии, тесткейсы и тд, занят именно этими вещами.

S>Так делается, когда продукт дядин. Будут проблемы — наймем кого надо и он будет делать то, что надо, а не то, что ему интересно.

Дядин или нет — дело десятое. Ощущение, что ты на тестирование смотришь как на чтото лишнее
Так делается, когда цена ошибки высока.
Чему равняется цена ошибки? Какого рода данные хранят в вашем файлохранилище?
Вы риски заказчика разделяете или вешаете на него? Пенальти за баг на проде платите?

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

Лично я внятный контроль качества вижу в серьёзных продуктовых конторах, т.е. "на себя". Энтарпрайзу до таких высот как до небес. В энтерпрайзе можно увидеть проекты вообще без тестирования, абы картинка была красивая. Для серьезной продуктовой конторы это смерть от имиджевых потерь. Как только юзеры догадаются, что контора продает пустышки, на ней сразу ставят жирный чорный крест.

I>>Очевидно, что такие вещи тестировщик делает не руками. Но сценарий и ожидания новые, ранее не зафиксированы ни одним из авто-тестов.
S>Извини, но по-моему ты пытаешься решать проблемы, которых нет, и которые тебя решать не просили.

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

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

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

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

I>Это неверная аналогия.
Верная.

I>Согласно определению
I>

I>Контроль качества – любая плановая и систематическая деятельность, проводимая на производственном предприятии (в производственной системе), которая реализуется для гарантированного подтверждения того, что производимые товары, услуги, выполняемые процессы соответствуют установленным требованиям

Какое хорошее определение. Оно как раз показывает, что контроль качества у нас есть. Жаль, что ты с ним не согласен. Но это не моя забота.

I>Итого — цель именно гарантии. Если гарантии необязательны, то и контроль необязателен. В таком случае нечего и парадигму тащить сюда
Цель деятельности — гарантии. Но гарантии не следуют из наличия деятельности, т.е. не являются обязательным следствием такой деятельности. Импликации тут нет. Тут нет импликации, и уж тем более нет эквиваленции, которую ты неудачно попытался опровергнуть.

S>>Мы их не ищем, они нас сами находят ))) На самом деле, часть будущих проблем видно на этапе разработки.

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

I>Этим и обеспечиваются гарантии
Это направлено на обеспечение гарантии, но не обеспечивает ее в полной мере.

S>>Так делается, когда продукт дядин. Будут проблемы — наймем кого надо и он будет делать то, что надо, а не то, что ему интересно.

I>Дядин или нет — дело десятое. Ощущение, что ты на тестирование смотришь как на чтото лишнее
Не знаю, откуда оно у тебя.
I>Так делается, когда цена ошибки высока.
I>Чему равняется цена ошибки? Какого рода данные хранят в вашем файлохранилище?
Любого, мне не докладывают.
I>Вы риски заказчика разделяете или вешаете на него? Пенальти за баг на проде платите?
Заказчика нет. Есть клиенты. Если клиента что-то не устраивает — он волен решать свои проблемы как-то по-другому.

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

I>Лично я внятный контроль качества вижу в серьёзных продуктовых конторах, т.е. "на себя". Энтарпрайзу до таких высот как до небес. В энтерпрайзе можно увидеть проекты вообще без тестирования, абы картинка была красивая. Для серьезной продуктовой конторы это смерть от имиджевых потерь. Как только юзеры догадаются, что контора продает пустышки, на ней сразу ставят жирный чорный крест.

Стопари. Тестирование у нас есть. Ты весь балаган развел лишь на почве того, что нет кадра, который бы 100% времени занимался экспл-чего-там тестированием. Но, как оказалось, приведенное тобой определение контроля качества и не требует такого кадра.

S>>Извини, но по-моему ты пытаешься решать проблемы, которых нет, и которые тебя решать не просили.

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

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

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

Вот буквально сегодня на хабре увидел комментарий (не мой, меня там вообще нет): https://habr.com/ru/post/474518/#comment_20850132

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

Вы в ответ на это можете возразить: «ну так давайте считать наши программы на С такой же чистой последовательностью команд, C — чистый язык!» И вы, самое интересное, будете абсолютно правы! Вы можете считать, что весь ваш сишный код просто живёт в монаде IO. Компилятор её там неявно за вас дописывает.

Какое новое знание, новые гарантии это нам даёт? Никаких. Какой в этом смысл? Никакого.

Смысл появляется тогда, когда у вас существуют функции, которые не живут в IO. Которые гарантированно (компилятором) не могут выдавать команды для работы с файловой системой. Или которые гарантированно (компилятором) не могут менять глобальные переменные. Или даже их читать. Или которые гарантированно (компилятором) не лезут в интернет или в БД.

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

Собственно, ровно то, о чем я тут талдычил. Можно просто выделить чистые функции как отдельную концепцию в языке (см. D, Ada, etc.) и получить ровно тот же эффект, что и странноватый подход хаскеля. Точнее, чтобы полностью смоделировать подход хаскеля (геморрой при написании грязного кода), надо сделать наоборот: все функции по умолчанию чистые, а грязные помечаются флагом наподобие "IO". Различие будет только в том, что нет притворства, что все функции чистые.

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

I>>Это неверная аналогия.
S>Верная.

Факт №1 — долголетие невозможно гарантировать. Следовательно у тебя гарантии есть выдумка.
Факт №2 — правильное питание может гарантировать исключительно отсутствие или своевременное обнаружение определенных проблем, связанных с этим самым питанием.
Пример №1 если ты не употребляешь алкоголь, то у тебя не будет алкогольных заболеваний печени, а печень будет работать лучше.
Пример №2 если ты ешь столько, сколько необходимо, то не будет проблемы лишнего веса. Из этого не значит, что ты проживешь 90 лет. Просто такой фактор, как лишний вес, у тебя играть не будет.

Вобщем, из твоего примера очень похоже, что гарантии в твоем понимании есть нечто, никак не связаное с продуктом, эдакая маркетинговая сказочка

I>>Согласно определению

Контроль качества – деятельность,для гарантированного подтверждения ...

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

Ты сказал, что гарантии это необязательный результат. А между тем в определении ясно, что это основной результат ради которого всё и проводится.
Итого — ты согласен с двумя противоположными по смыслу высказываниями а именно — "обязательно — необязательно"

I>>Итого — цель именно гарантии. Если гарантии необязательны, то и контроль необязателен. В таком случае нечего и парадигму тащить сюда
S>Цель деятельности — гарантии. Но гарантии не следуют из наличия деятельности, т.е. не являются обязательным следствием такой деятельности.

Цель — гарантии, но при этом цель не является обязательной

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

Это значит, что тесты будет выполнять не человек,а компилятор или еще что. Например — проверяешь инваринанты == код тестирует сам себя. Статическая типизация — компилятор протестирует все ли здесь в порядке.
Но это все тестирование отдельных аспектов, а интересует тестирование всей системы в целом, в т.ч. буквально тесты на проде.
Пример "переводим трафик на x% нодов, смотрим метрики, возвращаем как было". Это тоже тестирование и никаким авто-тестами не делается. Например потому, что настандартная ситуация, про которую автотест не знает, может убить всё нахрен, т.к. это прод.

I>>Дядин или нет — дело десятое. Ощущение, что ты на тестирование смотришь как на чтото лишнее
S>Не знаю, откуда оно у тебя.

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

I>>Так делается, когда цена ошибки высока.
I>>Чему равняется цена ошибки? Какого рода данные хранят в вашем файлохранилище?
S>Любого, мне не докладывают.

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

I>>Вы риски заказчика разделяете или вешаете на него? Пенальти за баг на проде платите?
S>Заказчика нет. Есть клиенты. Если клиента что-то не устраивает — он волен решать свои проблемы как-то по-другому.

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

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

У вас нет ключей == у вас нет некоторого ничтожно малого подмножества уязвимостей. А что с остальными уязвимостями?

I>>Лично я внятный контроль качества вижу в серьёзных продуктовых конторах, т.е. "на себя". Энтарпрайзу до таких высот как до небес. В энтерпрайзе можно увидеть проекты вообще без тестирования, абы картинка была красивая. Для серьезной продуктовой конторы это смерть от имиджевых потерь. Как только юзеры догадаются, что контора продает пустышки, на ней сразу ставят жирный чорный крест.

S>Стопари. Тестирование у нас есть. Ты весь балаган развел лишь на почве того, что нет кадра, который бы 100% времени занимался экспл-чего-там тестированием. Но, как оказалось, приведенное тобой определение контроля качества и не требует такого кадра.

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

S>>>Извини, но по-моему ты пытаешься решать проблемы, которых нет, и которые тебя решать не просили.

I>> А я и не решаю. Я рассказываю, что такое ручное тестирование и почему его нельзя заменить авто-тестами. Эти методики решают разные классы задач, которые есть всего лишь слабо пересекающиеся множества.
S>Как мило с твоей стороны. Местами это весьма неслабо пересекающиеся множества.

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

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

ARK>Вот буквально сегодня на хабре увидел комментарий (не мой, меня там вообще нет): https://habr.com/ru/post/474518/#comment_20850132

Цитата замечательная.

ARK>Собственно, ровно то, о чем я тут талдычил. Можно просто выделить чистые функции как отдельную концепцию в языке (см. D, Ada, etc.) и получить ровно тот же эффект, что и странноватый подход хаскеля. Точнее, чтобы полностью смоделировать подход хаскеля (геморрой при написании грязного кода), надо сделать наоборот: все функции по умолчанию чистые, а грязные помечаются флагом наподобие "IO". Различие будет только в том, что нет притворства, что все функции чистые.

Так в цитате написано, что putStr чистая, т.к. возвращает действие, но не выполняет его. В чем же притворство тут?

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

ARK>>Собственно, ровно то, о чем я тут талдычил. Можно просто выделить чистые функции как отдельную концепцию в языке (см. D, Ada, etc.) и получить ровно тот же эффект, что и странноватый подход хаскеля. Точнее, чтобы полностью смоделировать подход хаскеля (геморрой при написании грязного кода), надо сделать наоборот: все функции по умолчанию чистые, а грязные помечаются флагом наподобие "IO". Различие будет только в том, что нет притворства, что все функции чистые.

S>Так в цитате написано, что putStr чистая, т.к. возвращает действие, но не выполняет его. В чем же притворство тут?

Не знаю, есть ли смысл повторять еще раз, но почему бы нет. Итак, ситуация:

1) Есть программа на Haskell, в которой все — все без исключения! — функции являются IO.
2) Есть программа на C (произвольная).

Автор комментария (как и я за неделю до него) утверждает, что идеологически никакой разницы с точки зрения чистоты между пунктами 1 и 2 — нет. Можно с одинаковым успехом утверждать, что обе программы либо чисты (т.к. выполняются внешним вычислителем, а сами якобы ничего не делают), либо грязны (т.к. каждая функция в обеих программах ссылается на какую-то другую грязную функцию).

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

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

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

I> Факт №1 — долголетие невозможно гарантировать. Следовательно у тебя гарантии есть выдумка.
С пониманием гарантий долголетия почему-то у тебя нет проблем.

I>>>Согласно определению
I>

I>Контроль качества – деятельность,для гарантированного подтверждения ...

Ты приводил другое определение, вернись, пожалуйста к нему.

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

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

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

S>>Цель деятельности — гарантии. Но гарантии не следуют из наличия деятельности, т.е. не являются обязательным следствием такой деятельности.

I>Цель — гарантии, но при этом цель не является обязательной
Передергиваешь. Цель не является обязательным следствием действий, направленных на достижение этой цели.

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

I>Это значит, что тесты будет выполнять не человек,а компилятор или еще что. Например — проверяешь инваринанты == код тестирует сам себя. Статическая типизация — компилятор протестирует все ли здесь в порядке.
I>Но это все тестирование отдельных аспектов, а интересует тестирование всей системы в целом, в т.ч. буквально тесты на проде.
I>Пример "переводим трафик на x% нодов, смотрим метрики, возвращаем как было". Это тоже тестирование и никаким авто-тестами не делается. Например потому, что настандартная ситуация, про которую автотест не знает, может убить всё нахрен, т.к. это прод.
И почему это никакими авто-тестами не делается? Что тут такого, чего не сможет выполнить и оценить автотест?

I>А это следует из твоего заявления, что де тестирование нужно только когда на дядю работаешь.
Не следует. Мое заявление было не о тестировании как таковом. Оно было ответом на твой тезис о том, как оно обычно делается.

I>>>Чему равняется цена ошибки? Какого рода данные хранят в вашем файлохранилище?
S>>Любого, мне не докладывают.

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

I>>>Вы риски заказчика разделяете или вешаете на него? Пенальти за баг на проде платите?
S>>Заказчика нет. Есть клиенты. Если клиента что-то не устраивает — он волен решать свои проблемы как-то по-другому.

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

S>>Не переживай. У нас нет ключей от файлов заказчика.

I>У вас нет ключей == у вас нет некоторого ничтожно малого подмножества уязвимостей. А что с остальными уязвимостями?
Почему-то у меня возникает впечатление, что я отчитываюсь. А вроде как не обязан.
У нас есть очень большие клиенты. Со своими очень серьезными службами безопасности. Цепочки согласования у них довольно длинные, как по кол-ву людей, принимающих решение, так и по времени. Их требования нам удается выполнять. Или, лучше сказать, находить консенсус.

S>>Стопари. Тестирование у нас есть. Ты весь балаган развел лишь на почве того, что нет кадра, который бы 100% времени занимался экспл-чего-там тестированием. Но, как оказалось, приведенное тобой определение контроля качества и не требует такого кадра.

I>Требует! Нужен поиск новых, неожиданных проблем, а не просто многократное повторение, что регрессии не обнаружено.
Определение не требует. Перечитай его. "Любая систематическая деятельность, направленная".

S>>Как мило с твоей стороны. Местами это весьма неслабо пересекающиеся множества.

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

Ты нестрог к формулировкам. Ты утверждаешь вещи, которые расходятся со здравым смыслом. Например, из твоего требования наличия кадра, 100% времени занимающегося поиском, следует что один лишь разработчик не может обеспечить контроль качества, т.к. его деятельность не может на 100% состоять из поиска новых багов. Вместо этого определения контроля качества, которое ты приводил, не требует даже 1%. Ему достаточно просто систематической деятельности.

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

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

S>>Так в цитате написано, что putStr чистая, т.к. возвращает действие, но не выполняет его. В чем же притворство тут?

ARK>Не знаю, есть ли смысл повторять еще раз, но почему бы нет. Итак, ситуация:

ARK>1) Есть программа на Haskell, в которой все — все без исключения! — функции являются IO.
ARK>2) Есть программа на C (произвольная).

Да, я помню эту ситуацию.

ARK>Автор комментария (как и я за неделю до него) утверждает, что идеологически никакой разницы с точки зрения чистоты между пунктами 1 и 2 — нет. Можно с одинаковым успехом утверждать, что обе программы либо чисты (т.к. выполняются внешним вычислителем, а сами якобы ничего не делают), либо грязны (т.к. каждая функция в обеих программах ссылается на какую-то другую грязную функцию).

У меня есть сомнения, что автор комментария писал именно о ситуации, когда все функции программы на хаскеле есть IO.

ARK>Слово "притворство" относится скорее к используемой терминологии создателей хаскеля, которая именует "чистыми" те сущности, которые в других языках принято считать грязными.
Нет специальной терминологии создателей Хаскеля. Есть определение чистой функции. Все функции хаскеля, которые не используют бэкдоры, удовлетворяют этому определению без каких-либо специальных терминологий и притворства.

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

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

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

S>У меня есть сомнения, что автор комментария писал именно о ситуации, когда все функции программы на хаскеле есть IO.

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

ARK>>Слово "притворство" относится скорее к используемой терминологии создателей хаскеля, которая именует "чистыми" те сущности, которые в других языках принято считать грязными.
S>Нет специальной терминологии создателей Хаскеля. Есть определение чистой функции. Все функции хаскеля, которые не используют бэкдоры, удовлетворяют этому определению без каких-либо специальных терминологий и притворства.

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

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

Так прикол в том, что оно формально всему удовлетворяет.

S>Вот это "назову я программу на C++ чистой" — и есть притворство.

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

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

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

S>>У меня есть сомнения, что автор комментария писал именно о ситуации, когда все функции программы на хаскеле есть IO.

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

Они могут быть равны по результату, но не по чистоте.

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

ARK>В конечном итоге все сводится к трактовке отдельных слов в "общепринятых" определениях. Причем таких будто бы незначительных слов, которые кажутся сугубо второстепенными, но на самом деле дьявол именно в них. "Чистая функция — это функция, не выполняющая ввод-вывод." ОК, любая программа на С не выполняет ввод-вывод, она просто лежит на диске, а выполняет ввод-вывод внешний вычислитель (процессор).
И даже на этом уровне найдутся отличия. Выполняя функцию main на C с printf-ом, внешний вычислитель пачкает мир. Выполняя функцию main на Haskell с функцией putStr, внешний вычислитель не пачкает мир.

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

ARK>Так прикол в том, что оно формально всему удовлетворяет.
printf? С какого перепугу?

S>>Вот это "назову я программу на C++ чистой" — и есть притворство.

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

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

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

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

ARK>>ОК, любая программа на С не выполняет ввод-вывод, она просто лежит на диске, а выполняет ввод-вывод внешний вычислитель (процессор).
S>И даже на этом уровне найдутся отличия. Выполняя функцию main на C с printf-ом, внешний вычислитель пачкает мир. Выполняя функцию main на Haskell с функцией putStr, внешний вычислитель не пачкает мир.

А откуда ясно, что в С пачкает, а в хаскеле нет? Это где-то написано или является следствием чего-то?

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

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

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

Я вижу так:

Говорят, что эта функция всё равно «чистая», так как она сама по себе не проводит никаких операций с внешним миром, а лишь описывает последовательность команд, которую нужно совершить

Перевод: "Хаскель называет функцию, содержащую IO-вызовы, чистой".

Вы в ответ на это можете возразить: «ну так давайте считать наши программы на С такой же чистой последовательностью команд, C — чистый язык!» И вы, самое интересное, будете абсолютно правы!

Перевод: "Так что, с такой трактовкой чистоты IO-функций любую функцию на С тоже можно назвать чистой? Да, можно".

Какое новое знание, новые гарантии это нам даёт? Никаких. Какой в этом смысл? Никакого.

Перевод: "Абсурдная трактовка чистоты IO-функций? Да, абсурдная"

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

S>А вот потом, когда программа отработала, мы получаем готовый батч, который скармливаем в SQL Server, и уже он внезапно изменяет состояние базы.
S>Ясно, что это гораздо выгоднее, чем в каждом месте, где мы хотели сделать return from g in goods select g.Name, g.Price where g.VendorID = vendorId, сразу писать var r = db.ExecuteQuery("select g.Name, g.Price from goods g where g.VendorID = @vendorId", vendorId).
S>Во-первых, у нас могут быть "тупиковые" ветки, которые будут выброшены в процессе построения батча на основе условий, которые обнаружатся "в будущем".

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

S>Во-вторых, удерживать транзакцию открытой — плохо; поэтому перемежать обращения к базе с выполнением дорогостоящей client-side логики — дорого.

Но придётся, если нам нужна изоляция уровня REPEATABLE READ. А если мы удерживаем такую транзакцию, то не имеет значения прочитали ли мы сначала, а потом выполнили всё одним махом, или же выполняли в процессе.

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

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

S>>Они могут быть равны по результату, но не по чистоте.

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

ARK>>>ОК, любая программа на С не выполняет ввод-вывод, она просто лежит на диске, а выполняет ввод-вывод внешний вычислитель (процессор).
S>>И даже на этом уровне найдутся отличия. Выполняя функцию main на C с printf-ом, внешний вычислитель пачкает мир. Выполняя функцию main на Haskell с функцией putStr, внешний вычислитель не пачкает мир.

ARK>А откуда ясно, что в С пачкает, а в хаскеле нет? Это где-то написано или является следствием чего-то?
Ну как же? Где-нибудь да написано. И еще в этом можно убедиться с помощью отладчика. Да, в Хаскеле его как бы нет (не уверен). Но мы вполне можем написать аналог на C# и убедиться, что выполнение аналога putStr не приводит к выводу на консоль.

ARK>>>Так прикол в том, что оно формально всему удовлетворяет.
S>>printf? С какого перепугу?

ARK>А почему нет? Она не выполняет ввода-вывода, все в строгом соответствии с формальным определением. Ввод-вывод выполняет процессор, а printf — это просто кусок кода, содержащий команды для процессора.
Такая трактовка определения приводит к его бессмысленности. Все, что можно напечатать на бумаге — чисто по определению, т.к. бумага не умеет выполнять код.

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

ARK>Я вижу так:

ARK>

ARK>Говорят, что эта функция всё равно «чистая», так как она сама по себе не проводит никаких операций с внешним миром, а лишь описывает последовательность команд, которую нужно совершить

ARK>Перевод: "Хаскель называет функцию, содержащую IO-вызовы, чистой".
Причем тут хаскель? Детерминированная функция, создающая функцию и не делающая ничего кроме функции — чиста. Это справедливо не только лишь для хасклея.

ARK>

ARK>Вы в ответ на это можете возразить: «ну так давайте считать наши программы на С такой же чистой последовательностью команд, C — чистый язык!» И вы, самое интересное, будете абсолютно правы!

ARK>Перевод: "Так что, с такой трактовкой чистоты IO-функций любую функцию на С тоже можно назвать чистой? Да, можно".
"Да, можно" = не можем запретить считать. Это не есть согласие с чистотой любой функции на C.

ARK>

ARK>Какое новое знание, новые гарантии это нам даёт? Никаких. Какой в этом смысл? Никакого.

ARK>Перевод: "Абсурдная трактовка чистоты IO-функций? Да, абсурдная"
Да, такая трактовка чистоты, при которой любая функция C чиста — абсурдна.

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

I>> Факт №1 — долголетие невозможно гарантировать. Следовательно у тебя гарантии есть выдумка.
S>С пониманием гарантий долголетия почему-то у тебя нет проблем.

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


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

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

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

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

I>>Цель — гарантии, но при этом цель не является обязательной
S>Передергиваешь. Цель не является обязательным следствием действий, направленных на достижение этой цели.

Цель это обязательный результат, если все прошло успешно. Если неуспешно — цель недостижима. И это тоже результат, те же самые гарантии.

I>>Но это все тестирование отдельных аспектов, а интересует тестирование всей системы в целом, в т.ч. буквально тесты на проде.
I>>Пример "переводим трафик на x% нодов, смотрим метрики, возвращаем как было". Это тоже тестирование и никаким авто-тестами не делается. Например потому, что настандартная ситуация, про которую автотест не знает, может убить всё нахрен, т.к. это прод.
S>И почему это никакими авто-тестами не делается? Что тут такого, чего не сможет выполнить и оценить автотест?

А я выделил ответ на твой вопрос. Нет способа заскриптовать "а проверь, есть ли нечто новое, неизвестное, подозрительное, что может повалить весь прод"

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



S>У нас есть очень большие клиенты. Со своими очень серьезными службами безопасности. Цепочки согласования у них довольно длинные, как по кол-ву людей, принимающих решение, так и по времени. Их требования нам удается выполнять. Или, лучше сказать, находить консенсус.

Это хороший знак, что у вас есть такие большие клиенты, значит какие то гарантии вы чем то обеспечиваете

I>>Требует! Нужен поиск новых, неожиданных проблем, а не просто многократное повторение, что регрессии не обнаружено.
S>Определение не требует. Перечитай его. "Любая систематическая деятельность, направленная".

Требует. "Гарантированое подтверждение" включает в себя много всего

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

S>Ты нестрог к формулировкам. Ты утверждаешь вещи, которые расходятся со здравым смыслом. Например, из твоего требования наличия кадра, 100% времени занимающегося поиском, следует что один лишь разработчик не может обеспечить контроль качества, т.к. его деятельность не может на 100% состоять из поиска новых багов.

Разработчик совмещая роль тестировщика находится в постоянном конфликте интересов. Цели противоположные — вместо "быстрее написать" появляется "тщательнее протестировать"
В простых случаях совмещение работает. Но только в простых. Кроме того, в общем случае до кучи к конфликту интересов это совершенно разные знания, умения, подходы и методологии.

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

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

В конечном счете все сводится как раз к документации и толкованию исходного кода.

ARK>>А откуда ясно, что в С пачкает, а в хаскеле нет? Это где-то написано или является следствием чего-то?
S>Ну как же? Где-нибудь да написано.

А вдруг нет? Почему ты уверен, что написано?

S>И еще в этом можно убедиться с помощью отладчика.

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

S>Но мы вполне можем написать аналог на C# и убедиться, что выполнение аналога putStr не приводит к выводу на консоль.

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

ARK>>>>Так прикол в том, что оно формально всему удовлетворяет.
S>>>printf? С какого перепугу?
ARK>>А почему нет? Она не выполняет ввода-вывода, все в строгом соответствии с формальным определением. Ввод-вывод выполняет процессор, а printf — это просто кусок кода, содержащий команды для процессора.
S>Такая трактовка определения приводит к его бессмысленности. Все, что можно напечатать на бумаге — чисто по определению, т.к. бумага не умеет выполнять код.

Если определение позволяет трактовать себя разными способами — значит, оно не является формальным. Каким образом, по твоему мнению, необходимо дополнить определение, чтобы исключить "такую трактовку"?

ARK>>Перевод: "Хаскель называет функцию, содержащую IO-вызовы, чистой".
S>Причем тут хаскель? Детерминированная функция, создающая функцию и не делающая ничего кроме функции — чиста. Это справедливо не только лишь для хасклея.

ОК.

ARK>>Перевод: "Так что, с такой трактовкой чистоты IO-функций любую функцию на С тоже можно назвать чистой? Да, можно".
S>"Да, можно" = не можем запретить считать. Это не есть согласие с чистотой любой функции на C.

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

Ты отвечаешь примерно так: "Ты можешь считать как угодно, но я не согласен, потому что потому. Твоя трактовка неправильная, потому что из нее следует, что язык С — чистый".

Был бы очень признателен услышать такое определение чистоты, которое исключает несколько трактовок.

ARK>>Перевод: "Абсурдная трактовка чистоты IO-функций? Да, абсурдная"
S>Да, такая трактовка чистоты, при которой любая функция C чиста — абсурдна.

А почему любая функция С не чиста? Это "общеизвестно"?

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

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

S>>Я не поддержал заявления типа "а давайте вот это будет чистым по документации".

ARK>В конечном счете все сводится как раз к документации и толкованию исходного кода.
Толкуют сны. Код — выполняют.

ARK>>>А откуда ясно, что в С пачкает, а в хаскеле нет? Это где-то написано или является следствием чего-то?
S>>Ну как же? Где-нибудь да написано.

ARK>А вдруг нет? Почему ты уверен, что написано?
Уверен лишь в том, что нет смысла искать, т.к. ты захочешь трактовать по-своему. Как с цитатой с хабра.

S>>И еще в этом можно убедиться с помощью отладчика.

ARK>Отладчик — это сторонняя программа, она не может определять семантику языка.
Хорошо, прикрути вывод в файл.

S>>Но мы вполне можем написать аналог на C# и убедиться, что выполнение аналога putStr не приводит к выводу на консоль.

ARK>Мы можем написать такой же аналог для С и убедиться, что выполнение аналога printf не приводит к выводу на консоль.
И в чем же это будет аналог printf, если выполнение printf приводит к выводу на консоль?

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

ARK>Если определение позволяет трактовать себя разными способами — значит, оно не является формальным. Каким образом, по твоему мнению, необходимо дополнить определение, чтобы исключить "такую трактовку"?
Я ее исключаю без дополнений.

ARK>>>Перевод: "Так что, с такой трактовкой чистоты IO-функций любую функцию на С тоже можно назвать чистой? Да, можно".
S>>"Да, можно" = не можем запретить считать. Это не есть согласие с чистотой любой функции на C.

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

ARK>Ты отвечаешь примерно так: "Ты можешь считать как угодно, но я не согласен, потому что потому. Твоя трактовка неправильная, потому что из нее следует, что язык С — чистый".

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

ARK>Был бы очень признателен услышать такое определение чистоты, которое исключает несколько трактовок.
То, которое я использую, исключает. Но у тебя здесь другое мнение.

ARK>>>Перевод: "Абсурдная трактовка чистоты IO-функций? Да, абсурдная"
S>>Да, такая трактовка чистоты, при которой любая функция C чиста — абсурдна.

ARK>А почему любая функция С не чиста? Это "общеизвестно"?
Почему вдруг любая функция С не чиста? Разве я делал такое утверждение или это следует из моих утверждений?

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

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

I>>> Факт №1 — долголетие невозможно гарантировать. Следовательно у тебя гарантии есть выдумка.
S>>С пониманием гарантий долголетия почему-то у тебя нет проблем.

I>Гарантии качества совсем не такие. Никто не может гарантировать, что багов не будет, или что все баги будут найдены.
I>Гарантии качества совсем про другое.

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

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

В таком контексте восприятия слова "гарантии" мне не совсем ясно, как наличие кадра, занимающегося 100% поиском багов, влияет на возможность раздавать обещания компенсации? Контроль качества в виде систематической деятельности вообще напрямую с такими обещаниями не связан. Это ясно из твоего определения.

I>>>Цель — гарантии, но при этом цель не является обязательной
S>>Передергиваешь. Цель не является обязательным следствием действий, направленных на достижение этой цели.

I>Цель это обязательный результат, если все прошло успешно. Если неуспешно — цель недостижима. И это тоже результат, те же самые гарантии.
Я покупаю газпром, что бы разбогатеть завтра на 100 рублей. Т.е. завтра мы узнаем, была ли цель обязательным результатом этой покупки, или недостижимым? Но если я завтра, разбогатев на 100 рублей, захочу еще раз купить газпром. То послезавтра эта же цель будет недостижимой, при том, что сегодня она была обязательным результатом.... Прям, кот Шредингера на ровном месте.

I>>>Но это все тестирование отдельных аспектов, а интересует тестирование всей системы в целом, в т.ч. буквально тесты на проде.
I>>>Пример "переводим трафик на x% нодов, смотрим метрики, возвращаем как было". Это тоже тестирование и никаким авто-тестами не делается. Например потому, что настандартная ситуация, про которую автотест не знает, может убить всё нахрен, т.к. это прод.
S>>И почему это никакими авто-тестами не делается? Что тут такого, чего не сможет выполнить и оценить автотест?

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

I>>>Требует! Нужен поиск новых, неожиданных проблем, а не просто многократное повторение, что регрессии не обнаружено.
S>>Определение не требует. Перечитай его. "Любая систематическая деятельность, направленная".

I>Требует. "Гарантированое подтверждение" включает в себя много всего
Гарантированное подтверждение соответствия требованиям — это цель. И кстати, подтверждение соответствию требований не равно обещанию компенсировать.

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

S>>Ты нестрог к формулировкам. Ты утверждаешь вещи, которые расходятся со здравым смыслом. Например, из твоего требования наличия кадра, 100% времени занимающегося поиском, следует что один лишь разработчик не может обеспечить контроль качества, т.к. его деятельность не может на 100% состоять из поиска новых багов.

I>Разработчик совмещая роль тестировщика находится в постоянном конфликте интересов. Цели противоположные — вместо "быстрее написать" появляется "тщательнее протестировать"
I>В простых случаях совмещение работает. Но только в простых. Кроме того, в общем случае до кучи к конфликту интересов это совершенно разные знания, умения, подходы и методологии.

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

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

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

Если определение размытое, то захочу, конечно. Ты считаешь это некорректным?

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

Тут не понял.

S>>>Но мы вполне можем написать аналог на C# и убедиться, что выполнение аналога putStr не приводит к выводу на консоль.
ARK>>Мы можем написать такой же аналог для С и убедиться, что выполнение аналога printf не приводит к выводу на консоль.
S>И в чем же это будет аналог printf, если выполнение printf приводит к выводу на консоль?

Это написано в описании стандартной библиотеки С? А у хаскеля в документации написано, что IO-функция не приводит к выводу на консоль, а просто создает Action? А если бы было написано все наоборот — ну, просто предположим такое, абстрагируемся от текущего положения дел — то ты бы считал хаскельную функцию грязной, а сишную чистой?

ARK>>Если определение позволяет трактовать себя разными способами — значит, оно не является формальным. Каким образом, по твоему мнению, необходимо дополнить определение, чтобы исключить "такую трактовку"?
S>Я ее исключаю без дополнений.

Почему? Чем она плоха?

ARK>>Ты отвечаешь примерно так: "Ты можешь считать как угодно, но я не согласен, потому что потому. Твоя трактовка неправильная, потому что из нее следует, что язык С — чистый".
S>Ты разве не понимаешь, что твое утверждение истинно лишь в пределах твоей трактовки и не имеет отношения к другим трактовкам? Мне не интересно обсуждать твою трактовку. В рамках твоей трактовки я не делаю никаких утверждений, которые собирался бы отстаивать.

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

Я не знаю, как доступнее объяснить. Утрируя, диалог выглядит примерно так:

— Что такое яблоко?
— Это зеленый шарик.
— Но дальтоники видят розовый вместо зеленого, получается, что для них розовый пластиковый шарик и яблоко — это одно и то же?
— Нет.
— Почему нет? Твое определение яблока полностью подходит для розового пластикового шара, если человек дальтоник.
— Яблоко — не пластиковый шарик, это твоя трактовка.
— Тогда дополни свое определение, чтобы дальтоник смог отличить зеленое яблоко от розового пластикового шарика.
— Я отвергаю твою трактовку без каких-либо дополнений.
— А если посветить на яблоко светом другого спектра, то оно тоже зеленым выглядеть не будет, даже для обычного человека.
— Другие спектры я обсуждать не готов, даже пытаться не буду.

ARK>>А почему любая функция С не чиста? Это "общеизвестно"?
S>Почему вдруг любая функция С не чиста? Разве я делал такое утверждение или это следует из моих утверждений?

Уже спрашивал, спрошу еще раз: как отличить чистую функцию С от нечистой? Как ты поймешь, делает она ввод-вывод или нет? Отладчик, на всякий случай, не задает семантику языка. Семантику языка и стандартных функций задает спецификация языка и описание стандартной библиотеки (документация).

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

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

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


S>Но ведь если появились условия "из будущего", значит функция уже стала грязной, разве не так? Ведь чтобы получить внешние данные нужно провзаимодействовать с миром, а значит ваш пример уже невалиден.
Не обязательно. Это "будущее" к моменту исполнения нашей функции, возможно, уже наступило. Классика жанра — фильтрация с необязательными условиями. Можно внести необязательность в сам предикат:

where orderDate >= @startDate or  @startDate is null

а можно вычислить её в процессе построения предиката:

if (startDate.HasValue)
  q = q.Where(_ => _.orderDate >= startDate);

S>>Во-вторых, удерживать транзакцию открытой — плохо; поэтому перемежать обращения к базе с выполнением дорогостоящей client-side логики — дорого.
S>Но придётся, если нам нужна изоляция уровня REPEATABLE READ. А если мы удерживаем такую транзакцию, то не имеет значения прочитали ли мы сначала, а потом выполнили всё одним махом, или же выполняли в процессе.
Конечно же это имеет большое значение. Обычный императивный код крайне трудно переупорядочивать — современные компиляторы много времени тратят на то, чтобы восстановить "смысл" полученных инструкций, и переставить их так, чтобы сохраняя семантику, выполнить оптимизацию. Но их способности весьма ограничены, т.к. иначе мы получаем экспоненциальные времена компиляции.
Наличие явных зависимостей помогает устранить человеческий фактор.
Возвращаясь к аналогии с SQL, мы можем попробовать сделать резервирование товара через подъём каждой строки заказа в апп-сервер, затем для каждой из них мы находим партии-кандидаты отдельным запросом; затем в конце списка строим пересечение складов с партиями-кандидатами так, чтобы постараться скомплектовать всё из единого склада.
Типичный roundtrip между апп-сервером и СУБД — около 10 миллисекунд. Для заказа из 100 строк мы тратим целую секунду просто на общение между слоями; реализация той же логики в виде батча позволяет нам эту секунду сэкономить. С учётом характеристик современных SSD, мы получаем время удержания транзакции либо 200мс, либо 1200мс. Это совсем не одно и то же — несмотря на то, что 1000мс из них СУБД простаивает, параллельные транзакции могут налететь на выданные нам блокировки. Тогда 200мс "активной работы" СУБД превращаются в 1200мс "ожидания на блокировках". Итого у нас не просто throughput падает вшестеро, но и response times вырастают в 10 раз.
Просто из-за неудачного выбора порядка операций.