Сравнение Common Lisp с Gambit по отношению к их библиотеке и объектным системам
Я очень заинтригован Gambit Scheme, в частности, его широким спектром поддерживаемых платформ и возможностью помещать код C прямо в исходный код Scheme, когда это необходимо. Тем не менее, это Схема, в которой меньше "включенных батарей" по сравнению с Common Lisp. Некоторые люди любят кодировать много вещей с нуля, (якобы бреется), но не я!
Это подводит меня к двум моим вопросам, предназначенным для людей, которые использовали как Gambit, так и некоторую версию Common Lisp:
1) Который эффективно имеет лучший доступ к библиотекам? Схема имеет меньше библиотек, чем Common Lisp. Однако Gambit Scheme имеет более плавный доступ к коду и библиотекам C/C++, которые намного превосходят библиотеки Common Lisp. На ваш взгляд, перевешивает ли гладкость FFI в Gambit его отсутствие нативных библиотек?
2) Как объектные системы Scheme (например, TinyCLOS, Meroon) сравниваются с CLOS Common Lisp? Если вы обнаружили, что их не хватает, какие функции вы пропустили больше всего? Наконец, насколько важна объектная система в Lisp / Scheme в первую очередь? Я слышал о целых компаниях на основе lisp (например, ITA Software), которые вообще отказались от CLOS. Являются ли объекты действительно необязательными в Lisp/Scheme? Я действительно боюсь, что если у Gambit нет хорошей объектной системы, я могу пропустить их (мой опыт программирования является чисто объектно-ориентированным).
Спасибо за помощь начинающему конвертеру из C++ / Python,
- Мэтт
PS: Кто-то с более чем 1500 представителями, не могли бы вы создать тег "гамбит"? :) Спасибо, Джонас!
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 не должен отличаться в этом аспекте.
Конечно, Схема в целом имеет меньше библиотек в определенном стандарте, но любая конкретная реализация Схемы обычно основывается на этом стандарте, чтобы включать больше функций типа "батарейки включены".
Gambit, например, использует систему пакетов Snow, которая предоставит вам доступ к нескольким библиотекам поддержки.
Другие Схемы работают даже лучше, имея доступ к большему количеству (или лучше) библиотек поддержки. И Ракетка (с PlaneT) и Цыпленок (с яйцами) немедленно приходят на ум.
Тем не менее, Common Lisp также довольно богат, и большое количество интересных и полезных библиотек легко установить.
Что касается объектных систем Scheme, я лично склоняюсь в пользу Chicken Scheme и предпочел кооперативы. Тем не менее, нет ничего плохого в TinyCLOS. Либо бы хорошо послужил и не нашел бы чего-нибудь, чего не хватает. Хотя это последнее утверждение может быть связано с тем фактом, что я не склонен полагаться на множество объектно-ориентированных измов при написании Scheme. Обе системы в моем опыте имеют тенденцию выходить на поверхность, когда я хочу написать "протоколы" и затем иметь возможность специализироваться на протоколе, если это имеет смысл.