Por primera vez desde se inició el índice TIOBE hace casi 20 años, Java y C no ocupan las dos primeras posiciones. Así abren el anuncio en la web con los resultados del ranking para el mes de noviembre de 2020. TIOBE lleva casi dos décadas calculando la popularidad de los lenguajes de programación a partir del número de resultados en diferentes motores de búsqueda para las consultas sobre cada lenguaje. Si bien no es un dato sin sus críticas, puede medir relativamente el grado de interés online sobre los lenguajes en el tiempo.
Comentarios
#4 ¿qué propiedad mágica tienen las llaves sobre el scope de las variables que no se tenga -si se quiere- con indentaciones? Ninguna.
El scope es una cuestión de diseño de lenguaje. Las llaves no son necesarias si la identación es la que marca los niveles; exáctamente igual que la indentación no es necesaria más que por cuestiones de legibilidad si tienes llaves.
Lo que pasa es que cuando hay llaves también hay indentación porque si no no tienes legibilidad. Luego las llaves es lo que se puede eliminar, no la indentación.
Si no fuera por las indentaciones...
¿Tanto cuesta poner un fin para los for, if, whiles...?
#1 Sí. Sustituir corchetes y símilares por indentación es uno de los grandes aciertos de Python.
Igual que PEP8 para no tener debates sobre estilos.
#2 acierto las indentaciones? madre mía
Se puede saber en qué beneficia eliminar las llaves? Para empezar en Python incluso el bloque mínimo de ‘scope’ de las variables es a nivel de función / método precisamente por no tener llaves.
cc #1
#2 Yo creo que cuesta lo mismo escribir símbolos de cierre que indentar, supongo que es cuestión de gustos. A mí es que me va el C.
#5 por muchas llaves que pongas tienes que indentar igual para hacer el código más legible, así que las llaves es un añadido que puede sobrar.
Además la mezcla de espacios y tabuladores es una mala práctica, así que se puede ver como un plus que el propio compilador te fuerce a indentar bien.
Al final hay gustos y necesidades para todos, así que cada uno use lo que le guste o necesite en cada momento.
De Python me han fastidiado más algunos errores tontos que se dieron en tiempo de ejecución y que probablemente en otros lenguajes de hubieran visto al compilar que cómo se escriba o deje de escribir
#6 Cierto, de todos modos hay que indentar.
#6 Muy bonito todo hasta que tienes que copiar código de otro sitio, mover un bloque de tu código a otra parte, añadir un bucle o condición sobre un bloque de código que tenías escrito y entonces todo es caos en python. No sabes bien donde empieza y acaba, no sabes si tienes que poner o quitar tabuladores al pegar (si, hay que usar tabuladores, espacios no ), cuando copias de otro sitio no sabes si se va a copiar bien.
No se en que programas, pero a mí todo el sangrado me lo hace el IDE, que para eso está. Y lo puede hacer el solito gracias a las llaves que indican realmente donde empieza y acaba un bloque. Tampoco cuesta tanto poner unas llaves y dejas clarito todo tu código. El sangrado estará igualmente, y si no el IDE te lo puede hasta corregir.
#13 No se en que programas, pero a mí todo el sangrado me lo hace el IDE, que para eso está.
Normalmente los bloques lógicos de instrucciones relacionadas los separo con espacios verticales y nunca me ha pasado lo de no saber dónde acaba algo. En cualquier lenguaje te puede pasar que tengas que copiar un bloque de instrucciones lógicas dentro de una función grande y tienes que saber dónde acaba por el contexto.
Siempre suelo usar algún modo tipo vim del ide y para sangrar bloques selecciono un bloque y lo muevo a derecha e izquierda con una tecla.
Igual para ti es un problema insalvable, pero creo que tu queja es una minucia.
Veo más problema el mover código a proyectos con estilos de tabulación diferentes porque exige una disciplina que en otros lenguajes no es necesaria, pero programar de forma disciplinada también se puede considerar algo bueno.
#5 El C está muy bien para unas cosas y Python para otras
En general desconfío de cualquiera que quiere usar el mismo lenguaje para todos los problemas.
En 2020 todo son malas noticias
Python no es paralelo y es lento.
Es un lenguaje de scripting venido a más. Y eso se paga.
#8
Ah, y la ausencia de miembros privados en las clases es una genial idea.
#10 hay una cosa en Java llamada reflexión, gracias a la cual los miembros privados dejan de serlo.
(Ya puestos a buscarle los tres pues al gato)
#15
Si hubiera un lenguaje al que se le pudieran activar características según fuera necesario, sería genial.
Ah espera, que ya existe: C++.
cc #16
La reflexión, o introspección, si se usan es que algo estás haciendo mal.
En Python, sin reflexión ni introspección puedes acceder a todos los miembros de cualquier clase. Viene por defecto desde la primerita versión.
#17 ya veo, ya
#17 es todo convención.
Si pretendes acceder a los miembros "protegidos" en una clase de python (FYI: aquellos que empiezan por dos caracteres de subrayado __) es que algo estás haciendo mal
#19
El subrayado lo tienes que poner tú. No forma parte del lenguaje. El lenguaje no te va a avisar de nada, y el autocompletado te saca toda la mierda. Es maravilloso. Sin recurrir a nada especial como la reflexión o introspección.
#20 espera, que me entere bien. Debo haberte entendido mal. Te quejas de un lenguaje de programación, porque tu IDE hace algo que no debería (en tu opinión)
#21
No, señalo los fallos de un LP que no respeta lo más básico de encapsulación. https://stackoverflow.com/questions/24661886/why-make-class-members-private
Los que utilizan Python para ML porque no tienen ni idea de programar estarán contentos de regalar dinero a NVIDIA.
No tiene sentido obligar a indentar el código para luego «por convención» eliminar los miembros privados y protegidos. Oh, toda una maravilla de mantenimiento de código y compatibilidad de ABI y API.
La reflexión e introspección es una rotura explícita de la encapsulación segura, como el uso de la RTTI durante el remoldeado de punteros en C++. Mejor mantenibilidad, por favor.
#22 permíteme insistir en que la encapsulación no es más que pura convención. Lo mismo puedes acceder el API interno en Python (__ ), que puedes usar reflexión en Java por ejemplo. No deberías, pero allá tú: ya hablaremos cuando todo rompa en la próxima actualización. Mantenibilidad no es el principal problema aquí, sino los programadores chapuzas.
No entiendo qué intentas decir mezclando la indentación con la encapsulación, la verdad. Por favor no me pongas enlaces a stack overflow para dar verosimilitud a tus opiniones/gustos personales, que ya pinto bastantes canas. Ignoro tu edad pero por tu talibanismo... Mira chavalín, como puse en otro comentario there's no silver bullet.
De machine learning no te voy a opinar porque es una de las pocas cosas que no he hecho. Creo que lo dices por lo de los múltiples hilos, verdad? Ahí, de nuevo, creo que confundes lenguaje (Python) con implementación (CPython y su GIL). Si bien no es un problema insalvable, es verdad que es un coñazo en programación en paralelo. Pero siempre puedes optar por otras implementaciones como PyPy, cuyo rendimiento en programación multi hilo es mucho mayor ya que no tienen GIL. De este modo, no tiene limitación de 1 hilo de ejecución por núcleo de CPU. Yo no lo he usado demasiado, pero te puedo garantizar que su rendimiento es muchísimo mejor.
Aquí te dejo que se me pasó el momento all bran
#23
PyPy sigue teniendo locks (año 2017, y detallando cómo será el estado final): https://morepypy.blogspot.com/2017/08/lets-remove-global-interpreter-lock.html
PyPy no es 100% compatible con CPython. https://www.pypy.org/compat.html
Ni coñazo, ni coñaza. Python es un lenguaje de scripting venido a más: no tiene encapsulación, añaden clases e hilos sin tener multi-hilo. Y es lento, por ser interpretado (scripting).
Y el ML no lo mencionaba por los hilos. Lo mencionaba porque los que quieren usar ML para hacer sus cuatro mierdas de análisis y predicción utilizan los marcos de trabajo que regalan con las tarjetas de NVIDIA para usar con Python.
Así que, insiste en lo que quieras. No es pura convención. Es lo más básico de la programación y si no lo entiendes es tu problema, no el mío.
La reflexión e introspección (y remarco lo de introspección que obvias) en Java, como ya he dicho, es segura. Tiene mecanismos de seguridad que impiden realizar ciertas cosas y de las que se permite realiza comprobaciones en tiempo de ejecución. Como también lo tiene el remoldeado de punteros en C++ al utilizar la biblioteca de tiempo de ejecución. Eso es algo que ya he dicho e intencionadamente has pasado por alto porque desmonta tu hilo argumental de «eso es un punto de vista, opinión o gusto particular».
ya pinto bastantes canas. Ignoro tu edad pero por tu talibanismo... Mira chavalín, como puse en otro comentario there's no silver bullet.
Me parece que eres un dinosaurio que nunca has programado nada serio en su vida y vienes a hablar de opiniones en algo tan básico como es la encapsulación en un lenguaje que se le supone Orientación a Objetos, no scripting con objetos (lenguaje de scripting venido a más).
No hay balas de plata pero sí hay armas que aceptan distintos calibres.
#24 no, te equivocas. Lo he pasado por alto por dos motivos: 1 estoy con el móvil y no terminé de leer tu opinión personal por error, ya que no cabía en la pantalla. 2 terminé mi momento all bran, como dije en mi comentario anterior. Parafraseándote: seguro que lo pasaste por alto a sabiendas, verdad?
Pues claro que no es 100% compatible. La implementación de referencia sigue siendo cpython. Creo que sólo garantizan compatibilidad hasta Python 3.0, pero no estoy muy al día así que no me hagas demasiado caso y si te interesa algo míralo en su web.
Tienes razón, nunca he programado nada serio. Sólo llevo 15 años arreglando chapuzas de programadores Junior como tú, que todavía no saben desactivar el autocompletado en su IDE
Por cierto, mi principal lenguaje de programación no es python ni Java. Si bien me han puesto a cargo de varios proyectos bastante heavies escritos en tales lenguajes.
#25
Pues has empezado tú menospreciando, y continúas haciéndolo sin tener NPI. No quisiera haber estado en ninguno de esos equipos que has manejado.
no, te equivocas. Lo he pasado por alto por dos motivos: 1 estoy con el móvil y no terminé de leer tu opinión personal por error, ya que no cabía en la pantalla. 2 terminé mi momento all bran, como dije en mi comentario anterior. Parafraseándote: seguro que lo pasaste por alto a sabiendas, verdad?
Demasiada palabrería para ocultar que ignoras lo que no entiendes/rebate tus argumentos. Las negritas no van a ocultar la aplastante realidad: defiendes lo indefendible.
Pues claro que no es 100% compatible. La implementación de referencia sigue siendo cpython. Creo que sólo garantizan compatibilidad hasta Python 3.0, pero no estoy muy al día así que no me hagas demasiado caso y si te interesa algo míralo en su web.
Ni si quiera te lees los enlaces, ¿eh?
Cito textualmente: PyPy3 implements the Python language version 3.6.9. It has been released, but Python is a large language and it is quite possible that a few things are missing.
Para trolear hay que esforzarse un poquito más.
Sólo llevo 15 años arreglando chapuzas de programadores Junior como tú, que todavía no saben desactivar el autocompletado en su IDE. Por cierto, mi principal lenguaje de programación no es python ni Java. Si bien me han puesto a cargo de varios proyectos bastante heavies escritos en tales lenguajes.
Oh vaya, si te has ofendido
#26 exacto becario, no me leo tus enlaces... Estamos en menéame. Serás el único que los lee.
No me he ofendido, hombre. Parece que tú sí, cuando te contesté con programador Junior chapuza a tu dinosaurio que nunca ha programado nada serio
#8 there's no silver bullet
En román paladino: 10000000000 moscas no pueden estar equivocadas. Come mierda.
python = caca