Re: anti-python?

El 27 de agosto de 2009 23:45, Juan M Puertas<[email protected]> escribió:
>  Siempre se podría hacer un Python más cómodo aún.
>  Ahora no lo encuentro, pero hace poco ha salido un lenguaje basado en Python en el que no necesitas "import"; supongo que sólamente con la biblioteca estándar. :-)
>  Es decir, si escribes: "s = sin(p)", interna, invisible, y automáticamente es como si el programa escribiese: "from math import sin"

No se si te refieres al lenguaje "boo", aunque no diría que es un
lenguaje reciente.

En python se optó por ser "explícitos" hasta el extremo de estar
incluído como regla en el Zen de python ('import this'). Lo de los
imports implícitos no suele ser una ventaja a la larga, puesto que
pasado un tiempo llegas a olvidar concretamente qué estaba importado
implícitamente y qué no (yo tengo que examinar muchas veces el
__builtins__). Es mejor que tu código muestre explícitamente todo
aquello que necesite para funcionar, al menos sirvirá como ayuda a los
demás si quieren estudiar y probar tu código.

>  Para mi, la comodidad sería una gran evolución para cualquier lenguaje, que aquellas cosas que éste pueda hacer por ti, las haga, aunque siempre te deje la puerta abierta para hacerlo a tu manera.
>...
>  Una de las pocas pegas que he encontrado con Python, es que hace algunas cosas de una manera muy distinta a la mayoría de los lenguajes, por ejemplo; para declarar una matrix de tres dimensiones, así como algunas abstracciones que son un poco raras, pero que hacen la delicia de muchos como Chema. ;-)

Algunas veces no he podido disimular una sonrisa cuando alguien me
explica entusiasmado cómo ha conseguido crear "colecciones" con las
STL para C++ para procesar conjuntos de objetos, algo que en python se
hace sencillamente con una lista o un diccionario.

No creo que haya un único modo de hacer las cosas; si otros lenguajes
te parecen distintos a python es porque todavía te falta ver cómo se
las tienen que apañar con esos lenguajes.

Precisamente, estos días estoy revisando la "Intentional Programming"
ideada por Charles Simonyi (a quien microsoft debe toda la metodología
empleada en sus desarrollos). Este hombre tiene una visión de la
programación estratificada por niveles, donde el programador tendría
total libertad para crear su código siempre y cuando cumpla la
"metaprogramación" impuesta en un nivel superior. Para hacer esta
tarea, los programadores tendrían disponibles herramientas visuales
que mejoren la codificación, muy similar al WYSIWYG (también inventado
por Simonyi) empleado para procesar textos.

Ni que decir tiene que microsoft se ha ido por otro camino, el .Net, y
que Simonyi está desarrollando su "Intentional Programming" por su
cuenta.


Aunque no coíncido en todo, sí que coincido con el uso de la
"metaprogramación", entendiendo por tal las herramientas generadoras
de código a partir de pequeños códigos sencillos de programar. A veces
los programadores nos empeñamos en abstraernos rápidamente del dominio
de aplicación para así iniciar la codificación, menospreciando la
experiencia que podrían brindarnos los usuarios dentro de sus dominios
(financiero, gestión, etc). La metaprogramación podría servir tanto
para adaptar el código a la cultura propia del usuario como permitir
que sea el propio usuario el que codifique los parámetros de su
aplicación (cálculo de intereses, ponderaciones, etc). Sería un poco
llevar los generadores de código para GUIs al siguiente nivel.

En el lado práctico, no he encontrado nada de metaprogramación para
python. Sólo "metalua" <http://metalua.luaforge.net>.
_______________________________________________
Lista de correo Python-es 
http://listas.aditel.org/listinfo/python-es
FAQ: http://listas.aditel.org/faqpyes