¿La programación en Python es más rápida que en C, C ++ o Java? [cerrado]


27

Existe una creencia generalizada entre los que cuanto más dinámico y tipeado el lenguaje, más productivo será el programador. Guido van Rossum escribió sobre la productividad de la programación usando python en 1998 y al buscar en la web todavía veo personas haciendo referencia a esta afirmación exacta:

Sintácticamente, el código Python parece un pseudocódigo ejecutable. El desarrollo del programa usando Python es 5-10 veces más rápido que usando C / C ++, y 3-5 veces más rápido que usando Java. En muchos casos, un prototipo de una aplicación se puede escribir en Python sin escribir ningún código C / C ++ / Java. A menudo, el prototipo es suficientemente funcional y funciona lo suficientemente bien como para ser entregado como producto final, ahorrando un tiempo considerable de desarrollo. Otras veces, el prototipo se puede traducir en parte o en su totalidad a C ++ o Java; la naturaleza orientada a objetos de Python hace que la traducción sea un proceso sencillo.

¿Se ha evaluado adecuadamente este problema científicamente? Si no fuera por , ¿tal vez por los lenguajes de programación de hermanos como , o ?

No estoy buscando racionalizaciones, analogías o explicaciones de por qué podría ser difícil de responder, a menos que sea la opinión de investigadores o expertos la que se haya tomado el tiempo de analizar el problema.

Inicialmente hice esta pregunta a los escépticos . SE , y alguien sugirió que debería preguntarla aquí también.


25
Bueno, dado que ha restringido el conjunto de posibles respuestas, me atrevo a hacer un comentario haciendo otra pregunta que debería responderse primero (en mi humilde opinión): ¿Hay una métrica confiable y estable para medir la "productividad de un programador"?
Paul Michalik

1
@Paul Michalik: supongo que cualquier trabajo de investigación que analice la productividad tendrá una definición incluida (de lo contrario, sería muy difícil de medir). Entonces, si alguien hace referencia a la investigación, sería útil si incluyeran la definición en la respuesta. Probablemente haya (supongo) varias formas diferentes perfectamente aceptables para medir la productividad, tal vez "el tiempo que lleva pasar varias pruebas unitarias" sería una de ellas.
Kit Sunde

1
@Paul Michalik - Claro, pero ¿cuántas de las declaraciones que lees en libros, blogs, charlas y artículos de programadores se prueban empíricamente? Estoy seguro de que hay mejores o peores formas de medir la productividad. Por ejemplo. El "consumo / tiempo de café" probablemente sería peor que incluso las "líneas de código / tiempo" clásicas. Retendría mi opinión sobre las afirmaciones de productividad específicas que hemos visto y puedo argumentar los méritos en función de eso. Las afirmaciones de productividad tampoco son simplemente erróneas, estoy seguro de que las "líneas de código / tiempo" miden algo cuando las personas no intentan destruir la métrica.
Kit Sunde

1
Quizás te interese este artículo: citeseerx.ist.psu.edu/viewdoc/…
DistantEcho

1
@ChrisF - ¿Estás diciendo que esta pregunta no es aplicable a Programmers.SE? Ciertamente es para los escépticos, y parecía encajar aquí también. Tenía la impresión de que no debería hacerlo hasta que leí un comentario reciente de Robert Cartaino sobre esta pregunta: skeptics.stackexchange.com/q/1963/631 que esencialmente dice que está perfectamente bien si es de interés para ambas comunidades, y Solo lo hice después de que otro usuario me lo pidiera. Teniendo en cuenta que la pregunta es obtener votos positivos, parece que también es un interés para esta comunidad.
Kit Sunde

Respuestas:


17

El artículo 1 de Ousterhout sobre lenguajes de script sugiere que cuanto más alto sea el nivel de programación, más productivo será el programador. Si consideramos que, como dice Boehm 2 , el número de líneas que un programador puede escribir en un momento dado es constante y no depende del lenguaje o su tipo (bajo nivel, programación del sistema, secuencias de comandos), uno puede creer fácilmente la afirmación. La proporción de instrucciones por línea de código fuente resultante puede ser un orden de magnitud (o varios) mejor con los lenguajes de scripting que con los lenguajes de programación del sistema.

Como los lenguajes de secuencias de comandos dependen en gran medida de utilidades listas para usar para tareas comunes (por ejemplo, estructuras de datos, manipulación de cadenas), su uso principal generalmente es mejorar la productividad con el costo de una velocidad de ejecución más lenta al proporcionar una sintaxis que es fácil de aprender y eficiente para mantener programas con. No se recurre a un lenguaje de script cuando se necesita una velocidad de ejecución máxima.

[1]: JK Ousterhout, Scripting: Programación de nivel superior para el siglo XXI , Computadora (IEEE), 1998
[2]: B. Boehm, Economía de ingeniería de software , Prentice Hall, 1981


99
Si bien esta es una buena respuesta, no olvide que los lenguajes modernos sin scripting también tienden a incluir utilidades listas para usar que agilizan el desarrollo. C # viene a la mente. Cualquiera que sienta que Python viene con más utilidades predefinidas que C # simplemente conoce Python mejor que C #. En realidad, ambos tienen una amplia y comparable gama de utilidades "incorporadas".
Roman Starkov

@romkyns, para cualquier proyecto no trivial, necesita escribir mucho código. Incluso si tienes muchos ladrillos de Lego, los Bionicles no se unen mágicamente.

2
@Thor, pero realmente ayuda tener esos ladrillos de Lego por adelantado, en lugar de tener que construir primero un taladro de petróleo, una fábrica de plástico y una extrusora de bloques de lego.
Roman Starkov

2
tanto c ++ como Java tienen contenedores genéricos, y c ++ 11 tiene una lib estándar tan completa para algoritmos de clasificación e iteradores, etc. No estoy convencido de que alguien que programe python tenga una ventaja sustancial. Además, por mi parte, paso la mayor parte de mi tiempo de programación resolviendo qué es lo que tengo que hacer, no escribir. Así que creo que solo contar la cantidad de líneas que se necesitan para hacer una cosa no es un indicador claro de cuán rápido serías un programador en ese idioma.
Sam Redway

7

Si mide la productividad como "tiempo para escribir un programa simple específico", entonces depende mucho más de la experiencia del programador y la mente rápida que el lenguaje que realmente está evaluando al programador, no el lenguaje.

Creo que los concursos de códigos cronometrados indican que el lenguaje no importa realmente para ese tipo de tareas. No hay un idioma que gane tales desafíos más fácilmente que otros (al menos no si permite la relativa popularidad de los idiomas).

Si mide el rendimiento como "la efectividad del mejor programa" escrito en un idioma determinado, entonces es aún menos dependiente del idioma. Vea, por ejemplo, los resultados del concurso Galcon AI . El ganador está escrito en Lisp. La siguiente entrada de Lisp, sin embargo, ocupa el puesto # 280. ¿Qué nos dice esto sobre la idoneidad del lenguaje para escribir una gran inteligencia artificial de manera eficiente? En mi opinión, nada. Simplemente nos dice que a "bocsimacko" se le ocurrió e implementó los algoritmos más efectivos. Para el registro, el tiempo no fue un factor importante en este concurso: las personas tenían más de dos meses para desarrollar su código.

Por último, si mides el rendimiento como "costo a largo plazo de mantener un proyecto", entonces creo que estás en algo. Especialmente si contrata solo a las mejores personas para el trabajo y cuenta el costo en horas hombre en lugar de dólares. Tengo una fuerte opinión sobre qué idiomas son mejores para esto, pero al no tener pruebas sólidas para vincularlo, dejaré esta opinión. Quizás alguien más tenga enlaces para este tipo de actuación.


77
"Realmente estás evaluando al programador, no al lenguaje" - No si esto se hace realmente científicamente. Toma 100 programadores. Seleccione un proyecto general como "Escribir una aplicación de calendario con estos requisitos específicos". Los requisitos están vinculados a las pruebas unitarias automatizadas. 50 programadores escriben la aplicación en C ++, 50 en Python, seleccionados al azar para que los desarrolladores de calidad se desestimen de manera uniforme. Los resultados serían una puntuación que combina el tiempo promedio de finalización con el número de pruebas unitarias aprobadas. Compare el promedio de los resultados de Python con el promedio del resultado de C ++ y ... ¡CIENCIA!
Morgan Herlocker

2
@Prof Tal vez si obtienes mil de cada uno ... pero aún así, ¿cómo controlas el hecho de que solo las personas con una determinada mentalidad y cierto nivel de habilidad conocerán C ++?
Roman Starkov

puede hacer que su muestra solo se extraiga de personas que puedan pasar una prueba de competencia en C ++ y Python. Muchos de mis viejos profesores estaban haciendo estudios muy similares. También hace un par de suposiciones que otros han discutido aquí: programmers.stackexchange.com/q/73715/3792
Morgan Herlocker

6

http://page.mi.fu-berlin.de/prechelt/Biblio/jccpprtTR.pdf es uno de los pocos estudios que conozco que hizo una comparación directa real entre la productividad en varios idiomas. Es antiguo, pero vale la pena leerlo si encuentra interesante el tema. La comparación tiene varias deficiencias importantes sobre las cuales el artículo es muy honesto.

El resultado general es que los lenguajes de bajo nivel (por ejemplo, C, C ++) tardan más en escribir, pueden requerir mucha menos memoria y pueden ejecutarse mucho más rápido. Pero con muy alta variabilidad. Los lenguajes de secuencias de comandos de alto nivel tienden a tomar la mitad del tiempo de escritura y tienen menos variabilidad en el enfoque. En un grado inicialmente sorprendente, suele haber una forma obvia de hacer algo en un lenguaje de script.

Tenga en cuenta que todos los números de rendimiento para Java deben tomarse con un gran grano de sal: el papel se produjo en los años 90 antes de que las personas tuvieran mucha experiencia con Java y antes de que la JVM estuviera bien optimizada. Ambos factores deberían tener un impacto significativo.


1

Para decirlo en general, escribir un programa en Python generalmente será más rápido que escribir el mismo programa en C, C ++, Java.

También es probable que funcione más lento.

Hay, por supuesto, aplicaciones particulares para las cuales otros idiomas pueden ser más rápidos porque ciertas tareas involucradas son 'más nativas'.

Si bien no conozco ningún estudio para confirmar este aumento en la velocidad / productividad (como mencionó un comentarista, esto puede ser difícil de medir con precisión), ha habido una investigación directa sobre la expresividad del lenguaje.

Creo que hay algún mérito en la correlación entre la expresividad del lenguaje y la velocidad de programación. Simplemente imagine un patrón de iteración simple y cómo una comprensión de lista o de pitón forzada puede ser más sucinta. No solo se puede escribir inmediatamente más rápido, sino que también elimina las preocupaciones de errores fuera de uno, índices fuera de límites y otros problemas que pueden ralentizar significativamente el proceso de codificación.

Esto muestra una tabla de una estimación de las relaciones de expresividad de los idiomas. Si bien debe tomarse con un grano de sal, las notas a pie de página que menciona son muy valiosas.

http://en.wikipedia.org/wiki/Comparison_of_programming_languages#Expressiveness


-5

La última vez que usé Java (hace un tiempo, lo admito) tomó una pantalla llena de código para abrir y escribir en un archivo. Compare eso con un par de líneas en Python o Perl, y puede adivinar cuál es más rápido.

Obviamente, todos los idiomas tienen sus propias fortalezas y debilidades, pero para la mayoría de las tareas, Python será más rápido de escribir.


66
"se tomó una pantalla llena de código para abrir y escribir en un archivo": poner esto en una clase de servicio con dos métodos write()y read()como en el resto de su acceso a archivos de proyecto Java será lo más conciso en Python. Creo que su ejemplo es demasiado restringido para comparar Python y Java (aunque estoy de acuerdo en que Java tiende a ser más detallado).
Giorgio

Claro, pero Python, Perl y los lenguajes superiores generalmente han pensado en eso por adelantado, por lo que no necesita escribir las clases de utilidad (o no tantas). El uso de una clase de utilidad todavía lleva tiempo, y es un principio de código reutilizable que se aplica tanto a Java como a Python según lo que realmente esté haciendo.
wobbily_col

Esto supone que Java necesita entre 50 y 60 líneas de código solo para abrir y escribir un archivo. Esto simplemente no es correcto.
h22
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.