Hace unos días volví a Tucumán de las Smalltalks 2017, que se hicieron en la ciudad de La Plata. Las charlas estuvieron muy interesantes, con disertantes de excelente nivel.
En la conferencia participan muchas personas apasionadas por lo que hacen. Esto no es tan difícil de imaginar, considerando lo elegante y práctico que resulta programar en Smalltalk. No es casual, por ejemplo, que Smalltalk haya salido en segundo lugar entre los lenguajes de programación más queridos en las Stack Overflow Developer Survey 2017.
Durante la conferencia hice algunas entrevistas cortas, que quiero compartir con ustedes. Incluyo aquí la primera, con James Foster, en la que hablamos un poco sobre la persistencia en los sistemas orientados a objetos.
Había algo de viento durante la charla, así que si no se entiende algo pueden revisar la transcripción. Tienen también disponible una traducción al español, con algunos links. La entrevista también se puede escuchar desde Soundcloud.
We’re here with James Foster, from GemTalk Systems
Hello! Nice to be here
You work for GemTalk where you develop software to help in the persistence of data. So, what are the usual problems that we find when we try to implement persistence functionality on an object-oriented system?
On an object-oriented system, if the database is not object-oriented then we face the challenge of an impedance mismatch between the object and relational model, so that when you are saving your data you need to convert a complex object graph into a simple relational table, and then when you want to read your data you need to convert a simple relational data model into a complex object graph, and typically that is referred to as an impedance mismatch problem, and that probably represents the major challenge. The other challenge with using a relational database when you are working on an object-oriented system, is that you need to deal with a second programming language, so that your queries are done using typically SQL, and for someone who’s used to programming in an object-oriented language having to then deal with a SQL environment is a different paradigm, a different model that needs to be learned and dealt with.
So in that case it’s better to have an object-oriented database
So with an object-oriented database, we can take the objects as they exist in your client application and then persist them in their complete object graph model, and also you can write queries using the Smalltalk object-oriented programming language, so that you are using the same programming language on your client and on your server.
So, the product that you develop is for Smalltalk systems. What makes Smalltalk different?
Smalltalk is a product that came out of the Palo Alto Research Center at Xerox, they developed it in the 1970s and 1980s and it represents the pure object model approach that other so called object-oriented languages are adopting or imitating in an incomplete fashion. So with Smalltalk we focus on message sends between objects and with the message sending model, we find a simplicity and an elegance that increases our productivity.
Okay, thank you for your time
Thank you very much!
Estamos con James Foster, de GemTalk Systems
¡Hola! Encantado de estar aquí
En GemTalk desarrollan software para ayudar en la persistencia de datos. ¿Cuáles son los problemas usuales con los que nos encontramos cuando intentamos implementar la funcionalidad de persistencia en un sistema orientado a objetos?
En un sistema orientado a objetos, si la base de datos no es orientada a objetos, entonces nos enfrentamos con el desafío de un “desajuste de impedancia” (impedance mismatch) entre el modelo de objetos y el modelo relacional, de modo que cuando estás guardando los datos necesitas convertir un grafo de objetos complejo en una tabla relacional simple, y después cuando querés leer esos datos necesitas convertir un modelo simple de datos relacionales en un grafo de objetos complejo. Típicamente esto se conoce como un problema de desajuste de impedancia (impedance mismatch problem), y esto probablemente representa el desafío principal. El otro desafío que existe cuando utilizas una base de datos relacional en un sistema orientado a objetos, es que necesitas usar un segundo lenguaje de programación, de modo que tus consultas usualmente se realizan utilizando SQL, y para alguien que está acostumbrado a programar en un lenguaje orientado a objetos tener entonces que lidiar con un entorno SQL representa un modelo y paradigma diferentes que tiene que entender y aprender.
En ese caso entonces es mejor tener una base de datos orientada a objetos
Con una base de datos orientada a objetos, podemos tomar los objetos tal como existen en tu aplicación cliente y persistirlos con su grafo de objetos completo, y también podés escribir las consultas usando un lenguaje de programación orientado a objetos (en este caso Smalltalk), pudiendo utilizar entonces el mismo lenguaje de programación en tu cliente y tu servidor.
Entonces, el producto que desarrollan es para sistemas programados en Smalltalk. ¿Qué es lo que hace que Smalltalk sea diferente al resto de los lenguajes de programación?
Smalltalk es un producto que salió del centro de investigación de palo alto (PARC) en Xerox. Fué desarrollado en las décadas del 70 y 80, y representa el enfoque puro del modelo de objetos, que otros tan llamados “lenguajes orientados a objetos” adoptan o imitan de forma incompleta. Con Smalltalk nos enfocamos en el envío de mensajes entre objetos, y con este modelo encontramos una simplicidad y elegancia que incrementa nuestra productividad.
Bueno, gracias por tu tiempo!
Muchas gracias a vos!