- 20 Jahre Erfahrung als Ruby-on-Rails-Freelancer führten zu Common Lisp-Projekten, doch zunehmende Grenzen bei Performance, Portabilität und Laufzeitumgebungen brachten ihn dazu, wieder C zu wählen
- cl-facts bot einen schnellen Triple Store und verschachtelbare atomare Transaktionen, doch die lange Entwicklungszeit führte auch dazu, dass Kunden verloren gingen
- Unzufriedenheit mit virtuellen Maschinen, Linux-cgroups-basierten Containern und Garbage Collectors führte zur Einschätzung, dass C weiterhin die realistische Grundlage für Systemsoftware ist
- Die Arbeit begann mit libc3 und weitete sich zu Entwürfen für die Sprache C3, den Interpreter ic3 und den Compiler c3c aus; wegen eines Namenskonflikts wurde daraus später KC3
- KC3 umfasst heute eine nach C89 portierte Graphdatenbank, die REPL ikc3, den MVC-Webserver kc3_httpd und eine Dokumentationsseite auf Basis einer in C implementierten Markdown-to-HTML-Umsetzung
Wie Common-Lisp-Arbeit zu einer Neuschreibung in C führte
- Nach fünf Jahren Studium an einer französischen Computerschule und 20 Jahren Arbeit als freiberuflicher Ruby-on-Rails-Entwickler wurde Common Lisp, das zunächst wie eine kurze Lernphase erschien, zu einem immer größeren Projekt
- Mit Common Lisp wurde C-Code generiert, um einen ASN.1-Parser und ein Query-System zu erstellen; diese Arbeit wurde zu einem maßgeschneiderten Common-Lisp-to-C-SNMP-Server erweitert
- Anschließend entstanden mehrere Common-Lisp-Pakete
- cl-unix-cybernetics wurde das Projekt mit den meisten Sternen unter den GitHub-Repositories
- Auch cl-streams und cffi-posix wurden geschrieben
- cl-facts ist ein Triple Store, der als Common-Lisp-Graphdatenbank genutzt werden kann
- cl-facts bietet schnelle Performance, atomare Transaktionen, verschachtelbare Transaktionen, Kompatibilität mit
unwind-protectund eine einfache Nutzung, für die man nur drei Makros lernen muss - cl-facts wurde beim European Lisp Symposium in Belgien als Lightning Talk vorgestellt; die Folien stehen unter facts.pdf
- Die Entwicklung der Common-Lisp-Pakete dauerte lange und führte zum Verlust von Kunden, dennoch wird Common Lisp als Werkzeug für künftige Generationen betrachtet
C, KC3 und der aktuelle Aufbau
- Die Erfahrung, dass virtuelle Maschinen CPU und Bandbreite für Emulation verschwenden und in Linux-cgroups-basierten Containern immer wieder RCE- und Privilege-Escalation-Probleme entdeckt werden, führte zu einer auf OpenBSD fokussierten Wahl
- DevOps-Tools wie Terraform und Ansible wurden vermieden; außerdem begegnete man Menschen, die nicht nur mit VMs und Containern, sondern auch mit Programmiersprachen selbst unzufrieden waren
- Ein Fall, in dem mit Clojure ein Strategiespiel entstehen sollte, in dem Tausende Einheiten jeweils ihre eigene Wahrnehmung der Welt haben, scheiterte am Garbage Collector
- Auch Common-Lisp-Projekte waren durch den Garbage Collector in ihrem Einsatzbereich eingeschränkt; der Garbage Collector der JVM wird als kommerzielle Stärke bewertet, deren gute Umsetzung hohe Kosten verursacht
- Unter Performance- und Portabilitätsgesichtspunkten ist die vernünftige Wahl ohne zusätzliche Werkzeuge C
- Linux ist in C geschrieben
- OpenBSD ist in C geschrieben
- GTK+ ist in objektorientiertem, reinem C geschrieben
- GNOME ist in C geschrieben
- Auch viele Linux-Desktop-Apps sind in altem C geschrieben
- Ausgehend von der Utility-Bibliothek libc3 entwickelte sich die Arbeit zu Entwürfen für die Sprache C3, den Interpreter ic3 und den Compiler c3c
- UTF-8-Puffer und Datenstrukturen wurden so gestaltet, dass sie schnell hin- und hergereicht werden können; unter Inkaufnahme von Speicherkosten wurde Bounds Checking eingesetzt
- Defensive Programmierung wurde in den Mittelpunkt gestellt, mit dem Ziel, Bugs von Anfang an auf null zu reduzieren; der KC3-Code läuft nach eigener Aussage ohne sicherheitsrelevante Implikationen
- Der frühe Interpreter wurde so gebaut, dass tags, eine enum-tagged union, die alle Datentypen der Sprache enthält, in der REPL verarbeitet wurden
- Nach drei Jahren wurde ein Refactoring über fünf Schichten abgeschlossen, alle Tests bestanden wieder, und auch der Webserver befand sich erneut in einem Zustand, in dem er nicht mehr brach
- Da der Name C3 bereits verwendet wurde, wurde die Sprache in KC3 umbenannt
- Die bestehende Common-Lisp-Graphdatenbank cl-facts wurde nach C89 portiert
- Der Großteil wurde während des Covid-19-Lockdowns 2020 geschrieben
- Sie umfasst das Hinzufügen und Löschen von Triples, ein rekursives Query-System, Transaktionen, Logging und Persistenz
- Das ursprüngliche Common-Lisp-Design wurde nahezu unverändert in C89 umgesetzt
- KC3 enthält außerdem Parser und Generatoren, um die formale Bedeutung verschiedener algorithmischer Datentypen zu behandeln
- Dazu gehören Structs, Linked lists, Maps, Hash tables, Time, Complex, Rationals, Tuples, Code blocks, Quotes, Unquotes, Copy on write, Skip lists, Sets und weitere
- Es gibt Makros; Beispiele sollen in einem späteren Beitrag behandelt werden
- Große Inspiration kam von José Valim und der Arbeit an Elixir
- Die ikc3-REPL parst Eingaben von Tastatur oder Datei und gibt die Ergebnisse der KC3-Auswertung auf der Standardausgabe aus; sie wird für den Großteil der zweiten Stufe der KC3-Unit-Tests verwendet
- kc3_httpd ist ein Webserver mit MVC-Framework und erzeugt derzeit die Webseiten
- Common-Lisp-Beiträge erreichten 700 Aufrufe, und die Dokumentationswebsite wurde mit kc3_httpd und einer erweiterten Markdown-to-HTML-Implementierung in C erstellt
Noch keine Kommentare.