Nota: il seguente post può contenere opinioni controverse, quindi tieni presente che sono solo mie opinioni e non intendono offendere nessuno.
Sto programmando in un modo o nell'altro dal 1999. Inizialmente ho usato R, e poi, intorno al 2004, sono passato principalmente a Python.
Per molte applicazioni scientifiche, ad esempio, la simulazione, incluse cose come MCMC, sia R che Python sono troppo lente e devono essere velocizzate. Il solito modo di farlo è estendere con C o C ++. Sia per R che per Python, questo è quello che ho fatto, usando l'API C di R con C ++ e la libreria Boost Python con Python.
Tuttavia, per vari motivi, questa combinazione non è la soluzione ideale. Cosa è importante nella programmazione, in particolare gli algoritmi? Espressività e velocità, che sono ovviamente correlate. Più una lingua è espressiva, più velocemente si può scrivere in essa.
1) Per quanto riguarda l'espressività, né R né Python sono davvero ideali per scrivere algoritmi scientifici a mio avviso. Non si associano strettamente all'algoritmo sottostante. Tuttavia, sono entrambi notevolmente migliori del C ++.
2) Mi piace scrivere in Python, che è un linguaggio piacevole, anche se come notato sopra non è l'ideale per il lavoro algoritmico. Tuttavia, quando si deve lavorare con una combinazione Python / C ++ a causa di problemi di velocità, questo mix diventa notevolmente meno piacevole con cui lavorare. Quello che succede di solito è che scrivo per la prima volta in Python, e una volta che ho qualcosa che funziona bene, spesso scopro che è troppo lento (per un valore soggettivo troppo lento). Devo quindi decidere se dedicare una quantità irragionevole di tempo a riscriverlo in C ++ o sopportare la lentezza. Con il senno di poi spesso sento che avrei potuto fare meglio a sopportare la lentezza, soprattutto perché gli speedups ottenuti sono imprevedibili. Inoltre, l'interfaccia Boost Python tra i due è un notevole mal di testa di manutenzione, e avere il codice in due lingue molto diverse incollate insieme in questo modo è solo fonte di distrazione. Nessuna critica al proposito di Boost Python, è un'interfaccia potente come si potrebbe immaginare, e praticamente funziona quasi sempre.
Ora, in un mondo ideale, con tempo e risorse illimitate, nessuno di questi problemi sarebbe un grosso problema. Tuttavia, in progetti scientifici a cui ho lavorato, ho avuto la seguente esperienza.
A prescindere dal fatto che io abbia o meno dei collaboratori nel progetto, mi sembra sempre di finire facendo la stragrande maggioranza dell'informatica. In un totale di 5 progetti significativi, ho avuto una partecipazione sostanziale da una sola persona a un progetto. Quella persona ha fatto più che tirare il suo peso; ha fatto tanto quanto me o più. Tuttavia, in tutti gli altri casi, compresi i progetti con più collaboratori, ho svolto (praticamente) tutto il lavoro di calcolo. Mentre posso dire di non essere stato benedetto con i migliori collaboratori (sembra essere un misto di pigrizia e incompetenza), non mi è chiaro se questo stato di cose possa cambiare in futuro.
Il lavoro scientifico computazionale è un enorme sforzo e, se non riesco a cambiare il comportamento dei miei collaboratori, posso cambiare il mio modo di lavorare. Il miglioramento più importante sarebbe quello di fare le cose più rapidamente. Il che mi porta alla considerazione principale qui, che può aiutare il passaggio dalle lingue a qualcosa di meno ortodosso. Sulla base di ricerche passate, i candidati più probabili in ordine di probabilità sono Common Lisp e Ocaml. Ci sto pensando da anni, ma recentemente ci ho pensato più seriamente.
Per quanto ne so, poche persone usano CL o Ocaml per il calcolo scientifico. Durante la ricerca di questo sito, ho trovato due riferimenti a CL (uno era mio) e uno a Ocaml (mio). Nel corso degli anni ho avuto un paio di contatti incoraggianti con persone avventurose che lavorano ai margini. Nel 2008 mi sono imbattuto in una recensione del libro "Practical Common Lisp" di Peter Seibel (che possiedo), di Tamas K. Papp. Ciò ha attirato la mia attenzione, poiché era una delle poche menzioni dell'informatica scientifica per Lisp che avevo trovato in rete. Ho scritto a Tamas, che ha immediatamente risposto in modo utile e incoraggiante. Per citare lui
La mia produttività di programmazione probabilmente è aumentata di dieci volte con Lisp, ma ci sono voluti circa un anno e sto ancora imparando (ma dopo 2 mesi stavo andando abbastanza bene). Quindi, se stai lavorando a qualcosa di critico in termini di tempo, rimanda il passaggio.
Dovresti considerare di chiedere alla gente di cll, non sono il solo a sapere queste cose, altri fanno calcoli scientifici su Lisp.
Ha anche un blog e una pagina GitHub .
Un'altra persona con cui ho avuto una breve corrispondenza (nel dicembre 2006) è stata Ira Kalet , che ha usato Common Lisp nel contesto dell'oncologia delle radiazioni.
Forse ci sono altri che fanno calcoli scientifici su Lisp, ma non conosco nessuno.
Il problema più comune che le persone citano con CL è la mancanza di librerie. Questo è un grave problema nell'informatica di uso generale, ma potrebbe non esserlo tanto nell'informatica scientifica, in particolare dalle implementazioni da zero degli algoritmi. In particolare, riesco a cavarmela per la maggior parte del tempo con una libreria matematica di base, tra cui funzioni di distribuzione di probabilità, una libreria di array multidimensionale e un set di contenitori di base, ad esempio mappa, set, elenco ecc., Come si trova nelle librerie standard C ++ e Python.
So ancora meno di Ocaml di quanto non faccia a proposito di CL, ma lo ho lanciato in alternativa. È presumibilmente molto veloce, ha un'implementazione gratuita da parte dei ricercatori francesi e sembra la più praticabile della famiglia di lingue ML per il calcolo scientifico.
Per concludere, mi chiedo se gli altri hanno esperienza con questo, e quali pensieri hanno, se ce ne sono.
EDIT: Sono principalmente interessato all'esperienza di prima mano, nel contesto delle questioni di cui ho discusso sopra. Ad esempio, se usavi Python e C ++ (o R e C ++) e passavi a un linguaggio più oscuro, sarei molto interessato a conoscere le tue esperienze.