Mitos de la programación: Las promesas falsas de Python
En el foro de programación de 3dgames surgió un agitado debate entorno al lenguaje de programación Python. Todo inicio a partir de la noticia del release de la versión 3 de dicho lenguaje, cuya promesa es limpiar el lenguaje de aquellos elementos que van en contra de su filosofía troncal, pero el primer release de dicha versión se encuentra adolescido por una perdida en performance. A esto muchos de los usuarios se pusieron a dudar sobre la pertinencia de dicha decisión, lo cual llevo a discutir aún sobre otros aspectos de dicho lenguaje, más allá de cual versión.
Estos son los debates que surgieron:
El mito del que acá quiero hablar es el mito de las promesas del lenguaje Python. El sitio dice:
Python is a dynamic object-oriented programming language that can be used for many kinds of software development. It offers strong support for integration with other languages and tools, comes with extensive standard libraries, and can be learned in a few days. Many Python programmers report substantial productivity gains and feel the language encourages the development of higher quality, more maintainable code.
Aunque los primeros argumentos son comprobables, lo último es solo un deseo que se puede ver en su redacción como se deslindan de tal afirmación (Many Python programmers report… igual no son muchos 
… es broma). Lo cierto es que la promesa de productividad carece de comprobación, y la promese de mejora en calidad y mantenibilidad de código es totalmente mentira.
Hasta acá llega la postura políticamente correcta de Python, en cualquier otro lugar los python adictos van a defender ad nauseam la belleza del lenguaje.
Primero debemos recordar que no hay lenguaje que pueda garantizar la mantenibilidad, la calidad y/o la legibilidad del código, en dicho sentido cualquier promesa es vana. Siempre que haya en la tarea de programar la necesidad de mano de obra humana, esta disciplina va a depender de las capacidades literarias y comunicadores de los mismos para hacer del código fuente una pieza estéticamente agradable, legible, comprensible, mantenible por sus pares.
Ahora un lenguaje puede ser diseñado favoreciendo o entorpeciendo dicha tarea. Python hace esto último. Esto se debe al error de creer que el minimalismo, la simplicidad y lo dogmático es la combinación ideal para la elaboración de código fuerte en el aspecto estético-literario. Error que deviene en no comprender que dicho aspecto requiere consideraciones del área de comunicación y de una parte del diseño gráfico. Comunicación sobre todo, que es la falencia más grave de los programadores.
El punto clave es comprender que el código fuente es una pieza literaria. Es “leída” por otros además del autor, y estos “lectores” no necesariamente comparten la total comprensión del lenguaje usado, pero sí una base común cultural de como están estructurados los lenguajes de programación (o sea, no debe ser obligatorio conocer el lenguaje para poder leer código fuente escrito en el mismo, pero sí ser programador).
El código fuente es “redactado”, tiene una puesta en página y condicionantes estéticos que modifican la lectura. Esto es importante contemplarlo porque es la razón por la cual fue una mala decisión que el lenguaje dependa del espacio en blanco para delimitar bloques. La causa de esto, en mi opinión, fue mezclar inadecuadamente el paradigma funcional con el imperativo. El paradigma funcional hace uso del espacio porque su abstracción se sitúa sobre el lenguaje matemático que hace uso del espacio para poner en página las definiciones, pero esto solo funciona bien con el lenguaje lógico-matemático. El paradigma imperativo no comparte estas condiciones.
Hay varios otros puntos que muestran lo falente e inconsistente del lenguaje Python en lo que se refiere al aspecto estético-literario, varios de ellos discutidos en el debate que mencione arriba. Tratare de dedicarle algún tiempo a explicar algún otro, como, por ejemplo, porque está mal elegido el keyword “def” para definir funciones, que es un problema de retórica/comunicación.
Relatos tragicómicos de un moderador de foro de programación – Capítulo 0×03
Ultimamente estuve con mucho laburo, por lo que pase poco tiempo por el foro. Pero el show continua siempre.
No se como krugonN tiene tanta paciencia, o tal vez soy yo que perdí la habilidad.
Tratando de ayudar a sidpunk a resolver un tema de indexación en Google
Y después nos preguntamos porque es tan difícil iniciarse en la programación. Me quedo con una frase de Willar:
Y si hubiese leyes que regulen la programacion habria que meter presos a la gente que programa cosas que ya estan hechas.
No totalmente de acuerdo, pero, en la base de pensamiento, tiene merito.
Una interesante discusión sobre como manejar eventos del teclado en un videojuego.
Relatos tragicómicos de un moderador de foro de programación – Capítulo 0×02
Hablemos el mismo lenguaje estructurado y así las cosas irán mejor
Volví a recordar de mala manera porque Perl no me hace gracia… de paso quede como un boludo =] Keylogger en perl?? JA!
OK! I’ll buy Vista… but please no more Seinfeld & Gates!!!
Propuse festejar el día del programador con comida, bebida, y sin programar un carajo, y parece que la idea pego, aunque algunos la quisieron llevar un poco más lejos:
Che , y nos tocan el orto como los jefes pajeros a las secretarias en su dia?
Al parecer hacía mucho que alguien no sacaba el tema de que lenguaje pienso que es el mejor, porque otra vez con lo mismo, esta vez gráfico:
No me quede atrás con las sutilezas:
