Esta es la segunda entrevista que realicé durante las Smalltalks 2017, en la ciudad de La Plata. Esta vez entrevisto a Brian Foote, sobre las charlas que dió en las Smalltalks y en el Mini SugarLoaf PLoP 2017.
Está disponible la transcripción de la entrevista, además de una traducción al español con algunos links. La entrevista también se puede escuchar desde Soundcloud.
We are here with Brian Foote
Hi there!
In the talk that you gave, you mentioned some patterns that exist today in the Software industry. Could you summarize some of them?
Joe Yoder and I wrote a pattern collection a few years ago called Big Ball of Mud, which had things like Throwaway Code and the Big Ball of Mud itself and the admonition to keep things working, make sure that you are having a heartbeat, and somewhere in the attic… you know, this recently accelerating process of pondering what else could be said about things like that has been rolling around my head, and there were a few patterns that we now see are becoming ubiquitous these days, given the way that people are really working that probably are worthy of writing down, because everybody knows ‘em, you know. One of them is Bucket of Glue, and I’ve noticed years ago that instead of writing things from first principles, people were starting to integrate existing pieces more and just glue them together, sometimes not even in the same language, so… C could be a glue language that was calling out to a system to lash together existing pieces, that’s the example I used in the discussion, that’s what Mosaic did, was just lashing together existing parts, and it was widely successful, beyond anyone’s expectations at the time. And along with that is Copy and Paste, everybody does it, everybody does it, I used to ask people when they were teaching design patterns whether they thought copy and paste was bad, and there’s been a change, you know, you asked that question fifteen years ago, all the hands would go up, everyone goes oh this is evil, you should be writing your own code, that’s stealing, that’s cheating if you do it in computer class. Then you know, you could ask them “have you done it in the last week?”. Half the hands would go up, sheepishly the other half of the hands would go up, everybody does it, it’s what we do now cause’ there is so much out there. That’s the main thing it’s just cornucopia of stuff out there now. The change over the last… certainly this century, last ten years in particular, you know, the whole Github phenomenon. These days, if you can think of it, you can probably find twenty people who’ve attempted to write it already, and you can pick and choose from among of those things and your job would be just to figure out whether you can integrate it. You know, like ball of mud, which was something that we knew existed all over the place, I think there was this claim that it was the predominant architecture in practice out there… no one has ever disputed that. We didn’t really have the data, but no one has really disputed it. Predominant, who knows, you know, it’s all like everything is awful, but a whole lot of stuff particularly in the industry just wasn’t that good.
Okay. How did Smalltalk influence the pattern movement?
Through, you know, Ralph Johnson and the research group that were in the university of Illinois… here is what happened, we all start using Smalltalk, and there were all this moves you would see that you know you may not have thought of before, and you’d make a mental note to yourself “man, that’s clever, I’m gonna do that the next time I have that problem”, and… Easily the majority of the patterns in the Gang of Four book can and were found and observed in the ParcPlace VisualWorks Cincom, you know, Parc tradition images, and were emulated in any of the subsequent releases that retained a descendance of the original codebase. To some extent they weren’t all aped in the derivative codebases, because, as I was saying in the talk today, one of the things that kind of slowed Smalltalk adoption down was intellectual property issues. It was frustrating. When the guys in Ottawa wanted to make their own Smalltalk they couldn’t steal the code that they would loved to have stolen, you know, and so they had to do their own, and they had to consciously make it not look like the Parc code. They had a totally different character. The stylistic differences were very striking between the two.
So, okay. For you, what are the disadvantages of using Singleton?
There really is a need to be able to have a one-to-one correspondence between an object that represents an external resource, and the external resource. If you’ve got a file descriptor, you don’t wanna have two copies of it. If you’ve got a printer pool, you’ve maybe wanna have six instances one for each of the printers, you’ll wanna have the right IP address or whatever resource locator you’re using for the printers, on and on, things like that, that’s one legitimate use. A second one is when you’ve got an object that is pure behaviour, why do you need more than one instance? You can easily just share the one existing instance, and you’ll be fine, and you have the additional benefit that, you already know it’s immutable, if it has no state, so… one of the things I used to say in pattern courses is… the State pattern, you know, ironically the state objects in the State pattern are often stateless, and when they are stateless they can be Singletons. But, in some ways people have gone overboard with the idea of “there’s only one instance of anything”, that was kind of silly.
So, if I think that there is an object and I need only one instance of that object, is it necessary…(to make it a Singleton)?
First get an object and then call the constructor once, and don’t call it again, it’s the simplest way to get one copy of an object that you only want one copy of it, you don’t need to make it a Singleton, you just don’t need to make more than one. If for some reason that turns out to be something that people are stupidly doing, put the check in, but… it seems ridiculous that people thought “oh my god we are getting only one instance of this, cause’ if so I have to make it a Singleton because the Gang of Four said so, and you know, they are smarter than we are”.
Okay, and… there are some people who don’t know the difference between method overloading and polymorphism, for example in Java.
It’s a very important difference. Java is polymorphic on the receiver of messages, the receiver of function calls, but on all the other arguments of the functions it’s statically bound. You can overload functions in Java, but the resolution is done statically, and so the version of the function that you get is determined by the type of the argument being passed that can be resolved by the compiler statically and what that means is if you wanna have something that will take an instance of the superclass of a base class that you’ve never seen, and then have the dispatch discriminate according to the runtime type of that argument, the type system is just gonna say you’re crazy, it’ll just go to if there’s an implementation, a static implementation in the superclass it’ll run that, and then if you wanted you could then do a type case, or if you’re clever you could then do a double dispatch and then get the dynamic polymorphism back but that’s the only way you wanna do it, and that’s basically the mechanism you see for the Visitor pattern in the Gang of Four book for C plus plusers, if they wanna get dynamic polymorphism they have to basically do double dispatch if you’re doing it in a single dispatch language, which was a technique that was described at the very first OOPSLA back in 1986 before just about anybody listening to this would’ve been born. So, if you want that effect for real, you can go to a programming language that does multimethods and they’re becoming more plentiful. I’ve just noticed this music program that I have on my laptop called Super Collider has multimethods in it, some of the R implementations have multimethods in them, lot of the Lisp-based languages have multimethods, Groovy has multimethods… if we googled it we could find ten more, so… and they’re interesting, you know, they’re not… applications are sufficiently rare that a lot of language designers decided to let their languages live without them, but when you need’em, they’re nice. There was a paper of the CLOS guys looked at code and saw how often people were using them and they were quite rare, like single digit percentages of all the generic functions in their libraries actually discriminated on more than one argument, and that’s what they call runtime dispatch in CLOS, but it did let them do some nice things. When I was designing meta-architectures, if you had dynamic dispatch and you’re trying to design a kernel of new objects that could allow you to replace anything, you could do some really clever stuff if they were dynamically dispatched, but when I was messing with those back in the 90s, you wanna have and build dynamic dispatch into a kind of a guiding assumption, and you could get some mileage out of it. There the idea was: I want to be able to replace anything and extend anything, and I want to be able to compile that in as efficient a manner of possible, and from that point on behave as though the substitution were in effect for everybody. If I wanna change the way variable assignment works for everybody, there’s an object that I should be able to go in and get that is the one that defines how that works for everybody and I should be able to drop that in and have it work that way for everyone, including the kernel and I should have a scheme for resolving the circularity, so that’ll mean part of the system is still playing by the old rules but everybody else who sees it from a different vantage point can see it do the new rules, and that’s all doable, there’s some neat reflection tricks that haven’t been sufficiently described and popularized that would let people do those kind of things and I think that’d be pretty cool. We’ve got a proliferation of fixed intent language extensions, and fixed languages that introduce one or two new features at a time and there always seems that it would be nicer if you had a language that would let you go build any of this stuff if you needed it and a core that would allow that, and if people did wanna use features like that they will pull them out of Github or whatever they came from and use them, if they wanted an extension and it did the job they wanted then they could, and that still seems feasible, I’m curious whether anyone has done it, I’m a little behind on the research.
Okay, thank you!
You’re welcome!
Estamos aquí con Brian Foote
¡Hola!
En la charla que diste, mencionaste algunos patrones que existen hoy en la industria del software. ¿Podrías mencionar algunos de ellos? (La charla se titula “Software in the Age of Sampling”, hay disponible un video de otra instancia de la charla, dada en otra conferencia)
Joe Yoder y yo escribimos una colección de patrones hace unos años llamada “Big Ball of Mud”, que incluía patrones como “Throwaway Code” (código desechable), la propia “Big Ball of Mud” (gran bola de barro) en sí, y la advertencia de “Keep It Working” (mantener las cosas funcionando), asegurate de tener una palpitación constante. Y en algún lugar del ático… este proceso acelerado de pensar qué más se podría decir acerca de cosas como esas estaba rondando por mi cabeza, y había algunos patrones que se están volviendo omnipresentes el día de hoy, considerando la manera en la que las personas están trabajando realmente, y que probablemente son dignos de escribir, porque todos los conocen. Uno de ellos es “Bucket of Glue” (balde de plasticola). Me dí cuenta hace unos años que, en lugar de escribir cosas a partir de principios básicos, la gente había empezado a integrar piezas existentes, simplemente “pegandolas” entre sí. Y junto con eso está “Copy and Paste” (copiar y pegar), todo el mundo lo hace. Le solía preguntar a la gente cuando estaba enseñando patrones de diseño si es que pensaban que hacer copy-paste estaba mal, y en eso hubo un cambio. Si hacías esa pregunta hace 15 años, se levantaban todas las manos, todos decían “eso es malo”, “deberías escribir tu propio código”, “eso es robar”, “eso es hacer trampa si lo hacés en clase”. Después, bueno, podías preguntarles “¿Lo hicieron en esta última semana?”. La mitad de las manos se levantaban, y tímidamente la otra mitad también. Todo el mundo lo hace, es lo que hacemos ahora, porque hay muchísimas cosas disponibles. Esa es la cuestión principal, ahora hay un cuerno de la abundancia de cosas disponibles por ahí. Hubo un cambio en los últimos diez años en particular, todo el fenómeno de Github. Estos días, si podés pensar en algo, seguramente podés encontrar a veinte personas que ya intentaron escribirlo, y podés seleccionar y elegir entre esas cosas, y tu trabajo sería solamente ver si podés integrarlas. Como “Ball of Mud”, que fué algo que sabíamos que existía en todos lados, por ejemplo había gente que decía que era la arquitectura en práctica predominante… y nadie ha cuestionado eso alguna vez. Nosotros no teníamos los datos estadísticos, pero nadie lo negó.
¿Cuál fué la influencia de Smalltalk en el movimiento de patrones de diseño? [charla: “A Smalltalk Patterns Safari”]
A través de Ralph Johnson y el grupo de investigación que estaba en la universidad de Illinois… esto es lo que pasó: empezamos a usar Smalltalk, y había toda una serie de movimientos que veías, y eran cosas que quizás nunca se te habían ocurrido antes. Entonces hacías una nota mental diciendo “está re bueno eso, lo voy a hacer la próxima vez que tenga que solucionar ese problema”. Fácilmente la mayoría de los Patrones GoF pueden ser y fueron encontrados y observados en las imágenes de Smalltalk tradicionales de Parc, y fueron emulados después en todos los dialectos subsecuentes que conservaron una descendencia de la base de código original. Sin embargo, en cierto sentido no todos fueron imitados en las bases de código derivadas, porque, como dije en la charla de hoy, una de las cosas que ralentizó la adopción de Smalltalk fueron problemas de propiedad intelectual.
Para vos, ¿Cuáles son las desventajas de utilizar el patrón Singleton? [comentario: la respuesta es más a la pregunta ¿Cuáles son los casos en los que se puede usar el patrón Singleton?]
Hay una necesidad real de tener una correspondencia uno-a-uno entre un objeto que representa un recurso externo, y el recurso externo en sí. Si tenés un descriptor de archivo, no querés tener dos copias. Si tenés un pool de impresoras, quizás querés tener por ejemplo seis instancias, una para cada impresora, y querrías tener la dirección IP correcta para cada una, cosas como esas son usos legítimos del patrón. Un segundo caso es cuando tenés un objeto que solamente representa comportamiento, ¿Por qué querrías tener más de una instancia? Fácilmente podés compartir la única instancia existente, y vas a andar bien. Aparte, ya sabés que ese objeto es inmutable, porque no tiene estado. Una de las cosas que solía decir en los cursos de patrones sobre el patrón Estado es que irónicamente los objetos “estado” del patrón suelen no tener estado (ser “stateless”), y cuando no tienen estado entonces pueden ser Singletons. Pero bueno, en algún sentido la gente se enloqueció con la idea de que “solamente hay una instancia de todo”, y eso sí fue algo malo.
Entonces, si me parece que hay un objeto y necesito sólo una instancia de ese objeto, ¿Es necesario (que sea un Singleton)?
Primero identificá el objeto, y después invocá al constructor una sola vez, y no lo invoques de nuevo. Es la manera más simple de obtener una sola copia de un objeto del que querés sólo una copia. No tiene por qué ser un Singleton, simplemente no tenés que crear más de uno. Si por alguna razón eso parece ser algo que la gente está haciendo (crear más de una copia), incluí la verificación, pero… parece ridículo que la gente haya pensado “Dios mío, ¿Tenemos una sola instancia de esto? Porque si es así tenemos que hacer que sea un Singleton porque los patrones GoF dicen eso!”
Hay algunas personas que no saben cuál es la diferencia entre la sobrecarga de métodos y el polimorfismo, por ejemplo en Java [charla: “Reflection: Smalltalk’s Most Enduring Idea?”]
Es una diferencia muy importante. Java es polimórfico en el receptor de los mensajes, o sea, en el receptor de las llamadas a funciones, pero en todos los demás argumentos está enlazado estáticamente. Podés sobrecargar métodos en Java, pero la resolución se realiza de manera estática, por lo que la versión del método que obtenés está determinada por el tipo de los argumentos que le pasaste que puedan ser resueltos por el compilador de manera estática. Eso significa que si querés tener un método que reciba una instancia de una subclase que nunca has visto, y querés que la selección del método se realice de acuerdo al tipo del argumento en tiempo de ejecución, el sistema de tipos te va a decir que estás loco, y simplemente va a seleccionar la implementación que corresponde a la superclase y va a ejecutar eso. Y bueno, después si querés ahí podés hacer un switch con el tipo, o si sos ingenioso podés hacer un double dispatch y entonces tener polimorfismo dinámico de nuevo, pero esa es la única manera en la que podés hacerlo. Y ese es básicamente el mecanismo que se ve en el patrón GoF Visitor para C++. Si ahí querés tener polimorfismo dinámico, tenés que hacer un double dispatch (porque estás usando un lenguaje que tiene single dispatch), que es una técnica que fue descrita en el primer OOPSLA en 1986, antes de que casi cualquiera que esté leyendo esto haya nacido. Y bueno, si querés ese efecto de verdad, podés usar un lenguaje de programación que tenga multimétodos, y se están volviendo abundantes. Hace poco me dí cuenta que este programa de música que tengo en mi laptop llamado “Super Collider” tiene multimétodos, algunas implementaciones de R tienen multimétodos, muchos lenguajes basados en Lisp tienen multimétodos, Groovy tiene multimétodos… si lo googleáramos podríamos encontrar diez más… y son interesantes. Las aplicaciones son lo suficientemente raras para que muchos diseñadores de lenguajes decidieran no incluir multimétodos en su lenguaje, pero cuando los necesitás, están buenos. Había un paper de la gente de CLOS, donde miraron el código y analizaron cuál era la frecuencia con la cual se utilizaban multimétodos, y era bastante raro, digamos un porcentaje de un sólo dígito de todas las funciones genéricas de sus librerías realmente discriminaban en más de un argumento, y eso es lo que ellos llaman dispatch en tiempo de ejecución en CLOS, pero les dejó hacer algunas cosas buenas. Cuando estaba diseñando meta-arquitecturas, si estabas tratando de diseñar un kernel de nuevos objetos que te permitan reemplazar lo que sea, podías hacer cosas realmente ingeniosas si eran despachados dinámicamente. Cuando estaba jugando con eso allá en los 90, querías tener el dynamic dispatch como una suerte de premisa guía, y sacarle provecho. Ahí la idea era: Quiero ser capaz de reemplazar lo que sea y extender lo que sea, y quiero ser capaz de compilar eso de la manera más eficiente posible, y a partir de ese punto en adelante comportarme como si la sustitución hubiera sido en efecto para todos. Si quisiera cambiar la manera en la que se comporta la asignación de variables para todos, hay un objeto que debería ser capaz de encontrar, que es el que define cómo funciona eso, y debería ser capaz de modificarlo y hacer que funcione para todos de la manera que yo quiero, incluyendo el kernel, y debería tener un esquema para resolver la circularidad. Eso significaría entonces que una parte del sistema todavía estaría jugando según las reglas viejas, pero todos los que lo vean desde un punto de vista diferente lo ven siguiendo las reglas nuevas. Y todo eso es realizable, hay unos trucos elegantes de reflexión que no fueron lo suficientemente descritos y popularizados, que le permitirían a la gente hacer este tipo de cosas, y creo que eso es muy genial. Tenemos una proliferación de extensiones de lenguajes de intención fija, y lenguajes fijos que introducen una o dos nuevas características a la vez, y siempre parece ser que sería mejor si tuviéramos un lenguaje que te permitiera construir cualquiera de estas cosas si lo necesitaras. Entonces si la gente quisiera usar una característica nueva, podría sacarla de un repositorio en Github o de donde sea, y utilizarla, y eso sigue pareciendo factible. Tengo curiosidad de saber si alguien lo ha hecho, estoy un poco atrasado en la investigación.
Bueno, ¡Muchísimas gracias!
¡De nada!