История изменений

И часто пользователь операционной системы (не программист) изменяет системные файлы или пользователь информационной системы на SQL меняет таблицы (и особенно процедуры)?

Если я ничего не путаю, то мы говорили о производительности труда именно программиста.

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

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

В этом смысле Racket 100% динамический. ... Нельзя только изменять импортированные из других модулей объекты.

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

Возможность изменять на ходу одну функцию, переменную, определение класса независимо от места их определения - это основа процесса разработки в CL. Бывают случаи, когда это нежелательно. У меня был один такой случай. Для него я написал обёртку к команде IDE compile defun (кстати, я поменял тем самым функцию из чужого модуля). Обёртка запускается вокруг обычной функции среды compile defun и запрещает компилировать одно определение в файле с таким-то именем. Поэтому данный файл можно загрузить только целиком (типо с соблюдением модульности). Можно было бы запретить и загрузку файла иначе, как в рамках asdf-системы. Можно было и для compile написать такой wrapper, но в моём случае было достаточно защиты от дурака, а не от взлома.

Причём всё средства защиты на уровне UNIX'овых «невидимых файлов». Если файл начинается с точки, то он невидимый, если символ в пакете доступен через два двоеточия, значит он внутренний.

Защита от изменений ортогональна к динамизму реализации. В SQL защита основана на выделении полномочий на объекты. Пользователь не может поменять процедуру, если ему не дали на это прав. И в CL нетрудно сделать версию интерпретатора с ограничением полномочий, это на lisper.ru обсуждали в своё время. Дополнительные ограничения, связанные с границами модулей, выразимы через ограничения отдельных объектов. Если они наложены раз и навсегда и их нельзя снять, то они вредны, а не полезны.

И часто пользователь операционной системы (не программист) изменяет системные файлы или пользователь информационной системы на SQL меняет таблицы (и особенно процедуры)?

Если я ничего не путаю, то мы говорили о производительности труда именно программиста.

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

накладные расходы на пересборку невелики.

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

В этом смысле Racket 100% динамический. ... Нельзя только изменять импортированные из других модулей объекты.

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

Возможность изменять на ходу одну функцию, переменную, определение класса независимо от места их определения - это основа процесса разработки в CL. Бывают случаи, когда это нежелательно. У меня был один такой случай. Для него я написал обёртку к команде IDE compile defun (кстати, я поменял тем самым функцию из чужого модуля). Обёртка запускается вокруг обычной функции среды compile defun и запрещает компилировать одно определение в файле с таким-то именем. Поэтому данный файл можно загрузить только целиком (типо с соблюдением модульности). Можно было бы запретить и загрузку файла иначе, как в рамках asdf-системы. Можно было и для compile написать такой wrapper, но в моём случае было достаточно защиты от дурака, а не от взлома.

Причём всё средства защиты на уровне UNIX'овых «невидимых файлов». Если файл начинается с точки, то он невидимый, если символ в пакете доступен через два двоеточия, значит он внутренний.

Защита от изменений ортогональна к динамизму реализации. В SQL защита основана на выделении полномочий на объекты. Пользователь не может поменять процедуру, если ему не дали на это прав. И в CL нетрудно сделать версию интерпретатора с ограничением полномочий, это на lisper.ru обсуждали в своё время. Дополнительные ограничения, связанные с границами модулей, выразимы через ограничения отдельных объектов. Если они наложены раз и навсегда и их нельзя снять, то они вредны, а не полезны.