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

Если интероп с java не нужен

Значит, ты пишешь лабораторную работу и кложа тебе ни к чему, бери академически православную схему. В реальном коде (в основном в библиотеках, конечно) в жабу/жс нырять время от времени требуется.

какие у неё имеются достоинства?

1. Неизменяемые, персистентные структуры данных. Никаких «кто там изменил мой список в другом треде, блеять» и «надо скопировать весь этот хэшмап на 100500 ключей, чтобы никто его случайно не изменил».
2. Явное управление состоянием (references, software transactional memory). Если вот здесь мы храним изменяемое состояние, это сразу видно, и для его (атомарного) изменения есть отдельные функции. Никаких случайных изменений, никаких промежуточных неконсистентных состояний.
3. Отдельный синтаксис для основных составных структур данных (индексированные и ассоциативные массивы, множества — vectors, maps, sets). Не нужно щуриться, чтобы понять, что вот этот список из себя представляет — alist или plist, или это вообще какой-нибудь class parameter qualifier, а не структура данных. То есть синтаксиса становится немного больше, но каждый его кусочек становится легче воспринимать, а с составными структурами данных становится гораздо легче работать. Списки же в основном используются по прямому назначению — для представления кода.
4. Уклон в сторону структурной (утиной) типизации, в противовес номинальной (основанной на классах). Поддерживается и то, и то, но если в хэшмапе есть нужные ключи, то чем он не экземпляр типа. Полиморфизм не приколочен гвоздями к классам и типу первого параметра.
5. Стандартные функции (из clojure.core) оперируют абстрактными, а не конкретными структурами данных (например, sequence вместо cons cell) — легко добавить любому пользовательскому типу поддержку стандартных операций, достаточно реализовать для него интерфейс нужной абстракции.
6. Если для твоей проблемы есть решение на одном из языков платформы, ты легко можешь его использовать. А на жабе/жс столько всего уже понаписано…

Ограничения, конечно, тоже имеются — tail call optimization, например, его нет. С continuations тоже ситуация сложная.

Если интероп с java не нужен

Значит, ты пишешь лабораторную работу и кложа тебе ни к чему, бери академически православную схему. В реальном коде (в основном в библиотеках, конечно) в жабу/жс нырять время от времени требуется.

какие у неё имеются достоинства?

1. Неизменяемые, персистентные структуры данных. Никаких «кто там изменил мой список в другом треде, блеять» и «надо скопировать весь этот хэшмап на 100500 ключей, чтобы никто его случайно не изменил».
2. Явное управление состоянием, software transactional memory. Если вот здесь мы храним изменяемое состояние, это сразу видно, и для его (атомарного) изменения есть отдельные функции. Никаких случайных изменений, никаких промежуточных неконсистентных состояний.
3. Отдельный синтаксис для основных составных структур данных (индексированные и ассоциативные массивы, множества — vectors, maps, sets). Не нужно щуриться, чтобы понять, что вот этот список из себя представляет — alist или plist, или это вообще какой-нибудь class parameter qualifier, а не структура данных. То есть синтаксиса становится немного больше, но каждый его кусочек становится легче воспринимать, а с составными структурами данных становится гораздо легче работать. Списки же в основном используются по прямому назначению — для представления кода.
4. Уклон в сторону структурной (утиной) типизации, в противовес номинальной (основанной на классах). Поддерживается и то, и то, но если в хэшмапе есть нужные ключи, то чем он не экземпляр типа. Полиморфизм не приколочен гвоздями к классам и типу первого параметра.
5. Стандартные функции (из clojure.core) оперируют абстрактными, а не конкретными структурами данных (например, sequence вместо cons cell) — легко добавить любому пользовательскому типу поддержку стандартных операций, достаточно реализовать для него интерфейс нужной абстракции.
6. Если для твоей проблемы есть решение на одном из языков платформы, ты легко можешь его использовать. А на жабе/жс столько всего уже понаписано…

Ограничения, конечно, тоже имеются — tail call optimization, например, его нет. С continuations тоже ситуация сложная.

Если интероп с java не нужен

Значит, ты пишешь лабораторную работу и кложа тебе ни к чему, бери академически православную схему. В реальном коде (в основном в библиотеках, конечно) в жабу/жс нырять время от времени требуется.

какие у неё имеются достоинства?

1. Неизменямые, персистентные структуры данных. Никаких «кто там изменил мой список в другом треде, блеять» и «надо скопировать весь этот хэшмап на 100500 ключей, чтобы никто его случайно не изменил».
2. Явное управление состоянием, software transactional memory. Если вот здесь мы храним изменяемое состояние, это сразу видно, и для его (атомарного) изменения есть отдельные функции. Никаких случайных изменений, никаких промежуточных неконсистентных состояний.
3. Отдельный синтаксис для основных составных структур данных (индексированные и ассоциативные массивы, множества — vectors, maps, sets). Не нужно щуриться, чтобы понять, что вот этот список из себя представляет — alist или plist, или это вообще какой-нибудь class parameter qualifier, а не структура данных. То есть синтаксиса становится немного больше, но каждый его кусочек становится легче воспринимать, а с составными структурами данных становится гораздо легче работать. Списки же в основном используются по прямому назначению — для представления кода.
4. Уклон в сторону структурной (утиной) типизации, в противовес номинальной (основанной на классах). Поддерживается и то, и то, но если в хэшмапе есть нужные ключи, то чем он не экземпляр типа. Полиморфизм не приколочен гвоздями к классам и типу первого параметра.
5. Стандартные функции (из clojure.core) оперируют абстрактными, а не конкретными структурами данных (например, sequence вместо cons cell) — легко добавить любому пользовательскому типу поддержку стандартных операций, достаточно реализовать для него интерфейс нужной абстракции.
6. Если для твоей проблемы есть решение на одном из языков платформы, ты легко можешь его использовать. А на жабе/жс столько всего уже понаписано…

Ограничения, конечно, тоже имеются — tail call optimization, например, его нет. С continuations тоже ситуация сложная.