Yazılım Hayal Kırıklığı
(tonsky.me)- Modern yazılım, donanımdaki ilerlemeyi verimlilik, sadelik ve olgunluk olarak geri vermek yerine, “bilgisayar zaten yeterince hızlı” varsayımına yaslanarak verimsizliği normalleştirdi
- Web’de kaydırma, Google Inbox’ta bir e-postayı açmanın 13 saniye sürmesi, Windows 10 güncellemelerinin 30 dakika alması, metin editörlerinde yazı giriş gecikmesi gibi temel işler bile beklenenden yavaş hissettiriyor
- Android sisteminin 6GB olması, Windows 10’un 4GB olması, Google Keyboard’un 150MB yer kaplaması ve Electron uygulamaları ile Slack örnekleri; uygulama ve platformlardaki şişmenin performans, karmaşıklık ve güvenilirlik maliyetine yol açtığını gösteriyor
- OS, uygulama ve tarayıcı güncellemeleri ile iOS 11’in 32 bit uygulama desteğini kaldırması gibi değişiklikler yüzünden, bir zamanlar iyi çalışan yazılımlar da zamanla yavaşlayabiliyor veya bozulabiliyor
- Daha iyi yazılım yapmak için mühendislerin kendi kurdukları sistemlerin performansını, yapısını ve sınırlarını anlaması; daha az kaynakla daha hızlı ve öngörülebilir sonuçlar üretmesi gerekiyor
Performansı israf eden yazılım
- Modern yazılımın, mümkün olan performansın %1’i hatta %0,01’i ile çalışsa bile kabul edilebilir görüldüğü durumlar çok yaygın
- Otomobiller, binalar ve uçaklar fiziksel sınırlarına ya da ideal biçimlerine yaklaşırken, yazılım verimsizliği “bilgisayar zaten yeterince hızlı” sözüyle meşrulaştırıyor
- “Programcının zamanı bilgisayarın zamanından daha pahalıdır” özdeyişi, bilgisayar zamanının eşi görülmemiş ölçüde israf edildiği gerçeğini perdeleyebiliyor
- Her gün çalıştırılan bir Python programını Rust ile yeniden yazarak süreyi 1,5 saniyeden 0,06 saniyeye düşürmek mümkün olsa da, 6 saatlik emeğin geri dönüşünün 41 yılı aşması gerektiğini söyleyen tweet, verimlilik tartışmalarının simge örneklerinden biri olarak kullanılıyor
Katlanılamayacak kadar yavaş temel deneyimler
- En yeni taşınabilir bilgisayarlar Ay’a iniş döneminin bilgisayarlarından binlerce kat güçlü olsa da, en yeni MacBook Pro’da bile web sayfalarını 60fps ile akıcı kaydırmak zor
- Google’ın yaptığı Inbox, Google Chrome içinde tek bir e-postayı açmak için 13 saniye istiyor
- İçerik yerine boş beyaz kutuları animasyonla göstermek, web sayfalarının ulaşabildiği performans sınırına verilmiş bir tavize benziyor
- 120Hz ekranların yaygınlaştığı bir dönemde bile, web topluluğundaki tek bir yanıtı görüntülerken 60Hz’in dahi istikrarlı olmadığını savunuyor
- Windows 10 güncellemeleri 30 dakika sürüyor; o sürede SSD’yi biçimlendirip yeni bir build indirerek tekrar tekrar kurulum yapmak bile mümkün deniyor
- Modern metin editörleri, 42 yıllık Emacs’tan daha fazla giriş gecikmesine sahip
- Her tuş vuruşunda yalnızca küçük bir dikdörtgen alanı yenilemek gereken bir işin bile 16ms içinde tamamlanamadığı eleştiriliyor
- Oysa 3D oyunlar aynı 16ms içinde tüm ekranı render ediyor, girdiyi işliyor, dünya hesaplarını yapıyor ve kaynakları yönetiyor
- Daha hızlı donanım, daha iyi yazılım üretmekten çok, aynı işi daha yavaş yapan yazılımları çalıştırmak için kullanılır hale gelmiş durumda
Şişmiş uygulamalar ve platformlar
- Web uygulamaları yalnızca reklamlar engellense bile 10 kat hızlanabiliyor; AMP de yeni bir teknoloji olmaktan çok, şişkin kısımları kaldırmaya yönelik sağduyulu bir çözüm gibi görülüyor
- Android sistemi hiçbir uygulama olmadan bile 6GB; Windows 95 30MB iken Windows 10 4GB
- Windows 10, Windows 95’ten 133 kat büyük olmasına rağmen temel işlevleri çok da farklı sayılmıyor
- Android ise Windows 10’dan bile 1,5 kat daha büyük
- Google Keyboard tipik olarak 150MB, Google uygulaması 350MB, Google Play Services ise 300MB yer kaplıyor
- Google Keyboard yalnızca ekranda otuz kadar tuş çizen bir uygulamayken, tüm Windows 95’ten 5 kat daha karmaşık olup olmadığı sorularak eleştiriliyor
- Google Play Services kullanılmasa bile silinemiyor
- Varsayılan uygulamalar kurulduktan sonra fotoğraflar için yalnızca yaklaşık 1GB alan kalması, işletim sistemi, uygulamalar ve verilerin tek bir disket üzerinde tutulduğu dönemle karşılaştırılıyor
- Electron tabanlı bir Todo uygulaması; Xbox 360 denetleyici sürücüsü, 3D grafik render etme, müzik çalma ve web kamerası çekimi gibi işlevleri bile içinde barındırabiliyor
- Slack, sohbet ve basit bir metin editörüne yakın bir uygulama olmasına rağmen, yükleme süresi ve bellek kullanımı nedeniyle ağır uygulamalar sınıfına giriyor
- Uygulamalar büyüdükçe kontrol kaybı, karmaşıklık maliyeti, performans kaybı ve güvenilirlik borcu artıyor; gereğinden ağır uygulamaları normal kabul etmemek gerekiyor
Zamanla çürüyen yazılım
- Üç yıl önce 16GB’lık bir Android telefon yeterliyken, Android 8.1 döneminde uygulamalar özel bir gerekçe olmadan iki kat büyüyerek kullanımı zorlaştırdı
- iPhone 4s, iOS 5 ile tanıtıldı ama iOS 9’u çalıştırmakta zorlanıyor; ayrıca iOS 9’un temelde çok daha üstün olduğu da söylenemiyor
- iOS 11, 32 bit uygulama desteğini kaldırarak geliştiricisi kalmamış ya da güncellenmeyen uygulamaların tamamen kaybolmasına yol açabiliyor
- 1980’lerden kalma DOS programları birçok bilgisayarda değişiklik olmadan çalışabilirken, JavaScript uygulamalarının bir sonraki Chrome güncellemesinde bile bozulabileceğini söyleyen bir tweet alıntılanıyor
- Bugün sorunsuz görünen bir web sayfası bile 10 yıl içinde hiçbir tarayıcıda düzgün çalışmayabilir
- Aynı işi yapmak için yeni telefonlar ve yeni MacBook’lar alınıyor ama sonuçta aynı uygulamalar daha yavaş çalışıyor
Düşen kalite beklentisi
- Web sayfaları bir sorun çıktığında nedenini incelemek yerine kullanıcıdan sayfayı yenilemesini istiyor
- Web uygulamaları, uyumlu tarayıcılarda bile “rastgele” JavaScript hataları üretebiliyor
- Web sayfası ve SQL veritabanı tasarımının, render edilmiş bir web sayfası görüntülenirken verinin değişmeyeceği umudu üzerine kurulduğu eleştiriliyor
- Ortak çalışma özellikleri çoğu zaman “elimizden gelen bu” düzeyinde kalıyor ve veri kaybına yol açabilecek gündelik senaryolar barındırıyor
- “Hangi sürüm korunsun?” gibi diyaloglar, aslında çalışmalardan hangisinin yok edileceğini seçmek anlamına gelebiliyor
- Linux, süreçleri keyfi biçimde öldürebilen bir tasarıma sahip olsa da sunucularda en popüler işletim sistemi
- Dell monitör, AirDrop ve Bluetooth örnekleri; cihazların içindeki yazılım ile karmaşık spesifikasyonların, düzenli reset ya da şansa bağlı deneyimler yarattığını gösteriyor
- Kararlı çalışan bir şey teslim etmek için yapılan şeyi içten ve dıştan anlamak gerekir; ancak aşırı şişmiş sistemlerde bu çok zor
Programlama araçları ve geliştirme pratiklerindeki karmaşa
- Paket yönetimi, build sistemleri, derleyiciler, dil tasarımı ve IDE gibi temel öğelerde bile hızlı, verimli ve uzun ömürlü bir olgunluk görmek zor
- Build sistemleri, tüm değişiklik bilgisini ellerinde tuttukları halde düzenli olarak her şeyi silip yeniden başlatmayı gerektiriyor
- Bunu güvenilir, öngörülebilir ve yeniden üretilebilir hale getirmemek için bir neden olmadığı savunuluyor
- NPM’nin yıllarca “bazen çalışıyor” düzeyinde kaldığı söyleniyor
rm -rf node_moduleskomutunun Node.js/JavaScript geliştirmede kaçınılmaz görünmesini anlatan bir tweet alıntılanıyor
- Derleyiciler ile ön/son işleme aşamalarının dakikalar hatta saatler sürmesinin kabul edilmesi, “programcının zamanı önemlidir” iddiasıyla çelişiyor
- Hadoop’un tek bir PC’de çalıştırmaktan bile yavaş olduğu halde tercih edildiği örnekler, programcıların her zaman rasyonel kararlar vermediğini gösteriyor
- Makine öğrenimi ve “yapay zeka”, yazılımı güvenilir olmayan tahminler çağına taşıdığı gerekçesiyle eleştiriliyor
- “Yapay zeka” ya da “machine learning” içeren uygulama ve servisleri, güvenilmez, öngörülemez ve sonucu açıklaması zor sistemler olarak okuduğunu söyleyen bir tweet alıntılanıyor
- Linux üzerine VM kurup, VM içine Docker koymak; programları, dilleri ve çalışma ortamlarını temiz biçimde yönetmeyi bilmediğimizin işareti olarak yorumlanıyor
- Go’nun tek bir çalıştırılabilir dosya üretmesinin başlıca avantaj sayılması, ortalığın dağınık olmamasının bile başarı kabul edildiğini gösteriyor
- Bağımlılıklar, basit problemleri “tam paket çözüm” ile ele almaya çalışırken beraberinde edinim maliyeti ve yeni bağımlılıklar getiriyor
- Programları yeniden başlatmadan yıllarca çalıştırmak zor; bazen birkaç gün bile zor olabiliyor
- Süreç yeniden başlatma, veritabanını yeniden ayağa kaldırma, uygulamayı 20 dakikada bir yeniden başlatan watchdog’lar, yinelenen kaynaklar ve sıkıştırılmış aktarım; düzeltmek yerine hızlıca geçiştirme yöntemleri olarak görülüyor
- Bu pratiklerin mühendislik değil, tembel programlama olduğu; mühendisliğin ise yapılan şeyin performansını, yapısını ve sınırlarını derinlemesine anlamak anlamına geldiği savunuluyor
Birikmiş karmaşıklık ve piyasanın ilgisizliği
- Güncel yazılım, zar zor çalışan kodların üzerine yine zar zor çalışan kodların yığıldığı bir durumda; sürekli büyüyor, karmaşıklaşıyor ve değiştirme fırsatı azalıyor
- Sağlıklı bir ekosistem zaman zaman geri çekilip sonra ilerlemeyi gerektirir; ancak 25 yıldır yeni bir OS çekirdeği görülmediği ve artık yeniden yazmak için fazla karmaşık hale gelindiği söyleniyor
- Tarayıcılar da edge case’ler ve tarihsel sorunlar nedeniyle layout engine’i sıfırdan yeniden yazmayı zorlaştırıyor
- Bugünün ilerlemesi, monolit sorunlarını çözmek için microservices, microservices sorunlarını çözmek için Docker, Docker sorunlarını çözmek için Kubernetes eklemek; yani ateşe yakıt dökmek gibi görünüyor
- XML tabanlı bildirimsel yapılandırmadan YAML tabanlı microservices yapılandırmasına geçildiği, ama eski XML’in en azından bir şeması olduğunu söyleyen bir tweet alıntılanıyor
- Kullanıcılar mühendislerin sunduklarını kabullenmek zorunda; 350MB’lık Android uygulamaları, takılan kaydırma deneyimi ve “çalışmıyorsa yeniden başlat” yaklaşımı karşısında neredeyse seçenek yok
- Rakip ürünlerin hepsi de yavaş, büyük ve düşük kaliteli olduğunda rekabet baskısı oluşturmak zorlaşıyor
- iPhone/iOS ile diğer akıllı telefonlar ya da Chrome ile diğer tarayıcılar gibi zaman zaman gerilim yaratan ürünler çıksa da bunun kalıcı olmadığı düşünülüyor
- Mühendislerin görevi, modern bilgisayarlarla performans, güvenilirlik, kalite ve erişilebilirlik açısından nelerin mümkün olduğunu göstermek olmalı
Yine de görünen alternatifler
- Martin Thompson’ın LMAX Disruptor, SBE ve Aeron projeleri; etkileyici, sade ve verimli örnekler olarak gösteriliyor
- Raph Levien’in Xi editor projesi, doğru ilkeler gözetilerek yapılmış bir çalışma olarak değerlendiriliyor
- Jonathan Blow, kendi oyunu için bir dil geliştirdi ve kendi dizüstü bilgisayarında 500 bin satır kodu 1 saniyede baştan sona derleyebiliyor
- Bu, artımlı build ya da ara cache değil; tam bir fresh compile sonucu
- Hızlı program yazmak için dahi ya da sihirbaz olmaya gerek olmadığı; yalnızca modadaki toolchain gibi devasa çöp yığınlarının üstüne inşa etmemek gerektiği savunuluyor
Daha iyi yazılım için talepler
- Yazılım mühendisliği mevcut durumda kalmamalı, gelişmeli; aynı şeyi tekrar tekrar daha yavaş ve daha büyük biçimde üretmeye gerek yok
- Bugünkü geliştirme pratiği, ilerlemeden çok, yıpranmış araçlar üzerinde iş hedeflerini zar zor karşılayan bir duruma benziyor
- Yerel optimizasyonlara saplanmanın sonucu olarak, şişkin ve verimsiz bir duruma alıştığımız söyleniyor
- Mühendisler daha iyi araçlarla, daha iyi uygulamaları katbekat daha az kaynakla, hızlı, öngörülebilir ve güvenilir biçimde yapabilir ve yapmalıdır
- Güvenilir, öngörülebilir ve yüksek kaliteli ürünler teslim etmek için neyin neden yapıldığını bütünüyle anlamak gerekir; “elimizde olan buydu” mazereti kabul edilemez
2 yorum
Bu yazının Türkçe çevirisi daha önce yayımlandı, onu okuyabilirsiniz.
https://tonsky.me/blog/disenchantment/ko/
Bağlantıyı doğrudan çeviri bağlantısıyla değiştirdim.
Hacker News yorumları
Daha küçük, daha temiz, daha az hatalı, güvenli, hızlı ve uzun ömürlü kod elbette mümkün. Bunu bilgi çağının ilk dönemlerinde yapabildiysek, onlarca yıllık deneyim ve güçlü araçlar varken bugün yapamamamız için bir neden yok.
Bunu yapmamamızın nedeni, orada para olmaması; hatta gerçek bunun neredeyse tam tersi. VC yatırımlı girişimler hayatta kalmak için pazara önce çıkmak zorunda, olgun kuruluşlarda bile maliyet ve şişkinlik bir sorun değil, yöneticinin prestijini büyüten bir işlev gibi çalışıyor. Sonunda maliyet müşteriye yansıtılıyor.
“Acımasız piyasa ilkelerinin” bu israfı düzeltmemesinin nedeni, daha iyi bir kod tabanı bir gün krallığın anahtarlarını ele geçirebilecek olsa da gerçek rekabet ortamının patolojilere ve trendlere fazla açık olması gibi görünüyor.
Ancak VC yatırımlı şirketlere göre daha kolay yapabildiğimiz şey, refaktörleme ve teknik borçla uğraşma için zaman ayırmak. Nitekim şu anda 45 gün boyunca yeni özellik geliştirmeye sert fren yapıp başlıca teknik sorunlarla ilgileniyoruz. Gelecek yıl satın alınmayı bekliyorsanız böyle yatırımlar yapmak zordur; teknik borç da başkasının sorunu hâline gelir.
Ürün geliştirilmeye devam ettiği sürece yeni hatalar ve sorunlar çıkmaya devam eder. “Mükemmel kod” ancak artık yeni özellik eklenmeyen kapalı bir bağlamda mümkündür.
VC yatırım modelinin sektörü bu noktaya sürüklediğini düşünüyorum. Girişimler milyonlarca dolar alıyor; yatırımcılara geri ödeme yapacak kadar hızlı para kazanmak zorunda oldukları için uygulamadan mümkün olduğunca çabuk para sıkmaları gerekiyor. ROI metriği iliştirilmeyen işler kimsenin ilgisini çekmiyor.
Temelde açık erişim, parola olmaması veya kısa parolalar, güvenli olmayan parola saklama, her şeyin düz metin olması, girdi temizlemeyi önemsememek, telnet gibi şeyler vardı.
Yazılımın daha şişkin hâle gelmesinin bir başka nedeni de burada. Etkileşimleri ve riskleri görmeye başladık; bir kez gördükten sonra görmemiş gibi yapamazsınız. Ele alınması gereken sınır koşulları azalmıyor, artıyor; desteklenmesi gereken donanım da çoğalıyor.
Performanslı kod yazma süreci iyileştirilebilir, ama aynı zamanda taban beklenti bizim ona yetişme hızımızdan daha hızlı yükseliyor. Artık tekrar parolasız yöne doğru yavaş yavaş gitmemiz de ilginç.
Refaktörlemeyi acı verici hâle getiren yüksek birim test kapsamı çoğu zaman özellik çıkarmayı engeller; bence bu, test güdümlü geliştirme fanatiklerinin kabul etmek istediğinden çok daha sık olur. Sektördeki birçok “en iyi uygulama”, ürün-pazar uyumunu zaten bulmuş ve parayı kendiliğinden basan şirketlerdeki insanların ürettiği gerçekçilikten uzak dogmalara daha yakın.
Hâlâ zar zor kullanılabilen bir HP MS200 all-in-one’ım var. 2017’de bir garaj satışından ucuza almıştım; Linux kurunca Chrome yüklendikten sonra Skype’ın web sürümüyle tam ekran görüntülü arama yapmak veya YouTube’u tam ekran izlemek bile mümkündü.
Yakın zamanda tekrar elime geçti; çocuk için bilgisayar yapmadan önce FC38 ve en yeni Chrome’u kurdum, YouTube videoları slayt gösterisine döndü. Ayarlarla ne kadar oynasam da olmadı; RAM’i 2 GB’tan 3 GB’a çıkarınca, 6 yıl öncekiyle aynı 720p tam ekran oynatma seviyesine geri döndü.
Aynı işi yapmak için belleğin 1,5 katına, yani 1 GB fazlasına ihtiyaç duyulur hâle gelmiş. 16 GB’ın minimum olduğu sözünü de anlıyorum, ama bu berbat makinede bile Chrome neredeyse boşta duran bir web tarayıcısıyken bellek ayak izini yaklaşık 30 GB gösteriyor. Bunun çoğu muhtemelen mmap edilmiş dosyalardır, ama yine de 30 GB.
Buna karşılık çoğu cihazda pil ömrünün artması, daha düşük sıcaklıklar ve daha küçük RAM/disk gereksinimleri bariz bir iyileşme. YouTube eski kodlanmış dosyaları sunucularda kopya olarak tutabilir, ama kullanıcıların çoğunun modern cihazlardan eriştiği bir durumda bu alan israfı olur.
Chrome’un RAM kullanımındaki artışın büyük kısmı sandbox mimarisinin gelişmesinden geldi. Paylaşılan bellek ve süreç alanları sandbox’tan kaçan saldırılarda kullanılabildiği için daha fazla izolasyon eklendi; Chrome’un her sekme ve eklenti için yeni, bağımsız bir süreç başlatması da büyük bir neden.
Günümüzde reklam engelleyicilerin de etkisi büyük. Web kötüleştikçe etkili reklam engelleyici yapmak zorlaştı ve daha fazla kaynak gerektirir oldu. Yavaş yazılım yalnızca insanları rahatsız etmek için yavaşlamış değildir; çoğu zaman tehlikeli hack’lerin iyi uygulamalara dönüştürülmesi ve gereksinimlerin değişmesi sonucudur. FLV artık yeterli değil; h264 de h265 ve AV1 yaygınlaştıkça 5 yıl sonra uzun süre dayanacak gibi görünmüyor.
Modern araç zincirleri “tekerleği yeniden icat etme”ye odaklanıyor, ama her bağımlılık tekerleğin farklı bir sürümünü seçtiyse, yalnızca birkaç bağımlılığı içeri çekmek bile aynı düşük seviye işlevin altı farklı uygulamasını getirebiliyor.
Ne var ki kurulu olan Flatpak’ti ve şişkinlik hissediliyordu. Neyse ki Chrome hâlâ RPM olarak doğrudan native kurulabiliyor ve gerçekten OS’nin paylaşımlı kütüphanelerini kullanıyor.
Bu yazı asıl acı nokta olan bug konusuna hiç değinmiyor bile. Neredeyse tüm yazılımlar mümkün olduğunca bug doluymuş gibi hissettiriyor. Yazılımı her olağandışı yoldan ya da normal dışı akışla kullanmam gerektiğinde tedirgin oluyorum ve neredeyse her seferinde başarısız oluyor
Kısa süre önce Carvana’ya araba satarken Chrome ile Firefox arasında gidip gelerek işi zar zor hallettim. Chrome’da görsel yükleme sihirbazı bir JS istisnası veriyordu; o kısım mucize eseri yalnızca Firefox’ta çalıştı, ama sitenin geri kalanı Firefox’ta test edilmediği apaçık belli olacak kadar sorunluydu
Daha kötüsü, teknik olmayan kullanıcılar bir bug ile karşılaştığında suçu kendilerinde sanıyor. Şişkin ve yavaş olsa bile kararlı ve sağlam bir yazılıma artık seve seve razı olurum
Öte yandan, her şeyin ne kadar bug dolu olduğunu görmeye devam ediyorum; gerçekten daha mı bug’lı hale geldi, yoksa iç yüzünü öğrendikçe ve yaşlandıkça büyük şirket usulü yazılım geliştirmeye tahammülüm mü azaldı, bilmiyorum. Apaçık UX bug’ları kolayca yakalanabiliyorken “X özelliğini hemen çıkarın” diyen hayali ürün yöneticisine sinirleniyorum
Maliyet, fırsat maliyeti, pragmatizm gibi argümanları anlıyor ve kısmen katılıyorum; ama bazen yarım yamalak inşa edilmiş bir dünyada yaşamayı öylece kabullendiğimiz hissinden kurtulmak zor oluyor
Bugün de daha iyi olmuş gibi görünmüyor. Küçük çocukların eline telefon ya da dizüstü bilgisayar geçtiğinde, sadece düğmelere çok hızlı ya da beklenmedik sırayla basarak modern cihazları oldukça güvenilir biçimde takılmaya, donmaya ve çökmeye sürükleyebiliyorlar. Fiziksel olarak bozmuyorlar bile; modern teknolojinin durumu bu
Neden düzeltilmediğini anlıyorum. İnsanlar ara sıra yeniden başlatma gerekeceğini bekler hale geldi; böyle durumlarda suçu çocuğa atmak kolay ve yeniden başlatınca çözülüyor. Yine de işletim sistemi yaşam döngüsüne bakınca artık daha iyi olmasını umardım
C hakkında yazdığım yazıda söylemedim ama C kullanmamın büyük nedenlerinden biri, yazılımı şişkin hale getirmenin zor olması. Özellik ekleyebilirsiniz, ama tek bir özelliğin çalıştırılabilir dosyaya 100KB eklemesi bile kolay değildir
Şu anda ücretli bir işte çalışmıyorum ama “iş” için güçlü bir makine kullanıyorum. Buna rağmen IDE yerine Neovim ve tmux kullanıyorum; sıradan bir Linux dağıtımı değil, epey değiştirilmiş Gentoo kullanıyorum; systemd yerine OpenRC, tam bir masaüstü ortamı yerine de Qtile adlı döşemeli pencere yöneticisini kullanıyorum
Makineyi şişkin tutmamaya çalışıyorum; öyle ki açılıp yeni giriş yaptığımda yalnızca 40 süreç çalışıyor. Şu anda gerçekten yazılım mühendisliği yapıyorum. C’nin sorunlarını etkili biçimde hafifletirken yazılımı küçük ve hızlı tutmaya çalışıyorum ve bir gün bunun üzerine bir iş kurabilmeyi umuyorum
Şişkin olmayan, çevik yazılımlar için hâlâ bir pazar olup olmadığını göreceğiz gibi
https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-i...
https://gavinhoward.com/2020/12/my-development-environment-a...
https://gavinhoward.com/2023/06/an-apology-to-the-gentoo-aut...
https://gavinhoward.com/2023/09/lessons-learned-as-a-user-3-...
1980’lerde WordPerfect, Lotus 123, MS-DOS 1.0 ve Microsoft tarafından satın alınmadan önceki SubLogic Flight Simulator gibi programlar assembly ile yazılmıştı. O dönemde sektörü izleyenler, Microsoft’un WordPerfect ve Lotus 123’e göre yeni özelliklerde daha hızlı iterasyon yapmasını ve başka mimarilere daha hızlı port etmesini, MS Word ve MS Excel’in “şişkin” C ile yazılmış olmasına bağlıyordu. Çünkü rakipler assembly’de fazla uzun süre kalmıştı
Kişisel yazılımlarda da aynı ödünleşimi görüyorum. Daha ince C/C++ yerine daha üst seviye ve “şişkin” C#/Python kullanınca belirli işleri çok daha hızlı bitirebiliyorsunuz. C++’ta daha yetkinim ve küçük çalıştırılabilir dosyaları tercih ediyorum, ama C# yapmak istediğim işi daha hızlı bitiriyorsa o avantajın anlamı kalmıyor. Ben de şişkin yazılım sorununun bir parçasıyım
“Dünyanın en güçlü ve en hafif köprüsünü yapacağım” demek hayranlık uyandırıcıdır; “müşterinin karşılayabileceği maliyetle yeterince hafif ve yeterince güçlü bir köprü yapacağım” demek mühendisliktir
Yarısından biraz fazlasını okuyup bıraktım, ama temel iddia yazılımın hızlı olması gerektiği gibi görünüyordu; bu felsefenin gerekçelendirilmesine dair de “zaten gerçek bu” imasından başka aklımda bir şey kalmadı. Verimlilik artışının, verimliliğin peşinden koşmanın zaman maliyetini asla karşılamadığı durumlar olabileceği karşı argümanını kabul ediyordu, ama bu savla gerçekten boğuşmadan geçip gidiyordu
Yazının bir diğer temel özelliği verileri cımbızlamak ve alanı aşırı basitleştirmekti. “Yazılım o zamanı ve alanı kullanarak ne yapıyor ki?” diye birkaç kez duygusal bir çağrı yapıyor, ama bu soruyu ciddi biçimde yanıtlamaya çalışmıyor; yanıtının olmamasını da sanki yanlış yanıtın kanıtıymış gibi kullanıyor. İşlevsel eşdeğerliği olmayan çeşitli yazılımları da yalnızca performansları farklıymış gibi karşılaştırıyor
Verimsizliğin toplumsal, çevresel ve iş maliyetleri ile daha verimli yazılım hakkında söylenecek çok şey var; ama modern yazılımın, aslında hiçbir şey üretemeyecek kişilerin bile kendi ihtiyaç duydukları “kötü” şeyleri yapabilmesini sağlaması da tartışmaya değer. Bir yapı mühendisi “yeterince güçlü” olanı seçtiği gibi, modern geliştiriciler de çoğu zaman “yeterince hızlı” olanı hedefliyor
Tartışılacak zengin birçok konu var, ama bu yazı duygusal öfkede kalmış ve gerçek akıl yürütme ile argümanları ele alamamış. Bazı iddialarda doğruluk payı var, fakat yazının kendisi tartışma niyetinde olmadığını bence açıkça göstermiş
Ağınız da muhtemelen birkaç kbps’lik 2G değil, yüzlerce Mbps’lik 5G ya da fiber bağlantı. Sonuçta eylemler sözlerden daha güçlüdür; toplumun tamamı “daha hızlı yazılım” aksiyomuna göre hareket ediyorsa bunu gerçek olarak kabul etmekte sakınca yok
Özellikle de “geliştiricinin zamanı daha değerlidir” iddiasıyla aynı yerden çıkan bir aksiyom bu; fark yalnızca kimin zamanından tasarruf edildiğinde
Geliştirici düşük donanımlı cihazlarda da test etmezse bu sorundan hiç haberdar olamaz. Asıl sorun teknik taraftan ziyade, kodun çok yavaş olduğu rahatsız edici gerçeğiyle yüzleşildiğinde bazı geliştiricilerin savunmaya geçip hemen tartışmaya başlaması. Ürün yöneticisiyle oturup profil çıkarma ve optimizasyon için zaman ayırmak, baştan yeniden yazmadan performans sorununu nasıl hafifletebileceğinize bakmak gerekir
BASIC ve SQL de çok eskiden beri insanların “kötü” bir şey yapabilmesini amaçlıyordu; Fortran ve bugün ortadan kalkmış birçok dil ve teknoloji de öyleydi
Python ya da Java en cömert yorumla bile muhafazakâr; 70’lerdeki programlama dili gelişimini düşünürsek aslında anakronik demek gerekir. J ya da Prolog kavramsal olarak Rust veya Go’dan çok daha ileride, ama daha önce üretildiler. C89’dan C23’e kadar birikmiş C modern bir dil mi, yoksa yalnızca C23 mü modern; C89 ile C23 arasında gerçekten büyük bir fark var mı, o da muğlak
Üretildiği zaman ya da hayali bir evrim ağacı değilse, modernliği tanımlamanın başka bir yolu var mı merak ediyorum
Eski bir yakınma. Kanıksadığımız birçok kolaylığın bir maliyeti var ve bu maliyet ciddi biçimde birikiyor. 4K ekran, 800x600’den 17 kat fazla piksele sahip ve 32 bit renk kullanıyor; bu yüzden modern ekranlara yönelik grafiklerin ham boyutu yaklaşık 68 kat büyüyor
Eskiden statik görüntüler yeterliydi, ama artık yüksek kaliteli, yüksek kare hızlı animasyonlar standart. Arial Unicode 15MB’lık bir yazı tipi ve Windows 95 çalıştıran çoğu bilgisayarın belleğine sığmazdı bile
Her yerde yazım denetimi olağan hale geldi; bunlar üst üste ekleniyor. Yine de bilgisayarları çok daha konforlu kılıyorlar. 16 renkli video modlarını ya da çok sinir bozucu dolambaçlı çözümler olmadan İngilizce dışındaki iki dili aynı anda kullanamadığımız günleri özlemiyorum
Ama tek amacı bekleme süresini daha az sıkıcı göstermek olan animasyonları istemiyorum. Unicode da bedelini ödemeye değer
Yine de 1981’de olduğu gibi glifleri tek haneli milisaniyeler içinde ekrana çizebilmeliyiz. Pikseller ve glifler arttı, ama bu mümkün; yalnızca öncelik değil
Performans odaklı bir BMW’ye 100 bin dolar ödedikten sonra mühendisin 0-60mph hızlanmasının 30 saniye sürdüğünü söylemesi ve kullanıcının performans uzmanı olmadığı için bunu olduğu gibi kabul etmesi gerektiğini söylemesi gibi
Mevcut organizasyonda da benzer bir akış gördüm. Başlarda ekip küçükken ayrıntılar önemliydi. Yavaş olmamalıydı, animasyonlar akıcı olmalıydı, kaydırma hızı ve yükleme süreleri önemliydi; kullanıcı verimliliğini artırmak için en verimli ürünü yapmaya çalışıyorduk.
Ekip büyüdükçe değer, geliştirici verimliliğini artırma yönüne kaydı. Daha fazla soyutlama, katman ve framework geldi; bir geliştiricinin bir gününü kurtarmak uğruna tüm kullanıcıların toplamda milyonlarca saniyesini harcatan ödünler kabul edildi.
Fark görünürlükte. Yönetim geliştirme tarafındaki maliyeti görebiliyor ama biraz daha hızlı çalışma süresinin, daha iyi önbelleklemenin, daha akıcı kaydırmanın faydasını göremiyor. Çünkü ölçülmüyor. Bir organizasyon yalnızca ölçülebilir sayıları önemser noktaya geldiğinde bu akış doğal görünüyor.
Tabii bu, yapay zekanın bizim kötü yazdığımız şeyleri, ya da yapay zekanın kötü yazdığı şeyleri ve özgün yazının öngördüğü gibi son derece verimsiz yapay zekanın kendisini düzeltebilecek noktaya gelmesine kadar geçerli.
Arabalar ancak dışarıdan gelen petrol şokundan sonra optimize edildi; o da çok düzensiz biçimde. Aslında verimsiz ürünler çoğu zaman daha kârlıdır, çünkü müşteri onları daha sık değiştirmek zorunda kalır. Bir yıl sonra çatlayan berbat bir iPhone kablosu, Apple’ın tekrar tekrar yedek parça ücreti almasını sağlar. Beyaz eşyalar daha sık bozulur ama daha ucuza üretilir, birim başına kârı artırır. Önemli olan satış sonrası kullanım verimliliği değil, üretim verimliliğidir.
Yazılımda kapitalizm, yeni otomasyonları olabildiğince hızlı piyasaya sürüp enerji ve zaman israfını tüketicinin sırtına yükleyecek şekilde işler. Üretim zinciri giderek standartlaşıp optimize edildi; React geliştiricisini ya da Kubernetes yöneticisini depo işçisi gibi değiştirilebilir hale getirdi, bununla birlikte ücret baskısı da oluştu. Bazı otomasyonlar, muhasebe terimlerini anlaşılmaz hale getirip mesleği meşrulaştırmak gibi kendi kendini haklı çıkarmaya yakın; geri kalanı ise kârla ilgili.
Her şeyin bir maliyeti var. Hesaplama maliyeti ya da kötüleşen kullanıcı deneyimi yeterince büyükse verimlilik optimize edilir. ML modelleri buna örnek. Diğer durumlarda optimize edilmez, çünkü son kullanıcı daha az özellik karşılığında bunu istemez.
Arabalar da eskiden çok yakıt tüketirdi; ama yakıt maliyetleri ve çevre kaygıları yüzünden müşteriler başka bir şey istemeye başlayınca değişti. Birçok mühendis, müşteriler için ürün yapmak üzere para aldığını unutuyor.
Ayrıca özgün yazının yazarı eski bir Windows ya da Linux makinesinin tamamen açılmasını beklememiş gibi görünüyor. Modern sürümler çok daha hızlı açılıyor çünkü müşteriler bunu istedi. Telefonlar 24 saat açık kaldığından, birkaç ayda bir açılışın uzun sürmesini müşteri önemsemiyor.
Benim BIOS’um POST için yaklaşık 20 saniye harcıyor ve bunun normal olduğu söyleniyor. Sonrasında işletim sisteminin açılması yaklaşık 10 saniye sürüyor.
Doktorların ya da mühendislerin de yeni ilaçlar veya yeni enerji kaynakları geliştirmek için para aldıkları söylenebilir; ancak bu alanlar hassas ve önemli olduğu için devlet denetiminin birçok katmanı vardır. Yazılımda henüz bu düzeyde denetim yok.
Bunların ortamın kendisini şekillendirecek gücü var; bu yüzden “müşteri talebi”nin sonucunu büyük ölçüde başka yöne çevirebilirler.
Bu yazı 2018’den ve daha önce birkaç tartışma olmuştu.
https://news.ycombinator.com/item?id=18012334 (Eyl 2018)
https://news.ycombinator.com/item?id=21929709 (Oca 2020)
https://news.ycombinator.com/item?id=31798580 (Haz 2022)
Derinden katılıyorum. Geliştiriciler olarak seçim hakkımız olduğunu hatırlamak önemli. Her konuda seçim yapamayız ama daha az kötü alternatifi seçebiliriz.
Node kullanmak zorunda değilsiniz. .NET ya da JVM ekosistemlerinde de harika, geriye dönük uyumlu yazılımlar yazabilir ve bunların 10 yıl sonra da değişiklik gerekmeden çalışmasını bekleyebilirsiniz.
Tek sayfalı web sayfası yapmak zorunda da değilsiniz. Her tıklamada sayfayı tamamen yeniden yükleyen eski usul HTML de gayet iyi çalışır; hatta bu noktada gecikmesi daha düşük bile olabilir.
Masaüstü uygulamanızı Chromium ile yapmak zorunda da değilsiniz. Bir UI framework’ünü başlatmak biraz daha fazla iş ister ama kalite buna değer. Karar yetkisi her zaman bizde olmayabilir; ama olduğunda kötü seçimlerden uzaklaşmalıyız.