Lisp'e Giden Yol: Neden Lisp?

 (scotto.me)
1 puan yazan GN⁺ 3 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Lisp'te asıl mesele parantezli sözdiziminden çok, dili probleme göre genişletme düşünce biçimidir; gerçek değeri ancak REPL, paketler, semboller, condition ve restart mekanizmaları öğrenildiğinde ortaya çıkar
  • Kodun da verinin de liste olarak ifade edildiği homoiconicity sayesinde makrolar, değerlendirme öncesinde kodu veri gibi ele alarak yeni kontrol yapıları ve sözdizimsel soyutlamalar oluşturabilir
  • Common Lisp'te yerleşik while olmasa da bunu defmacro ile eklemek mümkündür; ancak bunu fonksiyonla taklit etmeye çalışınca argümanlar hemen değerlendirildiği için body kod değil değer haline gelir
  • Lisp geliştirme, çalışan süreç üzerinde sürekli kod değerlendirmeye dayanan REPL güdümlü geliştirmeye daha yakındır; bu sayede fonksiyonlar, makrolar ve değişkenler programı durdurmadan yeniden tanımlanarak evrimleştirilebilir
  • Dilin genişletilebilirliği ile canlı sistem yaklaşımı birleştiğinde, dahili DSL'leri kullanıcılara açan genişletilebilir yazılımlar üretmek mümkün olur; AutoLISP ve Emacs bunun temsilî örnekleridir

Lisp'in gerektirdiği farklı programlama sezgisi

  • Lisp ile ilk kez karşılaşan programcılar, bol parantezli sözdizimi, kendine özgü girintileme ve format fonksiyonunda ilk argümanla standart çıktının belirtilmesi gibi noktalara yabancılık hisseder
  • Lisp öğrenmek için yalnızca kod okumak yetmez; paketler ve semboller, proje oluşturma, kütüphane içe aktarma, REPL, condition ve restart mekanizmaları da kullanılabilmelidir
  • Daha büyük değişim ise algoritmaları kurma biçiminde ortaya çıkar
    • Lisp, diğer dillerde yapılması zor olan şeyleri mümkün kılar ve algoritmaların biçimini de değiştirir
    • Akış, önce probleme uygun olarak dili büyütüp ardından o dille program yazmaya doğru gider
  • Blub paradox, yalnızca daha az güçlü diller kullanmış programcıların Lisp'in güçlü yanlarını neden fark etmekte zorlandığını açıklayan bir kavramdır

Genişletilebilir bir dil

  • Lisp kendisini genişletebilir; Lisp uzmanları buna programmable programming language der
  • Buradaki temel araç macrodur
    • C, Rust veya Swift'teki makrolar gibi yalnızca tekrar eden kodu kaldırmakla sınırlı değildir
    • Lisp makroları, dilin bir parçası haline gelen yeni yapı taşları oluşturabilir
  • Common Lisp'te yerleşik bir while operatörü yoktur, ancak bu defmacro ile doğrudan eklenebilir
(defmacro while (condition &body body)
  `(loop while ,condition do
     (progn ,@body)))
  • Bu while makrosu, condition doğru olduğu sürece body içindeki birden fazla komutu çalıştırır
    • loop, karmaşık yinelemeler yazmak için kullanılan bir makrodur
    • progn, birden fazla ifadeyi sırayla çalıştırır ve son ifadenin sonucunu döndürür
  • Sonuç olarak (loop while ... do (progn ...)) yerine (while ...) biçimi kullanılabilir; böylece kod kısalır ve C'deki while yapısına benzer hale gelir

Makro ile fonksiyon arasındaki belirleyici fark

  • Aynı davranışı fake-while adlı bir fonksiyonla kurmaya çalışınca bu başarısız olur
(defun fake-while (condition body)
  (loop while condition do
    (funcall body)))
  • fake-while çağrısında argümanlar önce değerlendirilir
    • condition, doğruluk değeri t olur
    • progn içindeki (print counter) çalışır ve (decf counter) 2 döndürür
    • body, artık bir kod bloğu değil 2 değeridir
  • Sonrasında funcall bir fonksiyon bekler, ama 2 aldığı için The value 2 is not of type FUNCTION benzeri bir tür hatası oluşur
  • Buna karşılık while makrosu, condition ile body'yi hemen değerlendirmez; olduğu gibi korur
    • Genişleme sonucu macroexpand-1 ile görülebilir
    • Derleyici, genişletilmiş (LOOP WHILE ... DO (PROGN ...)) biçimindeki kodu alır
  • Makrolar, fonksiyonlardan farklı olarak argümanları önceden değerlendirmeden saf veri olarak işlediği için bu tür dönüşümler mümkündür

Listeler, s-expression ve homoiconicity

  • Lisp programları, symbolic expression yani s-expression dizilerinden oluşur
  • s-expression iki türe ayrılır
    • atom: sayı, string, sembol gibi veri birimleri
    • liste: atomları veya başka listeleri içeren koleksiyonlar
  • Lisp adı, LISt Processing'den gelir ve programı oluşturan komutlar da listelerle ifade edilir
  • Lisp'te liste hem temel veri yapısıdır hem de kod yazma biçimidir
    • Kodun da verinin de liste olarak ifade edilmesi özelliğine homoiconicity denir
  • Aynı (+ 1 2) listesi, değerlendirilip değerlendirilmemesine göre farklı davranır
    • (+ 1 2) kod olarak değerlendirilir ve 3 döndürür
    • '(+ 1 2) değerlendirilmez, veri listesi olarak aynen döner
  • Lisp, Polish notation kullanır; fonksiyon adı listenin ilk öğesidir, argümanlar ise onun ardından gelir
  • Kod ile veri arasındaki sınır ince olduğu için makrolar kaynak kodu dönüştürebilir ve program yazan programlar oluşturulabilir

Makroların ürettiği kod soyutlaması

  • Dili genişletmek, belirli bir program alanı için daha ifade gücü yüksek yeni yapı taşları üretmeyi sağlar
  • Tekrar eden boilerplate, özel makrolarla değiştirilerek kod azaltılır ve zaman kazanılır
  • Yeni kontrol yapıları oluşturularak kaynaklara erişim ve form değerlendirme biçimi denetlenebilir
  • Makrolar kod üretir, performansı iyileştirir ve karmaşık ya da hata üretmeye açık kodu gizleyen sözdizimsel soyutlamalar sunar

Lisp canlı bir sistemdir

  • Lisp, sadece bir programlama dili olmaktan çok çalışan canlı bir sistem olarak ele alınır
  • Yaygın dillerde akış çoğu zaman editörde kod yazma, sonra derleme ve çalıştırma, ardından gözlemleme, test etme ve hata ayıklama şeklindedir
  • Lisp'te ise önce Lisp süreci başlatılır, ardından REPL'e bağlanılır ve proje bu sürecin içine yüklenir
  • REPL, Read-Eval-Print Loop'un kısaltmasıdır; kodu değerlendirip sonucu anında gösteren etkileşimli bir ortamdır
    • Çalışmakta olan programı yürüten Lisp sürecine açılan bir pencere görevi görür
  • Lisp geliştiricileri, çalışan süreç içinde sürekli kod değerlendirir ve sonucu REPL'de doğrudan görür
    • tek tek fonksiyon testleri
    • veritabanı sorguları
    • değişken inceleme
    • hata ayıklama gibi işler de REPL üzerinden yapılabilir
  • Lisp sürecinin durmasına gerek yoktur; haftalarca ayakta kalabilir
  • Fonksiyonlar, makrolar ve değişkenler, dahili bellek olan environment içinde sürekli tanımlanır ve yeniden tanımlanır; bu akışa REPL güdümlü geliştirme denir

Lisp'te hot reloading

  • Web frontend dünyasında, dosya kaydı ya da sayfa yenileme ile JavaScript kodunun hot reload olması tanıdık bir deneyimdir
  • Yaygın hot reloading yaklaşımı; dosya izleme, değişen modülleri yeniden derleme ve değişiklikleri websocket üzerinden enjekte etme gibi ayrı araçlara ve tekniklere dayanır
  • Her yazılım yığını aynı düzeyde hot reloading sunmaz
    • bazı backend framework'lerinde yeniden derleme gerekir
    • desktop ve mobile geliştirme ortamlarında durum karışıktır
    • low-level dillerde çoğu zaman her seferinde tam derleme gerekir
  • Lisp'te hot reloading ayrı bir araç değil, canlı ortamda kod değerlendirilirken doğal olarak ortaya çıkan bir özelliktir
    • Bir sembol yeniden tanımlandığında fonksiyonlar, veriler ve makrolar yeni tanımı kullanır
    • durdurup derleme, testleri ayrıca çalıştırma ya da özel bir debugger kullanma ihtiyacı azalır
  • Lisp ile programlama, bir programı monte etmekten çok onu evrimleştirmeye benzer

Genişletilebilir yazılım

  • Dili genişletebilme ve canlı sistem yaklaşımı, Lisp'te genişletilebilir yazılım geliştirmeyi kolaylaştırır
  • Tipik desktop programlar eklentiler ya da scripting dilleri üzerinden genişletilir
    • geliştiricinin genişletme sistemini tasarlayıp sürdürmesi gerekir
    • kullanıcıların da eklenti veya uzantı yazmak için belirli API'leri öğrenmesi gerekir
  • Lisp'te ise makrolar aracılığıyla davranışlar kapsüllenip yeniden kullanılabilir hale gelirken doğal olarak DSL'ler oluşur
  • Bir yazılımı genişletilebilir yapmak için, içeride geliştirilen DSL'yi kullanıcıya açmak yeterlidir
  • CMS sunucusu örneğinde, server-side web sayfası üretimi için kullanılan html makrosu kullanıcılara sunulabilir
    • Kullanıcılar, Lisp değişkenlerini, dolist döngüsünü ve format ile string biçimlendirmeyi aynen birlikte kullanabilir
    • Geleneksel template dillerindeki {{ user_name }} ya da {% for %} gibi ayrı bir sözdizimini öğrenmeleri gerekmez
  • Bu DSL, Lisp'in koşulları, özyineleme, higher-order function'lar ve REPL üzerinden adım adım hata ayıklama yeteneğini aynen devralır
  • Matematiksel grafik yazılımı örneğinde ise formüller ve çizim için bir DSL açığa çıkarılır; kullanıcılar eğrileri ve noktaları kısa kodlarla çizebilir

Gerçek örnekler ve Lisp'in konumu

  • AutoCAD, tekrar eden işleri otomatikleştirmek ve karmaşık geometriler üretmek için AutoLISP kullanır
  • Emacs, büyük ölçüde kendi Lisp lehçesiyle yazılmış, yüksek genişletilebilirliğe sahip bir metin editörüdür
    • PDF okuyucu
    • web tarayıcı
    • e-posta istemcisi
    • RSS okuyucu
    • terminal çoklayıcı
    • Git istemcisi
    • müzik çalar
    • sohbet istemcisi
    • elektronik tablo
    • IRC istemcisi
    • hatta masaüstü pencere yöneticisi olarak genişletilmiş örnekler sıralanır
  • R. M. Stallman, Lisp'i güçlü ve zarif bir programlama dilinin ne anlama geldiğini kavratabilen bir dil olarak değerlendirir
  • Lisp'in bir gün varsayılan dil kadar yaygın kullanılacağı yönündeki beklenti gerçekleşmedi ve bundan sonra da gerçekleşmesi düşük bir ihtimal gibi görünüyor
  • Buna rağmen Lisp, 1960'lardan bu yana varlığını sürdürerek Fortran'dan sonra hâlâ kullanımda olan en eski programlama dili haline geldi
  • Lisp'in değeri, genişletilebilirlik, etkileşimli ortam ya da REPL gibi tek tek özelliklerde değil, bunların birleşiminde yatar

İlgili okumalar

1 yorum

 
GN⁺ 3 시간 전
Hacker News görüşleri

  • Programlama, aydınlık taraf ile karanlık taraf arasındaki gerilim üzerine kurulu
    Aydınlık taraf, programcının hata yapmasını engellemeye çalışır: goto’yu kaldırmak, statik tipler eklemek, hataların ifade edilemez hale gelmesini sağlamak gibi
    Karanlık taraf ise programcıya güç verir: makrolar, operatör aşırı yükleme, kendi kendini değiştiren kod, hatta çok satırlı regex’lere kadar her şeye serbestçe izin verir
    Lisp’in, programcının her şeyi yapabilmesine izin vermesi bakımından açıkça karanlık tarafta olmasına rağmen, aydınlık taraf programcıları tarafından da saygı görmesi ilginç. Bunun nedeni, dilin sadeliğinin Platoncu ve neredeyse bozulamaz görünmesi olabilir; ya da Lisp’in o kadar saf olması ki programlama evrenini doğuran bir tanrı gibi iki tarafı da kapsıyor olabilir

    • Dinamik tip ve statik tip tartışmalarında gördüğüm bir sözü uyarlarsak, izin verici diller tek başına çalışan programcıya güç verir ama ekip geliştirmede daha kısıtlayıcı dillere ihtiyaç olur
      Birlikte çalışacağınız insanları seçemezsiniz, ekip içindeki yetkinlik düzeyini de seçemezsiniz. Daha az deneyimli bir ekip arkadaşı hata yaptığında, dil ne kadar izin vericiyse sonuçları da o kadar büyük olur
      Bu yüzden kod incelemesi gerekir, ama o zaman da deneyimli programcıları öğretmene dönüştürmüş olursunuz. Diğer programcıların becerisini artırmaya harcanan zamanın bir kısmının boşa gitmesinin nedeni, programcıların her an gelip gidebilmesidir. Yapay zeka bu dengeyi değiştirebilir
      Sonuçta asıl mesele küçük ve yetkin ekipleri korumaktır, ama şirket politikaları yüzünden bu kolay değildir. Örneğin bus factor kaygısı ya da çıkış süresini kısaltmak için ekibe daha fazla geliştirici ekleme fikri sık sık ortaya çıkar
    • Lisp, genel olarak kesin çöp toplamaya sahip olduğu için aydınlık tarafa daha yakın sayılabilir. Çalışma zamanı tip kontrollerini tip güvenliği olarak sayarsanız, aslında epey tip güvenlidir de
      Yüksek güvenilirlikli sistemler Erlang ile de yazılıyor; biraz gözlerinizi kısarsanız onu başka bir Lisp lehçesi gibi de görebilirsiniz. Hatta LFE adında, Lisp tarzı bir Erlang olan S-ifadesi tabanlı bir sürüm de var
      Erlang’ın güvenilirliğinin özü, olağanüstü düzeyde hata önleme değil, hatadan kurtarma üzerinedir. Aydınlık/karanlık sınıflandırmasını ise sevdim
    • Bence Lisp’in büyük özelliği, değiştirilebilir değişken atamalarını çıkarırsanız temelde bildirimsel olması ve zorunlu bir paradigma olmamasıdır
      Statik tipler olmasa ve makrolar kontrolden çıkabilse bile, bildirimsel/işlevsel düşünce için taban çizgisi çok daha güçlü olduğu için programları daha net düşünmek ve akıl yürütmek adına iyi bir başlangıç noktası sunuyor
    • Malbolge’u hangi tarafa koyardık merak ediyorum. Peki Python, Haskell, Idris, Clean, C, K hangi tarafta?
      Aydınlık/karanlık ayrımı fazla basitleştirici görünüyor. Programlama dillerindeki denge çok karmaşık ve ilginç bir konu
      Yıllar boyunca çeşitli dilleri denedikten sonra bunun en sonunda kullanım bağlamı, kişisel zevk ve hedefler meselesi olduğunu gördüm. “Tüm zamanların en iyi programlama dili” diye bir şey yok; “aydınlık taraf programlaması için en iyisi” ya da “karanlık taraf programlaması için en iyisi” diye bir şey de yok
      Sanat resminde de aydınlık/karanlık taraf diye bir şey yoktur. Kuşkusuz daha büyük eserler vardır, ama herkesin diğer tüm resimlerle kıyaslandığında en güzel bulacağı tek bir “en iyi tablo” yoktur
      https://en.wikipedia.org/wiki/Malbolge
      https://en.wikipedia.org/wiki/Clean_(programming_language)
      https://en.wikipedia.org/wiki/K_(programming_language)
    • Aydınlık ve karanlığı birbirine karıştırmış gibi görünüyor. Yaratıcının en iyisini bildiği varsayımına dayanan kısıtlama ve disiplin karanlık taraftır; gücü insana emanet eden taraf ise aydınlık taraftır

  • Son birkaç ayda harika yeni editörler ve araçlar çıktı; bunları kaçırmamak gerekir
    Mine, tek indirilebilir uygulama olarak hot reloading ve anında debugging dahil, etkileşimli ve artımlı geliştirme akışını deneyimlemek için gereken her şeyi sunuyor. CL ve Coalton için
    https://coalton-lang.github.io/20260424-mine/
    OLIVE, VSCode için el yapımı bir eklenti; ICL ise terminal ve tarayıcı için yeni bir REPL ve gelişmiş özellikler sunuyor. Bonus olarak bir de JSCL tabanlı JupyterLite çekirdeği var, yani %100 tarayıcı içinde çalışıyor
    Hepsi burada görülebilir: https://lispcookbook.github.io/cl-cookbook/editor-support.ht...

    • mine kaynak kodunu bulamıyorum. Bir bağlantı var mı?

  • Web sitesinde bir sözdizimi vurgulama hatası var gibi görünüyor. Gövdeye eklenmiş kod parçaları siyah görünüyor, fareyle seçince gerçek metni görebiliyorsunuz
    Aynı hata masaüstü Chrome ve iPad Safari’de de görünüyor

    • Bu, arka plan rengini değiştirirken her zaman ön plan rengini de belirtmek gereken klasik durumlardan biri. Yoksa siyah arka plan üstüne siyah yazı blokları oluşur. Tarayıcınız dark mode’daysa muhtemelen düzgün görünüyordur
      Geçici çözüm olarak tarayıcı hata ayıklayıcısında bir kod öğesi açıp :not(pre) > code stiline color: white ekleyebilirsiniz
    • Yorumu okur okumaz hatayı düzelttim
    • MacOS Chrome mu? Linux’ta Firefox, Chromium ve Brave’de kod blokları düzgün görünüyor. Sanırım hepsi Qt kullanıyor
    • Hem Firefox hem Chrome’da aynı durum ortaya çıkıyor
    • İlk başta yazının sansürlendiğini sandım

  • Lisp’in avantajlarını öven çok yazı var. Lisp’i, fikirlerini ve dil ekosistemindeki yerini sakin bir dille eleştiren yazılar da görmek isterim
    Bu tür yazılar ya da burada atıf yapılan PG yazıları sonuçta “bilen bilir”e yakın duruyor. Cazibesini de anlıyorum, bu yazının açık ve örtük olarak öne sürdüğü iddiaları da anlıyorum
    Bilgisayar programlama son 60 yılda epey olgunlaştı. Daha derinlikli değerlendirmeler içeren daha fazla yazı görmek isterim

    • Dil olarak Lisp harika, ama ekosistemi sınırlı. İki kusuru var. Biri, fazla açık uçlu olması; yetenek ve disiplin yoksa eğlenceli Lisp hack’lerinin tavşan deliğine düşüp gerçek işi bitiremeden kalabiliyorsun. Bu sorun başka dillerde de var ama Lisp’te daha kötü olduğunu düşünüyorum
      İkinci kusur, yeterince yetkin insanların yıllarını alabilmesi ama ortaya çıkan sonucun bu zaman yatırımını haklı çıkarmamasıdır. Python gibi şeyler de yeterli oluyor. Lisp’e harcadığım zamanın büyük kısmını başka yerde kullanmış olmayı dilerdim
    • “Programlama epey olgunlaştı” ifadesi, sanki Lisp geçmişte bir yerde takılıp kalmış gibi geliyor
      Clojure, Clojurescript, Clojure-Dart, Fennel, Jade, Jank, Jolt, Coalton nispeten yeni diller ve hâlâ gelişiyorlar. Aklıma ilk gelenler bunlar, çok daha fazlası var
      Lisp bir bakıma programlama dili değil, bir fikir. Bugün kullandığımız neredeyse tüm programlama dillerini etkiledi ve etkilemeye devam ediyor. Bir fikri “sakin bir şekilde” eleştirmek zordur; grup teorisini eleştirmeye benzer. Yine de o fikrin belirli uygulamalarının artılarını ve eksilerini tartışabiliriz
    • Lisp’in laneti: https://www.winestockwebdesign.com/Essays/Lisp_Curse.html
    • Günümüz dillerinde standartlaştırılmış eşzamanlılık artık temel bir gereklilik. CL’de standartlaştırılmış async/await ya da bir eşzamanlılık modeli yok. Standart 1995’ten beri güncellenmedi, dolayısıyla bundan sonra da olması pek olası değil
    • Lisp’te bir tür tutma yeri yönü gibi bir şey var sanırım
      Bazı insanlara zihinsel olarak çekici geliyor. Bunu gerçekten niş bir müzik türüne benzetmek isterim. Seveni az ama sevenler çok yoğun seviyor. Programlama dünyasının Stockhausen’i gibi
      Temelde bir fandom. Şaşırtıcı derecede kalıcı bir fandom ama hiçbir zaman geniş kitlelere yayılmadı, bundan sonra da pek olası görünmüyor. Hatta şimdi konumu daha kötü. LLM’lerle donanmış olup kodun kendisine çok da ilgi duymuyorsan, neden özellikle Lisp ile yazdırmak isteyesin ki?

  • Lisp’i o kadar uzun süredir kullanıyorum ki sunduğu özelliklere gerektiği gibi minnet duymamaya başlıyorsun. Sonra popüler ve ekonomik olarak daha az riskli dillerde insanların kendilerini nasıl sabote ettiğini dehşetle görünce, bir anda yeniden Lisp’in değerini hissediyorsun

  • Ticari sahada alan özel dilleri bir anti-pattern’dir. Biri gidip dokümantasyonu zayıf, yalnızca kendisinin anladığı bir alan özel dili yapar ve ortadan kaybolur
    Sonraki programcılar bu garip dili çözmeye uğraşmak zorunda kalır. Neredeyse her zaman standart dil yapıları ve özelliklerini kullanmak daha iyidir. Kod, yazıldığından daha çok okunur

    • Her fonksiyon yazdığında aslında o alan için özelleşmiş kendi dilini de yaratmış oluyorsun
      Gerçekte itiraz edilen şey muhtemelen referans şeffaflığının eksikliğidir. Adil olmak gerekirse bu, Lisp dâhil birçok dilde sorun
    • Lisp’te sonraki programcılar gidip sadece macro expansion sonucuna bakabilir
      Modern araçlarla bunu isterlerse editörün içinde, aynı kaynak dosyada alternatif metin olarak, canlı bir Lisp ortamına bağlıyken de görebilirler
      Bunun iyi bir örneği Common Lisp’in LOOP makrosudur. Birinin kullanımını anlamak zorsa, Lisp’ten bunu daha ayrıntılı, LOOP olmayan temel çağrılara genişletmesini isteyebilirsin; LOOP’u hiç anlamana gerek kalmaz. Hatta gerçekten LOOP formunu genişletilmiş kodla değiştirebilirsin
      Bu, çoğu başka dilde alan özel dil kodunun aslında yorumlanan veri yapıları olması durumundan ayrılan temel bir farktır

  • Lisplerde gerçekten güçlü ve benzersiz şeyler var ama bu yazıların REPL ve hot reloading konularını sürekli öne çıkarmamasını isterdim
    REPL, yorumlanan dillerde, hatta bazı derlenen dillerde bile çok uzun zamandır temel bir özellikti. Hot reloading ne benzersiz ne de özellikle yaygın. Durum ve yamalarla uğraşmak gerektiği için, akıl yürütmeyi kolaylaştırmak adına her şeyi baştan başlatmanın en iyi uygulama sayılmasının bir nedeni var

    • Clojure öğrenirken ben de böyle düşünüyordum. Ancak çok daha sonra, Lispçilerin dediği REPL’in genelde komutları kolayca değerlendiren etkileşimli bir CLI’den ziyade, programı canlı bir oturuma bağlayıp çalışan uygulamanın bağlamında metin editöründeki formları hızla değerlendirebilme yeteneği anlamına geldiğini fark ettim
      Bu yüzden diğer yorumlanan dillere göre çok daha etkileşimli geliştirme mümkün oluyor
    • Dart/Flutter’da hot reload çok yaygın kullanılıyor. UI kodunu reaktif tarzda bir framework ile yazdığında ve UI render süreci “her karede yeni UI’ı sıfırdan oluşturuyormuş” gibi göründüğünde, neyin yeniden yüklendiğine neyin yüklenmediğine dair sezgi geliştirmek daha kolay oluyor
      Elbette kusursuz değil. Ama kullanıcı deneyimini yinelemeli olarak iyileştirirken yapılan değişiklik türlerinde çok iyi çalışıyor
    • Genel olarak katılıyorum
      Yine de hot reloading’in ileri seviye taraflarının önemli bir kısmının Common Lisp’te zaten ele alınmış olduğunu vurgulamak gerekir. REPL’in de esas olarak doğrudan bir şeyler yazılan yerden çok, çalışan imaj ile araçların etkileşime girdiği çok güçlü bir arayüz olarak kullanıldığını söylemek de aynı şekilde önemli
      Yine de bunların var olmasının, günümüzde onları pek de özel kılmadığı konusunda hemfikirim
    • Her Lisp lehçesinde iyi gelişmiş bir hot patch sistemi yoktur. Nesne yönelimli sistemlerin bunun için dikkatle tasarlanması gerekir
      Sınıf tanımı yeniden yüklemeyle değiştirildi ama eldeki mevcut instance’lar kaldıysa ne yapacaksın? Common Lisp lehçelerinin bu sorulara faydalı cevapları var ama karşılaştığın her Lisp için bu geçerli değil
      Bash de hot reloading destekler. Şu şekilde source ederek yerinde güncellenen modüller geliştirdiğim oldu
      $ . /path/to/script.sh
    • Genel olarak hot patch işlemenin acısı, büyük ölçüde kod tabanının yapısına ve neden hot patch yapmak istediğine bağlıdır. Dizi yapılı bir mimari ya da çalışma zamanı mantık hatası düzeltmesi söz konusuysa çok da büyük mesele değildir
      Kullanışlılığı sınırlıdır ama buna sık başvuracağın varsayımıyla başlarsan, bu sınırlamalar oldukça hızlı biçimde önemini yitirmeye başlar

  • Ben kişisel olarak bu aşamaları geçtim. Common Lisp, Forth ve Haskell kullandım; On Lisp ile Let Over Lambda'yı da keyifle okudum.
    Şu anda en iyi programlama dilinin Barry Jay'in Triage Calculus'u olduğunu düşünüyorum. Kombinatör mantığına ya da tiplenmemiş lambda hesabına yakın.
    Ama lambda hesabından farklı olarak, Triage Calculus'ta Lisp'in CAR ve CDR'sine benzeyen yerleşik alıntılama ve içgözlem var; bu yüzden tip denetimini eklemek kolay. Bu nedenle TC'de doğru soyutlamaları kurduğunuz sürece istediğiniz her tür sözdizimine sahip olabilirsiniz. Gerçek anlamda nihai programlama dili.
    TC, bir yanda programlama dili özellikleri ve sözdizimi, diğer yanda standart kütüphane ya da kullanıcı kodundaki fonksiyon/API tanımları arasındaki ayrımın sahte bir ikilik olduğunu gösteriyor. Yeniden kullanım amacıyla kod yazdığınız her seferinde dile bir şey ekliyorsunuz. Bunların hepsi TC'nin bir terimi olarak ifade edilebilir.
    Bütün sözdizimi tartışmaları alışkanlık meselesi. Yine de TC'de gerçekten istediğim bir sözdizimi özelliği let over lambda soyutlaması; çünkü kombinatörleri elle düzenlemek biraz can sıkıcı.

  • İyi yazılmış bir yazı.
    Eskiden bir gün herkesin Lisp kullanacağını, harika araçlar ve kütüphaneler ortaya çıktığında her şeyin mükemmel olacağını düşünürdüm. Hatta emeklilik planım bile bu süreci hızlandırmak için Lisp dilleri adına yüksek kaliteli kütüphaneler üretmekti.
    Yapay zekanın yükselişi bu hayali bitiriyor mu? Yine sorunu daha fazla ıvır zıvır ekleyerek mi çözmüş olduk? Süper zekâya sahip yapay zeka, mümkün olan en iyi programlama dilinde kod yazmak yerine, çalışana kadar etrafa tonla Python kodu mu saçacak?
    Bunun önemli olup olmadığını bilmiyorum. Ben sadece zarafetin olduğu bir dünya istiyordum.

    • İlk “Interface Builder”ın neye benzeyeceğini hep merak etmişimdir.
      “Jean-Marie Hullot, INRIA'da çalışırken Macintosh için Lisp ile yazılmış ‘SOS Interface’ adlı aracı geliştirdi; bu, ilk modern ‘interface builder’ idi”
      https://denninginstitute.com/itcore/userinterface/GUIHistory...
      Bunun NeXT'e geçip Objective-C ile kullanılmak yerine ana akım bir Mac ürünü haline gelmesi durumunda ne olurdu diye düşünüyorum.
      LISP bana çok uygundu. Üniversitedeki karşılaştırmalı diller dersinde LISP ödevlerinin hepsini tamamlayan tek kişi bendim ve LISP öğrenmek TeX kullanırken de bana çok yardımcı oldu.
      İstediğim şey, açık kaynaklı, düzgün bir native ya da cross-platform GUI toolkit ve projeleri bağımsız çalıştırılabilir derlenmiş kod olarak kolayca dağıtmanın bir yolu.
    • Dil asla cevap değildir. Lisp, Visual Basic'ten üstün değildir. İkisi de Turing-complete.
      İnsanlar her ikisiyle de iyi fikirleri ifade edebilir. Dili bir araç olarak düşünmek daha iyi. Bir darbeli matkap, basit döner matkap karşısında mutlak olarak üstün değildir. Bir deck inşa ederken darbeli matkap daha uygun olabilir ama ikisi de işi yapabilir.

  • Bunun https://web.archive.org/web/20120106121645/http://wiki.alu.o... olacağını sanmıştım.
    comp.lang.lisp'i takip ettiğim günleri hatırlattı. Bir bakıma drama gibiydi. Sadece programlama büyüsü değil, güçlü karakterler ve olaylar da vardı.