¿Hacia un nuevo "modelo =?iso-8859-1?q?est=E1ndar?="?

[Chema Cortés]

El Martes, 2 de Noviembre de 2004 20:24, Ernesto Revilla escribió:

> yo creo que en general el modelo estándar es válido, pero quizá con
> respecto a lenguajes dinámicos, la parte de compilación cambien un poquito.

Erny, me ha parecido muy interesante tu reflexión. No quisiera verlo como una 
confrontación entre modelos, nuevos o viejos. Durante muchos años, se han 
propuesto muchos modelos y no puede decirse, todavía, que haya alguno que se 
haya impuesto sobre los demás. Yo sólo quería hacer hincapié en que los 
cambios provocados al "modelo estándar" por la irrupción del Eclipse pueden 
arrastrar consigo a otros lenguajes como python, aunque ya estuvieran 
asimilados algunos de estos cambios.


> En general, no creo que hayan cambiado muchas cosas. Hace tiempo decía
> que no se podía comparar directamente los programas en nº de líneas de
> código fuente, que se usaba como base de la Ingenería de Software. Eso
> era cuando trabajaba mucho con VB y Access. Es difícil comparar los
> formularios e informes, porque no generan nº de líneas, y si lo generan
> (internamente) ¿cómo puedo comparar eso con pantallas de Cobol y otros?
> Lo mismo con Oracle / SQL Forms.
> Desgraciadamente, tenía que modificar un poco mis pensamientos, porque
> con respecto a eso hemos sido lanzados de nuevo hacia atrás para
> movernos lentamente hacia adelante (Glade, etc.) Curioso es, que en
> general no soy más productivo que hace 15 años cuando trabajaba con
> herramientas 4GL en entorno MS-DOS, aunque las soluciones sean
> probablemente más bonitas y sean bastante más fáciles de aprender.
> (Probablemente, algunas pantallas sean algo más complejo.)
>
> Lo que sí me parece interesante:
> * trabajamos con sistemas de gestión de versiones. Inicialmente teníamos
> rcs que me parece un invento buenísimo, pero quizá los sistemas de
> versiones se han popularizado, y además son base del movimiento Open
> Source. * un marco de trabajo para pruebas (PyUnit/JUnit).
> * gestión de proyectos, normalmente integrado en un IDE. Efectivamente,
> escribir programas es mucho más que escribir líneas de código. Deseamos
> ver lo que estamos haciendo con respecto al resto, y encontrar
> fácilmente cualquier parte del programa. Además, lo que hecho de menos
> es algo para acelerar la escritura de documentación. PyDoc está bien,
> pero mejor sería que pudiesemos escribir documentación con algún editor
> Wysiwyg directamente en el código fuente.

El tema de mejorar la documentación está tratado por la "Programación 
Literaria" (http://www.literateprogramming.com). También añoro alguna 
herramienta para este tipo de escritura de código. Se podría escribir con un 
editor TeX como el "kile", pero lo ideal sería emplear directamente XML y así 
poder incrustar en el código cualquier formato XML (XHTML, SVG, MathXML, 
XML-encripted,...).

Para python, es posible escribir los comentarios con reStructuredText 
(http://docutils.sf.net) que, aunque no haya un editor wysiwyg, es un modo 
bastante simple de crear documentación en diversos formatos a partir de 
comentarios en texto plano. No sería de extrañar que Guido lo incorporara 
como "estándar" en alguna versión de python (ya ha hecho algún comentario al 
respecto).


> Hecho de menos un marco para embalar y entregar las soluciones. Los
> proyectos pueden tirar de un conjunto de librerías, y dada la cantidad
> de estupendos paquetes en Python es fácil que se junten 10 o 15
> librerías. no estaría nada mal de tener junto al gestor de proyecto las
> librerías que se usan y dónde se pueden bajar. Entonces, cuando lo llevo
> a un cliente, se podrían bajar automáticamente todo el software necesario.

También se está trabajando en éllo. Con distutils algún día se podrá descargar 
los módulos directamente desde el repositorio PyPI tal como hace Perl con el 
CPAN.


> Por las características de antes:
> * los proyectos pueden ser más grandes (gestor de proyectos)
> * integran una cantidad de componentes existentes (gestor de proyectos)
> * participan muchas personas (sistema de gestión de versiones, sistemas
> de seguimiento de fallos (bugzilla/mantis), herramientas de comunicación
> entre desarrolladores, y entre usuarios finales y desarrolladores
> (correo, mensajería instantánea, listas de correo)
> * requieren vistas de alto nivel (UML, otros tipos de notación)
>
> Así que no comparto realmente ese modelo estándar, porque para muchos el
> Chat es igualmente otra herramienta más que se utiliza para desarrollar
> código, igual que el sistema de seguimiento de errores y eso no aparece
> en el modelo estándar.

Ése es justo el punto de vista a que me refería en mi primer mensaje. En el 
libro que comentaba, dedica medio libro a explicar técnicas como testeo 
(JUnit), almacenaje (Hibernate), patrón MVC (WebWork), etc, etc. e incluso 
habla de cómo comunicarse a través de wiki, IRC ó bugzilla. Y eso es sólo la 
primera mitad del libro; la otra mitad ya trata del desarrollo de 
aplicaciones tipo. Por separado, no son técnicas innovadoras, pero en su 
conjunto sí que suponen un nuevo modo de proyectar el desarrollo de una 
aplicación, un "nuevo modelo estándar".


> Ahora, respecto a mi sensación de haber desarrollado algunas soluciones
> en Python (principalmente son soluciones donde he actuado como único
> autor): * me equivoco tecleando, y muchas veces estoy depurando sólo para
> llegar a la variable que he escrito mal, es decir, puedo correr el programa
> 10 veces para quitar errores de variables/tipos. Vi el tema de Boo, es
> decir, un lenguaje basado en Python, pero con Tipos estáticos (tanto como
> dinámicos) y me parecía muy interesante.
> * no tengo gestor de proyectos (uso PythonWin)
> * algunas veces, tengo problemas instalando el programa, porque tengo
> que bajarme no sé cuántas librerías (todavía me falta ese módulo de
> dependencias que instala automáticamente todo lo necesario)
> * para lo que hago soy más lento que la plataforma anterior (MS-Access)
> (todavía, aunque espero que eso algún día en los próximos 2 años cambie)
>
>
> Saludos,
> Erny
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: no disponible
Type: application/pgp-signature
Size: 189 bytes
Desc: no disponible
URL: <http://mail.python.org/pipermail/python-es/attachments/20041103/7428ebe1/attachment.pgp>
------------ próxima parte ------------
_______________________________________________
Python-es mailing list
Python-es en aditel.org
http://listas.aditel.org/listinfo/python-es