- Birçok insanın hayal ettiğinden daha fazla sistem eski donanım üzerinde yeterince çalışabilir
- Gerçek yazılım optimizasyonu yapılırsa bu tür bir verimliliğe ulaşma olasılığı yüksektir
- Kıt bilişim kaynaklarının piyasa fiyatı sinyalleri, yazılım verimliliği için teşvik yaratır
- Mevcut yorumlayıcı tabanlı mikroservis ürünlerini native code ile oluşturulmuş monolitik mimariye dönüştürme ihtiyacı vardır
- Buna karşılık, çok ucuz ve ölçeklenebilir hesaplama kaynakları olmasaydı yenilikçi yeni ürünlerin geliştirilmesi muhtemelen çok daha seyrek gerçekleşirdi
1 yorum
Hacker News görüşleri
Piyasada hatalı ve verimsiz yazılımların da kusursuz yazılımlar kadar iyi satabildiği söylenebilir; çünkü ikisinden biri üretmesi en ucuz olan yazılımdır. Bu, “limon piyasası” hikâyesine benzer: piyasa tüm ürünleri yüksek kaliteliymiş gibi fiyatlar ama gerçekte maliyeti düşürmek için kaliteden feragat eder. Alıcılar satın almadan önce yüksek kaliteyle düşük kaliteyi ayırt edemediği için ikisine olan talep yapay olarak birbirine yaklaşır; bunun nedeni bilgi asimetrisidir. Bu olgu zaten gerçek ve yapay zekada da giderek daha görünür hale geliyor. Kullanıcılar gelişmiş makine öğrenimi uygulamalarıyla sadece üstüne “AI” etiketi yapıştırılmış bir çamaşır makinesini ayırt edemiyor. “AI” etiketi tek başına fiyat primi yaratıyor; böylece kullanıcı çamaşır makinesine gereğinden fazla para ödüyor. Alıcının “uzmanlar tarafından tasarlanmış ve yazılmış yazılım” aldığını sanıp berbat bir yazılıma para ödemesi de temelde aynı şey. Neredeyse tüm yazılımlar IC1-3 seviyesinde yazılıyor ve QA görevlisi de çoğu şirkette kaliteyi yükseltmeye çalışan tek kişi oluyor. Bazen stajyerler “LGTM” mantrasını tekrarlayıp iyileşme umuyor ama gerçekte bu bile nadir
Kaliteyle farklılaşan bir yazılım girişimi kurmaya çalıştım; daha iyi bir ürün olursa insanların bunu fark edip başarı getireceğine emindim ama öyle olmadı. Büyüdük ama çok yavaş büyüdük ve kâra geçemeden para tükendi. Öğrendiğim şey, düşük maliyetin ve dolayısıyla düşük kalitenin rekabetçi pazarlarda bir avantaj olduğuydu. Bunu üniversiteden beri duyuyordum ama bu deneyimle iliklerime kadar hissettim. Piyasada her şeyin vasata çekilmesinin ve bir şey popülerleştikçe yüksek kalitenin de bozulmasının nedeni bu. Ürün ölçeklendikçe maliyet düşürme baskısı artıyor. İnsanlar ucuza almak istiyor; biri de maliyeti (yani kaliteyi) kısarak daha ucuza veriyor. Şirketler hayatta kalmak ve kâr etmek için asgariyi ödüyor. Elbette bazen istisnalar var ama sonunda gidişat hep kademeli maliyet düşüşüne çıkıyor. Muhtemelen bunun da bir adı vardır; limon piyasasına biraz benziyor ama tam o değil. Piyasa çökmüyor, onun yerine her yere istikrarlı bir vasatlık yayılıyor
Piyasanın her ürünü “yüksek kalite” diye sattığı görüşüne itiraz var. Burada “yüksek kalite”nin ne demek olduğu önemli. Düşük performans = düşük kalite gibi anlaşılıyor ama gerçekte Teams, Slack, Jira gibi performansı kötü diye eleştirilen uygulamaların rakiplerine kıyasla çok daha iyi performans veren alternatifleri var. Ancak kullanıcılara Slack yerine terminal arayüzlü, görüntülü görüşmesi olmayan, emojisiz Weechat’ı seçmeleri söylense çoğu kişi ikincisini daha düşük kaliteli sayar. Performans da sadece bir özelliktir. Örneğin Chrome’un ilk başarısı hızlı olmasındandı ve Python geliştiricileri de performans kazanımı için uv/ruff’a geçiyor. Ama Slack 5 saniyede değil de 10 ms’de açılsa bile çoğu kullanıcı bunu önemsemez
Verimsiz yazılımın piyasanın limon yapısından kaynaklandığına katılmıyorum; bu sadece bilgi asimetrisi varsa geçerlidir. Çoğu durumda insanlar birkaç küçük hatayı umursamaz ve daha düşük fiyat ister. Çok sıkı QA ve birden fazla mühendisin kod denetimi süreçlerinden geçince fiyat karşılaştırması netleşiyor. Küçük ölçekte, küçük bir kitabevi için yazılım yaptım; hızlı geliştirdim ve çok da ücret almadım. Kusursuz değildi ama sorun çıktıkça hemen düzelttim, müşteri de bunun iyi bir anlaşma olduğunu bildiği için memnundu
Büyük şirketlerde korkunç İK, masraf yönetimi, zaman takibi ve sigorta portalları kullandım. O kadar kötüydüler ki ödemeyi yapan kişinin bu ürünü gerçekten kullanıp kullanmadığını sorguladım. Bir ekip müşteriye hatalar ve UI kâbuslarıyla dolu bir ürün sunsa, anında azar işitir, görevden alınır, hatta kovulmayı hak eder
Piyasanın “hatalı, verimsiz yazılım” satın almasının özü, aslında piyasanın <i>destek</i> satın alıyor olması. Bu, Google ya da insan desteği zayıf şirketler için de geçerli. “Destek” birçok biçimde ortaya çıkar — dokümantasyon, videolar, blog yazıları, yardım eden insanlar, kullandığım ortamın desteği (işletim sistemi, tarayıcı vb.), yapmak istediğim işin desteklenmesi vb. En kötü ERP’yi bile hayatta tutan bir numaralı şey sonunda gerçek insanlardır. Bir ürünün ölüm çizgisini belirleyen şey destek olup olmamasıdır. Küçük bir ekip kavga kazanmak istiyorsa “destek ihtiyacını” azaltıp desteği başka bir boyutta sunmak akıllıcadır. En kolay yol insan eklemektir. Ve güçlü yanları doğru anlatmak gerekir. Destek türüne göre değerlendirme değişir; örneğin açık kaynak kod ile kapalı kod karşılaştırmasında birçok kişi, koddan çok destek varsa kapalı olanı tercih eder
Costco’dan alışveriş yapmayı sevmemin büyük nedenlerinden biri, genelde çöp ürünler satmamaları. Filtreleri her zaman benim ölçütlerimle örtüşmüyor ama yine de anlamlı bir kalite filtresi sağlıyor
Kullanıcılar yazılım kalitesi ve performansına göre karar verebiliyor olsa bile, açık uygulama listeme baktığımda hiçbir uygulamayı sırf daha hızlı diye değiştiremem. Mesela Docker, iterm2, WhatsApp gibi araçları çok belirli nedenlerle kullanıyorum. En hızlı çözüm olsa bile geçemem; baştan benim ihtiyaçlarımı karşılayan bir yazılımın varlığı, performans ölçütünün ötesinde daha önemli bir şey
Yazılımların %99’u performans düşünülmeden yazılıyor. HN’de bile performans iyileştirmesi başlı başına tabu gibi görülüyor. L4/5 üzeri mühendislerde bile performans sezgisi çoğu zaman zayıf. İş açısından bakınca da yazılımı çalıştıracak donanım yetersiz kalana kadar verimlilik pek umursanmıyor; o durumda bile önce ek donanım almak tercih ediliyor
Bugünkü piyasa yapısında gerektiğinde yeni donanım alıp çalıştırabildiğimiz için hatalı ve verimsiz yazılım baskın durumda. Yazılım, donanımın işlem kapasitesini dolduracak şekilde şişiyor — “Andy verirse Bill alır” yasası. Bu yüzden yalın ve kaliteli yazılım üretmeye yönelik bir teşvik yok. Ama artık en gelişmiş çiplerin bulunamadığı bir dünya gelirse (örneğin jeopolitik kriz, büyük fabrika yıkımları vb.), kaynakları tutumlu kullanan yazılımlar ekonomik olarak çok değerli hale gelir; şişmiş yazılımlar artık çalıştırılamaz olur. Carmack da böyle bir durumda optimizasyon için hâlâ büyük bir alan olduğunu, sonuçta bir şekilde eski nesil çiplerde de yazılım çalıştırılabileceğini söylüyor
İyi tasarlanmış yazılımın değiştirilmesi kolaydır. Buna karşılık hatalarla dolu bir spagetti kod yığınına kimse dokunmak istemez; bu yüzden sonsuza kadar kalır. Saf evrim mantığıyla bakarsak sonunda kötü yazılımın baskın gelmesi şaşırtıcı değildir
İkinci el araba piyasasının limon piyasası olmasının nedeni, iyi bakılmış araçla bozulmak üzere olan aracı ayırt etmenin zor olmasıdır. Ama yeni araba piyasasında sıkı denetim olduğu için bu durum geçerli değildir. Yazılım ise her zaman yenidir. Nasıl ki otomobil kalitesi onlarca yıl içinde arttıysa, yazılımın da kalitesi yükseltilebilir. Belirli standartları karşılamadan satılamamalı, ciddi hatalar varsa geri çağırma olmalı, bilerek kusurlu ürün satana ceza verilmeli. Diğer tüm sektörler böyle işliyor
Web 2.0 “sonsuz beta” ve SaaS modelinin yaygınlaşması sayesinde kullanıcıların sabır eşiği de değişti. Microsoft nesiller boyunca “yazılımın bozuk olması normaldir” fikrini yerleştirdi. Herkes kötü yazılıma alıştıkça iyi yazılımın değerini de daha az anlar oldu
Ben gerçekten o AI etiketli çamaşır makinesinden aldım. Pazarlaması güldürdü ama fiyatı makuldü, o yüzden satın aldım
Sanırım burada sadece güvenlik açıklarından söz ediliyor. Performans veya başka hatalarla dolu Excel ya da Photoshop olsa insanlar çabucak kullanmayı bırakırdı. Ama güvenlik kullanıcı tarafından sorun çıkana kadar fark edilmez ve kullanıcı hack’lense bile nedenini bilmez; geliştiricinin de güçlü bir teşviki olmaz. Performansta ise belli bir seviyeden sonra daha fazla optimizasyona kaynak ayırmak istenmez; azalan getiri yasası devreye girer
Kullanıcı AI’ın ne kadar gelişmiş olduğunu ve sadece göstermelik “AI çamaşır makinesini” ayırt edemese bile, iyi AI kullanıcıların bilgi asimetrisini kendi başlarına aşmasına yardımcı olabilir. Sonuçta iyi AI’ı seçmenin bir yolu varsa sorun çözülebilir
“En ucuz yazılımı” üretmenin otomatik olarak ucuz olduğunu düşünmüyorum. Girişim ölçeğinde alelacele yapılmış yazılım daha ucuz olabilir ama ölçek büyüdükçe maliyeti daha da artar. Havayolları bile bir zeytini eksilterek maliyet kısıyor; bu durumda geliştiricilere optimizasyon yaptırmanın neden verimli görülmediğini merak ediyorum. Sürekli yeni özellik ekliyoruz ama kullanıcı sonunda her güncellemede yavaşlamayı hissediyor. Tersine hızlandığında da seviniyor. Mühendisler MBA gibi davranıp sürekli “değeri yok” cevabını veriyor. Oysa yazılım hatasını düzeltmenin “değeri” oldukça öznel. Mühendisin görevi hataları düzeltmektir. Marka da önemli ama bugünün büyük markaları marka değerini önemsemiyor gibi. Muhtemelen tüketici kolay kolay geçiş yapmadığı için; ama değiştirince de sadece yeni bir UI ve öğrenilmesi gereken yeni dertler geliyor (Apple bile artık sezgisel değil)
Bugünün dünyası zaten önceki nesil donanımlarda da çalışabilir ama CPU ve donanım sürekli hızlandığı için kodu daha verimli yazmaya gerek duyulmuyor
Bilgi asimetrisi sorunu FOSS ya da kapalı ama “shared source” ürünlerde aşılabilir. Koda doğrudan bakarak genel olarak kaliteli olup olmadığını anlayabilirsiniz. Belki somut hataları bulamazsınız ama fonksiyon uzunluğu, yorumlar, isimlendirme gibi şeylerden vicdanlı bir geliştirme kültürü olup olmadığını sezebilirsiniz. Gerçekten baktığınızda veritabanı şeması darmadağın olan pahalı kapalı ürünlere güven duymuyorsunuz
Kötü yazılım uzun vadede üretim (bakım) açısından daha pahalıya gelir
Bu yüzden markanın kalite koruyucusu işlevi gördüğü söyleniyor
Nasıl gıdada toksik, tarihi geçmiş ya da bağımlılık yapıcı katkılar içeren ürünlerin satışı yasaksa, yazılım için de düzenleme olmalı. Ama GDPR’dan önce düzenleme neredeyse anlamsızdı; bugün bile ihlaller günlük hayatın parçası
1980’den beri işlem gücü yaklaşık 1000 kat arttı. Dinamik dizi sınır kontrolünün performans maliyeti %5 olsa (ki gerçekte muhtemelen çok daha düşük), bu kontroller açıkken bile 950 kat daha hızlı bilgisayarlar kullanıyor olurduk. 1980’e dönüp “daha az hatalı, debug etmesi daha kolay, 950 kat hızlı bilgisayar” ile “yalnızca 1000 kat hızlı ama hâlâ daha hatalı ve debug etmesi daha zor bilgisayar” arasında seçim yap deseler, çoğu kişi 950’yi seçerdi. Ama biz sonunda 1000’i seçtik. Ben şahsen 1000 katçıların her şeyi bozduğunu düşünüyorum
Ama o 1000 kat performans, sınır kontrolüne değil bitmek bilmeyen soyutlama ve verimsizliğe harcandı
Yavaş ve hatalı yazılım satan tedarikçilere bunu Sparc 20’de çalıştırmalarını dayattığım oldu. Sonuçta yazılımı optimize ettiler ve şirketin piyasada başarılı olabileceği temel oluştu. Optimizasyon bir rekabet avantajıdır
Bu sadece 1980 sonrası için geçerli olabilir. Yakın tarihli bir videonun özeti şuydu: “Günümüz bilgisayarları 20 yıl öncekilerden o kadar da hızlı değil; bunu ancak özel optimizasyon yaparsanız hissediyorsunuz.” Konuşmacı derleyici optimizasyonları gibi şeyleri göz ardı etse de, gerçek performans artışının düşünüldüğü kadar büyük olmadığı, 15 yılda sadece iki kat arttığı söyleniyordu
Dizi sınır kontrolünün sadece %5 maliyet getirdiği varsayıldı ama tüm algoritmalar bu kadar basit değil. İşlem sayısına göre sadece kontrol eklemek bile maliyeti 3-4 kat artırabilir. Bazı kullanım alanlarında bu kontrolleri zorunlu kılmak dilin rekabet gücünü yok eder. Çoğu durumda önemli değil ama güvenli/genel mod ayrımıyla kullanmak daha mantıklı olur
Sadece sınır kontrolünü düşünürseniz maliyet düşük olabilir ama güvenli dillerin genel yükü çok daha büyüktür. GC dillerinde bellek kullanımı birkaç kat artabiliyor
Büyük sayılar yasasını unutmamak gerekir. Tek bir sistemde performansın %5 düşmesi büyük mesele olmayabilir ama dünya çapındaki tüm hesaplama ortamlarında %5 kayıp birikirse etkisi çok büyük olur
İnsan doğasının kısa vadeli kazancı tercih etmesine katılıyorum ama dinamik sınır kontrolleri güvenlik sorununu kendi başına çözmez; nihai çözüm hâlâ yok
Bugün bu halde olmamızın temel nedeni, tarayıcıya bağlı kalmış olmamız
İlk yanıt aslında neredeyse doğru cevaptı; C’nin hâlâ bu kadar yaygın kullanılması bile sorunun özünde yığının alt katmanlarında verimsizlik olduğunu gösteriyor
“%5” rakamının dayanağı belirsiz; hangi ölçüte göre hesaplandığı güven vermiyor. Diziye her eleman koyuşta kontrol yapıldığında gerçek maliyetin iki katı geçip geçmeyeceğini merak ediyorum
Günümüzde çoğu programlama dili zaten dizi sınır kontrolünü varsayılan olarak destekliyor
Node.js ilk çıktığında olanları hatırlatıyor. İstemci ve sunucu kodlamasını birleştirmesi büyük avantajdı ama bugün bir güvenlik kâbusuna dönüştü; daha küçük kod tabanına sahip minimalist dillerin de avantajı var
Tek bir string’in gigabaytlarca veriyi taşıyabildiğini daha erken fark etseydik, null sonlandırmalı string’ler ortadan kalkar ve herkes daha az acı çekerdi
1000 kat hızlı üründen keyif alan 1000Xers aslında çok küçük bir azınlık; sıradan kullanıcının karşılaştığı masaüstü yazılımları hâlâ yavaş
Aslında yaklaşık 100 bin kat daha hızlı hale geldik: sadece saat hızı 1000 kat, çekirdek sayısı 10 kat, komutlar AVX vb. sayesinde 10 kat; mimari olarak 1-2 milyon kat daha hızlıyız. Yine de hissedilen hıza etkisi yok
Robert Barton’ın böyle insanlara “aşağılık bir tarikatın başrahipleri” dediği söz aktarılıyor
1980’den itibaren bakınca hızlı ama 2005 sonrası bakarsanız artış yaklaşık 5 kat civarında
Saat hızı 2000 kat, SIMD gibi IPC ile 80 kat, çekirdeklerle çarpınca toplamda 1-2 milyon kat hız var. Ama programların çoğu, yazarları tarafından sadece “çalışıyorsa hızı da odur” anlayışıyla geliştiriliyor. Optimizasyonu gerçekten düşünenler çok az; HN kullanıcıları arasında bile böyle
2001’de 1GHz CPU, temel yazılımlar için yürütme hedefi olmalıydı. AI deneyimi de epey hayal kırıklığı yarattı. LLM’lerin dil dönüştürme, kod optimizasyonu vb. işleri rahatça yapmasını bekliyordum ama gerçek öyle değil. AI’a Unix
sedkodunu JVM diline port ettirdiğim bile oldu; temel şeyler dışında orta seviyenin üstünde tamamen başarısızdı. Sonuçta tüm bu akımın amacı yazılım kalitesini artırmak değil, “işleri azaltmak”. AI bundan sonra daha fazla kötü yazılım üretecekİşte bu, JavaScript’in ve kullanıcının geleceği
Google’da (ve Facebook’ta) çalışırken donanımın ne kadar ucuz olduğunu ve kod optimizasyonunun çoğu zaman ne kadar değersiz kaldığını gördüm. 10 yıldan da önce Google’da veri merkezi kaynak yönetimi zorunluydu ve her projenin bir bütçesi vardı. CPU, HDD, flash vb. kaynaklar birbiriyle takas edilerek göreli maliyet hesaplanıyordu. Flash, HDD’den 20 kat pahalı olsa bile gerçek darboğazlar hesaba katıldığında bazen daha ucuz hale gelebiliyordu. Bu kaynaklar yazılım mühendisi zamanı (1 SWE = 1 kişi-yıl) gibi ölçülere çevriliyordu. Bir optimizasyon 5000’den fazla CPU çekirdeği tasarrufu sağlamıyorsa çoğu zaman zarardı. Yalnızca çok büyük projelerde optimizasyon anlamlıydı; geri kalanında kod zaten kısa süre sonra değişeceği için anlamsızdı. Bir de web kullanılabilirliği açısından fare arayüzü çok verimsiz ve 30-40 yıl önceki metin tabanlı terminaller çok daha etkiliydi. “Web standartlaşır ve bir sonraki aşamaya geçeriz” diye umut ettim ama olmadı. Hâlâ her hafta yeni bir framework çıkıyor ve aynı kaydırma çubuğu bile donanımla uyumlu olmayacak şekilde yeniden uygulanıyor. Bunun çözümünü bilmiyorum
Bunun ancak mühendislik maliyetinin yüksek olduğu, marjı büyük ve çok sayıda projesi olan şirketlerde geçerli bir değerlendirme olduğunu düşünüyorum. Gerçekten biraz bile fazla para kalıyorsa onu mühendisleri optimizasyona ayırmak için kullanmak daha iyidir. Pratikte ise her şirket Google’ı taklit ediyor ve ekonomi mantığından bağımsız kararlar veriyor; bu da pek çok sorunu açıklıyor
Ben de eski Google çalışanıyım. Google daha çok CPU bazlı kullanım optimizasyonundan söz eder ama gerçekte iki şeye çok önem verirdi: latency ve toplam sunucu kullanım oranı. İkisi de üst yönetim için kritik KPI’lardı ve muazzam mühendislik kaynağı ayrılırdı. Makine sayısı büyüdükçe boşta bırakmak istemezsiniz ve latency’ye duyarlı bir işte birkaç ms azaltmak bile ciddi çaba gerektirir
Google kıstası, çekirdek başına maliyetin büyük olduğu şirketlerde anlamlıdır. Çoğu sıradan şirket için hiç geçerli değil; Facebook/Google/Netflix ölçeğinde işe yarayan bir yaklaşım
Google’ın daha iyi sıkıştırma ve ikili serileştirme formatları geliştirmesi de kendi kârlılığını artırmak içindi
Başlığı görünce Carmack’ın düşük güçlü donanımda yazılım optimizasyonunu eleştirdiğini sandım. Aslında öyle değil; donanım ilerlemesinin durduğu varsayımsal bir senaryodan söz ediyor ve sonuçta “ucuz, ölçeklenebilir hesaplama olmazsa yenilikçi ürünler azalır” diyor
Bu, dün açılan başlıkla bağlantılı bir konu
“Ucuz ve ölçeklenebilir hesaplama olmadan inovasyon azalır” sonucuna karşılık, pratikte akıllı telefondan bu yana neredeyse hiç yenilik görmedik; sermaye donanım ilerlemesine bağımlı hale geldiği için yeni ürünler de özünde eskilerden çok farklı değil
Ben şahsen buna katılmıyorum. Özellik geliştirmeye bir süre ara verilse bile yeterli hazırlıktan sonra inovasyon geri döner. Bir düşüş olabilir ama kalıcı olmaz
Asıl nokta, “şişkinlik”in salt israf değil, ekonomik teşviklerle ortaya çıkan bir geliştirme verimliliği aracı olması. Daha az karmaşık dillerle üretkenliği artırmak, daha fazla insan istihdam etmekten ve maliyet kısmaktan daha etkili olabiliyor
Donanım ömrünü planlı eskitme yerine 5 ya da 10 yıl daha uzatabilsek, elektronik atık, nadir mineral kullanımı ve sera gazı salımı muazzam ölçüde azalırdı. Ancak yazılım piyasası bu dışsallıkların maliyetini üstlenmiyor. Yayınla, test et, düzelt, yinele modeli uzun vadeli tasarımdan çok daha ucuz. Oyun sektörünün bazı bölümleri yüksek performans + gelir formülünü buldu ama yaygın değil. Kurumsal ve tüketici yazılımlarında performanstan çok, kullanıcının “katlanabildiği sınır” kadar minimum gereksinim önemseniyor. Sürekli yeni özellik eklenmesi ve değişim yüzünden performansa odaklanmak zor; bütçelerde de hata payı için pay bırakılıyor. Daha “hazır” halde ürün çıkaran yaklaşımlara kıyasla burada karmaşıklık ve değişim riski daha yüksek
Son 10 yılı aşkın süredir tüm borsa eşleştirme motorunu tek thread üzerinde çalıştırıyoruz. En azından işlemlerin sıralı işlenmesi tarafında hesaplama gücü o kadar da hızlı artmadı. Saniyede milyonlarca işlem yoksa kümeye yayılmaya bile gerek yok; tasarımı basitleştirip tek makinede halletmek mümkün
Bu gerçekten çok sinir bozucu. Birçok sistem mimarı kendi damgasını vurmak için sistemi gereksiz yere karmaşıklaştırdı ve bununla birlikte yeni sorunlar üretti. Oysa ilk tasarımlar zaten çoğu ihtiyacı karşılıyordu ve bugünün yerel işlem gücüyle tek makine çözümü gayet yeterli
Emir eşleştirmenin neden paralelleştirilemediğini merak ediyorum — sort’a benzer bir log kısaltma yaklaşımıyla paralel yapılabilir mi? Yoksa eşleştirme sürecinde basit sıralamanın ötesinde pek işlem olmadığı için mi zor?
Yalnızca basit işlem yapılacaksa tek thread yeterli olabilir ama her işlemde karmaşık hesap gerekiyorsa olmaz. Yine de gerçekte bunun ne kadar karmaşık olduğu konusunda alan bilgim yok
Geliştirme araçları ilerlemeyi sürdürseydi, eskiden RAD ile tam yerel GUI’ler kolayca yapılabiliyordu; bugün ise Electron baskın. Birden fazla web tarayıcısı, her biri Chromium tabanlı farklı türevler olarak sisteme kuruluyor
Sonuçta bu bir kaynak tahsisi ekonomisi sorunu. Geliştiricinin zamanını yazılımı optimize etmeye mi yoksa yeni özellik yapmaya mı harcatacağınıza karar veriyorsunuz. İkincisi daha çok gelir getiriyorsa tercih o olur; optimizasyon daha değerliyse de ona göre davranılır
Bunun ekonomik bir mesele olduğuna katılıyorum ama özünde yazılım şirketlerinin topluma yüklediği olumsuz dışsallıkların bir örneği olduğunu düşünüyorum. Ek enerji tüketimi, israf, artan elektronik atık vb. şeyleri hesaba katmıyorlar
Teknik ve finansal borcu başkalarına yıkıp muazzam miktarda çöp üretme düzeni bu. Optimizasyonun her zaman anlamlı olmayabileceğini kabul ediyorum ama sadece daha fazla sunucu ekleme alışkanlığı yine de üzücü
“Yeni özellik daha önemli” sözü duruma göre değişir. Ben son macOS, Windows, Android özelliklerinin çoğunu kullanmıyorum; verimli bir çalışma ortamı ve güvenlik benim için daha önemli. Tasarım yazılımlarında da yeni özellikten çok verimlilik artışı isterim. Hatta bazen 10 yıl önceki Illustrator/Photoshop’u arıyorum. Müzik üretim yazılımlarında yeni özellikler yaratıcı ihtiyaçlar için önemli olabilir ama verimliliği bozuyorsa itici geliyor. Kod editöründe VSCode bana yetiyor; daha hızlı ve hafif olmasını isterim
Kendi hayatımda verimlilik çok önemli. Örneğin mutfağa bir şey almaya giderken hep çöpleri ya da bulaşıkları da götürürüm ki iki kez yürümeyeyim. Yazılım da benzer. Ama “pahalı mühendis zamanı ile optimizasyon” ve “RAM/kaynak eklemek” arasında ikincisi neredeyse her zaman daha ucuz. Sorun yeterince büyüdüğünde ancak optimizasyon kazanç sağlar. Hangi seçeneğin daha iyi olduğuna en sonunda piyasa karar verir. Donanım ekleyerek elde edilen fayda azalmaya başlarsa yön optimizasyona döner. Moore yasası sınırına dayanmadığı için henüz o noktada değiliz
Sonuçta mesele taleptir. Tüketiciler daha hızlı yazılıma gerçekten önem verirse bunun için daha fazla ödemeye razı olur ama gerçekte performans düşük olsa bile fiyat daha ucuzsa onu seçerler
İşte “enshitification” tam olarak budur
Electron uygulamaları performans açısından çok eleştiriliyor ama Linux dizüstüyle iş ortamında ayakta kalmayı mümkün kılan temel yeniliklerden biri oldu. Örneğin Teams toplantılarına kurulum yapmadan kolayca katılabiliyorsunuz. Herkes Winamp’ın optimize kodunu özlese de pratikte Electron uygulamalarının erişilebilirliği rahatlık sağlıyor
Son dönemde Balatro oynarken düşündüğüm şey şu: Bugün bile yalnızca basit hesaplar ve sade grafikler gerektiren bir oyun, 90’ların donanımında (Pentium II + 3dfx) rahatça çalışabilecek gibi görünmesine rağmen, pratikte gereken minimum sistem özellikleri sürekli yükseliyor. Sadece modern dizüstünde çalışabilecek kadar aşırı gereksinim görmek şaşırtıcı
luavelove2dmotoruyla yapılmış. Geliştirici için rahatlık sağlıyor ama doğal olarak minimum sistem gereksinimini de yükseltiyor