Това е малко труден въпрос, тъй като разликите са както технически, така и (по-важното според мен) културни. Отговорът може да предостави само неточна, субективна гледна точка. Това е, което ще предоставя тук. За някои необработени технически подробности вижте Scheme Wiki.
Scheme е език, изграден на принципа на предоставяне на елегантен, последователен, добре обмислен базов езиков субстрат, върху който могат да се надграждат както практически, така и академични езици за приложение.
Рядко ще намерите някой, който пише приложение в чиста R5RS (или R6RS) схема и поради минималистичния стандарт повечето кодове не могат да бъдат преносими между реализациите на схемата. Това означава, че ще трябва внимателно да изберете внедряването на Scheme, ако искате да напишете някакъв вид приложение за краен потребител, тъй като изборът до голяма степен ще определи какви библиотеки са достъпни за вас. От друга страна, относителната свобода при проектирането на действителния език на приложението означава, че имплементациите на Scheme често предоставят функции, нечувани другаде; PLT Racket, например, ви позволява да използвате статично въвеждане и предоставя IDE, която е много съобразена с езика.
Оперативната съвместимост извън основния език се осигурява чрез управлявания от общността SRFI процес, но наличността на даден SRFI варира в зависимост от изпълнението.
Повечето диалекти и библиотеки на Scheme се фокусират върху идиоми на функционалното програмиране като рекурсия вместо итерация. Има различни обектни системи, които можете да заредите като библиотеки, когато искате да направите ООП, но интеграцията със съществуващия код силно зависи от диалекта Scheme и заобикалящата го култура (Chicken Scheme изглежда е по-обектно-ориентирана от Racket, например).
Интерактивното програмиране е друга точка, по която подобщностите на Scheme се различават. MIT Scheme е известна със силна поддръжка на интерактивност, докато 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, включително графични GUI създатели, специализирани системи за бази данни и т.н.
Обобщавайки, Scheme е език с по-елегантен дизайн. Това е предимно функционален език с някои динамични характеристики. Неговите реализации представляват различни несъвместими диалекти с отличителни характеристики. Common Lisp е напълно развит, силно динамичен, мулти-парадигмен език с различни грозни, но прагматични функции, чиито реализации са до голяма степен съвместими една с друга. Диалектите на схемата са по-статични и по-малко интерактивни от Common Lisp; Реализациите на Common Lisp обикновено са по-тежки и по-трудни за инсталиране.
Който и език да изберете, желая ви много забавление! :)
person
Matthias Benkard
schedule
20.03.2011
