En Sevdiğim Programlama Sözdizimi: "Pipelining"

• Pipelining, programlama dillerinde kodun okunabilirliğini ve bakım kolaylığını artıran önemli bir özelliktir
• Veri akışını soldan sağa, yukarıdan aşağıya doğal biçimde ifade etmeyi sağlayan bir yaklaşımdır
• Rust gibi dillerde pipelining, kod akışını netleştirir ve IDE otomatik tamamlama özellikleri sayesinde geliştirici verimliliğini artırır
• Haskell, Elm, SQL gibi çeşitli dillerde uygulanır; builder pattern ve method chaining de bir tür pipelining olarak görülebilir
• Okunabilirlik, düzenleme kolaylığı, IDE desteği, sürüm kontrol araçları (diff, blame) üzerinde olumlu etkileri vardır
• Fonksiyon iç içe geçirme yaklaşımına göre daha kısa ve daha net kod yazmayı sağladığı için iş birliği ve bakım açısından da avantajlıdır

---

En Sevdiğim Programlama Sözdizimi: Pipelining

Pipelining nedir?

• Önceki değeri aktararak parametre listesindeki bir argümanı atlamaya imkân veren bir özelliktir
• Kodun okunabilirliğini artırır ve yorum eklemeyi kolaylaştırır
• Veri merkezli olarak ardışık işleme adımlarını sırayla uygulayan bir sözdizimi stilidir
• Fonksiyonel tarzdaki kodlarda .map().filter().collect() gibi method chaining biçiminde sık kullanılır
• Rust'ta aşağıdaki kod bunun tipik bir örneğidir:

  data.iter()  
      .filter(|w| w.alive)  
      .map(|w| w.id)  
      .collect()  
  

• Buna karşılık tüm fonksiyonları iç içe yazarsanız, aşağıdaki gibi içten dışa doğru okunması gereken bir yapı ortaya çıkar:

  collect(map(filter(iter(data), |w| w.alive), |w| w.id))  
  

Pipelining neden iyidir?

• 1. Okunabilirlik ve bakım kolaylığı

  • Yukarıdan aşağıya okunması kolaydır → insanların okuma sırasıyla aynı veri akışı
  • Her satıra kolayca yorum eklenebilir
  • Uzun satırlarda parantez iç içeliği olmadan kısa ve açık bir yapı sunar

• 2. Düzenleme kolaylığı

  • Araya .map() gibi yeni bir fonksiyon tek satırda kolayca eklenebilir
  • git diff ve git blame içinde değişiklikleri takip etmek de daha temiz görünür

• 3. IDE / LSP desteği

  • . tuşuna basıldığında çıkan otomatik tamamlama listesiyle çok uyumludur
  • Türlerin açıkça bilinmesini gerektiren statik analiz için avantaj sağlar
  • Bunun düzgün çalışabilmesi için dilin statik tipleme tabanlı olması gerekir (ör. Rust, TypeScript)

SQL'de de pipelining var mı?

• SQL'in iç içe SELECT sorgularını pipeline tarzına dönüştürmeye yönelik bir öneri vardır
• Örnek:

  FROM customer  
  |> LEFT OUTER JOIN orders ON ...  
  |> AGGREGATE COUNT(...) GROUP BY ...  
  |> ORDER BY ...  
  

• Mevcut SQL'e göre daha net akış ve daha iyi okunabilirlik sağlar
• Dezavantajı: SELECT ifadesi yukarıdan ayrıldığında dönüş tipini anlamak zorlaşabilir → çözülebilir

Builder pattern ile ilişkisi

• Rust'taki Builder::new().option().option().build() gibi yapı tipik bir pipeline düzenidir
• İsteğe bağlı ayarları metodlarla kurarken kod takibi ve değişiklik yönetimi kolaylaşır

Haskell'de pipelining iyileştirmesi

• Haskell'deki $, &, |> gibi işleçler, fonksiyon bileşimi yerine pipeline kullanımını mümkün kılar
• Önce/sonra karşılaştırma örneği:

  -- 기존  
  checkPalindromes content = unlines $ map (show . isPalindrome) $ lines $ map toLower content  
  
  -- 개선  
  checkPalindromes content =  
    content  
      & map toLower  
      & lines  
      & map (show . isPalindrome)  
      & unlines  
  

Rust'ta pipelining'in avantajları

• Method chaining, type inference ve trait tabanlı yapısal genişletilebilirlik, pipelining ile çok iyi uyum sağlar
• Rust, fonksiyonel ve nesne yönelimli sözdiziminin güçlü yanlarını bir araya getirmiş gibi görünen bir yapıya sahip olduğundan, pipelining kullanımı burada son derece doğaldır

Sonuç

• Pipelining yalnızca basit bir sözdizimi değil, kod akışını, düzenlenebilirliği ve iş birliğini etkileyen temel bir özelliktir
• f(g(h(x))) gibi iç içe geçmiş yapı yerine x |> h |> g |> f yapısı daha insan dostudur
• Pipelining, "bir satırda bir işlem" gibi basit bir kural altında, doğal akışı ifade etmenin en iyi yollarından biridir

“Her pipe parçası ana veriyi alır ve tek bir iş yapar. Sonunda buna açık bir ad verirseniz, ortaya en ideal kod yapısı çıkar.”

[tested]

https://github.com/tc39/proposal-pipeline-operator

[progdesigner]

Sanırım bağlam olarak, herhangi bir metinde
satır sonu ve girintilemenin okunabilirlik açısından önemli olmasıyla
benzer bir durum.

[forgotdonkey456]

LINQ harika!

[bus710]

Gleam de bunu destekliyor, bu sayede kodu oldukça temiz yazabiliyorsunuz.

Bu arada, sanırım metinde kod bloğu olduğu için mobilde de masaüstü düzeninde görünüyor.

[bus710]

Düşününce, elm'de de oluyor.

[galadbran]

Az miktarda veri ve yukarıdaki örnekteki gibi basit seviyedeki kodlarda, görünüm olarak da fena olmadığını düşünüyorum.

Ama map() içine azar azar kod girmeye başladıkça ... kodu giderek şişirme eğilimi oluyor ve
dile ya da kullanılan kütüphane implementasyonuna göre etkisi değişse de, veri miktarı arttığında sadece veri yapısına veri biriktirip ya da onu manipüle ederek işlemeye kıyasla kolayca binlerce kat daha yavaşlayabildiği için,

Bir de sonradan bunu tercih etmememe yol açan yeni bir neden daha ortaya çıktı: Bu haberi telefonda gördüğümde PC seviyesindeki genişlik aynen korunmuştu ve yazı boyutu gözle zor seçilecek kadar küçülmüştü; bu yüzden haberi okumak çok zordu T.T

Temel olarak bunu tercih etmiyorum ve özellikle böyle yazmaya da çaba göstermiyorum.

[bichi]

Bana biraz da js verin lütfen |> yalvar yakar

[secret3056]

|> çok güzel

[howudoin]

En nefret ettiğim sözdizimi bu
Stack trace birazcık bile karışıksa debug etmek berbat

[cosine20]

Kesinlikle katılıyorum

[GN⁺]

Hacker News görüşleri

• Yazar buna "pipelining" diyor ama doğru terimin "method chaining" olduğunu düşünüyorum

  • Bash'teki basit pipeline ile karşılaştırma: her bileşen paralel çalışır ve ara sonuçlar stream edilir
  • Ruby'de ise her satır sıralı olarak işlenir ve her aşama arasında tam bir dizi oluşturulur
  • Debug etmek zorlaştığı için bugünlerde daha açık kod yazıyorum
  • Açık kod, görünüşte daha az temiz olsa da ara durumları incelemeyi kolaylaştırır

• Kişisel olarak bir dilin özellik setini küçük tutmayı ve hızla tamamlanmış bir özellik setine ulaşmayı destekliyorum

  • Ancak Elixir'in |> sözdizimini tüm dillerin benimsemesini isterdim

• Lisp makroları, yalnızca zincirlenmiş koleksiyon operatörleri için değil, çağrı zincirinin sırasını belirlemek için de genel bir çözüm sunar

  • Örneğin, (foo (bar (baz x))) ifadesi (-> x baz bar foo) olarak yazılabilir
  • Ek argümanlar olduğunda da bunu işleyebilir
  • Daha fazla ayrıntı için Clojure'un threading macro rehberine bakın

• Bu terimi fluent interface olarak öğrenmiştim. Pipelining başka bir şey

• Pipeline operatörü bir tür partial application'dır; birden çok argümanı bağlayarak yeni bir fonksiyon oluşturabilir ve onun çıktısını başka bir fonksiyona aktarabilirsiniz

  • Partial application program yazarken çok faydalıdır ve bir gün (Haskell dışı) diller bunu program bileşiminin temeli olarak kullanacaktır

• R'nin tidyverse kullanıcıları bunu zaten kullanıyor

• Pipelining debug etmeyi zorlaştırır. Exception handling zor olduğu için pipeline'a dallanma eklemek gerekir

  • Pipeline'lar yalnızca happy path programlarken faydalıdır

• SQL sözdizimi gereksiz yere karmaşık

  • SQL zaten bir operatör dili ama tarihsel nedenlerle pek çok kısıtı var
  • Yeni sözdizimine izin verilecekse daha basit yazılabilmeli
  • |> sözdizimi yeterince ifade gücü sunmuyor ve görsel gürültü ekliyor

• Yazar "anlam sözdizimini yener" diyor ama sözdizimi tercihine odaklanıyor

  • Pipelining, zincir uzadıkça debug etmeyi zorlaştırıyor
  • Python'a karşı eleştirel ama somut nedenler sunmuyor
  • "pipelining" tanımı net değil

• effect-ts hem pipeline hem de imperative kod yazmayı mümkün kılıyor

  • Pipeline yazımı ve generator kullanımı hakkında dokümantasyon sunuyor
  • Topluluğun büyük kısmı imperative tarzda generator'ları tercih etmeye başladı
  • Debug ve bakımın daha kolay olduğu görülüyor