En la década de los 80 teníamos BASIC hasta en la sopa: daba igual que C llevara años en el candelero, porque lo que nos vendían las revistas, la televisión y los fabricantes de microordenadores -que lo integraban en sus equipos de forma directa- era este lenguaje de programación. Hoy en día el lenguaje de programación más popular es Python. Fácil, accesible, y utilizado en todo tipo de entornos, domina un segmento en el que desde luego hay opciones notables. La clasificación anual de IEEE Spectrum, una de las más reputadas en este ámbito...
Comentarios
Fácil para empezar a cacharrear y entender la lógica de programación, pero una pesadilla para grandes proyectos.
Con una sintaxis horrorosa y sin tipar debería estar prohibido, pero gracias a sus extensas librerías está donde está.
Es el lenguaje que gusta a los que no les gusta programar.
#2 Discrepo. Como lenguaje dinámico es una maravilla (compáralo con Javascript... no hay color); lo que pasa es que hay que usarlo para lo que hay que usarlo, igual que el resto de lenguajes. Python, como lenguaje de scripts que es, no está pensado para megaproyectos, sino como un lenguaje-pegamento para hacer minitareas de gestión, generación y proceso de ficheros sencillos, etc.
#5 Es ideal como pegamento, pero también se pueden hacer grandes proyectos si te lo montas bien. Por ejemplo, Reddit está hecho en python.
#7 Si te lo montas bien, puedes hacer grandes proyectos hasta en ensamblador
#9 Hacer un gran proyecto en ensamblador es montárselo mal desde el principio...
#9 Bueno, y por aclarar un poco mi respuesta de antes: Dicen que el desarrollo de Linux empezó a acelerarse de verdad cuando Linus Torvalds empezó a usar C cada vez más en detrimento del ensamblador.
#12 Se lo que quieres decir, pero esa frase no es correcta para lo que tú planteas. Me explico:
Para empezar, estamos de acuerdo en que utilizar ensamblador para un proyecto grande sería un suicidio. Mi comentario pretendía utilizar una hipérbole para explicar mi punto de vista: utilizar python exclusivamente para un proyecto grande, y haciéndolo como se hace un proyecto grande (unos pocos "binarios" tochos) es un suicidio. Otra cosa sería lo que comentan en 11, por ejemplo, que es convertir un proyecto grande en muchos pequeños, pero entonces cada proyecto que se hace en python ya no es un proyecto grande, lo que es grande es su unión. Es diferente.
Respecto a lo que dices de Linux, no es una frase precisa porque, en origen, Linus había escrito un núcleo específico para Intel, y su objetivo original era aprender a programar para él. Por eso utilizó muchos trucos específicos del procesador que aceleraban y simplificaban el diseño, pero tenían que ser hechos en ensamblador y sólo funcionaban en arquitecturas x86. De hecho, al principio él consideraba que la portabilidad del núcleo entre arquitecturas era absurda, que cada núcleo tenía que ser específico de una arquitectura concreta y que la portabilidad tenía que ser a nivel de API (POSIX y compañía, vamos). Fue cuando se añadieron los primeros parches que daban soporte a multiplataforma para... ¿motorola 68000, creo? No lo recuerdo... puede que me esté columpiando... pero bueno, que fue ahí que vio que era bueno permitir que el mismo núcleo se utilizase en dos arquitecturas diferentes. Entonces cambió de idea (aunque supongo que también influyó el ver la gran cantidad de código que se compartía entre arquitecturas, como por ejemplo sistemas de ficheros, red, etc... y que era absurdo "reescribir" para cada arquitectura). Pero claro, como el ensamblador es específico de una arquitectura, tenía sentido intentar minimizarlo, para así reutilizar el máximo de código. Y así, poco a poco, fueron pasando más y más cosas de ensamblador (las cuales tenían que escribirse específicamente para un procesador concreto) a código en C, que era mucho más portable entre arquitecturas.
En otras palabras: no es que el error estuviese en utilizar ensamblador, sino que era un error de concepto lo que hacía que tendiesen a utilizar ensamblador. Cuando se cambió de concepto, la consecuencia fue el menor uso de ensamblador.
#2 #5 los proyectos grandes deberían convertirse en proyectos pequeños antes de abordarse. Es la idea común a toda la ingeniería del software, desde programación de muy alto nivel (como algunos consideran a Python) hasta microservicios (donde es muy evidente).
#5 Javascript ha mejorado mucho, sobretodo si lo usas con supersets tipo TypeScript.
#17 Por supuesto que sí, no te lo discuto. Y de hecho llevo una temporada larga utilizándolo para escribir algunas extensiones para Gnome Shell y reconozco que ya no es lo que era y que es cómodo utilizarlo. Pero se notan detalles que tienen que mantener por compatibilidad hacia atrás que, en mi opinión, son bastante feos. Por ejemplo:
- que si accedes a una propiedad que no existe en una clase, no salta una excepción sino que te devuelve un tipo válido, el cual puedes comprobar si es verdadero o falso (aunque la comparación será falsa siempre porque no existe). Esto da lugar a muchos errores de programación porque te confundiste al teclear y se te escapó una letra que no era.
- for ... in ... frente a for ... of ... : en python sólo tienes el for ... in ..., que en una lista te devuelve los elementos en sí. En javascript te devuelve índices con los que acceder a la lista, lo que es redundante. Sí, me dirás que el for ... in ... permite mantener la coherencia entre diccionarios y listas, pero personalmente me parece redundante y feo (aunque puede que esté influenciado por haber aprendido python antes).
- el uso del punto y coma: a ver, o lo haces obligatorio, o no lo usas nunca, pero eso de que sea opcional excepto cuando haya ambigüedad es una tremenda fuente de posibles bugs, porque cuando escribes código tú sabes lo que quieres decir y tiendes a ver el código de esa manera, con lo que es muy fácil que no pongas el punto y coma porque estás acostumbrado a no hacerlo, y se te pase que en un punto sí lo necesitas para evitar una ambigüedad. Y luego ponte a descubrir por qué no funciona un código que, obviamente, es justo el que tiene que ser y debería funcionar bien...
Luego ya, la necesidad de usar let y var me produce sentimientos encontrados. Por una parte no me gusta que, en pleno siglo XXI, todavía sigamos teniendo que definir variables en un lenguaje dinámico, pero por otra reconozco que permite evitar un error típico que es el de sobreescribir una variable cuando copiamos y pegamos código de otra parte en medio de una función.
#26 El uso del punto y coma es algo que queda restringido a:
a) Ignorantes que no entienden cómo funciona
b) Paranoicos que temen que las herramientras de construcción puedan romper algo, porque a)
c) Gente que "como en x se hace así en y también lo hago así"
#32 El tonillo de superioridad sobra. Y me reafirmo: cuando programo quiero centrarme en el algoritmo, no en la sintaxis. Además de que ya me pasó un par de veces de que el código no funcionaba como esperaba y era porque faltaba un punto y coma en donde era necesario (y encima ni siquiera era mi código).
#35 Hablo desde mi experiencia: la mayoría de gente usa lo puntos y comas por a) o c), o por
d) Siempre se ha hecho así / he visto que la gente de tal proyecto lo hace y por eso yo también
Por suerte ya no hay tanto dogmátismo como había hace unos años, en que muchos desarrolladores usaban los puntos y comas como si su funcionamiento fuera algo esotérico regido por reglas incomprensibles. Por eso uso el término ignorante, sin ánimo de insulto, ya que en 2020 define, claramente, una falta de conocimiento sobre algo esencial del lenguaje y que no se puede ignorar a no ser que sea a propósito.
En otros lenguajes te podría pasar parecido, pero quizá descubrirías antes el problema de sintaxis porque sería menos sutil. También depende de la experiencia y de lo espesa que esté una.
#36 Pues con la última frase me estás dando la razón: si con otra estructura el fallo sería menos sutil, es que, efectivamente, es una fuente de errores.
Las cosas como son: JavaScript no se inventó para ser un lenguaje con el que escribir miles de líneas de código, sino que pretendía ser solo un minilenguaje para hacer cosas simples en web, como cambiar la imagen en un botón al pasar el ratón por encima y similar (si, ya se que ahora eso se hace con CSS, pero originalmente eso era tarea de JavaScript), y por eso le añadieron el punto y coma automático, para hacerlo más atractivo para novatos. A fin de cuentas, en la mayoría de los casos el código no iba a ser más que una línea dentro de un onXXXXX="....". Y ahora no pueden forzarlo porque millones de páginas dejarían de funcionar.
Para mi es igual que no poner las llaves en los IFs en C cuando es solo una línea: sí, te ahorras dos caracteres, pero cuando andas jugando con código es un coñazo el "vale, voy a añadir algo en el if, así que tengo que meter llaves; ahora lo quito, y como me queda una sola línea, tengo que quitar las llaves para que quede consistente en estilo de código" (harto me tienen en gnome con las llaves cuando me revisan el código). Y además, cuando anidas ifs con elses tienes que tener cuidado porque puede haber ambigüedad (de hecho, por culpa de eso un parser LARL "puro" no puede analizar C correctamente), y es algo que se te puede pasar fácilmente y te obliga a revisar el código con cuidado hasta llegar al momento "soy imbécil, cómo no vi esto".
Acepto que a ti te de igual, pero para mí, que un lenguaje permita este tipo de ambigüedades me parece un fallo muy gordo, porque el tiempo que puedes perder depurando lo que no es más que un error sintáctico es muchisimo mayor que el que pierdes poniendo puntos y coma siempre, o llaves siempre (por cierto, lo de omitir las llaves en C, si no me equivoco, era para reducir las pulsaciones necesarias en los viejos, y lentos, terminales serie que se utilizaban en los primeros sistemas de uso compartido con Unix...)
#36 De hecho, completando lo que te escribí en 37 hace un rato (ya no puedo editar), te añado una página del libro del estándar C89 (el famoso de la C azul en portada) donde habla del if ... else y de la posibilidad de ambigüedad: el propio libro avisa de que es fuente de errores que pueden ser difíciles de pillar, lo que, en mi opinión, es una forma encubierta de recomendar usar siempre llaves (fíjate en el ejemplo que pone al final de la página y lo que dice de él). Obviamente no pueden coger y obligar a usarlas siempre porque entonces todo el código C pre-ANSI no compilaría, pero para mí está claro lo que quieren decir.
A fin de cuentas, cuando se inventó C, Kernigan y Ritchie trabajaban con terminales electromecánicos, que imprimían en papel a menos de diez caracteres por segundo. Evitar líneas y caracteres superfluos era una necesidad. Pero hoy en día eso no es necesario.
#38 En el caso del if estoy de acuerdo contigo (he ido cambiando de opinión a usar las llaves siempre), pero en el caso del punto y coma no porque básicamente nadie escribe 2 sentencias en la misma línea y, por lo tanto, es muy difícil provocar esos problemas, que son casos muy poco comunes, por no decir completamente esotéricos o contrarios a cualquier recomendación.
Las pocas veces que empieza la línea con [ ó ( compensan la increible pérdida de tiempo de poner los puntos y coma, configurar el editor para que lo haga automáticamente, el espacio en disco y, sobre todo, el ruido visual que no aporta nada de nada.
Como nota final, en lenguajes como Rust o Erlang tiene un significado, por lo que se puede aceptar, pero en JavaScript, desde mi punto de vista es una pérdida de tiempo en todos los sentidos.
#39 Pues qué quieres que te diga... la media hora que me pasé las dos veces que me ocurrió, no se las deseo a nadie. Y el código no tenía nada de esotérico, simplemente era uno de esos casos en los que escribes para adelante concentrándote en el algoritmo y se te escapa. E insisto: desde el momento en que no es que javascript no necesite puntos y coma, sino que los añade automáticamente en determinados casos, considero que es mejor ponerlos siempre. Lo del espacio en disco, honestamente, hoy en día no es excusa, ni "el tiempo que tardas en ponerlo": eso es automático, no se pierde tiempo. Y de ruido visual, tampoco: desde el momento en que hay casos en los que te interesa, para evitar líneas muy largas, dividir un comando en varias líneas, tener un elemento que te deje claro de un vistazo en donde acaba un comando y empieza el siguiente es todo lo contrario a "ruido visual".
Por cierto, cuando terminemos de discutir esto, si te apetece podemos seguir con "espacios vs. tabuladores"... creo que tenemos las mismas probabilidades de llegar a un punto común
#40
Pues a mí lo del ruido visual sí me molesta. Es decir, cuanto menos caracteres haya en pantalla mejor. Por eso también prefiero las comillas simples a las dobles (cuando no cambia el significado, que hay lenguajes en los que sirven para cosas diferentes).
No entiendo bien tu comentario: precisamente los puntos y comas sirven para tener esas líneas muy largas al poner varias instrucciones en la misma línea. No usándolos y recurriendo siempre a escribir cada cosa en una nueva línea evita eso. Y si se escribe todo en una nueva línea, añadirle el punto y coma al final es tan útil como añadir un comentario vacío.
He pasado de pro-tabulador a defensora acérrima de los espacios, así que conozco lo mejor de ambos mundos .
#41 El problema en Javascript es que, en realidad, y por debajo, sí se necesita el punto y coma para terminar una instrucción; lo que pasa es que el parser lo añade automáticamente en la mayoría de los casos. Y no lo digo yo, lo dice el estándar (http://es5.github.io/#x7.9). No es que diga "los puntos y coma son opcionales", sino que, literalmente, lo denomina "añadido automático de puntos y coma". Y aunque funciona en el 99% de los casos (y este es el problema) hay una serie de casos no tan raros en los que no lo hace bien, y te vuelves loco/a para encontrar el problema. El motivo es que necesita encontrar un "token no válido", lo que significa que si pones algo en dos líneas consecutivas que, de manera separada es sintácticamente correcto (y, además, es justo el comportamiento que quieres), pero uniéndolo en una sola línea también lo es, no se insertará un punto y coma automático y se interpretará como si fuese una sola línea. ESE es el problema, porque esas construcciones, aunque no son muy comunes, existen. Y precisamente que sean tan poco comunes es donde reside su gran peligro, porque escribes para adelante asumiendo que tu código va a funcionar, y de pronto te da una bofetada. Y lo siento, pero un lenguaje en el que tengas que estar atento a algo así, para mí, es un lenguaje mal diseñado. Precisamente por eso me gusta Python: porque es el indentado quien decide donde va cada cosa, con lo que lo que ves es lo mismo que entiende el parser. Ahí sí que no son necesarios ni puntos y coma ni llaves ni nada raro
De hecho, la primera vez que me pasó yo no tenía ni idea de qué iba el problema (era novato en Javascript), y fue después de mucho buscar que, de rebote, llegué a una página donde explicaban cómo el parser añadía automáticamente el punto y coma, y cómo, aunque funcionaba en general, podía dar problemas con varias construcciones. Y justo ahí encontré la construcción que me había dejado como regalito mi compañero.
Y vaya, coincidimos con tabuladores vs. espacios... ¡yo también soy un converso!
#42 Conocía el problema, y coincido contigo en que es un problema grave de diseño, pero, mientras no se cambie, me sigue pareciendo que es mejor evitar los puntos y comas en la medida de lo posible.
#44 Pues definitivamente no nos pondremos de acuerdo, porque en mi opinión, precisamente la única manera de evitar el problema es poniendo siempre puntos y coma, pues así evitas que se te cuelen los casos raros en los que son necesarios 😇
#45 No pasa nada, simplemente si algún día tuviera que mirar algún proyecto tuyo pensaría "anda que éste, en el siglo XXI y aún con los puntos y comas". Pero como buena programadora, aceptaría tu decisión y seguiría las convenciones del proyecto.
#46
#41 Y añado a mi comentario de 42 (que ya no puedo editar)... perdona si soy demasiado verboso, pero me gusta ser lo más preciso y explícito cuando hablo, no me gusta dejar nada a la interpretación... lo cual creo que se extiende a mi forma de programar
#17¿ Ya han resuelto lo del Batman?
https://www.destroyallsoftware.com/talks/wat
#5 Yo coincido con lo de la sintaxis horrorosa. Este confinamiento empecé a cacharrear con él y es horroroso. Ruby también es dinámico y le da mil vueltas en cuanto a legibilidad y elegancia, además de tener una librería standard muy completa. No sé si tendrá tantas librerías como Python, pero yo estoy haciendo un desarrollo casero para IoT con Ruby para la parte de control desde el PC y no he echado en falta nada. Y además tiene Rails que es una maravilla para el desarrollo web
#23 Ruby que una coherencia interna y elegancia que hace que Python parezca hecho por un amateur (hoy añado orientación a objetos, pero sólo para algunas cosas, en otras que usen funciones, mañana convierto los `print` en funciones, etc.). La única cosa que me gusta es el tema de identación, que me encantaría poder tener en Ruby ambas para evitar algunos `end`.
Tengo la desgracia de trabajar en proyectos con Python y es que veo siempre chapuzas por todos los lados de estudiante de primero; en contraposición, cuando he trabajado con Ruby sólo he coincidido con excelentes programadores que cuidan lo que hacen. Supongo que será sólo mi experiencia.
#2 Pues ya lo dice el artículo. Como el BASIC de nuestra era.
#3 Python es el lenguaje estrella para llamar a librerías de Inteligencia artificial implementadas en otros lenguajes.
#16 Y el martillo es la herramienta estrella para clavar cosas de otro material en otro, por mucho que tengas clavos, sin el martillo no haces nada.
Pues sin python, o R no hay IA, por mucha librería en C++ que haya. (por algo será)
#18 con la velocidad de ejecución de Python poco algoritmo útil vas a poder implementar.
Python solo es la interfaz para que gente sin formación específica en programación pueda cacharrear.
#22 La gracia está en usar los módulos apropiados cuando sea posible. Por ejemplo, numpy está hecho en C y es muy rápido.
#25 eso digo.
#16 Exacto. Es el pegamento que une un montón de librerías fantásticas implementadas en otros lenguajes. Como lenguaje es una castaña lenta, ineficiente y que induce a todo tipo de errores. Muy bueno para proyectos pequeños o medianos que tengan muy pocos casos de uso.
Yo he tenido la suerte de aprender a programar directamente con python.
Soy ingeniero de datos y para los que creamos scripts y pequeñas aplicaciones de ETL, python lo tiene todo. Muy legible, una enorme cantidad de librerías con muy buena documentación, simpleza...
No soy desarrollador y no sé hasta que punto python es mejor para desarrollo de grandes proyectos. Para lo que lo uso yo dame python y llámame tonto.
#1 Pues es el lenguaje estrella de la inteligencia artificial, asi que es muy recomendable saber usarlo
(esto va por tu ultima frase)
#3 Sí. A día de hoy la generación de modelos se hace con Python y R (este último sobre todo a nivel científico y académico).
Con grandes proyectos me refiero a proyectos que requieran un gran equipo coordinado y mucho tiempo de desarrollo.
#3 es el lenguaje estrella para hacer investigación en inteligencia artificial.
Pero para desarrollo de productos finales con inteligencia artificial, o sea, para hacer productos terminandos se atasca, sobre todo para plataformas con escaso o nulo soporte de python
Por eso hay tanto proyecto de IA super prometedor que se acaba quedando... En eso, prototipos, experimentos, etc.
#13 el python es el nuevo grafeno?
#3 no te creas.
Me gusta mucho esta noticia, porque siempre he dicho que mi opinión sobre Python es más o menos la misma que tenía Dijkstra sobre Basic .
#19 Por ilustrar un poco, esto era lo que decía Dijkstra sobre el BASIC.
Es prácticamente imposible enseñar una buena programación a los estudiantes que han tenido una exposición previa a BASIC: como programadores potenciales, son mutilados mentalmente más allá de toda esperanza de recuperación.
Pero es que el BASIC de entonces sí que era una verdadera patata, con los números de línea, casi sin sentencias de control, usando GOTO como cosa normal, etc. Por eso me parece un poco bestia tu comparación. Por aquí hablan del tema:
https://programmingisterrible.com/post/40132515169/dijkstra-basic
Lo que marca la diferencia de verdad es que sea un lenguaje tipado fuerte, lo que posiblita hacer refactorizaciones automáticas. Para "cacharrear" vale, pero sin el tipado fuerte es un infiero en cuanto a mantenimiento de código.
Si se ha puesto de moda es porque todas las librerías de IA van con este lenguaje y ahora está pegando muy fuerte el tema en el mundo científico
Python es un lenguaje para pequeños scripts
Es un lenguaje estupendo para scripts sucios, de usar y tirar. Un lenguaje sin tipos es un infierno en un proyecto grande por un motivo muy simple: un lenguaje fuertemente tipado permite hacer muchos más controles en tiempo de compilación.
Todo lo que no sea ensamblador es de maricones, aunque lo más que he hecho en ensamblador es una práctica de la universidad donde me daban el programa medio hecho.
#8 Me he pasado media vida programando en ensamblador.
Soy programador a nivel de uP, cachivaches y demás.
Ahora también programo en C/C++ y la verdad es que con ensamblador y C no son necesarios otros lenguajes para lo que yo hago, of course