Neden Her Şeyi Bırakıp Yeniden C Yazmaya Başladım

• Ruby on Rails freelancer’ı olarak 20 yıllık deneyim Common Lisp projelerine uzandı; ancak performans, taşınabilirlik ve çalışma ortamı sınırlamaları birikince yeniden C’yi seçmeye götürdü
• cl-facts, hızlı bir triple store ve iç içe geçirilebilir atomik transaction’lara sahipti; ancak geliştirme süresinin uzaması müşteri kaybetme sonucunu da doğurdu
• Sanal makineler, Linux cgroups tabanlı container’lar ve garbage collector’lara yönelik memnuniyetsizlik, C’nin sistem yazılımları için hâlâ gerçekçi temel olduğu kanaatine yol açtı
• libc3 ile başlayan çalışma; C3 dili, interpreter ic3 ve compiler c3c fikrine genişledi, ad çakışması nedeniyle daha sonra KC3 olarak değiştirildi
• KC3 bugün C89’a port edilmiş bir graph database, REPL ikc3, MVC web sunucusu kc3_httpd ve Markdown’dan HTML’e C implementasyonu tabanlı dokümantasyon sitesini de içeriyor

---

Common Lisp çalışmasının C ile yeniden yazıma uzanan süreci

• Fransa’da bir bilgisayar okulunda 5 yıl eğitim aldıktan ve 20 yıl Ruby on Rails freelancer geliştiricisi olarak çalıştıktan sonra, kısa bir öğrenme süreci olacağı düşünülen Common Lisp giderek daha büyük bir projeye dönüştü
• Common Lisp ile C kodu üreterek bir ASN.1 parser ve sorgu sistemi yaptı; bu çalışma özel bir Common Lisp-to-C SNMP sunucusuna genişledi
• Ardından çeşitli Common Lisp paketleri yazdı
  • cl-unix-cybernetics, GitHub depoları arasında en çok yıldız alan proje oldu
  • cl-streams, cffi-posix de yazıldı
  • cl-facts, Common Lisp graph database olarak kullanılabilen bir triple store’dur
• cl-facts; yüksek performans, atomik transaction’lar, iç içe geçirilebilir transaction’lar, unwind-protect uyumluluğu ve yalnızca 3 macro öğrenmeyi gerektiren kullanım kolaylığıyla ortaya çıkan bir sonuçtur
• cl-facts, Belçika’daki European Lisp Symposium’da lightning talk olarak sunuldu; sunum slaytları facts.pdf dosyasında yer alıyor
• Common Lisp paketi geliştirmek uzun zaman aldığı için müşteriler kaybedildi; ancak Common Lisp’in gelecek kuşaklar için bir araç olduğu değerlendirildi

C, KC3 ve mevcut bileşenler

• Sanal makinelerin CPU ve bant genişliğini emülasyona harcadığı; Linux cgroups tabanlı container’larda RCE ve privilege escalation sorunlarının sürekli keşfedildiği deneyimi, OpenBSD merkezli bir tercihe götürdü
• Terraform, Ansible gibi DevOps araçlarından kaçındı; VM ve container’ların yanı sıra programlama dillerinin kendisinden de memnun olmayan insanları gördü
• Clojure ile her biri kendi dünya algısına sahip binlerce birimin bulunduğu bir strateji oyunu yapma girişimi, garbage collector nedeniyle başarısız oldu
• Common Lisp projelerinin de garbage collector nedeniyle uygulanabilirlik alanı sınırlı kaldı; JVM’in garbage collector’ı ise iyi yapılması büyük maliyet gerektiren ticari bir güçlü yan olarak değerlendirildi
• Performans ve taşınabilirlik düşünüldüğünde, ayrı bir araç yoksa makul seçimin C olduğu sonucuna vardı
  • Linux C ile yazılmıştır
  • OpenBSD C ile yazılmıştır
  • GTK+ nesne yönelimli saf C ile yazılmıştır
  • GNOME C ile yazılmıştır
  • Birçok Linux masaüstü uygulaması da eski C ile yazılmıştır
• libc3 yardımcı kütüphanesiyle başlayıp C3 dili, interpreter ic3 ve compiler c3c tasarımına evrildi
• UTF-8 buffer’ların ve veri yapılarının hızlıca gidip gelmesini sağladı; bellek maliyetini göze alarak bounds-check uyguladı
• Defansif programlamayı merkeze aldı ve bug’ları baştan sıfıra indirme yönünü seçti; KC3 kodunun güvenlik sonucu doğurmadan çalıştığını belirtti
• İlk interpreter, dilin tüm veri türlerini barındıran enum-tagged union olan tags’i REPL’de işleyen bir biçimde geliştirildi
• 3 yıl sonra 5 katmanlı refactoring tamamlandı; testlerin yeniden tamamı geçti ve web sunucusu da tekrar bozulmayan bir duruma geldi
• Dilin adı, C3 zaten kullanımda olduğu için KC3 olarak değiştirildi
• Mevcut Common Lisp graph database’i cl-facts, C89’a port edildi
  • Büyük bölümü 2020’deki Covid-19 kapanması sırasında yazıldı
  • Triple ekleme/silme, recursive sorgu sistemi, transaction’lar, logging ve persistence içeriyor
  • Common Lisp’teki özgün tasarım C89 ile neredeyse aynen uygulandı
• KC3, çeşitli algoritmik veri türlerinin biçimsel anlamını ele almak için parser ve generator’lar da içeriyor
  • Structs, Linked lists, Maps, Hash tables, Time, Complex, Rationals, Tuples, Code blocks, Quotes, Unquotes, Copy on write, Skip lists, Sets gibi bileşenler yer alıyor
  • Macro’lar var; örnekler sonraki yazıda ele alınacak
  • José Valim ve Elixir çalışmalarından büyük ilham alındı
• ikc3 REPL, klavye veya dosya girdisini parse edip KC3 değerlendirme sonuçlarını standart çıktıya gönderir; KC3 unit test’lerinin 2. aşamasının büyük kısmında kullanılır
• kc3_httpd, MVC framework’e sahip bir web sunucusudur ve mevcut web sayfalarını üretir
• Common Lisp yazısı 700 görüntülenme aldı; dokümantasyon web sitesi kc3_httpd ve genişletilmiş Markdown-to-HTML C implementasyonu ile yazıldı