Dil tasarlamayı bırakın, onun yerine kütüphane yazın

• Programlama verimliliğinin özü, dilin kendisinden çok zengin bir kütüphane ekosisteminde yatar
• Ruby on Rails gibi dilin ileri seviye özelliklerinden yararlanan çerçeveler, uzman olmayanlara bile yüksek verimlilik sunar
• Ancak dilin yapısal sınırlamaları nedeniyle, Rails düzeyinde bir çerçeveyi Java veya C ile gerçekleştirmek zordur
• Dil tasarımı, yazılabilecek kütüphanelerin biçimini ve karmaşıklığını doğrudan belirler; dil gelişiminin özündeki amaç da budur
• Stanza dili bu bakış açısından, güçlü ve kullanımı kolay kütüphaneler üretmeyi mümkün kılan dil tasarımının önemini gösterir

---

Programlama dili ile kütüphaneler arasındaki ilişki

• Çoğu programlama dili; değişkenler, diziler, döngüler, fonksiyonlar gibi benzer temel bileşenlere sahiptir
  • Bazı diller birinci sınıf fonksiyonlar veya coroutine gibi ileri özellikler sunar, ancak uzman olmayanlar bunları pek kullanmaz
• Birçok geliştirici için verimliliği artıran etken dilden çok kütüphanelerdir
  • Örneğin Ruby on Rails, veritabanı tabanlı web uygulamalarını kolayca kurmayı sağlar
  • Rails sayesinde Ruby dilinin kendisinden çok çerçevenin kendisi tercih edilir

Ruby on Rails ile dil özelliklerinin etkileşimi

• Rails; Ruby'nin metaprogramlama, çalışma zamanında değerlendirme, birinci sınıf fonksiyonlar, garbage collection gibi çeşitli özelliklerinden yararlanır
  • Örnek: ActiveRecords metaprogramlamayı, şablon sistemi ise çalışma zamanında değerlendirmeyi kullanır
  • Olay işleme, birinci sınıf fonksiyonların callback olarak aktarılmasıyla gerçekleştirilir
• Java veya C'de bu özellikler eksik olduğundan Rails düzeyinde bir çerçeve gerçekleştirmek mümkün değildir
  • Java'nın metaprogramlama yetenekleri, ActiveRecords'u uygulayacak kadar güçlü değildir
• Dolayısıyla Rails, Ruby dilinin yapısı sayesinde mümkündür ve dil tasarımı kütüphane olanaklarını belirler

Dil tasarımı kütüphanelerin biçimini belirler

• C dili yalnızca fonksiyon bildirimi ve çağrısı üzerinden yeniden kullanımı desteklediği için, C kütüphanelerinin çoğu bir fonksiyonlar kümesi biçimindedir
• Ruby, birinci sınıf fonksiyonları desteklediğinden “butona tıklandığında çalışacak davranışı” kısa ve anlaşılır biçimde ifade edebilir
  • Buna karşılık Java'da handler sınıfı tanımlamak gerektiği için kod daha karmaşık hale gelir
• Bir dilin ifade gücü, kütüphanenin yapısını ve kullanılabilirliğini doğrudan belirler

Etkileşimli yazılım ve genişletilebilir çerçevelerin ortaya çıkışı

• 1970'lerin toplu işleme odaklı bilişiminde, fonksiyon merkezli kütüphaneler yeterliydi
• Günümüzün etkileşimli yazılımlarında ise genişletilebilir kütüphaneler gerekir
  • GUI veya olay tabanlı sistemlerde, “kullanıcı tıkladığında benim kodumu çalıştır” yapısına ihtiyaç vardır
• Java ve C++, kalıtım ve method overriding ile genişletmeyi destekler; bu yapı zamanla çerçevelere dönüşmüştür

Stanza tasarımının arka planı ve dil sınırları

• Stanza'nın tasarım motivasyonu, Java'da kullanımı kolay bir oyun programlama kütüphanesi yazmanın zorluğundan doğdu
  • Java'da eşzamanlılık bir durum makinesi (state machine) olarak ifade edilmek zorundaydı
  • Scheme, continuation desteği sayesinde daha sezgisel bir uygulamayı mümkün kılıyordu
• Ancak Scheme statik tip denetimini desteklemediği için hata ayıklama verimliliği düşüktür
  • Günümüzde çoğu dil, tip sisteminin kütüphane olarak genişletilmesine izin vermez
• Stanza; isteğe bağlı tip sistemi, garbage collection ve çoklu yöntem tabanlı nesne sistemi sunar
  • Ancak kullanıcı tanımlı yeni bir nesne sistemi yazmaya izin vermez

Dilin amacı ve araştırma yönü

• Genel amaçlı programlama dillerinin amacı, güçlü ve kullanımı kolay kütüphanelerin üretilmesini desteklemektir
  • Dil ne kadar güçlüyse, kütüphane kullanımı da o kadar özlü hale gelir
• Kod, iyi tasarlanmış bir kütüphaneyi kullandığında bir iş arkadaşına talimat veren cümleler gibi okunan doğal bir akışa sahip olur
• Racket, Shen ve meta-nesne protokolü araştırmaları, genişletilebilir tip ve nesne sistemlerini inceliyor
• Sonuçta diller, “hangi kütüphanelerin kullanılabildiği ve hangilerinin kullanılamadığı” ile ayrışır
• Zarif kütüphanelerin arkasında onlarca yıllık dil araştırması ve tasarım emeği bulunur

[GN⁺]

Hacker News yorumları

• En iyi örnek Prolog. Genelde mantık programlamasının temsilci dili diye anılır ama aslında fiilen çeşitli algoritmaların bir derlemesinden ibaret ve her dilde bir kütüphane olarak uygulanabilir. Bence Prolog’un sözdizimsel ifadesini her dilin kendi sözdizimine uyarlayarak sunmak yeterli olur

  • Prolog’un özü algoritmalar değil, mantıksal kuralları bildirimsel olarak ifade etme biçimi. Örneğin “büyükanne/büyükbaba, ebeveynin ebeveynidir” kuralını tanımlarsanız, bununla büyükanne/büyükbabayı bulabilir ya da tersine ebeveyn ilişkisini çıkarabilirsiniz. Bu tür iki yönlü çıkarım Prolog’un cazibesi. Elbette bunu genel amaçlı dillerde taklit etmek için yan etkisiz kod ve sınırlı bir DSL gerekir. CUDA’yı Python’dan çalıştıran PyTorch veya TensorFlow gibi diller arası çağrılar da mümkün olduğundan, dile bağımlı olmayan bir yapı da gayet mümkün görünüyor
  • Prolog’un sözdizimi, birinci dereceden mantığın (First Order Logic) bir alt kümesi; değişkenlere doğrudan değer atanmaz, olası değerler kümesi üzerinde koşullar sağlanana kadar arama yapılır. Prolog motoru basit bir kütüphane çağrısından fazlasını yapar — örneğin arama uzayının sıkıştırılmış temsili, paralel yürütme, otomatik budama gibi şeyler vardır. Bu yüzden Prolog genelde bir arka uç servis olarak kullanılır ya da kod üretimiyle entegre edilir. Prolog; planlama, kısıt çözümü, teorem ispatı, birleşimsel test, fiyat modelleme gibi alanlarda özellikle güçlüdür. Bu yüzden Prolog’u basitçe “kütüphane olarak yeterli bir dil” diye görmek bana biraz zorlama geliyor
  • Aynı mantıkla, nesne yönelimli özellikler de closure’larla taklit edilebildiği için dilde gerçekten gerekli olmadığını söyleyebiliriz. Ama açık bir sözdiziminin sağladığı ifade gücünün avantajları var
  • Prolog benzeri ilişkisel programlamayı bir kütüphane olarak uygulamak için dilin sembol ve değişken manipülasyonunu birinci sınıf vatandaş olarak desteklemesi gerekir. Lisp ailesi diller bunu bir nebze yapabiliyor ama genel amaçlı dillerde kullanılabilirlik ciddi biçimde düşüyor. Bob Harper’la konuştuğumda “git yeni bir dil yap” demişti; bu söz oldukça ikna ediciydi
  • Prolog öğrenmek istiyorum ama başlangıç öğreticileriyle ileri seviye örnekler arasında orta düzey materyal bulmak zor. Sudoku varyantı bulmacaları Prolog’la çözmeye çalışıyorum fakat mevcut örnekler fazla optimize olduğundan genelleştirilmiş ilişki tanımlarını öğrenmek zorlaşıyor. Özellikle bazı kuralların yanlış olabileceği durumları nasıl modelleyeceğimi merak ediyorum. Referans olarak SWI-Prolog’un Sudoku örneğine bakıyorum

• 10 yıl önce bir Scala hayranıydım. Tip sistemi içinde DSL oluşturabilen “Scalable Language” fikri çekiciydi. Ama topluluk JVM üzerinde Haskell gibi kullanmaya başlayınca ilgimi kaybettim. Bugünlerde WASM ve Graal gibi teknolojilerin dil seçiminde daha fazla esneklik sağlayacağını umuyorum. Çoğu durumda JS yetiyor ama gerektiğinde Rust gibi düşük seviyeli bir dil kullanabilmek güzel bir seçenek

  • Bana göre Scala’nın en büyük sorunu DSL’in aşırı kullanımı. Sadece dilin kendisini değil, test framework’ü gibi şeylerde de sanki başka bir dili daha öğrenmek gerekiyor. Elbette Hadoop MapReduce’u tek satırda ifade edebilmek etkileyici ama çoğu iş için fazla. Üstelik Scala geliştiricileri “sıkıcı kod” yazmak istemiyor. Şık görünmeye çalışırken geride bakım cehennemi bırakıp gittiklerini çok gördüm
  • Tüm Scala topluluğu Haskell yönelimli değil. Bu eğilimi daha çok bazı tip sihirbazları gösteriyor. Scala’yı sadece “daha iyi bir Java” olarak kullansanız bile harika. Fonksiyonel programlamanın faydalarından büyük bir yük olmadan yararlanabiliyorsunuz
  • Haskell zaten sık sık DSL üretimi için bir dil olarak kullanılıyor. Meta’nın Haxl’i ya da müzik için bir DSL olan TidalCycles iyi örnekler. Yine de yüksek dereceli tiplere dayalı kütüphaneler ciddi performans kaybına yol açıyor ve gereksiz yere karmaşık oluyor
  • Hiç Clojure(Script) kullandınız mı? Bir Lisp dili olarak probleme göre dili genişletmeye dayanan bottom-up programlama yapmaya elverişli. Paul Graham’ın On Lisp kitabında da bu yaklaşım vurgulanıyor. İlgili olarak Bottom Up vs Top Down Design in Clojure konuşmasını da tavsiye ederim
  • Ben yakın zamanda Scala öğrenmeye başladım ve fonksiyonel programlama açısından da gerçekten çok hoşuma gidiyor. DSL üretmenin ötesinde de farklı şekillerde kullanılabilecek kadar genel amaçlı olduğunu düşünüyorum. Scala’da eksik bulduğunuz bir şey var mı merak ediyorum

• Tipli bir betik dili ile bash’i değiştirebilsek harika olurdu. Elixir’le basit bir JSON ayrıştırıcı betiği yazdım ve oldukça iyiydi

  • Hiç Nushell denediniz mi? Eskiden “gerçek bir dil” gerektiren işleri tek satırda halledebiliyorsunuz. Mesela dosya listesini sıralayıp JSON olarak çıktı veren bir pipeline’ı kolayca yazabiliyorsunuz
  • Aslında shebang kullanarak birçok dilde betik yazabilirsiniz. Örneğin C#, Java, Go ile mümkün. Scriptisto kullanırsanız neredeyse her dilde shebang betikleri oluşturabilirsiniz
  • OCaml da betik dili gibi kullanılabilir. #!/usr/bin/env ocaml ile doğrudan çalıştırılabilir. Yalnız tek dosya içinde dış bağımlılıkları otomatik kurma özelliği yok
  • Go’da da shebang’i taklit eden bir hile var. İlgili tartışma için buraya bakabilirsiniz
  • Günlük betik işleri için Python veya PowerShell de iyi seçenekler

• Dil ve kütüphane birbirini dışlayan şeyler değil. Bazı kütüphaneler fiilen dil gibi çalışır, bazı diller de belirli kütüphaneler için tasarlanır. Örneğin Julia, performans ve kullanılabilirlik arasında iyi denge kuran bir örnek. Yüksek performanslı kodu doğrudan Julia’da yazabilir, JIT düzeyinde tipe özelleşmiş derleme ile optimize yürütme elde edebilirsiniz. Model basit bir fonksiyon çağrısı gibi görünür ama içeride çok incelikli işler döner

  • Evet, sonuçta asıl nokta hem dilin hem de kütüphanenin gerekli olmasıydı

• Raku, birden çok alt dili (slang) birbirine bağlayan bir yapı olarak tasarlanmış. Örneğin regex, PEG, quoting gibi şeyler ayrı mini diller olarak ele alınıyor ve Slangify ile kendi DSL’inizi kolayca ekleyebiliyorsunuz

  • Ama kişisel olarak tipin değişken adından sonra geldiği sözdizimi hoşuma gitmediği için Raku’yu sevmiyorum

• Bir zamanlar kıdemli bir geliştiricinin “özgeçmişte Rails görürsem direkt çöpe atarım” dediğini duymuştum. İnsanları kullandıkları dille değerlendirmek ne kadar saçma, bunu yeniden fark ettim

  • Rails’in yükselişi ve J2EE’nin gerileyişi aynı anda olduysa bu tesadüf değil. Rails, sade ve güçlü görüşlere sahip arka uç kodunun nasıl görünebileceğini gösterdi; bunun etkisiyle DropWizard, Javalin, Spring Boot gibi Java framework’leri ortaya çıktı
  • O kıdemlinin teknoloji yığını neydi acaba?
  • Böyle bir çalışma arkadaşının çöp kutusunu ben toplamak isterim. İyi Rails geliştiricisi bulmak zordur. Benim de RoR deneyimim var ve hâlâ seviyorum
  • Tabii Java geliştiricisi arıyorsanız, Rails özgeçmişlerini elemek verimli olabilir
  • Sonuçta insanları değerlendirmenin ölçütü kurum kültürüne uyum ve işbirliği tarzına göre değişir. Kusursuz bir filtreleme yöntemi yok

• Dil ya da kütüphane sonuçta hem makineyle hem insanlarla iletişim kurma aracı. Makineyle bitler ve voltajlar üzerinden, insanlarla ise niyet ve kavramlar üzerinden iletişim kuruyoruz. Bu yüzden bir dil ya da kütüphane insanlara açık ve hızlı bir ifade aracı sunuyorsa, onun dil mi yoksa kütüphane mi olduğu çok önemli değil. Rails de olsa Stanza da olsa, amaca uyuyorsa ve ekip kolayca anlayabiliyorsa doğru seçim odur

• Ben “kütüphane nihai dildir” diye düşünüyorum. Örneğin Ruby on Rails, Ruby tabanlı harika bir web servis dili. Ruby ve Rails birbirleri için evrildi. Sonuçta programlama, diller arasında süregelen bir çeviri süreci gibi

  • C# ve ASP.NET Core da benzer şekilde birlikte gelişti. Kullanıcı dostu sözdizimi ile sistem düzeyinde optimizasyonlar aynı anda ilerledi

• “Dil ne kadar güçlüyse kütüphane kullanımı o kadar kolay olur” sözü doğru. Eski Java ile Express benzeri bir framework yapmak zordu

  • Express’in ne olduğunu bilmiyorum ama Java’nın kütüphane kullanışlılığı sayesinde kurumsal bir dil haline geldiğini düşünüyorum
  • C#’ın ASP.NET Core minimal API yaklaşımı, Express’i neredeyse birebir uygulayan bir örnek. Bunun mümkün olması için dil ve framework’ün birlikte gelişmesi gerekiyor
  • Java’da da Javalin gibi Express benzeri framework’ler var. Sorun, topluluğun sadelik istememesi

• C dili için web framework derseniz, PHP var sonuçta, değil mi? ;)

  • Bu biraz kütüphane kavramını fazla esneten bir şaka gibi