¿Por qué se usa Python para computación científica / de alto rendimiento (pero Ruby no)?

106

Hay una cita de una charla de PyCon 2011 que dice:

Al menos en nuestra tienda (Laboratorio Nacional de Argonne) tenemos tres idiomas aceptados para la informática científica. En este orden son C / C ++, Fortran en todos sus dialectos y Python. Notarás la falta absoluta y total de Ruby, Perl, Java.

Fue en el contexto más general de la informática de alto rendimiento. De acuerdo, la cita es solo de una tienda, pero otra pregunta sobre los idiomas para HPC , también enumera Python como uno para aprender (y no Ruby).

Ahora, puedo entender que C / C ++ y Fortran se usen en ese espacio problemático (y que Perl / Java no se use). Pero me sorprende que haya una gran diferencia en el uso de Python y Ruby para HPC, dado que son bastante similares. (Nota: soy fanático de Python, pero no tengo nada en contra de Ruby).

¿Hay alguna razón específica por la cual el idioma despegó? ¿Se trata de las bibliotecas disponibles? ¿Algunas características específicas del lenguaje? ¿La comunidad? ¿O tal vez solo contingencia histórica , y podría haber sido al revés?

Cíclope
fuente
2
Sugeriría que aunque ambos son lenguajes dinámicos, Python y Ruby son bastante diferentes. Más diferente que similar.
Adam Crossland
20
No sé si esta es una respuesta, pero recuerde que Python tuvo más "tracción" antes de que Ruby despegara fuera de una pequeña comunidad con Rails (circa 2005-2006). Google había estado usando Python durante un tiempo, lo que elevó su perfil (principios de la década de 2000). La sintaxis de Python es clara y fácil de aprender y leer (y recuerden que esto era en la época en que Perl era realmente la única otra opción importante), por lo que creo que eso empujó la computación científica hacia ella. Después de eso, probablemente fue un refuerzo personal, ya que las personas crearon NumPy / SciPy, MatPlotLib y muchos otros paquetes de computación científica.
wkl
44
Las personas interesadas en esta pregunta también están interesadas en visitar el sitio de intercambio de pila de Computational Science .
Mark Booth
2
"la legibilidad cuenta"
jsbueno
1
Para ofrecer una perspectiva de Química Computacional, es trivial paralelizar un cálculo con Python, y también barato. Quizás ambas cosas también sean ciertas en Ruby. No lo sé.
Jonathan Landrum el

Respuestas:

108

Ampliaré mi comentario.

Creo que hay algunos factores que influyeron en el uso de Python en la informática científica, aunque no creo que haya ningún punto histórico definitivo en el que se pueda decir: "Sí, esa es la razón por la cual Python se usa sobre Ruby / cualquier otra cosa". "

Historia temprana

Python y Ruby tienen aproximadamente la misma edad; según Wikipedia, Python se lanzó oficialmente por primera vez en 1991 y Ruby en 1995.

Sin embargo, Python llegó a la fama antes que Ruby, ya que Google ya estaba usando Python y estaba buscando desarrolladores de Python en el cambio de milenio. Como no es que tengamos una historia curada de usos de lenguajes de programación y sus influencias en las personas que los usan, teorizaré que esta adopción temprana de Python por parte de Google fue un gran motivador para las personas que buscan expandirse más allá de solo usar Matlab, C ++, Fortran, Stata, Mathematica, etc.

Es decir, quiero decir que Google estaba usando Python en un sistema donde tenían miles de máquinas (piense en paralelización y escala) y procesaba constantemente muchos millones de puntos de datos (nuevamente, escala).

Confluencia de eventos

La informática científica se hacía en máquinas especializadas como SGI y Crays (¿las recuerdas?), Y por supuesto FORTRAN fue (y sigue siendo) ampliamente utilizado debido a su relativa simplicidad y porque podría optimizarse más fácilmente.

En la última década más o menos, el hardware básico (lo que significa cosas que usted o yo podemos pagar sin ser millonarios) se ha hecho cargo del ámbito informático científico y masivo. Mire las 500 clasificaciones actuales : muchas de las 'supercomputadoras' mejor clasificadas del mundo están construidas con hardware Intel / AMD normal.

Python llegó en un buen momento ya que, nuevamente, Google estaba promocionando Python, y Google estaba usando hardware básico, y tenían miles de máquinas.

Además, si profundizas en algunos viejos artículos de computación científica, comenzaron a surgir alrededor de la era del 2000.

Soporte anterior

Aquí hay un artículo escrito para el Software y Sistemas de Análisis de Datos Astronómicos , escrito en 2000, que sugiere Python como un lenguaje para la computación científica.

El artículo tiene esta cita sobre Python:

Python es un lenguaje de programación orientado a objetos interpretado que está comenzando a recibir considerable atención en aplicaciones científicas (Python, 1999). Esto se debe a que Python, y los lenguajes de script en general, representan el siguiente paso lógico para muchos proyectos científicos (Dubois 1994). Primero, Python proporciona un lenguaje de programación interpretado que puede verse como una extensión de los lenguajes de comando simples que ya utilizan los programas científicos.

En segundo lugar, Python se integra fácilmente con el software escrito en otros idiomas. Como resultado, puede servir como un lenguaje de control para controlar los programas existentes, así como un lenguaje adhesivo para combinar diferentes sistemas. Finalmente, Python proporciona una gran colección de módulos de terceros, una base de usuarios establecida y una variedad de documentación en forma de libros y referencias en línea. Por esta razón, uno podría verlo como una versión altamente pulida y ampliada de lo que los científicos a menudo intentan lograr al escribir sus propios intérpretes de comandos.

Entonces puede ver que Python ya había tenido tracción desde finales de los 90, debido a que era funcionalmente similar a los sistemas existentes en ese momento, y porque era fácil integrar Python con cosas como C y los programas existentes. Con base en el contenido del artículo, Python ya estaba en uso científico desde el período de tiempo 1995-1996.

Diferencia en el crecimiento de la popularidad

La popularidad de Ruby explotó junto con el surgimiento de Ruby On Rails, que salió por primera vez en 2004. Estaba en la universidad cuando escuché por primera vez el rumor sobre Ruby, y eso fue alrededor de 2005-2006. django para Python se lanzó alrededor del mismo período de tiempo (julio de 2005 según Wiki), pero el enfoque de la comunidad Ruby parecía estar muy centrado en promover su uso en aplicaciones web.

Python, por otro lado, ya tenía bibliotecas que se ajustaban a la informática científica:

  • NumPy : NumPy comenzó oficialmente en 2005, pero las dos bibliotecas en las que se creó se lanzaron anteriormente: Numeric (1995) y Numarray (2001?)

  • BioPython - biblioteca de computación biológica para python, se remonta al 2001, al menos

  • SAGE : paquete matemático con el primer lanzamiento público a principios de 2005

Y muchos más, aunque no conozco muchas de sus líneas de tiempo (aparte de solo navegar por sus sitios de descarga), pero Python también tiene SciPy (construido en NumPy, lanzado en 2006), tenía enlaces con R (el lenguaje de estadísticas) en A principios de la década de 2000, obtuve MatPlotLib, y también obtuve un entorno de shell realmente poderoso en ipython.

ipython se lanzó por primera vez a principios de la década de 2000, y se le han agregado muchas características que lo hacen muy bueno para la computación científica, como el gráfico integrado matplotlib y la capacidad de administrar clústeres computacionales .

Del artículo anterior:

También vale la pena señalar varios otros proyectos de computación científica relacionados con Python. La extensión numérica de Python agrega manipulación rápida de matriz y matriz a Python (Dubois 1996), MMTK es un kit de herramientas basado en Python para modelado molecular (Hinsen 1999), el proyecto Biopython está desarrollando herramientas basadas en Python para la investigación en ciencias de la vida (Biopython 1999), y Visualization Toolkit (VTK) es un paquete de visualización avanzado con enlaces de Python (VTK, 1999). Además, los proyectos en curso en la comunidad de Python están desarrollando extensiones para el procesamiento y el trazado de imágenes. Finalmente, el trabajo presentado en (Greenfield, 2000) describe el uso de Python en proyectos en el STScI.

Buena lista de paquetes científicos y numéricos para Python .


Entonces, gran parte de esto se debe probablemente a la historia temprana y la relativa oscuridad de Ruby hasta la década de 2000, mientras que Python había ganado tracción gracias al evangelismo de Google.

Entonces, si estaba evaluando lenguajes de secuencias de comandos en el período de 1995 a 2000, ¿qué estaba mirando realmente? Estaba Perl, que probablemente era lo suficientemente diferente sintácticamente para que la gente no quisiera usarlo, y luego estaba Python, que tenía una sintaxis más clara y una mejor legibilidad.

Y sí, probablemente exista una gran cantidad de autorrefuerzo: Python ya tiene todas estas geniales y útiles bibliotecas para la informática científica, mientras que Ruby tiene una voz minoritaria que defiende su uso en la ciencia, y hay algunas bibliotecas que están surgiendo , como SciRuby , pero Las herramientas de Python han madurado en la última década.

La comunidad de Ruby en general parece estar mucho más interesada en promover Ruby como un lenguaje web, ya que eso es lo que realmente lo hizo bien conocido, mientras que Python comenzó en un camino diferente, y más tarde se convirtió en un lenguaje web.

wkl
fuente
8
Había olvidado un poco sobre la integración de c. En muchos casos, un cálculo científico es computacionalmente intensivo, y poder escribir una rutina de CA para ese bit es una ventaja importante.
Spencer Rathbun
1
@SpencerRathbun El artículo que relacioné menciona el uso de Python con SWIG para generar envoltorios y permitir que Python interopere con el código C / C ++. SWIG no obtuvo el soporte oficial de Ruby hasta Ruby 1.6, que se lanzó en 2004. Por lo tanto, Python ya tenía una ventaja importante, solo compartir y usar herramientas adecuadas para permitir a las personas atornillar Python a sus sistemas existentes. No tener que deshacerse de todo ese código FORTRAN / C optimizado existente que estaba en uso fue probablemente el mayor impulsor.
wkl
3
En 1991 estábamos usando TCL para unir bibliotecas numéricas como una forma de analizar datos sin tener que escribir masas de C / Fortran. Python llegó en el momento justo para reemplazar a TCL. La facilidad de interactuar con 'C' (y por F2C con fortran) fue el gran problema en comparación con PERL, la interfaz TCL con 'C' fue muy fácil
Martin Beckett
Los procesos de apego preferenciales explican mucho sobre qué idiomas se utilizan. ¡Es Zipfian! Ver El Zipf Myatery "PAP" se explica a las 12:50 en él.
radarbob
37

He usado Python ampliamente para aplicaciones de ingeniería y Ruby para aplicaciones web.

El problema que veo con Ruby como lenguaje científico es que hay demasiadas opciones de sintaxis para una operación determinada.

Python está diseñado con la siguiente premisa "Debe haber una, y preferiblemente solo una, forma obvia de hacerlo". Esto hace que sea MUCHO más fácil leer el código de alguien y determinar su intención. Esta es la clave para las revisiones por pares para ingeniería, etc.

Me gusta Ruby y es genial para ciertas tareas, pero mi código Ruby podría ser sintácticamente completamente diferente al código de un programador diferente que hace exactamente lo mismo. Esto causa demasiada ambigüedad en un entorno científico o de ingeniería.

Joshua Shreve
fuente
3
Si de hecho. Ruby está en la tradición de TIMTOWTDI y, por lo tanto, es un Perl un poco mejor. El software está escrito para programadores. Los compiladores / intérpretes son, en ese sentido, una audiencia secundaria. Los científicos tienden a tomarse en serio la tarea de realizar su trabajo sin demasiada interferencia de software innecesariamente difícil. QED
Dominic Cronin
44
No estoy seguro de seguir este argumento. Si el programador y no una máquina es la audiencia principal, hay momentos en que redactar las cosas de manera diferente mejora la claridad y resalta la intención. ¿Un lenguaje más flexible no ayuda a la comprensión de nuestros cerebros humanos suaves?
Andrew Vit
10
Pero C también puede parecer una explosión en la Fábrica ASCII. Recuerde que en C, una matriz es una máscara alrededor de punteros. Por lo tanto, la matriz [5] puede escribirse alternativamente como * (matriz + 5), que también puede escribirse como * (5 + matriz), que también puede escribirse como 5 [matriz]. Lo cual es estúpido.
Jonathan Landrum el
1
Soy un programador de Perl a muy largo plazo, y sigue siendo mi idioma favorito para la mayoría de los propósitos. Sin embargo, no estoy seguro de las matemáticas. No estoy de acuerdo con esta actitud con respecto al enfoque TIMTOWTDI. Tener muchos enfoques disponibles no significa que todos sean buenos, por supuesto, pero es importante poder adaptar su expresión para que se mapee clara y directamente a la idea que está expresando, tanto para su audiencia humana como para la máquina. La falta de opciones sintácticas no ayuda a eso.
mc0e
@ AndrewVit: No necesariamente. TIMTOWTDI funciona muy bien si tiene un desarrollador, o si tiene un pequeño equipo de desarrolladores estrechamente integrado. Pero tan pronto como tenga personas que nunca se hayan reunido trabajando en el mismo código, comenzará a preguntarse "Oh, ¿por qué lo harían de esa manera?" O, alternativamente, escribirás una guía de estilo para obligar a todos a hacerlo de la misma manera, y luego ya no estarás haciendo TIMTOWTDI.
Kevin
17

En una conjetura, una gran parte de ella sería la dependencia de MATLAB por un montón de investigadores. Python tiene alternativas, como la salvia . Mientras que el rubí no, o al menos no hay obvios.

En segundo lugar, de acuerdo con las preguntas frecuentes de Ruby , Python está orientado tanto a los procedimientos como a los objetos, mientras que Ruby se disfraza como un lenguaje de procedimientos. Si está escribiendo un pequeño script para fines matemáticos, como lo que haría en matlab, el paradigma OO es un dolor de cabeza. No solo eso, sino que obliga a un salto conceptual lejos de los paradigmas funcionales / de procedimiento que usan los investigadores. Las matemáticas no son OO. Las matemáticas son funcionales, seguidas de procedimientos (piense en pruebas lógicas).

Finalmente, tenga en cuenta que las preguntas frecuentes de Ruby establecen que Ruby es más complejo que Python. La programación ocupa el segundo lugar para los investigadores, no primero como nosotros.

Spencer Rathbun
fuente
22
Creo que la cosa OO es un poco de arenque rojo. ¿Qué le importa a un investigador si la expresión 1 + 1envía el mensaje +al objeto 1? Eso no cambia la estructura de su programa en lo más mínimo.
sepp2k
1
@ sepp2k, creo que Spencer sugiere que Ruby requeriría que los científicos programen de manera diferente. No sé Ruby, pero suponiendo que tenía para crear objetos para escribir un programa en Ruby, Python, mientras que permite que los procedimientos - esto añadiría a la sobrecarga mental. No se concede mucho, pero para un no programador, cada trabajo extra sería una razón para usar otro idioma.
Cyclops
77
@ Cyclops entiendo lo que está sugiriendo. Estoy diciendo que está mal. El punto principal de la cita sobre Ruby disfrazado como un lenguaje de procedimiento es que no necesita estructurar su programa de una manera orientada a objetos. Si escribe algo como "2 + 2", está creando dos objetos Integer y está llamando a un método en uno (pasando el otro como argumento). Sin embargo, eso no hace que escribir "2 + 2" en ruby ​​requiera más esfuerzo que escribir "2 + 2" en otros idiomas.
sepp2k
55
Estoy con sepp2k, tampoco compro ese argumento. Algunos lenguajes, como Java, te imponen el paradigma OO, pero no así con Ruby. ¿Qué le impide escribir un programa puramente procesal o funcional en Ruby?
Mike Baranczak
2
@ Cyclops exactamente. Si bien Ruby puede pretender ser de procedimiento, en un contexto no trivial se encontrará con situaciones en las que el paradigma OO hace que el lenguaje funcione de cierta manera. Si no entiende o ignora eso, entonces no puede hacer lo que quiere o termina con un hack desordenado.
Spencer Rathbun
14

Cuando el BDFL (Guido van Rossum) escribió Python por primera vez, el objetivo era que fuera tan comprensible como el inglés simple (propuesta de financiamiento de DARPA) que eliminaría los errores de codificación comunes.

Un problema que es muy visible es el uso de sangría para delimitar bloques. En los lenguajes que tienen delimitadores de sentencias complejas explícitas (p. Ej., Llaves C, Pascal BEGIN / END), el espacio en blanco se contraería en un solo espacio antes de alimentar el código al lexer. Esto permitiría una gran variación en la forma en que se presenta el código.

Para los programadores profesionales esto no es un problema porque se han entrenado para manejarlo desde 30 o más horas a la semana de práctica.

Para otros profesionales donde la programación es una herramienta, este problema se convierte en un problema importante. Este grupo incluye matemáticos, físicos, químicos, ingenieros, etc.

Dado que Python reduce los errores para los programadores no profesionales, les permite pensar sobre el problema que están tratando de resolver y no tiene que lidiar tanto con la mecánica del lenguaje.

Este es un solo ejemplo de por qué es popular fuera de la profesión de programación. Hay otros ejemplos que se pueden usar para ilustrar el mismo punto, como las baterías incluidas, The Zen of Python ( import this), el uso del humor Monty Python, etc.

Lance Helsten
fuente
No puedo encontrar ninguna referencia a una disertación o programa de doctorado en el currículum o la lista de publicaciones de Guido . ¿Tienes una cita para eso? Esta entrevista solo dice que fue investigador en CWI.
M. Dudley
Me equivoqué totalmente en eso: había leído que él hizo una disertación al respecto, pero no hice la investigación adecuada al respecto. Encontré mi error después de haber escrito esta publicación, pero nunca hice la corrección aquí. Gracias.
Lance Helsten
5

Esta es una gran discusión aquí, creo que las publicaciones aquí realmente respondieron por qué Python es más popular en la comunidad científica. Sin embargo, hay algunos argumentos en contra de las ciencias del rubí:

  • Ruby puede codificarse más intuitivamente que Python (DSL, etc.): dados los paquetes correctos utilizados:

    compruebe bioruby: http://bioruby.org/ una reserva de secuencia puede ser simplemente: inversa, etc. si usa bases de datos: la API de enlace de base de datos ruby ​​es posiblemente mejor que python.

  • Ruby permite un mayor nivel de abstracciones al mismo tiempo que es conciso.

  • Mejor sistema de gestión de paquetes: las gemas de rubí son tan fáciles en comparación con: herramientas de configuración, pip, etc.

Sin embargo, la adopción de Ruby fue / es / será obstaculizada por su complejidad. Estoy pensando que Lisp es un lenguaje excelente / poderoso, pero ¿por qué no despegó como lenguaje general? La situación similar está aquí con el rubí: ¡hereda mucho poder del lisp, las charlas pequeñas y el perl !: pero solo una selección de personas realmente lo usará para obtener los beneficios. Al final, puede permanecer fuerte en ciertos nichos / áreas especiales (como el riel en la web, la marioneta en la configuración), es difícil para los 'no' programadores disfrutarlo por completo, pero podría ser un buen amigo del programador (vio alguna computadora los científicos disfrutan el lenguaje: http://www.cleveralgorithms.com/nature-inspired/index.html )

Alguna actualización más reciente: parece que Python ya está tomando el control del paisaje. Recientemente, libros como: http://www.amazon.com/Python-Data-Analysis-Wes-McKinney/dp/1449319793 y muchos otros libros (análisis de datos, aprendizaje automático, etc.) están escritos con Python como lenguaje utilizado . Si Ruby quiere ponerse al día, necesita algunos esfuerzos serios. Teniendo en cuenta matplotlib en python, es probable que pasen varios años para llevarlo al estado en el que se encuentra ahora. A menos que se realicen algunos esfuerzos serios en rubí, probablemente no pueda alcanzar la etapa de análisis de datos de python / computación científica en los próximos 2-3 años.

Isaac Pei
fuente
3

Después de usar Python para el análisis de datos durante un tiempo (proveniente de experiencias de trabajo con Ruby, Lua y R), el paquete numpy (y muchas bibliotecas científicas relacionadas) hace que sea 'posible' ejecutar un cálculo rápido (velocidad similar a C, como numpy está escrito / integrado con códigos C) con la facilidad de programación en python.

Numpy ha existido durante un tiempo, su disponibilidad ayudó a construir muchos otros paquetes científicos relacionados, como scipy, pandas ... etc. Sus excelentes herramientas hacen de python un gran ecosistema para la computación científica, mientras que en Ruby, una matriz similar más rápida La biblioteca de cálculo recién se está desarrollando (NMtrix: https://github.com/SciRuby/nmatrix ). Esta gran diferencia de tiempo hace que Python sea la opción obvia para la informática científica.

Ipstone
fuente
55
"Al final, Python es como el lenguaje de todos", deberá proporcionar una fuente para respaldar esto.
Walter
2

Me he estado preguntando lo mismo. Creo que es, como dijo Spencer Rathbun, debido al aspecto procesal de Python. Siendo yo mismo un "no programador", me parece hermoso la forma en que puede codificar en Ruby y el marco Rails es excelente para facilitar su uso. Sin embargo, cuando se codifica con fines científicos (matemáticas, biología, etc.), normalmente piensa en un lenguaje "matemático", es decir, no le importan las declaraciones como

Person.find_by_name 'Juanito'

pero te importa más

A = B*C + D

Así que creo que Ruby es poderoso porque muchas de sus características no se usarían en un programa científico. Es más fácil pensar en los procedimientos.

Juan Diego
fuente
0

Python tiene mejor soporte para matrices N-dimensionales con el paquete Numpy. No he visto nada similar para Ruby.

Python parece ser más rápido en la computación numérica / informática científica que he hecho. No tengo otra prueba que cuando escribí algoritmos similares en Python y Ruby, los algoritmos de Python se ejecutaron más rápido (YMMV).

Josh Petitt
fuente
2
Esto realmente no contribuye mucho a la discusión. La efectividad de Numpy ya está cubierta (en mayor detalle) en la respuesta aceptada . Su argumento de rendimiento sigue siendo poco convincente; No me gusta confiar en anécdotas cuando discutimos el desempeño histórico, especialmente cuando tales argumentos probablemente ya estén bien cubiertos con puntos de referencia confiables (bueno, más confiables que una anécdota sin contexto).
Brian
@Brian, de acuerdo.
Josh Petitt
@Brian, mi contribución específica fue el comentario sobre las matrices N-dimensionales. Este es el núcleo de lo que se basa Numpy, sí, pero no vi ninguna mención de matrices ND. Este es el núcleo del álgebra lineal y lo que Matlab y Numpy hacen bien. Ruby usa matrices como los programadores usan matrices, no como ingenieros y científicos usan matrices (es decir, matriz). Si cree que ayudaría, agregaré un comentario sobre las matrices ND a la respuesta aceptada.
Josh Petitt
@Brian, y aún mantengo mi comentario de que no he visto un buen soporte de matriz ND para Ruby para la informática científica.
Josh Petitt
0

Una razón es que Python tiene un buen soporte para usar / integrar / llamar a código C / C ++, mientras que Ruby no ofrece el mismo grado de integración. Esto significa que puede escribir los componentes de código de alto rendimiento en C / C ++, y luego usar Python (es decir, un lenguaje de alto nivel / más fácil de ver) para unir todo. Me imagino que esta es también una de las razones de su temprana adopción institucional por parte de Google.

david.barkhuizen
fuente
0

Creo que una de las principales razones por las que Python se hizo tan popular para la ciencia de datos fue por la cantidad de tiempo / esfuerzo (es decir, dinero) que pudimos ahorrar para extender nuestros scripts para una solución real (por ejemplo, un sistema de software). Con Python, podríamos construir más fácilmente una solución de sistema basada en el código que hemos escrito para la ciencia de datos.

Tengo experiencia en la búsqueda de un lenguaje de intérprete con esta función hace aproximadamente 15 años. En ese momento, Python fue elegido para ser el indicado, no porque sea el lenguaje perfecto para la ciencia de datos, sino porque era un lenguaje raro de OOP con un intérprete rápido / portátil que también era extensible para interactuar con otros lenguajes como C / C ++ / Java. A diferencia de hoy en día, esas fueron características excelentes pero raras para construir directamente soluciones a partir del código base ya implementado para la ciencia de datos.

El tiempo podría ser otro factor crítico para hacer un lenguaje de ciencia de datos. Hace 15 años, descubrimos que ya existían paquetes básicos como el numérico y el scipy para el cómputo numérico en Python, pero ni siquiera conocíamos la existencia de Ruby como lenguaje de programación. A fines de 2018, pude encontrar varios proyectos usando Ruby para la ciencia de datos. Tal vez 10 años después, uno podría preguntarse por qué Ruby es tan popular para la IA.

Tae-Sung Shin
fuente