Это немного сложный вопрос, поскольку различия являются как техническими, так и (что более важно, на мой взгляд) культурными. Ответ может дать только неточное, субъективное мнение. Это то, что я собираюсь здесь предоставить. Необработанные технические подробности см. В Scheme Wiki.
Схема - это язык, построенный по принципу предоставления элегантного, последовательного, хорошо продуманного базового языкового субстрата, на котором могут быть построены как практические, так и академические языки приложений.
Редко вы найдете кого-нибудь, кто пишет приложение на чистой схеме R5RS (или R6RS), и из-за минималистичного стандарта большая часть кода не переносима между реализациями схемы. Это означает, что вам придется тщательно выбирать реализацию схемы, если вы хотите написать какое-то приложение для конечного пользователя, потому что выбор в значительной степени будет определять, какие библиотеки будут вам доступны. С другой стороны, относительная свобода в проектировании реального языка приложения означает, что реализации Scheme часто предоставляют функции, о которых больше нигде не слышали; PLT Racket, например, позволяет использовать статическую типизацию и предоставляет интегрированную среду разработки, ориентированную на языки.
Функциональная совместимость за пределами базового языка обеспечивается через процесс SRFI, управляемый сообществом, но доступность любого данного SRFI зависит от реализации.
Большинство диалектов и библиотек Scheme сосредоточены на идиомах функционального программирования, таких как рекурсия, а не итерация. Существуют различные объектные системы, которые вы можете загружать как библиотеки, когда хотите выполнять ООП, но интеграция с существующим кодом сильно зависит от диалекта Scheme и окружающей его культуры (Chicken Scheme кажется более объектно-ориентированной, чем, например, Racket).
Интерактивное программирование - еще один момент, которым отличаются подсообщества Scheme. Схема MIT известна сильной интерактивной поддержкой, в то время как PLT Racket кажется гораздо более статичным. В любом случае интерактивное программирование не кажется центральной проблемой для большинства подсообществ Scheme, и я еще не видел среды программирования, столь же интерактивной, как большинство Common Lisps.
Common Lisp - устаревший язык, разработанный для практического программирования. Он полон уродливых замечаний и советов по совместимости - полная противоположность элегантному минимализму Scheme. Но он также гораздо более функциональный, если брать его сам за себя.
Common Lisp породил относительно большую экосистему переносимых библиотек. Обычно вы можете переключить реализации в любое время, даже после развертывания приложения, без особых проблем. В целом Common Lisp намного более единообразен, чем Scheme, и более радикальные языковые эксперименты, если они вообще проводятся, обычно встраиваются в виде переносимой библиотеки, а не определяют полностью новый диалект языка. Из-за этого языковые расширения, как правило, более консервативны, но также более комбинируемы (и часто необязательны).
Универсально полезные языковые расширения, такие как интерфейсы внешних функций, не разрабатываются формальными средствами, а полагаются на квазистандартные библиотеки, доступные во всех основных реализациях Common Lisp.
Языковые идиомы представляют собой дикая смесь функционального, императивного и объектно-ориентированного подходов, и в целом Common Lisp больше похож на императивный язык, чем на функциональный. Он также чрезвычайно динамичен, возможно, в большей степени, чем любой из популярных динамических языков сценариев (например, переопределение класса применяется к существующим экземплярам, а система обработки условий имеет встроенную интерактивность), а интерактивное исследовательское программирование является важной частью "путь Common Lisp". Это также отражено в средах программирования, доступных для Common Lisp, практически все из которых предлагают своего рода прямое взаимодействие с работающим компилятором Lisp.
Common Lisp имеет встроенную объектную систему (CLOS), систему обработки условий, значительно более мощную, чем простая обработка исключений, возможность исправления во время выполнения и различные виды встроенных структур данных и утилит (включая пресловутый LOOP макрос, итерационный подъязык, слишком уродливый для Scheme, но слишком полезный, чтобы не упомянуть, поскольку а также механизм форматирования, подобный printf, с поддержкой GOTO в строках формата).
Как из-за интерактивной разработки на основе изображений, так и из-за большего объема языка реализации Lisp обычно менее переносимы между операционными системами, чем реализации Scheme. Например, запуск Common Lisp на встроенном устройстве не для слабонервных. Как и в случае с виртуальной машиной Java, вы также можете столкнуться с проблемами на машинах, где виртуальная память ограничена (например, виртуальные серверы на основе OpenVZ). С другой стороны, реализации схем более компактны и портативны. Повышение качества реализации ECL несколько смягчило этот момент, хотя суть его остается верной.
Если вам нужна коммерческая поддержка, есть пара компаний, которые предоставляют свои собственные реализации Common Lisp, включая построители графического интерфейса, специализированные системы баз данных и так далее.
Подводя итоги: Scheme - это язык с более элегантным дизайном. Это прежде всего функциональный язык с некоторыми динамическими функциями. Его реализации представляют собой различные несовместимые диалекты с отличительными особенностями. Common Lisp - это полноценный, высокодинамичный, многопарадигмальный язык с различными уродливыми, но прагматическими функциями, реализации которых в значительной степени совместимы друг с другом. Диалекты схем имеют тенденцию быть более статичными и менее интерактивными, чем Common Lisp; Реализации Common Lisp обычно тяжелее и сложнее в установке.
Какой бы язык вы ни выбрали, желаю вам много веселья! :)
person
Matthias Benkard
schedule
20.03.2011
