Fin de año

Probablemente este sea la ultima entrada del 2006 :) Asi que a quienes me conocen y de casualidad leen estas lineas... les deseo un feliz año nuevo. La excusa de este blog, es la de tener una motivación para analizar los libros y papers que voy leyendo, creo que es una práctica recomendable: la actividad de pensar en las conclusiones o en lo que quería escribir, me generó más preguntas e hizo que viera algunas cosas que se me habían pasado de largo. Pero... la falta de periodicidad de los posts, es un reflejo de que la actividad de sentarme y plantearme lo que quiero escribir acerca de lo que lei, lleva bastante tiempo (no sé como hacen esas personas que escriben todos los días... pienso que viven para el blog!). Para contrarrestar eso voy a hacer un repaso rápido de las cosas que estuve leyendo (quizás en los próximos posts retome lo que me interese un poco más): Filosofía: Introducción al pragmatismo: Si alguna vez escucharon la frase "modelar la realidad", este librito viene muy al caso, aunque hace honor a la palabra introducción: es corto y no profundiza mucho. La primer parte me pareció algo densa, Rorty se dedica a introducir a todos los filósofos pragmatistas, y por lo tanto hay muchos nombres y referencias a cosas que no conozco. En especial me hubiese gustado que profundice más en algunos temas donde la filosofía pragmatista no me convence, su relación con la ética sobre todo. (no creo estar al nivel de agregar un post que hable más a fondo de los temas del libro... por que conozco poco y nada de filosofía). Qué es la filosofía?: Recien empiezo a leer este libro... y hasta ahora me resulta ameno y muy interesante :) Sistemas: Peopleware: Muy recomendable para todo aquel que trabaje en sistemas, no importa si es lider de proyecto, gerente o programador. (creo que quizas agregue al blog algún post sobre este libro... y si me es más fácil escribir sobre cosas que conozco mejor) Como clasifico este libro...(Matematicas? AI? Filosofía? O todo eso...) Göedel Escher Bach: Un libro GROSO, y no solo en cantidad de páginas. Recien voy por la primer parte. Hasta donde leí se podría decir que el libro trata básicamente del teorema de incompletitud de Göedel... pero eso sería quedarme muy corto: habla sobre sistemas formales, representaciones, inteligencia artificial, mezclando comentarios sobre la obra de Bach y Escher (como hizo el autor para conocer tanto!!) Otros: El capitán salio a comer y los marineros tomaron el barco: Es un diario personal del ultimo tiempo de Bukowski, con algunos dibujos de Robert Crumb (uno de los que dibujo American Splendor). Bueno y asi termina el ultimo post del año, quizás el año que viene le de algún giro a lo que publico en el blog... y si tengo tiempo agregue algún que otro dibujo...

JavaScript

En octubre, Hernán va a dar una charla en la UTN sobre lenguajes con prototipos (y en particular va a dar algunos ejemplos en Self). Yo voy a participar de esa charla, hablando a lo ultimo sobre JavaScript, para mostrar a una audiencia que en general esta acostumbrada a pensar que programar en objetos es definir clases, que los lenguajes orientados a prototipos no son una cosa bizarra, y que en realidad cuando navegan en Internet utilizan programas basados en prototipos todo el tiempo.

Hace mucho que no hacia nada en JavaScript, y en este "flashback" de ponerme a programar para un browser encontré un par de cosas:

• Mientras programaba me acordaba de lo que a veces decía Máximo en sus charlas en Mercap: una vez que uno realmente aprende a trabajar con objetos, la forma de pensar los programas cambia, ya no importa que el lenguaje que uno utilice no sea de objetos “all way down” como Smalltalk. Uno se acostumbra a pensar los problemas en términos de objetos. Esto lo note a la hora de escribir el programa, la verdad es que me resultaba muy engorroso pensar en "funciones" sueltas y cierta funcionalidad que empece a escribir en "funciones" termino en objetos.

• JavaScript es un lenguaje que permite hacer muchas "chanchadas": tiene una sintaxis que fomenta más los pequeños "hacks" que un modelado con objetos. Sin embargo permite cierto grado de flexibilidad que facilita la escritura de algunas cosas que en Java serían muy, pero muy engorrosas: por ejemplo tiene la posibilidad de crear "clausuras", las funciones son objetos y uno puede agregar ó quitar métodos de cualquier objeto incluso de los supuesta mente "primitivos".

• Cuando hace ya casi 4 años atrás ó más (oops me estoy volviendo viejo) hice cosas en JavaScript, lo que había en Internet eran todos pequeños hacks para hacer algún que otro efecto en el browser: rollovers, menús desplegables y algunos más "avanzados" escribían juegos que nunca funcionaban bien. Hoy hay un montón de aplicaciones, lo cual siendo un lenguaje con limitaciones de performance y modularización habla de la necesidad que existe de tener aplicaciones más "pesadas" que sean muy fáciles de acceder en Internet.(no olvidemos que AJAX pese a todo el hype que tiene alrededor no es más que un sucio hack, para resolver con una conexión HTTP cosas que podían implementarse mejor con una aplicación X hace mucho tiempo atrás). En este sentido creo que el framework de WPF de M$ va a sacudir un poco las cosas. No por que sea una tecnología novedosa, como siempre M$ copia cosas existentes. Si no por que M$ tiene una gran poder a su favor: no solo mueve una gran cantidad de usuarios, si no que tiene la facilidad para crear todo un mercado, por ejemplo ya anunciaron una edición del New York Times en versión WFP.

En fin, lo que hice este finde fue un "workspace" (ala Smalltalk) para evaluar código JavaScript en el browser e inspeccionar los objetos (pueden usarlo haciendo click acá). Pienso utilizar este workspace para mostrar los ejemplos en la charla.

Code Katas

Este sitio, contiene bajo el nombre "cool" de CodeKatas, una serie de ejercicios de programación (parece que la gente de Ruby tienen gran facilidad para crear nombres marketineros). En las artes marciales las formas (katas) son utilizadas para practicar y perfeccionar la tecnica. La intención de un "code kata" es similar: hacer pequeños ejercicios de diferentes maneras, de forma de adquirir práctica en la programación. (suena comico) Al mirar los problemas que plantea la página me lleve una desilusión: solo dos de los katas (KataOne y KataEigth) me parecieron interesantes, el resto me parecieron problemas de algoritmos que no aportan nada. Por eso me gustaría plantear "katas" similares, pero más orientados al diseño con objetos. En futuros posts ire agregando distintos problemas (y si tienen alguna idea escucho comentarios).

Programming as theory building (2)

Este post es una continuación del anterior que trataba sobre el artículo Programming As Theory Building de Peter Naur. Había quedado pendiente el planteo de las consecuencias de ver a la programación como una construcción de teorías. Las que extraje del artículo son: Modificar un programa no es modificar un archivo de texto.

In a program modification an existing programmed solution has to be changed so as to cater for a change in the real world activity it has to match. What is needed in a modification, first of all, is a confrontation of the existing solution with the demands called for the desired modification.

Esto significa que para poder hacer una modificación es necesario que el programador entienda la teoría detrás de la solución existente, de forma tal de poder confrontarla con los nuevos requerimientos. Por lo tanto puede ocurrir que la modificación "encaje" con la teoría existente, o bien sea inconsistente con ella y termine siendo un parche desconectado del resto del programa. Pretender que cualquier programador puede fácilmente cambiar la funcionalidad existente viene de pensar en los programas como si fuesen solo texto: "Parte de esa funcionalidad esta hecha en el sistema, simplemente habría que agregarle un par de cosas, debería ser muy sencillo" (total que tan difícil puede ser agregar una líneas de texto). Documentar no es suficiente.

The problem of education of new programmers in an existing theory of a program is quite similar to that the educational problem of other activities (...). The most important educational activity is the student's doing the relevant things under suitable supervision and guidance. In the case of programming the activity should include discussions of the relation between the program and the relevant aspects and activities of the real world, and of the limits set on the real world matters deal with by the program.

Es decir para poder entender un programa existente, es necesario comprender la teoría detrás del mismo. Esta compresión plantea el mismo problema que en otras areas de la educación. Cierto tipo de documentación ayuda, pero la transferencia persona a persona y la "práctica" guiada (pair programming por ejemplo) son más importantes que la documentación. (es como si uno quisiese aprender Análisis Matemático solo leyendo un libro, sin ayuda y sin hacer ejercicios) No hay un método de programación que sea el correcto.

As to the use of particular kinds of notation or formalization, again this can only be a secondary issue since the primary item, the theory, is not, and cannot be, expressed, and so no question of the form of its expression arises. It follows that on Theory Building View, for the primary activity of the programming there can be no right method.

Esto no invalida la aplicación de métodos, lo que indica es que solo son prácticas complementarias. Es decir pretender que uno puede crear buen software siguiendo al pie de la letra un método de desarrollo es erróneo, por que la actividad principal en la creación de software según este punto de vista es la elaboración de la teoría, es decir la adquisición de conocimiento que depende mucho de la persona y del "problema" a enfrentar. Luego en lugar de adoptar un método para la construcción del programa en si, es mejor centrarse en prácticas que ayuden a la construcción de teorías:

the quality of the theory built by the programmer will depend to a large extent on the programmer's familirity with model solutions of typical problems, with techniques of description and verification, and with principles of structuring systems consisting of many parts in complicated interactions.

Por ejemplo design patterns, test driven development y modularización. Cambio en el "status" del programador. Quizás este sea para algunos el punto más controversial, ya que para muchas prácticas de ingeniería de software se asume que la programación es similar a la producción industrial, donde el programador es un componente más de la cadena de producción.

On the Theory Building View the primary result of the programming activity is the theory held by the programmers. Since this theory by its very nature is part of the mental possession of each programmer, it follows that the notion of the programmer as an easily replaceable component in the program production activity has to be abandoned

Esto también plantea un desafío para la educación de los programadores, ya que si bien es importante conocer los aspectos técnicos, se debería poner énfasis en la formación de teorías.

Programming as theory building (1)

Hace bastante tiempo me habian mencionado el articulo Programming As Theory Building de Peter Naur... y hace poco consegui una copia (lamentablemente este articulo no esta en formato electronico para bajar en la web). Les cuento de que trata: La idea del articulo es aportar una contribución al entendimiento de "¿Qué es programar?". El mismo se divide en dos partes:

1. La programación vista como una construcción de teorias
2. Cuales son las consecuencias de ver a la programación como una construcción de teorias.

Para argumentar por que programar es construir teorias, Naur primero da dos ejemplos (basados en su experiencia personal) sobre el conocimiento adquirido por los programadores durante la creación de un programa. De estos dos ejemplos solo voy a mencionar el primero: Dos grupos de desarrollo A y B realizan un compilador. La idea no es que B reinvente la rueda, si no que utilize lo desarrollado por A. Por lo tanto el grupo A diseña y documenta el compilador de forma tal que pueda ser extendido. Cuando el grupo B comienza a extender el trabajo de A, muchas veces no utilizan las facilidades que poseia el compilador y que además habian sido discutidas en la documentación, en general las propuestas de B eran parches. En su lugar los miembros del grupo A eran capaces de proponer soluciones más simples, efectivas y enmarcadas dentro de la estructura del compilador. Esto no se debía a problemas del grupo B: que era capaz y estaba muy motivado. Al parecer la documentación no habia logrado transmitir el entendimiento (insight) sobre la teoria que era inmediatamente presente para los miembros del grupo A. La conclusión a la que llega Naur es que para ciertos programas grandes, las modificaciones, adaptaciones continuas y correccion de errores, son escencialmente dependientes de cierto tipo de conocimiento que posee un grupo de programadores. Si la programación involucra la adquisición de cierto conocimiento, lo que sigue es hacer una analisis más cercano a ese conocimiento. Para esto Naur recurre a la noción de teoría utilizada por Ryle. Es decir, cuando el dice que programar es construir teorias, no utiliza la palabra teoria en un sentido abstracto (como por ejemplo la teoría mecanica de Newton), si no en el sentido que le da Ryle, como actividad intelectual:

What characterizes intellectual activity over and beyond activity that is merely intelligent, is the person's building and having a theory, where theory is understood as the knowledge a person must have in order not only to do certain things intelligently but also to explain them...

¿Y cuales son las consecuencias de ver la programación de esta forma?.... eso queda para el proximo post ;)

Posmodernidad

Estoy leyendo desde hace algunos dias el libro Posmodernidad de Ester Díaz (a los que hicieron el CBC en la UBA seguramente el nombre les resulte familiar). El libro comienza explicando que es la posmodernidad (término que ya había visto en algún que otro texto, pero del que no tenía la menor idea) y continúa luego hablando sobre la posmodernidad en diferentes esferas de la cultura actual: arte, ciencia, vida cotideana y sexualidad. Lo que lei hasta ahora me gusta. Bien por que el libro es una especie de disparador (da "puntas" para leer sobre otros temas) o bien por que el contenido me resultó bastante enriquecedor. En el sitio de la autora hay un articulo sobre la posmodernidad y las ciencias que da una pauta de los temas que se tratan en el libro.

The Learning Edge

Hace unos días me pasaron para leer el articulo The Learning Edge (Communications of the ACM vol. 49, nro.6). El articulo habla sobre la aplicación de Flow al desarrollo de software. ¿Que es "Flow"? Esteee... ni idea! La definición corta (sacada de la wikipedia y del articulo) es: Flow es una palabra utilizada para definir un estado alterado de conciencia en el cual se modifica enormemente nuestra habilidad para concentrarse y actuar. (suena a... suena a... si! a frase de Pablo Cohelo) En fin volviendo al articulo en si, el autor habla de tres "zonas" en la tarea de desarrollar software:

• Ansiedad: La tarea es demasiado dificil para el desarrollador, lo que genera una ansiedad de no conocer la tarea que tiene que realizar. (si a esto se le suman ciertas situaciones donde la capacidad del desarrollador es puesta en duda este estado puede causar mucho estres).
• Confort: El desarrollador es perfectamente competente para la tarea a realizar.
• Aburrimiento: La tarea es muy simple para el desarrollador por lo que se torna rutinaria.

El articulo habla sobre una zona entre Confort-Ansiedad, la cual llama "Learning Edge". Según el autor cuando los desarrolladores trabajan en esta zona tienen una alta posibilidad de encontrarse en un estado de "Flow". Por lo tanto es importante para la "productividad" de un grupo de desarrollo la tarea de investigar y enfrentarse con nuevos problemas. Sin embargo dice que generalmente se tiende a trabajar entre las zonas de Confort y Aburrimiento, lo que en ultima instancia deriva en una menor productividad. Muy interesante, especialmente para aquellos "project leaders" con una visión más taylorista del desarrollo de software, que piensan que la productividad viene dada en cantidad de lineas de código por hora.