Python, veri bilimi için uygun bir dil değil

• Veri analizi, görselleştirme ve özetleme gibi derin öğrenme dışı veri işlerinde Python işlev olarak yeterli olsa da kullanım deneyimi karmaşık ve verimsiz bir akışa kaymaya yatkın
• Laboratuvar örneklerinin genelinde, R’ye kıyasla Python’ın basit grafik dönüşümleri ve istatistiksel hesaplamalar için bile daha fazla kod ve zaman gerektirdiği eğilimi tekrar tekrar gözlemleniyor
• pandas, matplotlib, NumPy gibi araçlar kullanılsa bile söz dizimi, indeksleme, parantezler ve metod zinciri yapısı yüzünden, mantıktan çok uygulama ayrıntılarına (logistics) takılıp kalınan durumlar sık yaşanıyor
• Buna karşılık R’nin tidyverse ekosistemi, veri işleme akışını doğal dil düzeyinde ifade ederek iş mantığını doğrudan koda aktarmayı kolaylaştırıyor
• Python, veri bilimi dili olarak mantık ile lojistiği ayırma konusunda yapısal sınırlara sahip ve bu, dilin ve ekosistemin tasarımından kaynaklanan bir sorun

---

Python ve R’nin gerçek kullanım deneyiminin karşılaştırması

• Laboratuvardaki üyeler dili serbestçe seçiyor, ancak Python kullananların fazla olduğu ve bunların basit ek analiz isteklerini hızlıca yerine getiremediği kalıbı tutarlı biçimde ortaya çıkıyor
  • Kutu grafiği → violin plot, histogram → yoğunluk grafiği, çizgi grafiği → ısı haritası gibi görselleştirme dönüşümlerini bile anında yapmak zor olabiliyor
  • R’de birkaç satırda biten işler, Python’da “masaya dönüp yeniden kod yazmak gerekecek” kadar yük gibi hissediliyor
• Python uzmanlarıyla ortak dersler yürütülürken bile gereken kod uzunluğu ve karmaşıklığında R ile büyük fark ortaya çıkıyor
  • “Neden bu kadar karmaşık olmak zorunda?” tepkisi çeşitli durumlarda tekrar tekrar görülüyor; bunun kişisel beceriden değil dil ve kütüphane mimarisindeki yapısal farktan kaynaklandığı düşünülüyor
  • Aynı mantıkta bile Python’da indeksleme, veriyi ayırma, yeniden birleştirme ve birden çok metodu bağlama ihtiyacı yapıyı uzatıyor
  • R tidyverse, filter → group_by → summarize gibi doğal bir zincirle doğrudan ifade imkânı sunuyor

Python’ın yaygın kullanılma nedeni ve sınırları

• Python’ın veri bilimindeki konumu, kendine özgü uygunluğundan çok tarihsel yayılımı, genel amaçlı oluşu ve ekosisteminin büyüklüğüne dayanıyor
  • Derin öğrenme alanı, PyTorch ve yapay zeka ekosistemi sayesinde açık biçimde Python merkezli
  • Ancak veri temizleme, keşif, görselleştirme ve istatistiksel modelleme tarafında hâlâ çok sayıda rahatsızlık noktası var
• Bu popülerlik “tarihsel bir kazaya (historical accident) yakın” olarak tanımlanıyor; R’ye kıyasla dil yapısının ağırlığı farklı örneklerde tekrar tekrar ortaya çıkıyor

İyi bir veri bilimi dilinin koşulları

• Veri keşfi, özetleme, model uydurma ve görselleştirme odaklı işlerde etkileşimli ortam, düşük kurulum maliyeti ve hızlı yineleme en kritik unsurlar
  • Derlenmiş dillerden çok betik tabanlı yorumlayıcı diller daha uygun
  • Performanstan önce kod sadeliği, hata riskinin azaltılması ve bilişsel yükün en aza indirilmesi gelmeli
  • Gerekirse tüm sistemi değil, yalnızca bazı işlemleri yüksek performanslı bir dille (Rust gibi) yeniden yazmak yeterli olabilir
• Gerçekçi olarak değerlendirilebilecek diller R ve Python
  • Matlab, Mathematica gibi seçenekler ya ticari ya da ekosistem açısından sınırlı
  • Julia sık anılsa da, yazar yeterince kullanmadığı için değerlendirmeyi erteliyor

“Mantık vs lojistik” sorunu

• Veri analizi dili, neyin hesaplanacağını (mantık) ve nasıl hesaplanacağını (lojistik) ayırabilmeli
  • Veri tipleri, indeksler, döngüler ve elle birleştirme ile uğraşmak gerekiyorsa, artık lojistiğe saplanılmış demektir
• Palmer Penguins örneğinde, R tidyverse ortalama ve standart sapma hesaplarını doğal dile yakın bir akışla ifade ediyor
  • Veri akışını parçalayıp sonra yeniden birleştirme sürecine ihtiyaç duymuyor
• pandas benzer işlevler sunuyor, ancak string belirtimleri, parantezler, metod zincirleri, reset_index gibi ek işler yüzünden okunabilirlik ve sadelik düşüyor
• Aynı iş saf Python ile uygulanmak istendiğinde
  • Döngü kurma → grup anahtarı oluşturma → bölme → ortalama hesaplama → varyans hesaplama → standart sapma hesaplama → yeniden birleştirme → sıralama gibi adımlar gerekiyor
  • Her şeyin elle yapılması gerektiğinden lojistik kodunun mantığı ezip geçtiği tipik bir örnek ortaya çıkıyor

Sonuç ve devam yazısı için işaretler

• Python, veri analizinde mantıktan çok uygulama ayrıntılarına odaklanmaya zorlayan yapısal sorunları tekrar tekrar gösteriyor
  • Bunun, dilin kendi özellikleri, kütüphane tasarım sınırları ve ekosistem genelindeki alışkanlıkların birleşik sonucu olduğu düşünülüyor
• Devam yazısında, Python’ın R’ye göre veri analizini neden daha zorlaştırdığını açıklayan somut teknik nedenler ele alınacak

Ek tartışma ve karşılaştırma açıları (okur geri bildirimleri dahil)

• tidyverse, temel R’ye göre daha uzun olabilir; ancak ifade gücü, tutarlılık ve veri işleme soyutlaması açısından güçlü olduğu görüşü de var
• Buna karşılık, R’nin modülerlik, test ve CLI uygulaması gibi yazılım geliştirme yönlerinde ciddi rahatsızlıklar yarattığı itirazı da dile getiriliyor
• Python, logging, sanal ortamlar, paketleme ve sınıf yapısı gibi geliştirici deneyimi açısından güçlü; ancak
  • matplotlib için sezgisel olmayan tasarım,
  • pandas için tutarsız söz dizimi,
  • scikit-learn için tasarım sorunları sık sık gündeme geliyor
• Bazı görüşlerde Python, “kararsız ve düşük kaliteli kodu hızla çoğaltan bir dil” olarak görülüyor;
  sürdürülebilir geliştirme için statik tipli dillerin daha iyi olduğu da söyleniyor

[kaydash]

Veri karmaşıklığı ve miktarı artıp adım adım bölünmüş işleme ihtiyaç duyulurken, aynı zamanda yapılandırılmamış veri, yapılandırılmış modeller ve LLM aracılığıyla işleme de gerekiyorsa, kullanım senaryosu da çok olduğundan en uygun dil değil midir?

[GN⁺]

Hacker News görüşleri

• boxplotu violin plota ya da line plotu heatmape çevirmek gibi çeşitli dönüşüm örnekleri verilmiş
  Aslında bu tartışma Python'dan çok matplotlib ile ilgili
  Python'da ggplot tasarımını istiyorsanız plotnine kullanabilirsiniz
  R kodunun daha kısa görünmesinin nedeni, R'nin standart dışı değerlendirme (non-standard evaluation) yaklaşımıdır
  Python dil düzeyinde bu tür genişletmelere izin vermez
  İlgili içerik için Computing on the language bağlantısına bakın

  • Sonuçta bu, Python ile R arasındaki farklarla ilgili bir tartışma
    Standart dışı değerlendirme etkileşimli ortamlarda kullanışlı olsa da, karmaşık analiz kodları yazarken aslında bir dezavantaj haline gelir
    Basit işler için bile dolaylı yollara başvurmak gerekebilir
  • R kodunda pipe'ın satır sonunda olması göze hoş gelmiyor
    Elixir'deki gibi önde pipe operatörü kullanmanın daha iyi olduğunu düşünüyorum
    Python da getattr gibi numaralarla benzer bir sözdizimini taklit edebilir, ama bu sonuçta dilden çok kütüphane API tasarımı meselesi
  • “Kütüphane olmadan lojistik işi R ile yapılsaydı?” Bunu hayal etmek bile korkunç
    R ancak kütüphaneler ve reçeteler olduğunda kolay; bunlar yoksa gerçekten zorlaşıyor ve çoğu kişi de uğraşmıyor
  • Bu amaç için seaborn uygun
    matplotlib'in hantallığını soyutlarken zengin özellikler de sunuyor
    Seaborn öğreticisi
  • Esas nokta sanki Python'dan çok, R'nin yapabildiği ama Python'ın yapamadığı şeyleri anlatmak

• Programlama dillerinde neden tabloların birinci sınıf nesne olmadığını merak ediyorum
  Çoğu dilde tablolarla çalışmak için pandas ya da polars gibi ayrı API'ler öğrenmek gerekiyor
  R'de data.frame birinci sınıf nesneye yakın, ama pratikte daha çok dplyr'ın tibbleı kullanılıyor
  Tablo verisini ele alan bir ifade dili hâlâ standartlaşmış değil
  Polars ile dplyr benzer bir felsefeyi paylaşıyor, ama sonuçta tek ortak temel sanki SQL gibi görünüyor
  Python kusursuz değil ama bence R de değil

  • Dil düzeyinde eksik birçok yapı varmış gibi geliyor
    tablo, matris, grafik, durum makinesi gibi yapılar dil seviyesinde desteklenmediği için kullanım alanları sınırlı kalıyor
    Bir dilin varsayılan olarak sunduğu araçlar, o dilin “güzel yolunu” belirler
    Eskiden key-value store da harici bir kütüphaneydi, ama artık neredeyse standart haline geldi
  • Q, Rye, Lil gibi diller tabloları gerçekten birinci sınıf veri tipi olarak ele alıyor
    Bir gün ana akım dillerin de bu tür tablo tabanlı programlamayı içine alacağını düşünüyorum
    Q dili, Rye karşılaştırma yazısı, Lil deney aracı
  • tibble ve data.table, data.frame'den türediği için R'nin temel fonksiyonları aynen çalışır
    Bu üç nesne arasında dönüşüm yapmak da çok kolaydır
  • Tablo boyutu 1 milyon, 1 milyar, 1 trilyon satıra çıktıkça problemin doğası tamamen değişir
    Bu ölçek farklarını zarif biçimde ele alabilecek standart bir API tasarlamak kolay değil
  • R'nin data.table paketi harika
    Ama dplyr dokümantasyon ve onboarding tarafında kazanarak sektörde benimsenmeyi elde etti

• Yazının ana fikri fena değil ama yazarın iddiasının dayanaklarını fazla erken açığa vurması üzücü
  R, data frame işleme konusunda güçlü ama dosya yönetimi ve bakım tarafında zayıf
  Bu tür iş çoksa Python daha iyi bir tercih oluyor; hız da önemliyse tercih Julia'ya kayıyor
  Hangi dilin seçileceği önceliklere bağlı
  Öğrencilerin pandas ile grafik gibi tablo dışı problemleri çözmeye çalıştığını sık görüyorum; böyle durumlarda araç seçimini yeniden düşünmek gerekiyor

  • Python örnek kodu uygun değil
    numpy kullanılırsa ortalama ve varyans hesapları zaten gömülü geliyor
    Python ile R'nin öğrenme zorluğu benzer, ama Python'ın gücü başka uygulamalarla entegrasyon tarafında
  • Yazının ikinci bölümü burada görülebilir
  • Ben de Python ile R'yi aşağı yukarı yarı yarıya kullanıyorum
    Büyük dosyaları işlerken Python, özet verileri analiz ederken R daha verimli
    Her dili doğru iş için doğru araç olarak kullanmak gerekir

• Bir Python programcısı olarak R'yi de kullandım; Python “her şeyi epey iyi yapan ama hiçbirinde kusursuz olmayan bir dil”
  Bütün gün veri analizi yapacaksanız R öğrenmek mantıklı
  R, istatistikçilerin düşünme biçimine göre tasarlanmış bir dil
  Başta yabancı geliyor ama o zihinsel geçiş aslında faydalı oluyor
  Yine de ben çoğunlukla Python'da çalışıyorum

• pandas ile veri bilimi yapmak mümkün ama hantal ve karmaşık geldi
  polars ile biraz iyileşti, ama duckdb kullanınca her şey tamamen değişti
  SQL sorgularını doğrudan notebook içinde çalıştırıp parquet dosyaları üzerinde analiz yapıyorum
  SQL hücreleriyle Python hücrelerini karıştırınca kod daha temiz oluyor
  Yazının sonundaki Python vs R karşılaştırmasına bakınca “Bu SQL ile yazılsa çok daha iyi olmaz mı?” diye düşündüm

  • Ben SQL'den çok data frame merkezli, dilin içinde kalan bir yaklaşımı tercih ediyorum
  • Sık sık polars kullanıyorum; duckdb'yi de bir denemeliyim

• Son Python örneği gereksiz yere uzun
  defaultdict ve statistics.stddev kullanılsa çok daha kısa olur

  • Bessel düzeltmesinin elle eklenmiş olması ilginç
    Çoğu zaman bunun anlamlı olup olmadığı düşünülmeden uygulanıyor
    Aslında buna sample_std_dev demek daha doğru olur
  • itertools.groupby da kullanılabilir
    Kod çok kısalmaz ama niyeti açıkça ifade edebilir
  • Orijinal kod daha okunaklı
    Kısaltmaya çalışırken okunabilirlikten ödün vermek iyi değil

• Julia'nın TidierData.jl paketiyle aynı örneği denedim; R sürümüyle neredeyse birebir aynı çıkıyor
  @chain, @group_by, @summarize gibi makro sözdizimleri R'nin tidyverse'üne benziyor

• Yazarın neden şikâyet ettiğini pek anlayamıyorum
  Python'ın veri bilimi için optimize edilmemiş olması zaten gayet açık bir gerçek
  Python bir DSL değil; MATLAB bile bilimsel hesaplama için tasarlanmış olsa da çok popüler bir dil değil
  İyi bir dil, kusursuz hava durumundan çok yaşaması rahat bir şehir gibidir
  Python da “havası çok iyi olmayan ama gelişen bir Kuzey Avrupa şehri” gibi
  Yazının konusu biraz tıklama avcılığı kokuyor; çok üretken bir tartışma değil bence

• Keşke Julia daha yaygın kullanılsa
  Daha önce psikometri makalesi için bir algoritmayı Julia ile yeniden uygulamıştım ve MATLAB'dan üç kat hızlı çalışmıştı
  İlgili makale bağlantısı

  • O 40 dakikalık çalışma süresi tasarrufunun, makalenin genel hazırlık takvimi içinde ne kadar önemli olduğunu merak ediyorum

• Son örnek, gerçekçi bir Python kodundan çok Python karşıtı bir taşlama gibi duruyor
  Standart sapmayı elle yazmak lisans ödevi seviyesinde bir şey
  Gerçekte hem R hem Python içeride bu tür döngüleri çalıştırıyor

  • Yazının laboratuvar bağlamına odaklanmasını anlıyorum
    Ama gerçek sektör ortamında Python ile mühendislik ekipleriyle işbirliği yapmak çok daha kolay
    Daha önce R kodunu production'a aldım ve çok kırılgandı
    R, keşifsel veri analizi (EDA) için harika ama büyük ölçekli yazılım geliştirme için uygun değil