Ну какая же ошибка, например, в передаче параметра по ссылке или в мутабельности, или в использовании глобальных переменных? А ведь речь и о них в немалой степени тоже, потому что они делают код менее очевидным.
Суть в том, что на некоторых языках бардак писать проще, чем на других, а это непосредственно и приводит к разнице в процентном соотношении этого бардака.
В статье тоже описаны способы решения, просто другие.
В Haskell, например, благодаря чистоте, описанные примеры почти нереальны и без использования линтеров и тестов. Но главное не это, а то, что, читая чужой код, можно полагаться на эту самую чистоту, что делает анализ чужого кода более простым.
Чем-то напомнило героин, в краткосрочной приносит наибольшее число игроков, а в итоге о нём дурно отзываются даже те, кто его и не пробовал.
Я, разумеется, иронизирую, тем более, конкретно по теме таких игр сказать ничего не могу.
Представьте, что у вас есть две одинаковые книги, но с одним различием: в некоем месте в одной книге написано «Василий», а в другой — «Пётр». Теперь вы оцифровываете первую книгу и получаете цифровую версию, в которой 10 рандомных букв оказались испорчены (заменены на другие). Какова вероятность, что тот, что прочтёт цифровую версию ошибётся, какая из книг была оцифрована?
Мне больше нравится в этом плане агда. Там можно сделать то же, но не используя метаязык, который выглядит сильно иначе, а используя обычную агду. А HList напоминает шаблонное метапрограммирование на си++
Так и Хаскель не запрещает, только надо использовать newtype, для которого и определить функтор иначе. Возможно, было бы удобнее, если б инстансы были именованные, и можно было бы их не импортировать, а определять нужные себе в данный момент, хоть бы и даже у функции в where.
Ну, несколько разные, но, на мой взгляд, не абсолютно. А ответ «проверка отсутствия ошибок» вы бы сочли за удовлетворительный? И как проверить (в рамках тестирования, ибо можно доказать формально, но это уже не тестирование), кроме как поиском тех самых ошибок?
Возможно, что-то вроде: «потому что без тестирования невозможно выявить истинное состояние производимого продукта, и насколько он соответствует ожиданиям потребителя».
По-моему, это не ответ на вопрос. Мало ли что без чего невозможно, но выбирает человек что-то одно, почему именно тестирование-то?
Ошибка – несоответствие производимого продукта требованиям, прямым или косвенным.
Ну так с учётом этого, «поиск ошибок» раскрывается в «поиск несоответствия производимого продукта требованиям, прямым или косвенным».
Чем это отличается от «комплекс мероприятий, направленный на проведение проверок на соответствие производимого продукта требованиям, к нему предъявляемым (прямым и косвенным).»?
но с одинаковой вероятностью ли?
В Haskell, например, благодаря чистоте, описанные примеры почти нереальны и без использования линтеров и тестов. Но главное не это, а то, что, читая чужой код, можно полагаться на эту самую чистоту, что делает анализ чужого кода более простым.
Я, разумеется, иронизирую, тем более, конкретно по теме таких игр сказать ничего не могу.
Это действительно так? Можете уточнить, где об этом написано?
Это не совсем так
Просто это всё же обычный список со всеми вытекающими, но юникод в нём помещается.
По-моему, это не ответ на вопрос. Мало ли что без чего невозможно, но выбирает человек что-то одно, почему именно тестирование-то?
Ну так с учётом этого, «поиск ошибок» раскрывается в «поиск несоответствия производимого продукта требованиям, прямым или косвенным».
Чем это отличается от «комплекс мероприятий, направленный на проведение проверок на соответствие производимого продукта требованиям, к нему предъявляемым (прямым и косвенным).»?