- Mevcut D liderliği üzerinden katkı yapmanın uzun süredir tıkandığına dair şikâyetler birikince, bazı katkıcılar OpenD adlı D dili çatallamasına geçti
- Tartışmanın özü D’nin kapalı kaynak olup olmamasından çok, GPL olarak açılması ve gdc’nin yayımlanmasından sonra bile geliştirme biçimi ve karar alma süreçlerinin topluluğa yeterince açık olmaması
- Ares/Tango’nun daha sonra druntime’a uzanan örneği, Phobos etkinliğinin azalması, PR’ların bekletilmesi ve “D gripes and wishes” sonrasında uygulamanın yetersiz kalması çatallamanın gerekçeleri olarak gösteriliyor
- OpenD’ye geçiş sonrasında upstream D’ye PR, hata bildirimi, kullanıcı desteği, DLF toplantıları ve DConf Online katılımı durduruluyor; dpldocs.info ise maliyeti karşılandığı sürece sürdürülecek
- Ücretli destek sözleşmesi olmayan mevcut D kütüphaneleri ve uygulamaları upstream D uyumluluğu garantisi almayacak; uzun vadeli destek yolu OpenD’ye katılım tarafına kayıyor
OpenD’ye geçme nedeni
- OpenD, D dilinin bir çatallamasıdır ve mevcut D liderliği aracılığıyla upstream’e katkı yapma sürecinin uzun zamandır çok yıldırıcı olduğu düşüncesinden doğmuştur
- D’nin kapalı kaynak bir dil olduğuna dair tekrarlanan ifade doğru değildir
- Derleyicinin D’ye özel kısmı 2002’de GPL olarak açıldı
- Tamamı GPL olan derleyici gdc 2004’te yayımlandı
- Ancak D’nin geliştirme metodolojisinin yeterince açık olmadığı ve karar alma süreçlerinde topluluktan anlamlı girdinin çok az olduğu eleştirileri sürüyor
- D’nin temel özellikleri ve kavramları ile mevcut D kodunun önemli bir bölümü topluluk girdisi ve emeğinden geldi; ancak yalnızca kabul edilen örneklere bakılırsa hayatta kalma yanlılığına düşülebilir
Eski katkı darboğazı ve Ares/Tango örneği
- D tarihinde kabul edilmiş çok sayıda yama olduğu gibi, uzun süre bekletilmiş çok sayıda yama da vardı
- Bugün druntime olarak bilinen kod, Walter’ın topluluk katkılarını kabul etmemesi sonucunda ortaya çıkan bir çatallamadan doğdu
- 2004’te upstream ile iş birliği yapmaya çalışan geliştiriciler, katkılarını kaybetmemek için D’yi çatalladı
- Bu çatallama başta Ares olarak adlandırıldı, sonra başka topluluk çabalarıyla birleşerek Tango oldu
- Tango kendisini “D için Geliştiricinin Kütüphanesi” olarak konumlandırdı ve geliştiricilerin katkılarının gerçekten memnuniyetle karşılandığı bir alan işlevi gördü
- Tango ekosisteminde Phobos ekosisteminde olmayan birçok unsur vardı
- Çatallama 4 yıl boyunca sürdürüldükten ve popülerlik kazandıktan sonra upstream uzlaşma yoluna gitti; bu akış bugünkü druntime’a uzandı
- Altta yatan değerlendirmeye göre Ares/Tango çatallaması olmasaydı D piyasada anlamlı bir konum elde edemeyecekti ve bu çatallama D’yi krizden kurtardı
Altın çağ sonrası azalan katılım
- Tango’nun çekirdek geliştiricilerinin geri döndüğü ve Andrei Alexandrescu gibi isimlerin katıldığı dönem, D geliştirmenin görece açık olduğu ve 2013 civarında etkinliğin arttığı bir altın çağ olarak tanımlanıyor
- Neredeyse tüm ticari D kullanıcılarının Ares çatallamasından çıkan koda doğrudan bağımlı olduğu da vurgulanıyor
- Ancak eski alışkanlıklar ortadan kalkmadı ve altın çağ katkıcılarının çoğu toplulukta kalmadı
- Bazıları çalışmalarının değer görmediği bozuk süreçleri açıkça gerekçe göstererek ayrıldı
- Bazılarının etkinliği kişisel nedenlerle azaldı ve yeterince yeni katkıcı kalmadı
- Phobos geliştirme etkinliği 2018 ortasında ciddi biçimde azaldı; sonrasında iki kez küçük etkinlik artışı oldu
- berni44’ün CTFE uyumlu kayan nokta biçimlendirme eklemesi
- Paul Backus’un sumtype modülünün
std.sumtypeolarak kabul edilmesi
- berni44, 2020’de bir PR incelemesi için neredeyse 3 ay bekledikten sonra topluluktan ayrılacağını söyledi; 1 yıl sonra geri dönerek yakın dönemde Phobos geliştirme etkinliğinde artış yarattı, ancak birkaç ay sonra tekrar ayrıldı
- dmd’nin kendisinde de Walter’ın kişisel katkı miktarı genel olarak sabit kalsa da, diğerlerinin katkısı azaldığı için payı altın çağdaki yaklaşık 1/6 düzeyinden bugün yaklaşık 1/3’e çıktı
Tekrarlanan şikâyet toplama ve uygulama eksikliği
- 2022 Noel’i civarında Mike Parker insanlardan “D gripes and wishes” listelerini göndermelerini istedi
- Birçok kişi sonuç çıkmayacağını düşündü, ancak çok sayıda yanıt geldi
- Yaklaşık 6 ay sonra, 18 Mayıs 2023’te yanıtları derleyen açık belge yayımlandı
- Sonrasında kamuya açık biçimde doğrulanan sonuç, şu hedeflerin belirlenmesiyle sınırlı kaldı
- Dil, derleyici ve standart kütüphaneyi kararlılaştırma
- Araçlar ve üçüncü taraf kütüphane desteği gibi ekosistem iyileştirmeleri
- Web sitesini düzenleme, eski dokümantasyon ve eğitimleri güncelleme, web sitesini yeniden tasarlama gibi topluluğu güçlendirme
- İstenen şey “genel yazmayın, somut yazın” olsa da, birçok somut şikâyete verilen yanıt büyük kategoriler hâlindeki hedef maddeleriyle sınırlı kaldı
- 2016H1 Vision Document’ta da katılımı artırma, araçlar, dil kararlılığı ve spesifikasyon iyileştirmeleri, kütüphane eklemeleri gibi benzer hedefler bulunduğu için, hedef belirlemekten çok uygulamaya ihtiyaç olduğu görüşü savunuluyor
OpenD’ye geçişle değişenler
- Upstream D’ye katkı denemeleri durduruluyor ve tüm derleyiciyi hedefleyen OpenD çatallamasına geçiliyor
- dpldocs.info dokümantasyon barındırması, maliyeti Patreon ile ancak karşılanan bir durumda; maliyetler karşılandığı sürece dub paket desteği dâhil çalışmaya devam edecek
- Upstream D güncellemelerini almayacak
- Mevcut işlevlerin muhtemelen düzgün çalışmaya devam edeceği düşünülüyor
- Blogda upstream D’ye özel destek bölümü durduruluyor
- İstatistikler artık yer almayacak
- Adı “This Week in ARSD” olarak değişiyor; ileride “This Week in OpenD” olabilir
- Upstream D’ye PR ve hata bildirimleri hemen durduruluyor
- Kendisine fayda sağlayan içerikler upstream’e gönderilmeyecek, OpenD’ye birleştirilecek
- D kullanıcı desteği de durduruluyor
- Geçmişte farklı deneyim düzeylerindeki D kullanıcılarına her hafta saatlerce destek verilmişti; artık upstream D sorularına yanıt garanti edilmiyor
- Yanıt verilirse büyük olasılıkla OpenD’nin denenmesi söylenecek
- Yönetişim değişikliğini ön koşul olarak kabul etmedikleri sürece DLF toplantılarına katılınmayacak
- DConf Online canlı yayın daveti gelse bile reddedilecek
- D kütüphaneleri için yalnızca ücretli destek sözleşmesi olan hedeflerde, iç sürümler ile dış derleyici güncellemeleri arasında uyumluluk taahhüdü sürdürülecek
- Diğer kullanıcılar için upstream D uyumluluğu derhâl iptal ediliyor
- Kod, açık veya zımni hiçbir garanti olmadan olduğu gibi sunuluyor
- OpenD çatallamasına katılanlar için bu kütüphane desteği sürecek
- D uygulamaları da kütüphaneler gibi upstream D uyumluluk taahhüdüne sahip değil; zaten kişinin kendi kullanımı için tasarlandıklarından uyumluluk garantisi daha gevşek
Kalan duruş
- Son 16 yılda D’ye çok zaman ayırdığını ve programlama kariyerinin büyük bölümünü D’ye ve ondan önceki Digital Mars C++’a borçlu olduğunu belirtiyor
- Walter Bright ve çalışma arkadaşlarının hayatında büyük etkisi olduğunu, Walter’ın programlama dili projeleri için mükemmel bir katkıcı olduğunu değerlendiriyor
- Yine de artık Walter Bright’ın D’sinden ayrılıp OpenD adlı ayrı yolu seçiyor
- OpenD’nin başarılı olması için yapılacak çok iş var ve başarısız olma olasılığı da çok yüksek; ancak artık başarısızlığın sorumluluğunun yalnızca OpenD tarafındaki kendilerinde olduğunu düşünüyor
1 yorum
Hacker News yorumları
En azından Walter ve muhtemelen diğer D liderliği de burada aktif olduğuna göre, bu yorumları görme ihtimalleri yüksek
Onların da insan olduğunu, D'yi gerçekten önemsediklerini ve benim deneyimime göre ellerinden gelenin en iyisini yapmaya çalışan, temelde iyi insanlar olduklarını hatırlamanızı isterim
Şimdi neden farklı olacağını düşündüğünüzü bilmiyorum; bu bana Tango 2. perde gibi bir tekrar hissi veriyor
Tek fark, artık geminin çoktan kalkmış olması
Proje başka bir liderlik altında daha iyi olabilecekse, bu olasılık değerlendirilmelidir
Kişisel olarak D'nin yeniden canlanmasını gerçekten istiyorum; hâlâ en sevdiğim dil
Walter'a ya da başka birine saldırmak değil bu; sadece sevdikleri şeyi hayatta tutmaya çalışan insanlar
Üzücü ama böyle bir şeyin eninde sonunda olması kaçınılmazdı. Çünkü yıllardır D fork'u hakkında çok fazla konuşuldu
2010'da Andrei Alexandrescu'nun kitabı çıktığında, D'de iyi olan neredeyse her şey C#, Java ve C++'a girdi
Uygulamaları D'deki kadar temiz olmayabilir, ama daha iyi araçlar ve kütüphane ekosistemleri içinde bir şekilde kullanılabiliyorsa, aradaki fark çok da önemli olmuyor
İnsanları çekecek altın özelliklerin peşinde çok fazla zaman kaybedildi ve bu özellikler de kararlı hâle getirilemedi
Andrei de bugünlerde D'den çok C++ ve CUDA ile meşgul görünüyor
Son 10 yılda native derlenen programlama dillerinin rönesansı da üstüne eklenince rekabet daha da sertleşti
Bu yüzden daha da üzücü. Çünkü topluluğun içinde sohbet etmesi keyifli, harika insanlar çok
Her gün Python kullanıyorum ve D'de özlediğim çok şey var
Performansı saymıyorum bile
D'ye dışarıdan bakan biri olarak benzer bir şey görmüştüm
Rust yeniyken lifetime (ömür) kavramı D topluluğuna önerilmişti, ama Walter bunun gereksiz olduğunu düşünmüştü
Birkaç yıl sonra Walter, Rust'tan yeterince farklı kendi lifetime önerisini getirdi; bu yüzden de topluluğun önceki önerisine kıyasla daha az doğrulanmış durumdaydı
Artık D'ye ilgimi kaybettiğim için yeni lifetime özelliğinin ne kadar olgunlaştığını bilmiyorum, ama Rust'taki kadar faydalıysa şaşırırım
Her özellikte başka dil özellikleriyle etkileşim, bilişsel yük, derleme hızında düşüş, standart kütüphane tasarımında karmaşıklık, geriye dönük uyumluluğun bozulması gibi ödünleşimler vardır
Başka bir dilde sevdiğiniz tek bir özelliği desteklemek için büyük çaplı bir elden geçirme beklemenin makul olduğunu düşünmüyorum
Araştırma grubum birkaç yıl önce yanıt eksikliği ve dil geliştirme yönünün kötü olması nedeniyle D'yi bırakıp Rust'a geçti
Adam ve diğerlerinin OpenD ile başarılı olmasını umuyorum, ama bu fırsatta daha özgün ve akılda kalıcı bir isim seçseler iyi olur
Yeni bir yönetişim modeli, yeni özellikler listesi ilan etmekle ya da bazılarını çıkaracağını kararlaştırmakla başlamaz; ilgili taraflardan oluşan bir çoğunlukla yönetişimi tartışmakla başlar
Bu bir model değişikliği değil, yalnızca iktidar değişimidir
Meşru şikâyetler olabilir ve D'nin Walter'a kapı bekçisi olarak bağımlı olması bazılarına fazla katı gelebilir
Ama bu fork'un başlama biçimi uzun vadede iyi bir işaret değil
Fork'un başarılı olması için geniş destek alması ve sonunda yalnızca sayıca az birkaç üretken katkıcının değil, D topluluğunun çoğunluğuna yakın bir kesimin de yanına çekilmesi gerekir
Aksi hâlde fork da başarısız olur, orijinal projeye olan ilgi de daha fazla bölünür ve elde kalan yaşama şansı bile kaybolabilir
Ayrıca onlarca yıl boyunca destekleme becerisi ve iradesi gerekir
Görünüşe göre bir güncelleme yayımlanmış: https://dpldocs.info/this-week-in-d/Blog.Posted_2024_01_08.h... ve belli ölçüde ilgi de görmüş gibi
Kişisel olarak adını Died koysalar daha eğlenceli olurdu diye düşünüyorum
“It never Died” gibi havalı bir ifade de mümkün olurdu, fork olduğu da anlaşılırdı ve ileride gerekirse dili yeni bir yöne taşıma alanı da bırakırdı
OpenD tam uyumluluk gibi bir izlenim veriyor
Elbette bu konuda doğrudan bir çıkarım yok; başarılı olmasını dilerim
D forumunda bu konuda büyük bir başlık var: https://forum.dlang.org/thread/beykokfitddfdsjyqjjy@forum.dl...
Orijinal yazı daha çok kişiler arası çatışmalara dair şikâyetlerden oluşuyor; bu bağlantıda ise daha fazla teknik tartışma var
Buna bakınca fork'u yapanların aslında farklı bir dil istediği ve bunun için çeşitli uyumluluğu bozan değişiklikleri de göze almaya hazır oldukları anlaşılıyor
Kişisel olarak D'nin çöp toplayıcıya tamamen odaklanması hâlinde hangi niş pazarı hedeflediği konusunda kafam karışıyor
Daha önce de belirgin bir nişi olduğu söylenemezdi. Özünde “%10 daha iyi C++” idi ve onu net biçimde farklılaştıran bir öldürücü özelliği olmadığı için pazarlaması zordu
Çoğu kişi mevcut destek, kod tabanı ve sektör altyapısı nedeniyle C++'ta kalacak; yeni projelerde Rust kullanacak ya da sadelik isterse Zig'i tercih edecek gibi görünüyor
Özellikle C++20'den sonra zaten “%10 daha iyi C++” var sayılır
Buna karşılık çöp toplayıcıya odaklanmanın büyük yardımı olup olmayacağını da bilmiyorum
O zaman C# ve Java ile rekabet etmek gerekir; bu ikisi en başından beri çöp toplama özelliği olan, güvenli ve daha özlü C++ ardılları olarak tasarlanmış diller ve bugün onlarla nasıl rekabet edilebileceğini pek göremiyorum
Özellikle C#, ham işaretçiler, referans türü/değer türü denetimi, bellek yerleşimi denetimi gibi oldukça iyi düşük seviye ve unsafe özelliklerin yanı sıra; yaşlı, nesne yönelimini önceleyen bir dil için fena olmayan bir tür sistemi ve reflection'a sahip, ayrıca ML ailesinden özellikleri de sürekli bünyesine katıyor
Açıkçası D'nin vizyonu bana her zaman kafa karıştırıcı geldi
BetterC, safe mod, ömürler gibi belirli dil özelliklerinin belgelerini okudum ama sözdizimsel olarak okunması zordu; ayrıntılı açıklamalar çok olsa da genel olarak iyi anlatılmamıştı
Dilde tutarlı bir tasarım vizyonu ya da amacı doğru düzgün hissedemedim
Yazar bu soruna değiniyor ama onların vizyonu da pek daha net görünmüyor
Bazı somut orta vadeli teknik hedeflerin olması iyi, fakat bu hedeflerin ne için var olduğu belli değil
Ben bir Rust programcısıyım, yeni kişisel projelerde ne kullanacağım belli; ama başka bir şey seçmek zorunda kalsam OCaml, C++, hatta C# kullanmayı tercih ederim
Birincisi, D bir C++ alternatifi ama C++ değil ve birçok C++ geliştiricisi bu fark yüzünden hayal kırıklığına uğradı
İkincisi, D bir C++ alternatifinden çok daha fazlasını yapabilir
Betikler, genel amaçlı programlama dili ve özellikle ImportC ile BetterC gibi C birlikte çalışabilirliği için kullanılabilir
Fork'un hedeflerinden biri çöp toplayıcı konusunda artık bahane üretmemek
Standart kütüphanede hâlâ referans sayımı, unique pointer vb. de var
Birisi çöp toplayıcıdan kaçınan bir fonksiyon katkısı yapmak isterse kabul edileceğini düşünüyorum
Ancak bu fork'ta Adam'ın standart kütüphaneye yeni fonksiyon eklerken çöp toplayıcıdan kaçınmak için aşırı uğraştığını görme ihtimalimiz düşük
O, çöp toplayıcı korkusunun abartıldığını düşünüyor
Son 10 yılda programlama dillerinin yönetişimi etrafında öğrenilecek çok şey oldu
Yükselen ve değişim hâlindeki dillere bakınca, onların da yönetişimle ilgili büyük çatışmalar ya da hatalar yaşadığını görüyoruz
Artık bir programlama diline bakarken temel olarak incelenmesi gereken şeyin yönetişim olduğunu düşünüyorum
İşleyişlerini nasıl anlattıklarına, gerçekte nasıl yürüttüklerine, şimdiye kadarki sonuçların nasıl olduğuna ve bundan sonra nasıl olacağına bakmak gerekiyor
Programlama dillerinin evrimi neredeyse tamamen karmaşıklık yönetimi gibidir ve aynı anda birden fazla paydaşın ihtiyaçlarını dengeli biçimde karşılamayı gerektirir
Neredeyse tüm yönetişim çatışmaları, bir paydaş grubunun başka bir grup için zorunlu olan gereksinimlere itiraz etmesiyle ortaya çıktı ve iki tarafı her zaman memnun etmek mümkün değil
Rust'ın
asyncözelliği bunun bilinen bir örneği; çalışıyor ama genel olarak tatmin edici olmayan bir tasarımı açıklıyorGo nadir bir istisna; çekirdek ekibin tüm paydaşlara saygı duymak zorunda olması için bir neden yoktu ve bunu yapacak kaynakları ile iradesi de yeterliydi, ama yine de bazı çatışmalar yaşandı
1960-80'lerin standart yazım modeli çok daha iyiydi ve siyasi kavgaları da kısa bir dönemle sınırlıyordu
Birden fazla derleyici implementasyonu olmasının ne gibi olumsuz yanı olduğunu pek bilmiyorum
Kişisel olarak C'nin bu kadar yaygınlaşmasının başlıca nedeninin bu olduğunu düşünüyorum
Derleyiciler kendi yönlerinde keşif yapabilir; değeri kanıtlanan dil uzantıları sonunda diğer implementasyonlar tarafından da benimsenir ve bazen komite uzlaşma sürecinde fazla zedelenmeden standarda bile girebilir
En azından gcc ve dlang tarafındaki implementasyonlarla 2 tane olduğunu sanıyordum