Исправление monk, (текущая версия) :
Тогда у меня вопрос - в чем отличие того же Racket (или вообще scheme) от Common Lisp? Что их делает разными языками?
В первую очередь — идеология: Анализ пользователей Common Lisp и Racket
На Common Lisp обычно получается чуть быстрее написать. Но намного сложнее получить гарантии надёжной работы. И принято документировать между строк кода.
В Racket же есть контракты (https://docs.racket-lang.org/guide/contracts.html), типизированные модули (https://docs.racket-lang.org/ts-guide/index.html), стандарт на документацию (https://docs.racket-lang.org/scribble/index.html).
Причём всё сделано не в стиле, принятом в C и Common Lisp, когда достаточно, чтобы библиотека работала в 90% случаев, а если что не так, то будет UB в C или отладчик в CL.
Если контракты, то с возможностью указать контракт типа «данная функция возвращает функцию от числа, которая всегда возвращает число не меньше переданного первого аргумента»:
(->i ([argument real?])
[result (argument) (-> real? (>=/c argument))])
Если типизация, то система типов уровня Haskell, а не C++.
Если документация, то с возможностью вывода в HTML и TeX и возможностью вычислять во время формирования текста.
Если макросы, то с гарантией того, что имя снаружи может протечь в результат раскрытия макроса.
Если компиляция, то воспроизводимая. В CL все модули компилируются в одной виртуальной машине и процесс компиляции модуля может влиять на компиляцию следующего. В Racket компиляция каждого модуля в изолированной среде.
В недостатке — чуть ниже производительность (аналога declare unsafe из CL нет) и хуже отладчик.
Исходная версия monk, :
Тогда у меня вопрос - в чем отличие того же Racket (или вообще scheme) от Common Lisp? Что их делает разными языками?
В первую очередь — идеология: Анализ пользователей Common Lisp и Racket
На Common Lisp обычно получается чуть быстрее написать. Но намного сложнее получить гарантии надёжной работы. И принято документировать между строк кода.
В Racket же есть контракты (https://docs.racket-lang.org/guide/contracts.html), типизированные модули (https://docs.racket-lang.org/ts-guide/index.html), стандарт на документацию (https://docs.racket-lang.org/scribble/index.html).
Причём всё сделано не в стиле, принятом в C и Common Lisp, когда достаточно, чтобы библиотека работала в 90% случаев, а если что не так, то будет UB в C или отладчик в CL.
Если контракты, то с возможностью указать контракт типа «данная функция возвращает функцию от числа, которая всегда возвращает число больше переданного первого аргумента»:
(->i ([argument real?])
[result (argument) (-> real? (>=/c argument))])
Если типизация, то система типов уровня Haskell, а не C++.
Если документация, то с возможностью вывода в HTML и TeX и возможностью вычислять во время формирования текста.
Если макросы, то с гарантией того, что имя снаружи может протечь в результат раскрытия макроса.
Если компиляция, то воспроизводимая. В CL все модули компилируются в одной виртуальной машине и процесс компиляции модуля может влиять на компиляцию следующего. В Racket компиляция каждого модуля в изолированной среде.
В недостатке — чуть ниже производительность (аналога declare unsafe из CL нет) и хуже отладчик.