Степпер для SBCL - помогайте

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

Почему-то вы совершенно исключаете возможность «поправил - компилятор проверил, типы в порядке — а программа вместо полезных данных выдаёт ерунду».

Значит, ваши типы недостаточно типастые! У меня так было. Навернул еще типов сверху, и всё стало хорошо.

Это потому что на боку твоего типа написано "Муляж". А на боку моего типа написано "Desert Eagle 50 калибра" (c)

Можно ли это считать признанием лиспера, что одна из фич лиспа провоцирует порочный подход к разработке?

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

К тому же «порочный подход» — понятие субъективное. Вот мои соображения на эту тему: Анализ пользователей Common Lisp и Racket .

Всё это перекликается с «собор против базара», последней модой на идеи «чтобы улучшить качество программ надо выкинуть из языка ООП и исключения». Или выкинуть goto и define. Или выкинуть изменение переменных.

Видел на хабре утверждения, что 1С взлетел именно потому, что в нём нет ООП. В смысле, есть встроенные классы Справочник, Документ, ... и от них можно отнаследоваться. Но отнаследоваться от своего класса нельзя. Переопределить метод предка нельзя. И благодаря этому никаких проблем с хрупким базовым классом, порядком наследования и прочим.

выкинул джаваскрипт и не заменил его тайпскриптом

Думал над этим , рассматривал тайпскрипт и его аналог, не помню уже как назывался и ecma6. И то и друго и третье оставляет яваскрипт яваскриптом по большому счёту. Решил освоить хаскель, благо есть ghcjs

Вообще хаскеляторы, смотрю, то пхп зарабатывают, то 1С.

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

Можно ли это считать признанием лиспера, что одна из фич лиспа провоцирует порочный подход к разработке?

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

Людей, которые пишут на лиспе прямо сейчас, думаю, на LOR немного, не говоря о том, чтобы писать за деньги. Поэтому ты вполне сгодишься за лиспера.

К тому же «порочный подход» — понятие субъективное. Вот мои соображения на эту тему: Анализ пользователей Common Lisp и Racket .

Ого, сколько там «еды». Напомнило, лет десять назад я такие треды считал чуть ли не лучшим чтивом на свете. Было дело, да.

Так может, надо вместо signed int указать в сигнатуре unsigned int?)

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

Пусть мы имеем функцию переводящую температуру (в Кельвинах) в давление (в Паскалях). Вообще не проблема сказать, что на входе должно быть положительное число. Но что если наша модель корректна лишь в некотором диапазоне температур? Тогда возможно две возможности:

• Наша система типов так не умеет. Ставим проверки времени исполнения и имеем де-факто динамически типизированную программу в котрой статические типы — не более чем визуальный мусор.
• У нас продвинутая система типов. Тогда (по результатам наблюдения многочисленных обсуждений на лоре и stackoverflow) программирования из рассуждений в терминах предметной области превращается в «ехала монада через монаду, ой ковариантность нарушается, ничего зигохистоморфным монадным трансформером поправим». Хотя изначально предполагалось, что типы должны помогать, а не служить источником проблем, с которыми нужно бороться.

Кажется какой-то матаппарат её потеряет нынешний смысл, типа отрицательной температуры под корнем где-то окажется, и только лишь.

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

Добавь третье: у нас есть метапрограммирование и мы генерируем бойлерплейт для проверок времени компиляции, которые в исходнике будут не видны.

То есть он конкурентоспособен с языками времён ANSI CL, но с современными не хватает базовой инфраструктуры.

Кложа интерперабельна с явой, а это огромный красивый мир очень хорошо документированных библиотек на все случаи жизни. Работает на jvm. Евангилисты заявляют о том что размер кода меьше на порядок чем на яве (а то и на два). Уж в несколько раз точно. Но пользуются ценители. Может конечно кложа молодая ещё.

На кложу сильно фапали при появлении, но потом ее ждала судьба всех JVM-языков, как и скалы, кстати.

P.S. Скобки не проблема.

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

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

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

В рамках этой модели. А модели эти меняют, дополняют и уточняют всю историю человечества.

Почему-то вы совершенно исключаете возможность «поправил - компилятор проверил, типы в порядке — а программа вместо полезных данных выдаёт ерунду».

Ну честно говоря да, исключаю, наверное на 99%. Фокус в том что вы пишете находясь в сознании (или нет?). Типы лишь помогают быстро заметить огрехи (которых полно во время разработки), ну или в случае хаскеля, «заставляют» использовать хорошие примитивы (иначе замучаешься исправлять огрехи). Если вы действительно не в курсе что пишете в некотором определённом смысле, то ни типы ни нетипы ничто не поможет. Программа не будет работать в любом случае. Смысл этот случай обсуждать, он ведь от языка и типов не зависит.

Решил освоить хаскель, благо есть ghcjs

PureScript попробуй.

Так может, надо вместо signed int указать в сигнатуре unsigned int?)

Простейшие случаи вроде (число vs положительное число) они действительно ловят.

В тех языках которые я видел, они ничего не ловят.

Ура! Хоть кто-то понял суть моей критики типизированных языков.

К слову, во времена Си, Фортрана и Алгола типы использовались по своему прямому назначению: ускорить работу скомпилированной программы. Если указать, что значение переменной всегда влезет в два байта, то компилятор может под неё жёстко определить место на стеке или в регистре.

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

Или выкинуть goto и define

не могу не заметить, что выкидиывание готу массово улучшило код. Правда потом вышла амнистия на готу, ибо в си без готу сложновато ошибки обрабатывать. Но тем не менее, читать (и поддерживать) сишный код без готу заметно легче, по моему.

Видел на хабре утверждения, что 1С взлетел именно потому, что в нём нет ООП. В смысле, есть встроенные классы Справочник, Документ, ... и от них можно отнаследоваться. Но отнаследоваться от своего класса нельзя. Переопределить метод предка нельзя. И благодаря этому никаких проблем с хрупким базовым классом, порядком наследования и прочим.

Хочу отметить что по-моему правдоподобно. ООП действительно очень сложно, я программирую уже лет 12 наверное. читал банду четырёх, фаулера, ещё кого то.

Весь SOLID сводится к искусству: либо ты отхерачил на этом с десяток другой лет и для определённого круга вариантов знаешь что «вот так лучше не делать, а вот так заработает». Либо нет. Солид это совсем не правила для монады, аппликатива и моноида: сложное, практически неформализуемое знание. Поэтому в реальности как только начинаешь наследовать, сразу жди проблем. Я не считаю себя ооп профессионалом и стараюсь избегать наследования заменяя его делигированием или ещё чем. Лет 6 назад я считал этот совет наивным.

Поэтому подобный запрет на наследование - только от «надёжных» базовых классов на мой взгляд действительно мог дать языку преимущество в производительности труда.

Значит, ваши типы недостаточно типастые! У меня так было. Навернул еще типов сверху, и всё стало хорошо.

Если у вас есть проблема и вы используете для её решения регулярные выражения, то теперь у вас две проблемы. Почему-то вспомнилось это высказывание.

ну, скажем, языки jvm живы вполне. и на кложе и на скале и на котлине можно найти работу. но да, яву они не заменили.

Типы лишь помогают быстро заметить огрехи (которых полно во время разработки), ну или в случае хаскеля, «заставляют» использовать хорошие примитивы (иначе замучаешься исправлять огрехи).

Я перестал верить в типы, когда при запуске leksah увидел ошибки Gtk-Critical: gtk_notebook_get_tab_label: assertion 'list != NULL' failed. И когда понял, что я даже не могу найти, куда поставить вывод отладочной информации. И судя по https://github.com/leksah/leksah/issues/455 причину подобных ошибок сами разработчики тоже не могут устранить.

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

Может.

Это где такое?

Так может, надо вместо signed int указать в сигнатуре unsigned int?)

На самом деле нужно указать отдельный тип TempС. Проблема которую действительно решают типы - это проблема ошибок при стыковке сущностей. Если функция принимает TempС, то мы не может туда передать просто число, нужно его явно скастовать в TempС. И вот при этом кастовании (рантайм операции) уже можно проверять всё что душе угодно, а саму операцию покрыть тестами.

Наша система типов так не умеет. Ставим проверки времени исполнения и имеем де-факто динамически типизированную программу в котрой статические типы — не более чем визуальный мусор.

Наша система типов всегда чего то да не умеет. это ведь не отменяет того что она умеет. Даже примитивная сишная система типов вполне себе отлавливает простые ошибки.

У нас продвинутая система типов. Тогда (по результатам наблюдения многочисленных обсуждений на лоре и stackoverflow) программирования из рассуждений в терминах предметной области превращается в «ехала монада через монаду, ой ковариантность нарушается, ничего зигохистоморфным монадным трансформером поправим». Хотя изначально предполагалось, что типы должны помогать, а не служить источником проблем, с которыми нужно бороться.

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

Не так ли?

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

Если вы действительно не в курсе что пишете в некотором определённом смысле, то ни типы ни нетипы ничто не поможет.

Бинго. А ведь «не в курсе что пишете» это, наверное, 90% энтерпрайза. Сложно «быть в курсе» когда продукт — стотыщмиллионов строк говнокода, который дописывает уже третье поколение инженеров.

Может.

хм.

гм-гм. но ведь никто не обещал что ошибок не будет. и не будет трудных ошибок.

Но ошибок должно стать меньше, массово.

Пусть мы имеем функцию переводящую температуру (в Кельвинах) в давление (в Паскалях). Вообще не проблема сказать, что на входе должно быть положительное число

Вообще не обязательно. На входе должно быть нечто, что ведёт себя как положительное число, т.е. реализует определённый интерфейс. ИМХО компилятору большего знать не нужно и ничего проверять не нужно, кроме того, что переданная сущность соответствует заявленному интерфейсу. Поэтому «примитивная» джава рулит, а хаскель нет.

Бинго. А ведь «не в курсе что пишете» это, наверное, 90% энтерпрайза. Сложно «быть в курсе» когда продукт — стотыщмиллионов строк говнокода, который дописывает уже третье поколение инженеров.

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

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

Правда потом вышла амнистия на готу,

Вот в этом суть. Поэтому я и не говорю, что моя точка зрения на отладчики верна. Это просто моя точка зрения.

Что касается Common Lisp, то для корпоративной разработки есть ещё один огромный минус: любой программист может изменить данные или функции в любом пакете. То есть аналога private нет вообще.

Поэтому пытаться сейчас продвинуть Common Lisp для корпоративной разработки будет аналогично попытке продвинуть ОС Genera (то есть OpenGenera) в качестве операционной системы на рабочие станции. При том, что в Genera вообще нет изоляции процессов. Любой процесс может изменять данные любого другого процесса, а пользователь может внести изменения в ядро ОС прямо на ходу.

Что касается Common Lisp, то для корпоративной разработки есть ещё один огромный минус: любой программист может изменить данные или функции в любом пакете. То есть аналога private нет вообще.

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

Что касается Common Lisp, то для корпоративной разработки есть ещё один огромный минус: любой программист может изменить данные или функции в любом пакете. То есть аналога private нет вообще.

Аналогично (не полное подобие, но сойдёт) в питоне публичны все поля класса. И ничего, никто не умер.

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

Я никак не могу найти чем интерфейс ПоложительногоДействительногоЧисла отличается от интерфейса ДействительногоЧисла. Не поможете? :)

Вот в этом суть. Поэтому я и не говорю, что моя точка зрения на отладчики верна. Это просто моя точка зрения.

Рассуждая чуток отвлечённо: но имея отличное (от других) мнение, ты уже претендуешь на истину. Если же ты не претендуешь на истину, то обманываешь других (и себя?), получается. Зачем тогда высказывать мнение, которое даже гипотетически не может оказаться верным хотя бы в каких то ситуациях?

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

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

Более честным мне кажтеся попытаться определить границы применимости своей гипотезы.

Если вы действительно не в курсе что пишете в некотором определённом смысле, то ни типы ни нетипы ничто не поможет.

А если в курсе, что пишете, то типы вам не нужны, так как вы и так не передадите строку вместо числа (вы же знаете, что в передаваемой переменной и какой параметр ожидает вызываемая функция).

Рассуждая чуток отвлечённо: но имея отличное (от других) мнение, ты уже претендуешь на истину. Если же ты не претендуешь на истину, то обманываешь других (и себя?), получается. Зачем тогда высказывать мнение, которое даже гипотетически не может оказаться верным хотя бы в каких то ситуациях?

Оно будет верным для людей с определённой шкалой ценностей. Это примерно как утверждение «Государство должно гарантировать право собственности». Суждение верно или неверно только в рамках определённого мировоззрения.

Ведь все наши понятия — продукт общественного соглашения, не более… Поэтому в 1937 году в СССР действительно существовал троцкистско-зиновьевский блок, чего не отрицали даже его участники, этот заговор был настолько же реален, насколько реальны были Магнитка и Соловки, и таковым его делала общая убежденность в его существовании. В конце концов кому, как не руководству мирового коммунистического движения, решать, является ли та или иная группа людей троцкистско-зиновьевским блоком или нет? Большего авторитета в этой области не существует, да и сама терминология не принята в других кругах. Преположим, что изобретатель языка эсперанто ввел специальное слово для обозначния какой-то группы людей. Эсперантисты будущего могут не употреблять этого слова, но кто из них скажет, что доктор Заменхоф лгал или ошибался?.. Реальность словам придают люди. Когда умрет последний христианин, уйдет из мира и Христос, когда умрет последний марксист, исчезнет вся объективная реальность, и ничто не скопируется и не сфотографируется ничьими чувствами, и ничто не дастся никому в ощущение, существуя независимо, как не происходило этого ни в Древнем Египте, ни в Византийской империи. Сколько осиротелых демонов носятся уже над ночной землей! Мир создает вера, с предметы создает уверенность в их существовании, и наоборот: мир создает веру в себя, а предметы уеждают в своей подлинности, без одного нет другого… © Пелевин

А если в курсе, что пишете, то типы вам не нужны, так как вы и так не передадите строку вместо числа (вы же знаете, что в передаваемой переменной и какой параметр ожидает вызываемая функция).

мы «не на столько в курсе чтобы помнить каждую делать, но достаточно в кусре чтобы программа работала, если типы сошлись».

Суждение верно или неверно только в рамках определённого мировоззрения.

нет оно верно или неверно относительно того на сколько адекватно оно описывает реальность.

Более честным мне кажтеся попытаться определить границы применимости своей гипотезы.

Вот! Нашёл: https://www.jwz.org/doc/worse-is-better.html

Мой подход верен только в рамках подхода MIT. Когда лучше отсутствие программы, чем программа с нецелостной и местами некорректной архитектурой.

на сколько адекватно оно описывает реальность

Моё утверждение «пользоваться отладчиками плохо» является оценочным. Оценочные суждения про хорошо/плохо к реальности отношения не имеют. Они имеют отношения только к мировоззрению/религии.

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

И вопрос верно это или нет, вполне себе стоит.

А иначе, почему плохо?

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

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

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

и мировоззрение/религия тут совершенно непричём.

Мой подход верен только в рамках подхода MIT. Когда лучше отсутствие программы, чем программа с нецелостной и местами некорректной архитектурой.

ну, то что он «верен в рамках подхода мит» - вилами по воде писано.

Но ты претендуешь на то что он верен. Ну ок, я не готов спорить, может так оно и есть.

чем интерфейс ПоложительногоДействительногоЧисла отличается от интерфейса ДействительногоЧисла. Не поможете? :)

Помогу, они отличаются названием, т.е. типом с точки зрения компилятора.

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

Как бы сказать. Вот есть утверждения «кушать чужаков плохо» или «убивать неполноценных детей плохо». Можно также расписать цепочку рациональных рассуждений хоть за эти утверждения, хоть за их противоположности с точки зрения развития общества, но в целом доказать их невозможно.

В целом вся суть рациональных рассуждений сводится к анекдоту:

Вернулся Петька в дивизию на каникулы, Василий Иванович его спрашивает:
- Ну и чему, Петька, там в академии вас обучают?
- Да вот - логике, психологии и диалектике.
- Ух ты, Петька, а что это за науки?
- Как бы это объяснить, Василий Иваныч? Вот пример: пришли в баню двое - чистый и грязный, кто раньше мыться пойдет?
- Думаю, грязный, ведь ему нужнее.
- Правильно, Василий Иваныч, это и есть логика. Теперь смотри: чистый - он почему чистый? Мыться любит! Так кто же первым мыться пойдет?
- Получается, Петька, что чистый...
- Верно, вот это и есть психология.
- Погоди, Петька, я что-то не понимаю. Так а на самом деле кто первый пойдёт?
- А вот это, Василий Иваныч, и есть диалектика!

Вот и с отладчиками так. За: если использовать отладчик, то можно быстрее находить места ошибок и быстрее их исправлять, в результате быстрее получится безошибочный код. Против: если использовать отладчик, то меньше думаешь как программа работает, а значит меньше понимаешь как её исправлять так, чтобы ошибка не вылезла в другом месте, в результате получение безошибочного кода займёт больше времени.

Как бы сказать. Вот есть утверждения «кушать чужаков плохо»

Ну, те ребята которые кука съели по моему неплохо жили в отличие от тех которые стали работать на испанцев.

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

Поэтому я и оговорился про социальную область сразу - там сложнее, хотя тоже можно.

Вот и с отладчиками так. За: если использовать отладчик, то можно быстрее находить места ошибок и быстрее их исправлять, в результате быстрее получится безошибочный код. Против: если использовать отладчик, то меньше думаешь как программа работает, а значит меньше понимаешь как её исправлять так, чтобы ошибка не вылезла в другом месте, в результате получение безошибочного кода займёт больше времени.

Да, но твоё рассуждение всё таки конкретно и обозначает что «против» перевешивают «за». Ну и да, в реальности всё таки оно как то конкретно, правда, может быть «пофиг» , а может зависеть от ситуации сложным образом.

То что доказать это «невозможно» - опять неоднозначно. Невозможно логически, без метрических данных. Ну да. Но это лишь следствие того что пока ты реальные данные не внёс в систему, она никак с реальностью по большому счёту не связана.

ПРоведи стат. измерения, собери статистику, посмотри корреляцию, вот и увидишь формальное статистическое док-во.

А так, если исходит из твоих слов, то ничего и нигде не должно работать и никогда нет способа выбора технологии. «ведь доказать невозможно».

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

ну, то что он «верен в рамках подхода мит» - вилами по воде писано.

Могу попробовать доказать. Подход MIT — 4 аксиомы:

1. Simplicity-the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.
2. Correctness-the design must be correct in all observable aspects. Incorrectness is simply not allowed.
3. Consistency-the design must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness.
4. Completeness-the design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness.

То есть по значимости Corectness = Consistency > Completeness > Simplicity interface > Simplicity implementation.

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

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

Поэтому там, где используется отладчик, обычно после исправления сотни-другой ошибок приходится делать так называемый «рефакторинг» чтобы архитектура программы была более-менее нормальной. Если отладчика нет, то исправление архитектуры является единственным путём найти ошибку.

Невозможно логически, без метрических данных.

С метрическими данными тоже плохо. Индивидуальная разница производительности очень велика.

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

однако корректность = консистентности. почему, интересно, вместо того чтобы потратить две минуты в отладчике и устранить инкорректность, ты тратишь недели чтобы привести интерфейс к некоторой степени констенси?

очевидно, ты нарушаешь.

в жизни ты прав, только если у тебя затратыот((2 минуты * корректнесс)) > затратыот((2 недели на консистенси)) на некотором глобальном (важном) промежутке времени . Но однако из предложенных аксиом такого вывода сделать нельзя.

Но ты почему то всё равно считаешь его верным. Кажется, ты жервта пропаганды)

вообще то индивидуальная разница статистически не шибко важна для случая когда у тебя нет хорошего способа отделить эти индивидуальности заранее. А этот случай вообще то основной.

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