Сравнение Common Lisp с Gambit с их библиотекой доступа и объектными системами

Question

Я довольно заинтригован Gambit Scheme, в частности, его широким спектром поддерживаемых платформ и способностью помещать код C прямо в исходный код Scheme, когда это необходимо. Тем не менее, это Схема, в которой меньше «включенных батарей» по сравнению с Common Lisp. Некоторым нравится кодировать множество вещей с нуля (энергичное бритье), но не мне!

Это подводит меня к двум моим вопросам, предназначенным для людей, которые использовали и Gambit, и немного разновидности Common Lisp:

1) Какой из них имеет лучший доступ к библиотекам? Схема имеет меньше библиотек, чем Common Lisp. Однако Gambit Scheme имеет более плавный доступ к коду и библиотекам C / C ++, которые намного превосходят библиотеки Common Lisp. На ваш взгляд, перевешивает ли гладкость FFI в Gambit отсутствие встроенных библиотек?

2) Как объектные системы Схемы (например, TinyCLOS, Meroon) сравниваются с CLOS Common Lisp? Если вы обнаружили, что их не хватает, какие функции вы пропустили больше всего? Наконец, насколько важна объектная система в Lisp / Scheme в первую очередь? Я слышал о целых компаниях на основе lisp (например, ITA Software), которые вообще отказались от CLOS. Являются ли объекты действительно необязательными в Lisp / Scheme? Я боюсь, что если у Gambit нет хорошей объектной системы, я могу пропустить их (мой опыт программирования чисто объектно-ориентирован).

Спасибо за помощь начинающему конвертеру из C ++ / Python,

- Мэтт

PS: Кто-то с более чем 1500 представителями, не могли бы вы создать тег "гамбит"? :) Спасибо, Джонас!

Answer 1

Конечно, Схема в целом имеет меньше библиотек в определенном стандарте, но любая конкретная реализация Схемы обычно основывается на этом стандарте, чтобы включать больше функций типа «включенные батареи».

Например, Гамбит использует Snow система пакетов, которая предоставит вам доступ к нескольким библиотекам поддержки.

Другие схемы работают еще лучше, имея доступ к большему количеству (или лучше) библиотек поддержки.Как Ракетка (с PlaneT ), так и Курица (с яйцами ) сразу приходят на ум.Интересные и полезные библиотеки легко установить.

Что касается объектных систем Scheme, я лично склоняюсь в пользу Chicken Scheme и предпочел coops .Тем не менее, с TinyCLOS все в порядке.Либо будет хорошо служить, и на самом деле ничего не будет не хватать.Хотя это последнее утверждение может быть связано с тем фактом, что я не склонен полагаться на множество объектно-ориентированных измов при написании Scheme.Обе системы в моем опыте имеют тенденцию появляться, когда я хочу написать «протоколы», а затем иметь возможность специализироваться на протоколе, если это имеет смысл.

Answer 2

1) Я не использовал Gambit Scheme, поэтому я не могу сказать, насколько гладкой является интеграция C / C ++.Но все Common Lisps, которые я использовал, имеют полнофункциональные C FFI: s.Таким образом, наличие библиотек C одинаково.Требуется некоторая работа для интеграции, но я предполагаю, что это также относится и к схеме Gambit.В конце концов, Lisp и C разные языки ..?Но, возможно, у вас другой опыт, я бы хотел узнать больше в этом случае.

Возможно, вас заинтересует Quicklisp , действительно хороший новый проект Common Lisp - он делает его очень простымустановить много качественных библиотек.

2) C ++ и Python предназначены для использования ООП и классов в качестве типичных средств инкапсуляции и структурирования данных.У CLOS нет таких амбиций вообще.Вместо этого он предоставляет универсальные функции, которые могут быть специализированы для определенных типов аргументов - не обязательно классов.По сути, это включает ООП, но в Common Lisp ООП является удобной функцией, а не чем-то фундаментальным для достижения цели.

Я думаю, что CLOS намного более хорошо спроектирован и гибок, чем объектная модель C ++ - TinyCLOSне отличайтесь в этом аспекте.