C'est un peu une question délicate, car les différences sont à la fois techniques et (plus important encore, à mon avis) culturelles. Une réponse ne peut jamais fournir qu'une vision imprécise et subjective. C'est ce que je vais fournir ici. Pour quelques détails techniques bruts, consultez le Wiki Scheme.
Scheme est un langage construit sur le principe de fournir un substrat de langage de base élégant, cohérent et bien pensé sur lequel des langages d'application pratiques et académiques peuvent être construits.
Vous trouverez rarement quelqu'un écrivant une application en pur Scheme R5RS (ou R6RS), et en raison de la norme minimaliste, la plupart du code n'est pas portable entre les implémentations de Scheme. Cela signifie que vous devrez choisir soigneusement votre implémentation de Scheme, si vous souhaitez écrire un type d'application pour l'utilisateur final, car le choix déterminera en grande partie les bibliothèques disponibles. En revanche, la liberté relative dans la conception du langage d'application réel signifie que les implémentations de Scheme fournissent souvent des fonctionnalités inédites ailleurs; PLT Racket, par exemple, vous permet d'utiliser le typage statique et fournit un IDE très conscient du langage.
L'interopérabilité au-delà du langage de base est assurée par le processus SRFI communautaire, mais la disponibilité de tout SRFI donné varie selon l'implémentation.
La plupart des dialectes et bibliothèques Scheme se concentrent sur des idiomes de programmation fonctionnelle comme la récursion au lieu de l'itération. Il existe divers systèmes d'objets que vous pouvez charger sous forme de bibliothèques lorsque vous souhaitez faire de la POO, mais l'intégration avec du code existant dépend fortement du dialecte de Scheme et de sa culture environnante (par exemple, Chicken Scheme semble être plus orienté objet que Racket).
La programmation interactive est un autre point sur lequel les sous-communautés de Scheme diffèrent. MIT Scheme est connu pour son fort support en termes d'interactivité, tandis que PLT Racket est beaucoup plus statique. Dans tous les cas, la programmation interactive ne semble pas être une préoccupation centrale pour la plupart des sous-communautés de Scheme, et je n'ai encore jamais vu un environnement de programmation aussi interactif que celui de la plupart des Lisp communs.
Common Lisp est un langage éprouvé sur le terrain conçu pour la programmation pratique. Il est plein de verrues laides et de correctifs de compatibilité - tout le contraire du minimalisme élégant de Scheme. Mais il est aussi beaucoup plus riche en fonctionnalités pris pour lui-même.
Common Lisp a engendré un écosystème relativement important de bibliothèques portables. Vous pouvez généralement changer d'implémentation à tout moment, même après le déploiement de l'application, sans trop de problèmes. Globalement, Common Lisp est beaucoup plus uniforme que Scheme, et les expérimentations linguistiques plus radicales, si elles sont faites, sont généralement intégrées en tant que bibliothèque portable plutôt que de définir un tout nouveau dialecte. En raison de cela, les extensions de langage ont tendance à être plus conservatrices, mais aussi plus combinables (et souvent optionnelles).
Les extensions de langage universellement utiles comme les interfaces de fonctions étrangères ne sont pas développées de manière formelle mais reposent sur des bibliothèques quasi-standard disponibles sur toutes les principales implémentations de Common Lisp.
Les idiomes de langage sont un mélange sauvage d'approches fonctionnelles, impératives et orientées objets, et en général, Common Lisp semble plus être un langage impératif qu'un fonctionnel. Il est également extrêmement dynamique, sans doute plus que la plupart des langages de script dynamiques populaires (la redéfinition de classe s'applique aux instances existantes, par exemple, et le système de gestion des conditions intègre directement l'interactivité), et la programmation interactive et exploratoire est une partie importante de "la voie de Common Lisp". Cela se reflète également dans les environnements de programmation disponibles pour Common Lisp, pratiquement tous offrant une sorte d'interaction directe avec le compilateur Lisp en cours d'exécution.
Common Lisp dispose d'un système d'objet intégré (CLOS), d'un système de gestion des conditions nettement plus puissant que la simple gestion des exceptions, de la patchabilité en temps d'exécution, et de divers types de structures de données et d'utilitaires intégrés (y compris le tristement célèbre LOOP macro, un mécanisme d'itération beaucoup trop laid pour Scheme mais beaucoup trop utile pour ne pas en parler, ainsi qu'un mécanisme de formatage semblable à printf avec un support GOTO dans les chaînes de format).
En raison du développement interactif basé sur l'image et de la plus grande complexité du langage, les implémentations de Lisp sont généralement moins portables entre les systèmes d'exploitation que les implémentations de Scheme. Faire tourner un Common Lisp sur un appareil embarqué n'est pas pour les âmes sensibles, par exemple. De même que la machine virtuelle Java, vous avez tendance à rencontrer des problèmes sur des machines où la mémoire virtuelle est limitée (comme les serveurs virtuels basés sur OpenVZ). Les implémentations de Scheme, en revanche, ont tendance à être plus compactes et portables. La qualité croissante de l'implémentation ECL a en partie atténué ce point, bien que son essence reste vraie.
Si vous recherchez un support commercial, il existe quelques entreprises qui proposent leurs propres implémentations de Common Lisp, y compris des constructeurs d'interfaces graphiques GUI, des systèmes de bases de données spécialisés, etc.
En résumé, Scheme est un langage plus élégamment conçu. C'est principalement un langage fonctionnel avec quelques fonctionnalités dynamiques. Ses implémentations représentent divers dialectes incompatibles avec des caractéristiques distinctives. Les dialectes de Scheme ont tendance à être plus statiques et moins interactifs que Common Lisp; les implémentations de Common Lisp sont généralement plus lourdes et plus complexes à installer.
Peu importe le langage que vous choisissez, je vous souhaite beaucoup de plaisir! :)
