IronScheme est-il suffisamment complet ou suffisamment stable pour mériter d'être étudié?

IronScheme est mentionné sur Wikipédia en tant que successeur d'un projet échoué appelé IronLisp, apportant Lisp à CLR et .NET, comme Clojure le fait pour la JVM. Quelqu'un a-t-il de l'expérience avec cette langue? Il semble assez complet (99%), mais je ne sais pas comment juger si cela vaut la peine de jouer pour le configurer ou non. Par stable ou complet, je veux dire l'utiliser pour des projets réels plutôt que de simplement jouer avec des outils et des problèmes de style Project Euler.

Je suis l'auteur d'IronScheme. Je ne sais pas vraiment comment répondre à votre question, mais j'essaierai :)

IronScheme essaie tout d'abord d'implémenter Scheme (R6RS en particulier), l'objectif secondaire étant l'interopérabilité CLR.

Comparé à Clojure (en se concentrant sur leurs mauvais points), IronScheme ne:

• vous donner des exceptions d'exécution CLR; IronScheme utilise la gestion des exceptions de Scheme
• vous donnent des traces de pile «infinies»; IronScheme est correctement récursif
• être difficile à configurer; il suffit d'extraire dans le répertoire et d'aller
• mettre longtemps à démarrer; IronScheme (quand ngen'd) ne prend que 0,1 seconde pour démarrer le REPL
• être ambigu; IronScheme implémente une spécification standardisée

Malheureusement, où Clojure gagne est:

• Documentation
• Cadres et bibliothèques
• Communauté d'utilisateurs

C'est inquiétant pour IronScheme, car les 3 derniers mentionnés sont en grande partie un scénario d'oeuf de poule. Personnellement, j'ai tendance à créer des bibliothèques uniquement lorsque j'en ai besoin, et avec une très petite communauté d'utilisateurs, il n'y a pas beaucoup de contribution des utilisateurs à part les rapports de bogues. J'aimerais une plus grande communauté d'utilisateurs.

En ce qui concerne le support, j'aide normalement les utilisateurs le plus rapidement possible. Cette preuve peut être vue à partir de mes temps de réponse sur les forums de discussion IronScheme. De plus, les bogues sont normalement corrigés dès qu'ils ont été identifiés.

En ce qui concerne la stabilité, la base de code est assez mature, et actuellement seules les corrections de bogues et les optimisations sont les seuls ajouts de code.

En ce qui concerne la convivialité, si vous êtes familier avec le framework .NET, vous pouvez faire à peu près n'importe quoi avec IronScheme comme vous pouvez le faire avec n'importe quel autre langage .NET; cela peut être plus difficile ou plus facile selon la quantité que vous êtes prêt à résumer en des idiomes plus similaires à Scheme. Les choses sont très faciles à écrire dans IronScheme; par exemple, tout mon framework MVC est à peine 400 lignes de code Scheme, grâce à puiser dans ASP.NET (je n'aime certainement pas réinventer la roue).

N'hésitez pas à demander des éclaircissements si la réponse n'est pas suffisante. Demian fait également de bons arguments en termes de maintenabilité.

Cordialement

leppie

Remarque: Je n'ai pas d'expérience avec IronScheme, alors prenez mes pensées avec un grain de sel (bien qu'il soit davantage axé sur l'utilisation de la technologie de pointe).

Bien que je joue avec une nouvelle technologie avec des problèmes triviaux (outils personnels, Project Euler, etc.), je suis très prudent d'utiliser cette technologie dans des projets à part entière. Pourquoi?

• Soutien communautaire: de qui obtiendrez-vous de l'aide lorsque vous heurtez un mur?
• Problèmes imprévus: si la technologie n'a pas été minutieusement testée au combat, est-ce que je veux vraiment fouiller dans le code de la bibliothèque pour essayer de trouver une solution à un problème qui n'a peut-être pas été rencontré? Si je voulais faire partie de l'équipe de validation, alors peut-être, mais 99% du temps, je veux juste faire mon projet et ne pas avoir à me soucier de la plomberie.
• Engagement de l'équipe: que se passe-t-il si celui qui dirige le projet débranche la prise? Mes projets sont alors orphelins, sauf si je souhaite reprendre le projet, pour lequel j'ai les mêmes problèmes que le point précédent.

Ainsi, bien que l'apprentissage des nouvelles technologies soit toujours une bonne chose (la pire chose qui puisse arriver est que vous appreniez comment quelqu'un d'autre implémenterait quelque chose - ce qui est bien), cela peut vraiment vous mordre dans le cul si vous l'adoptez tôt pour des projets complets .