Prodüksiyonda 8 Yıl Haskell’den Sonra 8 Ay OCaml Kullanma Deneyimi (2023)

 (chshersh.com)
1 puan yazan GN⁺ 2024-12-04 | Henüz yorum yok. | WhatsApp'ta paylaş
  • Bir geliştirici, prodüksiyonda 8 yıl Haskell ve 8 ay OCaml kullanma deneyimine dayanarak iki fonksiyonel dilin gerçek geliştirme hissini karşılaştırıyor
  • Haskell daha özlü bir söz dizimi ve güçlü tip özellikleri sunuyor; ancak seçeneklerin çokluğu tasarım ve soyutlamaya fazla zihinsel enerji harcatabiliyor
  • OCaml, özellik sayısı daha az olsa da first-class modules, pratik değiştirilebilirlik ve öngörülebilir kod stili sayesinde uygulamaya odaklanmayı kolaylaştırıyor şeklinde değerlendiriliyor
  • Ekosistem Haskell’de daha büyük; fakat kütüphane seçimi başlı başına ayrı bir beceri gibi hissedilebiliyor. OCaml ise küçük olsa da gerekli araçlar beklenenden iyi çalışıyor
  • Her iki dil de ana akım dillere göre küçük ve standart kütüphaneleri neredeyse minimal; ancak belirli bir SDK bağımlılığı çok kritik değilse endüstriyel uygulama geliştirmek için yeterince kullanılabilir

Karşılaştırmanın çıkış noktası

  • Ölçüt, prodüksiyonda 8 yıl Haskell, 8 ay OCaml kullanma deneyimi
  • Karşılaştırma eksenleri söz dizimi, dil özellikleri, ekosistem, araçlar, derleyici mesajları ve standart kütüphane
  • Her iki dil de gerçek endüstriyel gereksinimleri destekleyecek kadar gelişmiş durumda; ancak mevcut tercih OCaml tarafına daha yakın

Söz dizimi: Haskell daha özlü, OCaml de ML ailesinin avantajlarına sahip

  • Haskell, fikirleri çok az karakterle ifade edebildiği için söz dizimsel zarafeti güçlü biçimde hissettiriyor
  • OCaml de ML ailesi bir dil olarak çok iyi; ancak Haskell daha örtük (tacit) bir stil sunuyor
  • Bir string içindeki sayıların toplamı örneğinde Haskell bunu sum . map read . words ile kısa biçimde ifade ederken, OCaml pipeline ile string’i bölme, dönüştürme ve fold etme adımlarını açıkça gösteriyor
  • İkili ağaç tipi tanımı, iki dilde de cebirsel veri tiplerini doğal biçimde ifade ediyor
  • Ayrıştırma örneklerinde iki dil de pattern matching ve option değerleri kullanıyor; ancak Haskell do notasyonu ve guard, OCaml ise Option.bind ve açık match kullanıyor

Özellikler: Haskell zengin, OCaml daha az dikkat dağıtıyor

  • Haskell’de özellik sayısı o kadar fazla ki karşılaştırma noktası olarak C++ akla gelebiliyor
  • Birçok özellik, sorunları incelikli çözmek için araç sağlıyor; fakat gerçek uygulamaya geçmeden önce çözümü nasıl tasarlamak gerektiğini düşündürebiliyor
  • Haskell’de TypeFamilies, DataKinds, GADTs gibi seçenekler arasında tasarıma dalmak kolay
  • Mevcut OCaml projelerinde kötü durumlar genelde yetersiz değişken adları, eksik dokümantasyon ve 200 satırdan uzun fonksiyonlar düzeyinde kalıyor; bunlar yönetilebilir görülüyor
  • Buna karşılık mevcut Haskell projeleri, 8 yıllık deneyimle bile hazırlıklı olmanın zor olduğu karmaşıklıklarla karşılaştırabiliyor
  • Bu fark nedeniyle OCaml’de daha üretken hissediliyor

  • İki dilin paylaştığı özellikler

    • İfade merkezli söz dizimi, varsayılan immutability, higher-order fonksiyonlar, anonim fonksiyonlar, cebirsel veri tipleri ve pattern matching sunuyorlar
    • Parametrik polimorfizm, tip çıkarımı, monad söz dizimi şekeri, garbage collector, multithreading ve GADTs de ortak olarak kullanılabiliyor

  • Haskell tarafında daha belirgin özellikler

    • Haskell varsayılan saflık, birleştirilebilir lazy evaluation, type class’lar, higher-kinded type’lar ve isteğe bağlı dil uzantıları sunuyor
    • Çok sayıda güçlü özelliğe sahip olduğu için soyutlama biçimi projeden projeye büyük ölçüde değişebiliyor

  • OCaml tarafında daha belirgin özellikler

    • OCaml first-class modules, polymorphic variants, nesneler, sınıflar ve kalıtım ile kullanımı kolay değiştirilebilirlik sunuyor
    • Özellik yelpazesi Haskell’den daha dar; ancak bu durum kod tabanını daha öngörülebilir kılma avantajına dönüşüyor

Ekosistem: Haskell daha büyük, OCaml’de gerekli çözümler var

  • Her iki dil de niş fonksiyonel programlama dilleri olduğu için en yeni framework’lerde first-class destek beklemek zor
  • Yine de genel işlerin çoğu için çözümler var; bazı durumlarda daha fazla custom binding yazmak gerekebiliyor
  • OCaml’de de pratikte gerekli paketler aşağıdaki gibi bulunabiliyor
  • Haskell ekosisteminde daha fazla paket ve hazır kullanılabilir çözüm var
  • Stripe API istemci kütüphanesi Haskell’de 13 adet, OCaml’de 1 adet; OCaml tarafındaki son değişiklik 8 yıl önce olduğundan fiilen 0’a yakın görülüyor
  • Haskell’de çözümü bulduktan sonra bile çok fazla seçenek arasından hangi kütüphaneyi seçeceğine karar vermek gerekiyor
  • Kütüphane seçimi ayrı bir beceri gibi ele alındığından, kütüphane değerlendirme yöntemi üzerine yazılmış bir yazı da var
  • Yeni bir Haskell kütüphanesi çoğu zaman başka bir sorunu çözmekten ziyade farklı bir soyutlama ya da yeni bir özellikle başka türlü yazmak istemekten doğuyor
  • GitHub API istemcisi yapıp bolca JSON ayrıştırmaktansa, comonad’larla logger tasarlamak daha ilginç gelebiliyor

Araçlar: Haskell güçlü ama dalgalı, OCaml iyi çalışıyor

  • Haskell araçlarında güçlü avantajlar ile kullanılabilirlik sorunları bir arada bulunuyor
  • Hoogle, yalnızca tip imzasıyla tüm ekosistemde arama yapmayı sağlayan güçlü bir araç
  • Buna karşılık build aracı hata mesajları, çalışan bir projede build planı bulamama durumları, paket değişikliği sonrası IDE’nin yeniden derleme yapması, belirli sürüm standart kütüphane dokümantasyonunun bulunmaması gibi sorunlar var
  • Haskell araç deneyiminde, diğer dillerin bu tür araçlar olmadan nasıl kullanıldığına şaşırılan anlar ile Haskell kullanıcılarının temel kullanılabilirlik olmadan nasıl idare ettiğine şaşırılan anlar bir arada yaşanıyor
  • OCaml ekosistemi daha küçük olduğu için bir şeyin çalıştığını görmek her seferinde şaşırtıcı olabiliyor
  • LSP tabanlı VSCode OCaml eklentisi ek ayar gerektirmeden çalıştı ve sorun çıkarmadı
  • OCaml araçlarına giriş deneyimi en konforlu olmasa da sezgisel, sağlam ve çoğu durumda düzgün çalışıyor

  • Araç karşılaştırması

Derleyici mesajları: Haskell uzun, OCaml öz

  • Fonksiyonel dillerde derleyici, kodun amaçlanan varsayımları neden karşılamadığını anlamak için temel araçtır
  • Bu nedenle hata mesajları gerekli bilgiyi erişilebilir biçimde göstermeli
  • Haskell derleyici mesajları çok bağlam bilgisi içeriyor, uzun oluyor ve yinelenen ya da dikkat dağıtan bilgiler barındırma eğiliminde
  • OCaml derleyici mesajları oldukça kısa ve bazen fazla kısa
  • Örnek hatalı program, Haskell’de x = 1 + [3, 1, 2] ve OCaml’de let x = 1 + [3; 1; 2] gibi bir tamsayı ile listeyi toplamaya çalışan kod

Standart kütüphane: İkisi de minimal, dokümantasyon kalitesinde Haskell öne çıkıyor

  • Standart kütüphane, dilde yazılan ilk programı ve sonraki kullanım deneyimini şekillendirir
  • İyi bir standart kütüphane bir programlama dilinin başarısının temelidir; yetersiz bir standart kütüphane ise alternatif standart kütüphane tartışmalarını sürekli doğurabilir
  • İdeal standart kütüphanenin batteries-included yaklaşıma yakın olması gerektiği düşünülüyor
  • İstenen içerikte Option benzeri tipler, UTF-8 string’ler, Map ve HashMap, JSON ve XML ayrıştırıcıları, asenkron primitifler gibi şeyler yer alıyor
  • Build aracı ve bağımlılık izleme implementasyonu öğrenmek istemiyorsanız standart kütüphanede daha fazla işlev gerekir
  • Build Systems a la Carte, bağımlılık izleyicileri ve build araçları alanını analiz eden bir kaynak
  • Haskell ve OCaml’in standart kütüphaneleri görece minimal
    • Haskell’de Map ve HashMap bulunmuyor
    • OCaml’de non-empty lists ve Bitraversable yok
  • Haskell standart kütüphanesi base, OCaml ise OCaml standard library kullanıyor
  • Haskell dokümantasyon kalitesi bazen deneyimli geliştiricileri bile şaşırtacak kadar iyi olabiliyor
  • Haskell dokümantasyonunda kaynak koda gitme gibi avantajlar da var; OCaml’de de böyle bir özelliğin hazırlık aşamasında olduğu söylendiği aktarılıyor

  • Dokümantasyon örnekleri

    • Haskell List dokümantasyon örneği
    • OCaml List dokümantasyon örneği
    • Sonucu apaçık olan fonksiyonlarda bile örnek odaklı dokümantasyon, API’nin nasıl kullanılacağına dair anında fikir verir

Sonuç: İkisi de endüstriyel kullanım için uygun, ancak mevcut tercih OCaml

  • Her iki dil de gerçek endüstriyel gereksinimleri destekleyecek kadar gelişmiş durumda
  • Ana akım dillerle karşılaştırıldığında hâlâ küçük diller sayılırlar
  • Belirli bir SDK’nın varlığına kritik biçimde bağımlı değilseniz, bu iki dilden hangisini seçerseniz seçin bir sonraki uygulamanızı keyifle geliştirebilirsiniz
  • Şu anda OCaml ile gerçekten bir şeyler üretmeye odaklanmak daha kolay görülüyor

İlgili okumalar

Henüz yorum yok.

Henüz yorum yok.