Sıradışı programlama dili Hurl

 (hurl.wtf)
2 puan yazan GN⁺ 2024-05-27 | 1 yorum | WhatsApp'ta paylaş
  • Hurl, genel dallanma veya döngüler yerine yalnızca istisna işleme ile kontrol akışını kurgulayan deneysel bir programlama dili
  • Nicole Tietz-Sokolskaya ile Recurse Center’daki arkadaşlarının sohbetinden doğdu; site kullanım belgeleri ve örneklerin yanı sıra hata ayıklama kılavuzu ile soru-cevap bölümü de sunuyor
  • Tanıtım sayfasındaki alıntılar, “monstrosity is beautiful”, “Certified unhinged™” gibi ifadelerle bilinçli olarak şakacı bir havayı öne çıkarıyor
  • Hurl ve sitenin kaynak kodu açık, ancak e-posta ile yama göndermek için yama haklarını devretmek gerekiyor
  • Lisans, AGPL-3.0, GAL-1.0 veya ticari lisans seçeneklerinden biri olarak sunuluyor

Yalnızca istisna işlemenin kaldığı bir dil deneyi

  • Hurl tek bir amaç için oluşturuldu: istisna işleme tabanlı kontrol akışından oluşan bir dilin mümkün olup olmadığını araştırmak
  • Fikir, Nicole Tietz-Sokolskaya ile Recurse Center’daki arkadaşlarının sohbetinden çıktı; arkadaşlarının kimlikleri “nezaket gereği” açıklanmıyor
  • Site, Hurl kullanım belgeleri ve örneklerinin yanı sıra hata ayıklama kılavuzu ve soru-cevap bölümü sunuyor

Şaka gibi görünse de gerçekten açık bir proje

  • Tanıtım sayfasında Hurl’ün karakterini yansıtan alıntılar yer alıyor
    • “This monstrosity is beautiful, and I must never touch it”
    • “Certified unhinged™!”
    • “is "🤮" an available quote?”
  • Ek alıntılar yayımlatmak isterseniz Nicole’e e-posta göndermeniz ve alıntının dahil edilmesine açıkça onay vermeniz gerekiyor

Kaynak kodu ve lisans koşulları

  • Hurl dili ve bu sitenin kaynak kodu Hurl's repo üzerinde açık olarak yayımlanıyor
  • Bir hata veya yanlışlık bulursanız e-posta ile yama gönderebilirsiniz; ancak yamaya ilişkin tüm hakları devretmeniz gerekiyor
    • Bu, yeniden lisanslama ve ticari lisans olasılığını korumak için bir koşul
  • Proje aşağıdaki üç lisanstan biriyle kullanılabiliyor

    • AGPL-3.0

      • GAL-1.0: Gay Agenda License
      • ticari lisans
      • Lisans inceleme sürecinde joke licenses ve unfortunate licenses da değerlendirildi, ancak sonuçta yukarıdaki üç lisans kullanıldı

İlgili okumalar

1 yorum

 
GN⁺ 2024-05-27
Hacker News yorumları

  • Bir programlama dili tasarlıyor olsaydım include/import için namespace zorunlu kılar, mümkünse en üst düzey yan etkileri de engellerdim.
    let foo = include "lib/foo.hurl" gibi alıp foo.init() çağırmak çıkarım yapmayı çok daha kolaylaştırır.
    Buna karşılık include "lib/foo.hurl" // side effects ardından baz(buz) gelirse, fonksiyonların ve değişkenlerin standart kütüphaneden mi yoksa bir yerden include edilmiş mi olduğunu anlamak zorlaşır.

    • Açık ad bağlama yoksa import ifadesiyle namespace'in eşleşmesini zorunlu kılmak daha iyi olur.
      import "foo/bar", foo.* veya bar.* kullanılmasını sağlamalı; bazz.* ortaya çıkmamalı. Aklıma tam Go geliyor.
    • Katılmıyor değilim ama işte kullandığım IntelliJ, hangi referansın nereden import edildiğini açıkça gösteriyor ve kısayolla oraya gitmek de mümkün.
      VSCode da eklentiler ve LSP ile benzerini yapıyor ama çok daha kötü. Kodda gezinme o kadar yavaş ki VSCode ile çalışamam.
      Bu tür önerilerin yalnızca böyle araçlar yokken mi işe yaradığını merak ediyorum. En azından profesyonel ortamda böyle araçlar olmadan yaşamak imkânsız görünüyor.
    • Böyle yapınca foo.init()'e parametre geçebilirsiniz; çıplak import ile bu mümkün değil.
    • Akış kontrolü istisna merkezli olan bir dilde, “çıkarımı kolay” gemisi çoktan kalkmış gibi.
      Bu projenin değersiz olduğu anlamına gelmiyor; aksine onu bir sanat eseri olarak görüyorum.
    • %100 katılıyorum.
      Bir keresinde Ruby'yi fork edip require'ın sembol tablosunun üstüne yazmamasını sağlamaya çalışmıştım; ama Ruby ekosisteminin paylaşılan global değişken duruma aşırı bağımlı olduğunu düşünüp sonunda Ruby'nin kendisine ilgimi kaybettim.

  • İstisnalar, çağıran ile çağrılan arasındaki sözleşmeyi anlamayı zorlaştırıyor ve kodun bağlılığını da artırıyor; bu yüzden bana hep kötü geldi.
    Go veya Rust'taki gibi dönüş değeriyle ele alma biçimini tercih ederim. Dili kabaca incelediğimde bu sorunu çözen bir unsur var mı pek emin olamadım.
    IDE bir fonksiyonun yakalanmamış tüm istisnalarını dinamik olarak bulup istisnanın fırlatılabileceği yerlere atlamayı sağlarsa bu model de kabul edilebilir olabilir. Ama bağlılığın nasıl ele alınacağını bilmiyorum; kontrol akışı grafiği de aşırı kırılgan hâle gelecek gibi.

    • Java'da IntelliJ tam olarak bunu yapıyor. İstisna fırlatan bir fonksiyon varsa ve projenin bir yerindeki çağıran bunu yakalamıyorsa sorun olarak işaretliyor; implementasyona veya çağrı konumlarına kolayca gidilebiliyor.
      Ancak Java'da, RuntimeException'dan türemediği sürece bir fonksiyonun fırlatabileceği istisnalar fonksiyon imzasının parçasıdır. Böyle bir durumda imzaya eklemeden istisna fırlatırsanız derlenmez.
      Java'nın koşulları, IDE'nin yakalanmamış istisnaları raporlamasını çok daha kolaylaştırıyor; ama runtime istisnası değilse statik analizle çözülebilecek bir problem.
      Öte yandan standartlaştırılmış Ok/Err sarmal değerleri döndürme yaklaşımı, hem araç desteği hem geliştirici konforu açısından daha basit görünüyor.
    • İstisna fırlatmak ile istisnayı değişken olarak döndürmek arasında kelimenin tam anlamıyla hiçbir fark yok.
      Tek fark, istisna iletme yaklaşımında derleyicinin sizin yerinize yazacağı kalıp kodu elle yazmak zorunda kalmanız.
      2024'te düzgün çalışan bir kafaya sahip birinin bunu neden elle yapmak isteyeceğini gerçekten anlayamıyorum.
    • Go hata bağlamını doğal biçimde yutmasaydı onu daha çok severdim sanırım.
      Kullandığım süre boyunca, debugger olmadan kök nedeni bulmak çok daha acı vericiydi.

  • toss örneği “çoğunlukla fonksiyon dışına birden fazla değer aktarmak için kullanılır; şart değil ama sevimli” diye anlatılmış, oysa gereksiz olmak bir yana sürdürülebilir generator'ları gerçekleştirmiş oluyor.
    Elbette hemen sürdürmek dışında başka bir şey yaptırmak isterseniz oldukça ilginç olabilir. Tüm codebase'i toss'un iç-dış yığını olarak kurmanız yeterli.

    • Tam olarak aynı değil. Sürdürülebilir generator programın daha sonraki herhangi bir noktasında sürdürülebilir; burada ise return'ün işleyici tarafında leksik olarak scope'lanmış olması gerekir.
      Örneğin Python'da next()'i her yerden çağırabilirsiniz.
      Bu daha çok yan kanaldan callback geçirmek gibi. toss o callback'i çağırır; return de kelimenin tam anlamıyla oradan döner.
    • Okuduktan sonra aklıma gelen ilk şey de tam olarak buydu.
      Başka bir dilde gerçekten kullanışlı olacak bir özelliğin burada atılabilir sevimli bir özellik gibi ele alınması biraz şaka mı diye düşündürüyor.
    • Daha çok yığın tabanlı olay yayılımına benziyor.
    • C#'taki yield gibi bir şey mi?
    • Benim de ilk düşüncem aynıydı. Generator'ları olan küçük ve hoş bir dil; fena değil.

  • Hurl, Smalltalk veya Common Lisp tarzı condition system'a epey yakın görünüyor.
    Stack unwinding ve sürdürme, olası restart'lardan yalnızca ikisi: https://gigamonkeys.com/book/beyond-exception-handling-condi...

  • Projenin kendisinden bağımsız olarak, daha fazla şeyin alan adında .wtf uzantısını kullanması hâlinde dünyanın daha iyi bir yer olacağına kuvvetle inanıyorum.

  • Bu, cebirsel etkilerin zayıf bir biçimi gibi geliyor; yine de böyle bir dili ve onunla neler yapılabileceğini görmek harika.

    • Cebirsel etkileri hiç anlamış değilim ama Hurl dokümanlarını anlayabiliyorum.
      Cebirsel etkiler temelde Hurl'ün toss anahtar sözcüğü gibi bir şeyse, toss'tan hangi açıdan daha güçlü olduğunu merak ediyorum.

  • Eğlenceli bir düşünce deneyi.
    İstisnalardan gerçekten nefret ediyorum ve istisnasız bir dil istiyorum.
    İstisnalar çağımızın goto'su.
    Maybe/Option ve Effect/Result varken, istisna fırlatıp nerede ele alındığını zihinde takip etmek için pek sebep yok.
    Cebirsel etkilerin daha popülerleşip zaten fazlasıyla karmaşık olan frontend JS'i de etkilemesinden biraz endişeliyim. Çünkü akış kontrolü için “istisna” fırlatma yaklaşımını teşvik ediyor.
    Bütün bunların amacı asenkron/senkron renk problemini önlemekse, bana göre kesinlikle buna değmez.

  • Vay, bundan hoşlanmadım. Ama tuhaf biçimde neredeyse zarif bir yanı var.
    Zihinde modellemesi çok zor, ama yine de öyle.
    Biraz daha ciddi söylersem, sürdürülebilir istisnalar ile sürdürülemez istisnalar için sözdizimsel olarak farklı catch ifadeleri olmasını isterdim. O zaman return'ün kontrol akışını en yakın anlık istisnanın fırlatıldığı tarafa geri gönderip göndermediğine dair sözdizimsel belirsizlik ortadan kalkar.
    Ayrıca standart kütüphane sıradan değer döndüren fonksiyonlara kaçmamalı. Kendi pişirdiğini yiyince miden yanıyor diye yememek olmaz.

    • Doğru. Ama başka bir alternatif olarak, değer beklenen bir konumda fonksiyon çağrılınca sözdiziminin bunu otomatik olarak catch etmesi de sağlanabilir.

  • hurl edilen şeylerin yakalanabildiğini ama toss edilenlerin yakalanamadığını mı doğru anladım? Alışması biraz zaman alacak.
    Ayrıca ne kadar Hurl yazarsam insanların bana tosser demeye başlayacağından da endişeliyim.

  • Toss ilginç bir dil yapısı gibi geliyor. Yığın üzerinde yukarı çıkarak istisna işleyicisini buluyor, sonra yeniden asıl konuma dönüp hiçbir şey olmamış gibi yürütmeyi sürdürüyor.
    Bu yapıyla runtime'da ek davranış enjekte etmek mümkün görünüyor.
    Genellikle nesne yönelimli kodda bağımlılık enjeksiyonu servis constructor'ları üzerinden yapılır; toss bunu “toss işleyicisi” ile mi mümkün kılıyor?

    • Koka'ya bakın. Cebirsel etki sistemine sahip “gerçek” bir dil.
      https://koka-lang.github.io/koka/doc/book.html#why-handlers
    • Common Lisp'in condition system'ına oldukça benziyor.
      Çok fazla bilmiyorum ama runtime'da davranışı bu şekilde enjekte etmeye izin verdiğini biliyorum.
    • VB'nin Resume Next'ine benziyor.