Je suis étonné de la citation suivante dans le contexte d’un article "Pourquoi Scheme ?" : "Aujourd’hui on n’entend plus parler que de Python, dont Gérard Berry, toujours au congrès de la SIF, soulignait l’appartenance, avec ses cousins Perl, PHP et Javascript, à une famille de langages qui avaient jeté par-dessus bord les acquis de 50 ans de recherche en théorie et pratique des langages de programmation, par exemple par l’abandon de techniques de typage des données propres à éviter de nombreux bugs."

En effet, Scheme et Python partagent le principe d’un typage fort (l’usage de type inappropriés génèrent une erreur explicite et non un comportement aberrant), mais dynamique (détection à l’exécution et non à la compilation). Je situe ces deux langages dans la même catégorie à ce sujet. Des variantes certes (associative lists vs. dictionaries), mais rien de fondamentalement différent.

La principale lacune de Python comparée à Scheme concerne surtout les affectations/déclarations. Scheme est pointilleux à ce sujet. Ainsi, une déclaration et une affectation s’écrivent différemment : (set ! a 42) provoquera une erreur si la variable n’est pas déclarée préalablement... et la déclaration permet de définir une portée. Côté Python, c’est "perfectible" (deux niveaux de portée : toute la fonction ou globale, et dont une implicite... donc pas de détection d’erreur si on oublie un la fameuse déclaration "global" !).

Pour un niveau de programmation intermédiaire, on peut avoir aussi des différences. Ainsi, (map f l) retourne une liste en Scheme... alors que Python retourne un objet "map". C’est facile à convertir en liste, mais fait une idée de plus à enseigner. Avec du recul, l’idée de Python n’est pas bête... évaluation paresseuse comme sur Haskell mais inutile pédagogiquement.

Côté syntaxe, on a un modèle homogène côté Scheme, mais côté Python, même si la logique du langage est différente de la composition des structures de données, on a un modèle homogène (une ligne qui se termine par " :" est suivi d’un bloc indenté) qui ne devrait pas poser de problème d’apprentissage. Obliger l’élève à indenter est peut-être d’ailleurs bien vu pédagogiquement (et le professeur a la garantie d’avoir des devoirs identés !). Par ailleurs, autant, le côté "le programme est une structure de données" est important pour les auteurs de macros, je ne perçois pas l’intérêt pour un débutant qui sera à 10 lieux d’en créer.