Nota: la siguiente publicación puede incluir opiniones controvertidas, así que tenga en cuenta que son solo mis opiniones y no tienen la intención de ofender a nadie.
Estoy programando de alguna forma u otra desde alrededor de 1999. Inicialmente usé R, y luego, alrededor de 2004, cambié principalmente a Python.
Para muchas aplicaciones científicas, por ejemplo, la simulación, que incluye cosas como MCMC, tanto R como Python son demasiado lentos y deben acelerarse. La forma habitual de hacerlo es mediante la extensión con C o C ++. Para R y Python, esto es lo que hice, usando la API de R de C con C ++ y la biblioteca Boost Python con Python.
Sin embargo, por varias razones, esta combinación no es la solución ideal. ¿Qué es importante en la programación, particularmente los algoritmos? Expresividad y velocidad, que por supuesto están relacionadas. Cuanto más expresivo es un idioma, más rápido se puede escribir en él.
1) En lo que respecta a la expresividad, ni R ni Python son realmente ideales para escribir algoritmos científicos en mi opinión. No se asignan de cerca al algoritmo subyacente. Sin embargo, ambos son considerablemente mejores que C ++.
2) Disfruto escribiendo en Python, que es un lenguaje agradable, aunque, como se señaló anteriormente, no es ideal para el trabajo algorítmico. Sin embargo, cuando uno tiene que trabajar con una combinación Python / C ++ debido a problemas de velocidad, esta mezcla se vuelve mucho menos agradable para trabajar. Lo que suele suceder es que primero escribo en Python, y una vez que tengo algo que funciona bien, a menudo descubro que es demasiado lento (por algún valor subjetivo de demasiado lento). Luego me enfrento a la decisión de pasar una cantidad de tiempo irrazonable reescribiéndola en C ++ o tolerar la lentitud. En retrospectiva, a menudo siento que podría haber sido mejor soportar la lentitud, especialmente porque las aceleraciones obtenidas son impredecibles. Además, la interfaz de Boost Python entre los dos es un dolor de cabeza de mantenimiento significativo, y tener código en dos idiomas muy diferentes pegados de esta manera es simplemente una distracción. No se pretende criticar a Boost Python, es una interfaz tan poderosa como uno podría imaginar, y prácticamente funciona la mayor parte del tiempo.
Ahora, en un mundo ideal, con tiempo y recursos ilimitados, ninguno de estos problemas sería un gran problema. Sin embargo, en proyectos científicos en los que he trabajado, he tenido la siguiente experiencia.
Ya sea que tenga o no colaboradores en el proyecto, siempre parezco terminar haciendo la gran mayoría de la informática. En un total de 5 proyectos importantes, solo tuve una participación sustancial de una persona en un proyecto. Esa persona hizo más que jalar su peso; hizo tanto como yo o más. Sin embargo, en todos los demás casos, incluidos los proyectos con múltiples colaboradores, he realizado (prácticamente) todo el trabajo computacional. Si bien puedo decir que no he sido bendecido con los mejores colaboradores (parece ser una mezcla de pereza e incompetencia), no tengo claro si es probable que este estado de cosas cambie en el futuro.
El trabajo científico computacional es un esfuerzo enorme, y si no puedo cambiar el comportamiento de mis colaboradores, puedo cambiar la forma en que trabajo. La mejora más importante sería hacer las cosas más rápido. Lo que me lleva a la consideración principal aquí, que es que cambiar los idiomas a algo menos ortodoxo puede ayudar. Según investigaciones anteriores, los candidatos más probables en orden de probabilidad son Common Lisp y Ocaml. He estado pensando en esto durante años, pero recientemente lo he estado pensando más en serio.
Por lo que puedo decir, pocas personas usan CL u Ocaml para el cálculo científico. Al buscar en este sitio, encontré dos referencias a CL (una era mía) y otra a Ocaml (mía). He tenido un par de contactos alentadores a lo largo de los años con personas aventureras que trabajan en la periferia. En 2008 me encontré con una crítica de libro de "Practical Common Lisp" de Peter Seibel (que yo poseo), de Tamas K. Papp. Esto me llamó la atención, ya que era una de las pocas menciones de computación científica para Lisp que había encontrado en la red. Le escribí a Tamas, quien inmediatamente respondió de manera útil y alentadora. Para citarlo
Mi productividad de programación probablemente se multiplicó por diez con Lisp, pero eso tardó alrededor de un año y todavía estoy aprendiendo (sin embargo, me fue bastante bien después de 2 meses). Entonces, si está trabajando en algo de tiempo crítico, posponga el cambio.
Debería considerar preguntarle a la gente por cll, no soy el único que sabe sobre estas cosas, otros hacen computación científica en Lisp.
También tiene un blog y una página de GitHub .
Otra persona con la que mantuve un breve contacto (en diciembre de 2006) fue Ira Kalet , quien ha usado Common Lisp en el contexto de la oncología de radiación.
Quizás hay otros que hacen computación científica en Lisp, pero no conozco a nadie.
El problema más común que la gente cita con CL es la falta de bibliotecas. Este es un problema grave en la informática de uso general, pero puede no serlo tanto en la informática científica, particularmente desde las implementaciones de algoritmos desde cero. Específicamente, puedo pasar la mayor parte del tiempo con una biblioteca matemática básica, que incluye funciones de distribución de probabilidad, una biblioteca de matriz multidimensional y un conjunto básico de contenedores, por ejemplo, mapa, conjunto, lista, etc., como se encuentra en las bibliotecas estándar de C ++ y Python.
Sé incluso menos sobre Ocaml que sobre CL, pero lo lancé como una alternativa. Supuestamente es muy rápido, tiene una implementación gratuita por parte de investigadores franceses y parece ser el más viable de la familia de lenguajes ML para computación científica.
Para concluir, me pregunto si otros tienen experiencia con esto, y qué pensamientos tienen, si los hay.
EDITAR: Estoy principalmente interesado en la experiencia de primera mano, en el contexto de los problemas que he discutido anteriormente. Por ejemplo, si solía usar Python y C ++ (o R y C ++) y se mudaba a un lenguaje más oscuro, estaría más interesado en escuchar sus experiencias.