IronScheme è abbastanza completo o abbastanza stabile da meritare di essere studiato?

Sono l'autore di IronScheme. Non sono sicuro di come rispondere alla tua domanda, ma proverò:)

IronScheme prima tenta di implementare Scheme (R6RS in particolare), con l'obiettivo secondario di interoperabilità CLR.

Rispetto a Clojure (concentrandosi sui loro punti negativi), IronScheme non lo farà:

• fornisce eccezioni di runtime CLR; IronScheme utilizza la gestione delle eccezioni di Scheme
• ti danno "infiniti" stacktraces; IronScheme è correttamente ricorsivo della coda
• essere difficile da configurare; basta estrarre nella directory e andare
• impiegare molto tempo per avviarsi; IronScheme (quando ngen'd) richiede solo 0,1 secondi per avviare REPL
• essere ambigui; IronScheme implementa una specifica standardizzata

Sfortunatamente dove vince Clojure è:

• Documentazione
• Framework e librerie
• Comunità di utenti

Questo è preoccupante per IronScheme, in quanto l'ultimo 3 menzionato è uno scenario da uova di gallina. Personalmente, tendo a creare librerie solo quando ne ho bisogno, e con una comunità di utenti molto piccola, non c'è molto contributo da parte degli utenti oltre alle segnalazioni di bug. Mi piacerebbe una community di utenti più grande.

Per quanto riguarda il supporto, di solito aiuto gli utenti il più velocemente possibile. Questa prova può essere vista dai miei tempi di risposta sulle tavole di discussione di IronScheme. Inoltre, i bug vengono normalmente risolti non appena sono stati identificati.

Per quanto riguarda la stabilità, il codebase è piuttosto maturo, e attualmente solo correzioni di bug e ottimizzazioni sono le uniche aggiunte al codice.

Per quanto riguarda l'usabilità, se hai familiarità con il framework .NET, puoi fare praticamente qualsiasi cosa con IronScheme come puoi con qualsiasi altro linguaggio .NET; potrebbe essere più difficile o più facile a seconda di quanto sei disposto ad astrarre in più idiomi simili a Scheme. Le cose sono molto facili da scrivere in IronScheme; per esempio il mio intero framework MVC è a malapena 400 linee di codice Scheme, grazie al contatto con ASP.NET (non mi piace certo reinventare la ruota).

Sentiti libero di chiedere chiarimenti se la risposta non è sufficiente. Demian è anche un buon punto in termini di manutenibilità.

Saluti

leppie

Nota: non ho esperienza con IronScheme, quindi prendi i miei pensieri con un pizzico di sale (anche se è indirizzato più sull'utilizzo di tecnologia all'avanguardia).

Mentre giocherò con la nuova tecnologia con problemi banali (strumenti personali, Project Euler, ecc.), sono molto cauto nell'usare tale tecnologia in progetti in piena regola. Perché?

• Supporto della comunità: da chi riceverai assistenza quando colpisci un muro?
• Problemi imprevisti: se la tecnologia non è stata testata in modo approfondito, desidero davvero voler scavare nel codice della libreria per cercare di trovare una soluzione a un problema che potrebbe non essere stato rilevato ? Se volevo far parte del team di commit, allora forse, ma il 99% delle volte voglio solo portare a termine il mio progetto e non dovermi preoccupare degli impianti idraulici.
• Impegno del team: cosa succede se qualcuno che dirige il progetto si spegne? I miei progetti sono quindi orfani, a meno che non voglia riprendere il progetto, al quale ho gli stessi problemi del punto precedente.

Quindi, mentre apprendere nuove tecnologie è sempre una buona cosa (la cosa peggiore che può succedere è che impari come qualcun altro implementerebbe qualcosa - che è buono) , può davvero farti venire il culo se lo adotti presto per progetti completi.