Norberto, Me leiste la mente.
Comento algunos insights que encontré absurdos: 1. "es posible pensar mucho y muy analíticamente sin llegar a ninguna parte". Es posible llegar a contradicciones o contradicciones aparentes. Si llegas a alguna parte o no, es cosa de prueba y error (el método científico). La base de la ciencia es el descubrimiento y el descubriento es por definición impredecible. Eso de "sin llegar a ninguna parte" es sólo un punto de vista. Otra persona podría decir lo contrario ante la misma situación. 2. "[Programar] Es un pensamiento tendiente más a lo analítico-racional que a lo intuitivo, como el del matemático, pero no tanto, y por eso no somos matemáticos." Discrepo profundamente de esa frase. Me inicié en el mundo de la programación programando juegos y los mejores juegos eran los que usaban fórmulas matemáticas. No sólo andaban más rápido, sino que los resultados eran mejores. Programar al fin y al cabo no es más que realizar transformaciones algebraicas. Quienes no lo hacen así, escriben tremendos enredos que funcionan mal y son inmodificables (frágiles). Peter Naur sostiene que programar es equivalente a la construcción de teorías. 3. "Llevándolo al extremo, cuando la economía ha logrado una simplificación total, no hace falta programar." Amén. Suena absurdo, pero históricamente ha ocurrido lo mismo en casi todos los ámbitos de la actividad humana. Por eso hoy en día no existen escribas ni herreros. En el ámbito de la programación, las especificaciones serán ejecutables. Es el equivalente a decir que habrá un programa universal que resolverá todo, sólo necesitará conocer las especificaciones y ejecutarlas directamente. Es interesante, pero más interesante seŕa cuando la Economía como disciplina se encuentre resuelta. Entonces se acabará la escasez, y en un mundo sin escasez los precios tienden a cero. Es un poco lo que estamos viviendo, excepto para bienes que no pueden ser creados, como los bienes inmuebles que se disparan de precio porque el terreno no puede ser creado. 4. " los tests me están ayudando a economizar, no el código, si no mi propia actividad mental." Llevándolo al extremo, se podría pensar que un módulo genera tests que son importantes para lograr un resultado y otro módulo genera el programa que pasa esos tests. Ambas actividades son automatizables. El primer corolario es que el programador dejará de ser necesario y el segundo corolario es que los sistemas que podremos construir serán cada vez más grandes. Diría que el límite hoy en día es la imaginación del cliente y no la capacidad de programar el sistema (a menos que estés aprendiendo a programar). 5. "me ha pasado que el browser se me tare y me modifique las variables asignadas" Suena remal. Yo escribiría el browser de nuevo usando tests para todo, o lo instrumentaría para ver porqué se tara. Si estás construyendo un edificio de piezas lego, primero asegúrate que las piezas estén bien. Si ignoras los defectos de las piezas y luego construyes un artefacto para controlar la caida del edificio, puede ser mucho más esfuerzo y no lograr los resultados esperados. Al fin y al cabo lo importante es tener claro los objetivos de largo plazo y tener un plan coherente que muestre la luz al final del túnel. Saludos, Guillermo. 2009/11/15 Norberto Manzanos <[email protected]> > Muy buena discusión. > > > Aporto algunas ideas, probablemente muy teñidas de subjetividad, pero que > tal vez aún así sirvan para algo. > Trabajar intensivamente con tests fue uno de los cambios más importantes en > mi vida como programador, tal vez tan importante como pasar de Pascal a > Smalltalk. Siempre me pregunto porqué suceden este tipo de cosas, tratando > de centrarme no tanto en el objeto, es decir, la tecnología, si no en el > sujeto, es decir, la mente del programador, o sea, la mia. Hernán dice al > pasar que aplicar test es tirarle el trabajo a la computadora para poder > pensar más en otras cosas y esto me parece que es un aspecto fundamental. > Esto me lleva a una pregunta que se sale totalmente de las cuestiones > técnicas, pues al hablar de nuestra cabeza y la forma en que la utilizamos, > forzosamente nos salimos de la informática y vamos a un terreno menos > explorado, la psicología del programador. > ¿Por qué programamos? (O en todo caso, ¿por qué programo?) > Una primera respuesta sería: por que nos gusta pensar. Es un pensamiento > tendiente más a lo analítico-racional que a lo intuitivo, como el del > matemático, pero no tanto, y por eso no somos matemáticos. Acaso nuestros > estilos, nuestros gustos como programadores puedan definirse por el grado de > combinación entre el pensamiento deductivo y el intuitivo. Pero más allá de > esta difícil cuestión, lo que quiero destacar es que ese gusto por pensar > tiene que tener ciertas características para que no sea simplemente una > patología: es posible pensar mucho y muy analíticamente sin llegar a ninguna > parte. Obviamente, nuestro límite más grande es que la programación genera > un producto sujeto a una validación inmediata: el programa tiene que > funcionar, aquí y ahora. Pero volviendo a lo que es estrictamente la > actividad de programar, nuestro aliado más grande es una vieja > característica de la naturaleza humana (y de la naturaleza en general, por > qué no) que es la economía. Economía en sentido amplio, no economía > monetaria: lo que a veces se llama economía de esfuerzo. Lo que nos > maravilla de la tan mentada elegancia matemática no es otra cosa que la > economía. > Cada vez que podemos olvidarnos de que abajo de nuestro Smalltalk hay un > sistema operativo, cada vez que delegamos una responsabilidad en otros > objetos, cada vez que confiamos en un framework, estamos liberando memoria > de nuestras mentes que en lugar de ocuparse de asuntos de otros, se puede > ocupar de los propios. > Se podría definir la actividad de programar como tratar de resolver > cuestiones cada vez más complejas mediante soluciones cada vez más simples. > Llevándolo al extremo, cuando la economía ha logrado una simplificación > total, no hace falta programar. Es el caso de como laburan muchos > programadores actualmente, pegando cosas, configurando, llenando > especificaciones, pero sin escribir una línea de código, o muy pocas. Es una > paradoja para pensarla aparte. Pero esta paradoja tal vez nos enseñe algo: > que a veces también queremos ponerle un límite a la actividad economizadora, > pues nos hace ganar mucho, pero también nos puede hacer perder algo. > > En mis primeros tiempos como programador encontraba mucho placer en tener > la totalidad de un sistema en la cabeza: cada variable, cada procedimiento > (estoy hablando de Pascal). Me gustaba incluso leer un programa de cabo a > rabo y tratar de mantener las bifurcaciones posibles en la cabeza, para ver > si el sistema soportaba todos los acontecimientos posibles. > No se si esta es una conducta normal en un programador incipiente, si es > propia de la juventud, o que, pero hace rato que encuentro placer en algo > totalmente opuesto: que lo que hago descanse sobre bases que no hay que > conocer en detalle, o al menos, si alguna vez conocí los detalles, que haya > un punto en que es posible olvidarlos. > > Precisamente, el trabajo a partir de tests permite, si no olvidar los > detalles, poder hacer funcionar la mente de tal forma que los detalles > puedan ser olvidados temporariamente, pero que ante la necesidad de > conocerlos, poder recuperarlos, hacer un "load", tal vez mandando a otra > página los aspectos de más alto nivel, trabajar sobre esos detalles, para > finalmente volver a liberar la mente y seguir adelante con el objetivo > inicial. > Cada vez que descubro que por haber cambiado un detalle se produce un > impacto no deseado y que este descubrimiento no fue producto de tener todo > el código en mi cabeza, si no una simple luz roja me maravillo: los tests > me están ayudando a economizar, no el código, si no mi propia actividad > mental. > > Creo que las falencias achacables al trabajo con test no tienen que ver con > la idea subyacente a esta metolodogía, si no más bien con las limitaciones > que tienen las herramientas que utilizamos. > Señalo sólo una, para no hacerla tan larga. > Dado que los tests son una especie de registro de la actividad del sujeto > sobre un determinado dominio, es imprescindible que ese registro tenga no > sólo un ordenamiento temporal, si no también un ordenamiento lógico, un > ordenamiento de los más simple a lo más complejo. > Supongamos el test más boludo del mundo: asignación y verificación de la > asignación, es decir, un setter y luego un getter que devuelva el objeto > seteado. Si bien hay casos en que esto no es trivial, en la mayoría los > casos lo es. No obstante, me ha pasado que el browser se me tare y me > modifique las variables asignadas. Es claro que si este test falla, todos > los demás deberían fallar y todos estos fallos son triviales, pues dependen > de un único fallo básico. Con las herramientas que utilizamos normalmente no > hay forma de detectar que es ese test básico el que está fallando. > Yo uso un método muy pedorro que no recomiendo a nadie, pero que a mi me > sirve: numero los nombres de los métodos tratanto de mantener así el órden > lógico. A la espera de algo mejor. > > Despues de tanto bla bla, un poco de código. > Hace un tiempo hice una ampliación del TestRunner de Squeak para suplir > alguna de las falencias de las herramientas de test. Es algo bastante > primitivo porque para hacerlo bien hay que modelar muchas cosas que no están > modeladas en Squeak (las categorías de clases y métodos, por ejemplo) . > Este es el script de instalación (tiene que estar el último Installer > cargado) > > | url | > url:=url:= 'www.squeaksource.com'. > (HTTPSocket httpGet: ' > http://swikicaicyt.homeip.net/WebOpus/uploads/ProgressBarMorph.st') > readStream fileIn. > (HTTPSocket httpGet: ' > http://swikicaicyt.homeip.net/WebOpus/uploads/ProgressMorph.st') > readStream fileIn. > (Installer monticello http: url ) project: 'CoverageTestCase'; > install: 'CoverageTestCase'. > > Luego hay que hacer > TestFanRunner initialize. > TestFanRunner open. > (Para que aparezcan los tests propios tiene que ser subclases de > CoverageTestCase) > > Está también en la página nuestra ( > http://www.caicyt.gov.ar/letodoc/paquetes-publicados) pero aún no hay > ninguna documentación. > > Saludos > Norberto > > > > > > > > > > > > > -- Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org -~----------~----~----~----~------~----~------~--~---
