Hiçbir şey yapmayacaksanız, en azından doğru şekilde hiçbir şey yapmamayı bilin

• Belirli bir platform ya da kullanımdan kaldırılma durumu nedeniyle gerçek işlev sağlanamasa bile, mevcut uygulamaların bozulmaması için belgelenmiş API sözleşmesi içinde “hiçbir şey yapmayan” bir davranış tasarlanmalıdır
• Xbox gibi yazdırma altyapısı olmayan ortamlarda, NotSupportedException yerine 0 yazıcı döndüren başarılı bir yanıt, PC’ye göre yazılmış uygulamalar için daha güvenlidir
• Bu yaklaşım inert API olarak adlandırılır; API yüzeyi ve belirtimi korunur ama gerçekte yararlı bir iş yapılmaz
• Kullanımdan kaldırılan bir widget API’sinde CreateWidget başarılı olup nullptr döndürürse çağıran taraf çelişkili bir durum yaşar; bu yüzden belgelenmiş ERROR_CANCELLED hata yolu daha tutarlıdır
• Doğru tasarlanmış bir inert API, yalnızca işlevi ortadan kaldırır ve mevcut kodun zaten hazırlıklı olduğu hata yollarını kullanarak istisna, hatalı handle ve çökme olasılığını azaltır

---

İşlev olmasa da API sözleşmesi kalır

• API’nin hiçbir şey yapmaması gereken durumlar olabilir, ancak bu etkisiz davranış da mevcut kod ve belgelenmiş davranışla uyumlu olmalıdır
• Kötü tasarlanmış bir etkisiz davranış; istisnalar, çelişkili dönüş değerleri ve geçersiz durumlar üretip uygulama çökmelerine ya da gereksiz kullanıcı hatalarına yol açabilir

Xbox’ta yazdırma API’sini etkisizleştirme yöntemi

• Windows’ta kapsamlı bir yazdırma altyapısı bulunur, ancak Xbox’ta bu altyapı yoktur
• Xbox’ta bir uygulama yazdırmayı denediğinde yazdırma işlevi NotSupportedException fırlatırsa sorun büyüyebilir
  • Xbox’a yüklenen uygulamalar büyük olasılıkla esas olarak PC’de test edilmiştir
  • PC’de yazdırma her zaman mümkün olduğundan, yakalanmayan bir istisna uygulamanın çökmesine neden olabilir
  • İstisna yakalansa bile kullanıcı “incident code’u destek ekibine iletin” gibi bir hata mesajı görebilir
• Daha iyi tasarım, yazdırma işlevinin başarılı olması ama kurulu yazıcı olmadığını bildirmesidir
  • Uygulama yazıcı seçme arayüzünü açar ve boş bir liste gösterir
  • Kullanıcı yazıcı olmadığını görüp yazdırma isteğini iptal edebilir
• Yazıcı kurulumu konusunda yardımcı olmaya çalışan uygulamalara ise kurulum işlevi hemen dönüp kullanıcının işlemi iptal ettiğini ifade eden bir sonuç kodu verebilir

inert API’nin koşulları

• Bu tür “hiçbir şey yapmayan” davranışa inert denir
• inert API, API yüzeyinin varlığını korur ve belirtime uygun çalışır, ancak gerçekte yararlı hiçbir iş yapmaz
• Temel nokta, belgelerle tutarlı kalırken mevcut kodda sorun çıkarma olasılığı en düşük olacak şekilde hiçbir şey yapmamaktır
• Yazdırma API’sine yazdırmanın gerçekten mümkün olup olmadığını denetleyen bir işlev de eklenebilir
  • Uygulama bu işlevi kullanarak yazdırmanın hiç desteklenmediği sistemlerde Print düğmesini gizleyebilir
  • Yazdırmanın mümkün olduğunu varsayan basit uygulamalar da “yazıcısı olmayan ve kurulum denemelerinin etkisiz kaldığı bir sistem” davranışı görür

Kullanımdan kaldırılan widget API’sinde kaçınılması gereken tasarım

• Kullanımdan kaldırılacak API’de widget handle’ı oluşturan bir işlev, widget handle’ı alan işlevler ve widget handle’ını kapatan bir işlev vardır
• İlk öneri, CreateWidget işlevinin S_OK döndürmesi ve aynı anda *widget = nullptr ayarlamasıydı
  • Çağrı başarılı görünür ama geçerli bir handle alınmamış olur
  • Gerçek test kodlarından bazılarında başarı, dönüş değerine göre değil handle’ın null olup olmadığına göre belirleniyordu
• EnableWidget işlevinin “geçersiz handle” döndürmesi de çağıranı şaşırtır
  • Uygulama, CreateWidget başarılı olduktan sonra aldığı handle’ı EnableWidget işlevine geçirir
  • API, bu handle’ın geçerli olmadığını söyler
  • Çağıran taraf “widget istedim ve aldım, ama tekrar gösterince bunun widget olmadığı söyleniyor” şeklinde çelişkili bir durum yaşar

Belgelenmiş hata yoluyla düzeltilen tasarım

• Mevcut belgelerde, kullanıcının widget oluşturmayı iptal ettiğini ifade eden ERROR_CANCELLED dönüş değeri zaten vardır
• Uygulama, dış koşullar nedeniyle widget oluşturulamayabileceği ihtimalini zaten ele almak zorunda olduğundan, widget oluşturma her zaman kullanıcı iptali ile başarısız olacak şekilde ayarlanabilir
• Düzeltilmiş tasarımın akışı basittir
  • CreateWidget, *widget = nullptr bırakır ve HRESULT_FROM_WIN32(ERROR_CANCELLED) döndürür
  • Widget oluşturma her zaman başarısız olduğundan geçerli bir widget handle’ı hiç oluşmaz
  • GetWidgetAliases, EnableWidget, Close işlevleri handle’ın geçerli olmadığını belirten E_HANDLE döndürür
• Bu yöntemde widget olmadığı için sahte alias üretmeye de gerek kalmaz
  • Geçerli bir widget bulunmadığından uygulamanın normal biçimde alias isteyebileceği bir durum da yoktur

Masaüstü API’lerini başka ortamlara taşırken ölçüt

• Masaüstünde yazdırma API’si her zaman vardı ve “yazıcı listesini getir” işlevinin istisna fırlatmayacağı belgelenmiştir
• Bu API Xbox’a taşınırken mevcut masaüstü uygulamalarının çalışmaya devam etmesi isteniyorsa, “Xbox’ta yazıcı yok” gerçeğini dürüstçe döndüren inert davranış doğru yaklaşımdır
• “Kaç yazıcı var?” sorusuna istisna fırlatmak, belgelenmiş API sözleşmesiyle uyuşmaz
• Aynı ilke mevcut API’leri kullanımdan kaldırırken de geçerlidir
  • Yararlı bir iş yapılmasa bile API davranışı sözleşmeyle tutarlı olmalıdır
  • Mevcut kodun zaten işleyebildiği dönüş değerlerini ve durumları kullanmak önemlidir

[GN⁺]

Lobste.rs görüşleri

• Burada kastedilen, yazdırma işlevlerinin yazdırma tamamen destekleniyormuş gibi tutarlı biçimde çalıştığı, ama tuhaf bir şekilde gerçekte hiç yazıcı bulunmadığı; bu da birçok şeyi açıklıyor
  Şakayı bir kenara bırakırsak, bu kadar aşırı savunmacı programlama ve kullanıcı deneyimi yaklaşımına katılmıyorum. Böyle olunca yazılım nedenini bile bilmeden görevini yapmaz hale geliyor ve nedenini öğrenmenin de bir yolu kalmıyor. Uygulama hataları yakalayıp mümkünse kullanıcı dostu bir mesaj üretmeli; bunu yapamıyorsa en azından özgün hata mesajını kullanıcıya göstermeli. Arka plan işi ise bir hata günlüğü olmalı
  Bu yazının uygulama geliştiricisinden çok API geliştiricisinin bakış açısından yazıldığını kabul ediyorum. O yüzden API hatalarını belgelendirmeli ve çağıran tarafın harekete geçebileceği hata mesajları sağlamalısınız
  Ayrıca erişim izni yok diye UI'da düğmeleri gizlemekten de hoşlanmıyorum. Yer varsa düğmeyi gösterip devre dışı bırakmak ve kullanıcı üstüne geldiğinde onu nasıl etkinleştirebileceğini anlatan bir mesaj göstermek daha iyi bence
  • Bunun sıradan bir API geliştiricisinin değil, bir Windows API geliştiricisinin bakış açısı olduğunu da hesaba katmak gerekir. Windows API'lerinde sürüm değişse bile geriye dönük uyumluluğu bozmamak, Microsoft'un uzun süredir benimsediği bir tutum
  • Bu, klasik bir Postel yasası / sağlamlık ilkesi tartışması. Artık sağlamlık ilkesinin eskidiğini ve HTML gibi ya da düzgün bir ayrıştırıcı yazmayı zorlaştıran devasa protokoller ve dosya biçimleri gibi canavarlar ürettiğini hepimiz biliyoruz
    Genel olarak doğruluğu talep etmek daha iyidir. Ama mevcut kullanıcı tabanınız 1 milyar kişiyse, mümkün olduğunca bir şeyleri bozmamak çok akıllıcadır ve kullanıcı açısından sadece çalıştığı için sistem düzeyinde gerçek bir değer de üretir. Sonuçta tavır şu olmalı: erken başarısız ol, ama çok sayıda şeyi başarısız hale getirme
  • Bu durumda mevcut API'lerden birinin belgelenmiş bir hatası yok, dolayısıyla baştan hata işleme de olmayabilir. Mevcut yazılımların hepsini bozmak istemiyorsanız iyi niyetli bir yalan söylemeniz gerekir
    Bu, API'den çok ABI kararlılığına yakın bir konu. Windows'ta 15 yıl önce derlenmiş yazılımlar da mümkün olduğunca yeni işletim sistemlerinde çalışmaya devam etmelidir. Fonksiyon imzasını değiştiremezsiniz; bu yüzden artık anlamı kalmamış API'leri bile çalışır tutmak için iyi niyetli yalanlar söylemek gerekir
    Örneğin API hâlâ Active Desktop varmış gibi davranır. Çünkü alternatif, çok sayıda eski yazılımı kırmaktır
  • Kesinlikle katılıyorum. Herhangi bir nedenle benim ekranımda görünmeyen ama yanımda anlatan kişinin ya da eğitim içeriğinin ekranında görünen bir düğmeyi arayıp durmak kadar sinir bozucu bir şey yok
    Özelliğin kaldırılıp kaldırılmadığını mı, yoksa bu arada başka bir ekranın altına mı gömüldüğünü anlayamıyorsunuz
  • Uygulamanın hataları yakalayıp kullanıcıya göstermesi gerektiği doğru.
    Ama uygulama bunu yapmazsa, o uygulamayı kullananlar uygulamayı değil Windows'u suçlar. Hatta uygulama çökse bile yine Windows'u suçlarlar
    Bu yüzden Microsoft geçici çözümler üretiyor. Yazdırma işinin sessizce yok olmasına izin vermek çok daha kolay; kullanıcı da kısa bir duraksamadan sonra “aa doğru ya, yazıcı yoktu” deyip durumu kabulleniyor
• Yazıcı kurulum fonksiyonu hemen dönüp sonuç kodu olarak kullanıcı işlemi iptal etti döndürebiliyorsa, uygulama desteği açısından bu neredeyse kesin olarak, yazdırma API'sinin en baştan istisna fırlatmasından daha zor yönetilen ve istenmeyen davranışlara yol açar
• Son zamanlarda çok fazla AI destekli programlama yapıyorum ve ajanın sık sık null olup olmadığını kontrol eden if denetimleri eklediğini görüyorum. Bunu her gördüğümde bu yazı aklıma geliyor
  Bu yüzden ajana null denetimlerini tekrar tekrar eklememesini, bunun yerine zararsız fonksiyonlar kullanmasını ve değerin asla null olmadığını bildirim anında bir kez doğrulamasını söyledim

[GN⁺]

Hacker News yorumları

• Bunu hataları yutma biçimi olarak öğrendim ve kötü bir pratik olduğunu düşünüyorum.
  Xbox’ta yazdırma yapılamaması gibi gerçek bir sorunu çözmediği gibi, yazılımın ne kadar bozuk olduğunu gizleyerek hata bulmayı ve test etmeyi çok daha zorlaştırır.
  Go’daki panic bence iyi; çünkü çalışma zamanında kötüye kullanılsın ya da kurtarılsın diye değil, test aşamasında programcının yanlış yaptığını yüksek sesle haber veren bir siren olarak tasarlanmıştır.
  Bir sistemdeki aktörler kendi kusurlarını ya da hatalarını aktif biçimde gizlediğinde, nedeni bulup düzeltmek üstel ölçüde zorlaşır.

  • Hata tasarımı bağlama göre değişir.
    Benim çalıştığım B2B, mikroservis ve API odaklı sistemlerde, belirtim dışı istekleri hızlıca başarısız kılmak doğru yaklaşımdır.
    Ama Windows uyumluluk uğruna inanılmaz derecede geriye doğru esnedi; SimCity gibi bozuk ama ünlü yazılımları bellek yamalarıyla bile yaşattığı örnekler var: https://arstechnica.com/gadgets/2022/10/windows-95-went-the-...
    Kullanıcının sistem kodunu düzeltemediği masaüstü ortamlarında, çoğu durumda son kullanıcı deneyimi doğruluktan daha önemlidir.
    BSOD’un neden çıktığı önemli değildir; Microsoft’un öğrendiği şey, kötü yazılım ya da donanım yüzünden Microsoft’un itibarının zarar gördüğüdür.
    Kişisel olarak hatalı girdi ya da koşullarda hızlı başarısız olan veya duran tasarımları tercih ederim, ama bu ortamda bu yaklaşımın değerini de anlayabiliyorum.
    Önemli olan bağlamdır; taraflardan birini dogmatik biçimde uygulamak değil.
    Örneğin Chen’in yaklaşımını bir nükleer reaktör ya da ultra düşük gecikmeli alım-satım tasarımına taşıyamazsınız; ama bir oyun motoru için harika bir yaklaşım olabilir.
  • Yeni bir platform için alternatif çalışma zamanı tasarlarken kilit nokta, neyi hata sayacağınıza kendiniz karar vermenizdir.
    Çalışma zamanı bileşenini “zararsız biçimde pasif” bırakıp bırakmama sorusu, uygulamanın panic üretip üretmeyeceğinden önce gelen bir tasarım kararıdır.
    Bu durumda “Xbox’ta yazdırmak” ifadesinin ne anlama geldiğini belirlemek Microsoft’a düşer.
    Bunu hata olarak tanımlayabilir ya da teorik olarak ileride desteklenebilecek, fakat şu anda gerçekten nasıl yapılacağı olmayan bir özellik olarak tanımlayabilir.
    USB yazıcı takılırsa ve Gameboy’un GB Printer’ı destekleyen oyunlarındaki genişleme portu gibi, bir “oyun” yazdırmanın yolunu biliyorsa, teoride Xbox’ta da yazdırmak mümkündür.
    Bir Xbox oyununun yazdırmayı denemesi mutlaka özü itibarıyla hata değildir; bunu hata olarak tanımlamak da uygulama taşınabilirliği gibi ödünleşimleri olan bir tercihten ibarettir.
    Xbox’ta seçilebilecek yazıcı bulunmayan bir seçim ekranı gösterebilir, API’ye yazdırmış gibi yalan söyletebilir ya da gerçekten yazdırmayı destekleyebilirsiniz.
    Ancak “Xbox’ta yazdırma”nın anlamını hata olarak tanımladıktan sonra, o hatanın fırlatılmayıp yutulması bir uygulama ya da hata ayıklama sorunu hâline gelir.
  • Bu hataları yutmak değil; Linux tarzı bir ifadeyle kullanıcı alanını bozmamaya daha yakın.
    Olası iki işlem var: makinede asla yazıcı olmayacağı için hata vermek ya da makinede asla yazıcı olmayacağı için boş bir yazıcı listesi döndürmek.
    İkisi de geçerli, ama kullanıcı alanını bozmayan yalnızca biri.
  • Yazıyı okuduğunuzda, geliştirici deneyiminden çok kullanıcı deneyiminden söz ettiğini görüyorsunuz.
    “Sireni yüksek sesle çalmak” testçiler ya da geliştiriciler için iyidir, ama son kullanıcı için pek iyi değildir.
    Son kullanıcı açısından hatayı yutmak, uygulamanın çökmesinden daha iyidir.
  • İnternet bağlantısı başarısız olduğunda onlarca yıldır sadece başarısız olduğu mesajının çıkması sinir bozucu.
    Neyin başarısız olduğunu bilemiyorsunuz: benim bilgisayarımdaki yazılım mı, donanım mı, Ethernet kablosu ya da Wi‑Fi mı, switch mi, yönlendirici mi, kablo modem mi, eve gelen internet kablosu mu, ISP mi, yoksa bağlanmaya çalıştığım uzak sistem mi; bu konuda hiçbir iyileşme olmadı.

• Olumsuz tepki verilmesi beklenir, ama Word ’97 belgesine ya da 30 yıl önce MS-DOS için derlenmiş bir oyuna tıkladığınızda beklediğiniz gibi açılmasının nedeni tam da bu tür kirli işlerdir.
  Geriye dönük uyumluluk her zaman messy’dir; ya kusurlu biçimde yapılır ya da hiç yapılmaz.

  • Microsoft hakkında bu nakaratı sık duyarım, ama oyunlarda pek şanslı olmadık.
    Sonunda GOG kullanıyorsunuz; GOG da nihayetinde ortamı sanallaştırıyor.
    Örneğin orijinal Sim City’yi Windows 11’e kurup başarılı olacak kimse çıkacağını sanmıyorum.
  • Word ’97’de yazılmış bir dosya 25 yıl önce bile iki farklı bilgisayarda tam beklendiği gibi açılmıyordu.
    Biçimlendirme kurulu yazıcı sürücüsüne bağlıydı.
    Buna karşılık 35 yıl önceki LaTeX dosyaları bugün hâlâ gayet iyi çalışıyor.
  • 1997’den kalma bir dosya olsa bile şansınızın yaver gitmesi gerekir; hangi ofis uygulamasında açarsanız açın, büyük olasılıkla yanlış görünecektir.
    Word, aynı bilgisayarda ve aynı sürümde yeniden açtığınızda bile biçimlendirmenin değişmeyeceğini garanti edemiyordu; bu yüzden TeX öğrenmeye başladım.
    Oyunlarda da Microsoft GFWL’i kapatınca sayısız oyunu bozdu.
    Orijinal Dark Souls, Steam’de yeniden yayımlanana kadar oynanamaz hâldeydi; korsan sürüm kullanmak gerekiyordu.
  • Güncel 64 bit Windows’ta MS-DOS yazılımları çalışmaz.
    “Desteklenmiyor” iletişim kutusu çıkar; dosbox indirebilirsiniz ama bu “tam olarak beklediğiniz gibi” değildir.
  • Keşke bu doğru olsaydı, ama çocukluğumdan sakladığım oyunları çalıştırmak için çok uğraştım.
    Neredeyse her seferinde ya vazgeçtim ya da GOG’dan yeniden satın aldım; aslında uyumluluk sorunlarını çözmüş bir çalışmaya para ödemiş oldum.

• UI’ın, gerçekte var olabilecekmiş gibi ima ettiği ama şu anda yok dediği cihaz arayüzü kadar sinir bozucu bir şey yok
  Sonunda zaman harcayıp o cihazların desteklenmediğini ve o ekranın yalnızca birinin hazırladığı bir mockup olduğunu anlamanız gerekiyor

  • Yine de bu, uygulamanın doğrudan çökmesinden daha az sinir bozucu olur
    Uygulama yazdırmanın desteklenmediği duruma hazırlıklı değilken yazdırma bir istisna fırlatırsa, uygulama muhtemelen olduğu gibi çöker
    Yazdırmanın desteklenmemesi durumuna hazırlıklı bir uygulama, açık bir API ile önce yazdırma desteği olup olmadığını kontrol etmeli ve desteklenmiyorsa yazdırma UI’ını göstermemelidir
    Yazı böyle bir uygulamadan değil, önce kontrol etmeyen uygulamaların nasıl ele alınacağından bahsediyor
    Hata uygulamada olsa da iyi bir platform, kötü uygulamaların doğrudan çökmesine izin vermek yerine onları mümkün olduğunca çalışır tutmaya çalışmalıdır
  • Burada sorumluluk Microsoft’tan çok, yazılımı yazan kişinin yazıcı durumunu ele almamasında olabilir
    Microsoft’un rolü, yazılım sağlayıcısı yazıcıyı düşünmedi diye uygulamanın çökmesini engellemektir

• Bir uygulama yazdırmaya çalıştığında kullanıcıdan yazıcı seçmesini isteyip boş bir liste göstermek... Microsoft 30 yıldır öğrenememiş gibi: https://www.reddit.com/r/hacking/comments/djvzd/windows_nt_l...

• Yazıda önerilen somut yön, yani kullanıcı acı çekmeden önce bileşenin acı çekmesi gerektiği sözü doğru; ama çerçeveleme çok rahatsız edici
  “API’nin hiçbir şey yapmamasını sağlamanız gereken zamanlar vardır”, “yazdırma fonksiyonunun NotSupportedException fırlatması yanlıştır” gibi ifadeler kesinlikle genel tavsiye değildir
  Bu, berbat istemcileri desteklemek için yapılmış bir hack’tir; bazen gerekli olsa da normal ya da genelleştirilebilir bir tavsiye değildir
  Bu tür ifadelerde, bir Microsoft geliştiricisi olarak yaşanan acıyı içselleştirmenin izleri görülüyor

  • Berbat bir istemci değil; sizin bu değişikliğe karar vermenizden önce yazılmış bir istemci
    İstemci değişmemişken API onu bozuyorsa, berbat olan istemci değil API’dir
  • Bir yazılım platformu azımsanmayacak sayıda geliştirici tarafından benimsendiyse berbat uygulamalar da kaçınılmaz olarak ortaya çıkar; o zaman da böyle şeyler yapmak gerekir
    Yaygın biçimde benimsenmiş ve geriye dönük uyumluluğu ciddiye alan her platform için bu tamamen normal ve genelleştirilebilir bir iştir
    Windows bunun başlıca örneğidir, ama Linux kernel ABI’sinde, glibc’de, web platformunda, Java’da vb. de aynı şey yaşanır
  • Mevcut istemcilerin zaten kullandığı bir API’yi uygulamanız gereken zamanlar olur
    Zamanı geri alıp istemcileri yeniden derleyemez ya da yeniden yazamazsınız
    İstemci zaten NotSupportedException kontrol ediyorsa onu döndürmelisiniz; ama etmiyorsa başka bir yaklaşım gerekir
  • Windows ekibindeyken böyle bir tavır sergileseydiniz, yönetici olsam belki de sizi işten çıkarırdım
    Burası Windows
    Kullanıcıların bağımlı olduğu uygulamaları bozamazsınız
    “Berbat” ya da yanlış çalışan istemci uygulamalar varsa, beklenildiği gibi çalışmalarını sağlamak için gerekli tüm workaround’ları, shim’leri ve uyumluluk hack’lerini kullanmalısınız
    SimCity’nin çalışması için özel bellek yönetimi kodu eklemeniz gerekse bile aynı şey geçerlidir
  • O “berbat istemci” uzun zaman önce kapanmış bir şirket tarafından yazılmış olabilir
    Müşteriniz o istemciye bağımlıdır ve sizin yaptığınız değişiklik yüzünden durursa sizi suçlayacaktır

• Burada herkes “hiçbir şey yapmama” ve “hata işleme” konularına takılıyor, ama yazı sanki tüm sorunları yutup kumbaya söyleyelim demiyormuş; bunu iyi açıklayamamış gibi
  Asıl bağlam, değişmeyecek yazılımlar için emülasyon ve uyumluluk; bu da çoğu durumdan çok farklı
  Microsoft’un kendisi de bu ikisi arasındaki sınırı sık sık bulanıklaştırdığı için daha da kafa karıştırıyor, ama burada bahsedilen şey genel hata işleme değil
  Emülasyon özünde yalan söylemektir
  Xbox’a gerçekten yazıcı bağlamanın bir yolu yoktur; Linux üzerinde Windows oyunu çalıştırıyorsunuzdur; sahte iPhone aslında AWS’deki bir ARM sunucusu olabilir
  Yalan söyleyecekseniz bunu inandırıcı biçimde yapmalısınız; böylece mevcut uygulamalar çalışmaya devam eder
  Microsoft mevcut Windows uygulamalarının Xbox’a port edilebileceğini söylediğinde, Windows uygulamalarına yazdırabilecekleri vaadi vardı; dolayısıyla Xbox bunun mümkünmüş gibi görünmesi için yalan söylemelidir
  Buna karşılık bir program use-after-free yapıyorsa ve siz sessizce, sanki hata yokmuş gibi etrafından dolanıyorsanız bu doğru bir işlem değildir
  Çünkü kimse mevcut use-after-free hatalarının bile yeni platformda hata düzeyinde uyumlu olacağını vaat etmedi

  • Yazının hiçbir yerinde değişmeyecek yazılımlar için emülasyon yapıldığına dair bir bağlam yok
    Bu, istediğiniz pozisyonu desteklediği için varsaydığınız bir yorumdan ibaret
    Aslında yazıdaki içerik, yarın Xbox için bir program yazıp yazdırmaya çalıştığımda da aynen geçerli
    Bu davranışın yalnızca eski ve bakımı yapılmayan yazılımlar için geçerli olduğunu ayıran bir şey yok

• Bu yaklaşımı hem seviyorum hem de sevmiyorum
  İçgüdüsel olarak sorunları kötü niyetli uyum yoluyla ele almayı sevmem
  Öte yandan amaç, yazdırma bozuk olsa bile daha fazla kullanıcının platformda daha fazla yazılım çalıştırmasını sağlamaksa bunun iyi bir karar olduğuna tamamen katılıyorum

• Bu yorum akışı tuhaftı
  Microsoft’un yaptığı her şeyden nefret eden insanların kesinlikle olduğu anlaşılıyor
  Blogun ana fikri, uygulamaları (UWP) XBOX’a getirme sürecini sürtünmesiz hâle getirmek
  Yeniden derleme olmadan, dağınık ifdef’ler olmadan, ek iş olmadan uygulamanın “sadece çalışmasını” sağlamak; ardından geliştirici uygulamayı XBOX platformuna göre uyarlayabilir
  Önemli olan, geliştiricinin hiç çaba harcamadan uygulamayı XBOX’a getirebilmiş olmasıdır; bu hem platform hem de geliştirici için iyidir
  Kullanıcı açısından yazıcı listesinin boş olması, yazdırmanın mümkün olmadığına dair açık bir sinyaldir
  Hepsinden önemlisi, uygulama çökmez ya da “Bir sorun oluştu. Lütfen daha sonra tekrar deneyin” gibi en kötü türden bir hata göstermez
  Bu mesaj daha iyi bir kullanıcı deneyimi değildir
  Geliştirici uygulamayı yeniden derleyip daha açıklayıcı bir mesaj koyabilir, ama o zaman başa dönmüş oluruz

  • Bu thread’in %95’i yazıyı anlamamış gibi
    Örneğin hataları yutma suçlaması meselenin özüyle hiç ilgili değil

• Bu yazıyı eleştirenlerin kaçırdığı temel nokta, burada istisna fırlatılması gereken istisnai bir durum olmadığıdır.
  Bu cihaza bağlı bir yazıcı yok; bu durumda tanım gereği böyle olduğu için uygulama bu durumu düzgünce ele almalı, çökmemeli.
  Bir dizüstü bilgisayar yazıcıya erişemiyor diye istisna fırlatmaz.

  • Yazıcı kullanılabilirliğini yanlış ele alan, yaygın kullanılan Microsoft dışı bir üründen güncel bir örnek istiyorsanız gnome-control-center var.
    Ayarlarda bir yazıcı ekledikten sonra kurulum sırasında “Color Profiles” sekmesine geçerseniz, zamanlama denk geldiğinde gnome-control-center çöker.
    Daha yakından bakınca, kullanılabilir yazıcıları listelemeye çalıştığını; bir yazıcının olması gerektiğini bildiğini ama bilgiler henüz mevcut olmadığı için olduğu gibi çöktüğünü görürsünüz.
    Neyse ki GNOME yazıcı kurulumunu bitirene kadar birkaç saniye bekleyip ayarları yeniden açmanız yeterli.
    Yine de farklı geçmişlere sahip son kullanıcıların masaüstünü düzgün kullanmasını sağlayan temel bir uygulama, ideal bir dünyada asla çökmemeli.
    Sınır koşullarını düşünmek zordur; sınır koşullarını ele almanın kendisinin de başka sınır koşulları olduğunu hayal etmek daha da zordur.
    Haklı ya da haksız, en azından yazar “kötü bir uygulama, Wayland’i destekleyecek şekilde yeniden yazılmalı” demekten daha derin düşünüyor.

• Bir zamanlar tarayıcıların, HTML kodunda hata olsa bile sayfayı göstermek için elinden geleni yapması harika bir strateji sayılıyordu.
  Yazarın niyetini olabildiğince tahmin edip devam etmek; hataların kötü olduğu ve kullanıcıların hata istemediği varsayımıyla hareket etmek gibi.
  Bu deneyimden ders aldığımızı sanıyordum, ama öyle değilmiş gibi görünüyor.

  • Tarayıcılar hâlâ bu stratejiyi izliyor.
    Bunu katı doğrulamayla değiştirmeye çalışan XHTML girişimi başarısız oldu; onun yerine başarılı olan HTML5, geriye dönüp mümkün olan tüm hatalı dizilerin nasıl yorumlanması gerektiğini açıkça tanımladı ve tarayıcıların en azından tutarlı davranmasını sağladı.
  • Tarayıcıların girdiye hoşgörülü olması sayesinde modern web mümkün oldu.
    İlk tarayıcılar daha önce görmedikleri bir etiketle karşılaşır karşılaşmaz hata gösterseydi, yeni tarayıcı özellikleri doğar doğmaz boğulup kalırdı.
  • Hello ve World! yazıp, edindiğimiz bilgelik sayesinde artık hata çıkıp çıkmadığını görebiliriz.
    Ama hâlâ düzgün render ediliyorsa, bu ya öğrenecek daha çok şeyimiz olduğu ya da belirli türdeki hataları zarifçe ele alıp istisnai durumlarda çökmenin de bir anlamı olduğu anlamına gelebilir.
  • Son 20 yılda yazılımın gelişimi, LLM’ler hariç pek de harika değildi; LLM’ler de sansürle mahvedildi.
    1999’a ışınlansak pek de özleyecek bir şeyim olmaz gibi geliyor.
  • Ne öğrendiğimizi düşündüğümüzü merak ediyorum.