Portada
mis comunidades
otras secciones
#4:
#1 Estaría de acuerdo con que hay que aprender C, si todos los que estudian programación fuesen a dedicarse a la Informática, pero no es el caso. Hoy en día un médico interesado en analizar e interpretar datos sin utilizar los paquetes estadísticos tradicionales (y de pago), probablemente debiera conocer algo de R (con los problemas que indica el artículo) y más le valiera aprender Python. Lo mismo y con mayor razón, se puede aplicar a la mayoría de las Ciencias Sociales e Ingenierías. Si vas a trabajar directamente con Hardware, por cierto debes conocer C y Assembler, qué duda cabe. Pero si eres Ingeniero Agrónomo, más te vale pensar en términos de Python. Los Matemáticos también se sienten muy cómodos con Python. El motivo es que se trata de un lenguaje multiparadigma, que deja a todos contentos, luce como Pseudocódigo, por lo que permite centrarse en el algoritmo y no en la sintaxis del lenguaje. Puede emplearse en Programación Orientada a Objetos o en Programación Funcional.
Opino que es la mejor selección como primer lenguaje, mejor que Java o C++ y te permite pasar a C en cualquier momento que lo necesites. Sólo algunas de nuestras universidades se han dado por enteradas, espero que como siempre, no seamos los últimos en subir al tren.
Opino que es la mejor selección como primer lenguaje, mejor que Java o C++ y te permite pasar a C en cualquier momento que lo necesites. Sólo algunas de nuestras universidades se han dado por enteradas, espero que como siempre, no seamos los últimos en subir al tren.
#1:
Esto de los lenguajes de programación, es como todo, depende del contexto donde estés programando.
El lenguaje por excelencia es el c, ya que es el que se encuentra más cerca del nivel de máquina.
Yo soy programador en assembler, y me dedico a programar microprocesadores y microcontroladores, aunque también he programado en lenguajes de alto nivel esporádicamente.
El gran problema es siempre el control y manejo de las señales de I/O, y en lenguajes de alto nivel dependerá de las librerías (o API) disponibles y las implementaciones de hardware para poder manejar dichas señales, interrupciones, etc.
Aparte de eso, todos los lenguajes de cierto nivel son iguales (variables, arrays, control de bucles, tomas de decisión, etc.) con su sintaxis y sus peculiaridades, pero en el fondo son lo mismo. Vistos un par de ellos, puedes entender un tercero sin demasiados problemas.
Decir que un lenguaje se come a los otros, es como mínimo, un poco arriesgado.
El lenguaje por excelencia es el c, ya que es el que se encuentra más cerca del nivel de máquina.
Yo soy programador en assembler, y me dedico a programar microprocesadores y microcontroladores, aunque también he programado en lenguajes de alto nivel esporádicamente.
El gran problema es siempre el control y manejo de las señales de I/O, y en lenguajes de alto nivel dependerá de las librerías (o API) disponibles y las implementaciones de hardware para poder manejar dichas señales, interrupciones, etc.
Aparte de eso, todos los lenguajes de cierto nivel son iguales (variables, arrays, control de bucles, tomas de decisión, etc.) con su sintaxis y sus peculiaridades, pero en el fondo son lo mismo. Vistos un par de ellos, puedes entender un tercero sin demasiados problemas.
Decir que un lenguaje se come a los otros, es como mínimo, un poco arriesgado.
#15:
#2 #6 Pero vamos a ver, señores: "The homogenization of scientific computing..."
El artículo sólo se refiere al ámbito de programación científica (tipo MATLAB o R). Ahí entiendo que Python sí que puede llegar a dominar fácilmente, sobre todo comparando su precio con el de MATLAB.
Ahora, en cuanto a programación de bajo/medio nivel y para aplicaciones más generales o que requieran muy alta eficiencia, C/C++ son y seguirán siendo fundamentales... en mi opinión.
#2 Su CV me parece espectacular. Pero ojo, que es psicólogo, no Computer Scientist ni similar...
El artículo sólo se refiere al ámbito de programación científica (tipo MATLAB o R). Ahí entiendo que Python sí que puede llegar a dominar fácilmente, sobre todo comparando su precio con el de MATLAB.
Ahora, en cuanto a programación de bajo/medio nivel y para aplicaciones más generales o que requieran muy alta eficiencia, C/C++ son y seguirán siendo fundamentales... en mi opinión.
#2 Su CV me parece espectacular. Pero ojo, que es psicólogo, no Computer Scientist ni similar...
#6:
#2 Si, me parece muy bien su currículum y olé sus huevos, sin lugar a dudas.
Pero lo que yo estoy diciendo es muy diferente. Yo tampoco empecé ayer precisamente, he visto crecer lenguajes (y casi nacer) c, cobol, pascal, forth, basic y después C++, Ada, y la tira más para aparecer luego otros como php, phyton, ruby, java, y ya paro.
Y sigo defendiendo lo mismo, dependerá en el contexto donde se programe. Si lo hacemos en entornos PC con Internet (me es igual el S.O.) o lo hacemos en un lavavajillas. Y también dependerá del cometido del programa.
De todas formas sigo opinando que es muy arriesgado decir que python se come a los otros, es mi opinión, of course
Pero lo que yo estoy diciendo es muy diferente. Yo tampoco empecé ayer precisamente, he visto crecer lenguajes (y casi nacer) c, cobol, pascal, forth, basic y después C++, Ada, y la tira más para aparecer luego otros como php, phyton, ruby, java, y ya paro.
Y sigo defendiendo lo mismo, dependerá en el contexto donde se programe. Si lo hacemos en entornos PC con Internet (me es igual el S.O.) o lo hacemos en un lavavajillas. Y también dependerá del cometido del programa.
De todas formas sigo opinando que es muy arriesgado decir que python se come a los otros, es mi opinión, of course
#62:
#56 ¿Alguien me explica que hacen biólogos o psicólogos picando código?
A nivel científico, continuamente:
Análisis de datos, programación de experimentos (en el caso de los psicólogos: estímulos que tienen que aparecer exactamente en el momento indicado, según patrones decididos en función de reglas específicas, medición de respuestas con sus tiempos de reacción...), simulación de modelos matemáticos que representan la formalización de teorías para comprobar su ajuste a los datos...
Todo eso conlleva un montón de programación, lo malo es que:
1) la mayoría de nosotros somos autodidactas, aprendimos "por nuestra cuenta" y por tanto cogemos vicios, somos ineficientes, cometemos errores que a un programador de verdad le parecerían cómicos... Además de eso, sólo nos interesa aprender a nivel superficial, para resolver problemas concretos.
2) para cada una de esas tareas hay un lenguaje más adecuado que los otros. Para análisis de datos, R sin duda. Si quieres usar técnicas bayesianas, te tienes que ir a paquetes concretos que se combinen con R o MATLAB. ¿Quieres gráficos bonitos y exportables en algún formato que sirva para algo a un novato como yo? pues dale a R. Para programar experimentos, de nuevo combinaciones de MATLAB + paquetes específicos, o librerías de Python que sirven exactamente para cierto tipo de experimentos. Para simulaciones, depende: MATLAB o R + paquetes suele ser la mejor opción, pero he visto de todo.
Depende mucho de la tradición que lleve el laboratorio donde estés, pero por lo general nadie te libra de tener delante como mínimo dos lenguajes una vez al día. Si puedes pasarle la pelota a alguien que sepa, genial (por eso en muchos laboratorios hay un técnico que da soporte con estas cosas). Pero cuando no puedes hacerlo... Es una pesadilla. Si mañana me cambio de laboratorio, toca aprender de cero.
Sin duda, a los científicos (que no somos ingenieros) nos vendrían bien dos cosas:
1) que nos enseñen a programar antes, incluso en el bachillerato.
2) unificar: Python es imperfecto, pero si alguien que conoce el tema dice que puede servir como herramienta unificadora, a lo mejor es verdad. Yo no lo puedo saber, porque soy sólo un usuario, y no sé mucho del tema. Me limito a usar algunas de esas herramientas para mi trabajo. Nada más.
A nivel científico, continuamente:
Análisis de datos, programación de experimentos (en el caso de los psicólogos: estímulos que tienen que aparecer exactamente en el momento indicado, según patrones decididos en función de reglas específicas, medición de respuestas con sus tiempos de reacción...), simulación de modelos matemáticos que representan la formalización de teorías para comprobar su ajuste a los datos...
Todo eso conlleva un montón de programación, lo malo es que:
1) la mayoría de nosotros somos autodidactas, aprendimos "por nuestra cuenta" y por tanto cogemos vicios, somos ineficientes, cometemos errores que a un programador de verdad le parecerían cómicos... Además de eso, sólo nos interesa aprender a nivel superficial, para resolver problemas concretos.
2) para cada una de esas tareas hay un lenguaje más adecuado que los otros. Para análisis de datos, R sin duda. Si quieres usar técnicas bayesianas, te tienes que ir a paquetes concretos que se combinen con R o MATLAB. ¿Quieres gráficos bonitos y exportables en algún formato que sirva para algo a un novato como yo? pues dale a R. Para programar experimentos, de nuevo combinaciones de MATLAB + paquetes específicos, o librerías de Python que sirven exactamente para cierto tipo de experimentos. Para simulaciones, depende: MATLAB o R + paquetes suele ser la mejor opción, pero he visto de todo.
Depende mucho de la tradición que lleve el laboratorio donde estés, pero por lo general nadie te libra de tener delante como mínimo dos lenguajes una vez al día. Si puedes pasarle la pelota a alguien que sepa, genial (por eso en muchos laboratorios hay un técnico que da soporte con estas cosas). Pero cuando no puedes hacerlo... Es una pesadilla. Si mañana me cambio de laboratorio, toca aprender de cero.
Sin duda, a los científicos (que no somos ingenieros) nos vendrían bien dos cosas:
1) que nos enseñen a programar antes, incluso en el bachillerato.
2) unificar: Python es imperfecto, pero si alguien que conoce el tema dice que puede servir como herramienta unificadora, a lo mejor es verdad. Yo no lo puedo saber, porque soy sólo un usuario, y no sé mucho del tema. Me limito a usar algunas de esas herramientas para mi trabajo. Nada más.
#53:
Aquí todo el mundo está hablando de factores que pueden ser importantes pero no tienen mucho que ver con los argumentos que se exponen en el artículo. No se trata de encontrar el mejor lenguaje en cuanto a velocidad computacional, eficiencia, etc., sino del mejor lenguaje para satisfacer demandas muy concretas de gente que necesita programar con fines diferentes pero sin ser programadores. Cada lenguaje tiene su curva de aprendizaje, por ejemplo, y ése es un factor que muchos comentaristas están trivializando, como si todos fuéramos programadores y nos dedicásemos a ello 8h al día.
Pensad en un biólogo, en un psicólogo, cuyo trabajo consiste en hacer un experimento y acaban con una matriz de datos de 1000x1000 (por ejemplo). Esa persona tiene que aprender un lenguaje no con el objetivo de programar cualquier cosa que quiera, sino con el de meramente manejar y analizar los datos. Ahí, la elección podría ser R. Pero lleva tiempo aprenderlo.
Y entonces toca hacer otro experimento, y hay que programarlo (no analizar los datos: programar el experimento, es una tarea diferente). ¿Y en qué lenguaje? Pues tal vez MATLAB (que se aprende más rápido), o JS, o librerías de Python que están orientadas específicamente a ello... En cada equipo de investigación tienen su preferencia.
Al final tenemos a personas que no son programadores manejándose precariamente con 3 ó 4 lenguajes, uno para cada tarea. A mí me ha pasado mil veces equivocarme y ponerme a escribir código de R en un script de MATLAB, acabo mezclando todo... Y el autor sugiere que tal vez podríamos unificarlo todo... con Python. ¿No es el más eficiente en términos computacionales? Bueno, eso no es tan grave mientras sirva para lo que queremos. No tener que aprender (a medias) al menos 3 lenguajes para 3 cosas distintas.
Pensad en un biólogo, en un psicólogo, cuyo trabajo consiste en hacer un experimento y acaban con una matriz de datos de 1000x1000 (por ejemplo). Esa persona tiene que aprender un lenguaje no con el objetivo de programar cualquier cosa que quiera, sino con el de meramente manejar y analizar los datos. Ahí, la elección podría ser R. Pero lleva tiempo aprenderlo.
Y entonces toca hacer otro experimento, y hay que programarlo (no analizar los datos: programar el experimento, es una tarea diferente). ¿Y en qué lenguaje? Pues tal vez MATLAB (que se aprende más rápido), o JS, o librerías de Python que están orientadas específicamente a ello... En cada equipo de investigación tienen su preferencia.
Al final tenemos a personas que no son programadores manejándose precariamente con 3 ó 4 lenguajes, uno para cada tarea. A mí me ha pasado mil veces equivocarme y ponerme a escribir código de R en un script de MATLAB, acabo mezclando todo... Y el autor sugiere que tal vez podríamos unificarlo todo... con Python. ¿No es el más eficiente en términos computacionales? Bueno, eso no es tan grave mientras sirva para lo que queremos. No tener que aprender (a medias) al menos 3 lenguajes para 3 cosas distintas.
#2:
#1 Hombre, si te lees el artículo, yo creo que el que lo escribe sabe bastante bien de lo que está hablando. No lo dice por decir o porque tenga un pronto o esté embarazado. Se nota que ha pasado años y años "picando código" en diferentes lenguajes y es bastante bueno en lo que hace.
Te dejo con su CV que no parece el de alguien que empezó ayer en este mundillo:
http://www.talyarkoni.org/Yarkoni_cv.pdf
Te dejo con su CV que no parece el de alguien que empezó ayer en este mundillo:
http://www.talyarkoni.org/Yarkoni_cv.pdf
#13:
#7 En la gran mayoria de "algoritmos pesados de tratamiento de datos" el cuello de botella esta en la E/S de datos y no en los propios cálculos, por lo que la eficiencia de del lenguaje de programacion es prácticamente despreciable.
En los demás algoritmos (en los que el cuello de botella no está en la E/S) es cierto que Cpython es bastante lento. Pero ojo, lo es lento es la máquina virtual de Cpython, no el propio lenguaje en si, y con otras implementaciones tales como pypy se obtendrian mejoras de varios ordenes de magnitud.
En los demás algoritmos (en los que el cuello de botella no está en la E/S) es cierto que Cpython es bastante lento. Pero ojo, lo es lento es la máquina virtual de Cpython, no el propio lenguaje en si, y con otras implementaciones tales como pypy se obtendrian mejoras de varios ordenes de magnitud.
#10:
#1 Decir que todos los lenguajes son iguales es como decir que todos los idiomas son iguales porque tienen palabras para "rojo" "correr" y "vagina". Unos lenguajes son más expresivos que otros al realizar ciertas tareas. Es cierto que hay un conocimiento "genérico" que es lo que se denomina "saber programar", pero muchos lenguajes tienen características que se tarda tiempo en interiorizar y usar. Python es uno de ellos. Lo puedes usar como si fuera C, o Java, pero te pierdes lo bueno de Python si conoces "the python way".
Un saludo
Un saludo
#49:
No veo NINGUNA referencia x aquí al hecho de que (C)Python, al igual que Ruby y otros intérpretes con GIL (Global Interpreter Lock) sólo puede ejecutar un hilo de Python interpretado a la vez... A ver qué tal evoluciona el rendimiento del código de cálculo científico escrito en un sólo hilo cuando los procesadores de mañana tengan 64 o 128 núcleos y sólo se use uno de ellos...
De paso, un artículo interesante(ENG): http://www.toptal.com/python/why-are-there-so-many-pythons
#31 Amen! Yo vengo del mundo Java y lo tengo clarísimo (tip: en www.coursera.org hay un curso de programación reactiva en Scala dictado por Martin Odersky y los creadores de Akka), aunque creo que habrá que crear y aprenderse las extensiones reactivas eficientes para todos los lenguajes y plataformas mayoritarios.
De paso, un artículo interesante(ENG): http://www.toptal.com/python/why-are-there-so-many-pythons
#31 Amen! Yo vengo del mundo Java y lo tengo clarísimo (tip: en www.coursera.org hay un curso de programación reactiva en Scala dictado por Martin Odersky y los creadores de Akka), aunque creo que habrá que crear y aprenderse las extensiones reactivas eficientes para todos los lenguajes y plataformas mayoritarios.
#18:
#7 que tendrán que ver unas cosas y otras!
Un lenguaje no es mas que una abstraccion del lenguaje máquina. Lo ineficiente es las vueltas que tengas que dar para llegar a que la máquina haga su tarea. Python es C, y como bien dice #13, los problemas que tenga de rendimiento están directamente relacionados con el intérprete. Tambien has de tener en cuenta que quizás se pierda más tiempo no en la ejecución del código, sino en su desarrollo, y python ahí lleva una ventaja enorme por su alto reciclaje de código y su curva de aprendizaje.
Python está orientado al scripting, a la web y la portabilidad de código. C es un lenguaje de bajo nivel para propósito general y especializado en herramientas cercanas al nivel máquina, aplicaciones de alto rendimiento o que requieran una adaptación al hardware. Comparar dos lenguajes de propósitos diametralmente opuestos es inutil, más cuando resultan ser complementarios y compañeros perfectos uno del otro
Python es bueno por lo que dice su zen , o como dice #10 , the python way:
Hermoso es mejor que feo.
Explícito es mejor que implícito.
Simple es mejor que complejo.
Complejo es mejor que complicado.
Plano es mejor que anidado.
Disperso es mejor que denso.
La legibilidad cuenta.
Los casos especiales no son suficientemente especiales como para romper las reglas.
Aunque lo pragmático gana a la pureza.
Los errores nunca deberían dejarse pasar silenciosamente.
A menos que se silencien explícitamente.
Cuando te enfrentes a la ambigüedad, rechaza la tentación de adivinar.
Debería haber una — y preferiblemente sólo una — manera obvia de hacerlo.
Aunque puede que no sea obvia a primera vista a menos que seas holandés. (NT: Guido van Rossum es holandés)
Ahora es mejor que nunca.
Aunque muchas veces nunca es mejor que *ahora mismo*.
Si la implementación es difícil de explicar, es una mala idea.
Si la implementación es sencilla de explicar, puede que sea una buena idea.
Los espacios de nombres son una gran idea — ¡tengamos más de esas!
Un lenguaje no es mas que una abstraccion del lenguaje máquina. Lo ineficiente es las vueltas que tengas que dar para llegar a que la máquina haga su tarea. Python es C, y como bien dice #13, los problemas que tenga de rendimiento están directamente relacionados con el intérprete. Tambien has de tener en cuenta que quizás se pierda más tiempo no en la ejecución del código, sino en su desarrollo, y python ahí lleva una ventaja enorme por su alto reciclaje de código y su curva de aprendizaje.
Python está orientado al scripting, a la web y la portabilidad de código. C es un lenguaje de bajo nivel para propósito general y especializado en herramientas cercanas al nivel máquina, aplicaciones de alto rendimiento o que requieran una adaptación al hardware. Comparar dos lenguajes de propósitos diametralmente opuestos es inutil, más cuando resultan ser complementarios y compañeros perfectos uno del otro
Python es bueno por lo que dice su zen , o como dice #10 , the python way:
Hermoso es mejor que feo.
Explícito es mejor que implícito.
Simple es mejor que complejo.
Complejo es mejor que complicado.
Plano es mejor que anidado.
Disperso es mejor que denso.
La legibilidad cuenta.
Los casos especiales no son suficientemente especiales como para romper las reglas.
Aunque lo pragmático gana a la pureza.
Los errores nunca deberían dejarse pasar silenciosamente.
A menos que se silencien explícitamente.
Cuando te enfrentes a la ambigüedad, rechaza la tentación de adivinar.
Debería haber una — y preferiblemente sólo una — manera obvia de hacerlo.
Aunque puede que no sea obvia a primera vista a menos que seas holandés. (NT: Guido van Rossum es holandés)
Ahora es mejor que nunca.
Aunque muchas veces nunca es mejor que *ahora mismo*.
Si la implementación es difícil de explicar, es una mala idea.
Si la implementación es sencilla de explicar, puede que sea una buena idea.
Los espacios de nombres son una gran idea — ¡tengamos más de esas!
#16:
#1 C será el lenguaje por excelencia, pero en ciencia solo se usa en robótica y en visión artificial y no predominantemente.
Matlab, Python, R o Java se usan muchísimo más que C para computación científica, ya que es todo programación exploratoria, hacer las cosas rápidamente y para eso se usan lenguajes mucho más productivos y semánticos que C.
Matlab, Python, R o Java se usan muchísimo más que C para computación científica, ya que es todo programación exploratoria, hacer las cosas rápidamente y para eso se usan lenguajes mucho más productivos y semánticos que C.
Comentarios
#1 Estaría de acuerdo con que hay que aprender C, si todos los que estudian programación fuesen a dedicarse a la Informática, pero no es el caso. Hoy en día un médico interesado en analizar e interpretar datos sin utilizar los paquetes estadísticos tradicionales (y de pago), probablemente debiera conocer algo de R (con los problemas que indica el artículo) y más le valiera aprender Python. Lo mismo y con mayor razón, se puede aplicar a la mayoría de las Ciencias Sociales e Ingenierías. Si vas a trabajar directamente con Hardware, por cierto debes conocer C y Assembler, qué duda cabe. Pero si eres Ingeniero Agrónomo, más te vale pensar en términos de Python. Los Matemáticos también se sienten muy cómodos con Python. El motivo es que se trata de un lenguaje multiparadigma, que deja a todos contentos, luce como Pseudocódigo, por lo que permite centrarse en el algoritmo y no en la sintaxis del lenguaje. Puede emplearse en Programación Orientada a Objetos o en Programación Funcional.
Opino que es la mejor selección como primer lenguaje, mejor que Java o C++ y te permite pasar a C en cualquier momento que lo necesites. Sólo algunas de nuestras universidades se han dado por enteradas, espero que como siempre, no seamos los últimos en subir al tren.
Esto de los lenguajes de programación, es como todo, depende del contexto donde estés programando.
El lenguaje por excelencia es el c, ya que es el que se encuentra más cerca del nivel de máquina.
Yo soy programador en assembler, y me dedico a programar microprocesadores y microcontroladores, aunque también he programado en lenguajes de alto nivel esporádicamente.
El gran problema es siempre el control y manejo de las señales de I/O, y en lenguajes de alto nivel dependerá de las librerías (o API) disponibles y las implementaciones de hardware para poder manejar dichas señales, interrupciones, etc.
Aparte de eso, todos los lenguajes de cierto nivel son iguales (variables, arrays, control de bucles, tomas de decisión, etc.) con su sintaxis y sus peculiaridades, pero en el fondo son lo mismo. Vistos un par de ellos, puedes entender un tercero sin demasiados problemas.
Decir que un lenguaje se come a los otros, es como mínimo, un poco arriesgado.
#2 #6 Pero vamos a ver, señores: "The homogenization of scientific computing..."
El artículo sólo se refiere al ámbito de programación científica (tipo MATLAB o R). Ahí entiendo que Python sí que puede llegar a dominar fácilmente, sobre todo comparando su precio con el de MATLAB.
Ahora, en cuanto a programación de bajo/medio nivel y para aplicaciones más generales o que requieran muy alta eficiencia, C/C++ son y seguirán siendo fundamentales... en mi opinión.
#2 Su CV me parece espectacular. Pero ojo, que es psicólogo, no Computer Scientist ni similar...
#2 Si, me parece muy bien su currículum y olé sus huevos, sin lugar a dudas.
Pero lo que yo estoy diciendo es muy diferente. Yo tampoco empecé ayer precisamente, he visto crecer lenguajes (y casi nacer) c, cobol, pascal, forth, basic y después C++, Ada, y la tira más para aparecer luego otros como php, phyton, ruby, java, y ya paro.
Y sigo defendiendo lo mismo, dependerá en el contexto donde se programe. Si lo hacemos en entornos PC con Internet (me es igual el S.O.) o lo hacemos en un lavavajillas. Y también dependerá del cometido del programa.
De todas formas sigo opinando que es muy arriesgado decir que python se come a los otros, es mi opinión, of course
#1 Hombre, si te lees el artículo, yo creo que el que lo escribe sabe bastante bien de lo que está hablando. No lo dice por decir o porque tenga un pronto o esté embarazado. Se nota que ha pasado años y años "picando código" en diferentes lenguajes y es bastante bueno en lo que hace.
Te dejo con su CV que no parece el de alguien que empezó ayer en este mundillo:
http://www.talyarkoni.org/Yarkoni_cv.pdf
#7 En la gran mayoria de "algoritmos pesados de tratamiento de datos" el cuello de botella esta en la E/S de datos y no en los propios cálculos, por lo que la eficiencia de del lenguaje de programacion es prácticamente despreciable.
En los demás algoritmos (en los que el cuello de botella no está en la E/S) es cierto que Cpython es bastante lento. Pero ojo, lo es lento es la máquina virtual de Cpython, no el propio lenguaje en si, y con otras implementaciones tales como pypy se obtendrian mejoras de varios ordenes de magnitud.
#1 Decir que todos los lenguajes son iguales es como decir que todos los idiomas son iguales porque tienen palabras para "rojo" "correr" y "vagina". Unos lenguajes son más expresivos que otros al realizar ciertas tareas. Es cierto que hay un conocimiento "genérico" que es lo que se denomina "saber programar", pero muchos lenguajes tienen características que se tarda tiempo en interiorizar y usar. Python es uno de ellos. Lo puedes usar como si fuera C, o Java, pero te pierdes lo bueno de Python si conoces "the python way".
Un saludo
Aquí todo el mundo está hablando de factores que pueden ser importantes pero no tienen mucho que ver con los argumentos que se exponen en el artículo. No se trata de encontrar el mejor lenguaje en cuanto a velocidad computacional, eficiencia, etc., sino del mejor lenguaje para satisfacer demandas muy concretas de gente que necesita programar con fines diferentes pero sin ser programadores. Cada lenguaje tiene su curva de aprendizaje, por ejemplo, y ése es un factor que muchos comentaristas están trivializando, como si todos fuéramos programadores y nos dedicásemos a ello 8h al día.
Pensad en un biólogo, en un psicólogo, cuyo trabajo consiste en hacer un experimento y acaban con una matriz de datos de 1000x1000 (por ejemplo). Esa persona tiene que aprender un lenguaje no con el objetivo de programar cualquier cosa que quiera, sino con el de meramente manejar y analizar los datos. Ahí, la elección podría ser R. Pero lleva tiempo aprenderlo.
Y entonces toca hacer otro experimento, y hay que programarlo (no analizar los datos: programar el experimento, es una tarea diferente). ¿Y en qué lenguaje? Pues tal vez MATLAB (que se aprende más rápido), o JS, o librerías de Python que están orientadas específicamente a ello... En cada equipo de investigación tienen su preferencia.
Al final tenemos a personas que no son programadores manejándose precariamente con 3 ó 4 lenguajes, uno para cada tarea. A mí me ha pasado mil veces equivocarme y ponerme a escribir código de R en un script de MATLAB, acabo mezclando todo... Y el autor sugiere que tal vez podríamos unificarlo todo... con Python. ¿No es el más eficiente en términos computacionales? Bueno, eso no es tan grave mientras sirva para lo que queremos. No tener que aprender (a medias) al menos 3 lenguajes para 3 cosas distintas.
#56 ¿Alguien me explica que hacen biólogos o psicólogos picando código?
A nivel científico, continuamente:
Análisis de datos, programación de experimentos (en el caso de los psicólogos: estímulos que tienen que aparecer exactamente en el momento indicado, según patrones decididos en función de reglas específicas, medición de respuestas con sus tiempos de reacción...), simulación de modelos matemáticos que representan la formalización de teorías para comprobar su ajuste a los datos...
Todo eso conlleva un montón de programación, lo malo es que:
1) la mayoría de nosotros somos autodidactas, aprendimos "por nuestra cuenta" y por tanto cogemos vicios, somos ineficientes, cometemos errores que a un programador de verdad le parecerían cómicos... Además de eso, sólo nos interesa aprender a nivel superficial, para resolver problemas concretos.
2) para cada una de esas tareas hay un lenguaje más adecuado que los otros. Para análisis de datos, R sin duda. Si quieres usar técnicas bayesianas, te tienes que ir a paquetes concretos que se combinen con R o MATLAB. ¿Quieres gráficos bonitos y exportables en algún formato que sirva para algo a un novato como yo? pues dale a R. Para programar experimentos, de nuevo combinaciones de MATLAB + paquetes específicos, o librerías de Python que sirven exactamente para cierto tipo de experimentos. Para simulaciones, depende: MATLAB o R + paquetes suele ser la mejor opción, pero he visto de todo.
Depende mucho de la tradición que lleve el laboratorio donde estés, pero por lo general nadie te libra de tener delante como mínimo dos lenguajes una vez al día. Si puedes pasarle la pelota a alguien que sepa, genial (por eso en muchos laboratorios hay un técnico que da soporte con estas cosas). Pero cuando no puedes hacerlo... Es una pesadilla. Si mañana me cambio de laboratorio, toca aprender de cero.
Sin duda, a los científicos (que no somos ingenieros) nos vendrían bien dos cosas:
1) que nos enseñen a programar antes, incluso en el bachillerato.
2) unificar: Python es imperfecto, pero si alguien que conoce el tema dice que puede servir como herramienta unificadora, a lo mejor es verdad. Yo no lo puedo saber, porque soy sólo un usuario, y no sé mucho del tema. Me limito a usar algunas de esas herramientas para mi trabajo. Nada más.
#4 En la mía seguimos con Pascal
#7 que tendrán que ver unas cosas y otras!
Un lenguaje no es mas que una abstraccion del lenguaje máquina. Lo ineficiente es las vueltas que tengas que dar para llegar a que la máquina haga su tarea. Python es C, y como bien dice #13, los problemas que tenga de rendimiento están directamente relacionados con el intérprete. Tambien has de tener en cuenta que quizás se pierda más tiempo no en la ejecución del código, sino en su desarrollo, y python ahí lleva una ventaja enorme por su alto reciclaje de código y su curva de aprendizaje.
Python está orientado al scripting, a la web y la portabilidad de código. C es un lenguaje de bajo nivel para propósito general y especializado en herramientas cercanas al nivel máquina, aplicaciones de alto rendimiento o que requieran una adaptación al hardware. Comparar dos lenguajes de propósitos diametralmente opuestos es inutil, más cuando resultan ser complementarios y compañeros perfectos uno del otro
Python es bueno por lo que dice su zen , o como dice #10 , the python way:
Hermoso es mejor que feo.
Explícito es mejor que implícito.
Simple es mejor que complejo.
Complejo es mejor que complicado.
Plano es mejor que anidado.
Disperso es mejor que denso.
La legibilidad cuenta.
Los casos especiales no son suficientemente especiales como para romper las reglas.
Aunque lo pragmático gana a la pureza.
Los errores nunca deberían dejarse pasar silenciosamente.
A menos que se silencien explícitamente.
Cuando te enfrentes a la ambigüedad, rechaza la tentación de adivinar.
Debería haber una — y preferiblemente sólo una — manera obvia de hacerlo.
Aunque puede que no sea obvia a primera vista a menos que seas holandés. (NT: Guido van Rossum es holandés)
Ahora es mejor que nunca.
Aunque muchas veces nunca es mejor que *ahora mismo*.
Si la implementación es difícil de explicar, es una mala idea.
Si la implementación es sencilla de explicar, puede que sea una buena idea.
Los espacios de nombres son una gran idea — ¡tengamos más de esas!
#1 C será el lenguaje por excelencia, pero en ciencia solo se usa en robótica y en visión artificial y no predominantemente.
Matlab, Python, R o Java se usan muchísimo más que C para computación científica, ya que es todo programación exploratoria, hacer las cosas rápidamente y para eso se usan lenguajes mucho más productivos y semánticos que C.
#4 No confundas al personal. A nadie se le ocurriría escribirn un algoritmo pesado de tratamento de datos con Python, porque uno de los problemas de Python es que es terriblemente ineficiente; no llega al QBasic, pero casi.
Python sirve para llamar a funciones que ya están programas en "verdaderos" lenguajes de programación C o Fortran. Si no existiera SWIG, hoy Python sería un lenguaje exótico que solo lo utiliarían los frikis.
Python es un lenguaje que viene de perlas para escribir archivos de comandos en linux:
#!/usr/bin/env python
print 'Este es mi primer programa escrito en Python'
Ya sé que a nadie le importa, pero como comentar es gratis...
No veo NINGUNA referencia x aquí al hecho de que (C)Python, al igual que Ruby y otros intérpretes con GIL (Global Interpreter Lock) sólo puede ejecutar un hilo de Python interpretado a la vez... A ver qué tal evoluciona el rendimiento del código de cálculo científico escrito en un sólo hilo cuando los procesadores de mañana tengan 64 o 128 núcleos y sólo se use uno de ellos...
De paso, un artículo interesante(ENG): http://www.toptal.com/python/why-are-there-so-many-pythons
#31 Amen! Yo vengo del mundo Java y lo tengo clarísimo (tip: en www.coursera.org hay un curso de programación reactiva en Scala dictado por Martin Odersky y los creadores de Akka), aunque creo que habrá que crear y aprenderse las extensiones reactivas eficientes para todos los lenguajes y plataformas mayoritarios.
No tengo ni puta idea de lo que estáis hablando.
El mérito de Python es que está programado en C.
#11 perfectamente. Lo que describes es el equivalente a que exista la palabra "agua" en un idioma. Mejor aún, la palabra "mamá" (que se dice casi igual en todos los idiomas)
#52 Aún me pregunto como puede ser que una colectivo como el de los desarrolladores que se supone tan preparado nos dejemos llevar tanto por modas. Supongo que porque la industria del software se rige por más criterios que los técnicos.
También me llama la atención esa ley no escrita de la gente que se dedica a la programación que obliga a intentar demostrar todo lo que se sabe en cada comentario.
Dicho esto, en mi opinion (xD) lo que demuestra esta afirmación es que al final lo que hace imponerse un lenguaje es su ecosistema, y al facilidad para dar soluciones a los problemas con la misma herramienta extensiones mediante (también esto puede llevarnos a pensar que todo son clavos para el mismo martilo, pero vaya). De hecho casi se valora más desde un plano humano el utilizar un solo lenguaje.
El flame (necesitaba meter un anglicismo, estaba en el guión) sobre que lenguaje es mejor ya lo dejo para harina de otro costal, porque creo que es un tema aparte, que una tecnología se imponga en el uso no necesariamente implica que sea mejor, ni que no lo sea. Yo creo que aquí lo que habría que examinar es si X (Python en este caso) resuelte eficazmente los problemas que se presentan (hay veces en las que nos interesa valorar el procesamiento en paralelo, otras la escalaabilidad, otras las dos cosas, otras ninguna sino que se eficiente en sistemas embebidos, otras simplemente que sea fácil de usar... ) y de ser así si existe otra herramienta que lo haga de forma más eficiente.
#96 En ciertas ocasiones puede ser útil usar un experto en computación, como por ejemplo para implantar un sistema de gestión de datos que vaya a utilizarse durante largo tiempo, o para desarrollar un programa estable pensado para distribuirse abiertamente.
Sin embargo, casi siempre se trata de crear pequeños (y no tan pequeños) scripts y programas ad hoc a medida para distintas situaciones que te vas encontrando. No hay versiones discretas, porque el programa va cambiando a medida que lo necesitas. No sigues criterios de usabilidad, porque los únicos que lo vais a utilizar sois tú mismo y como mucho tus compañeros del grupo de investigación. No te molestas en crear una versión estable y bonita, porque has creado el programa para analizar esos datos en concreto y puede que nunca vuelvas a utilizar el mismo programa.
En muchas ocasiones la programación y el análisis de los datos están tan integrados y tan poco separados que utilizar a un experto en programación sería demasiado engorroso, ya que para nuestras necesidades se tarda menos en enseñar a un biólogo a programar lo suficiente que en enseñar a un programador suficiente biología.
la abstracción tiene un coste en rendimiento y en perdida de control mientras mas alto programes menos control tiene sobre la maquina y menos rendimiento puedes sacar de ella, ejemplo
una linea en XML --> J lineas en java --> J*M lineas en la maquina de java --> J*M*C lineas en C ---> J*M*C*Ma caracteres en código maquina .... donde aveces cada multiplicador puede llegar mucho mas que 20
sino mirad a los móviles que esta apunto de salir equipos de 8 núcleos, si el software final estuviera en C los móviles serian otro mundo, eso si no habría tantos programadores
ya que este abstracción existe por que con lenguajes mas alto nivel se ahorra tiempo y el tiempo es dinero, de echo en menos de una hora de programación haces en el móvil una brújula, o un nivel, o incluso haces que conecta el google maps con el GPS y te indica los lugares interesante de la zona, cual puedes monetizar
#1 Decir que Java y C se parecen es como decir que Hitler es clavado a Marx. De programar con orientación a objetos como Java a programar en C hay un mundo. Da la sensación que, aun siendo verdad que programas en assambler, en la vida has programado nada con orientación a objetos, si no no me lo explico.
#19 Sí, alguien que no conoce Python le pones un FOR contraido y lo va a entender por los cojones...
Y yo que siento es que nos estamos homogenizando a JavaScript (inclusive en el servidor con el node.js)
#63 ¿No sería lo suyo que alguien hiciera una herramienta visual para ese tipo de tareas, en el lenguaje X, en vez de que vosotros tengáis que picar cuando no tenéis preparación alguna del tema?
Si alguien se decide a hacerlo, con distribución gratuita y continuamente puesto al día... Lo cubriré de besos y ofreceré la mitad de mis riquezas.
En serio: esas herramientas existen en algunos ámbitos, por ejemplo en el análisis de datos tenemos programas estadísticos tipo SPSS, para programar experimentos tienes E-Prime (donde hay que picar muy poco código)... Pero en cuanto aprendes R, por ejemplo, te das cuenta de que con esos programas te estás metiendo tú solito en una jaula, pierdes flexibilidad y capacidad de hacer lo que tú necesitas y te limitas a unas pocas opciones a golpe de clic. Eso por no hablar de que es software de pago, y que si mañana me cambio de universidad y allí no tienen licencia de E-Prime probablemente estoy vendido
Si alguien hiciera una herramienta como la que describes, pero potente y con mucha flexibilidad... ¡Tendría exitazo! Nosotros sólo queremos que nuestro trabajo sea fácil.
#16 En telecomunicaciones también se utiliza C
Acaba de celebrarse la PyConES en Madrid el cual disponía de un track científico. Para el que esté interesado puede empezar por estas diapostivas de la mano@pybonacci que hacen un resumen fabuloso sobre este asunto.
Python + Ciencia =
El fin de semana estuve en la PyconES, un gran nivel de asistente y todo un conjunto de ponencias dedicadas al uso de Python en el mundo científico.
Personalmente utilizo Python+Django en el desarrollo profesional de aplicaciones. Son aplicaciones grandes, donde el trabajo en grupo es primordial, donde es importante tener un estilo unificado, donde la legibilidad cuenta.
Puede que otros lenguajes nos permitiesen ejecutar la aplicación en 0.009 segundos menos, pero creo que haríamos un flaco favor a nuestros clientes si por esa sobreoptimización nuestros clientes tuviesen que pagar la misma aplicación 3 o 5 veces más cara.
A todos nos suena aquello de que "La optimización prematura es la raíz de todos los males", ¿verdad? Pues elegir un lenguaje porqué es "más rápido" sin más es una optimización prematura. Python te permite centrarte en el problema a resolver, te permite explicar con código tu problema a otra persona y que además lo entienda, y es lo suficientemente rápido para la mayoría de los usos normales.
Para usos científicos Python te permite utilizar la misma expresividad y además conseguir rendimientos más que aceptables utilizando librerías optimizadas realizadas en otros lenguajes (C, C++, F77).
A la gente que lo utilizamos cada día nos encanta y estamos orgullosos de la comunidad. Todas las discusiones de rapidez C, C++, Java, .Net, que si no me gusta que me obliguen a identar, ... la verdad es que desde siempre me dan igual.
La realidad es tozuda, la gente utiliza Python porque le soluciona los problemas, las aplicaciones hechas en Python son los suficientemente rápidas, al final lo que los programadores Python queremos es hacer el trabajo y poder mantener las aplicaciones que realizamos. Lo seguiriemos haciendo mientras muchos estarán diciéndonos que serían capaces de hacer lo mismo en el lenguaje X en 20 nanosegundos menos.
#41 La indentación forzada es uno de los grandes defectos de Python.
#27 En python también se pueden agrupar varios comandos en una línea, usando «;» igual que en C. Lo de la indentación como regla al lenguaje creo que es una buena idea, por legibilidad y por la ventaja que conlleva para proyectos con más de un programador.
#27 Aparte no va a partes.
Resumen rápido (e igual inexacto) de lo que dice el tío (que no habla de que un lenguaje sea mejor que otro):
- Antes tenia que usar varios lenguajes dependiendo de lo que quisiera hacer (el tipo de problema)
- Era un rollo, hay que aprender y/o recordar cosas cada vez.
- No soy ingeniero informático, ni siquiera ingeniero, y solo habla de computación cientifica.
- Ahora Python tiene casi todas las librerias/wrappers necesarias para hacer gran cantidad de trabajo.
- El 95%-100% de lo que hacía lo puedo hacer con Python
- Ya no tengo que recordar/reaprender varios lenguajes diferentes, gano en productividad y en paz mental
- Hey, ¿no sería buena cada vez que tengo un nuevo problema ver si lo puedo hacer en Python y así no perder tiempo reaprendiendo cosas, haciendo wrappers para juntar varios lenguajes, etc.?
- Sé que hay a veces en las que no es conveniente (problemas particulares, necesidades especiales de eficiencia, etc.) ¡Pero sí ME sirve para el 95%-100% de mi trabajo!
- FIN
python está bien para hacer tus primeras aproximaciones a un problema, como calculadora avanzada digamos. Algo como matlab.
Pero para programas serios es una locura. Yo lo sufro dia a día. Donde esté C++...
Cada lenguaje está hecho para una cosa. Python empieza a englobar muchas cosas por su facilidad y comodidad pero nunca hay que olvidar que es para eso, para cosas sencillas.
#24 Tu programa sería más rápido, más eficiente y ocuparía menos memoria si usaras esta otra fórmula:
print "¡Hola mundo!"
#27 No pienses en cómo lo lees hoy, piensa en si lo entenderás de aquí a un par de años. Que lo mismo sí, pero a veces con códigos de hace una semana ya te pierdes, imagínate un par de años...
#23 node.js es un cáncer que habría que erradicar de la faz de la tierra. JavaScript debe quedarse en el lado del cliente, que ahí funciona muy bien.
El futuro en el lado de servidor está en Scala y la programación reactiva, sin ninguna duda: muy fuertemente tipado, oo (no orientado a prototipos como js), funcional, concurrente de serie... Visto el empuje que está teniendo el compilador, cada vez veo más probable que fagocite un buen trozo del pastel de Java.
Un dejavú más, lo he !
visto tantas veces, desde la tecnología Rushmore de Foxpro, hasta la explosión de Java o Sap, todos en su campo iban a ser los lenguajes definitivos. Todos los programadores cometen el mismo error de percepción, creen haber encontrado el lenguaje definitivo. Al final, es la evolución tecnológica y sus mil facetas la que marca el camino.
Por debajo de todo, c
Pues yo programo en Monty
Un titular como "X se come al resto de lenguajes" sólo podía venir de los Pythonitas...por qué no me sorprende
¿Alguien me explica que hacen biólogos o psicólogos picando código?
#62 No hacía falta un comentario tan largo, de verdad, pero gracias.
¿No sería lo suyo que alguien hiciera una herramienta visual para ese tipo de tareas, en el lenguaje X, en vez de que vosotros tengáis que picar cuando no tenéis preparación alguna del tema?
Por ejemplo, pocos informáticos conozco que tengan el atrevimiento de soltar la perla de que "X se come al resto de lenguajes".
#95 ¿No es mejor tener a un experto en ciencias de la computación en tu equipo para que haga esas labores?
A mí no se me ocurriría construir casas por mucho que sepa utilizar el Autocad...
Creo que va siendo hora de dejar de programar con tarjetas perforadas...
#0 Me ha gustado el artículo, muchas gracias. Llevo tiempo rumiando la idea de empezar a aprender a programar en Python en mi tiempo libre (no lo necesito para mi trabajo, pero me gusta programar, y nunca se sabe cuándo tu trabajo puede cambiar ni qué podría ser considerado un plus para conseguir un nuevo empleo). Este artículo creo que me ha dado el empujón definitivo. Gracias.
#63 No hacía falta un comentario tan largo, de verdad, pero gracias.
Es que además de contestarte me he ido por las ramas. Sorry.
Yo creo que una persona que no utiliza ningún lenguaje compilado en ningún contexto es una persona que en realidad "no sabe programar". En mi opinión, y esto va a sonar exagerado para muchos de vosotros, el boom de los lenguajes interpretados ha funcionado en los círculos de personas ignorantes los lenguajes compilados (total o parcialmente), entre los que se incluyen los profesores de universidades que se decantan por Python o Java: puedo decir que hay una gran mayoría de profesores que tienen un conocimiento superficial de C++, que ni siquiera dominan plantillas con cierta completitud, y lo digo por experiencia y observación.
Y es que hay una gran ventaja que no se puede obviar de lenguajes clásicos compilados, y es que los programas resultantes son más rápidos, siempre, sin excepción. Los lenguajes que proporcionan características extra como compilado al vuelo (Java, en bytecode), estrategias especiales de paso de parámetros (como Python) o los lenguajes funcionales puros con sus estrategias de evaluación pasivas y demás (como Haskell) pueden realizar decisivas en su competición con "otros lenguajes interpretados".
En el artículo que se cita, todos los lenguajes a los que Python está sustituyendo son otros lenguajes interpretados, aunque me sorprende su preferencia sobre MATLAB: la sintáxis de éste último para tratar con señales digitales (las imágenes también lo son), es mucho mejor. Y si se trata de coste/libertad, que se utilize GNU Octave, que es gratis y libre.
La única desventaja de los lenguajes compilados es la sintáxis, pero C++ (es mi ejemplo de referencia) está haciendo importantes esfuerzos en ésta dirección, en los últimos estándares.
Se mire como se mire, en cualquier aplicación científica la eficiencia es importante, y a C/C++ nadie los gana en eficiencia en tiempo de ejecución.
El problema viene cuando cualquiera que conozca un lenguaje de programación se cree que sabe programar, hasta tal punto con esos estas comunidades de programadores no informáticos (ingenieros industriales de diferentes áreas, matemáticos, telecos, psicólogos como en el ejemplo, y otros tipos de científicos), son las que empiezan a dominar ciertas áreas y son sus costumbres y preferencias las que dirigen "el mercado".
Y luego pasa lo que pasa: lo que empiezan siendo pequeñas aplicaciones para análisis de datos o "scripts recurrentes" acaban conviertiéndose con el tiempo en aplicaciones completas, con diseños horribles (aunque funcionen), imposibles de mantener, y no todo lo eficientes que podrían haber sido. Todo dirigido por la flojera y el desconocimiento.
Lo que debería ocurrir es que los no informáticos deleguen un poco más su trabajo a los informáticos programadores, y que sean ellos los que decidan cuando viene bien Python, cuando viene bien Octave o cuando viene bien C/C++.
MUAHAHAHAHAHA!!!
#51 Cualquier persona con conocimiento de matemáticas a un nivel de bachillerato, primero de ingeniería, puede entender una comprensión de listas:
i para todo i que pertenece a conjunto A -> [i for i in listaA]
La comprensión de listas es un ejemplo de expresividad del lenguaje.
#c-16" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2063449/order/16">#16 Depende del campo de la ciencia del que estemos hablando, no generalicemos tan rápido. En física de partículas, comsología y física teórica en general aún se usa bastante Fortran y, en su defecto, C++ o C#.
#1 Aparte de eso, todos los lenguajes de cierto nivel son iguales (variables, arrays, control de bucles, tomas de decisión, etc.) con su sintaxis y sus peculiaridades, pero en el fondo son lo mismo. Vistos un par de ellos, puedes entender un tercero sin demasiados problemas.
Pues no puedo estar más en desacuerdo.
#15 Estoy de acuerdo. En el ámbito de la computación científica, python es de lo mejorcito que hay. Igual que para otros ámbitos, son otros los lenguajes que se acomodan mejor. Por ejemplo cuando quieres hacer una buena interfaz gráfica, python empieza a cojear. No es que no se pueda, es que es más difícil que en otros lenguajes.
Lo bueno de python es que tiene una curva de aprendizaje bastante rápida, lo que ayuda a los que son científicos pero no han estudiado programación ni algoritmia. También es bastante intuitivo y tiene un sistema de importar paquetes muy potente. Creo que poca gente puede discutir eso.
Yo lo que estoy un poco harto es de esa gente que te quiere vender su lenguaje preferido por cojones, antes eran los de Java y ahora son los de Python.
#1 Todos iguales??? ja!
#20 Y añade Mecánica de Fluidos computacional (aerodinámica, combustión, climatología), simulación de los mecanismos de plegado de proteínas, etc...
Los que realizan supercomputación suelen ser C/C++/FORTRAN edulcorado con MPI/OpenMP y CUDA/OpenCL. Evidentemente Python es una herramienta muy útil, pero por cuestiones de rendimiento en las simulaciones muy costosas se emplean esos otros.
#41: El problema es que cada persona tiene sus ojos. Mis ojos no son los mismos que los del creador de Phyton, y lo que para el pueda ser fácil de leer, para mi podría ser difícil de leer.
Yo prefiero los códigos que visualmente son compactos, en cambio hay gente que ahí se perdería porque lo verían todo muy apelotonado.
En cambio si yo leo un código suyo (que para ellos es normal), a lo mejor me parece demasiado disperso y por eso me costaría leerlo.
#28: Mientras esté claro para ti, el código estará bien.
El problema de Phyton es que tienes que escribirlo como le gusta al autor de ese lenguaje, no como te gusta a ti.
En cambio en C te apañas como quieres.
Y Ruby on Rails sólo lo usan los programadores hipster
Por cierto, es un framework no un lenguaje de programación como creen muchos
#81, y por cierto ha sido un congreso excelente.
#63 #74 Es imposible crear una herramienta visual lo bastante flexible como para analizar los datos de cualquier experimento que le pongan por delante, para crear cualquier simulación a medida, o para programar cualquier pipeline bioinformático.
Para analizar unos pocos datos que no necesiten mucho tratamiento puedes usar SPSS o incluso Excel, para algunas simulaciones vale el SimuLink de Matlab, y para análisis bioinformáticos/genómicos quizá te baste con Galaxy si tus requisitos son lo bastante sencillos. Sin embargo, la ciencia experimental por definición está siempre empujando los límites y encontrándose con problemas nuevos que no se habían considerado antes, o se quiere analizar los datos mediante un proceso totalmente nuevo. También se puede necesitar integrar datos de múltiples aparatos en formatos distintos, o se quiere que los resultados se presenten en un formato gráfico totalmente personalizado.
Por eso muchos biólogos y otros científicos experimentales necesitan programar en el día a día, en R, Python, Perl o incluso Java. La programación no es sólo cosa de informáticos.
#4 Creo que lo has resumido muy bien. Depurar un programa en Python me resulta muy fácil. Es un lenguaje muy legible. Por el contrario los punteros de C son diabólicos. Cuando el programa no va y tienes que depurarlo los punteros te obligan a pensar en como se está generando el código y en la estructuración de la memoria para el código y para los distintos tipos de variables. Lo ideal es tener en la cabeza solo cosas relativas al problema que quieres resolver. La ventaja de C es que al ser muy cercano a la máquina genera un código muy rápido, pero con los procesadores actuales sobra velocidad para todo lo que no sea manejo de hardware a bajo nivel. Se trata de un nicho muy especializado.
#9 Sí, y haciendo módulos, que es peor
#1 Más allá de lo que cuenta el artículo, que se centra sobretodo en el uso que da al lenguaje, el tema, tal como lo veo, no es ese, es la "expresividad" del lenguaje.
Yo no tengo ninguna práctica desarrollando cosas a bajo nivel; conozco poco C o C++ en el sentido de estar habituado a ellos. Conozco la sintaxis, los paradigmas de programación imperativa y orientación a objetos, y algo de su librería estándar. Creo que es innegable que lenguajes de muy alto nivel como ruby y, sobretodo, python, son mucho más "expresivos". Java o PHP, los otros lenguajes que "conozco", son feos, más expresivos, pero feos.
Por expresivo entiendo que su sentido es autoexplicativo. C y C++, si no los conoces, no los "entiendes". Una persona puede no conocer python pero, si sabe programar, es muy probable que entienda lo que diga el lenguaje. Python es expresivo, elegante, sobretodo... hermoso!
#15 Aunque en mi trabajo no lo uso, por lo que veo en el despacho, el crecimiento de Python es una realidad. Todo el desarrollo de tratamiento de imágenes se está migrando de Matlab a Python.
Y hace poco hablando con un compañero, pequeñas tareas que antes realizaba con otras aplicaciones (compilaciones de latex, ejecuciones programadas como compilaciones con cada commit etc) están siendo migradas.
#2 Es un académico, y psicólogo. Decir que Python se está comiendo los demás lenguajes... se mire com se mire es una exageración. Puede que por ser accesible - fácil de aprender, fácil de leer, cantidad de librerías disponibles, y está instalado en casi cualquier linux que pilles - tiene ese "atractivo" en la comunidad científica. Pero está lejos de comerse a todos los lenguajes. Esto es como todo: dependiendo del ámbito, hay una corriente u otra. Si hablas de tecnologías web, hoy en día se podría decir que Javascript se está comiendo a todos los demás lenguajes. Si hablas de estadística y machine learning, quizás R. En muchos ámbitos están también resucitando los lisp... y así puedes seguir.
#8 Pascal? en serio?
Vamos a ver #10 escríbeme en python una función que retorne un entero como la suma de dos enteros pasados como argumentos a dicha función. Y después me dices si es muy diferente a escribir esa misma función en c o en basic, por ejemplo.
¿Comprendes donde quiero ir?
#1 Prueba prolog o lisp y verás que iguales son. En cuanto al artículo no creo que haya un lenguaje de propósito general como bien dices porque siempre habrá lenguajes más específicos donde sea mas fácil hacer según que cosas pero eso provoque que otras sean menos intuitivas
#56 Si me diesen un céntimo por cada vez que alguien me ha dicho que un lenguaje determinado es mejor que otro, seguramente ahora estaría en alguna isla paradisiaca, quemando dinero a tope, y pasando del tema. Como podrás deducir de mi comentario en #57, soy un firme creyente de que no hay un lenguaje que sea mejor en términos absolutos.
Y por cierto, vaya por delante que aunque en mi trayectoria profesional sobretodo he programado con PHP, soy un fan de Python. Y aún así reconozco que antes de decantarme por un lenguaje de programación, tengo saber en qué contexto se va a utilizar.
Y ya puestos esto es pascal
Que sí que te equivocas un montón al escribir y se tiene que arreglar palabras a diferencia de C u otros pero da un gusto de leer...
http://es.wikipedia.org/wiki/Pascal_%28lenguaje_de_programaci%C3%B3n%29
Aparte que con los modernos compiladores se puede insertar ensamblador directamente sin más. Contiene las instrucciones del Lisp empezando por Str... Con sintaxis pascal, claro. Las de la tortuga del Logo
más... de todo con delphi, kylix o el freepascal y lazarus
Por cierto el compilador del pascal/object pascal del delphi/kylix (ahora está en embarcadero) es más rápido claramente que el gcc
Y es cierto que es fácil equivocarse al usar casi inglés pero es prácticamente pseudocódigo fácil de leer para cualquier persona y se puede montar un S.O. completo con él como con C++ u otros. Con miles de instrucciones
En fin... No es el que más me toca trabajar pero sí el que más me gusta ver el código y me parece que era el ideal en GNU/linux para usarlo en lugar del VisualBasic/ .Net de windows para usuarios de carácter general
#2 Pues viendo el curriculum por encima se trata de un psicologo que utiliza lenguajes de programación para un area de investigación muy determinada. No lo veo para nada como una opinión a nivel general o de un experto en ingenieria del software o lenguajes.
Yo pienso que hay que saber adaptarse a casi cualquier lenguaje segun la aplicación en función de muchos factores, y generalmente si a nivel profesional es algo que no decides tu, si no que viene impuesto por el tipo de proyecto, la empresa, los gustos de tu jefe...
#4 Python tiene muchas virtudes, pero no ser el primer lenguaje que un informático debe aprender. Prefiero lenguajes fuertemente tipados que tienen errores de compilación, de linkado y de ejecución...
#c-84" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2063449/order/84">#84 En general estoy totalmente de acuerdo con tu post.
Pero algo que quería comentar (y paso de empezar a poner # a muchísimos comentarios, aunque se que aquí ya apenas se leera) es que Java NO ES TAN LENTO. Para el que no lo sepa aunque tenga maquina virtual, bytecode y etc. lo normal es que no se ejecute como código interpretado, sino que se usa el compilador JiT que compila directamente a código nativo (no me meto si hay optimizaciones para cada procesador, por familias o demás), otra cosa es que la compilación tarde más o menos.
El primer post que leí buscando en google: ¿Es java lento? http://codigocomestible.com/2010/03/29/java-es-lento/ (es del 2010) y lleva a comparativas como:
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=java
#84 Yo creo que una persona que no utiliza ningún lenguaje compilado en ningún contexto es una persona que en realidad "no sabe programar".
Que no haya encontrado el contexto en el cual la eficiencia de un lenguaje compilado sea un factor tan clave como el de obtener un resultado más rápidamente gracias a las facilidades de los interpretados lo descartamos entonces ¿no?
La única desventaja de los lenguajes compilados es la sintáxis...
Pues una de las sintaxis más "copiada" es la de C precisamente. Tengo la impresión de que te referirás a otra cosa
Se mire como se mire, en cualquier aplicación científica la eficiencia es importante, y a C/C++ nadie los gana en eficiencia en tiempo de ejecución.
¿Te suena de algo Ensamblador?
Lo que debería ocurrir es que los no informáticos deleguen un poco más su trabajo a los informáticos programadores...
Porque claro, en las universidades (por el caso que nos ocupa), los "informáticos" están siempre disponibles, al servicio de lo que requieran el resto de los departamentos, en su quehacer diario.
A ver si nos aclaramos. La gente que, no siendo propiamente informáticos, se ponen a programar, es porque lo necesitan para facilitar su trabajo diario. En ese sentido, prefieren lenguajes más "flexibles" en la forma de hacer las cosas, aunque pierdan en rendimiento. Cuando el rendimiento sea un requisito, tarde o temprano acabarán yendo a C o a Ensamblador, no te preocupes.
Pero no siendo ese el caso, intentarán ir a un lenguaje que les haga ser rápidos, y que sea fácil de entender. Y eso Python lo cumple.
Me sorprende muchísimo que nadie haya mencionado una de las diferencias cruciales entre python y C/C++/Java: el tipado estático. Para mí, es la razón principal por la que digo no a python (vale, hay más, pero la principal es ésa). En python los tipos no existen en tiempo de compilación, y no tienes un compilador que te avise de que estás pasando el tipo incorrecto. Esto, que parece una tontería, es absolutamente crucial para según qué cosas. Por poner un caso que me ha tocado hacer tanto en lenguajes con tipado estático como en lenguajes sin él, la típica refactorización de cambiar cadenas por un tipo enumerado o una clase con más información es un infierno en lenguajes sin tipado estático, incluso aunque tengan code coverage de tests cercano al 100%. En lenguajes con tipado estático es casi trivial.
Luego está el tema de que el tipado estático ayuda increíblemente a saber lo que hace un método mirando la signatura, ya que ves exactamente qué tipos recibe y puedes consultar qué operaciones se les pueden aplicar (en Python, cuando una función está pensada, por ejemplo, para tres enteros, se ve rápido en el código porque se usan operaciones matemáticas. Pero cuando recibe tres objetos distintos, cada uno con sus llamadas, no tienes más cojones que intentar hacer ingeniería inversa con las llamadas a métodos, hasta que encuentras alguno que reconoces). Esto es así porque, por mucho duck typing, en la práctica la mayoría de funciones no son supergenéricas y pensadas para recibir mil combinaciones de tipos, sino que se escriben porque necesitas realizar una operación específica sobre unos tipos específicos. Y ésa es otra, si en python te pasas con los diccionarios te puedes encontrar con que estás usando de facto un tipo (un registro con unos campos concretos) sin haberlo definido en un punto concreto, con lo que violas el llamado "single source of truth", que parece una tontería teórica, pero ya verás cuando necesites hacer una modificación a ese registro y no la tengas en cuenta en todos los sitios en los que lo usas.
En general, mantener o refactorizar un código pequeño o mediano (y me voy tan abajo como a 10-20k líneas o así) en un lenguaje sin tipado estático se hace muy cuesta arriba a medida que el código crece. En un lenguaje con tipos y compilado la complejidad crece más o menos linealmente y es todo mucho más escalable. Y ya sé que existen analizadores estáticos de python, pero no son tan rigurosos como un compilador de verdad, y eso se nota, o al menos yo cuando lo he usado lo he notado (y no es difícil ni por asomo que un analizador estático dé por bueno a un código que peta nada más arrancarlo). Con los IDEs lo mismo, ayudan pero no hacen milagros.
Firmado: uno de los cuatro locos que aún preferimos mil veces C++ o Haskell antes que Python . Y que no era tan anti-lenguajes sin tipos hasta que le tocó sufrirlos en varios curros.
#49 Pues usas la libería de multiprocessing y asunto arreglado. Los threads lo usas en python cuando estan limitados por E/S o similar. http://docs.python.org/2/library/multiprocessing.html
Además normalmente si necesitas más rendimiento puedes cambiar a cython partes del script. Luego le unes una interfaz atractiva para ir haciendo los apuntes estilo ipython notebook y a nivel científico se convierte en una herramienta de análisis prototipeado muy adecuada.
#84 Creo que tu comentario es injusto. Existen muchas situaciones: Supongo que la más general es para la cual se utiliza el lenguaje meramente como una herramienta; vamos que se usa python porque es un poco más general y flexible que una hoja de cálculo. Otra situación es en la que aparecen los programadores "no informáticos" es cuando se tienen que solucionar problemas muy específicos y complejos; o sea, si yo quiero realizar un modelo de relatividad numérica, apenas existen algunas herramientas generales que me puedan ayudar. El trabajo y dinero que me cuesta contratar al informático que dices y sobre todo hacerle entender la naturaleza del problema que me traigo entre manos (el informático en este caso no es un físico teórico, ni lo tiene que ser) a lo mejor no merece y prefiero escribir mi programa en lo que conozco o medio aprendo, aunque no sea la mejor programación posible (normalmente en estos casos se va a C/C++/Fortran por velocidad)
Otro caso es si soy un observacional o experimentador y tengo cientos de miles de datos o medidas que tengo que catalogar y ofrecer a la comunidad mediante una interfaz provechosa; en este caso si que merece esa contratación, ya que en este caso el informático que sabe de bases de datos, php y similares lo va a hacer mucho mejor que yo. Lo mismo se puede decir de hacer un buen diseño interactivo con ventanitas bajo, digamos, qt o lo que sea.
python es una buena herramienta y por eso se utiliza mucho en el mundillo científico, tiene una sintaxis OO clara, un montonazo de software ya hecho y disponible libremente y tiene la virtud de que enchufarle módulos escritos en C/C++/Fortran es relativamente sencillo. Es por eso que se usa; yo creo que es sólo una razón práctica. Finalmente, tengo que decir que a la mayoría de los informáticos con los que me ha tocado trabajar, programar en python les gusta.
#50 ¿difícil? ¿Has probado PyQt o PySide?
#89 #93 #97 Sí, quizás me he sobrepasado un poco. Analizando mi comentario más detenidamente parece que estoy condenando a los no-informáticos y a Python, y no es eso lo que quería decir. Haré una comparativa separándolo por aspectos. En algunos comparo lenguajes interpretados (con Python como estandarte), con compilados (C++); en otros, informáticos vs no-informáticos.
Primero, sobre comodidad (lenguajes):
Una cosa que me preocupa es el hecho de que el éxito de Python lo esté convirtiendo en el lenguaje del siglo XXI, despreciando a las ventajas de los demás. La gente parece que busca un único lenguaje en el que aferrarse para huir de los que no comprenden. También comprendo que es más cómodo utilizar solo un lenguaje, en vez de tener tu programa dividido en varios lenguajes diferentes que se comunican entre sí como procesos independientes. El problema es que de esta forma lo que parece comodidad acaba siendo contraproducente: Octave/MATLAb sigue siendo de lejos mucho más cómodo para tratar con matrices que Python. Si estás haciendo una aplicación en donde el 40% (por ejemplo) sea tratamiento de señales o imágenes, una mejor alternativa a escribir un programa en MATLAB o Python, es escribirlo en MATLAB Y Python, y que cada uno se encargue de lo que mejor sabe hacer. Y este tipo de cosas no las hace un no-informático.
Ahora, contra los lenguajes compilados, las críticas suelen ir en general en la dirección de que la sintáxis es engorrosa, pero por ejemplo en C++ (es mi ejemplo predilecto), esta sintáxis va simplificándose y la distancia será menor con el tiempo. Ya han añadido con el nuevo estándar C++11 bucles al estilo Python/Octave "for (i : contenedor)", funciones lambda, variadic templates (buenísimos), operadores sufijos, auto detección de tipos e incluso para el tipo de retorno (para el estándar C++14), aunque su trato con cadenas, algunos tipos de tratos con tipos, y su manejo de estructuras estilo diccionario siguen siendo de la vieja escuela.
El problema de un lenguaje como C++ es que es un lenguaje estandarizado, y por lo tanto, su evolución es más lenta, de ahí que las novedades sintácticas lleguen tarde. Lo que quiero decir es que la facilidad sintáctica no es inherente a los lenguajes interpretados: a todos los lenguajes se les puede poner más azucar.
Segundo, eficiencia (lenguajes):
Aquí no diré mucho. Evidentemente, la principal ventaja de los programas compilados es la eficiencia en ejecución, sobre todo si tu compilador también lo es optimizando. Sé que Python también se puede compilar, y que la gran desventaja de los lenguajes interpretados son sobre todo los bucles. Como dice "Pybonnaci", en computación numérica normalmente lo que tenemos es una lista de operaciones de cálculo y no tantos bucles, por lo que quizás la diferencia sea menor.
Habría que hacer benchmarks específicos, de aplicaciones específicas, en entornos específicos, para ver en qué situaciones uno gana al otro y cuándo merece la pena irse a lenguajes más duros como C/C++ y cuando quedarse con más sencillos como Python.
Pero la rapidez en cálculo tampoco es lo único que importa al hablar de eficiencia. El uso de memoria también es importante. Los lenguajes interpretados incitan a que el programador no se preocupe de cómo utilices la memoria, ya que él lenguaje se encarga de todo. Y nuevamente, depende de la aplicación que necesites. Normalmente, como todo proceso automático, hay situaciones en las que el recolector de basura, que no es perfecto, no optimice la memoria de la mejor forma posible, y haya que hacerlo de forma manual, pero resulta que los lenguajes interpretados no ofrecen mucho control en este aspecto. Pero C++ por ejemplo sí que lo ofrece, y tiene ciertos mecanismos que, utilizados bien, hacen innecesario incluso la existencia del recolector de basura (siempre se puede conseguir hacer innecesarios objetos dinámicos de corta vida, que son los que más ineficiencia en memoria generan, y el primer objetivo de los recolectores).
Nuevamente, un "no-informático" no suele pensar en este segundo aspecto de la optimización.
También podría hablar de las optimizaciones que hacen los interpretes contra los compiladores. No domino el tema así que no diré mucho, pero hay una diferencia fundamental: creo que un lenguaje como C++ siempre puede optimizar el código mucho mejor que un interprete, porque un compilador de C++ tiene muchísima más información estática que uno interpretado. En los lenguajes interpretados, los programas deben "vigilarse" en tiempo de ejecución para poder ser optimizados, con las posibles limitaciones que esto puede conllevar, y en C++ (la verdad, no he utilizado nunca otros lenguajes compilados modernos, como D, así que no puedo compararlos con ellos, y nunca he utilizado tampoco lenguajes compilados más antiguos, como FORTRAN), la optimización se hace en una pasada ya que se tiene una información más completa y profunda.
Tercero, mantenimiento (informáticos):
Muchas veces, el factor determinante para que un "no-informático" contrate a uno que sí lo es, suele ser únicamente el "tamaño" de la aplicación. Si requiere muchas líneas de código: llamo al informático, y si no, lo hago yo. Es lo que definen como "complejo". ¿Y qué hay de la legibilidad del código, qué hay del diseño, qué hay del entorno de desarrollo, qué hay de la extensibilidad, qué hay de la documentación, qué hay del control de versiones, qué hay de lo demás? Yo no digo que los informáticos hagan falta para todo, el problema es que un no-informático (la parte contratante) no sabe cuándo un informático puede ser necesario o no. Y yo digo lo siguiente: si el software va a tener vida corta, puedes hacerlo tú si sabes, si va a tener una larga vida (si crees o ves que el programa lo vas a necesitar durante mucho tiempo), contrata a un informático: saldrás ganando. Asístelo en lo que creas que sabes más que el (optimización de cálculo fundamentalmente, que los científicos saben más de matemáticas que los informáticos). El tamaño importa, pero no es el criterio determinante. El tiempo de vida está relacionado con un posible "incremento del software". Contra más tiempo utilices un mismo programa, más probable es que necesites añadirle nueva funcionalidad. Es muy raro que construyas un software que sea útil durante mucho tiempo sin cambios.
El criterio determinante es la vida del programa que estés haciendo, ya que la única habilidad verdaderamente irremplazable de un informático es a la hora de programar "correctamente", más que "óptimamente". Los informáticos también pueden llegar a optimizar muy bien el código en muchas direcciones, también los entrenan para ello, pero no-informáticos también lo pueden hacer relativamente bien en ciertas cosas. Sin embargo, en programar "bien" desde un punto de vista genérico, de modo que el programa tenga muchas propiedades deseables para que sea estable, debuggeable, documentable, comprensible... a eso, nadie gana a los informáticos (a los informáticos buenos).
La relación entre programas "grandes" y programas "duraderos" es que lo primero implica lo segundo: nadie va a requerir un programa de 10.000 líneas de código para utilizarlo solamente unas semanas. Pero el criterio determinante, como ya digo, es el segundo.
Cuarto, influencia (lenguajes):
Python es un lenguaje muy versátil: vale para prácticamente todo. Eso lo hace un poco omnipresente, además de ser más sencillo que su alternativa predilecta: C++. Eso está haciendo que, debido a su comodidad, incluso las universidades delegen la enseñanza y utilización de Python en contra de C++, por su comodidad. Normalmente, los profesores que más tiran en esta dirección son los más cercanos a las ciencias de la computación o informática aplicada, que a los que están más cerca de la pura programación. Y si ni en la universidades se enseña C++, mucho hemos perdido en el camino, ya que C++ es un lenguaje super potente e irremplazable para las situaciones donde mejor funciona. Bajo mi punto de vista, si la tendencia sigue así, los informáticos perderán competitividad.
Es preferible que un informático se pegue de ostias contra C++ y aprenda Python por su cuenta, o se utilice en asignaturas más específicas, a que aprenda Python por su cuenta, ya que debido a su complejidad, nadie va a aprender a programar en C++ a no ser que tenga que realizar aplicaciones en donde la eficiencia sea tan tan tan determinante, como en un juego; porque incluso para software de simulación, muchas veces se programan en MATLAB o Python solo porque los supercomputadores de las universidades "se lo tragan todo" (caso real).
Además, se disminuye el conocimiento general en programación. Aprender programación lógica o funcional es una experiencia positiva: conoces nuevas realidades, nuevas formas de programar, y nuevas ideas que pueden ser utilizadas en otros contextos. El problema es que, como estos lenguajes suelen tener poca aplicabilidad práctica, asignaturas específicas de programación lógica o funcional cada vez son menos comunes. ¿Dónde se podían seguir aprendiendo estos lenguajes? Pues por ejemplo en asignaturas específicas que los utilicen por su naturaleza, como la inteligencia artificial, y sus derivados, pero las universidades también están empezando a enseñarlas usando Python u otros lenguajes.
Por ejemplo, en mi universidad (UCA), donde se enseña procesamiento de imágenes e inteligencia artificial, debido a que el departamento de donde salen todos esos profesores están especializadas en reconocimiento de patrones, y usan MATLAB casi exclusivamente (para tratar imágenes), en vez de enseñar inteligencia artificial usando por ejemplo lenguajes funcionales (como históricamente solía ser), lo enseñan con MATLAB (he de decir que también aprendí CLISP). Otras universidades hacen lo mismo pero con Python.
El caso es que los criterios de personas no relacionadas con la programación pura obligan, solo por una cuestión de número, a desplazar otros lenguajes que deberían ser n
#4 Aunque yo he enviado el enlace, no estoy de acuerdo. La mejor opción no es Python, la mejor opción es PyPy
#32
Mala carta de presentación, cualquier programador debería saber tirar del hilo de una funcón yy saber en mayor o menor medida lo que hace
Al final todos los lenguajes son muy similares, personalmente prefiero ver más entornos con un compilador potente, para programación científica los lenguajes manejados tipo Java o .Net Framework son lo peor en rendimiento y manejo de memoria (especialmente Java), y los interpretados tipo Python o Basic tampoco por el mismo motivo. Delphi tenía un compilador impresionante (pena que Borland ya no exista), con resultados cercanos a C. En programación científica tienes que ir a C, Objetive C o C++, para que los cálculos no tarden horas, a no ser que la tarea sea poco intensiva. R, Python sirven para cálculos pequeños, de andar por casa, cuando tienes que manejar millones de datos y cálculos es dónde se nota la potencia de C, Objetive C y C++.
Este de los lenguajes de programación, es uno de los flamewars más viejos y estériles que existen. Y con el tiempo lo es más (más viejo y más estéril).
En realidad hay pocas preguntar que hacerse a la hora de elegir un lenguaje de programación. A saber:
- ¿Es el rendimiento un tema importante? Atención con esta pregunta, que ahora con los procesadores con muchi-cores la pregunta es cada vez más difícil de responder. Si eliges bien las estructuras de datos y los algoritmos en tu programación, la diferencia de rendimiento entre un lenguaje u otro, es mínima. De hecho, en el caso de que se perciba, seguramente se llegue a la conclusión que es más barato invertir en hardware, que en reescribir tu programa en otro lenguaje.
Si aún con todo esto, sigues pensando que el rendimiento es importante, la mejor opción será aquel lenguaje que esté más próximo al lenguaje máquina. Y no, no es C: es el ensamblador del propio procesador.
- ¿Están las herramientas que vas a utilizar en tu programación disponibles en la distribución estándar de tu lenguaje, o mediante librerías? Si no es así, deberías pensar seriamente el considerar aprender otro lenguaje que si que lo tenga. Y si integrado en la distribución básica de tu lenguaje, mejor aún. Más integrado suele traducirse en más óptimo en varios sentidos.
Por ejemplo, cuando he intentado usar Python para temas de programación web, siempre me he encontrado con la pega de que no tiene soporte nativo para sesiones, como PHP. También se que tiene librerías que te permiten hacer uso de ellas. Pero eso, son librerías. No están integradas en el lenguaje. En ese sentido y en ese contexto, considero PHP mejor que Python.
- ¿Te sientes cómodo trabajando con él? Parece una tontería, pero cuando estamos hablando de productividad, es muy importante que nos sintamos cómodos con él. Es decir, que no perdamos demasiado tiempo en pensar como se hacen las cosas con el lenguaje de programación en cuestión. En estas cosas, los lenguajes de más alto nivel (más distancia entre ellos y el código máquina), suelen dar muchas facilidades en el sentido de ayudar a hacer las cosas abstrayéndonos del hardware que hay por detrás.
En este caso Python es muy interesante, porque es un lenguaje de programación multiparadigma: te permite resolver un problema desde diferentes perspectivas. Y cada una de ellas puede ser más interesante que otra en función del problema.
Resumiendo: esto de decir qué lenguaje es mejor o peor muchas veces es un intento vano de justificar una elección personal, que nadie ha pedido que sea justificada. Se puede hacer cualquier cosa con cualquier lenguaje de programación. Simplemente hay que elegir el conjunto de lenguaje y librerías que te haga ser más productivo. Lo demás, es filosofar porque tienes demasiado tiempo libre.
#100 No le des tantas vueltas. Python se utiliza para hacer scripts, enlazar procesos y funciones programadas en diferentes lenguajes. Pero no es que se lancen ahora; llevan haciéndolo desde hace décadas.
Serious business!
#32 yo no soy programador al uso, con muchas taras, osea apenas hago comentarios, documentación cero y los indentados suelen ir según tenga el día...
...pero si mi ex-jefe me pregunta por teléfono por alguna cosa, casi puedo indicárselo de memoria!
#47 ¿por qué estás desacuerdo con esa afirmación?
#4: Pues yo prefiero C y no soy informático, sino de ingeniería técnica industrial.
A parte de que no me gusta que me digan cómo debo indentar el código... yo indento siguiendo mis necesidades, no las necesidades del autor del lenguaje. Hay veces que agrupo varios comandos en una misma línea, si tienen mucho que ver entre ellos.
El mejor lenguaje es que el más comunidad tiene... ¡HeDicho!
Python se ha extendido muy rapidamente porque da soluciones rapidas/eficaces a los problemas mas comunes. Pero hay otras cosas para las que no es tan eficiente al ser un lenguaje interpretado.
Que es un lenguaje muy util? Si.
Que vaya a acaparar el 100% del mercado? Dificilmente.
#91 ¡Espectacular!
#100 Hay veces que la velocidad y eficiencia "humana" es más interesante que la de código. Es decir, Python es un lenguaje diseñado para humanos y C para máquinas. Siempre pudes escribir en un lenguaje de bajo nivel (como C) las partes críticas de tu código para quitarte cuellos de botella. En programación científica esta muy claro si se compara Fortran vs. Python http://www.cacheme.org/ventajas-python-fortran-c/
#104, mira, esto es un programa en Lisp:
http://landoflisp.com/guess.lisp
Esto, un programa en Haskell:
http://hackage.haskell.org/package/base-4.6.0.1/docs/src/Data-Foldable.html
Y esto, un programa en APL (no, no hay problemas de codificación):
http://www.computerhistory.org/atchm//wp-content/uploads/2012/10/matrix.jpg
Lo único que tienen en común estos lenguajes de programación es que ambos pueden ser interpretados por una máquina de Turing determinista. Yo no creo que eso sea suficiente para decir que todos los lenguajes de programación son similares.
#42 El título dice "computación científica". Imagínate a qué tipo de gente se refiere: médicos, biólogos, o psicólogos como el autor.
#60 Pues viendo el curriculum por encima se trata de un psicologo que utiliza lenguajes de programación para un area de investigación muy determinada. No lo veo para nada como una opinión a nivel general o de un experto en ingenieria del software o lenguajes.
Exacto. Es un científico que necesita programar para investigar, no un programador al que pagan por programar. Es exactamente de lo que va el post.
#13 Estas equivocado, pypy no es un interprete como Cpython o Jython, es un JIT.
#86 pypy proporciona un interprete escrito en R, pero puedes usar pypy en el interprete que quieras porque realmente pypy es un JIT, auqne realmente no se aconseja usar otro que no sea el propio.
#56 Yo me dedico a programar simulaciones para calibrar tests. Por ejemplo! Pero también tenemos análisis de datos, programación de experimentos, simulaciones de otro tipo, psicometria avanzada....
#71 Totalmente de acuerdo contigo! En mi uni se enseña SPSS y yo hice bien en querer aprender R por mi cuenta : ) ¿Qué usas para programar experimentos en Python? ¿OpenSesame?
#49 lo estoy haciendo Básicamente porque me interesa montar un servicio web en Play (http://www.playframework.com/), usando MongoDB para la persistencia con el plugin ReactiveMongo (http://reactivemongo.org/).
¿Y qué tal te va el curso? Yo hice el anterior de PF y me encantó, así que me apunté a este también. Es una maravilla poder tener a esa gente dando clases de gratis (mira lo que vale el training de Typesafe).
#12
Y mirarse algo escrito en prolog que se las trae...
O lo sencillo que es el Logo (pero limitado) para usar por usuarios no expertos en programación
Je... hay tantos y tantas diferencias Además como que hay declarativos, imperativos y mixtos...
#16 Ok, te he pillado y entiendo tu punto de vista.
Pero al final, es todo parecido. Funciones complejas que derivan de otras funciones más simples.
Quizás yo no he sabido expresarme bien, cuando he dicho que todos los lenguajes de programación son lo mismo...
Me refería a la gramática, no a la potencia de cálculo (que por otra parte ha de estar programada)
Mi pregunta entonces sería:
¿Que entendemos por lenguaje de programación?
¿A que nivel nos situamos?
#20 Ya me imagino que cada área de conocimiento es distinta, pero por lo general para prototipar se usan lenguajes más productivos. Luego si el mismo programa va a estar rulando años pues se cambiará a lenguajes más eficientes como C/C++.
#28 Nadie entiende un código que no ha mirado ni una sola vez durante 2 años, y menos si tú código no es de calidad.
#42 goto #15