Por qué dejé todo y empecé a escribir C otra vez

• Tras 20 años de experiencia como freelancer de Ruby on Rails, el trabajo derivó en un proyecto de Common Lisp, pero las limitaciones acumuladas de rendimiento, portabilidad y entorno de ejecución lo llevaron a elegir C nuevamente
• cl-facts tenía un almacén de triples rápido y transacciones atómicas anidables, pero el tiempo de desarrollo se extendió y también terminó provocando la pérdida de clientes
• La insatisfacción con las máquinas virtuales, los contenedores basados en Linux cgroups y los recolectores de basura llevó a concluir que C sigue siendo una base realista para el software de sistemas
• El trabajo que empezó con libc3 se expandió hacia la idea del lenguaje C3, el intérprete ic3 y el compilador c3c; luego pasó a llamarse KC3 por un conflicto de nombres
• Actualmente, KC3 incluye una base de datos de grafos portada a C89, el REPL ikc3, el servidor web MVC kc3_httpd y hasta un sitio de documentación basado en una implementación en C de Markdown a HTML

---

Cómo el trabajo en Common Lisp derivó en una reescritura en C

• Después de estudiar durante 5 años en una escuela de computación en Francia y trabajar 20 años como desarrollador freelancer de Ruby on Rails, Common Lisp, que pensó que sería un aprendizaje breve, se convirtió en un proyecto cada vez más grande
• Generó código C con Common Lisp para crear un parser ASN.1 y un sistema de consultas, y ese trabajo se expandió a un servidor SNMP personalizado de Common Lisp a C
• Luego escribió varios paquetes de Common Lisp
  • cl-unix-cybernetics se convirtió en el proyecto con más estrellas entre sus repositorios de GitHub
  • También escribió cl-streams y cffi-posix
  • cl-facts es un almacén de triples que puede usarse como base de datos de grafos en Common Lisp
• cl-facts es un resultado con alto rendimiento, transacciones atómicas, transacciones anidables, compatibilidad con unwind-protect y una usabilidad que solo requiere aprender 3 macros
• cl-facts se presentó como lightning talk en el European Lisp Symposium en Bélgica, y las diapositivas de la presentación están en facts.pdf
• El desarrollo de paquetes de Common Lisp tomó mucho tiempo y le hizo perder clientes, pero consideró que Common Lisp es una herramienta para las generaciones futuras

C, KC3 y la configuración actual

• La experiencia de que las máquinas virtuales desperdician CPU y ancho de banda en emulación, y de que en los contenedores basados en Linux cgroups siguen apareciendo problemas de RCE y escalada de privilegios, llevó a una elección centrada en OpenBSD
• Evitó herramientas DevOps como Terraform y Ansible, y también vio a personas insatisfechas no solo con VM y contenedores, sino con los propios lenguajes de programación
• Un caso en el que se intentó crear en Clojure un juego de estrategia con miles de unidades, cada una con su propia percepción del mundo, fracasó por el recolector de basura
• Los proyectos de Common Lisp también tuvieron un alcance limitado por el recolector de basura, y el recolector de basura de la JVM se evalúa como una fortaleza comercial que requiere un gran costo para hacerlo bien
• Considerando rendimiento y portabilidad, concluyó que, salvo que haya herramientas aparte, la elección razonable es C
  • Linux está escrito en C
  • OpenBSD está escrito en C
  • GTK+ está escrito en C puro orientado a objetos
  • GNOME está escrito en C
  • Muchas apps de escritorio de Linux también están escritas en C antiguo
• A partir de la biblioteca de utilidades libc3, el trabajo evolucionó hacia el lenguaje C3, el intérprete ic3 y la idea del compilador c3c
• Hizo que los búferes UTF-8 y las estructuras de datos se movieran rápidamente entre sí, y aplicó bounds-checking aceptando el costo de memoria
• Puso la programación defensiva en primer plano y tomó la dirección de reducir los bugs a 0 desde el principio; afirma que el código de KC3 se ejecuta sin implicancias de seguridad
• El intérprete inicial se creó como un REPL que procesaba tags, una union con enum-tagged que contiene todos los tipos de datos del lenguaje
• Tres años después terminó una refactorización de 5 capas, todas las pruebas volvieron a pasar y el servidor web también quedó en un estado en el que ya no se rompe
• Como el nombre C3 ya estaba en uso, el lenguaje pasó a llamarse KC3
• La base de datos de grafos existente en Common Lisp, cl-facts, fue portada a C89
  • La mayor parte se escribió durante el confinamiento por Covid-19 en 2020
  • Incluye agregado y eliminación de triples, un sistema de consultas recursivas, transacciones, logging y persistencia
  • Implementa casi tal cual en C89 el diseño original en Common Lisp
• KC3 también incluye parsers y generadores para tratar el significado formal de varios tipos de datos algorítmicos
  • Incluye Structs, Linked lists, Maps, Hash tables, Time, Complex, Rationals, Tuples, Code blocks, Quotes, Unquotes, Copy on write, Skip lists, Sets, entre otros
  • Tiene macros, y en una publicación posterior se tratarán ejemplos
  • Se inspiró mucho en José Valim y el trabajo en Elixir
• El REPL ikc3 parsea la entrada desde teclado o archivos y envía el resultado de la evaluación de KC3 a la salida estándar; se usa en la mayor parte de la segunda etapa de las pruebas unitarias de KC3
• kc3_httpd es un servidor web con framework MVC y genera las páginas web actuales
• El artículo sobre Common Lisp registró 700 visitas, y el sitio web de documentación está escrito con kc3_httpd y una implementación extendida en C de Markdown a HTML