Esta es la tercera entrevista que realicé luego de las Smalltalks 2017, en la ciudad de La Plata. Esta vez entrevisto a Hernán Wilkinson, de 10Pines. Está disponible la transcripción de la entrevista, incluyendo algunos links.
Estamos con Hernan Wilkinson, de 10Pines.
¡Hola, qué tal!
¿Qué tiene de interesante para vos Smalltalk? O sea, si alguien está trabajando con algún otro lenguaje, ¿Vale la pena aprender Smalltalk?
Bueno, si, a ver… Smalltalk tiene muchas cosas interesantes por las que vale la pena aprenderlo. La primera tiene que ver con el lenguaje en sí mismo, Smalltalk es más que un lenguaje, es un ambiente de desarrollo, entonces una de las características interesantes es el lenguaje, que es un lenguaje simple, de sintaxis sencilla, y que tiene todo abierto, todo está disponible para el programador, por lo tanto puede aprender cómo se implementa un lenguaje de programación, o sea, puede ver cómo se implementa un while, cómo se implementa el if, puede ver cómo se implementa una infraestructura de excepciones, puede ver cómo se implementa un lenguaje de objetos, porque todo el metamodelo, que tiene que ver con crear supongamos clases en el caso de Smalltalk, instanciar objetos, etc, está abierto, y con todo el código disponible. Entonces eso por un lado lo convierte en una herramienta de aprendizaje y de investigación muy importante, que para la gente que tiene interés en entender cómo se desarrolla un lenguaje de programación, es muy bueno. Y hay que entender que Smalltalk siempre tuvo todo el código disponible, siempre fue en ese sentido open source, ¿Por qué? Porque los creadores de Smalltalk entendían que una parte fundamental del aprendizaje tenía que ver con la transmisión del conocimiento que ellos tenían, entonces ¿Cómo transmitían su conocimiento? Permitiendo que el resto vea cómo ellos habían desarrollado lo que habían desarrollado… bueno, y además también por el tema de la subclasificación, si uno subclasifica y no ve cómo está implementada la superclase es muy difícil subclasificar correctamente, pero bueno, también tiene que ver con esta filosofía de apertura y de aprendizaje. Después otra característica para mi muy interesante es el dinamismo, el hecho de poder crear objetos y manipular objetos rápidamente, dinámicamente, desde un inspector poder modificar un objeto, enviarle un mensaje, ver qué pasa… y fundamentalmente el debugger. El debugger es una herramienta poderosísima en Smalltalk, es el mejor debugger que yo conozco de cualquier lenguaje de programación, donde uno puede hacer cosas que la gente ni se imagina, como por ejemplo volver para atrás en el stack y volver a ejecutar, o modificar objetos mientras se está debuggeando para ver qué pasaría, o crear métodos a partir del mensaje que un objeto no sabe responder dinámicamente. El debugger es maravilloso. Y todo este dinamismo se traduce en el feedback inmediato, la posibilidad de ir viendo los resultados de lo que uno hace y de lo que uno piensa inmediatamente, y por lo tanto eso hace que sea una herramienta que te ayuda en todo el proceso de resolución del problema que estás encarando, es una herramienta que te ayuda en todo ese proceso de creación de la teoría de la solución que vos estás armando, y te permite validar que esa teoría de solución que estás armando sea válida o no. Entonces rápidamente uno puede ir encontrando la solución, debido a toda esa facilidad que te da. Por eso también Smalltalk es tan bueno para hacer TDD, no por nada Kent Beck cuando formaliza TDD lo hace porque estaba trabajando en Smalltalk, entonces todo ese ciclo de TDD, esos tres pasos: test, coding y refactoring tienen que ver con todo este dinamismo que Smalltalk te da. Esas creo que son las características principales.
Bueno, eso también le da una importancia muy grande a Smalltalk desde un punto de vista histórico. Por ejemplo, Brian Foote mencionaba en su charla que al estar todo el código abierto, muchos patrones de diseño se han documentado por primera vez después de observar bases de código en Smalltalk. Sobre ese tema de patrones, un patrón que me intriga realmente es el patrón Singleton. No sé cuales son tus opiniones sobre ese patrón o tus consejos sobre el uso del patrón.
Bueno, creo que vos ya conocés mi opinión sobre el Singleton y por eso me la estás preguntando. Yo siempre digo que el Singleton es como Pablo Escobar, es el patrón del mal. Creo que, si, a ver, primero para mí no es un patrón, es una técnica, y que además es muy mal utilizada y poco comprendida, porque singleton significa una clase que tiene una única instancia, y poder acceder a esa única instancia de manera global, digamos un scope pseudo-global. Como muchas cosas de nuestra profesión, ese concepto se fue deformando, y se empieza a utilizar esta idea de tener acceso global a un objeto debido a errores de diseño que generalmente se cometen que tienen que ver con no pasar como parámetro o como colaborador en un mensaje algún objeto. Típico error: quiero acceder a mi conexión con base de datos desde un objeto que está muy abajo en mi árbol de ejecución, entonces como la conexión a la base de datos no la recibí como parámetro o como colaborador, entonces accedo de manera global, y ¿Cómo se accede de manera global? Utilizando un Singleton. Entonces, el problema del Singleton es que genera un acoplamiento muy fuerte entre objetos que tienen poca responsabilidad respecto a algo con mucha responsabilidad como por ejemplo es una base de datos o una conexión con una base de datos. Y ese acoplamiento después es muy intrusivo, genera muchos problemas de diseño. Uno de ellos se empieza a observar cuando querés testear por ejemplo, debido a que un objeto está acoplado con la base de datos, cuando querés testearlo sí o sí tenés que tener la base de datos, lo cual ya empieza a traerte problemas porque hace que el test tenga que tener la base de datos, hace que el test se ejecute lento, hace que para poder ejecutar ese test tenés que armar todo tu ambiente de base de datos, bueno, toda una serie de problemas que se generan debido a ese acoplamiento innecesario. Entonces, a ver… no es que el Singleton es malo por sí mismo, como muchas cosas en la vida no es que son malas por sí mismas sino porque las utilizamos mal. Entonces desde ese punto de vista yo creo que el Singleton ha generado más problemas que soluciones, y es por eso que para mi es algo que habría que tratar de desterrar… a ver, lo primero que habría que tratar de hacer es que la gente lo entienda y entienda cuándo aplicarlo, cuándo no, cuales son las ventajas y cuales son las desventajas, pero lamentablemente a veces por X motivos no todos lo terminan de entender, copian ideas de otros lados, el ser humano aprende copiando, y cuando ven ejemplos en Internet o en libros donde tienen un Singleton, entonces empiezan a copiar y armar esa idea de solución que termina generando todos estos problemas. Entonces para mi estaría bueno desterrar el Singleton de todos esos ejemplos, para evitar que se copien malas soluciones, y bueno, empezar a resolverlo de otras maneras. Pero si, básicamente, el problema del Singleton es el acoplamiento que eso genera, y por lo tanto el degradamiento dentro del diseño.
En una de tus charlas has mostrado el trabajo que están haciendo con Cuis University, y bueno, en particular el concepto de Denotative Object, que bueno, más allá de la implementación particular que tienen en ese sistema, me parece súper interesante el hecho de que uno pueda tener un sistema… o desarrollar un sistema orientado a objetos sin tener clases, pero eso es algo que mucha gente no lo sabe. No sé cuál es tu opinión al respecto o si tenés algún comentario.
Respecto de Denotative Object, la implementación la hice tan rápido, creo que en cuatro días, tres días, que es medio un asco, hay cosas que son medio feas, que siempre quise tener un poco de tiempo para hacerlas más lindas, hay mucho código repetido, más que nada en todo lo que tiene que ver con el tema de las herramientas, por ejemplo ocultar en el debugger todo lo que no tiene que ver con objetos denotativos, ese tipo de cosas fue hecho muy prueba y error, y nunca tuve el tiempo de hacer una síntesis de todo eso. Entonces hay una parte que está medio feucha en la implementación, otra parte que no tanto, pero bueno, eso respecto de la implementación. Respecto del concepto, sí, lamentablemente la gente cree que objetos tiene que ver con clases, de hecho yo una vez conocí una persona que era profesor de una materia de objetos en una universidad, que un día me vino a decir que había encontrado cuál era el problema del paradigma de objetos, y lo que me dijo fue que el problema era el nombre, que no debería llamarse paradigma o programación orientada a objetos, sino que debería llamarse programación orientada a clases, porque uno estaba todo el tiempo trabajando con clases. Entonces eso demuestra la falta de conocimiento sobre el tema, y la confusión, porque sí, es verdad que en lenguajes de clasificación uno programa sobre clases o con las clases, pero por otro lado no hay que olvidar que las clases son objetos también, y que en definitiva las clases están para modelar conceptos, que es ese agrupamiento de comportamiento, esa representación de conocimiento común a muchos individuos, pero que también se puede trabajar con otras formas de organizar el conocimiento que no tiene que ver con crear estas clases, sino con trabajar por ejemplo con objetos prototípicos, como por ejemplo lo propone Ungar y Lieberman en el lenguaje Self. Hay un paper famoso del año 85, 86 de OOPSLA, que se llama El Tratado de Orlando, donde justamente hablan sobre este tipo de cosas. En realidad el lenguaje Self fue Ungar y… bueno, no me acuerdo el otro, Lieberman no trabajó en Self. Pero bueno, la idea de trabajar con objetos sin clases es muy interesante, permite por lo menos evitar tener que hacer esa generalización, esa abstracción que es la clase, y te permite entonces empezar a representar con objetos elementos concretos de la realidad. Y al poder hacer eso, el resultado es mucho más rápido, porque hay todo un proceso de generalización que no tenés que hacer. Entonces, lo que tiene de interesante enseñar de esa forma, es que podés empezar a hacerle entender al alumno qué es un objeto, qué significa que sepa responder mensajes, qué representa un objeto, para que después de que entienda esa parte que es el mapeo directo entre el elemento de la realidad y el objeto, vea que ¡Upa! Ahora puedo empezar a sacar una generalización de estos objetos que son parecidos, y tengo varias… por lo menos dos maneras: una es utilizando clases y otra es utilizando prototipos. Y bueno, y eso te abre la cabeza bastante, porque te hace entender distintas maneras de ver un problema y una solución. En ese sentido es muy interesante. Pero bueno, a nivel industrial… ahora por Javascript la parte de prototipación ha logrado expandirse, pero es pura casualidad. Es más, yo creo que muchos programadores de Javascript no tienen la más mínima idea de que están trabajando sólo con objetos o de qué significa hacer prototipación a nivel objetos, y bueno, de hecho ahora en la última versión de Javascript le han agregado por lo menos sintaxis para trabajar con clases, por más de que por detrás es todo objetos, pero bueno, sí, es una mera casualidad nada más.
En tu otra charla, has usado TDD para desarrollar una herramienta de refactoring. ¿Cuál es la importancia de hacer TDD cuando desarrollamos un sistema?
Bueno, para mí es muy importante. No es fácil acostumbrarse a hacer TDD, lleva tiempo. Pero una vez que uno lo entiende y lo internaliza, es muy importante por varios motivos. Primero porque te obliga a pensar la solución en pequeños pasos, o sea, en pequeñas partes. Entonces, te permite encarar un problema grande de a poco, y al encararlo de a poco te permite en definitiva ser más productivo. O sea, es mucho más fácil resolver pequeños problemitas de a poco, que terminan resolviendo el gran problema, que tratar de ir a resolver el gran problema de una. Entonces, desde ese punto de vista, lo que tiene de muy bueno TDD es que te enseña, te obliga, te permite particionar un problema grande en problemas más chicos que es algo que generalmente no hacemos, y es algo que generalmente no nos enseñan a hacer tampoco en la facultad. Entonces esa es una de las cosas interesantes que tiene: a ver, este es un problema grande, ¿Cómo lo resuelvo? Bueno, en el caso del ejemplo que yo di era el rename de una variable de instancia, entonces bueno, ¿Qué es un rename de variable de instancia? Bueno, primero tengo que agregar una variable de instancia, después tengo que copiar todas las referencias de la variable de instancia vieja a la nueva, después tengo que renombrar todos los métodos que hayan referenciado (a esa variable de instancia) y después tengo que borrar (la variable de instancia vieja), bueno, esos cuatro pasos surgen automáticamente de pensar en problemas más chiquititos, que es lo que te obliga a hacer TDD. Y por otro lado tiene algo muy interesante y es que te da como un proceso de trabajo, son esos tres pasos que hay que dar, y como te ofrece ese proceso, o ese procedimiento de trabajo, uno puede reflexionar sobre cómo lo está haciendo. Entonces uno puede empezar a pensar bueno, a ver, ¿Cuánto tiempo estoy tardando en hacer el paso uno, que es escribir el test? ¡Upa! Ya voy diez minutos, entonces si hace diez minutos que estoy escribiendo un test, y… por ahí significa que el test es muy complejo… o por ahí no, pero lo importante es que uno puede reflexionar sobre eso, o si estás quince minutos tratando de hacer pasar un test, y bueno, hay algún problema, porque entonces o el test que escribí es muy complejo, o la solución sobre la que estoy trabajando no es muy buena y entonces me obliga a tener que tocar mucho para poder hacer pasar el test… Y todo ese tipo de reflexión que uno puede hacer sobre la forma en la que está trabajando te ayuda a entender mejor sobre aquello que estás trabajando y te ayuda a trabajar mejor, porque vos de a poco empezás a decir ah no, pará, este test en realidad lo podría haber escrito en dos otros tests más simples, y entonces ahí empezas a perfeccionar tu manera de hacer TDD, tu manera de programar en definitiva. Y eso, ese tipo de reflexión que uno puede hacer cuando hace TDD debido a que tiene este procedimiento, no lo podés hacer cuando estás desarrollando de la manera clásica, en donde vos agarrás y empezás a encarar el problema: bueno, escribo este mensaje voy a implementarlo en este método y después voy a crear esta clase, y después… y todo eso se hace de una manera muy desorganizada, generalmente olvidándose de cosas -que son después los famosos bugs- o cometiendo errores debido a que uno va programando el sistema en su cabeza, corriendo el sistema en su cabeza, como dice Bret Victor en ese famoso video de Inventing on a Principle, entonces uno termina jugando a ser computadora, y bueno los seres humanos no somos buenas computadoras, nos equivocamos, y al estar corriendo el sistema en nuestra cabeza todo el tiempo, nos cansamos más, etc. Entonces, lo que tiene de bueno TDD principalmente es eso: esa posibilidad de particionar un problema grande en cosas más chiquititas, y reflexionar sobre cómo uno programa, sobre cómo uno está desarrollando software. Y después por supuesto está todo el valor agregado, que para mi es importante pero es accidental, digamos no es… a ver, es muy importante desde el punto de vista del mantenimiento del software tener una batería de tests automatizada, es un valor agregado pero que viene como resultado de hacer TDD, porque uno podría también tener tests automatizados sin hacer TDD, de hecho mucha gente escribe tests sin hacer TDD, lo cual también es muy bueno, porque tener una batería de tests que te permite asegurar que todo lo que funcionaba antes sigue funcionando después de que hiciste un cambio, es fundamental. Pero esa es una ventaja adicional, para mí lo más importante está en estas dos primeras cosas que te mencioné.
Bueno, ¡Muchísimas gracias por tu tiempo!
No, por nada, un gusto.