¿IronScheme es lo suficientemente completo o estable como para que valga la pena aprenderlo?

IronScheme se menciona en Wikipedia como sucesor de un proyecto fallido llamado IronLisp, que lleva a Lisp a CLR y .NET, como lo hace Clojure para la JVM. ¿Alguien tiene experiencia con este idioma? Parece bastante completo (99%), pero no estoy seguro de cómo juzgar si vale la pena mi tiempo para configurarlo o no. Por estable o completo, me refiero a usarlo para proyectos reales en lugar de solo jugar con herramientas y problemas de estilo de Project Euler.

Soy el autor de IronScheme. No estoy realmente seguro de cómo responder a su pregunta, pero lo intentaré :)

IronScheme primero intenta implementar Scheme (R6RS específicamente), con el objetivo secundario de ser la interoperabilidad CLR.

En comparación con Clojure (enfocándose en sus puntos negativos), IronScheme no:

• darle excepciones de tiempo de ejecución CLR; IronScheme utiliza el manejo de excepciones de Scheme
• darle trazas de pila 'infinitas'; IronScheme es correctamente recursivo de cola
• ser difícil de configurar; simplemente extraer al directorio e ir
• tardan mucho en comenzar; IronScheme (cuando ngen'd) solo tarda 0.1 segundos en iniciar REPL
• ser ambiguo IronScheme implementa una especificación estandarizada

Lamentablemente, donde Clojure gana es:

• Documentación
• Marcos y bibliotecas
• Comunidad de usuarios

Esto es preocupante para IronScheme, ya que los últimos 3 mencionados son en gran medida un escenario de huevo de gallina. Personalmente, tiendo a crear solo bibliotecas cuando las necesito, y con una comunidad de usuarios muy pequeña, no hay mucha contribución de los usuarios además de los informes de errores. Me encantaría una comunidad de usuarios más grande.

En cuanto al soporte, normalmente ayudo a los usuarios lo más rápido que puedo. Esta evidencia se puede ver en mis tiempos de respuesta en los foros de discusión de IronScheme. Además, los errores normalmente se corrigen tan pronto como se han identificado.

En cuanto a la estabilidad, la base de código es bastante madura, y actualmente solo las correcciones de errores y las optimizaciones son las únicas adiciones de código.

En cuanto a la usabilidad, si está familiarizado con el marco .NET, puede hacer casi cualquier cosa con IronScheme como lo puede hacer con cualquier otro lenguaje .NET; puede ser más difícil o más fácil dependiendo de cuánto esté dispuesto a abstraer en expresiones idiomáticas más esquemas. Las cosas son muy fáciles de escribir en IronScheme; por ejemplo, mi marco MVC completo tiene apenas 400 líneas de código Scheme, gracias a aprovechar ASP.NET (ciertamente no me gusta reinventar la rueda).

No dude en pedir aclaraciones si la respuesta no es suficiente. Demian también hace buenos puntos en términos de mantenibilidad.

Saludos

leppie

Nota: No tengo experiencia con IronScheme, así que toma mis pensamientos con un grano de sal (aunque está más orientado al uso de tecnología de punta).

Aunque jugaré con nuevas tecnologías con problemas triviales (herramientas personales, Proyecto Euler, etc.), soy muy cauteloso de emplear dicha tecnología en proyectos completos. ¿Por qué?

• Apoyo comunitario: ¿de quién recibirá ayuda cuando golpee un muro?
• Problemas imprevistos: si la tecnología no se ha probado a fondo, ¿ realmente quiero profundizar en el código de la biblioteca para tratar de encontrar una solución a un problema que puede no haberse encontrado? Si quería formar parte del equipo de compromiso, tal vez, pero el 99% del tiempo solo quiero terminar mi proyecto y no tener que preocuparme por la tubería.
• Compromiso del equipo: ¿Qué sucede si quien dirige el proyecto desconecta? Mis proyectos quedan huérfanos, a menos que quiera asumir el proyecto, a lo que tengo los mismos problemas que el punto anterior.

Entonces, si bien aprender nueva tecnología siempre es algo bueno (lo peor que puede pasar es que aprendas cómo alguien más implementaría algo, lo cual es bueno), realmente puede morderte el culo si lo adoptas temprano para proyectos completos .