а отсылка про то, что такое наблюдение влияет на наблюдаемый объект, она разве не про мутабельность была?
Эта отсылка была к тому, что ПО с дебагами и прочими трейсами ведёт себя совсем не так, как без них.
ага, это просто цена за инструмент. просто нужно о ней знать и всё.
Попробуйте в следующий раз дочитывать комментарии до конца. Или хрен с ними с комментариями, фразы-то до конца дочитывайте.
и О(N^2) на время разработки
и О(N^4) на поиск багов
А использовали бы типы — не было бы такой ерунды у вас, как вы описываете.
Возможность написать функцию, которая будет обрабатывать сразу много разных типов.
Нет, конечно. Она всё ещё обрабатывает ровно один тип.
а в языке динамической типизации эту сборку осуществляет компилятор, а не программист. вот и вся разница.
А кто в языке с динамической типизацией осуществляет проверку, что вещи вне этого списка не придут, и кто отличает String как Real от String как String?
На практике я бы считал приближённо и в интервальной арифметике — всё равно все данные с погрешностями. А там уже и формулы расслабить можно, и полегче будет.
Но, опять же, я ничего не знаю о предметной области.
Ставь лайк, если любишь искать ключи где светлее, а не где потерял.
Ведь мир-то (весь мир!) состоит из мутабельных объектов.
Бездоказательное утверждение, отсылающее к эмоциям. Причём тут вообще мутабельность и объекты?
Кому в голову такое придёт?
Соломенным чучелам, с которыми вы активно спорите.
трейсы исключений помогают в сложных случаях, когда отсутствует понимание: где находится источник ошибки.
В случае таймаутов от этих трейсов (вызывающего сервера, отваливающегося по таймауту вызываемого) толку, как с трейсов изнутри grep для понимания, где в приложении, пишущем логи, по которым вы грепаете, проблема.
У меня всё больше впечатление, что к разработке софта вы относитесь как-то сбоку, как ПМ или скрам-мастер там, не знаю.
ну вслух, что ли мою фразу перечитайте. слово прямо рядом со словом "клетка" стоит.
То есть, это вы сказали, не я. QED.
ибо помимо аннотаций типов, мы теперь вынуждены иматься с return ошибок
Чем это сложнее, чем throw ошибок?
с написанием дублей методов для типов с их матчингом
Что это вообще значит?
и сборкой многих типов в единый АДТ
Чего там собирать? Это O(1) от размера кодовой базы и O(n) от количества типов ошибок, которых в стандартных оперднях очень мало.
(который является попыткой инкарнации динамической типизации)
Вы это повторяете в который раз, но в который раз отказываетесь пояснить, какое отношение АДТ имеют к динамической типизации.
То, что в инте может быть 0, может быть 1, а может быть 42 — это случайно не проявления динамической типизации, кстати?
вот в Python, например, программист не думает об управлении памятью, а в Rust вынужден постоянно об этом думать.
Да, абсолютно бессмысленное упражнение, ведь между кодом на Rust и Python нет никакой разницы по характеристикам исполнения.
именно невычислимы. но адепты типов стремятся это сделать.
Я боюсь, вы даже не понимаете, в каком смысле тут упоминалась невычислимость. Это, конечно, очень смешно.
И, кстати, типы и ООП во многом синонимы. И вы должны были бы оппонировать автору статьи. Но нет - вам кажется, что вы не такие.
Не все базисы, по которым раскладывается intrinsic-сложность систем, одинаково полезны. ООП — неудачный базис [в большинстве задач, и в подавляющем большинстве задач, с которыми сталкивался лично я]. ФП (в смысле типов) — куда более удачный базис [снова в большинстве задач].
У этой ОС есть очень даже фиксированный API под именем POSIX.
Модули ядра ты пишешь через POSIX?
Нет, только матом, только им описывается обратная совместимость Хаскеля!
А мне норм. Я как-то раз спокойно в 2019-м году взял компилятор, написанный мной в начале 2017-го и с тех пор не обновлявшийся, поменял в stack.yaml резолвер на актуальный stackage lts, потратил где-то 10 минут на выковыривание устаревших методов из кодовой базы в несколько тыяч строк, и всё после этого сразу заработало (получив заодно где-то ЕМНИП 20% прироста производительности тупо за счёт обновления компилятора и библиотек).
А то, что милые люди из WellTyped поломали систему сборки?
Эээ, я тут открыл для себя ghcup и последние года три получаю свежий ghc оттуда, так что не в курсе — а что там поломали?
Я постарался донести до ряда людей (Зубин, Гамари) простую мысель, что OCaml легко проходит через сцену любого копроративного театра безопасности за счёт того, что bootstrap компилятор поставляется в байткоде.
Не видел ни одной компании, где отсутствие бутстраппинга являлось бы ключевым препятствием перед корпоративной красной лентой. Основная сложность в нашей общей компании-то была ЕМНИП в том, чтобы убедить клоунов актёров из этого театра дать blanket permission на либы в hackage.
Кстати, как там gcc нынче бутстрапится, и кому это мешает?
Не просто безграмотность, а воинственная безграмотность.
вот итератор/счётчик позиции цикла или этих ваших итераций - это целое число, встроенный тип?
Подразумевая, что вы имели в виду индекс массива, то это встроенный тип Fin, параметризованный (гошники зажмурились) длиной (все остальные зажмурились) массива. Функция
writeAt : Array n a → Fin n → a → Array n a
не может выйти за границы вообще никогда, для любого массива любой длины, полученного откуда угодно, хотя Array и Fin являются библиотечными типами.
Что вы устали? Игнорировать эмпирические данные? Так вы и в прошлый раз это скипали и не отвечали по существу. Я вам пример, как разделение на чистые и нечистые функции не увеличивает объём кода, вы продолжаете бегать с «в два, нет, в три, нет, в десять раз больше пять экранов текста!»
затем, что этот код мы пишем? пишем.
Это тупейший клей между рантайм-системой и вашей бизнес-логикой. Там нечего тестировать.
прежде чем отдавать его клиентам убедиться нужно, что он работает? нужно
Чем меняют поведение наблюдаемой системы и её перф-характеристики.
Там, где я работал и где скорость ответа действительно была важна и приводила к более плачевным денежным исходам, чем «юзер монополиста подождёт вызова такси не 5 секун, а 10, и с вероятностью 1% в следующий раз предпочтёт идти пешком», это не работало. Работает только снятие полного дампа трафика и дальше уже существенно более тяжёлая артиллерия, чем дебаг-данные, трейсы ошибок и профайлинг средствами языка/окружения.
Впрочем, это так, лирика. Лучше скажите, как тут помогают трейсы исключений? Вы до таймаутов и прочих проблем на проде на них вообще забиваете, что ли, лол?
чуть глаза поднимите прямо на процитированный Вами текст, в нём написано в какую. прямо в Вашей цитаете есть ответ.
Так там нету.
вынуждены писать более сложный код
Что сложнее? Как раз проще: понятно, что может завершиться ошибкой (и какой), а что — нет.
от повышения сложности код становится менее надёжным, а не более, как хотелось бы
я пожаловался что с переходом на return error мы утратили весьма удобный инструмент
Только его и не было.
который помогал в отладке
При разработке или на проде? В первом случае вы код прямо пишете сейчас новый, какие там глубокие стектрейсы для ваших кеширующих микросервисов? Во втором случае, может, есть какая-то связь с отсутствием выразительных типов?
Да не, снова ерунда.
вы НАМЕРЕННО задали вопрос из области "были примеры, где этот инструмент не работал".
После ваших просьб в разговоре об ФП написать аналог вашей функции на SQL (до сих пор лолирую) или черри-пикинга отдельных библиотек в отдельном языке я на вашем месте бы не стал про это даже вспоминать.
я подтвердил, что да, были примеры, где этот инструмент не работал. и зафиксировал, что вы уводите дискуссию от первоначального пункта 1
Да не, вы просто инструменты путаете. Вы говорите об экзепшонах, когда дело в какой-нибудь там виртуальной машине для джавы или дотнета (в которых я не шарю совсем, поэтому не смогу поддержать разговор), которая может выборочно и чуть ли не ретроспективно собирать трейсы, деоптимизировать, и так далее.
Соответственно, законы физики и теории вычислимости не мешают тому же .NET CLR записывать трейс каждый раз, когда вы в F# возвращаете его аналог Left , или мне наваять за пару вечеров плагин к ghc, который каждой функции будет добавлять констрейнтHasCallStack , чтобы потом его захватывать в моей собственной иерархии ошибок.
Просто это всё нафиг никому не нужно, потому что ценность трейсов в сильно типизированных языках переоценена. Это как жаловаться, что JS безапелляционно лучше C++, потому что в JS есть eval.
Только при этом они есть даже в питоне. Просто спецификации формата — это, внезапно, спецификации формата, которые нужны, чтобы показать, условно, сколько знаков после запятой печатать, а не что-то там затыкать. Использование %d или %fв том же питоне — это просто дань традиции, чтобы программистам из других языков было проще и привычнее.
Нет никаких причин, почему нельзя было бы писать просто % в хаскельном printf — типы аргументов всё равно известны статически, и как их печатать, тоже известно статически. Просто WTF-момент от простых процентов больше, чем экономия пары знаков.
А написать типизированный принтф, терм которого после частичного применения к чему-нибудь вроде
printf "Hello {}, your age is {}"
имел бы тип Show a ⇒ Show b ⇒ a → b → String , даже проще, чем париться с полноценным разбором строки форматирования в компилтайме и последующим тайпчекингом аргументов.
Я не понимаю, как вы можете это всерьёз писать после того, как вы сами попросили меня реализовать выбранную вами (и по-вашему грязную) функцию в ФП, я это успешно сделал, выделив одну строку на грязь и дюжину строк на чистоту (такое-то удвоение ×2), и в итоге всё равно всё занимало меньше, чем у вас в вашем языке.
размер кодовой базы от такого действия удвоится (а то и утроится) - что никому не нужно.
А чё не удесятерится? Откуда здесь хотя бы даже удвоение?
тестировать "грязные" всё равно придётся
Зачем?
Пат
Мат. У меня. В адрес ваших способностей к восприятию текста, либо вашей благонамеренности в дискуссиях (возможно, вы просто шитпостите, и полное игнорирование эмпирических свидетельств с другой стороны является обманом, чтобы набрать классы).
Если фиксирует, то это ограничивает мою свободу дальнейшей разработки. Вы что, не настоящий программист, которому нужны костыли-подпорки, чтобы писать код?
прокликали - это и есть тесты. просто выполняете их вручную.
Нет, это не тесты, потому что я не потратил время на их описание в коде, они не выполняются каждый раз, и они не фиксируют поведение на будущее. Это одноразовая проверка, которой на практике достаточно.
тесты решают реальные проблемы
Так какие проблемы они решают, кроме повышения зарплаты в потогонках через демонстрацию написанных строк кода, и прикрытия ЧСВ тимлидов, мастурбирующих на совершенно бессмсыленные метрики вроде code coverage?
Доказательством тому - статистика мест, где пользователи чаще делают ошибки.
Это не доказательство, потому что тесты не избавляют от логических ошибок.
потому что иначе тело бы не скомпилировалось, например. Опа, и у вас нет паник.
Потом вы бы попытались доказать какие-нибудь свойства этой функции, вроде add a (add b c) = add (add a b) c, и у вас бы это не получилось, и вы бы подумали, что add делает какую-то ерунду (и правда, делает ерунду). Опа, и у вас нет вранья в именах.
А в тестах без типов бы вы написали add (-4) 2 = -2 и пошли бы дальше писать микросервисы для кэширования, не заметив, что делаете ерунду.
так вот, нормальные интеграционные тесты помогают в обоих случаях
Бездоказательное утверждение.
смоделировали действия пользователя в тесте - поправили. тест сохранился на будущее.
Трата времени. Без тестов быстрее прокликали, и всё. Тем более, успехов в тесте воспроизвести всё богатство окружений пользователя.
Тестами пользуются только сектанты из аджайл-тусовки, которым важно продать как можно больше написанного кода, потому что им платят за строчки кода. Ничего сложнее запросов к серверу, где они мокают http-клиент и проверяют, что моки возвращают то, что в мок передали до теста, они всё равно не проверяют.
как-то так это и работает
Снова бездоказательное убеждение. С моей колокольни видится, что вы ничего сложнее упомянутых вами выше микросервисов для кэширования (сиречь хэшмапы, которую вы и на диск-то сохранить для персистенса не сможете) не писали, где вы тестируете, что мок мапы возвращает замоканные значения.
Эта отсылка была к тому, что ПО с дебагами и прочими трейсами ведёт себя совсем не так, как без них.
Попробуйте в следующий раз дочитывать комментарии до конца. Или хрен с ними с комментариями, фразы-то до конца дочитывайте.
А использовали бы типы — не было бы такой ерунды у вас, как вы описываете.
Нет, конечно. Она всё ещё обрабатывает ровно один тип.
А кто в языке с динамической типизацией осуществляет проверку, что вещи вне этого списка не придут, и кто отличает String как Real от String как String?
Лол ок.
На практике я бы считал приближённо и в интервальной арифметике — всё равно все данные с погрешностями. А там уже и формулы расслабить можно, и полегче будет.
Но, опять же, я ничего не знаю о предметной области.
Причём тут ФП? Мы уже тесты обсуждаем, а они совершенно не нужны. Нет ни единого проекта, в котором использовались бы тесты и который был бы полезен.
Ставь лайк, если любишь искать ключи где светлее, а не где потерял.
Бездоказательное утверждение, отсылающее к эмоциям.Причём тут вообще мутабельность и объекты?Соломенным чучелам, с которыми вы активно спорите.
В случае таймаутов от этих трейсов (вызывающего сервера, отваливающегося по таймауту вызываемого) толку, как с трейсов изнутри grep для понимания, где в приложении, пишущем логи, по которым вы грепаете, проблема.
У меня всё больше впечатление, что к разработке софта вы относитесь как-то сбоку, как ПМ или скрам-мастер там, не знаю.
То есть, это вы сказали, не я. QED.
Чем это сложнее, чем throw ошибок?
Что это вообще значит?
Чего там собирать? Это O(1) от размера кодовой базы и O(n) от количества типов ошибок, которых в стандартных оперднях очень мало.
Вы это повторяете в который раз, но в который раз отказываетесь пояснить, какое отношение АДТ имеют к динамической типизации.
То, что в инте может быть 0, может быть 1, а может быть 42 — это случайно не проявления динамической типизации, кстати?
Да, абсолютно бессмысленное упражнение, ведь между кодом на Rust и Python нет никакой разницы по характеристикам исполнения.
Я боюсь, вы даже не понимаете, в каком смысле тут упоминалась невычислимость. Это, конечно, очень смешно.
Не все базисы, по которым раскладывается intrinsic-сложность систем, одинаково полезны. ООП — неудачный базис [в большинстве задач, и в подавляющем большинстве задач, с которыми сталкивался лично я]. ФП (в смысле типов) — куда более удачный базис [снова в большинстве задач].
Модули ядра ты пишешь через POSIX?
А мне норм. Я как-то раз спокойно в 2019-м году взял компилятор, написанный мной в начале 2017-го и с тех пор не обновлявшийся, поменял в stack.yaml резолвер на актуальный stackage lts, потратил где-то 10 минут на выковыривание устаревших методов из кодовой базы в несколько тыяч строк, и всё после этого сразу заработало (получив заодно где-то ЕМНИП 20% прироста производительности тупо за счёт обновления компилятора и библиотек).
Эээ, я тут открыл для себя ghcup и последние года три получаю свежий ghc оттуда, так что не в курсе — а что там поломали?
Не видел ни одной компании, где отсутствие бутстраппинга являлось бы ключевым препятствием перед корпоративной красной лентой. Основная сложность в нашей общей компании-то была ЕМНИП в том, чтобы убедить
клоуновактёров из этого театра дать blanket permission на либы в hackage.Кстати, как там gcc нынче бутстрапится, и кому это мешает?
Не просто безграмотность, а воинственная безграмотность.
Подразумевая, что вы имели в виду индекс массива, то это встроенный тип
Fin, параметризованный (гошники зажмурились) длиной (все остальные зажмурились) массива. Функцияне может выйти за границы вообще никогда, для любого массива любой длины, полученного откуда угодно, хотя
ArrayиFinявляются библиотечными типами.Как вы могли устать отвечать, если ни единого ответа на это от вас не было?
Как можно игнорировать то, чего нет?
Я вам снова на примере показал, как это количество сократить до
round $ 1 / (1 + 12)= 8%, а вы снова это игнорируете.Абсолютно верно. Бизнесу не нужны тесты и аджайл. Бизнесу нужен работающий код. Ваше слепое поклонение тестам совершенно необоснованно.
Что вы устали? Игнорировать эмпирические данные? Так вы и в прошлый раз это скипали и не отвечали по существу. Я вам пример, как разделение на чистые и нечистые функции не увеличивает объём кода, вы продолжаете бегать с «в два, нет, в три, нет, в десять раз больше пять экранов текста!»
Это тупейший клей между рантайм-системой и вашей бизнес-логикой. Там нечего тестировать.
Карго-культ и секта.
Ну так см. последний абзац.
Или
Data.String.Interpolate.Чем меняют поведение наблюдаемой системы и её перф-характеристики.
Там, где я работал и где скорость ответа действительно была важна и приводила к более плачевным денежным исходам, чем «юзер монополиста подождёт вызова такси не 5 секун, а 10, и с вероятностью 1% в следующий раз предпочтёт идти пешком», это не работало. Работает только снятие полного дампа трафика и дальше уже существенно более тяжёлая артиллерия, чем дебаг-данные, трейсы ошибок и профайлинг средствами языка/окружения.
Впрочем, это так, лирика. Лучше скажите, как тут помогают трейсы исключений? Вы до таймаутов и прочих проблем на проде на них вообще забиваете, что ли, лол?
Так там нету.
Что сложнее? Как раз проще: понятно, что может завершиться ошибкой (и какой), а что — нет.
Бездоказательное утверждение.
Получили статические гарантии. Это лучше.
Только его и не было.
При разработке или на проде? В первом случае вы код прямо пишете сейчас новый, какие там глубокие стектрейсы для ваших кеширующих микросервисов? Во втором случае, может, есть какая-то связь с отсутствием выразительных типов?
Да не, снова ерунда.
После ваших просьб в разговоре об ФП написать аналог вашей функции на SQL (до сих пор лолирую) или черри-пикинга отдельных библиотек в отдельном языке я на вашем месте бы не стал про это даже вспоминать.
Да не, вы просто инструменты путаете. Вы говорите об экзепшонах, когда дело в какой-нибудь там виртуальной машине для джавы или дотнета (в которых я не шарю совсем, поэтому не смогу поддержать разговор), которая может выборочно и чуть ли не ретроспективно собирать трейсы, деоптимизировать, и так далее.
Соответственно, законы физики и теории вычислимости не мешают тому же .NET CLR записывать трейс каждый раз, когда вы в F# возвращаете его аналог
Left, или мне наваять за пару вечеров плагин к ghc, который каждой функции будет добавлять констрейнтHasCallStack, чтобы потом его захватывать в моей собственной иерархии ошибок.Просто это всё нафиг никому не нужно, потому что ценность трейсов в сильно типизированных языках переоценена. Это как жаловаться, что JS безапелляционно лучше C++, потому что в JS есть
eval.Только при этом они есть даже в питоне. Просто спецификации формата — это, внезапно, спецификации формата, которые нужны, чтобы показать, условно, сколько знаков после запятой печатать, а не что-то там затыкать. Использование
%dили%fв том же питоне — это просто дань традиции, чтобы программистам из других языков было проще и привычнее.Нет никаких причин, почему нельзя было бы писать просто
%в хаскельном printf — типы аргументов всё равно известны статически, и как их печатать, тоже известно статически. Просто WTF-момент от простых процентов больше, чем экономия пары знаков.А написать типизированный принтф, терм которого после частичного применения к чему-нибудь вроде
имел бы тип
Show a ⇒ Show b ⇒ a → b → String, даже проще, чем париться с полноценным разбором строки форматирования в компилтайме и последующим тайпчекингом аргументов.Я не понимаю, как вы можете это всерьёз писать после того, как вы сами попросили меня реализовать выбранную вами (и по-вашему грязную) функцию в ФП, я это успешно сделал, выделив одну строку на грязь и дюжину строк на чистоту (такое-то удвоение ×2), и в итоге всё равно всё занимало меньше, чем у вас в вашем языке.
А чё не удесятерится? Откуда здесь хотя бы даже удвоение?
Зачем?
Мат. У меня. В адрес ваших способностей к восприятию текста, либо вашей благонамеренности в дискуссиях (возможно, вы просто шитпостите, и полное игнорирование эмпирических свидетельств с другой стороны является обманом, чтобы набрать классы).
Ответ на мой вопрос о том, как блок кода может запросить упомянутую вами информацию, будет, или тезис о бектрейсах в исключениях снимаем?
В каких «НЕКОТОРЫХ»? Это стандартный случай для работающего в проде (сиречь собранного с оптимизациями, и так далее) кода на C++.
В какую клетку, зачем загонять? Что это за фантазии проступают через текст?
ИМХО количество мест, где stackless полезнее, особенно для уже имеющихся языков с имеющимися кодовыми базами, куда выше, чем где stackful полезнее.
Ну так тем более, собирайте только там, где нужно. В чём вопрос-то?
Если откуда-то трейс не нужен — просто не записывайте его, точно так же, как вы сейчас его не записываете, если он вам не нужен.
В одном конкретном случае из миллионов.
На это надо потратить время, и ради чего?
Если фиксирует, то это ограничивает мою свободу дальнейшей разработки. Вы что, не настоящий программист, которому нужны костыли-подпорки, чтобы писать код?
Нет, это не тесты, потому что я не потратил время на их описание в коде, они не выполняются каждый раз, и они не фиксируют поведение на будущее. Это одноразовая проверка, которой на практике достаточно.
Так какие проблемы они решают, кроме повышения зарплаты в потогонках через демонстрацию написанных строк кода, и прикрытия ЧСВ тимлидов, мастурбирующих на совершенно бессмсыленные метрики вроде code coverage?
Это не доказательство, потому что тесты не избавляют от логических ошибок.
В нормальном языке для начала было бы
потому что иначе тело бы не скомпилировалось, например. Опа, и у вас нет паник.
Потом вы бы попытались доказать какие-нибудь свойства этой функции, вроде
add a (add b c) = add (add a b) c, и у вас бы это не получилось, и вы бы подумали, чтоaddделает какую-то ерунду (и правда, делает ерунду). Опа, и у вас нет вранья в именах.А в тестах без типов бы вы написали add (-4) 2 = -2 и пошли бы дальше писать микросервисы для кэширования, не заметив, что делаете ерунду.
А что с ним нетипизируемого? Даже хаскель может.
Бездоказательное утверждение.
Трата времени. Без тестов быстрее прокликали, и всё. Тем более, успехов в тесте воспроизвести всё богатство окружений пользователя.
Тестами пользуются только сектанты из аджайл-тусовки, которым важно продать как можно больше написанного кода, потому что им платят за строчки кода. Ничего сложнее запросов к серверу, где они мокают http-клиент и проверяют, что моки возвращают то, что в мок передали до теста, они всё равно не проверяют.
Снова бездоказательное убеждение. С моей колокольни видится, что вы ничего сложнее упомянутых вами выше микросервисов для кэширования (сиречь хэшмапы, которую вы и на диск-то сохранить для персистенса не сможете) не писали, где вы тестируете, что мок мапы возвращает замоканные значения.
Тесты не-ну-жны и вредны.