Repensar la programación de bases de datos
Un nuevo lenguaje funcional de código cerrado, inspirado en Elm y que compila a SQL para PostgreSQL y SQLite, reaviva debates de larga data sobre la mejor manera de programar contra bases de datos relacionales. Sus defensores aprecian sus consultas componibles y fuertemente tipadas, la seguridad de tipos de extremo a extremo entre la base de datos y el frontend, y funciones como los tipos suma y la seguridad de fila reforzada, mientras que sus críticos ven simplemente otra abstracción al estilo ORM que oscurece SQL, se queda atrás respecto a las capacidades de la base de datos y arriesga acoplar demasiado los datos a un solo lenguaje y proveedor. Muchos también cuestionan la licencia por suscripción y la gobernanza de un único proveedor, argumentando que la madurez, el ecosistema y la alineación de SQL con el modelo relacional siguen superando las mejoras ergonómicas incrementales de las nuevas capas de consulta.
Recepción general
- A muchos les resulta estéticamente agradable y conceptualmente emocionante el nuevo lenguaje de consultas funcional, especialmente a los fans de la programación funcional y del diseño al estilo Elm.
- Otros ven que convierte un SQL conciso en código más verboso y menos legible, y dudan de que aporte suficiente beneficio frente al SQL en bruto o a las herramientas existentes.
- Varios comentan que otra “reemplazo de SQL” difícilmente logrará una adopción amplia dada la madurez y el ecosistema de SQL.
SQL frente a lenguaje de consultas funcional
- Sus defensores sostienen que SQL es torpe, antiguo, basado en cadenas y difícil de componer o analizar estáticamente; quieren pipelines, composición estilo map/filter y comprobación de tipos de extremo a extremo.
- Quienes defienden SQL destacan su base matemática (álgebra relacional), su madurez, sus potentes funciones (CTEs, funciones de ventana) y su ubicuidad, incluida la accesibilidad para personas no programadoras.
- Algunos señalan la divergencia de SQL respecto de la teoría relacional pura (semántica de multiconjuntos, NULLs), pero aun así lo ven como la herramienta adecuada para almacenar y consultar datos.
ORM, gestión de esquemas y expresividad
- Hay debate sobre si esto es “solo un ORM disfrazado”. Desde el punto de vista del usuario, muchos dicen que se comporta como un ORM pese a las afirmaciones de marketing.
- Los críticos de los esquemas estilo ORM-en-código argumentan que esas capas se quedan atrás respecto a las capacidades de la base de datos (particionado, compresión, restricciones avanzadas) y, en última instancia, fuerzan un regreso a SQL.
- Otros prefieren enfoques que tratan SQL como la fuente de verdad y generan enlaces tipados a partir de él.
Seguridad de tipos e integración frontend–backend
- Los defensores destacan la seguridad de tipos de extremo a extremo desde la base de datos hasta el backend y el frontend, incluidos los tipos suma y pipelines reutilizables, como un gran valor añadido.
- Los escépticos contraargumentan que SQL ya es fuertemente tipado (salvo en motores como SQLite) y que la seguridad de tipos entre capas también puede lograrse mediante generación de código y mecanismos de “describe”.
Propiedad de la base de datos, arquitectura y longevidad
- A algunos les preocupa que un lenguaje “posea” la base de datos, sobre todo con codificaciones personalizadas (p. ej., para tipos suma) que complican la interoperabilidad y el acceso a los datos a largo plazo.
- Varios subrayan que las bases de datos y los esquemas SQL a menudo sobreviven a cualquier aplicación o lenguaje concreto; prefieren que la base de datos sea el centro estable, no un objetivo de compilación.
- Existe escepticismo sobre si es sensato vincular la representación de los datos de forma estrecha a un lenguaje cerrado y de nicho para sistemas de larga vida.
Licencia, modelo de financiación y confianza
- La licencia de código cerrado basada en suscripción genera una preocupación significativa. Una cláusula citada sugiere que los usuarios podrían perder acceso a los datos cuando caduquen las suscripciones, algo que muchos consideran inaceptable para sistemas críticos.
- La experiencia previa con proyectos similares llevó a varios comentaristas a preocuparse por el “bus factor” y el mantenimiento a largo plazo; la dependencia de un equipo pequeño y único se ve como arriesgada.
- Algunos celebran la experimentación con nuevos modelos de financiación para un desarrollo sostenible, pero aun así no lo adoptarían en proyectos profesionales ni siquiera personales debido al riesgo.
Alternativas y antecedentes
- Los comentaristas señalan intentos previos con ideas similares: LINQ, bibliotecas de Haskell como Selda, sistemas basados en Datalog, generadores de código SQL (p. ej., sqlc, Ormin) y otros “lenguajes de programación de bases de datos”.
- Practicantes con experiencia sostienen que décadas de intentos de lenguajes integrados con bases de datos y ORM han fracasado en gran medida frente a “usar solo SQL + un driver”, especialmente en rendimiento y transparencia.
Usabilidad, documentación y preguntas abiertas
- La gente quiere ver ejemplos complejos de joins entre varias tablas y cómo se expresan las agrupaciones/agregaciones, señalando que los ejemplos simples no resultan convincentes.
- A algunos les intrigan funciones como la seguridad reforzada a nivel de fila y los tipos de datos algebraicos, pero encuentran que la sintaxis es difícil de leer de un vistazo.
- La documentación se describe como escasa (por ejemplo, palabras clave mencionadas pero no explicadas por completo), lo que dificulta evaluar el sistema en profundidad.
- Sigue sin estar claro hasta qué punto el lenguaje expone todas las capacidades de PostgreSQL/SQLite y cómo se manejan en la práctica las migraciones y la evolución del esquema, especialmente para tipos avanzados.