edición general
172 meneos
2477 clics
Lenguajes de programación: Python es el más popular de 2019 según IEEE Spectrum

Lenguajes de programación: Python es el más popular de 2019 según IEEE Spectrum

IEEE Spectrum ha publicado su sexta lista anual con los lenguajes de programación más populares del año a través de múltiples plataformas, y, para sorpresa de pocos, Python vuelve a repetir como líder indiscutible, tal como pasara en 2017 y en 2018. Para los menos familiarizados, la clasificación de IEEE Spectrum es considerada un buen indicador de la popularidad de los lenguajes actuales, aunque dista de ser perfecta, siempre exponen su metodología al publicar los números.

| etiquetas: lenguajes , programación , ieee spectrum , lista , 2019 , python , más popular
«12
  1. Python no es mas que java interpretado,por tanto Java gana.
  2. La Esteban también es la más popular...
  3. ¡Rápido, usemos python!  media
  4. Cuando se pueda compilar python nativamente para la web, reventará la puta gráfica.

    Webasambly te esperamos.
  5. No tiene nada que ver. Python está escrito en C, y la sintaxis es completamente diferente.
  6. #6 Este mensaje era una respuesta a 1
  7. #1 Se te ve puesto en el tema. Cuéntanos más, por favor.
  8. #6 La implementación de referencia, CPython, sí. Pero existen otras: PyPy, IronPython, Jython...
  9. #1 ehhhh no.
  10. #9 No creo que nadie use Jython aparte de cuatro frikis de apache o ibm en el típico proyecto hiper legacy de python 2.7.X, aparte estamos en 2019 y no hay perspectiva de que soporte python3 en el futuro.

    PyPy sí te lo compro, es más rápido, pero no es java, así que no sé por qué el trol ese dice que es java interpretado.
  11. #1 Es mucho mejor el java compilado nativo, claro.
  12. #5 espero que no :troll:
  13. Pensé que spectrum era BASIC
  14. #1 Claro, claaaaro que sí. Espero que seas un trolo sin gracia. Jajaja.
  15. #5 servidor! :ffu:
  16. Me alegro de que por fin el python sea valorado como se merece, pero me preocupa muy muchísimo no sólo que el java esté en segunda posición, sino que siga en la lista, o incluso que siga existiendo.
  17. Si algo funciona, para que complicarse ?
  18. Pues yo creo que Python es el nuevo PHP, ves cada guarrada escrita en él que flipas
  19. #4 casi... Mira skulpt
  20. #11 Tu mismo te respondes "por qué el trol", pueso eso, trolear.
  21. #17 Sigo sin entender todo ese odio por Java
  22. #13 espero que sí
  23. #17 Python es muy mal lenguaje. pero siempre habrá borregos.
  24. #1 Al principio iba a responderte con más detalle pero a cada vuelta que le doy a tu frase más sin sentido es. Simplemente y como consejo , si te dedicas a la informática estudia y fórmate. Creo que lo necesitas y lo digo sin acritud ni intención de ofenderte. Es un consejo sincero.
  25. #4: Claro, como HTML+CSS+JS consume poca RAM, metamos también otro intérprete más (y una fuente más de posibles agujeros de seguridad).

    Si quieren meter un conversor de Python a JS, que lo hagan, pero que no inflen más las páginas web.
  26. Warning: comentario altamente sujetivo

    Soy programador Python traído desde las profundidades de .NET. Y una de las diferencias sustanciales es la reducción de carga cognitiva con respecto a .NET y similares. Con mucho menos código haces lo mismo, y menos código por regla general quita ruido facilitando la lectura (yo me paso más rato leyendo código que escribiéndolo en general). MI vida se ha vuelto mucho más fácil en general gracias a python.

    Muchos dirán que la falta de un compilador que te haga de colchón es un fail muy grande (por su naturaleza dinámica). Lo que esta gente ignora es que, precisamente, esa falta de compilador te obliga a mantener una alta cobertura de tests, obligando al equipo a tener la disciplina de implementar tests para todas las features, algo que, para mí, es superpositivo. Tu compilador de cara a refactors son los tests.

    Mantengo microservicios y monolitos de cientos de miles de líneas en python, y solo le veo un par de pegas:

    1- Python serio no es para novatos precisamente por la necesidad de tests. El equipo ha de ser consciente de ello. Novato en python == código plagado de bugs.
    2- No es un lenguaje pensado para programación funcional, razón por la cual mi sueño sería hacer algún proyecto serio con Elixir.

    Pero sí, programar en python en general me ha cambiado la vida, y no miro hacia atrás. En el mundo business general no es necesario el rendimiento de Java o C++ o Rust, ya que tus cuellos de botella suelen estar en el IO, no en la CPU.
  27. Yo solo usaría Python si lo tuviera que usar obligatoriamente en el trabajo (no soy programador).

    En caso contrario, me niego a programar en eso, es lo más asqueroso que he conocido, indentado por espacios. :palm:
    Si, a algunos os gustará y lo respeto, pero eso de indentar por espacios me resulta insoportable.
    No hace falta que me respondáis diciendo que programar con espacios está bien por tal o cual motivo, no me vais a convencer, no me gusta, lo odio y como digo, ya intenté hacer una cosa con Python hace un par de años y lo tuve que dejar, era insoportable.

    Todo lo que he programado, que no es mucho, siempre lo he hecho con C y JS.
  28. #28 Puedes usar tabs ehhh. Siempre y cuando dentro del mismo fichero haya consistencia y no mezcles tabs y espacios, tabs se pueden usar.
  29. #29: Me da igual tabulaciones que espacios, prefiero las llaves de C.
  30. #28 Coincido plenamente contigo. Y eso que uno de mis lenguajes favoritos es Haskell, que también usa los espacios para las estructuras de control, pero por su naturaleza funcional es muchísimo más claro que Python . En Python es facilísimo escribir un espacio de menos o de más y liarla pardísima.
  31. #25 En efecto. Python y Java son como un huevo a una castaña.
  32. #27 Pues mi experiencia después de muchos años programando es la contrario. Quiero toda la verificación estática que el compilador pueda darme. Es fácil olvidar escribir un test, pero el compilador nunca se va a olvidar de verificar lo que le pidas. Y a la hora de refactorizar es infinitamente más sencillo si tienes información de tipos. Por algo la mayoría de los lenguajes hasta ahora dinámicos están incluyendo tipado opcional.

    Y en cuanto a que el código de Python sea más compacto que el de C#, por mi experiencia con ambos lenguajes eso se debe más al diseño de las bibliotecas que al lenguaje en sí.
  33. #30 Al final es lo mismo...en C usas llaves, pero si estás en un equipo de desarrollo bien pronto aparecerá una norma de estilo y tendrás que usar llaves e identación por narices.

    Lo mejor en ese aspecto es go. Ejecutas go fmt y el código se formatea como debe ser. Un poco autoritario, pero se acaban las discusiones de formateo
  34. #33 Opiniones hay miles, y entiendo tu punto de vista. En mi proceso de programación, suelo usar las siguientes reglas:

    - No necesitamos declarar el tipo de las variables en la mayoría de casos si ponemos unos buenos nombres de variables (sólo declaro el tipo si creo que en un cierto punto puede mejorar la entendibilidad de mi código). Cierto que ayudan al refactorizado en algunos casos, pero a cambio de "ruido" que a menudo no hace falta. Como muchas cosas en la vida, todo es sopesar pros y contras.
    - Toda feature que se espera que haga la aplicación tiene un test de aceptación end to end. Si se ha olvidado escribir ese test que precisamente comprueba la correctitud del código y la feature... Ya te falla lo más elemental, y no es problema del lenguaje, sinó del programador.
  35. #31
    What? Llevo 3 años trabajando profesionalmente con Python y NUNCA la he liado pardisima por eso. Cualquier editor de codigo te lo va a marcar como SyntaxError y si no cuando vayas a arrancar el projecto te va a tirar un SyntaxError y donde. O me estas diciendo que ni siquiera arrancas el codigo que escribes?
  36. #5 Sí, y para la administración pública. :palm:
  37. Creo que estos estudios confunden búsquedas online con popularidad.

    Para mi que haya un montón de búsquedas sobre python me indica que es el segundo lenguaje de mucha gente, y que su lenguaje principal lo tienen más por la mano y no tienen que buscar tanto "como hacer x" en él.

    Al menos es mi caso, tengo muchas más búsquedas del tipo "<cosa> python" que de "<cosa> golang" siendo Go el lenguaje que uso el 90% del tiempo. Además creo que python está peor documentado y por eso tengo que buscar más.
  38. #28 Año 2019. Todavía existen humanos que no saben qué significa "tab expansion" y se créen que para indentar con espacios hay que darle a la barra espaciadora.
  39. #26 Pues Google quería (y quiere) introducir Dart al Front. No me extrañaría que implementara un intérprete en Chrome
  40. #8 #10 #15 #25 veo que si no se pone :troll: todo el mundo se toma tus comentarios en serio,por muy absurdos que sean.
  41. ¿Se refiere a Python 2 o Python 3? Muchos dirán inmediatamente que Python 3 pero resulta que gran parte de las librerias y scripts existentes están escritos en Python 2. Así que tenemos una misma denominación para dos lenguajes incompatibles.
  42. #39 La lista de IEEE Spectrum no confunde búsquedas online con popularidad
  43. Yo desde que uso TypeScript no echo de menos a Python
  44. #28 pero si se pueden usar tabuladores, wtf xD, eso sí no debes mezclar tabs o espacios lo cual sería una guarrada. También hay IDEs que te cambian unos por otros en un clic
  45. #50: No es el pulsar la barra espaciadora, es que no me gusta hacer la estructura del código a base de espacios.
    Si modificas el código corres riesgo de perder la estructura, por eso prefiero las llaves, porque con ellas la indentación viene después de hacer la estructura y hay menos riesgo de equivocarse en mi opinón.

    CC #40.
  46. #51 ah oki, se supone que es para forzar a los mas desorganizados a mantener cierto orden, pero a veces da la lata si
  47. #41: Si, pero no deja de ser un aumento de la complejidad.
    xkcd.com/927/
  48. #52: Es que no todos los programadores lo son a tiempo completo, a veces uno puede necesitar la programación como complemento a otras actividades del trabajo o del tiempo libre.
  49. #26 Se ve que sabes bien lo que es wasm y como funciona :roll:
    PD: Funciona en el mismo sandbox en el que funciona JS
  50. #22 a ver con cual lenguaje creas un software para cualquier plataforma...
  51. #5 En industria hay mucho VB.Net
  52. Cuanta bilis en cada envío sobre lenguajes de programación, ni que fuera política o fútbol.
  53. #56 Python mismo?
  54. #28 vaya argumento, como si la tabulación fuese una característica importante en un lenguaje :palm:
  55. #61: Si eres programador casual y tienes que retocar a menudo el código, si, es una faena que se organice tabulaciones (o espacios) y no por llaves.

    Es lo que muchos detestamos de Python.
  56. #43 Pocos quedan para el 2. Y muchos estan dejando de darle soporte.
  57. #62 Pues te recomiendo profundizar en las vicisitudes de la ciencia de la computación antes de descartar alegremente un lenguaje, ya sea python, java o el que sea. No es el más popular por capricho de los desarrolladores ni por la tabulación, te lo aseguro.
  58. #48 Pues yo me he defendido con la documentación de serie para muchísimas cosas, y stack overflow para algoritmos más bien, casi casi.
  59. #54 Pues Python es ideal para esos casos.
  60. #64: Lo será por lo que sea, yo te digo que estuve haciendo unas pruebas y a mi eso de que se organice por la indentación y no por llaves no me gusta en absoluto.

    C podrá gustar más o menos, pero si quieres envolver un trozo de código con un IF para hacer una prueba, lo haces en un momento y si pones el IF y su llave de cierre sin indentación, luego ves bien dónde lo tenías para poderlo quitar. En Python eso, sencillamente, no es posible. Y si copias y pegas un trozo de código en otro, tienes que tener mucho cuidado con actualizar la indentación, a mi eso no me hace sentir cómodo.
  61. #46 ¿Qué tiene TypeScript que no tenga Python?
    ¿Programas sólo para la web?
    ¿Que intérprete utilizas?
  62. #1 Project Manager de indra por casualidad?
  63. #19 Pero las guardadas te las puedes encontrar con cualquier cosa.
  64. #39 La documentación en línea de Python no la veo tan mala. Eso sí, de algunas librerías externas si que me parece mala. Pero eso no es culpa de Python en sí.

    He cotilleado documentaciones de otros lenguajes para ver si me interesaba migrar y no la veía tan clara. Quizás porque no estoy acostumbrado a ella.
  65. ¿Y también dice esa estadística si todos los que usan esos lenguajes saben programar?
  66. #73 No veo la explicación tan diferente. Quizás si que la de Python es algo peor.
  67. #67 no estoy discutiendo tus gustos, faltaría más. Lo que intento decirte es que concluir que un lenguaje es mierda por su estilo de indentación es como decir que una casa es basura por las cortinas del salón.
  68. #77 No comparto tu clasificación entre informáticos y no informáticos. Yo soy informático y lo utilizo muchísimo. La cuestión es para qué se utiliza. Y también cómo se utiliza, porque saber usar bien python tiene su miga.
  69. #80 Porque estás en el nicho de informáticos que usan Python. #77 se refiere a que hay muchos perfíles que de vez en cuando tienen que programar algo y lo hacen con Python porque para esas personas, científicos por ejemplo, es mucho más sencillo tirar 100 líneas para hacer sus historias que aprender un lenguaje estructurado con tipado fuerte y rendimiento consistente.
  70. #73 Vale que tengo experiencia en Python y básicamente ninguna en Perl, pero la explicación de Python la he entendido sobre la marcha (no recuerdo haber tenido nunca que utilizar any de todas formas) y la de Perl me ha costado un rato entenderla. Supongo que la de Python necesitas saber que es un "iterable" pero yo creo que en los cursos de Python que he visto se enseña hacia el principio (no de lo primero, pero). Tal vez añadiendo un enlace a algún sitio donde expliquen los iterables sería mejor. Por otro lado también veo innecesario el ejemplo que ponen.
  71. #59 Estoy de acuerdo. Hay lenguajes que me gustan más, otros menos y tal vez alguno que no va conmigo, pero entiendo que son más intereses y gustos personales que otra cosa. Cada uno que use lo que más le apetezca. Tal vez el problema es justamente ese, cuando te ves obligado a usar un lenguaje que no te "pega" y le acabas cogiendo manía.
  72. #51 Sin acritud, si te cuesta tanto prestar atención a un detalle tan nimio como la identación, quizá deberías buscar otro hobby/profesión.

    Por cierto, el día que descubras los debuggers y los breakpoints condicionales que tienen los IDEs modernos.
  73. #17 Con el tema del tipado es un quiero y no puedo. Si programas cosas pequeñas, con equipos que están acostumbrados a trabajar juntos, el tipado puede ser superfluo e incluso engorroso, pero a medida que los desarrollos se hacen más y más grandes y complejos, y tienes 40 tios -algunos novatos- picándole por todos lados, pasar del tipado es un lujo que pocos querrán asumir.

    En realidad, yo creo que Python está aumentando mucho debido al programador universitario que lo usa de manera doméstica, académica y luego también en investigación. Pero en negocio, creo que tenemos Java y js para rato.
  74. #68
    ¿Qué tiene TypeScript que no tenga Python?
    angular, y nx (Desconozco si existe equivalente en Python)

    ¿Programas sólo para la web?
    Sí. Pero las aplicaciones angular se pueden convertir fácilmente en aplicaciones de escritorio y en aplicaciones móviles.

    ¿Que intérprete utilizas?
    Generalmente ninguno. Cuando uso alguno uso node o ts-node

    Personalmente pienso que Python es mas para el ámbito científico (Para físicos, matemáticos, etc). Para el ámbito empresarial prefiero TypeScript
  75. #28 Esto que dices no tiene ningún sentido, en todos (o casi todos) los lenguajes de programación ya usas tabulaciones para indentar el texto. En Python es obligatorio, pero en los demás lenguaje también debes hacerlo.

    Y eso sin entrar en el tema de que todas las IDEs actuales ya te indentan automáticamente el código.
  76. #86 Estoy bastante perdido con TypeScript y angular
    las aplicaciones angular se pueden convertir fácilmente en aplicaciones de escritorio y en aplicaciones móviles.
    ¿Con aplicaciones de escritorio te refieres a un ejecutable? ¿Cómo compilas el programa de typescript a ejecutable?
    ¿Con aplicaciones móviles te refieres a apks?

    Si no usas intérprete, ¿cómo pruebas los programas?
  77. #88 Existen varios proyectos para crear aplicaciones móviles android e iOs a partir de una aplicación web como por ejemplo:

    cordova.apache.org/
    ionicframework.com/

    Para crear una aplicación de escritorio tambien puede usar:

    electronjs.org/
    nwjs.io/

    Creo que casi todos generan "ejecutables" y apk al uso. Aunque no tendrán el rendimiento de una aplicación nativa puede ser mas que suficiente para uso empresarial donde lo que prima es reducir los tiempos de desarrollo

    Sobre lo de intérprete no se muy bien a que te refieres (para node esta el comando node y para typescript el comando ts-node pero no son la forma habitual de de probar una aplicación). Tal vez te refieras a cosas como el comando ng de angular
  78. #84 y #87: Si yo también indento siempre, sin embargo:
    - A veces meto las líneas agrupadas, cuando tienen relación entre si y son varias (hago una tabla).
    - A veces meto código mal indentado porque solo lo estoy probando y luego lo quito (y no voy a estar cuidando la presentación para probar un poco).

    Vale, los programadores expertos de alto nivel no lo harán así, pero es que la programación no solo es el alto nivel, sino también gente que programa de forma esporádica. A veces solo necesitas un trozo de código... no desarrollar una gran plataforma.
  79. #79: Si Python tendrá maravillas, pero para programar de forma casual en mi opinión es peor.
  80. #91 Gracias por argumentar tu postura.

    Yo sólo digo que los seres humanos no somos parsers y funcionamos mucho mejor con la ayuda visual de la identación.

    De hecho, me he encontrado con más bugs en otros lenguajes (por ejemplo un equipo que trabajaba en Node) por un formateo raro y un despiste con las llaves que en Python. Piensa también que en un equipo de desarrollo grande puede que algún compañero se le vaya la pinza mucho y no le dé la gana de seguir ninguna guía de estilo.

    He estado programando más de 5 años profesionalmente con Python y es un lenguaje que tiene muchos problemas, como todos, pero precisamente el tema de la identación es un acierto.
  81. Los valientes programamos en C, Ksh para script y a veces Perl. El resto mariconadas.
  82. Qué pena que Rust no esté entre ellos. Es un lenguaje que merece la pena aprender.
  83. #91 No sé a qué te refieres con lo de la tabla, pero cualquier guía de buenas prácticas de C o C++ te serviría para Pyhton, y a mí me encanta porque te obliga a seguir ciertas pautas.

    Como ya he dicho antes, cualquier IDE moderno te va indentando automáticamente y si pones algo mal te lo marca en rojo (igual que en cualquier otro lenguaje de programación), por lo que yo no le veo desventaja alguna.
  84. #96: Lo de poner una tabla es si son varias instrucciones relacionadas. Rara vez lo hago, pero cuando lo hago queda bien porque se ve mejor, al menos yo.
  85. #97 Por ejemplo?
  86. #98: Algo de este tipo:

    variable_a_inicio = 0; variable_a_fin=0;
    variable_b1_inicio = 0; variable_b1_fin=0;
    variable_b2_inicio = 0; variable_b2_fin=0;
    variable_c_inicio = 0; variable_c_fin=0;

    Una tabla bien ordenadita (poniendo espacios para alinear) para mi gusto queda mejor. Habrá quién use vectores y tal, yo prefiero hacerlo así si no es una lista correlativa, es mi forma de programar.

    Es algo que se da poco, pero con C lo puedo hacer a mi gusto, con Python... bueno.

    También digo que de Python no me desagrada tener que pulsar la barra espaciadora o el botón de tabular, sino el hecho de que si quiero meter parte del código en un IF para poder hacer una prueba un momento, no es tan simple como en C que puedes poner el IF sin nada de indentación y su llave de cierre también, y así sabes bien por dónde te llegas por si lo tienes que quitar, y si no lo quitas, lo pones todo en su sitio y listo, pero no andas decorando el código para un experimento momentáneo.
  87. #37 A mí no me ha pasado, pero sí he visto a compañeros a los que les ha pasado, y se han tirado varias horas arreglándolo. También te digo que era un código que se ejecutaba en un servidor y lo estaban editando por SSH, no tenían un editor hipersofisticado.

    Pero no es sólamente mezclar tabuladores y espacios, eso es fácil de arreglar. El problema surge cuando mueves código de un lado a otro y se te descolocan los espacios, y cambia totalmente la estructura de tu programa.
«12
comentarios cerrados

menéame