Entrevista a Richard Hipp
Creador de SQLite
Esta entrevista fue originalmente realizada en inglés por email. Por tanto, primero se ofrece una traducción al español, y al final, se encuentra la versión original.
This interview was originally conducted in English by email. The Spanish translation is provided first, followed by the original version.
Richard Hipp es un desarrollador de software estadounidense, conocido principalmente por ser el creador del sistema de gestión de bases de datos relacionales SQLite. Hipp, tiene un PhD en Ciencias de la Computación de la Duke University, comenzó a trabajar en SQLite en 2000 mientras trabajaba en General Dynamics. En 2002, lanzó la primera versión pública de SQLite, que rápidamente ganó popularidad debido a su tamaño pequeño, eficiencia y flexibilidad. Desde entonces, Hipp ha continuado desarrollando y manteniendo SQLite, que se ha convertido en una de las bases de datos más populares y ampliamente utilizadas en el mundo.
Además de SQLite, Hipp ha desarrollado y contribuido a numerosos otros proyectos de software de código abierto; incluyendo CVSTrac, un sistema de seguimiento de bugs y wiki para CVS; un widget HTML para Tcl/Tk; y es creador del sistema de control de versiones Fossil SCM (que es competidor de Git). En reconocimiento a su trabajo en SQLite, Hipp recibió un premio Google O'Reilly Open Source Award en 2005.
Existe un consenso en que tanto SQLite como Fossil SCM son herramientas fáciles de usar; y no sólo eso, también su implementación es simple y elegante. Por tanto, es para mi un gusto haber podido conversar con uno de los grandes desarrolladores de software y contribuidores del ecosistema open source.
¡Espero disfruten de la entrevista!1
Versión traducida
(1) ¿Cuál fue el momento clave que te llevó a crear SQLite, y qué problemas específicos estabas tratando de resolver en ese momento?
Quería una biblioteca de base de datos SQL que pudiera vincular con mi aplicación y que pudiera leer y escribir contenido directamente desde el disco en lugar de enviar mensajes de ida y vuelta a un proceso de servidor separado. No pude encontrar tal biblioteca, así que la escribí yo mismo y la llamé SQLite.
Estaba trabajando como programador freelance. Uno de los problemas que me habían contratado para resolver involucraba un programa para encontrar soluciones aproximadas óptimas a un problema de grafos NP-completo. El “grafo” necesitaba leerse de una base de datos Informix. Funcionó bien la mayoría del tiempo. Pero a veces la base de datos Informix estaría caída y cuando el cliente hacía doble clic en mi aplicación, mi aplicación mostraba un cuadro de diálogo de error que decía “No se puede conectar a la base de datos”. No había nada que mi aplicación pudiera hacer al respecto, ya que el problema era externo a la aplicación. Sin embargo, como era mi aplicación la que entregaba el mensaje de error, yo recibía el ticket de problemas.
Pensé: “Si pudiera leer el contenido de la base de datos directamente desde el disco, entonces mi aplicación no dependería de un servidor externo y este problema no surgiría”.
El cliente no aprobó esta idea, así que no implementé SQLite como parte de ese contrato. Comencé a escribir SQLite unos meses después, en mi propio tiempo. El primer código se verificó el 2000-05-29.
(2) ¿Cómo logró SQLite una adopción tan amplia en la industria, y qué factores crees que contribuyeron a su éxito?
Nunca fue parte de mi plan de carrera ser un “chico de bases de datos”. Puse el código fuente de SQLite en internet como una curiosidad, pensando que otras personas podrían encontrarlo interesante. Nunca anticipé el nivel de interés que provocaría. Nunca pensé que SQLite se convertiría en un negocio.
De hecho, durante los primeros dos o tres años de su existencia, SQLite fue un proyecto de código abierto poco conocido y raramente utilizado. Seguí mejorándolo, poco a poco, porque disfruto escribiendo y trabajando en software. Pero SQLite no se utilizaba ampliamente. Luego, a partir de alrededor de 2003, comencé a recibir llamadas de las principales empresas tecnológicas de la época (AOL, Motorola, Symbian) pidiendo mejoras y soporte para SQLite para que pudieran utilizarlo en sus productos. Me dije a mí mismo: “¿Qué? ¿Puedes realmente ganar dinero con software de código abierto?” SQLite se convirtió en un negocio a tiempo parcial en ese momento. Un par de años más tarde, Android y iPhone salieron al mercado, y en ese punto SQLite se estableció firmemente en el paisaje de software para dispositivos embebidos. Dejé de hacer trabajo de desarrollo freelance y comencé a dedicar toda mi atención a SQLite.
¿Por qué fue exitoso SQLite? No lo sé, pero mi conjetura es que SQLite es simple:
SQLite proporciona un modelo más simple para una base de datos relacional que los motores de base de datos cliente-servidor como PostgreSQL y MySQL, ya que no hay proceso de servidor que mantener en ejecución. Lee y escribe directamente desde el disco. Si el sistema de archivos funciona, entonces puedes acceder a tus datos. No dependes de un servidor separado.
La base de datos SQLite es un solo archivo en el disco. Esto simplifica la gestión de múltiples bases de datos. Es trivial hacer una copia de seguridad de la base de datos (simplemente copia el archivo) o transferir la base de datos de una máquina a otra. Es mucho más fácil para los desarrolladores pensar en ella porque hay un solo archivo en el disco que pueden señalar y decir “Esta es la base de datos”.
La biblioteca SQLite no tiene dependencias externas más allá de la biblioteca C estándar, por lo que es simple de implementar. Además, la biblioteca SQLite es compacta y utiliza poca memoria en comparación con las soluciones de base de datos cliente-servidor.
En resumen, SQLite “simplemente funciona”. Los desarrolladores de aplicaciones no necesitan preocuparse tanto por su solución de almacenamiento de datos y pueden enfocar más esfuerzo mental en resolver problemas para sus clientes.
(3) ¿Cómo surgió Fossil SCM, y qué diferencias de diseño tiene en comparación con Git?
El primer código para SQLite se almacenó en CVS, que era el sistema de control de versiones predominante en esa época. CVS era genial (mejor que otros sistemas de control de versiones contemporáneos y mucho mejor que los sistemas que vinieron antes) pero tenía sus limitaciones. Así que comencé a buscar alternativas.
Me inspiré en Monotone, que había llamado mi atención porque utilizaba una base de datos SQLite como formato de archivo de repositorio. Probablemente habría movido SQLite a Monotone excepto por el hecho de que necesitaba un puerto TCP personalizado y protocolo de comunicación cliente-servidor. Esto fue antes de la disponibilidad generalizada de servidores virtuales privados (VPS) y así que mi sitio web se hacía a través de hosting compartido y necesitaba un sistema donde pudiera ejecutar el lado del servidor como un script CGI. Comencé a experimentar con estas ideas en 2005. Git y Mercurial también habían comenzado en ese momento y los examiné también. Pero, al igual que con Monotone, no veía cómo ejecutarlos como CGI. Al mismo tiempo, también tenía un contrato con el fabricante de aviónica Rockwell Collins y ellos me presentaron DO-178B, que estudié cuidadosamente. No sentí que ni Git ni Mercurial cumplieran con los requisitos de gestión de configuración de software de DO-178B. Al no encontrar un sistema existente que se ajustara a mis necesidades, una vez más me dispuse a escribir mi propio.
Fossil es como Git (y Monotone y Mercurial) en que representa la historia de un proyecto de software como un grafo dirigido acíclico, donde cada confirmación es un nodo. Los nodos se identifican mediante un hash criptográfico y, por lo tanto, son inmutables. Así que el modelo de datos subyacente es conceptualmente el mismo.
Fossil se diferencia de Git de muchas maneras:
El formato de los artefactos individuales (“objetos” en la jerga de Git) es completamente diferente.
Los repositorios de Fossil se sincronizan sobre HTTP/HTTPS ordinarios. El servidor se puede ejecutar utilizando CGI.
El repositorio de Fossil se almacena en una base de datos SQLite (como Monotone), en lugar de como una pila de archivos más el formato de archivo “packfile” personalizado de Git.
Fossil es un ejecutable autónomo, lo que lo hace fácil de instalar, actualizar y/o desinstalar.
Además de control de versiones, Fossil también admite tickets de problemas distribuidos, wiki y documentación. Y tiene un servicio de chat de desarrolladores integrado.
Inspirado en DO-178B, Fossil pone un gran énfasis en mantener un registro de auditoría inmutable y promover la conciencia situacional de los desarrolladores.
Un beneficio no intencionado de escribir Fossil es que también sirve como una plataforma de prueba y “dogfooding” excelente para SQLite. Cuando estoy trabajando en Fossil, tengo que utilizar SQLite de la misma manera que cualquier otro desarrollador. Esto me fuerza a mirar la API de SQLite desde una perspectiva diferente a cuando estoy trabajando en SQLite mismo. Me ayuda a empatizar con las luchas de otros desarrolladores que están tratando de integrar SQLite en sus productos, y a ser más simpático con las solicitudes de mejoras de API. He agregado muchas características útiles en SQLite simplemente porque las necesitaba yo mismo para utilizarlas en Fossil. SQLite es un producto mejor porque lo uso en la implementación de Fossil.
(4) La opinión general entre los desarrolladores de software es que tanto SQLite como Fossil SCM tienen un buen diseño, no sólo en términos de facilidad de uso, sino también de implementación. ¿Cuáles son los principios de diseño de software que crees que son relevantes para hacer buen software?
(A) La complejidad es tu enemiga. Mantén las cosas lo más simples posible.
(B) Evita utilizar la primera solución que se te ocurra. Si piensas un poco más en el problema, a menudo encontrarás una aproximación mejor.
(C) Documenta tu código, especialmente las definiciones de estructuras de datos y variables, con comentarios cuidadosos. Escribe el código de manera que pueda ser leído, entendido y mantenido por otros. Explica las cosas claramente. No, el propósito de esa subrutina que acabas de escribir o esa variable que acabas de declarar no es obvio desde su nombre.
(D) Diseña para la prueba. No es suficiente escribir software que funcione; también debes escribir software que sea fácil de verificar, que pueda ser fácilmente probado para funcionar.
(5) ¿Qué proyectos o áreas de investigación estás explorando actualmente, y cómo ves el futuro de la tecnología de bases de datos?
Siempre tendremos bases de datos. Como dice el viejo dicho: “Sin datos, o eres afortunado o estás equivocado”. La pregunta debería ser: “¿Cómo serán las bases de datos en el futuro?” Creo que SQL estará aquí para quedarse. Incluso cuando empecé a escribir SQLite, seguía pensando que SQL estaba más relacionado con el soporte de mainframes heredados y que no era más que una complicación innecesaria. Pero he llegado a reconocer que SQL realmente tiene algunas ideas inquebrantables: (1) transacciones, (2) abstracción de datos y (3) un lenguaje declarativo.
Tener transacciones es vital para construir sistemas robustos. Si las máquinas nunca se caen y el poder nunca se corta inesperadamente, entonces tal vez las transacciones no serían tan importantes, pero esas cosas suceden.
Fred Brooks escribió en The Mythical Man-Month que “La representación es la esencia de la programación informática”. Y tenía razón. Es más importante obtener la estructura de datos correcta que obtener el código correcto. La estructura de datos puede persistir durante años y décadas. Resulta que el modelo de datos relacional es una excelente manera de definir las estructuras de datos para la mayoría de los problemas del mundo real.
La característica clave de SQL es que el programador le dice a la máquina “qué” computar, no “cómo” computarlo. Esto es una inversión de la mayoría de los otros lenguajes de programación, donde el programador especifica un algoritmo y el “qué computa esto” se deja como ejercicio para el lector. Con SQL, el programador no necesita pensar en algoritmos, sino que se enfoca en conceptos de alto nivel. Mientras tanto, una inteligencia artificial integrada en el motor de base de datos (el “planificador de consultas”) deduce el mejor algoritmo.
SQL tiene sus defectos, pero en su núcleo es un concepto muy poderoso. Hemos visto múltiples esfuerzos en las últimas décadas para reemplazar SQL con conceptos de gestión de datos más “modernos”. Pero todos esos esfuerzos han fracasado, y la gente sigue volviendo a SQL. Creo que SQL estará aquí en alguna forma u otra (esperanzadamente, pero no necesariamente incluyendo SQLite) durante muchas décadas más.
(6) ¿Cómo ves la industria de desarrollo de software actual con la popularidad de los sistemas de generación de código automático impulsados por inteligencia artificial?
Creo que el potencial de la inteligencia artificial (IA) está sobrevalorado.
La IA es ciertamente útil. Recuerda que hay una IA (llamada “planificador de consultas”) en el corazón de cada motor de base de datos SQL. Estoy seguro de que se encontrarán nuevos usos para la IA y que las tecnologías de IA serán un ahorro de tiempo valioso en los próximos años. Pero soy escéptico sobre las predicciones apocalípticas para una toma de posesión de la IA.
Me recuerda cuando era niño en la década de 1960 y 1970, y los futuristas predijeron que todos tendríamos helicópteros privados en lugar de coches, que pronto tendríamos colonias humanas en la luna, y que toda nuestra ropa sería hecha de fibras vegetales para que pudiéramos usarla una vez y luego tirarla. Me recuerda cuando la gente decía que los reactores de fusión nuclear harían que la electricidad fuera tan barata que no valdría la pena medirla. Nada de esto se ha cumplido, al menos de momento.
Recientemente, los tecnólogos han estado prediciendo que los coches pronto serían completamente autónomos. Parece que la conducción totalmente autónoma está siempre a dos o tres años vista.
Creo que la IA se desarrollará de manera similar. Seguro que habrá algunos resultados útiles. Pero creo que la generación completamente automática de código será difícil de conseguir. La codificación asistida por IA parece un resultado más probable que la generación de código totalmente autónoma.
(7) Si tuvieras la oportunidad de viajar en el tiempo y dar consejos no técnicos a tu yo más joven, ¿qué sería, y por qué lo consideras importante?
Responderé a una pregunta ligeramente diferente: “¿Qué consejo darías a los jóvenes de hoy?” Mi respuesta: “Resuelve más problemas de los que creas”.
Hay dos lados en esta ecuación: los problemas que creas y los problemas que resuelves. Minimiza el primero y maximiza el segundo.
Todo el mundo crea problemas. Consumes comida y agua y aire. Ocupas espacio de vida. Esperas que tu empleador y/o tus clientes te paguen. No puedes evitar crear todos los problemas, pero puedes evitar crear problemas innecesarios. No desperdicies recursos. No seas difícil de llevar. No seas dramático innecesariamente. No hagas un desastre innecesario.
Por otro lado, resuelve tantos problemas como puedas. Comienza con pequeñas cosas: haz tu cama. Recoge la basura y ponla en la papelera. Sé amable con el cajero que te atiende en la tienda. Estas cosas son buenos ejercicios para resolver problemas más grandes. Una vez que seas bueno en las pequeñas cosas, busca problemas más grandes que resolver. Ayuda a tu familia y amigos. Ayuda a tus clientes. Ayuda a la comunidad.
Si puedes resolver más problemas de los que creas, nunca te faltarán empleo, amigos, amor y felicidad.
Original
(1) What was the pivotal moment that led you to create SQLite, and what specific problems were you trying to solve at that time?
I wanted an SQL database library that I could link with my application and that could read and write content directly from disk instead of sending messages back and forth to a separate server process. I couldn't find such a library, so I wrote my own and called it SQLite.
I was working as a freelance programmer. One of the problem I was hired to solve involved a program to find good approximate solutions to a certain NP-complete graph problem. The “graph” needed to be read out of an Informix database. That worked great most of the time. But sometimes the Informix database would be down and then when the client would double-click on my application, my application would show an error dialog box that said “Cannot connect to database”. There is nothing my application could do about this, since the problem was external to the application. Nevertheless, since it was my application that delivered the error message, I got the trouble ticket.
I thought: “If only I could read the database content directly from disk, then my application wouldn't need to depend on an external server and this issue wouldn't arise.”
The customer did not approve of this idea, so I did not implement SQLite as part of that contract. I started writing SQLite a few months later, on my own time. The first code was checked in on 2000-05-29.
(2) How did SQLite achieve such widespread adoption in the industry, and what factors do you think contributed to its success?
Being a “database guy” was never a part of my career plan. I put the SQLite source code out on the internet as a curiosity, thinking other people might find it interesting. I never anticipated the level of interest that it would provoke. I never thought that SQLite would become a business.
Indeed, for the first two or three years of its existence, SQLite was a scarcely known and seldom used open-source project. I kept improving it, little by little, because I enjoy writing and working on software. But SQLite was not widely deployed. Then beginning in around 2003, I started getting phone calls from the largest tech companies of that time (AOL, Motorola, Symbian) asking for enhancements to and support for SQLite so they could use in their products. I thought to myself: “What? You can actually make money from open-source software?” SQLite became a part-time business at that point. A couple more years passed and Android and iPhone came out, and at that point SQLite became firmly established in the software landscape for embedded devices. I stopped doing freelance development work and began devoting all of my attention to SQLite.
Why was SQLite successful? I don't know, but my guess is because SQLite is simple:
SQLite provides a simpler model for a relational database than client/server database engines like PostgreSQL and MySQL in that there is no server process to keep running. It reads and writes directly from the disk. If the filesystem is working then you can have access to your data. You do not depend on a separate server.
SQLite database is a single file on disk. This simplifies management of multiple databases. It is trivial to make a backup of the database (just copy the file) or to transfer the database from one machine to another. It is much easier for developers to think about because there is a single file on disk that they can point to and say “This is the database”.
The SQLite library has no external dependencies beyond the standard C library, so it is simple to deploy. Furthermore the SQLite library is compact and uses little memory compared to client/server database solutions.
In short, SQLite “just works”. Application developers do not need to stress as much about their data storage solution and can focus more mental effort on solving problems for their customers.
(3) How did Fossil SCM emerge, and what design-level differences does it have compared to Git?
The first code for SQLite was stored in CVS which was the predominate version control system of that era. CVS was great (better than other contemporary version control systems, and far better than systems that came before) but it did have its limitations. So, I began looking for alternatives.
I was inspired by Monotone which had come to my attention because it used an SQLite database as its repository file format. I probably would have moved SQLite into Monotone except for the fact that it needed a custom TCP port and protocol for client/server communications. This was before the wide-spread availability of Virtual Private Servers (VPSes) and so my websites were done via shared hosting and I needed a system where I could run the server side as a CGI script. I started tinkering with these ideas in 2005. Git and Mercurial had also started up at that time and I looked at them too. But as with Monotone, I didn't see a way to run them as CGI. At about the same time, I also had a contract with avionics manufacturer Rockwell Collins and they introduced me to DO-178B which I studied closely. I didn't feel like either Git or Mercurial met the software configuration management requirements of DO-178B. Finding no existing system that met my needs, I once again set out to write my own.
Fossil is like Git (and Monotone and Mercurial) in that it represents the history of a software project as an acyclic directed graph, where each check-in is a node. Nodes are identified by a cryptographic hash and are thus immutable. So the underlying data model is conceptually the same.
Fossil differs from Git in many ways:
The format of individual artifacts (“objects” in Git-parlance) is completely different.
Fossil repositories sync over ordinary HTTP/HTTPS. The server can be run using CGI.
The repository for Fossil is stored in an SQLite database (like Monotone), rather than as a pile-of-files plus the bespoke “packfile” format of Git.
Fossil is a self-contained, standalone executable, making it easy to install, upgrade, and/or uninstall.
In addition to version control, Fossil also supports distributed trouble tickets and wiki and documentation. And it has a built-in developer chat service.
Inspired by DO-178B, Fossil puts a lot of emphasis on maintaining an immutable audit trail and promoting developer situational awareness.
An unintended benefit of writing Fossil is that it also serves as a great testing and “dogfooding” platform for SQLite. When I'm working on Fossil, I have to use SQLite in the same way that any other developer would. This forces me to look at the SQLite API from a different perspective than when I'm working on SQLite itself. It helps me to empathize with the struggles of other developers who are trying to build SQLite into their products, and to be more sympathetic to requests for API enhancements. I've ended up adding a lot of useful features in SQLite simply because I needed them myself for use in Fossil. SQLite is a better product because I use it in the implementation of Fossil.
(4) A general opinion among software developers is that both SQLite and Fossil SCM have good software design, not only in terms of ease of use but also in terms of implementation. What software design principles do you think are relevant for making good software?
(A) Complexity is your enemy. Always keep things as simple as possible.
(B) Avoid using the first solution that comes to mind. If you think about a problem a little longer, often you will come up with a better approach.
(C) Document your code, and especially data structure and variable definitions, very carefully with comments. Write the code such that it can be read, understood, and maintained by others. Explain things clearly. No, the purpose of that subroutine you just wrote or that variable you just declared is not obvious from its name!
(D) Design for testability. It is not sufficient to write software that works - you also need to write software that is easily verified, that can be easily proven to work.
(5) What projects or areas of research are you currently exploring, and how do you see the future of database technology?
We will always have databases. As the old saying goes: “Without data, you are either lucky or you are wrong.” The question should be: “What will databases look like in the future?”
I think that SQL is here for the long term. I didn't used to think that way. Even when I first started writing SQLite, I was still of the opinion that SQL was more about mainframe legacy support and was just an unnecessary complication. But I have since come to recognize that SQL really does have some unstoppable ideas: (1) Transactions, (2) Data abstraction, and (3) A declarative language.
Having transactions is vital to building robust systems. If machines never crashed and the power never went out unexpectedly, then perhaps transactions would not be as important, but those things do happen.
Fred Brooks wrote in “The Mythical Man-Month” that “Representation is the essence of computer programming.” And he was spot on. It is more important to get your data structure right than to get the code right. The code can be replaced, but data structures linger for years and decades. It turns out (and this was a big surprise to me) that the relational data model is great way to define the data structures for most real-world problems.
The key feature of SQL is that the programmer tells the machine “what” to compute, not “how” to compute it. This is an inversion of most other programming language where the programmer specifies an algorithm and the “what does this compute” aspect as left as an exercise to the reader. With SQL, the programmer does not need to think about algorithms, but instead focuses on higher-level concepts. Meanwhile, an AI embedded inside the database engine (the “query planner”) deduces the best algorithm.
SQL has its warts, but at its core it is a very powerful concept. We've seen multiple efforts over the past few decades to replace SQL with newer, more “modern”, data management concepts. But all those efforts have fallen flat, and people keep coming back to SQL. I think SQL will be around in some form or another (hopefully, but not necessarily including SQLite) for many decades to come.
(6) How do you see the current software development industry with the popularity of AI-powered automatic code generation systems?
I think the potential of AI is over-hyped.
AI is certainly useful. Remember, there is an AI (called the “query planner”) at the heart of every SQL database engine. I'm sure new uses for AI will be found, and that AI technologies will prove to be an invaluable time saver in coming years. But I'm skeptical of the apocalyptic predictions for an AI take-over.
I remember when I was a kid in the 1960s and 1970s, futurists were predicting that everybody would have private helicopters rather than cars, that we would soon have human colonies on the moon, and that all our clothing would be made from plant fibers such that you wear an outfit once and then toss it away. I remember people saying that nuclear fusion reactors would make electricity so plentiful that it would be too cheap to meter. None of this has come to pass, at least not yet.
More recently, technologists have been predicting that cars would soon be fully autonomous. It seems like full autonomous driving is always just two or three years away.
Untold billions of dollars of research has gone into these things, but it turned out the end goal is more difficult than originally estimated. I'm guessing that AI will play out similarly. Sure, there will be some useful results. But I think that full automatic code generation will prove to be elusive. AI-assisting coding seems a more likely outcome than fully autonomous code generation.
(7) If you had the opportunity to travel back in time and give non-technical advice to your younger self, what would it be, and why do you consider it important?
I'll answer a slightly different question: “What advice do you give to younglings today?” My answer: “Solve more problems than you create.”
There two sides to this inequality: The problems you create and the problems that you solve. Minimize the first and maximize the second.
Everyone creates problems. You consume food and water and air. You take of living space. You expect your employer and/or your customers to pay you. You cannot avoid creating all problems, but you can avoid creating unnecessary problems. Don't waste resources. Don't be hard to get along with. Don't pick unnecessary fights. Don't be unnecessarily dramatic. Don't make an unnecessary mess.
On the other side, solve as many problems as you can. Start small: Make up your bed. Pick up litter and put in in the waste can. Be kind to the clerk who is ringing up your purchase at the market. These things are good practice for bigger problems. Once you get good at the small things, look for larger problems that your family or friends or neighbors or clients or customers are having and devise innovative solutions for solving those problem. Problem solving is an acquired and a perishable skill. Keep practicing and improving.
If you can consistently solve more problems than you create, you will never lack for employment, friends, love, and happiness.
La versión traducida se realizó usando Llama 3 y DeepL. También doy las gracias a Oscar Fernandez, por indicarme los errores en la traducción.