Alternatif Uygulama Sorunu

Alternatif uygulamanın sorunu

Yazar, yazılım dünyasında tekrar tekrar ortaya çıkan alternatif uygulama sorunundan bahsediyor. Yazarın deneyimi ağırlıklı olarak dinamik tipli programlama dillerini optimize etmek üzerineydi.

• PyPy projesi, Python için gelişmiş bir JIT derleyicisi geliştirdi, ancak pratikte neredeyse hiç kullanılmadı. Python sürekli yeni özellikler ekleyip değiştiği için PyPy'nin buna yetişmesi zordu.
• LuaJIT çok takdir görüyor, ancak Lua dili yeni özellikler eklemeyi sürdürdükçe LuaJIT birkaç sürüm geride kalmış durumda.
• TruffleRuby JIT en etkileyici performansı sundu, ancak CRuby'ye kıyasla özellik uyumluluğu yetersizdi; bu yüzden dağıtımı sınırlı kaldı.

Ders: alternatif uygulamalar başarısız olmaya mahkum bir tercih olabilir

• Alternatif bir uygulama yapıldığında, resmi uygulamadaki değişimlere bağımlı hale gelmek kaçınılmazdır.
• Resmi uygulama projenin yönünü kontrol eder ve alternatif uygulama ise yalnızca onu takip edebilir.
• Geleneksel olarak yorumlayıcı diller için JIT uygulamaları yapılırken, yorumlayıcıya yeni özellik eklemek çok daha hızlı olduğu için resmi uygulama JIT'in önüne geçebilir.

YJIT: Ruby JIT derleyicisinin CRuby içinde uygulanması

• YJIT de başka bir Ruby JIT'i, ancak bunu doğrudan CRuby'nin içinde uygulamayı seçti.
• Bu sayede YJIT baştan itibaren tüm CRuby özellikleriyle %100 uyumlu olabildi.
• Bugün Ruby'nin resmi JIT'i haline geldi ve Shopify, Discourse, GitHub gibi yerlerde kullanılıyor.

Daha geniş açıdan çıkarılacak ders

• Mevcut dillere benzeyen ama onlarla uyumlu olmayan Crystal dili de ancak sınırlı bir başarı elde etti.
• Var olan dillere benziyor gibi görünüp uyumlu olmamak insanları sadece kafa karışıklığına sürüklüyor.
• Yeni bir programlama dili yapılırken, mevcut bir dilin alt kümesi olmaya çalışmak yerine kendi yolunu çizmek daha iyi.
• Böylece başka uygulamaların performansına, özelliklerine veya kütüphanelerine bağlı kalmadan kendi hızı ve yönüyle evrimleşebilir.

GN⁺ görüşü

• Yazıda anlatılan "alternatif uygulama sorunu", yalnızca programlama dilleri için değil, çeşitli yazılım ve donanım sistemleri tasarlanırken de dikkat edilmesi gereken bir konu.
• Yalnızca kararlılık ve uyumluluğa odaklanılırsa yenilik yapmak zorlaşabilir. Ancak gerçek kullanıcı açısından uyumluluk çok önemli bir unsur. Yeni teknolojiler ile kullanıcı dostuluğu arasında denge kurmak önemli.
• Uzun vadeli bakışla, yeni başlatılan bir projenin "kiminle uyumlu olduğu" ve "hangi yönde evrileceği" üzerinde yeterince düşünmek gerekiyor.
• Yeni bir programlama dili yapılırken yalnızca mevcut dillerin sözdizimine benzemek, kafa karışıklığını artırır. Bunun yerine kendi felsefesini ve yönünü netleştirmek daha doğru.
• Pazardaki rekabetten çok yaratıcı ve özgün çözümler ortaya koymanın uzun vadede başarı şansını artırdığı görülüyor.

[GN⁺]

Hacker News görüşü

• Yeni bir alternatif implementasyon geliştirirken mevcut sürümden farklı bir mimariye sahip olunursa, mevcut sürümde kolay olan şeyler yeni sürümde çok zor olabilir. Örneğin proprietary bir yazılım section bazında load/save yaparken yeni sürüm tüm belgeyi belleğe yüklüyorsa, ek dosya ekleme özelliğini desteklemek için yeni sürümün tüm mimarisini değiştirmek gerekebilir.
• Mevcut implementasyona alternatif olarak konumlanmak kaybettiren bir önerme. "Python + X" diye pazarlanan projelerin resmi sürümle rekabet etmesi zor. Ancak MicroPython gibi microcontroller'lar için tasarlanıp CPython ile rekabet etmeyip diğer microcontroller programlama ortamlarıyla rekabet ederse başarılı olabilir.
• Uyumluluk iddialarına rağmen, pratikte eski dil özelliklerinde bile uyumluluğun düşük olması alternatif implementasyonların başarısız olma nedenlerinden biri oluyor. Ruby ve Python için native C extension desteğinin yetersizliği buna örnek.
• Startup kurma deneyimine göre, temel özellikleri kovalamak yerine mimarinin kurumsal özellikleri destekleyebildiğini göstermek ve farklılaştırıcı bir şeye odaklanmak gerekirdi.
• Geliştiriciler JIT'ten çok dil özelliklerine ve birlikte çalışabilirliğe önem veriyor. Mevcut projelere katkı sunmak yerine kendi paralel projesini yapmak daha kolay, ama bunun kimin için olduğunu kendine sormak gerekiyor. Kendini beğenmişliğe kapılmamaya dikkat etmek lazım.
• Wrapper kodu standarttan sapıyor ve yetersiz dokümantasyon nedeniyle acı veriyor. Yalnızca gerçekten gerekli özellikleri eklemek ve varsayılanları kullanmak daha iyi.
• Bu, TiDB'nin MySQL uyumluluğu nedeniyle yaşadığı sorunlara benziyor. Teoride açık bir protokol ama pratikte yönü Chrome belirliyor.
• Kotlin hakkında herhangi bir yorum yoktu.