История изменений
Исправление monk, (текущая версия) :
Контракты в случае Racket задают одновременно неявные и ленивые ограничения на сущности в программе. Это очень плохо с точки зрения анализируемости. Такие программы должны легко становиться запутанными и выходить из под контроля.
По моему опыту ровно наоборот. Если в контракте указано какое-то условие, то я могу на него полагаться. Если условие такое, что его нельзя проверить сразу (функция возвращает функцию, которая возвращает целые числа), то в момент появления ошибки я увижу не непонятно откуда взявшееся не-число в переменной, а сообщение о том, что функция вернула не-число и это нарушает контракт модуля такого-то. Поэтому при корректных контрактах по любой ошибке всегда можно указать место возникновения ошибки с точностью до модуля. В случае CL, если функция нарушает свой контракт, то ошибка может выплыть совсем в другом месте.
Фактически, это позволяет в Racket производить отладку модулей абсолютно независимо друг от друга. И использование модуля не зависит от реализации этого модуля.
Идеологемы типа «при выборе между иск и игрек мы всегда выбираем икс» всегда приводят к проблемам, зачастую к фатальным. Я такое не раз наблюдал в решениях разработчиков ЯП, и в Яре тоже есть такие решения, которые я пытаюсь менять по мере осознания возникающих проблем
Такие идеологемы должны быть, если мы хотим иметь целостный язык. Иначе получаем как в CL: всюду поддержка переопределения на лету, разработки в образе; но кроме defstruct, defconstant (и частично defpackage); всё есть объект, CLOS часть стандарта; но elt и прочие функции для работы с произвольными последовательностями про CLOS не в курсе; в основном функции первым аргументом получают объект; но nth и gethash наоборот.
В данном случае, я радуюсь, что не использую «грохот» - ведь это уже вторая идеологема, направленная против практичности. Сколь бы много приложений на нём не было написано - при такой идеологии это лишь академический язык.
Смотря что понимать под практичностью. Если писать в одиночку, то контракты кажутся излишеством. Но если десять человек пилят каждый свой модуль, то возможность локализовать, кто именно накосячил через 5 секунд после появления ошибки почти бесценна.
К тому же данная идеологема является возможностью, а не обязанностью. В стандартной библиотеке контракты стоят только на входные данные и только быстрые, также есть unsafe- версии функций без проверок вообще.
Исходная версия monk, :
Контракты в случае Racket задают одновременно неявные и ленивые ограничения на сущности в программе. Это очень плохо с точки зрения анализируемости. Такие программы должны легко становиться запутанными и выходить из под контроля.
По моему опыту ровно наоборот. Если в контракте указано какое-то условие, то я могу на него полагаться. Если условие такое, что его нельзя проверить сразу (функция возвращает функцию, которая возвращает целые числа), то в момент появления ошибки я увижу не непонятно откуда взявшееся не-число в переменной, а сообщение о том, что функция вернула не-число и это нарушает контракт модуля такого-то. Поэтому при корректных контрактах по любой ошибке всегда можно указать место возникновения ошибки с точностью до модуля. В случае CL, если функция нарушает свой контракт, то ошибка может выплыть совсем в другом месте.
Фактически, это позволяет в Racket производить отладку модулей абсолютно независимо друг от друга. И использование модуля не зависит от реализации этого модуля.
Идеологемы типа «при выборе между иск и игрек мы всегда выбираем икс» всегда приводят к проблемам, зачастую к фатальным. Я такое не раз наблюдал в решениях разработчиков ЯП, и в Яре тоже есть такие решения, которые я пытаюсь менять по мере осознания возникающих проблем
Такие идеологемы должны быть, если мы хотим иметь целостный язык. Иначе получаем как в CL: всюду поддержка переопределения на лету, разработки в образе; но кроме defstruct, defconstant (и частично defpackage); всё есть объект, CLOS часть стандарта; но elt и прочие функции работа с произвольными последовательностями про CLOS не в курсе; в основном функции первым аргументом получают объект; но nth и gethash наоборот.
В данном случае, я радуюсь, что не использую «грохот» - ведь это уже вторая идеологема, направленная против практичности. Сколь бы много приложений на нём не было написано - при такой идеологии это лишь академический язык.
Смотря что понимать под практичностью. Если писать в одиночку, то контракты кажутся излишеством. Но если десять человек пилят каждый свой модуль, то возможность локализовать, кто именно накосячил через 5 секунд после появления ошибки почти бесценна.
К тому же данная идеологема является возможностью, а не обязанностью. В стандартной библиотеке контракты стоят только на входные данные и только быстрые, также есть unsafe- версии функций без проверок вообще.