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

Статический анализ - это, например, анализ какая функция вызывает какую. Анализ, символы из какого пакета используются в функциях из данного пакета. Есть ещё один вид анализа, важный именно для лиспа: анализ, можно ли собрать данный исходник «с нуля». Например, может быть так, что в данном образе исходник собирается, а в пустом не соберётся, поскольку какая-то функция переименована или просто порядок определений такой, что в этом порядке не соберётся. У меня это на сегодня две основных просадки по производительности труда.

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

CLOS/MOP - это вещь, от которой я держусь подальше только потому, что CLOS просаживает производительность. Если, не дай бог, производительность просядет ниже питона, мы лишимся одной из киллер-фич. К тому же код становится неоднозначным и менее понятным при чтении. Вообще-то настраиваемая возможность по M-. попасть в определение сущности - это тоже важная фича лиспа. С методами это уже не так.

Правильно. Потому что нужно работать.

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

Кстати, CL никогда не обещал интроспекцию/рефлексию «сырых» S-выражений.

Неважно, что он обещал. Мы живём в конкурентной среде. Ну и язык лисп - это не просто S-выражения. Есть ещё ридмакросы, в т.ч. определённые пользователем.

Статический анализ - это, например, анализ какая функция вызывает какую. Анализ, символы из какого пакета используются в функциях из данного пакета. Есть ещё один вид анализа, важный именно для лиспа: анализ, можно ли собрать данный исходник «с нуля». Например, может быть так, что в данном образе исходник собирается, а в пустом не соберётся, поскольку какая-то функция переименована. У меня это на сегодня две основных просадки по производительности труда.

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

CLOS/MOP - это вещь, от которой я держусь подальше только потому, что CLOS просаживает производительность. Если, не дай бог, производительность просядет ниже питона, мы лишимся одной из киллер-фич. К тому же код становится неоднозначным и менее понятным при чтении. Вообще-то настраиваемая возможность по M-. попасть в определение сущности - это тоже важная фича лиспа. С методами это уже не так.

Правильно. Потому что нужно работать.

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

Кстати, CL никогда не обещал интроспекцию/рефлексию «сырых» S-выражений.

Неважно, что он обещал. Мы живём в конкурентной среде. Ну и язык лисп - это не просто S-выражения. Есть ещё ридмакросы, в т.ч. определённые пользователем.