История изменений
Исправление monk, (текущая версия) :
Например, во всех SQL-серверах есть возможность подать запрос с консоли, т.е. eval, а также alter table и alter procedure, т.е., SQL реализован динамически. Посмотрите, как широко испольузется SQL. Также сама операционная система является динамической реализацией, если считать исполняемые файлы функциями.
И часто пользователь операционной системы (не программист) изменяет системные файлы или пользователь информационной системы на SQL меняет таблицы (и особенно процедуры)?
Чем больше программа, тем больше накладные расходы на её пересборку.
Пересобираются только изменённые модули и те модули, которые от них зависят. Поэтому, если базовые модули написаны корректно, то накладные расходы на пересборку невелики. Динамическая же замена на лету напоминает kexec для обновления ядра (чтобы uptime не слетал). В случае более-менее существенных изменений, ломается состояние системы.
вводятся разные средства для придания реализации некоторых свойств динамизма, например, плагины и скриптовые языки
В этом смысле Racket 100% динамический. Для запуска любого кода на базе существующего достаточно стандартного REPL'а. Нельзя только изменять импортированные из других модулей объекты. Но для плагинов такое ограничение — необходимость. Новую версию модуля также можно загрузить на ходу.
> (enter! "m.rkt")
> (define tt (a 5))
> tt
6
> (enter! "m.rkt")
[re-loading /home/monk/languages/racket/test/m.rkt]
> tt
6
> (a 5)
4
Поэтому именно из соображений производительности труда я призываю пользоваться динамическими реализациями, а не статическими. Поэтому я за Common Lisp и против Racket.
Из обоснованных аргументов только идея «язык как операционная система с shell». Из которой вытекает идея разработки в образе.
Но я именно поэтому буду против. :-) Common Lisp для пользователя программы - это как UNIX с одним пользователем: root. Пользватель может изменить любой объект и с лёгкостью сломать систему. Причём всё средства защиты на уровне UNIX'овых «невидимых файлов». Если файл начинается с точки, то он невидимый, если символ в пакете доступен через два двоеточия, значит он внутренний.
Исходная версия monk, :
Например, во всех SQL-серверах есть возможность подать запрос с консоли, т.е. eval, а также alter table и alter procedure, т.е., SQL реализован динамически. Посмотрите, как широко испольузется SQL. Также сама операционная система является динамической реализацией, если считать исполняемые файлы функциями.
И часто пользователь операционной системы (не программист) изменяет системные файлы или пользователь информационной системы на SQL меняет таблицы (и особенно процедуры)?
Чем больше программа, тем больше накладные расходы на её пересборку.
Пересобираются только изменённые модули и те модули, которые от них зависят. Поэтому, если базовые модули написаны корректно, то накладные расходы на пересборку невелики. Динамическая же замена на лету напоминает kexec для обновления ядра (чтобы uptime не слетал). В случае более-менее существенных изменений, ломается состояние системы.
вводятся разные средства для придания реализации некоторых свойств динамизма, например, плагины и скриптовые языки
В этом смысле Racket 100% динамический. Для запуска любого кода на базе существующего достаточно стандартного REPL'а. Нельзя только изменять импортированные из других модулей объекты. Но для плагинов такое ограничение — необходимость. Новую версию модуля также можно загрузить на ходу.
> (enter! "m.rkt")
> (define tt (a 5))
> tt
6
> (enter! "m.rkt")
[re-loading /home/monk/languages/racket/test/m.rkt]
> tt
6
> (a 5)
4
Поэтому именно из соображений производительности труда я призываю пользоваться динамическими реализациями, а не статическими. Поэтому я за Common Lisp и против Racket.
Из обоснованных аргументов только идея «язык как операционная система с shell». Из которой вытекает идея разработки в образе.
Но я именно поэтому буду против. :-) Common Lisp для пользователя программы - это как UNIX с одним пользователем: root. Пользватель может изменить любой объект и с лёгкостью сломать систему. Причём всё редства защиты на уровне UNIX'овых «невидимых файлов». Если файл начинается с точки, то он невидимый, если символ в пакете доступен через два двоеточия, значит он внутренний.