Python es un lenguaje de programación bastante majo, pero con un fallo de base: está orientado al ámbito educativo. Todos los problemas que presenta Python, surgen de este afán educativo.

Y por mucho que soporte funciones lambda, paso de parámetros por nombre, y todos los programas sean inherentemente "fáciles de leer"... me da una sensación tipo odio visceral.

O sea, no es que me niegue a programar en Python, que vamos, mejor que peor se pueden hacer cosas muy guapas. Lo que pasa es que rara vez sería mi primera elección, y se me enciende como una gran luz roja de alarma cuando alguien me habla de mantener algo hecho en Python.

Estos son los motivos:

Python "incluye pilas"

Significa que lo máximo posible está hecho en Python. Incluso llamadas a funciones simples, que otros lenguajes traducen a llamadas a funciones en C o ensamblador, en Python están hechas en Python. Muy educativo... y muy poco eficiente.

No, en serio, es algo así como la antítesis de la optimización.

Sintaxis bonita a la fuerza

El arte de programar, aparte de la ciencia de programar, se llama arte porque el código resultante debe ser "bonito a la vista". Es otra forma de decir "fácil de leer" o que se pueda ver de qué va el tema con solo echar un vistazo, sin necesidad de realizar un análisis lógico-formal del código en sí. No es fácil conseguir código a la vez científicamente correcto y artísticamente bello, pero quien lo consigue es instantáneamente reconocido como un gran programador.

O eso debería ocurrir, porque en Python ¡todo código es igual de bonito!

Es más: el único código que funciona, es el que es bonito... WTF!?

Personalmente cuando tiro código, lo normal es que compruebe que funcione (vamos, si no funciona, como que mal asunto). Pero al mismo tiempo, dentro del código que "sí funciona", me gusta distinguir entre código bonito y feo:

• Bonito: código bien ordenado, espaciado, bien legible, comprobado, testeado y comentado. No habría que tocarlo en años.
• Feo: código que funciona, pero que he puesto a las tantas de la madrugada rápido y corriendo. Habría que echarle otro vistazo, y andarse con cuidado.

No es lo mismo que un "TODO". Al marcar algo como "TODO", significa que eso está pendiente de hacer, de limpiar, de comprobar... porque no se sabe si funciona bien, o porque directamente falta alguna funcionalidad.

El código "feo", es código que puede tener algún fallo, o puede requerir algún otro test, o que simplemente me gustaría refactorizar algún día cuando tenga tiempo porque creo que se podría hacer mejor, aunque por ahora funcione.

Python, no me deja escribir código feo, por lo que me obliga a apuntar las cosas en TODO por narices. Lo cual me obliga a distinguir TODOs "importantes" de "no tan importantes" de "poco importantes" de "a lo mejor esto ni siquiera es un TODO".

TODOs que no son TODOs... pues no me gusta.

Todos los programadores escriben código bonito

...incluso los novatos y/o paletos que no saben hacer la O con un canuto.

En un lenguaje como C, nada más ver un trozo de código se nota si el programador sabe ordenar las cosas o no, si sabe qué partes son más importantes o no, si sabe qué puede suponer un problema, o cómo ayudar a mantener ese código en el futuro.

En Python, tanto el más experimentado como el más novato, producen código con una pinta parecida. No basta con mirarlo por encima, hay que leérselo y analizarlo para saber si su creador sabe algo o sólo está escribiendo tonterías.

Porque vamos, todo programador escribe para que la cosa compile... y en Python, por narices, hay que hacerlo bonito para que compile.

Eso está mal, muy mal.

Python no usa corchetes

Este parece ser el motivo de usar espaciado para ordenar las funciones, y es que poner mal un corchete -en lenguajes que los usan- puede suponer cagarla de forma estrepitosa. En Python, no se puede cagarla poniendo mal los corchetes; nada más escribir un trozo de código, se ve claramente si está bien espaciado o no.

El problema viene de que para poner bien los corchetes, hay que pensar sobre el flujo lógico del programa. Como mínimo, pensarlo un par de veces, y puede que más. En Python con una sola vez basta, lo que hace que los flujos lógicos estén menos pensados.

Es el mismo motivo por el que los programas en Java rara vez fallan en los flujos lógicos o en integración; la exigencia de ser explícito, obliga al programador a pensarse las cosas 4, 5 o hasta 10 veces. De esa forma, es más fácil detectar fallos, aunque suponga una paliza a la hora de querer cambiar cuatro tonterías.

Conclusión

Un lenguaje potente y completo, con una tonta limitación de rendimiento, y una fuerte pérdida de confianza a la hora de evaluar código ajeno.

Si a eso le añadimos que suele gustarle a gente próxima a la mentalidad universitaria, y por tanto dispuesta a reinventar la rueda cada dos por tres... ya la hemos terminado de liar.

Y es una verdadera lástima, porque tiene algunas cosas muy interesantes.